Offline OData Refreshes and Updates

Offline OData applications use a local, offline store (on-device copy of the enterprise data) to ensure that data is always accessible, even when the mobile device is offline.

• Updating the offline store

  Applications can make changes to data when the mobile device is offline. Those changes are made to the local offline store, then stored in a request queue. Updates that are queued but have not yet been sent to the back end are reflected in the local offline store. The application developer must ensure that the offline store is periodically updated from the back end when the mobile device is online. This periodic update is called a refresh.

• Updating the back-end

  When the mobile device is online, a request queue flush can be performed. Flushing the request queue sends up changes that have been made to the offline store but have not yet been made to the back end. Once a request is successfully received by the back end, the request is deleted from the queue, the change is made to the back end, and a new version of that object is sent to the offline store the next time the application performs a refresh.

  Note Refreshes and request queue flushes are not performed automatically. The offline application must explicitly call the relevant Harmonized API methods to perform a refresh or request queue flush.

• Schema upgrades

  A schema upgrade of the offline store is performed whenever a new version of the OData service is provided.

  When a client refresh request is sent to the server, the request includes the OData metadata document that the client is expecting. The SAP Mobile Platform Server gets the metadata from the OData producer and compares it with what the client sent up. If the schemas do not match, then a new database is generated on the server and downloaded to the device.

  On the device, the new database replaces the old database. However, the request queue database is a separate database and nothing happens to it, so any unflushed requests can still be sent to the server. Consequently, after the new database is received, the client looks at the request queue and replays any of the outstanding requests that have not yet been sent to the server.

  Schema upgrades are expected to be additive, meaning you can alter the OData model by adding entities or properties, but not by removing entities or properties. Because of this, the operations in the request queue can be replayed successfully on the new schema. If a non-additive change to the schema is required, then a new OData end point should be used for the backend data, new defining requests should be used in the application, and a new application would need to be deployed.