Small SAP Talk. Cache for OData Service

When it comes to optimizing business application performance, all means are good—especially when those means are standard. The vendor suggests activating the OData service caching mechanism to speed up the performance of applications where it's used.

The working principle is roughly as follows: if the data for the requested entity is cached for a specific user, it flows smoothly to the frontend (or wherever it’s needed). Otherwise, a request is generated (i.e., the corresponding method of the DPC_EXT class is called), triggering all the usual ABAP implications (checks, data selections, and other “joys”). In certain situations, using caching can be justified or even necessary (at the consultant's or developer's discretion).

See: Cache for OData Services

To activate the caching mechanism in an OData service, you need to specify the class /UI2/CL_GW_DP_CACHE as the data provider.

Also, activate the relevant parameter in the configuration table /UI2/CACHE_SUP by running transaction /UI2/CACHE.

Here is how the service works without the caching option enabled (the service is called on every application load):

And here’s how the service works with caching enabled (the service was called only once because the cache was empty during the initial SAPUI5 application load):

For more information about the "Small SAP Talk" series, refer to the following note:​

See: Small SAP Talk