OData Offline and Delta Token Support: How your services choice can make SMP more scalable

It’s great to have been able to attend SAP TechEd/d-code last week in Las Vegas and I look forward to the upcoming Berlin event as well.  Now that SMP 3.0 SP04 is out, we have full support for large scale disconnected operation in Hybrid and Native SMP clients via OData Offline services.  A number of attendees visited us in the Platform booth to talk about disconnected operation in SMP.  Many of those folks had questions about the ins-and-outs of OData delta token support and why it might be a useful thing to have.

If you are interested in a good discussion about SMP Offline and OData services, I suggest you review Jeff Gebo’s lecture on the subject from Las Vegas.

As it turns out, the capabilities of the OData services layer you select will have an impact on the overall scalability of your application. That’s what I want to address with this article. I have been thinking on how to describe a simple model to help everyone understand the possible modes for connecting to OData web services. I’d like to propose a simple naming model to convey the various operational differences and performance impact of each, corresponding to “Good”, “Better”, and “Best”.

It goes like this (click to enlarge this drawing):

Model “C” – “Good” — An OData service is available, but it does not support delta token processing — this includes, I think, most current Integration Gateway use cases and most non-SAP web service providers.  In the “C” model, an update request from a mobile client requires a “GET” of the full entity collection from the back end; a key/hash service on the SMP server uses SMP’s Admin database to maintain a record of all rows present for each registered device.  Each refresh request from the application triggers a fresh “GET” of the provisioned entity collection, the SMP server will then compare the keys of each record and hashes of the new collection with the information stored in the Admin database.  This comparison is used to compute an optimized set of changed data that is then sent from the SMP Server to the client application on the device.

Model “B” – “Better” — A Delta-enabled OData service is available.  A “Delta-enabled” web service provides OData delta token support by executing the same full collection query from the back-end and then manually computing the delta collection set.  An example of this can be found in the JPA support model example in Apache Olingo 2.0.0:  the service executes a complete “select” on the source database and then uses the delta-token information to filter the selected data set down to a change set.  “B” improves on “C” by eliminating the need for the Key/Hash tracking mechanism at the SMP server.

Model “A” – “Best” — A Delta-optimized OData service is available. It is capable of leveraging capabilities of the back end system to perform optimized queries at each update request from the client.  Mode “A” improves on “B” by reducing the query load on the back-end system of record.  Extra processing at the web services layer and at the SMP server is avoided, too.

Note: “Delta-enabled” is a term we use commonly with SAP.  “Delta-optimized” is my own term used to distinguish a step up from plain-old-delta-enabling.  There might be a standard SAP term for that; if so, let me know.

SUMMARY

Model “C” gives you offline data support at the expense of added SMP Server processing required each time a client application requests a refresh.  The actual impact will depend on the frequency of updates, the number of registered applications, and the size of each collection being updated.  Since full collections will need to be supplied with each refresh from the back end, there may well be a noticeable performance impact on your back end system, as well.

Model “B” significantly reduces the processing burden on the SMP Server and eliminates the need to keep a record of keys and hashes at the server, too.   Model “A” is the best of all. Good for all the server layers involved and that it maximizes performance throughout.

It’s worth saying that all of these differences in the services are completely invisible to the Client’s Harmonized SDK layer used to program Disconnected operation. It’s also true that this processing is the same for both SMP and the newly announced HANA Cloud Platform Mobile Services (HCPms).  And those are both Good Things.