Using Correlation Cleanup Function in DOE

[Former Member]

In my scenario, we have a bi-directional DO with back-end adapter that supports CREATE, MODIFY, GETLIST, and GETDETAIL operations.  Upon CREATE, the data is saved on device with temporary order number.  After synchronization, the CREATE BAPI-Wrapper creates the real order in SAP and back-end push sends the new "real" order to DOE which sends it to device via a distribution model.  This is all good.

The issue is that the temporary order number data instance is still resident in mobile device.  As a result, we have two identical sets of data on device: (1) The temporary order, and (2) The real SAP order.

After consulting documentation, I have discovered that DOE provides the Correlation concept to correlate temporary order and real order, and then cleanup temporary data on device using the Correlation Cleanup Function (part of back-end adapter):

http://help.sap.com/saphelp_nwmobile71/helpdata/de/80/dbd65144d547fb96c3109441fa681b/frameset.htm

However, I cannot find any documentation on implementing this correlation cleanup scenario in DOE/ECC.  Can anyone please point to some examples?

[Former Member · Accepted solution]

Hi Roman,

         Yes, correlation concept will definitely help you here. Mainly you have to do two steps.

1. Maintain correlation fields at all child nodes of data object

2. Define your correlation key cleanup function module in your Backed Adapter

     For maintaining correlation fields, you need to go to child node of data object, click on the button 'Explicit key map' from the tool bar. You will get a screen to maintain correlation fields. You can select any field(or set of fields) where unique values are maintained at run time. You will have to do this step for all child nodes and root node can be exempted.

     The clean up function module is required only if you maintain a separate extra field for the purpose of correlation. As this field was not required in Backend, you can define a clean up function module(signature as one table parameter of type root node) and implement to clean up the value in Backend. But if you use any existing field as correlation field, this clean up function is not required.

Best Regards,

Manne.

[Former Member · Accepted solution]

Thank you Manne.  I now understand the correlation concept for child nodes of a data object.  The idea is that DOE will `recognize` the child nodes based on a specific correlation field.  The thing I still don't understand is how is the correlation defined for the root node?

For example, if the sales order is created on the client MaxDB with a temporary order ID, how can we define correlation on the root node to know that MaxDB temp sales order is correlated to the actual SAP sales order number?

Regards,

Roman

[Former Member · Accepted solution]

Hi Roman,

          Client doesn't have to do anything for this correlation concept and everything will be handled by server(DOE) in following way.

          Whenever sales order is created with temp Backend key, DOE calls 'CREATE' bapi with all the details. If this CREATE call is successful, this will return the header row(sales order header node) back to DOE. Since header node is always a single record, it is easy for DOE to map what is sent to backend (old key) and what is returned by backend (new key). Hence you don't need correlation at header level. But for child node, the record count can be more than 1 and it is difficult job for DOE to map what is sent to Backend(multiple child records with old keys) and what is returned(Multiple child records with new keys). This mapping is not possible as key itself is changed and hence we need correlation key to map child records.

          With this correlation concept, DOE replaces all the Backend keys to new (got generated in the Backend) in the incoming message and send it back as confirmation message. When this confirmation is applied on the client, it will overwrite the content in the client DB using SYNCKEY. Here the SYNCKEY of this confirmation message is same as the SYNCKEY of original message generated by client. After this confirmation is applied, client will have only new Backend keys and old ones doen't exist anymore.

          Hope this is clear.

Best Regards,

Manne.

[Former Member · Accepted solution]

Hi Manne,

Thanks for very helpful answers.  I got this concept to work with CREATE BAPI-Wrapper.  However, for MODIFY BAPI-Wrapper, when I change an existing order by adding new line items to it, will the DOE know to call GETDETAILS BAPI-Wrapper like it does after the CREATE call?  Or is the backend push responsible for providing the updated order instance (with new line item keys)?  This is the only part I'm still not clear about.

Thanks for your help!

Regards,

Roman

[Former Member · Accepted solution]

Hi Roman,

       Yes, even after MODIFY bapi  wrapper call, GETDETAIL is called by DOE, changes will be merged, applied in CDS (DOE caching) and sent to the client as part of confirmation message to the modify call. You don't have to wait for push message from Backend to client.

Best Regards,

Manne.