Federated Portal Caching
SAP NetWeaver Portal provides a dedicated caching service (FederatedPortalCache) for the federated portal scenario. Its primary purpose is to reduce network traffick to the producer by storing semantic objects on the consumer side for reuse.
The caching service is based on application interfaces of JCache (belonging to AS Java) and the Portal Runtime (PRT) cache.
The federated portal uses a dedicated region in the cache. Objects are cached separately for each user. The cache stores semantic objects, such as iViews, pages, layouts, and roles, which are transferred from producer to consumer. It includes personalized and administrator-based portal semantic objects, the raw data of portal semantic objects, their aliases, and more.
You specify the amount of time an object is kept in the cache. If a requested object is cached and is within its validity period, the consumer reuses the object instead performing a call through the network to the producer. Objects without a defined validity period inherit the validity period of the closest parent group that has a defined validity period.
Example of cached information in a federated portal:
· In remote role assignment mode, the role and its navigation structure are cached at runtime when a user on the consumer requests the role from the producer.
· In remote delta link mode, the producer caches remote delta link content that a content administrator has modified on the consumer to reduce the number of round trips at runtime between the producer and consumer portals.
· In remote delta link mode, the consumer caches shared areas within the producer's Portal Catalog structure, thereby improving the browsing experience of the remote Portal Catalog.
Caching in a Clustered Environment
The federated portal caching service provides a persistency option on top of the memory cache, thereby providing support for a clustered environment. The persistent cache acts as a repository for the memory cache of the nodes of the cluster. In a clustered environment, each server has its own cache, including memory cache, and all servers (nodes) share persistency in a single database. When a server retrieves updated objects they are immediately updated in the central database so that objects are up-to-date and available to all servers in the cluster without the need to go through the network again.
Persistency can also be used to make cached objects available after restarting the portal server and to provide the capacity for storing a large number of semantic objects (which standard memory would not typically be able to handle in a production environment). For example, when the portal retrieves a role at runtime through remote role assignment, consider the number of objects each role contains and multiply by that by the number of concurrent users served by each role.
Risks Involved Using Federated Portal Caching
Using caching in a federated portal environment involves certain risks; for example:
● The service parameters must be manually configured by portal administrators. Therefore, as with many other portal services, incorrect values may result in poor performance of the portal and outdated content viewed by end users at runtime.
● The use of a database for caching is a process that affects performance. It may slow down the retrieval time of a semantic object if for every object there is the need to retrieve it from the database. In addition, performance problems may result if, due to under-use of the cache, many transfers over the network are required.
Despite these risks, caching has overall performance benefits over non-cached data that needs to be retrieved over the network.
More Information
· Configuring the Federated Portal Cache
● Clearing and Synchronizing the Federated Portal Cache
● Optimizing Your Consumer Profile