Skip to Content
avatar image
Former Member

Cascade SyncBos not work correctly

Hi,

we have a parent SyncBo called Y01_ORD_TR and other child SyncBos Y02_ANOM.

An user have a register in his mobile device, then we replicate, and this register is deleted from table merep_207.

Then the user have a modification of this register and sincronize it.

In the sincronization process the system return the next error message for Y01_ORD_TR :

Record not on device

Return code 1 (DOWNLOADER)

and the next message for Y02_ANOM:

Related SyncBO Y01_ORD_TR with Sync key 0000017057 is not present on the device.

Return code 1 (DOWNLOADER)

Then if I reprocess the record of the SyncBo Y01_ORD_TR it works correctly and modify it in R/3 without exist the record in MI (it was deleted from table merep_207 during the replication).

Can anybody tell mewhy is it happens???

Thanks, regards.

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

1 Answer

  • avatar image
    Former Member
    Aug 07, 2007 at 03:17 AM

    Hi Jose,

    For the error message :- MI is an offline solution and at any point of time backend is the boss and we have to follow the backend. If backend deleted a record, it will be removed from RDB and hence it will be delted from all devices from next sync. But the problem here is the record will be visible in the device til he syncs and he can modify the record with out knowing that its deleted from the backend..

    Now there are two business scenarios here..

    1. Once the data is deleted, no updates are allowed. If the data is actually deleted (not soft delete or archieved), then there is no chance to modify it.

    2. Another scenario requires the data modified from the device user to be updated so that there should not be any data loss. (otherwise modification from the device user will be lost).

    MI supports both these scenarios, based on the parameter settings. By default its the first scenario.

    If you enable REPROCESS_ON_NO_DATA parameter to 'X', it works as scenario 2. The updates are allowed, ofcourse subject to the backend validation in modify bapi wrapper.

    MI will call GetDetail bapi wrapper to fetch the data from the backend and then merge the device changes to it and then call modify bapi wrapper. If either of these bapis fail, then the data won't be updated in the backend. Obiously no conflict checking done here and the data will be overwritten in the backend (based on modify bapi implementation). Because of this, we want this to happen only during reprocessing (not during normal sync from user) which is ofcourse triggered by admin who is aware of the consequences.

    Hope its clear to you..

    Regards

    Ajith

    Add comment
    10|10000 characters needed characters exceeded