Locking mechanism in SAP Gateway.

[velsankar_sundar]

Hi ,

    I am new to SAP Gateway. I have a scenario where i will get a record from the backend custom table ex:Lets assume a student mark details. The user can change the students mark in the Ui5 screen and then on the click of submit. The record will be updated in the backend .

My question is since we are changing the data in the table, who can we handle the locking mechanism in the SAP Gateway when the record is in process.

Since i will read the record by using one RFC and update the record by using another RFC.

Inputs needed on this. Thanks in advance.

[former_member184867 · Accepted solution]

In REST based application concurrency is achieved using Optimistic Locking. This is approach is little different from Pessimistic Locking which we normally follow in database applications.

To achieve Optimistic Locking you need to pass a version information with the data so that the client always changed latest data. If the data being changed by client is not latest, then server will reject it.

In OData, you can achieve it using E-tag, Gateway also support Etags..

[velsankar_sundar · Accepted solution]

Hi Atanu,

              Do you have any example or reference document for the one you said.

Thanks.

[AshwinDutt · Accepted solution]

Hello Atanu,

It would be great if you can share example or any document which is describing how we can implement exactly optimistic locking with some valid use case.

Regards,

Ashwin

[former_member184867 · Accepted solution]

Excerpts from OData specification

3.1 Concurrency control and ETags

OData uses HTTP ETags for optimistic concurrency control. A few special considerations apply for ETags:

When retrieving an Entry the server returns an opaque ETag value 

When getting several Entries in a feed, the ETag value is included as metadata in the Entry itself. See [OData-Atom][OData-JSON]
When retrieving a single Entry, the ETag is returned as a response header called ETag as defined by HTTP. The Server can choose to also include it in the body as they would do for feeds for consistency.
During processing of POST, PUT and MERGE the server should compute a new ETag and return it in a response header, regardless of whether the response has a body with the actual Entry information.

When issuing a PUT, MERGE or DELETE request, clients need to indicate an ETag in the If-Match HTTP request header. 


If for a given client it is acceptable to overwrite any version of the Entry in the server, then the value “*” may be used instead.
If a given Entry has an ETag and a client attempts to modify or delete the Entry without an If-Match header servers should fail the request with a 412 response code.



OData servers will use weak ETags often as a way of indicating that two resources may be semantically equivalent but a particular request may see a different representation of it. Clients should be prepared to handle weak and strong ETags.

Some excerpt on Optimistic Locking from Internet

Optimistic locking is a technique for managing concurrent access to a resource. Pessimistic locking is the usual kind, and means you’re wrapping transactions and locks around your operations. It’s pessimistic, because you assume there will be contention for the resource while you work with it. In optimistic locking, you assume there won’t be contention, but the scheme will tell you if there is.
The mechanism in optimistic locking is simple. For each instance of a resource, whether its a row in a database or a file or whatever, I keep a version number. When I get that resource from the system, I also get the version number. Note that I don’t “check out” the resource, or lock it, or block anyone else from grabbing it. Then I modify the object. When I save it, I send back both the representation and the version number I got originally. The system is responsible for checking to make sure the version number is still the same. If it is, I win — the system saves my data. Then it adds one to the version number.
However, if someone else updates the instance of that resource in the meantime, the version will differ from the one I have. So when I go to save the it, the system can tell I have an out-of-date version of the object, report the error, and I’ll have to start over.
A collision is not the end of the world — usually it means notifying the user that particular resource was updated in the meantime, get the fresh data, and ask if they still want to make the change. Usually you want to reserve optimistic locking for resources where the chance of a collision is really low — just because it’s a hassle repeating the update cycle. So optimistic locking isn’t well suited for resources where there’s a lot of contention, or where starting over is very difficult.
Even with that caveat, in the REST world, optimistic locking can work really well because it’s low-overhead, and you don’t face the problem of distributed transactions when you access a variety of resources.

The HTTP headers which are useful for optimistic locking are spelled out in the HTTP 1.1 specification.
When you recieve a copy of a resource, you can write the server to provide:

ETag header :  the current value of the “entity tag”. You can supply a resource version here for optimistic locking.

When you send an HTTP request, you can include:

If-Match header : means only perform the operation if the entity tag value matches the resource’s current value. That is, only if the version hasn’t changed in the meantime.

In order to write your service to provide an optimistic locking version in the ETag header, you first have to track the version number of the resource. Usually, this means adding another column to the database to hold this value. Then the client/server interaction goes like this:

Client: GET the resource
Server: return the representation of the resource, and the ETag header with the current version number for optimistic locking.
Client: PUT or POST the modified resource, and the If-Match header with the same version number.
Server: Check the database to see if the resource they want to change has that version number.

If so, save the resource.
If not, return a 412 “Precondition Failed” response, letting the client know that it couldn’t perform the update, and the client will have to start over.


If possible, the check and save should be atomic. In the database world, you can accomplish that by taking advantage of the atomic nature of UPDATE:

UPDATE … WHERE id = the_id AND current_version = etag_value

If the row count is 0, it means that the identified resource is not at the right version.
Or you can always just wrap the thing in a transaction, and do a SELECT and UPDATE in the same transaction context, locking the record in the meantime. But note that the lock only lasts as long as the update, not as long as the entire GET / PUT / SELECT / UPDATE cycle.

How to implement in Gateway ?

1. While defining the entity you need to mention a property which will be the etag property for an entity. In my example I mention timestamp property is the etag for entity ZENTITY_EE.

Screenshot of Entity from Service Builder:

2. in GET_ENTITY you need to always populate timestamp property for the entity.

3. When you do a READ you get an ENTITY tag with an etag value which will look like

<entry m:etag="W/"'20140324104208'"" .......> [value mighytbe different for you]

Result Of Read :

4. For any update on that particular entity, along with payload, You need to pass a HTTP header called  "If-Match" , the header value will be   W/"'20140324104208'"  [which you got in step 3]

In UPDATE_ENTITY you need to update the TIMESTAMP field in DB with the current timestamp so that next time when someone reads the data get the latest version.

I have used timestamp as the field having version information, you can use any versioning mechanism.

This is all I have for now.. 

[AshwinDutt · Accepted solution]

Hello Atanu,

Thanks a lot for the information Will try and get back to you in case of any difficulties.

Regards,

Ashwin

[AshwinDutt · Accepted solution]

Hello Atanu,

If the ETag entry provided by the client in the If-Match header does not match, the server is failing with 412 "Precondition Failed" response code.

Working as expected Thanks a lot for the in puts.

Regards,

Ashwin

[velsankar_sundar]

Hi Atanu,

             One more small doubt , how could the backend program will get the etag timestamp, you have mentioned update with the current timestamp.  How do the if-match works.

Thanks,

S.Velsankar

[former_member184867]

Backend system will not need the etag value sent via If-Match. Control will come to the

DPC if IF-Match value is legal, server will do this validation for you. You just need to pass the current timestamp (or version information) when you save the data in database.  

[velsankar_sundar]

Thanks Atanu

[AshwinDutt]

Hello Velsankar,

Kinldy have a look at this discussion .

I am not sure if it will help you or not but you can just glance once

Regards,

Ashwin

[velsankar_sundar]

Thanks Ashwin i will look into the details