Kapsel Offline OData - Flush works, but doesn't clear sap.islocal() flag

[Former Member]

I am working on a Cordova/SMP Kapsel based application using the OData Offline plugin.

The application is designed to be in "offline" mode all the time, except when the user clicks a sync button, which then executes the flush() and then upon success, then refresh(). 

All this is working, except I have noticed that after the flush/refresh, the local data objects which had been modified or created still shows up along with the actual data which has been pulled from the backend, so there appear to be duplicates.  We noticed the issue because it doesn't seem to occur for all entities.

We have been able to correct the issue for some entities by changing the return (the backend is SAP NW GW) to return the fully updated object in the return for the POST/CREATE request.  This seems to have the resolved the issue for some entities but not all.

The offline store correctly removes the object from the request queue (so it does not get processed any more) but it does not remove the flushed data like it is supposed to.  I assume there is some sort of mapping that gets done internally that allows it to figure out which record to remove after a successful flush, but can't seem to figure it out. 

Any ideas?

[Former Member · Accepted solution]

Hello Dan,

We have the same problem, do you have any work around about that?

Thank you!

[Former Member · Accepted solution]

It looks like the basic rule of thumb is that you can't modify the key fields during the transaction.  For example you can post data to the backend that has key fields either blank or populated.  During the transaction (CREATE/UPDATE/MERGE,etc) when the data is returned in the response, anything can be changed by the backend except populated key fields.  If the backend overwrites blank fields, that is fine.

In our case, we were trying to generate temporary offline key values, which get overwritten on the POST to the oData (SAP NWGW) server with the real backend generated unique key values.   It looks as though the better way to do this would be to create a separate non-key field which could store the temporary offline value (so the UI can use it), so that the key values don't change during the transaction.

Let me know if you need more clarification...

[Former Member · Accepted solution]

Thank you Dan for your very useful information and approach.

Our situation is a bit special, we want to flush (POST/PUT) new records and then have those records deleted from the local offline store (we also use temporary ids). We don´t know what response should the backend give to those requests in order to achieve this.

Here you have a post created by me :

[Former Member · Accepted solution]

The same logic applies, even in our case.  When you POST/PUT something to the OData server, the http response payload must contain the new or updated record (http://www.odata.org/getting-started/basic-tutorial/#create).   In this response payload, the backend can add key values that did not exist in the POST/PUT, but if it changes one (id# for example) the SMP Offline store does not clear.  I assume this is because the offline store odata provider is tracking these by the key values.

[Former Member · Accepted solution]

Thank you for your useful explanation.

I would like to ask you, what is your implementation to fix this POST problem? we have tried to make the POST request omitting the "ID", and also with a "fake" ID (and returning the new ID within the same object in both cases) and none of these worked.

PUT is working because IDs already exist in the database.

Thank you in advance.

[Former Member · Accepted solution]

To get it to clear, we had to make sure how we handled these 2 things:

- The request could only include key values in the POST if they were not going to change in the response payload.  If omitted or not included we had to include a blank value (null or undefined did not seem to work consistently).  This seemed to be true often for all values not just key values.  We had to include blank values to get it to clear.

- The response had to include the correctly populated key values which were updated by the post.

For example:

if request "key1"="123" and response "key1"="123", then OK

if request "key1"="" and response "key1"="123", then OK

if request "key1"=null or undefined and response "key1"="123" then NOT OK

if request "key1"="123" and response "key1"="124" then NOT OK

Try to play around with this and see if you can get it to clear properly.

[Former Member · Accepted solution]

Hello Dan,

At least, implementation had been successfully!! In the backend side had not implemented DELETE HTTP method and now they have a method created but without code, only with this implementation and your help was enough..

Thanks a lot!!

Óscar.

[Former Member · Accepted solution]

Glad to hear it!  Thanks.