Offline OData Version Support and Limitations
OData version 2 is supported for the offline OData feature, with several exceptions.
iOS, Android, and Windows supports a mix of OData 2.0 and 4.0 metadata annotations for defining additional characteristics or capabilities of a metadata element, such as a service, entity type, property, function, action, or parameter. For example, you can now define a valid range of values for a particular property. Windows supports 2.0. For details, see the Native OData API documentation for your platform, which is installed with the SDK or available on the help portal.
- There is no support for these OData concepts:
- Function imports.
- ETags when using the if-match/if-none-match headers when performing LOCAL reads.
- Modifying properties or complex type properties by addressing them in the URL.
- Metadata annotations are not populated in the Metadata object.
- The Offline OData feature has the following limitations:
- The maximum length (MaxLength) of Edm.String key properties is 10922 characters and MaxLength needs to be present in the metadata.
- The maximum length (MaxLength) of Edm.Binary key properties is 32768 bytes and MaxLength needs to be present in the metadata.
- The Android and Windows offline store does not support mutual authentication using X509Certificates loaded from the System KeyStore/KeyChain. It does support X509Certificates which are provided from a secure file store. The secure file store may be an SAP component, or 3rd party component, so long as the X509Certificate is supplied to the X509KeyManager when required.
- The navigation property used for the deep insert must refer to at most one entity.
- Media resources can not be read in a batch request.
- The Offline OData SDK for Windows does not support using client certificates to perform mutual authentication with the server.
- The SAP HANA Cloud Platform, mobile service for development and operations does not provide the functionality to use No Rewriting mode to support external back ends for offline usage.
- Requests to read the metadata must not include query options.
- Custom query options not passed to the backend:
- For modification requests, custom query options are not passed to the backend. However, if the app requires custom behavior, the developer can set custom headers and custom cookies per request that are sent to the backend.
- For defining requests, the custom query options are sent to the backend. In this case, the exact URL that the app gives or the associated delta link provided by the backend is sent. Currently, custom query options are not sent when retrieving the metadata or service document.
- Relationships not reflected on the client until after a refresh:
If the app uses only a referential constraint property to create/modify a relationship, the updated relationship is not reflected in the local store until the modification request is flushed and then refreshed. There are other means to make this work. For example, have the gateway backend ignore a bind operation (another operation in OData creates/modifies relationships that can be reflected locally), and locally use both a bind operation and update a referential constraint property. The relationship is reflected locally using the bind, but the relationship is created/modified in the backend using the referential constraint property. This work around is necessary in cases where the backend does not support bind operations or $links. If it supports either, updating the relationships using referential constraint properties is unnecessary.