need help::etag in Netweaver Gateway Odata services

[Former Member]

Hi Experts,

We are trying to implement etags in Netweaver Gateway Odata services.

Has anyone tried using etags , if so please let us know the steps to implement it.

I also need to know if any developer guides available for it.

Regards,

Nikhilaash BS

[former_member184867 · Accepted solution]

Excerpts from my response in thread

1. 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.

[AshwinDutt]

Hello Nikhil,

When you create your entity, you need to set one of our property as ETag.

When you fire the GET operation your response will contain the ETag value.

You need to pass this value inside the If-Match Header along with the payload when you are performing modifying operations.

ETag Handling - SAP NetWeaver Gateway Foundation (SAP_GWFND) - SAP Library

Please have a look here which will help you accomplishing the same ->

Regards,

Ashwin