Skip to Content

Offline Kapsel plugin -Flushed data persist in the offline store after refreshing store

We are working on a hybrid offline application of Plant Maintenance .We are able to create the Notification offline. When the user clicks a sync button, it executes the flush() and then upon success, then refresh() and Notification is creating in back end. But the local data objects which had been created still showing up in the list along with actual data from back end and remains as duplicate.

While creating a notification offline the Notification No will be null and upon Flush() the Notification No is getting created from SAP .Because of this there is a mismatch in the response from oData in both offline and online. Is there any way to avoid the mismatch in response?

Is it possible to delete these local records after they are flushed to the back end,So that the list will display only the refreshed data.

Add comment
10|10000 characters needed characters exceeded

  • Follow
  • Get RSS Feed

2 Answers

  • Apr 17 at 04:37 AM

    In the offline app, are you manually creating an ID as null on creation of the notification? You might need to not explicitly define a value for the primary key so that the framework can handle it. E.g., if primary key is "NotificationNo", don't set the value as null, just don't set it at all.

    Add comment
    10|10000 characters needed characters exceeded

  • Jul 03 at 05:44 PM

    The most likely explanation for this behavior is that the backend is failing to return the proper information in the POST response. When you issued the POST request locally, the Offline OData client created a temporary edit link to identify it with. When you did the flush, it send that POST request to the backend and expected to get back the real edit link. If that had happened correctly, it would be able to map the real edit link to the temporary edit link, would know that the two entities were the same, and would only have one of them, and would eventually remove the POST request, knowing that it had been completed successfully and the entity now existed. If the POST response is incorrect, that mapping can't be established, so you end up with two versions of the same entity, and the POST request never gets removed. To diagnose this, it would be helpful to see the response from that POST request.

    Add comment
    10|10000 characters needed characters exceeded