HTTP is an inherently unreliable protocol. If connection or other issues prevent the client from receiving a response the client is left in doubt if the request was processed by the server. Idempotency guarantees delivery of synchronous messages exactly once. For idempotent requests (for example GET) the client can simply re-try the request. But for operations that change the server state (for example, creating a new item or invoking a side-effecting service operation such as “Reject Workflow”) re-issuing the request may result in an undesired state, as for example two items instead of one item are created.
Two optional request header attributes and one response header attribute facilitate the ability to retry requests without incurring unintended side-effects:
A 32 character GUID string representing a client-generated, globally unique for all time, identifier for the request.
The date and time at which the request was first created. If specified, the client directs that the request must be repeatable. The client can make the request multiple times with the same RequestID and RepeatabilityCreation header values and get back an appropriate response without the server executing the request multiple times.
Response Header: RepeatabilityResult
A string describing how the server has handled the requested repeatability. The following values are possible.
The request was accepted and the server guarantees that the server state reflects a single execution of the operation. The response returns the success or failure state of the operation as first executed by the server, and reflects either the current state of the system or the state as it existed when the request was first received.
The request was rejected because the server does not support repeatable execution of the request. The server returns 412 (Precondition Failed) without attempting to execute the request. The server state is the same as if the request had never been received.
The request was rejected because the combination of RepeatabilityCreation and RequestID was invalid or because the RepeatabilityCreation time was outside the range of values held by the server. The server returns 412 (Precondition Failed) without attempting to execute the request. The server state is the same as if the request had never been received.
The request header attributes are passed on to the SAP Business Suite backend system. In the backend system the idempotent utility (provided by the underlying SAP NetWeaver) handles the idempotent support generically. When the backend system receives a request it delegates the handling of the RepeatabilityCreation header to the idempotent utility class.
You configure idempotent services by scheduling a background job that ensures that request messages in SAP Gateway only occur once.
For this the SAP Gateway Implementation Guide (MG) has been enhanced. In transaction SPRO open the SAP Reference IMG and navigate to .
To define settings for idempotent services, proceed as follows:
Click on the Activity icon of the above mentioned IMG activity.
Enter the following default values:
For Period Hours in Document the typical value is 6.
For Period Hours in Document ID the typical value is 12.
A message displays confirming that the job has been scheduled.