With the release of SAP Enterprise App Modeler and its ability to easily create offline mobile applications, I have received many questions about the recent new features in the Offline OData Service within SAP Cloud Platform mobile services. In this blog, I will describe the enhancements to the Offline OData Service over the last few SDK releases.
First, let me provide a quick overview of Offline OData.
Offline support enables client applications to access back-end data without needing a persistent connection to the back end.
You might want to run applications offline to:
To work offline, an application must initialize an offline store, which is a subset, chosen by the client application of the data in the back end. SAP Cloud Platform mobile service for development and operations provides an Offline OData Service that moves data between the back end and the client offline store.
In 2016, Offline OData added support for the new SAP Cloud Platform iOS SDK. All the new features I describe in this blog are available in both the SAP Cloud Platform iOS SDK and the SAP Mobile Platform SDK.
For the New Features, I have grouped them into large buckets – continuous improvement, performance, and usability.
SAP Cloud Platform SDK for iOS enables you to quickly develop your own native apps, with Swift, Apple’s modern programming language.
The SDK offers a fully Swift-based API to accelerate enterprise app development in Apple’s Xcode IDE. The Foundation layer provides key enterprise services for security, connectivity, app services and more.
To learn more, view the Developer home for SAP Cloud Platform SDK for iOS.
Offline OData now provides support for mobile applications based on the SAP Cloud Platform iOS SDK in addition to the previously supported SAP Mobile Platform SDK.
Application Developers can stop certain transactions that failed due to issues in the backend from merging. As an Application Developer, I can mark some requests as unmergeable so that the error archive merge algorithm won't merge requests and end up with invalid state workflows.
For example, the first request is ‘Create’, the second request is a non-mergeable ‘Update’. If the ‘Create’ fails, the error archive merge algorithm knows not to merge the ‘Create’ request with the ‘Update’ request.
As stated in the previous feature, there are some requests that users do not want merged due to possible errors in the backend, so this feature enables users to patch specific requests and re-sync the transactions without merging them.
For example, if the application is syncing multiple requests in a transaction and the first request is ‘Create’ which sets the status to ‘Open’. The second request is ‘Update’ which sets the status to ‘In Progress’ and the third request is ‘Update’ which sets the status to ‘Closed’. If there is an error with the initial Create request, the transaction cannot be patched and merged because the back end will not allow the issue to be created with a status of ‘Closed’. This must be completed as separate transactions.
To support this, the developer would have marked those ‘Update’ requests as being non-mergeable. What that means, however, is that if the ‘Create’ request fails on the backend, subsequent patch requests made on the end of the chain can’t be merged with the ‘Create’ request because of the intervening non-mergeable ‘Update’ requests. It is for this reason that a different approach for fixing requests with errors is needed, because simply adding patch requests the end of the list of requests will not work in this scenario. This new approach is to allow the patch request to target the ‘Create’ request directly, instead of targeting the entity.
So, Application Developers can now patch the first request, ‘Create’, directly. Once the ‘Create’ request syncs successfully, so will the following ‘Update’ requests with status values that the back end will accept.
Offline OData now provides the ability to query/filter a parent table based on the relationships to a child table. Here is an example – I have two collections, "Farms" and "Answers", with 1:M relationships between them. I should be able to filter for all farms who have answered X to question Y. This is like the SQL "exists" query syntax. To support this Offline OData provides access to lambda operators previously only found in OData v4 – ‘any’ and ‘all ’.
Application Developers now have the option to remove non-matching entities from the client after refreshing. Currently in Offline OData, if entities are created in my application that don’t match the defining request(s), they stay on the client and do not disappear after a refresh(). As an example, I may be a service worker who is only sent work orders currently assigned to me, but I am also capable of creating new work orders which will initially be unassigned and may end up being assigned to a different service worker. At the moment, work orders like this can be created on the client, but since they are not returned by the refresh(), they stay on the client forever. Now Application Developers have more control how to handle these situations. The Application Developer can have these types of entities disappear automatically. It is an option that can be configured.
This new feature in Offline OData provides the ability to delete links locally and in the backend with a single operation, even if my backend doesn't support $links. Specifically, this means that I expect to be able to set the dependent properties specified in a referential constraint to null, thereby deleting the relationship.
Over the last few SDK releases, Offline OData has focused on improving performance. Offline OData is now able to better leverage indexes that the customer specifies to a much greater extent than before.
During internal testing, we have regularly recorded performance improvements of up to 1000 times faster. If you are already using indexes for your data, you should be able to take advantage of this performance increase.
Usability is a big part of the feedback that we receive from external and internal customers. Our goal within Offline OData is to continuously listed to our customer feedback on usability and make changes to the product based on that feedback. The following new features increase Application Developer productivity.
End users can now get more feedback during the synchronization process. If the sync is running in the foreground, Offline OData provides a lot more information and feedback to the end user of the mobile application.
While some users choose to monitor the sync with extra feedback (stated previously), other users can now let the sync run in the background with little or no manual intervention.
Offline OData will enable the sync to run in the background to the extent that the OS allows it do so. Some OS will require manual intervention as some point and force the user to act, but Offline OData will resume the sync rather than restart it from the beginning.
Offline OData now provides the ability to turn on logging on the client of all requests (fetch and CRUD) made by the application for debugging purposes.
First, let me provide a quick overview of Offline OData.
Offline support enables client applications to access back-end data without needing a persistent connection to the back end.
You might want to run applications offline to:
- Enable users to continue to use applications when there is intermittent network coverage or the application is offline
- Improve performance by only sending requests to SAP Cloud Platform mobile services on demand rather than for every transaction.
To work offline, an application must initialize an offline store, which is a subset, chosen by the client application of the data in the back end. SAP Cloud Platform mobile service for development and operations provides an Offline OData Service that moves data between the back end and the client offline store.
In 2016, Offline OData added support for the new SAP Cloud Platform iOS SDK. All the new features I describe in this blog are available in both the SAP Cloud Platform iOS SDK and the SAP Mobile Platform SDK.
For the New Features, I have grouped them into large buckets – continuous improvement, performance, and usability.
Continuous Improvement
Support for SAP Cloud Platform iOS SDK
SAP Cloud Platform SDK for iOS enables you to quickly develop your own native apps, with Swift, Apple’s modern programming language.
The SDK offers a fully Swift-based API to accelerate enterprise app development in Apple’s Xcode IDE. The Foundation layer provides key enterprise services for security, connectivity, app services and more.
To learn more, view the Developer home for SAP Cloud Platform SDK for iOS.
Offline OData now provides support for mobile applications based on the SAP Cloud Platform iOS SDK in addition to the previously supported SAP Mobile Platform SDK.
Configure Handling of Merge Errors
Application Developers can stop certain transactions that failed due to issues in the backend from merging. As an Application Developer, I can mark some requests as unmergeable so that the error archive merge algorithm won't merge requests and end up with invalid state workflows.
For example, the first request is ‘Create’, the second request is a non-mergeable ‘Update’. If the ‘Create’ fails, the error archive merge algorithm knows not to merge the ‘Create’ request with the ‘Update’ request.
Ability to Patch Error Requests
As stated in the previous feature, there are some requests that users do not want merged due to possible errors in the backend, so this feature enables users to patch specific requests and re-sync the transactions without merging them.
For example, if the application is syncing multiple requests in a transaction and the first request is ‘Create’ which sets the status to ‘Open’. The second request is ‘Update’ which sets the status to ‘In Progress’ and the third request is ‘Update’ which sets the status to ‘Closed’. If there is an error with the initial Create request, the transaction cannot be patched and merged because the back end will not allow the issue to be created with a status of ‘Closed’. This must be completed as separate transactions.
To support this, the developer would have marked those ‘Update’ requests as being non-mergeable. What that means, however, is that if the ‘Create’ request fails on the backend, subsequent patch requests made on the end of the chain can’t be merged with the ‘Create’ request because of the intervening non-mergeable ‘Update’ requests. It is for this reason that a different approach for fixing requests with errors is needed, because simply adding patch requests the end of the list of requests will not work in this scenario. This new approach is to allow the patch request to target the ‘Create’ request directly, instead of targeting the entity.
So, Application Developers can now patch the first request, ‘Create’, directly. Once the ‘Create’ request syncs successfully, so will the following ‘Update’ requests with status values that the back end will accept.
Queries based on child relationships
Offline OData now provides the ability to query/filter a parent table based on the relationships to a child table. Here is an example – I have two collections, "Farms" and "Answers", with 1:M relationships between them. I should be able to filter for all farms who have answered X to question Y. This is like the SQL "exists" query syntax. To support this Offline OData provides access to lambda operators previously only found in OData v4 – ‘any’ and ‘all ’.
Ability to clean up non-matching entities on client
Application Developers now have the option to remove non-matching entities from the client after refreshing. Currently in Offline OData, if entities are created in my application that don’t match the defining request(s), they stay on the client and do not disappear after a refresh(). As an example, I may be a service worker who is only sent work orders currently assigned to me, but I am also capable of creating new work orders which will initially be unassigned and may end up being assigned to a different service worker. At the moment, work orders like this can be created on the client, but since they are not returned by the refresh(), they stay on the client forever. Now Application Developers have more control how to handle these situations. The Application Developer can have these types of entities disappear automatically. It is an option that can be configured.
Delete relationships based on referential constraints
This new feature in Offline OData provides the ability to delete links locally and in the backend with a single operation, even if my backend doesn't support $links. Specifically, this means that I expect to be able to set the dependent properties specified in a referential constraint to null, thereby deleting the relationship.
Enhanced Performance
Over the last few SDK releases, Offline OData has focused on improving performance. Offline OData is now able to better leverage indexes that the customer specifies to a much greater extent than before.
During internal testing, we have regularly recorded performance improvements of up to 1000 times faster. If you are already using indexes for your data, you should be able to take advantage of this performance increase.
Usability Enhancements
Usability is a big part of the feedback that we receive from external and internal customers. Our goal within Offline OData is to continuously listed to our customer feedback on usability and make changes to the product based on that feedback. The following new features increase Application Developer productivity.
More feedback during syncs
End users can now get more feedback during the synchronization process. If the sync is running in the foreground, Offline OData provides a lot more information and feedback to the end user of the mobile application.
Enhanced support for background sync
While some users choose to monitor the sync with extra feedback (stated previously), other users can now let the sync run in the background with little or no manual intervention.
Offline OData will enable the sync to run in the background to the extent that the OS allows it do so. Some OS will require manual intervention as some point and force the user to act, but Offline OData will resume the sync rather than restart it from the beginning.
Turn on logging on client for all requests
Offline OData now provides the ability to turn on logging on the client of all requests (fetch and CRUD) made by the application for debugging purposes.
- SAP Managed Tags:
6 Comments
