SAP Sourcing incorporates a cache that stores frequently accessed, infrequently changed objects in server memory to eliminate the overhead of retrieving them from the database. The cache provides a dramatic boost to SAP Sourcing performance.

The cache provides two basic models. The first, static caching, assumes that cached objects are almost never changed during system operation. An example of this is Directory Configurations. These are accessed relatively often (during each login) and rarely if ever change after initial setup. Once the cache is active, those types of objects that are defined as statically cached are generally all retrieved into server memory at startup. This slows the startup process somewhat, but the trade-off is considerably faster system operation after startup. Even statically cached objects are refreshed periodically as changes occur, but there is no guarantee that a user will immediately see the changes.

The second cache model is dynamic. It is used when the class of objects can change, but changes infrequently. When an application requests the object, the cache first verifies that its in-memory version is current, and retrieves a new version from the database if necessary. This is still more efficient than always retrieving the object from the database. Whether an object is cached, and the cache mode that is used, are configured by object class. These configuration settings are loaded automatically when the cache is enabled and are controlled by SAP technical personnel.

The application installs with the cache disabled by default. In general, this is appropriate for the early stages of system implementation. While the most basic master data objects are being defined, it can be misleading to have the cache enabled, as changes made to the master data objects may not immediately be visible. Later in the implementation process, the cache can be enabled to improve performance. The cache should be enabled before the system is deployed in production mode.

To enable the cache:

After you make this change, the cache is activated when the property is saved.

You can view cache statistics on the Cache page. The cache is partitioned by context.

This partitioning typically results in at least two cache contexts:

The current enterprise context is selected by default, changing the context by selecting another context from the drop-down list enables viewing of the other contexts active in the current system. The number of objects cached is displayed, along with the number of cache hits, misses, and discards by class. In addition, at the time of the last cache refresh, the page indicates whether a cache refresh is pending and displays a refresh button per class for manually refreshing the cache.

A cache hit represents finding an object in the cache, thereby saving database and object creation overhead. A cache miss reflects an object requested from the cache but not found and subsequently loaded into the cache from the database. A cache discard is a count of objects discarded from the cache to make room for a new object based on the cache high-water mark setting, which is used to limit the amount of memory consumed by cached objects. In general, it should not be necessary to click the Refresh link on the cache statistics display, as the refresh should be automatic. In certain special situations, you may be guided by Technical Support to use the Refresh link that updates the cache with the latest versions of that class of object. A high hit count indicates that caching that object is providing a strong performance benefit; a low hit count indicates that the usage of the object is light. If server memory is at a premium, an administrator could work with Technical Support to stop caching that class of objects or reduce the number of cached objects of that class to reduce memory usage by the cache.