Shulou(Shulou.com)06/01 Report--

In this issue, the editor will bring you about how the two locking mechanisms in SAP Fiori are realized. The article is rich in content and analyzes and narrates it from a professional point of view. I hope you can get something after reading this article.

Method 1: ETAG mechanism

SAP CRM Fiori uses this mechanism.

Look at a specific example to understand. Suppose I select the Opportunity with an ID of 3456 with the user name Jerry, and then click the Edit button:

A read operation will be triggered and sent to the background:

The background responds to the read request and writes the corresponding value in the response header field ETAG.

The value of the ETAG at the end of the 26AE can be calculated logically by the application, and the last modification timestamp (Last Changed Timestamp) corresponding to the request node can be used directly, such as the following ABAP code:

You can also calculate a HASH value based on the complete contents of the data and return it to Fiori UI as ETAG:

Now I have made changes to the same Opportunity with another user and saved it successfully. Then go back to the editing window of the user Jerry, where Jerry has no idea that the Opportunity has been modified by another user. Jerry modifies the Name field of Opportunity, click the Save button.

Receive this prompt message.

You can observe from Chrome Development Tool that when Jerry clicks the save button, the header of the request sent to the background contains an If-Match field whose value is the ETAG field that the background returns to Jerry at the end of the 26AE when Jerry first clicks the edit button.

What happened behind the back, please? In the framework's method CHECK_BEFORE_MODIFICATION, the framework compares the incoming ETAG of the Fiori UI request with the latest ETAG:

CHECK_BEFORE_MODIFICATION calls the CHECK_ETAG_MATCH method again. If check fails, the current save operation will not be performed.

Method 2: lock implementation based on BOPF

This approach is used for Fiori applications of S/4HANA, such as Material application. This kind of Fiori application, the consumption of OData service is based on CDS view plus BOPF.

Open a Material and click Edit:

When you go to the ABAP backend and use the transaction code SM12, you can observe that the database table corresponding to Material is locked:

How did this happen?

In the S/4HANA background, use the transaction code BOBX to open the BO model I_PRODUCTWD. Expand the model, double-click EDIT, and you can see that the class implemented by this Edit is CL_I_DR_PRODUCTWD.

Double-click the class, and its method LOCK_ACTIVE_DOCUMENT is the handler that responds to the click of the edit button on the Fiori UI.

We set the breakpoint in this method, then click the edit button on the UI, and the breakpoint is triggered. From the call stack, you can clear the shackle code that observes how the program execution flow is delivered from the BOPF framework to the Material application after the edit button is clicked. This locking logic calls the traditional ABAP Enqueue function module.

This is how the two locking mechanisms in SAP Fiori shared by the editor are realized. If you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.