Skip to content

Repeatable Requests

It is essential that business transactions (represented by client requests) are applied to the back end only once. If there are communication errors that prevent the client from knowing if a request was applied to the back end, the client must retry the request to prevent it from being lost. However, a retry could potentially apply the transaction to the back end twice.

Problematic Scenarios

There are three typical problematic scenarios:

  • Data loss A client sends a request, but a communications error prevents the OData service from receiving the request.

  • Duplicate execution

    1. A client sends a request.
    2. The request is received by the OData service and applied to a back-end database.
    3. A communication error prevents the client from receiving any response.
    4. The client retries the request.
    5. The request is received by the OData service and incorrectly applied a second time to the back-end database.
  • Client confusion

    1. A client sends a request.
    2. The request is received by the OData service and applied to a back-end database.
    3. A communication error prevents the client from receiving any response.
    4. The client retries the request.
    5. The request is received by the OData service and an error occurs because the request was already executed.
    6. The client is informed that there was an error when in fact there was not. The application or user may take the wrong follow-up action based on this error response. Additionally, the application could be left in an error state that blocks further operations.

None of these scenarios are acceptable in an application. Data loss means lost business and duplicate execution means customers could be billed twice for a service. Either case can result in financial and legal consequences.

It’s also important to note that communication errors are not rare events. Most clients use wireless networks where connectively loss is common. Mobile field workers encounter spotty network coverage. They may be at a remote site or in a factory with interference.

For full details see Repeatable Request from OASIS.

Repeatable Requests on the SAP Cloud Platform

Repeatable requests are supported by the SAP Cloud Platform (or for on-premise installations, through a SAP Cloud Connector).

To turn on the feature, specify the check_repeatable_requests parameter for the endpoint in application configuration file, for example:

1
2
3
[endpoint] 
name=myEndpoint 
check_repeatable_requests=Y

For more information on configuring repeatable requests, see Application Configuration File.

Back end OData services can also support repeatable requests (if implemented).

Repeatable Requests on the Client

This feature is supported by default, so nothing needs to be done in your offline application. The Offline OData component automatically adds repeatable request headers (RequestID and RepeatabilityCreation) to each modification request to ensure that the request is applied exactly once if it is received multiple times. The RequestID and RepeatabilityCreation headers are required by the server's repeatable requests implementation so that it can determine whether or not the request has already been applied. The Offline OData component also automatically retries requests on the next upload in case any error has happened in last upload.

If both the back end OData service and mobile service do not support repeatable requests, set the enableRepeatableRequests property of an OfflineODataParameters instance to false so that the repeatable request headers are not generated or sent.

Summary

Repeatable requests are an essential feature for any OData business application because:

  • Communication errors are not rare events.
  • Data loss or duplicate execution of a request are not acceptable.

Supporting repeatable requests in the middle layer (mobile services) compensates for the lack of repeatable requests support in the back end to handle communication errors between the client and mobile services. While it does not compensate for a communication breakdown between mobile services and the back end, in practice clients are typically on wireless networks and have a much greater likelihood of experiencing connectively loss. The mobile services to back end connection is typically a reliable hard-wired connection and is effective in handling typical errors.