What does it do?
Errors in the offline world are important and need to be handled. This is important for the mobile app to be valuable and reliable for the users. There are various options to handle the errors after they occurred
- Building logic and UIs to handle the error case and enable users to fix the error locally on the device
- Send the error to the server let a back office team handle it.
- Try to build logic in the backend to fix errors automatically
Why is it needed?
There are multiple reasons errors can occur when an app is working with offline data. When the app successfully downloaded datasets the following errors can occur by trying to upload changes made offline.
Permissions
On business data it can happen that users are allowed to see data but are not allowed to change it. This could lead to a salesperson placing a order on a certain product which he is not allowed to sell.
Invalid values
Certain values changed offline could be rejected by the server during the sync. Examples here are:
- Salesman George enters Salesorder with a negative quantity which is not allowed.
- While Salesman George changed an order offline the backoffice also did changes to the same order. When Georges mobile device now sends the changes a conflict is detected by the backend.
These Errors need to be handled to avoid inconsistency of Data or even loss of business data. For our Salesman George the order and changes to the address are important as well as for the customer.
How does it work?
SAP OData Offline Architecture
The OData Offline consist of two stores. The data store and request store. If the Offline OData framework (part of all mobile SDKs from SAP) triggers a download the downloaded data will be stored in the data store. Now the data can be read via simple OData requests locally
.
Request store
The request store stores all request of type put, delete, post, patch. When the developer calls the upload function these requests will be sent to the backend in the order they where added to the queue. If the backend responds with an error, that request and all subsequent requests affecting to the same entity will stay in the queue. The SDK will continue to process all request from different entities until it has worked through the queue.
ErrorArchive
The Error archive contains the all the information about the request which was sent and the response form the server. The Error archive can be accessed by the developer via an OData API call against the "ErrorArchive" entity set, just as they would access any other entity set. The Response will look like this:
{
"__metadata": {
"uri": "ErrorArchive(2L)",
"type": "OfflineOData.Error"
},
"RequestID": "2",
"CustomTag": null,
"Domain": "ODataDomain",
"HTTPStatusCode": 500,
"Code": null,
"Message": "{\"error\":{\"code\":null,\"message\":{\"lang\":\"en\"\"value\":\"\\\"OData - JPA
"InnerError": null,
"RequestMethod": "MERGE",
"RequestURL": "\/SalesOrderItems(ItemNumber=10SalesOrderId='500000020')",
"RequestBody": "{\"Quantity\":\"-2\"}",
"AffectedEntity": {
"__deferred": {
"uri": "ErrorArchive(2L)/AffectedEntity"
}
}
}
Here are the steps how to produce an error offline and how to handle with our OData Offline SDK.
Story:
- Salesguy George sells to Emma the HT-9999.
- So George orders offline and by mistake types -2 as the Quantity. As a result the app puts the request into the request store.
- Once George is back where the app has connectivity the app sends the request from the request store to the server.
- The Server responds with a Error Code 500
- The app can get all the details from about the error and about the related item from the error archive
- George goes back to his list of salesOrder items and fixes it by changing the value from negative two which was his typo to positive two. As a result the app putsa new request into the request store.
- if the SDK now syncs the merged requests are send to the backend
- the backend responds with a 200 which clears the Error Archive
- result is that that George's order for Emma is placed correctly and Emma will get her delivery of the great HT9999 soon.
For more details on this work through our tutorials on this topic.
Summary
The best and most efficient error handling though is avoiding them, where possible.
In our example a small check in the UI when George is editing the SalesOrderItem and to not let him enter a negative value would fix the problem. This would also improve the User experience as George would get instance feedback on his action. Compared to before the solution required George to remember what the right quantity for Emma was, and this possibly hundred of sales later.
to stay tuned follow me
sami.lechner or at
twitter
more details and help @ SAP Mobile
