Show TOC

Cache for OData ServicesLocate this document in the navigation structure

An OData service call can produce entity sets that are so large that it can take many seconds or even minutes to return them to the consumer. What is more, moving to the next page causes the data to be read from the database again before positioning to that page. Users do not want to wait a long time for the system to respond. In such a case it makes sense to use a cache mechanism for storing entity sets. We call this the cache for OData services.

The main benefits of the cache for OData services are as follows:

  • Performance improvements resulting from storing complete entity sets in a clustered database
  • Support for OData system query options $filter, $orderby, $skip and $top. These are used for filtering the data (selection criteria), sorting the result list and paging in the UI ($skip and $top). The cache for OData services improves applications by adding the capability of selecting and sorting the data as well as paging through the result in the UI.

OData services can be registered for using the cache in Customizing by using transaction /N/UI2/CACHE.

Create a new entry for your service and fill in the following fields:

  • Service name: The the name of your service which you have registered with transaction /IWBEP/REG_SERVICE

  • Data provider class: It must always be /UI2/CL_GW_DP_CACHE

  • Filtering: Select if the application called supports filtering. This has the effect that the filter criteria are stored in the cache.

  • Sorting: Select if the application called supports sorting. This has the effect that the sort criteria are stored in the cache.

  • Paging: Select if the application called supports paging. This has the effect that the page criteria are stored in the cache.

  • Cache active: Select to activate the cache for your service.

If you do no set filtering, the cache reads all data from the database and stores them in the cache. Filtering is then taken over by the cache.

If you set filtering, the cache selects the data from the database and stores them in the cache. Different selection criteria therefore result in different cache records. The same logic applies to sorting and paging.

Another feature is the retention of data in the cache. We differentiate between two cases:

  • Client-side cache deletion:

    The developer decides when to delete the cache by using the OData operation refreshCache.

  • Server-side cache deletion:

    An event in the back end initiates a cache deletion, for example, a change of a Web Dynpro CHIP configuration. It triggers the deletion of the CHIP catalog and it deletes the cache where the CHIPs are stored.