方法1： ETAG机制
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失败，当前的保存操作将不会执行。
所以其实文章标题的“锁”其实并不准确，因为这种方法底层其实并不存在物理的基于数据库表某一行记录的锁。
方法2： 基于BOPF的锁实现
这种方式用于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。
- SAP Managed Tags:
