Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 
With the recent release of SAP Cloud Platform SDK for iOS and SAP Cloud Platform SDK for Android in January 2019, there are plenty of new Offline OData features that you can take advantage of.

If this is your first introduction to Offline OData, you may want to first review an overview of Offline OData.  For more detailed information on Offline OData, review this blog.

Here is a quickie overview.  Offline support enables client applications to access back-end data without needing a persistent connection to the back end.

You might want to run applications offline to:

  • Enable users to continue to use applications when there is intermittent network coverage, or the application is offline

  • Improve performance by only sending requests to SAP Cloud Platform mobile services on demand rather than for every transaction.


New Features

  • Print request queue and defining queries

  • Delete individual queries from Error Archive

  • Proxy classes for Error Archive and Event Log

  • Undo pending changes

  • Undo local creation

  • Transaction Builder


Print request queue and defining queries

In the latest release of the Offline OData feature, the ability to print the request queue and print defining queries have been added to ILOData for diagnostic purposes.  Previously, developers had to use SQL Anywhere to examine the content of the .udb files. Now, you can query ILOData and see what is available and better diagnose problems with the client.

In addition, use the SDKs for iOS and Android, developers can provide a method for end-users to upload the request queue and defining request information to the logs for further diagnostics.




Delete individual queries from Error Archive

Developers now have the ability to remove individual entries from the Error Archive.  This allows the user to effectively cancel requests which failed that they are unable or unwilling to fix. For requests that have dependent request, when a user deletes a request, all dependent requests (including both sent and failed, or unsent requests) will be deleted as well. If the dependent requests have error archive entries, those entries will also be deleted.


In the screenshot below using ILOData, we get a count of the requests in the error archive (5). We then delete the first item in the error archive and get a new count.




Now, we can check the dependents for a request in the error archive.




Proxy classes for error archive and event log

Developers building Offline applications using the SDK for iOS and SDK for Android can now interact with the Offline OData error archive and event log using proxy classes.

These proxy classes reduce the amount of coding needed to work with the error archive and event log in Offline OData.

The image below shows working with the error archive with and without proxy classes.

The image below shows working with the event log with and without proxy classes

Using the SDK tools, autocomplete is available to help you use the proxy classes as can be seen in the screenshots below.




Undo Pending Changes

For offline applications, pending changes means changes made locally that have not been uploaded to the server yet.  By undoing pending changes, the user will restore things to the original state as if those changes had never been made.

There are two major categories to undo pending changes

  • An existing entity downloaded from back end

    • you can make local changes and undo will restore its data to the original state.

  • For a new entity created locally

    • undo will remove it


When calling undo, relationships and requests will be adjusted.


In the screenshots below, we do a request for customers and order by ID.  We then update the name for customer 19.






Now, we undo the pending changes and can see that the name change has been reverted back to its original state.





In the screenshots below, we create a new customer, CustomerID: 20. Then we undo those changes and the customer is not created on the server.





A query for customers brings back only 19.  Customer 20 is no longer listed.


Below is how the code is used in SAP Cloud Platform SDK for iOS


Below is how the code is used in SPA Cloud Platform SDK for Android



Undo local creation

This feature was initially created for SAP Asset Manager and is now available to all customers.  Previously, if you did a create and then deleted the entity or object created, offline would still post both the create and then the delete.  Now, developers have the option to enable the delete option where if you create and delete prior to the upload to the server, Offline OData will cancel out the create and nothing is sent to the server.

Take a look at the example below. The undo local creation feature is not enabled. In this example, we create a customer and then delete customer locally.  We then upload our changes to the server.  Both the create and delete are sent to the server.

In the example below, the undo local creation feature is enabled. Here, we also create and delete a customer locally.  We then upload our changes to the server.  Nothing about this customer is uploaded to the server.


The image below is the same timestamp as the previous server tracking image because nothing was sent to the server.

Whether to enable this feature or not depends on how you want to manage and track data.  If you are looking to reduce the amount of data being sent to the server, then this feature helps.  However, when auditing, you don’t see everything the user is doing.  If you want to audit everything including local changes made by users – even when the changes cancel each other out, then you leave this feature disabled.


Transaction builder

The transaction builder is another feature that was previously created for SAP Asset Manager and is now available to all customers as an option.  The transaction builder enables developers to group operations together so that when changes are uploaded to the server, a business object is loaded as few times as possible.  As a developer, you can give operations a transaction ID.  When data is uploaded to the server, Offline OData analyzes the request queue and finds all the operations with the same transaction ID and groups them into as few changesets as possible.

A transaction ID can be

  • the same as an EntityValue

  • a static value

  • a string

Below is a screenshot from SWIFT showing how the transaction builder is used.

Note: similar to undo local creation, using this feature is optional and based on your business needs.  When auditing, you will not see operations in the same order that the user performed then since Offline has grouped operations to optimize and reduce the amount of time a business object is loaded.


All of these great features are available now.  You can use them today in the SDK for iOS and SDK for Android.  The Mobile Development Kit will also incorporate these features in future releases.