Page tree
Skip to end of metadata
Go to start of metadata

The delta process allows you to add specific data for a query to the cache. This means that you no longer have to read all data for the query from the database when the data basis changes. However, a complete rebuild of the cache is always necessary if metadata, master data , hierarchies, exchange rates and so on change. But a complete rebuild of the cache object also has to be performed for InfoProviders that are not suitable for the delta process when changes take place. InfoProviders are delta process enabled when a time stamp, a sequential number or - as with InfoCubes - the request shows which entries have been added.

Currently delta cache procedure is supported for DataStore objects (advanced) with the modeling property 'All Characteristics are Key, Reporting on Union of Inbound and Active Table'(also called cube-like) and InfoCubes for which the request ID makes it possible to tell which entries will be added.

SAP Online Documentation

Delta Caching

Invalidation of the OLAP cache

An OLAP cache object is always restricted to one specific Bex query. The query result must always be the same, regardless of whether it was created using the cache or not. Therefore, a cache object must always be invalidated or adjusted in case of modifications which have influence on it's calculation. There are different factors of influence:

  • Changes to the metadata (InfoProvider and InfoObjects)

  • Changes in the query definition

  • Changes to the data (InfoProvider, master data, hierarchies)

The system recognizes these changes using time stamps, however it also checks whether they affect the first part of processing, that is, whether they really influence the contents of the cache object (see also Note 688085). You can find detailed information on the behavior of the OLAP cache in relation to the data in the cache in SAP note 1138864.

Functioning of the Delta procedure

In the delta cache process every cache object contains the 'watermark' of the data (per part provider). This is archieved by the fact that the the system notes up to which REQUEST ID the data is read in the cache object. If further requests have been loaded, a query would use the cache object and only had to read the new requests from the data base.

The new requests are assigned to the cache object via "collect" and the cache object is written back afterwards. To read the requests missing for a cache object, 0REQUID must still be visible in the InfoCube. If the system automatically compresses an InfoCube when loading, the delta process is ineffective since the delta can no longer be accessed.

An InfoProvider can participate in the delta process if a class, which implements IF_RSD_DELTACACHE_SUPPORT, is specified for it. In addition to the normal Basis InfoCubes(class CL_RSD_DC_SUPPORT_INFOCUBE) and cube-like ADSOs, this is the case only for the virtual InfoCubes of SEM-BCS (CL_RSSEM_DC_SUPPORT_VP_BCS).

  • No labels