With the latest releases of SAP Cloud Platform Mobile Services SDK for iOS and SAP Mobile Platform SDK 3.1 now available to customers, Offline OData has new features and capabilities available in both SDKs. You can take advantage of these new features regardless of whether you are building native or hybrid mobile apps. In this blog, I’ll go through all the latest features from Offline OData now available.
If you are new to Offline OData, review an Introduction to Offline OData.
Here is a list of the latest features available in all SDKs
This feature in Offline OData provides support for repeatable requests at the Offline OData server level if the backend doesn’t support repeatable requests. Developers will be able to configure the Offline OData server so that it provides that support.
When this functionality is active and the client sends the same request (with the same request ID) twice, typically due to a failure to receive the response caused by a network interruption, the Offline OData server will have cached the response it received from the backend OData producer the first time, and will send that response back to the client instead of sending the request for a second time to the backend OData producer.
The Offline OData server can only go so far. If there is a communication failure between the Offline OData server and the backend OData producer, this feature will not be able to address that. It is preferable to have repeatable requests implemented in the backend OData producer, this feature is intended for those cases where the backend OData producer does not.
Developers are now able to provide information to Offline OData when the store opens that specifies whether the backend supports bind operations. If bind operations are supported, the feature behaves as it did previously. If the backend does not support bind operations, the following happens if the client issues a bind operation:
Previously, developers only had the ability to use a predefined list of static dynamic requests for Offline applications. This limits the types of applications developers can build.
Now, developers can add new defining requests dynamically. In the example below, which uses the ilodata diagnostic tool, we add a defining request for SalesOrderHeaders to a store which has already been opened. The data from the newly added entity set can now be downloaded and viewed.
If we also added a defining request for CustomerDetails, we can view the relationship data between Sales Orders and Customers.
Below is a view of the data retrieved. We look at one sales order and can see the customer details within that sales order.
This allows the application to, for example, download only the data it needs initially, then download data for subsequent screens in the background, reducing the startup time.
This feature enables developers to build in the power to cancel a data sync. The feature provides an API to allow developers to code the application to react to changing network conditions automatically or provide mobile app users the ability to cancel the data sync manually and retry later. When the application or mobile app user restarts the data sync, it resumes from where it left off rather than starting over.
One important note about canceling and resuming downloads. The partial download is not committed until it finishes. If there are 10,000 queries and it only downloads 5,000 and then the download is canceled, the end-user will not be able to see the 5,000 results until the download resumes and completes.
The function call to cancel the data upload is try provider.cancelUpload().
The function call is cancel the data download is try provider.cancelDownload()
Developers are given an API that allow the mobile application to automatically upload its Offline store database files to SAP Cloud Platform Mobile Services or SAP Mobile Platform without the end-user needing to know which files need to be uploaded or where to find them. These database files can be used to help diagnose issues.
An Offline store consists of two udb files: entity store database file and request queue database file. These files help diagnose issues with Offline OData, specifically it can help SAP diagnose customer issues.
Previously, customers would need to manually extract the files directly from the device, zip them and send them to SAP support. Now, app developers can call an API from the SDK that sends the files directly to SAP Mobile Platform server or SAP Cloud Platform mobile services. Once implemented in the application, the end-user can click a button and the files are automatically sent to the appropriate server as a zip file and are ready for download.
In the example and screenshots below, the developer creates a button
that calls the API. The user receives a popup stating that the offline store has been sent to the server.
There is a new subtab under Registrations and Users called Client Databases where the administrator can view which databases have been uploaded. Here the admin can download the files and send them to SAP support for diagnostics and debugging.
If the database is encrypted on the device, the end-user can still send the files to the server. Once the developer/admin has the files, they will need the key to be able to view the data in those files.
Developers can issue a query to get a list of which entities were modified/created during the last download. The query will simply list the entities and not distinguish created vs modified. The list of entities is available only for the last download and the query list is reset and updated for each data download.
A common use case for this feature is for applications like SAP Asset Manager, custom mobile development kit applications, or other custom application to have the ability to indicate to the end-user when something is new or updated in the application they are viewing. The application can maintain a list by running a query with this filter function.
The call for this feature is get [entitysets]?$filter=sap.upsertedlastdownload()
In the example below, a customer is added to the local client.
After the data sync download, run a query to get all content that has been added or modified on the server since the last download.
Now, in the example below, I run the filter function to see what has changed since the last download. This change could be from the local user or another user sharing the same server.
If you are new to Offline OData, review an Introduction to Offline OData.
Here is a list of the latest features available in all SDKs
- Repeatable Requests
- Support for OData producers that do not support bind operations
- Add defining requests dynamically
- Cancel, stop and resume data syncs
- Upload Offline Store to Server
Repeatable Requests
This feature in Offline OData provides support for repeatable requests at the Offline OData server level if the backend doesn’t support repeatable requests. Developers will be able to configure the Offline OData server so that it provides that support.
When this functionality is active and the client sends the same request (with the same request ID) twice, typically due to a failure to receive the response caused by a network interruption, the Offline OData server will have cached the response it received from the backend OData producer the first time, and will send that response back to the client instead of sending the request for a second time to the backend OData producer.
The Offline OData server can only go so far. If there is a communication failure between the Offline OData server and the backend OData producer, this feature will not be able to address that. It is preferable to have repeatable requests implemented in the backend OData producer, this feature is intended for those cases where the backend OData producer does not.
Support for OData producers that do not support bind operations
Developers are now able to provide information to Offline OData when the store opens that specifies whether the backend supports bind operations. If bind operations are supported, the feature behaves as it did previously. If the backend does not support bind operations, the following happens if the client issues a bind operation:
- If the bind operation is included in a dependent entity for a relationship that specifies a referential constraint, the bind operation will be replaced by setting the dependent properties directly.
- If the bind operation is included in a principal entity for a relationship that specifies a referential constraint, the request will be rejected with an error.
- If the bind operation is included in an entity for a relationship that does not specify a referential constraint, the relationship will be created locally but the bind will be omitted from the request that is sent to the OData backend.
Add Defining Requests Dynamically
Previously, developers only had the ability to use a predefined list of static dynamic requests for Offline applications. This limits the types of applications developers can build.
Now, developers can add new defining requests dynamically. In the example below, which uses the ilodata diagnostic tool, we add a defining request for SalesOrderHeaders to a store which has already been opened. The data from the newly added entity set can now be downloaded and viewed.
ILOData > add defining query
> Enter the defining query name: Sales
> Enter the defining query: SalesOrderHeaders
> Retrieve media streams (Y|N)?: n
The defining query was added successfully.
ILOData > download
Downloading… Sent 611 bytes. Received 2274 bytes.
Download complete.
If we also added a defining request for CustomerDetails, we can view the relationship data between Sales Orders and Customers.
ILOData > get SalesOrderHeaders?$expand=CustomerDetailsBelow is a view of the data retrieved. We look at one sales order and can see the customer details within that sales order.
{
“__metadata”: {
“uri”: “SalesOrderHeaders(‘50000000103’)”,
“type”: “ESPM.SalesOrderHeaders”
},
“SalesOrderId”: “50000000103”,
“CreatedAt”: “\/Date(1500076800000)\/”,
“CurrencyCode”: “EUR”,
“CustomerId”: “1100000323”,
“GrossAmount”: “95,081”,
“CustomerDetails”: {
“__metadata”: {
“uri”: “Customers(‘1100000323’)”,
“type”: “ESPM.Customers”
}
“CustomerId”: “1100000323”,
“City”: “Chuo”,
“Country”: “JP”,
“FirstName”: “Kazuo”,
“HouseNumber”: “3”,
“LastName”: “Koike”,
“UpdatedTimestamp”: “\/Date(1524160623921)\/”
},This allows the application to, for example, download only the data it needs initially, then download data for subsequent screens in the background, reducing the startup time.
Cancel Sync Process
This feature enables developers to build in the power to cancel a data sync. The feature provides an API to allow developers to code the application to react to changing network conditions automatically or provide mobile app users the ability to cancel the data sync manually and retry later. When the application or mobile app user restarts the data sync, it resumes from where it left off rather than starting over.
One important note about canceling and resuming downloads. The partial download is not committed until it finishes. If there are 10,000 queries and it only downloads 5,000 and then the download is canceled, the end-user will not be able to see the 5,000 results until the download resumes and completes.
The function call to cancel the data upload is try provider.cancelUpload().
The function call is cancel the data download is try provider.cancelDownload()
Upload Offline Store to Server
Developers are given an API that allow the mobile application to automatically upload its Offline store database files to SAP Cloud Platform Mobile Services or SAP Mobile Platform without the end-user needing to know which files need to be uploaded or where to find them. These database files can be used to help diagnose issues.
An Offline store consists of two udb files: entity store database file and request queue database file. These files help diagnose issues with Offline OData, specifically it can help SAP diagnose customer issues.
Previously, customers would need to manually extract the files directly from the device, zip them and send them to SAP support. Now, app developers can call an API from the SDK that sends the files directly to SAP Mobile Platform server or SAP Cloud Platform mobile services. Once implemented in the application, the end-user can click a button and the files are automatically sent to the appropriate server as a zip file and are ready for download.
In the example and screenshots below, the developer creates a button
that calls the API. The user receives a popup stating that the offline store has been sent to the server.There is a new subtab under Registrations and Users called Client Databases where the administrator can view which databases have been uploaded. Here the admin can download the files and send them to SAP support for diagnostics and debugging.
If the database is encrypted on the device, the end-user can still send the files to the server. Once the developer/admin has the files, they will need the key to be able to view the data in those files.
Query created or modified entities
Developers can issue a query to get a list of which entities were modified/created during the last download. The query will simply list the entities and not distinguish created vs modified. The list of entities is available only for the last download and the query list is reset and updated for each data download.
A common use case for this feature is for applications like SAP Asset Manager, custom mobile development kit applications, or other custom application to have the ability to indicate to the end-user when something is new or updated in the application they are viewing. The application can maintain a list by running a query with this filter function.
The call for this feature is get [entitysets]?$filter=sap.upsertedlastdownload()
In the example below, a customer is added to the local client.
ILOData > post Customers City=Redwood Country=US DateofBirth=1982-01-01T00:00:00 EmailAddress=sap@sap.com FirstName=Sue LastName=Berry
HTTP 201: Created
After the data sync download, run a query to get all content that has been added or modified on the server since the last download.
ILOData > upload
Uploading… Sent 2372 bytes. Received 659 bytes.
Upload complete.
ILOData > download
Downloading… Sent 752 bytes. Received 626 bytes.
Download complete.Now, in the example below, I run the filter function to see what has changed since the last download. This change could be from the local user or another user sharing the same server.
ILOData > get Customers?$filter=sap.upsertedlastdownload()
HTTP 200: OK
{
“d”: {
“results”: [
{
“__metadata”: {
“uri”: “Customers(‘2000000001’)”,
“type”: “ESPM.Customers”
},
“CustomerId”: “2000000001”,
“City”: “Redwood”,
“Country”: “US”,
“DateofBirth”: “\/Date(475286400000)\/”,
“EmailAddress”: “sap@sap.com”,
“FirstName”: “Sue”,
“HouseNumber”: null,
“LastName”: “Berry”,
“UpdatedTimestamp”: “\/Date(1524161547373)\/”
}
]
}
}
ILOData >- SAP Managed Tags:
9 Comments
