Untypical usage of ETag – dealing with network connection loss in SAPUI5 apps
ETag is a GateWay feature for collision detection. It is a very useful to solve the problem of multiple users updating on the same object using the optimistic lock. This blog gives a detailed implementation.
Our story is a bit different. It’s about how a single user is updating the same object multiple times and how ETag can detect this and make the UI & Gateway on the same page.
The Problem: wifi connection loss causes double picking in a sales order
In our recent project, we’re experiencing an issue that a customer SAPUI5 app is sending the same request to the server occasionally, while the device is having an unstable WIFI connection. By further analysis, we find out that the UI5 app is re-sending a same request to the server, while it experiences a network reset.
Here is what happened:
Our client happens to have a faulty device, which constantly has wifi connection loss and reconnection. (It’s is out of scope to analysis hardware issue on this blog, so I’ll focus on the software part only), Then things happened:
- The UI5 app( running on the faulty device) sends an OData request to pick a sales order item
- Gateway server receives the request and processed the picking request, then respond to UI
- At the same time, the device’s connection is lost, so UI5 didn’t receive the response
- UI5 automatically re-send the previous OData request when connection is re-established
- Gateway server receives the request again and processed the request again.
- Gateway server responds to UI5.
Now the problem is that UI5 app “thinks” its request has been delivered only once. Because it only gets 1 response. However, the order in the backend has been picked twice. This causes an over-picking, while the user intends only pick one.
The Solution: ETag to deal with collision detection
The solution to this is pretty standard, the ETag. Once UI sends the same request multiple times, Gateway will fail the second one,. Then the UI is forced to refresh to get the latest status from gateway. So the status on the UI and gateway is consistent.
Good to know this usage.
Thanks, Joseph. Another ex-colleague is experiencing a same issue too.
Identifying the real problem and test the solution is much harder than implement the solution itself. My tester colleague is even thinking of test on a tablet in a car to get a connection loss...