Skip to Content

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):

ABC.png


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.

To report this post you need to login first.

14 Comments

You must be Logged on to comment or reply to a post.

  1. Martin Grasshoff

    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,

    Martin

    (0) 
          1. Martin Grasshoff

            Hi Frankie,

            well SAP Mobile Platform and HCP mobile services are both providing the described functionality for Model C.

            I’d like to add that this model works best on-premise, since uploading all data to HCPms and calculate the delta there adds much bandwidth and latency. Anyhow depending on your amount of data, this may not impact the overall solution.

            -Martin

            (0) 
  2. Steffen Froehlich

    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?

    Thanks,

    Steffen

    (0) 
    1. Riley Rainey Post author

      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.

      Riley

      (0) 
  3. Martin Kraemer

    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?

    (0) 
    1. Riley Rainey Post author

      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 (http://help.sap.com/saphelp_smp306sdk/helpdata/en/da/6c897199704e39b561c8f5b3ddfe98/content.htm) — 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.

      Riley

      (0) 
    1. Riley Rainey Post author

      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.

      Regards,

      Riley

      (0) 

Leave a Reply