Let's follow up this discussion at the Neptune Community
(this forum will be kept in read-only mode)
I am struggling with assuring, that my data reaches the SAP back end.
In a use case where connection-loss is a pretty common thing, this is a big deal for the app.
Currently I am thinking of two ways of handling that problem.
1. Maintaining a Z-Table where every ajax call data is stored and every time the app comes back online, this table needs to be screened and the data on my device will adjust accordingly.
2. Creating a structure similar to bapiret2 which is sent every time an ajax call is triggered. This way the call would send data and receive some sort of answer. If this structure is empty, i know something happend during the transmission.
Which way would be the most elegant one? Is there another way I haven't thought of?
At the client side, in the ajaxError event you will know that something went wrong: in the server logic / during communication.
What caused the event can be known by checking the contents of result and status parameters.
Try putting a debugger; statement inside your ajaxError event and check the contents of result and status. You will clearly see how it works.
In your scenario, the AjaxError will still be triggered.
I'm not sure, this solves my problem.
Using the Error event gives me the indication something went wrong at client side.
Is there any chance of checking, what caused this event?
Further more I am talking of a scenario where I send and receive bigger amounts of data. In my understand it would be possible there is just enough connection to send the data but not to send the response back.
In this case, I would have updated data at backend-side but the device would still receive an AjaxError because of the connection loss. Right?
When your SAP server does not answer with an expected result (i.e. communication loss during http-response), the AjaxError event at the UI5 control with your Ajax ID is triggered automatically and can be used to handle further frontend behaviour.
Our 'Design Best Practice' article should also be helpful, especially section 'Backend Calls'