方法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。

要獲取更多Jerry的原創技術文章，請關注公眾號"汪子熙"或者掃描下面二維碼:

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/24475491/viewspace-2150971/，如需轉載，請註明出處，否則將追究法律責任。