在 SAP Fiori 应用里打开一张销售合同，页面从后端读取当前数据。几分钟后，业务人员修改了付款条件并保存。就在这段时间里，另一个会话也可能已经修改了同一张销售合同。如果前端仍然拿着几分钟前的旧数据直接发起PATCH，而后端毫无判断地接受这次修改，新请求就可能覆盖另一个会话已经提交的数据。
这种问题在企业系统里并不罕见。销售订单、采购申请、生产订单、服务确认、主数据维护，只要一个业务对象可能被多个会话同时访问，就会碰到版本一致性问题。
SAP Gateway Foundation 在 OData 服务运行时里提供的Conditional Handling，正是为这一类问题准备的。它建立在 HTTP 条件请求和ETag机制之上，其中If-Match主要解决修改操作中的并发一致性问题，If-None-Match主要解决读取操作中的重复传输问题。SAP Gateway 已经为很多常规场景准备了通用实现，应用开发不必每次都从头编写一套版本比较逻辑。
理解这套机制时，一个容易混淆的地方是ETag到底是什么。
ETag是 Entity Tag 的缩写，可以把它理解成服务器为某个资源版本提供的标识。SAP Gateway 官方文档强调，客户端读取一个实体时得到的是一个 opaque ETag，也就是不透明的标识值。客户端应该拿它进行后续比较，而不应该依赖它的内部编码方式去推断业务含义。
业务系统经常使用时间戳生成ETag。例如某些 SAP S/4HANA OData V4
