Error Handling¶
Offline OData provides flexible mechanisms to help developers handle failed requests.
When a request fails against the back-end OData service during an upload operation, the request and any relevant details are stored in the ErrorArchive.
Offline OData Upload action will only be considered failed if there are communication errors during upload. The upload is treated as successfully completed if there aren't any communication errors, although some requests may fail due to the back end. See error categories for more information.
To determine if any requests have failed, you can examine the special ErrorArchive entity set.
You can use ClientAPI.read API or Target binding to access the ErrorArchive.
{
"Target": {
"Service": "/MyApp/Services/MyOData.service",
"EntitySet": "ErrorArchive"
}
}
clientAPI.read("/MyApp/Services/MyOData.service", "ErrorArchive", [], "").then(function(result) {
if (result && result.length > 0) {
for (let i = 0; i < result.length; i++) {
let entry = result.getItem(i);
// Do something with the entry....
}
}
});
Reverting Error State¶
By default, if you execute a DELETE request against any single entity in ErrorArchive using the DeleteEntity action, it reverts all error states and discards all data from ErrorArchive.
Note
You can only reference an entity in the ErrorArchive via its @odata.readLink property. Therefore, when you wish to delete an entity of the ErrorArchive, you must use the "ReadLink" property of the DeleteEntity action. It's not possible to use QueryOptions to reference an entity in the ErrorArchive.
In addition, the requests associated with entities in ErrorArchive are removed.
After the DELETE request, all entities or relationships in error state are reverted so that they appear as though the failed requests were never applied, and are no longer in error state. The ErrorArchive entity set is empty.
You can change this behavior to allow deleting individual entity in the error archive instead by setting EnableIndividualErrorArchiveDeletion to true in your OData service's store parameter. After enabling this setting, deleting an individual entity in the ErrorArchive will only delete that entity and its dependent entities. In addition, pending requests associated with the deleted entities in the ErrorArchive are also removed from the requests queue. All other non-related entities will not be removed.
For more details in handling offline OData error, see the following "Handling Errors and Conflicts" guide.
{
"_Type": "Action.Type.ODataService.DeleteEntity",
"Target": {
"Service": "/MyApp/Services/MyOData.service",
"EntitySet": "ErrorArchive",
"ReadLink": "{@odata.readLink}"
}
}
Finding Entities in Error State¶
Any entities or relationships in the offline store that were affected by a failed request are moved into error state, which indicates that the state of the entities or relationships in question may not be valid and should be fixed before proceeding.
Entities that are in error state are identified by presence of the @sap.inErrorState annotation.
There are two approaches to locate entities that are in error state.
The first approach is through filtering based on the error state setting in entities.
{
"Target": {
"Service": "/MyApp/Services/MyOData.service",
"EntitySet": "PurchaseOrders",
"QueryOptions": "$filter=sap.inerrorstate()"
}
}
clientAPI.read("/MyApp/Services/MyOData.service", "PurchaseOrders", [], '$filter=sap.inerrorstate()').then(function(result) {
if (result && result.length > 0) {
for (let i = 0; i < result.length; i++) {
let entry = result.getItem(i);
// Do something with the entry....
}
}
});
Fixing Requests in Error State¶
When an entity or relationship is in error state, the application can make additional modification requests to correct the data and fix the error before retrying upload.
See this topic for more details on how to fix requests in error state.