cancel
Showing results for 
Search instead for 
Did you mean: 

Best approach to build an offline store for collections with $expand and delta queries?

Former Member
0 Kudos

Hello dear SMP 3.x Experts. I have a tricky question, about combining of two of the greatest features from SMP, offline and delta queries. I hope some of you guys can help me to solve the scenario that I'll describe below:

I am in the implementation of a project using SAP Gateway 2.0 SP 12, SMP server 3.0 SP 09, and SMP SDK 3.0 SP 10.

We have a business requirement to work in a mobile device with a main list of clients (master) belonging to the user of the application or salesperson, and when the user click one item, a form is shown for to edit data about the client (detail) including inserts for some related business objects like addresses and telephones (detail-detail). All that must work offline.

We tried to cover the requirement configuring the Kapsel local store like below:

"definingRequests" : {

                "Customers" : "/CustomerSet?$filter=ownerSalesPersonId eq '" + salespersonId + "'"+"&$expand=AddressSet,PhoneSet"

              }


The configuration works ok, resolving the requests online and offline. But we have an issue related to delta queries, and that is because when we made a GET request to SAP Gateway using $expand (in the refresh process), the GET_ENTITY_SET_EXPAND is executed, but not the GET_ENTITY_SET_DELTA. Therefore, the ABAP developers from Gateway have not chance to do the corresponding delta tracking.

We try to take advantage of the constraints defined between the entities Customer and Address, and not use $expand in the local store definition. However, this force us to download all the universe of Addresses from the backend, or to add the salesperson ID to the Address collection. We think this is not the optimal design. The alternative definition is shown below:


"definingRequests" : {

                "Customers" : "/CustomerSet?$filter=ownerSalesPersonId eq '" + salespersonId + "'",

                "Addresses" : "/AddressSet",

                "Telephones" : "/PhoneSet"

              }


So, the question is. What is the recommended local store definition, if we need a complex set of collections with a main collection filtered by some property, and some other dependent collections related using constraints in the OData Model, and when we also need to use delta queries for the main collection. A draft of the OData modeling is shown below:


Accepted Solutions (1)

Accepted Solutions (1)

matt_borges
Explorer
0 Kudos

As far as I am aware (although admittedly I'm not an SAP Gateway expert), SAP Gateway does not support deltas with $expands with OData version 2.

Regardless of whether or SAP Gateway supports it, Offline OData does not support OData server returned delta responses when the defining request contains an $expand.  So you have 4 options (in no particular order):

1) Use SMP computed deltas and keep the $expand.  By default if the OData backend does not return a delta token, the SMP server will compute the deltas for the client (and it can do so even when a $expand is used).  What this means is that between the SMP client and the SMP server a delta response is sent, however, between the SMP server and the OData server a full download is done.

2) Separate the defining requests (as you showed at the end of your question) and use sharing for the Addresses.  If you use sharing (configurable in an application configuration INI file), all the devices will have all the Addresses, but the SMP server will cache the data.  The result is that only one user will take the hit for downloading the Addresses to the SMP server.

3) Add the salesperson ID to your addresses collection (as you suggested).

4) The OData V2 standard allows a navigation property to be used in a $filter with some restrictions.  With your OData model you can use these as your defining requests (assuming your OData server supports this):

/CustomerSet?$filter=ownerSalesPersonId eq 'salespersonId'

/AddressSet?$filter=CustomerSet/ownerSalesPersonId eq 'salespersonId'

/PhoneSet?$filter=CustomerSet/ownerSalesPersonId eq 'salespersonId'


These defining requests assume the navigation property from AddressSet to CustomerSet and PhoneSet to CustomerSet is "CustomerSet".


Hope this helps,

Matt

Former Member
0 Kudos

Thanks a lot for your answer Matt,

We are looking more about the option 4. We make a test but get an error complaining because “the property CustomerSet does not exist”. Then we tried to add a second navigation property from Phone to Customer, but it give us an error on the Gateway complaining because “PhoneSet is not the main Collection”. It seems than we are missing some configuration. Could you share to us some links or documentation about details about the steps to execute for the options 1 and 4 that you mention above?


Thanks in advance

Jeff-Gebo
Advisor
Advisor
0 Kudos

Hi Edgar,

can you execute those queries in a REST client? Or is that where you are seeing those errors?

Thanks,
Jeff

Former Member
0 Kudos

Hi Jeff, Thanks for look at the discussion,

I executed the queries inside the offline store configuration of a hybrid application based in an example from Kapsel developer guide (Sample that Defines Relationships using $expand). However, the same errors are throwed if we execute the queries direct on the URL of a web browser.

Did you know some link or material where addressed the issue about management and filter in offline mode with complex related OData collections?

Thanks in advance

matt_borges
Explorer
0 Kudos

For option 1 you really don't need to do anything.  It sounds like your OData server can't return a delta link since your defining request contains an expand.  In that case, the SMP server is going to automatically compute deltas unless you explicitly told it not to (in an application config INI file).

For option 4 it sounds like the issues you are having are gateway issues and not offline OData issues.  As I said, I'm not a gateway expert so I can't really provide answers for you.  Jeff Gebo is trying to find a gateway expert that may be able to help you out.

Matt

Former Member
0 Kudos

Excellent Matt, temporarily we opted for option 1.

We will remain on the lookout for new information to achieve the most optimal solution.

Best regards, Edgar.

Answers (0)