Understanding Behaviour of Delta Tracking for Shared Data in Offline OData - SAP SDK for iOS

[JFULGENCIO]

Hi all,

We are working on a native iOS mobile app with ECC as the back end.In the config file for the app, we have a defining query for a master data and set this as both delta tracked (tracking is implemented in the back end) and shared data.

We noticed that with this set-up, the delta token sent in the service call sometimes belong to another user as confirmed in the delta query log tables. This seems to make sense because as shared data, the framework should be able to fetch updates for any user as long as the token is known.

The potential issue that we are facing now is that somewhere in CREATE_UPDATE_LOG_ENTRY_INT of class /IWBEP/CL_QUERY_RESULT_LOG, the delta query framework is checking if the current user/requestor is the owner of the token passed in the request. When this check is not satisfied, the delta query fails resulting to the app not getting the updated master data.

The check on delta token owner vs current user/requestor seems to be in conflict with the concept of shared data so I am wondering if any of you can help us better understand how this combination of parameters work along with the delta query framework in the back end. There are probably some reference material or note that we may miss so appreciate any help.

Thanks,

Jeff

[former_member190800]

david.brandow can you take a look at this?

[guo-pingzhang]

Hi Jeff,

I can only explain about how offline is doing regarding shared cache + backend (ECC) delta tracking

When client syncs with server, server will first check if the cache is timed out or not (controlled by refresh_timeout parameter, default 15mins), if not timed out, server will directly send data in cache to client.

If timed out, server will request backend with the delta token got from last response (at least 15mins ago depends on when last sync happens). So this delta token could be generated by another user who synced when cache timed out last time.
After getting the 'delta' from backend, server will compute the delta for this device. Because delta of backend is very possible to be different for delta needed for this device consider this device is not the one who triggered last cache refresh.

So if SSO mechanism of endpoint is not configured using technical user, then you will see this user is requesting backend with another user generated delta token.

When using shared cache, basically all users are sharing same set of data and who get the data from backend shouldn’t matter. So it is best we don’t give delta token an owner because anyone can query using any delta token and they should get same result.

The other way to workaround the delta token owner conflict is using a technical user in SSO mechanism of endpoint configuration. But that is most probably in-acceptable because then all other requests of this endpoint like create\update\delete an entity will use technical users too.

Thanks,
Guoping

[JFULGENCIO]

Thanks for the explanation Guoping.

We were expecting the same thing as you re: delta token for shared cached should not be linked to a particular user but the method in the back end has an explicit check on delta token owner ( as stored in the DB table) and sy-uname (essentially whoever is triggering the request).

We wanted to get some feedback from the community first before you consider raising a ticket for clarification.

Regards,

Jeff