SAP CRM Fiori采用了这种机制。
看一个具体的例子来理解。假设我用用户名Jerry选中了这个ID为3456的Opportunity，点击Edit按钮之后：
会触发一个读操作发到后台：
后台响应这个读请求，并且在响应的头部字段ETAG里写入了对应的值。
这个26AE结尾的ETAG的值可以由应用程序采取不同的逻辑计算，可以直接采用请求节点对应的最后修改时间戳(Last Changed Timestamp), 例如下面这段ABAP代码：
也可以基于数据的完整内容计算一个HASH值出来作为ETAG返回给Fiori UI:
现在我用另一个用户，对同一个Opportunity做了修改，成功保存。然后再回到用户Jerry的这个编辑窗口，此时Jerry根本不知道该Opportunity已经被另一个用户修改了。Jerry修改了Opportunity的Name字段，点击保存按钮。
收到这个提示信息。
从Chrome Development Tool里能观察到，当Jerry点击了保存按钮后，发送到后台的请求的头部包含了一个If-Match字段，这个字段的值就是Jerry第一次点击编辑按钮时，后台返回给Jerry的26AE结尾的ETAG字段。
背后发生了什么事请呢？在框架的方法CHECK_BEFORE_MODIFICATION里，框架会把Fiori UI请求传进来的ETAG和当前最新的ETAG做比较：
CHECK_BEFORE_MODIFICATION又会调用CHECK_ETAG_MATCH方法。如果check失败，当前的保存操作将不会执行。
这种方式用于S/4HANA的Fiori应用，比如Material application。这种Fiori应用，消费的OData service是基于CDS view 加上BOPF实现的。
打开一个Material，点击Edit:
此时到ABAP后台使用事务码SM12能观察到Material对应的数据库表被锁住了：
这是怎么实现的呢？
在S/4HANA后台使用事务码BOBX打开BO模型I_PRODUCTWD. 展开模型，双击EDIT，能看到这个Edit实现的类为CL_I_DR_PRODUCTWD.
双击这个class，它的方法LOCK_ACTIVE_DOCUMENT就是响应Fiori UI上编辑按钮点击的处理函数。
我们在这个方法里设置断点，然后在UI上点击编辑按钮，断点触发。从调用栈即可清除观察到编辑按钮点击之后，程序执行流是如何从BOPF框架投递到Material应用的枷锁代码。这个加锁逻辑调用的是传统的ABAP Enqueue function module。