on 2015 Sep 21 4:32 AM
Greetings fellow SAP people, I come here with a few doubts regarding Syclo framework in order to use Delta Query and Tracking.
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.
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.
Best regards.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thank you for your comment, I'll take a look on the link.
We will use then the deltatoken and Delta Query to supply the info for the modified items.
In that note, I'm curious, the objKey is to be used to store the key fields for the search for the modified registers in their respective tables, my question is, say i have 5 fields that are the key, should i concantenate them all in that field and then in the Delta Query method, separate them accordingly or should be better to create these fields separatedly in the exchange table?
Cheers
Hi Emmanuel,
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.
Jirong Wang
User | Count |
---|---|
83 | |
12 | |
10 | |
10 | |
10 | |
9 | |
8 | |
7 | |
5 | |
5 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.