Offline Delta and Syclo Framework
Greetings fellow SAP people, I come here with a few doubts regarding Syclo framework in order to use Delta Query and Tracking.
I'm using this guide: #3 - How To Implement Lightening Fast OData Services with Exchange Table
As far as my understanding goes, Syclo Framework helps implementing the tracking table and the delta object and then with the binding of elements.
I'm implementing the example as it is in the H2G but I'm also trying to understand the underlying concept that goes with it.
I've got the following questions and suppositions of what happends when the EFI is triggered.
- The Delta Table will keep track of every CUD operation that takes place in the APP side
- If the APP goes offline, once it goes back online, the Delta Tracking side will trigger the Delta Query to obtain the partial data using the Delta Table in order to just make updates based on the portion of the content created while it was offline.
As far as I understood, that's all on the SAP side. However I'm curious about the next:
I was told that, in order to perform the update for the Delta History, it was necesary to implement ETags. Is this true?
The Delta side is only responsible for updates of the information, the offline side of the businessu operations should be handled by the SMP side to send the request once the APP is back online, is this assumption true?
WIth no further ado, I thank you all for your comments and your interest, perhaps if these questions are common knowdledge then I apologize, and if you guys could point me to any useful documentation to handle this case, i'd be greatly thankful.
Jirong Wang replied
Syclo xchange table should comply to standard structure, which consists of two key fields: MOBILE_APP, OBJKEY. For oData delta token use case, MOBILE_APP is probably some constant value, OBJKEY is a 100 chars field, which can be a concatenated value. For composite key, which is your example, it should be the concatenation of all 5 key fields for your object.
It is possible to have non-key extension fields in an xchange table, so you can store the key field values in the extension fields to make it easier during delta calculation. For example, for material document, we have a composite key MBLNR + MJAHR. So the OBJKEY field should be the concatenation of MBLNR+MJAHR. Then you can add extension fields MBLNR, MJAHR in the xchange table, which contains the value of the original field. i.e, material document 49000177/2015, so OBJKEY should have the value 00490001772015. Extension field MBLNR should have value 0049000177, MJAHR should have value 2015.
Also like to point out, eTag is intended for conflict detection during CUD, delta token is for read query, these are different use cases.
Hope this helps.