Offline OData Conflicts and Errors

Offline OData errors fall in the following categories:

• Network errors

  Occur when communication with the server is interrupted during a request flush or a server refresh.

  If you have an Android application, a network error causes an exception; if you have an iOS application, a network error causes an NSError.

  You can generally resolve network errors by retrying the operation at a later time. However, if network errors occur while you are configuring your application, ensure that you have specified the correct application configuration settings.

• Contract violation errors

  Occur when the application attempts to perform an invalid operation, such as sending a malformed request or attempting to call API methods without first calling the openStore method.

  If you have an Android application, a contract violation error causes an exception; if you have an iOS application, a contract violation error causes an NSError.

• Business logic failures

  Occur if business logic at the OData Producer prevents an update that is allowed at the offline store. The error is recorded in the ErrorArchive, which is returned to the client device as an OData feed. The application can obtain the body of the original request and allow the user to re-submit the operation. The application receives notification of these errors through the Request Failure Listener (Android), or the Request Failure Delegate (iOS).

Conflicts are specific types of errors that arise when multiple clients simultaneously modify the same data in the back end. Your application should include a process to either avoid conflicts, or to log them when they arise.

OData services use Etags to identify conflicts. However, applications must implement their own conflict resolution logic.

An ETag is an identifier that is assigned to a specific version of an entity. When an entity is modified, a new ETag may be assigned.

To use ETags to detect conflicts in your application:

1. The application retrieves an entity, along with its ETag, from the offline store.

2. When an update request is made, the application sends the request, along with the original ETag, to the offline store.

3. If the ETag that is provided with the update request matches what is currently in the offline store, the update is performed locally and a new ETag is generated. The request and the ETag given back to the application by the offline store are added to the request queue. If the ETag does not match, an error is generated.

4. When a request queue flush is performed, the request and the ETag are sent to the OData Producer. If the ETag matches the ETag in the OData Producer, the update is performed and the updated entity plus a new ETag are retrieved by the application during the next refresh. If the ETag does not match, the error is put in the ErrorArchive and the application then determines how to proceed.