OfflineODataProvider

OfflineODataProvider service options.

The version of the Offline OData library.

Initializes an OfflineODataProvider.

The name of the Offline OData store.

The name of the Offline OData store.

Whether or not the provider has metadata.

Metadata of the service. See CSDLDocument.

Logger of the provider. App developers can configure log level on the logger and control what level of information will be logged.

See SAPCommon.Logger.

Deletes the physical store from the file system. All instances of the OfflineODataProvider must be closed before the physical store can be deleted.

Deletes the physical store from the file system. This method will close the OfflineODataProvider before attempting to delete the physical store. Note that, this will also clear any information about the defining queries. Therefore, before opening again, any defining queries required for the initial download will need to be respecified.

Closes the OfflineODataProvider, freeing any resources. If a download or upload is active, it will be cancelled (it may be resumable after the provider is re-opened).

Checks whether or not the there are any pending requests stored in the request queue that have not yet been uploaded.

Checks whether or not there is a pending download.

Checks whether or not there is a pending upload.

Open the provider. After this call, the internal metadata data structure will be changed so any values cached in memory will need to be re-retrieved.

Upload local data to update the OData backend.

Download the data for all defining queries from the OData backend to update the local data. If the defining queries are delta enabled, only the changes will be downloaded.

Downloads the data for the specified subset of defining queries from the OData backend to update the local data. If the defining queries are delta enabled, only the changes will be downloaded.

Cancels all downloads and file downloads including those that are queued. This method will also cancel an initial download and file download if it is called while the OfflineODataProvider is opening for the first time.

Cancels the current upload.

Asynchronously sends Offine store to CPms server.

Add a defining query to the provider. There are three types of defining queries:

1) A defining query that identifies one or more entities where the automaticallyRetrievesStreams property is set to false. In this case, even if the defining query identifies media entities, the media streams will not be downloaded.

2) A defining query that identifies one or more entities, some of which may be media entities, and where the automaticallyRetrievesStreams property is set to true. In this case, the media streams will be downloaded as well for media entities.

3) A defining query that identifies a single media entity and the automaticallyRetrievesStreams property is set to true. The URL specified in this case MUST be the read link of the media entity, not the read link of the media stream. For example, if the media entity’s read link is Documents(101) and the media stream’s read link is Documents(101)/$value, the expected URL of the defining query is Documents(101).

Defining queries can be added before or after the OfflineODataProvider has been opened.

For performance reasons, it is not recommended (although it is supported) to use $expand in defining queries, unless your OData backend supports deltas with $expand in defining queries.

The Offline OData server component can take advantage of referential constraints to build relationship information instead of relying on $expand. For example, if the relationship (Association) between Customers and Orders has a referential constraint in the metadata document, the defining query https://sapcpms/odata/endpoint/Customers?$expand=Orders is equivalent to the pair of defining queries https://sapcpms/odata/endpoint/Customers and https://sapcpms/odata/endpoint/Orders; in both cases, all Customers, Orders, and relationship information for Customers and Orders are downloaded.

Remove a defining query.

Defining queries of type 1 and 2 can only be removed before the OfflineODataProvider is open for the first time.

Defining queries of type 3 can be removed before or after the OfflineODataProvider has been opened.

See definition in DataServiceProvider.

See definition in DataServiceProvider.

See definition in DataServiceProvider.

Note: key of the entity will be removed if it has been set. No key should be set when creating a media entity.

See definition in DataServiceProvider.

See definition in DataServiceProvider.

See definition in DataServiceProvider.

See definition in DataServiceProvider.

See definition in DataServiceProvider.

See definition in DataServiceProvider.

See definition in DataServiceProvider.

Query the ErrorArchive, the builtin Offline OData entity set which contains information about requests that failed during the last upload.

Query the EventLog, the builtin Offline OData entity set which contains information about Offline OData events such as upload and download.

See definition in DataServiceProvider.

See definition in DataServiceProvider.

See definition in DataServiceProvider.

See definition in DataServiceProvider.

See definition in DataServiceProvider.

Dump content (as a JSON object) of request queue of the offline store to log.

See SAPCommon.LogLevel.

Dump defining queries (as a JSON object) that have been added to the offline store to log.

See SAPCommon.LogLevel.

Offline OData does not support this method.

Pings the server to check that both the Offline Server component and the OData backend are reachable. This function will return successfully if both are reachable and will throw an error otherwise.

Undo pending local changes for a given entity. While you can make changes to existing entities and new entities locally, you can also undo the changes without uploading them. An existing entity will be restored to the original status as if no any changes had been made. A new entity will be removed as if the entity had never been created.

For example, say you have an existing entity customer101. You can either:

1. Patch customer101 several times. Undoing the changes will restore all property values.

2. Associate customer101 to some purchase orders. Undoing the changes will remove the relationships.

3. Delete customer101. Undoing this change will bring customer101 back.

As another example, say you have created a new entity customer102 locally. No matter what subsequent operations you apply to it, undoing the changes will remove customer102 as if this entity had never been created.

There are some more complex cases that Offline OData provides flexible support. For example, say you created a new entity order102 that deep inserted a new related entity customer102 in one request. There can be different sequences of performing undo:

1. Undo changes for customer102 first. In this case, customer102 will be removed, and order102 will remain (since you are not undoing changes for order102) but is not related to any customer (since customer102 has been removed). The original request for creating order102 and customer102 will be adjusted accordingly to produce the correct result. You can continue to undo changes for order102, which will remove it.

2. Undo changes for order102 first. In this case, order102 will be removed, and customer102 will remain (since you are not undoing changes for customer102) but is not related to any order (since order102 has been removed). The original request for creating order102 and customer102 will be adjusted accordingly to produce the correct result. You can continue to undo changes for customer102, which will remove it.

Undoing pending changes and undoing local creation (see OfflineODataParameters.enableUndoLocalCreation) are somewhat related but there are some key differences:

1. Undoing local creation is an optimization for the back end to not send a POST request if a new entity created locally is deleted before it is uploaded. Undoing pending changes is not intended to be an optimization but rather allows correcting mistakes or changing your mind about what you did.

2. Undoing local creation only applies to new entities created locally. Undoing pending changes also applies to existing entities that have been downloaded from back end.

3. For a new entity created locally, you can remove it by undoing pending changes for it without performing a deletion. However, you need to perform a deletion on the entity if you want to apply undoing local creation in order to remove it.

4. Undoing local creation takes effect (removing affected requests from request queue) when you perform an upload. Undoing pending changes takes effect (removing affected requests from request queue) when you call the method.

5. The undoing local creation algorithm respects cascading deletes while undo pending changes does not.

6. Because undoing local creation is an optimization, it will not remove requests for deleted entities which would cause entities that were downloaded from the server to be deleted. Undo pending changes on the other hand disregards whether the requests have a side affect on a server entity or not; it simply removes all references to the specified entity in the request queue.

See definition in DataServiceProvider.

See definition in DataServiceProvider.