Writes, ETags and concurrency

A write test has to prove more than "it saved". It has to prove the right entity changed in the right way, nothing else changed, and that two people changing the same document cannot silently overwrite each other. OData handles the last point with ETags: a version stamp the server gives you with each entity and checks when you write.

The write verbs

SAP services often allow deep inserts: one POST that creates a header with its items, for example a sales order with to_Item in API_SALES_ORDER_SRV. Many SAP APIs do not allow every verb on every entity: check the metadata annotations, and test that a forbidden verb is refused cleanly (often 405 or a business error), not silently ignored.

How ETags work

1. GET the entity. The ETag comes back in the ETag response header and in the body: __metadata.etag in V2 JSON, @odata.etag in V4.
2. Send the PATCH, PUT or DELETE with If-Match: <etag>, plus the CSRF token.
3. If nobody changed the entity since your read, the server applies the change and issues a new ETag.
4. If someone did, the server answers 412 Precondition Failed. Re-read, re-apply your change to the current data, and try again.
5. If you send no If-Match to a service that requires it, the server answers 428 Precondition Required.

Some clients send If-Match: * to make the error go away. An SAP KBA gives that as a workaround for one API, and it does make the call succeed, because * matches any version. It also switches off the protection. Use it only when overwriting is the documented intent, never as the default in a test suite.

Worked example: changing an address in CMQ

1. Fetch the CSRF token with a GET on the service root and keep the cookies.
2. GET the address of business partner 17100001 that Wei's recipe created, and store its ETag and current street value as the baseline.
3. PATCH the street with If-Match set to the stored ETag. Expect 204.
4. GET it again. Expect the new street, the other fields unchanged and a new ETag.
5. PATCH again with the old ETag. Expect 412, and the street from step 3 still in place.
6. Restore the baseline street with the current ETag. Expect 204, then read back to confirm.

Some operations are not plain create or update at all: releasing a document, posting, or setting a status. V2 services expose them as function imports, usually called with POST and parameters in the URL; V4 services expose actions, often bound to an entity. They need the CSRF token, and many also need the ETag. Test them like any write: known start state, expected status change, read-back and cleanup.

Designing concurrency tests

A useful habit: after every write, compare the full entity before and after, not just the field you changed. SAP backends derive values. Changing a ship-to address can redetermine a tax jurisdiction; changing a sales order quantity re-prices the item and can change the schedule lines and the credit status. The API call returned 204, but the business result is in those derived fields, and that is what Maria will notice in order-to-cash testing.