ETag Based Optimistic Concurrency in OData

An ETag is an opaque value the server attaches to a representation of an entity at the moment it is read, typically derived from a last-changed timestamp or an explicit version number field. When the client later sends an update or delete, it must include that value in an If-Match header. The server recomputes the current value and compares it; a mismatch means the entity changed between read and write, and the request is refused with a 412 status instead of silently overwriting someone else's change. The structural fact that causes most confusion: nothing about this is automatic just because the service is OData. In RAP the ETag is only active if a specific field on the CDS projection is explicitly marked as the ETag source and the behavior definition declares it as the master etag field. If that annotation is absent, the service has no concurrency protection at all, and it fails silently rather than with an error.

Apply ETag concurrency control where more than one user or process can plausibly update the same entity instance between another user's read and write, and where a lost update carries real cost: financial postings, approval-driven master data, shared planning records. It is the wrong tool for pure read services, for append-only child collections where updates to existing rows are rare or meaningless, and for entities already protected by an enqueue lock at the transaction layer, where adding ETag checks on top mostly generates confusing duplicate rejections. It is also unnecessary boilerplate on every single node of a business object just because the root has it; child nodes with their own independent lifecycle need their own consideration, not an automatic copy of the root's field.

ETag handling sits in the OData protocol layer, above the RAP behavior definition and the underlying CDS entity, and below the consuming UI or integration client. The value itself is sourced from a real field on the entity, commonly a last-changed timestamp maintained by the framework or an explicit version counter maintained by application logic. Fiori Elements and the standard SAPUI5 OData model handle the client side transparently: they cache the ETag from each GET and attach it automatically to the next PATCH or DELETE for that entity, so front-end developers rarely touch this directly. It replaces the older pattern of custom code that re-read a record before saving just to compare a timestamp manually. In managed RAP, once the annotation exists, the framework performs the comparison itself; in unmanaged RAP, the developer must implement the check inside the save sequence explicitly.

A sales order item CDS projection view carries an ETag annotation on its LastChangedAt field, and the behavior definition for the corresponding RAP business object names that field as the etag master field. Two users open the same item in a Fiori Elements object page. User A changes the delivery quantity and saves; the UI sends a PATCH with an If-Match header matching the ETag from the last GET, the update succeeds, and LastChangedAt advances. User B's screen still holds the ETag from before User A's change. User B edits an unrelated field, like a text note, and saves. The PATCH carries the stale If-Match value; RAP compares it against the current LastChangedAt, finds a mismatch, and returns 412 Precondition Failed. The UI surfaces a message telling User B the data has changed and to refresh before retrying. No custom code was written for any of this; it follows directly from the annotation on the CDS field and the behavior definition declaration.

In the RAP-based, clean core oriented model on S/4HANA, declaring an ETag field on entities exposed for update is standard practice, not an optional extra, and reviewers should expect it on any writable business object. Older Gateway services built with SEGW commonly required the developer to compute and compare the ETag manually inside custom ABAP, which is error-prone and is discouraged now in favor of the declarative CDS annotation plus behavior definition approach, where the framework performs the comparison consistently. No specific release threshold is implied here beyond general availability of RAP on S/4HANA; the point is the shift from manually coded checks to a declared, framework-enforced one.

The developer implements the CDS annotation and, in unmanaged scenarios, the comparison logic itself. The architect decides which field represents the meaningful version state for a given entity and whether concurrency control is warranted at all for that node. Functional consultants flag business processes where concurrent edits by different roles are common. Handover documentation should name the etag source field explicitly and describe expected client behavior on a 412 response.

Read rap-behaviour-definition-and-behaviour-implementation for where the etag master field is declared and how managed versus unmanaged handling diverges. Read rap-managed-versus-unmanaged-scenarios to understand which model performs the ETag comparison automatically. Read rap-draft-handling to see when the check actually fires relative to draft saves versus activation. Read odata-batch-requests-and-deep-inserts for how a mismatch on one entity inside a batch propagates to the rest of the request. Read debugging-an-odata-service-end-to-end for tracing an unexpected 412 back to its actual cause.