Metadata Cache
The SAP Gateway metadata component allows a full caching of the metadata which significantly increases the performance of a request which is sent through SAP Gateway.
Three different access scenarios are possible:
-
It is required to satisfy a request to the OData service document or the OData service metadata document.
-
The SAP Gateway runtime itself needs to access the metadata in order to process a request.
-
The IW_BEP software component needs to access the metadata in order to process a request.
SAP Gateway delivers functionality for all these scenarios by providing a three-level caching strategy.
Access Scenario 1 - Web Infrastructure Cache
In this scenario consumer requests exist to get the service document or the service metadata document. This means there are requests to resources which change only rarely in productive environments.
In order to use HTTP standard techniques SAP Gateway OData Channel sets the HTTP response header for service (metadata) documents according to the HTTP caching standards (Last-Modified). This parameter enables the web infrastructure components (for example, a web server and browser) to already satisfy requests out of their caches if the resources have already been requested before.
The application-specific model provider classes can influence this time stamp via implementing method GET_LAST_MODIFIED. The default implementation of this method derives the last modified time stamp based on the changed time stamp of the model provider class (MPC). The application can overwrite the logic if it does not fit.
Access Scenario 2 - SAP Gateway Metadata Cache
If the request cannot be satisfied via the Web infrastructure cache or if the SAP Gateway runtime itself needs to access the metadata, for example for a read of a feed it is checked whether the metadata of the current service is already present in the SAP Gateway metadata cache (if enabled).
If it is present the data is directly retrieved from the cache. If, on the other hand, it is not present the data is read from the respective data sources and passed back. An example of a data source is model provider class or the SAP Gateway metadata persistency, stored in the SAP Gateway metadata cache (to serve subsequent requests out of it).
In the SAP Gateway OData Channel programming paradigm the model provider class including the last modified time stamp is only called once when initially loading the metadata and storing it in the SAP Gateway metadata cache. If the model provider class is changed afterwards (for example, on account of coding changes or due to an import of a changed model provider class) the SAP Gateway metadata cache performs a handshake for every service document or service metadata document request and checks whether the cache contains most up-to-date metadata. If the metadata is outdated a cache refresh is triggered automatically.
Note that this handshake is not performed for business data requests. The cache handshake is only performed in the OData Channel programming model via IW_BEP APIs. If the LAST_MODIFIED implementation of the model provider always returns the latest timestamp the cache is refreshed in every service document and service metadata document call.
Access Scenario 3- IW_BEP Metadata Cache
The cache on the IW_BEP cannot be disabled and requires a proper implementation of model provider class method to retrieve the last modified timestamp.
If the model provider class is not changed but the underyling ABAP Dictionary binding, for example a definition of a field type in an ABAP structure, the changes are not reflected directly as there is no hook for ABAP Dictionary changes. In this case the metadata cache on the IW_BEP needs to be cleared manually.
The SAP Gateway metadata cache can be enabled and disabled and is per default deactivated in non-productive systems. We recommend the following cache settings:
-
Development systems
The SAP Gateway metadata cache should be disabled in order to always get the latest metadata (default setting).
OData Channel applications should set the latest timestamp in the GET_LAST_MODIFIED method of their model provider classes or stick to the default implementation.
-
Productive systems
The SAP Gateway metadata cache should always be enabled in order to increase the performance (default setting).
NoteYou need to clean-up the metadata cache after every import of a changed model provider class.
-
Performance test systems
The SAP Gateway metadata cache should always be enabled in order to increase the performance (default setting).
Performance tests should only be done after the SAP Gateway metadata cache has been fully initialized, that is, at least the service has to have been called once.
You can make settings for the SAP Gateway metadata cache in the SAP Customizing IMG (implementation guide) in transaction SPRO.
In the SAP Gateway hub system
open the SAP Reference IMG and navigate to 
SAP NetWeaver 
SAP Gateway OData Channel Administration Cache Settings Metadata Cache 
.
In the IW_BEP system open the SAP Reference IMG
and navigate to SAP NetWeaver SAP Gateway Service Enablement Backend OData Channel Support Utilities Clear Cache .
These activities are available:
-
On the SAP Gateway hub system
-
Activate or Deactivate Cache
This activity shows the current status of the cache and allows you to activates/deactivate the metadata cache.
-
Clear Cache
This activity allows you to fully clear the cache or to clear the cache for a range of models.
-
-
On the backend system:
Clear Cache
This activity allows you to fully clear the cache or to clear the cache for a range of models.