SAP CRM Fiori採用了這種機制。數據庫
看一個具體的例子來理解。假設我用用戶名Jerry選中了這個ID爲3456的Opportunity,點擊Edit按鈕以後:app
會觸發一個讀操做發到後臺:框架
後臺響應這個讀請求,而且在響應的頭部字段ETAG裏寫入了對應的值。函數
這個26AE結尾的ETAG的值能夠由應用程序採起不一樣的邏輯計算,能夠直接採用請求節點對應的最後修改時間戳(Last Changed Timestamp), 例以下面這段ABAP代碼:事務
也能夠基於數據的完整內容計算一個HASH值出來做爲ETAG返回給Fiori UI:it
如今我用另外一個用戶,對同一個Opportunity作了修改,成功保存。而後再回到用戶Jerry的這個編輯窗口,此時Jerry根本不知道該Opportunity已經被另外一個用戶修改了。Jerry修改了Opportunity的Name字段,點擊保存按鈕。io
收到這個提示信息。ast
從Chrome Development Tool裏能觀察到,當Jerry點擊了保存按鈕後,發送到後臺的請求的頭部包含了一個If-Match字段,這個字段的值就是Jerry第一次點擊編輯按鈕時,後臺返回給Jerry的26AE結尾的ETAG字段。function
背後發生了什麼事請呢?在框架的方法CHECK_BEFORE_MODIFICATION裏,框架會把Fiori UI請求傳進來的ETAG和當前最新的ETAG作比較:class
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。
要獲取更多Jerry的原創技術文章,請關注公衆號"汪子熙"或者掃描下面二維碼: