Custom E-tag for optimistic lock in SAP Gateway Odata for Deep Update

This blog is about the locking concept in SAP Gateway odata for update deep method. As there are already many blogs on optimistic and pessimistic locking mechanism. And in Gateway Odata there are different ways to implement optimistic lock for concurrency control. below are the ways which I am trying to categorizing 

1.) Using Timestamp for E-tag

2.) Using Hash for E-tag

3.) Making Soft State(state-full) service(which I believe is not a good approach as it will lose Rest architecture constraint of stateless, and service will consume more resources to maintain state.

4) Durable locks using CDS-BOPF concept.

Note: For beginners, there are blogs/SAP help out there which explains the locking concept using lock objects in SAP.

Here comes the issue with the UI Apps which consumes odata service, which will not persist the locks as the session will be closed after every request(REST is stateless).

For example, If we call a OData request to lock the sales order, the request will go to the backend by opening a session, locks the sales order and when the request is completed, the session will be closed and all the locks will be removed.

To persist above we can either make a soft-state or use optimistic lock.

And if we are not using BOPF then E-tag is the best option for the locking mechanism. So for any update, patch, merge or delete operation it works fine. Challenge comes in Update deep entity as in Odata there is no such operation called update deep entity method.

So to overcome this problem many projects use create deep entity for both purposes Create deep entity and update deep entity(If the key is there then update operation).

Now coming back to E-tag based on timestamp which again has two methods to implement in DPC class with below methods in DPC_EXT class —

1.) If we are using function import then this method need to redefine and implement—

GET_IS_CONDI_IMPLE_FOR_ACTION Get flag if conditional handling is done for function import

2.) if we are not using function import but normal entity set then below method—

GET_IS_CONDITIONAL_IMPLEMENTED Get flag if conditional handling is done by provider App

if update deep entity is there, then those scenarios are not covered with standard gateway odata as for creating deep entity or for create entity there is no locking mechanism(which is obvious).

So to solve this issue I created the custom E-tag in creating deep entity itself.

Below are the steps involve how to create custom E-tag

Step 1

There should be timestamp in entity, and that should be mandatorily updated for each update operation so we can compare the timestamp for optimistic lock.

And make that property as etag,

So if simple entity is there which were created using structure then just put the property name of timestamp as below image —

if  cds view is used then in  MPC_EXT method define is redefined using below code snippet —

it will make changedatetime field as E-tag.

if service is implemented properly then for each read for this entity will bring Etag value as timestamp as below —

This need to read from front end and while doing update operation need to do a comparison .

Step 2

Need to implement logic in DPC_EXT class

If we are using function import then this method need to redefine and implement—

GET_IS_CONDI_IMPLE_FOR_ACTION Get flag if conditional handling is done for function import

2.) if we are not using function import but normal entity set then below method—

GET_IS_CONDITIONAL_IMPLEMENTED Get flag if conditional handling is done by provider App

Here GET_IS_CONDITIONAL_IMPLEMENTED need to redefine. Below is code snippet —

Above code will link etag to read service so that we can read from database etag and compare with Etag which is coming from payload.

Step 3

Put logic in Create_deep method to compare the custom tag value as below –

Step 4

From front end when doing update operation need to copy etag value to customtag in header  as below —

While doing update need to compare both timestamp.

Step 5

Below is code snippet to read custom etag from code and comparing with data base time tamp

Step 6

So instead of If-match value we are using custometag value and comparing if value match then the operation will be performed otherwise 428 error will come(precondition required) which means we are trying to update record which is already updated by someone else. so need to read again and try.Step 6.

So instead of If-match value we are using custometag value and comparing if value match then the operation will be performed otherwise 428 error will come(precondition required) which means we are trying to update record which is already updated by someone else. so need to read again and try.

By above way we can have an optimistic lock on create deep entity and based on key we can segregate when the update operation is happening then only we will use this custom E-tag.