What is Offline OData Client SDK?
Offline capabilities using Delta Queries is an emerging concept in SAP and this blog provides an overview of Offline OData client SDK and key implementation aspects of Delta Token functionality.
As of releases 2.x.x., the SUP OData Client SDK was primarily for applications transacting online with live back-end data. However, there was an option provided to temporarily cache or persist small amounts of data for the applications to resume to work seamlessly if there exists any drop in connectivity over a short period of time. Accordingly, starting from SAP Mobile Platform (SMP 3.0), the existing offline capabilities are enhanced further, wherein the application that works online 99% of its running time can now work seamlessly like an offline/online application. The notable difference is that the application can perform changes to the data when there is no connectivity and later those changes can get propagated to the back-end with order respected.
Hence, to ensure that the client SDK performs like a typical offline enabled library, changes were executed not only to incorporate a persistent cache, but also have a request queue to store the change requests (HTTP(s), as OData SDK still deals with REST over HTTPs) in that order in which they were created, when the application was not connected to the desired server. This feature was not supported in SUP versions 2.x.x. The best part here is that all offline capabilities have been included as a part of the client SDK itself with no additional work needed from the server side.
Now, let’s take a typical business case. Let’s assume you have downloaded a large collection of products and we have cached this product list. How can we update it?
In order to take care of this aspect, the Delta Query functionality has been introduced starting from SAP Netweaver Gateway 2.0 SP07.
Overview of Delta Query Support
Delta query protocol defines a pull-model protocol for clients to get changes for a store. Clients can poll the store for changes periodically or as required or capable stores can provide change notifications to the client when changes are available to be pulled.
This delta query is particularly relevant for projects where performance is critical, wherein loading takes place continuously every time, when full payload is not acceptable, say for instance for projects where the client often polls to get the latest data and any updates. Hence, for client and server performance, it can be very helpful to always display the current state in a poll-interaction, but with the lowest overhead on both client and server.
Implementation of Delta Queries & Delta Token functionality
An OData service can implement delta queries. This implies for each GET request to the OData service, the service will responds with the data, along with an additional delta link. This delta link is a combination of an identifier and a timestamp. Next time, whenever the device wants to request data, it will send a GET request including the delta link, wherein the ODataService will respond to only those objects that were new, updated or deleted (according to the timestamp inside the delta link). This way, you will drastically save time for getting the data and also on the device for parsing the data. The response can be merged to the existing data by using the cache object. However, you need to note that the developer of the OData service has to implement this delta query functionality, either by using Delta Exchange Tables (retrieved from the Syclo framework) or by its own (for example, by calling a BAPI, which gets the timestamp as input and returns the corresponding items).
Implementation of Delta Token functionality
OData exposes collection of records as EntitySets. These EntitySets supports varied options like sorting, filtering or paging to reduce the amount of the data that is sent across the wire.
In this context, paging can be considered as a very robust option to minimize the size of the payload and enhance performance. In order to use paging on client side, the OData request need to specify the $skip and $top tokens. If you work with server-driven paging, you need to use the $skiptoken.
However, some applications prefer to use client side caching, instead of paying. In such scenarios, SAP NetWeaver Gateway provides Delta Tokens that enables you to reduce resource consumption on the server and wire, when the same request is sent multiple times from the same client. The OData Delta Token lets clients to use caching when retrieving entity sets.
Accordingly, the client gets only the modified records, once all the initial records are retrieved. Hence, the initial request will return all records and a Delta Token. The consequent request consisting of the exact query options sends the Delta Token from the initial request. The response will then consist only the modified records. However, if no records have been modified, since the initial request, then the response will not contain any records.
There are two main approaches to implement Delta Token functionality such as:
1. Syclo Exchange Framework based approach: It calculates deltas at modification time, wherein the ABAP system tracks relevant changes, as they occur. At request time, the deltas are already prepared, making them available. Though this approach needs higher development efforts, however, it’s more scalable and ensures an optimized overall performance.
2. Delta determination at request time approach: In this type of approach, the system compares old and new states to check which records have been modified/deleted. Here, though the implementation effort is small, it however does not optimize the backend performance. This implies, if you have more records in the full collection, the response time of the request tends to get longer.
However, with both the approaches, the payload of the response is minimized, though the first approach seems to be more prudent, as it ensures optimization of the backend performance.
For more information on Innovapptive's Portfolio of SAP Certified Mobile Applications, please click on the link. Alternatively, if you would like to discuss with an Innovapptive solution expert, you can reach out to us by emailing us at sales@innovapptive.com or you can reach a sales representative at (713) 275-1804.
