Skip to Content

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.


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.

You must be Logged on to comment or reply to a post.
  • Hi Riley,

    I just want to point out that all this is true for SAP HANA Cloud Platform mobile services as well, since it supports exactly the same OData Offline feature.

    Have Fun,


  • Hi Riley,

    do you know any limitations on SMP-cache? Are the OData calls also cached per user? What about query options like $filter and $select, are these also chached separately from GET_ENTITYSET calls?

    When an Delta-enabled OData service exists, is the cache for SMP disabled automatically or can I switch it in SMP-Admin console?



    • Steffan,

      Under typical conditions, all back-end requests are processed with the user's credentials -- the information received by the device is appropriate for the user requesting the data.

      There are a few special cases worth noting however: (1) You can override the credentials for a specific whitelisted connection by enabling "Anonymous Access" and supplying a common set of credentials to be used to access the back end connection. That's set in the "Back-End" tab of an Application definition at the SMP server. (2) I haven't played with it yet, but I believe you can mark an entity collection as "shared" -- this will cause the SMP server to treat the entity set as identical across all devices which allows the SMP server to optimize how it tracks and delivers the information to devices.  Naturally, you'd only use these two special cases when the data in question does not vary from one user to another.

      Regarding $select and $filter, those can be added to your entity queries both in the provisioning BOM and in individual requests at the device.  Where you'd used them would depend on what data you needed for the application.


  • Hi Riley,

    in model C hases are stored in the admin database.

    As an administrator would this have any impact on my backup & recovery strategy given the fact that this stores "business data" inside the database?

    Is the server able to restore these entries for delta calculation in case of data loss?

    • Hi Martin,

      Aside from primary keys and hashes, there is no business data stored at the SMP server.  That said, the "C" model does introduce a layer that links the data on the device to the back end(s).  You will want to have a recovery strategy in place at your SMP server -- that's one reason that we have enhanced the overall architecture to support putting a fully clustered database in place as your SMP Admin data store, by the way.

      I'll reconfirm it, but to my knowledge, I don't believe the server would ever use the client database to "recover" the state information at the server in the event of a server storage failure -- but that's an interesting question and I'll find the answer.

      Two final notes: it wasn't relevant to my blog post so I didn't mention it, but SMP 3.0 and HCPms both support server-side caching of completely sharable data collections ( -- that's the antithesis of models "A" or "B" in terms of avoiding a middle tier cache.  Still, it may prove useful in many situations.  Second,  I think you see that models "A" and "B" offer a superior architecture.  Certainly one that is easier to program and maintain.  Model "C" offers a way to bridge to those higher performance options while limiting the amount of reprogramming required in the overall architecture.


    • Hi Vinish,

      Why, yes, there is an article that I wrote in January describing Olingo 2.0's support for Delta Tokens (link) -- that approach would follow Model A.