.The following parameters are used in the factory methods of the personalization service, for example getContainer and getPersonalizer.
The scope object contains parameters for controlling the behavior of objects of the personalization service. Note the following parameters:
validity
This parameter is used in container mode to control how long a container is valid. After the validity has expired, the data may still be stored on the front-end server, but it is no longer used. The validity parameter can have the following values:
Value |
Description |
---|---|
0 |
The data is persisted in the launchpad window, and is lost when the window is closed or when the launchpad is reloaded. |
<nn> |
Number of minutes the data is to be persisted on the front-end server, for example 30. |
infinity |
The data is persisted on the front-end server without any time restrictions. |
For validity > 0 (including infinity) a copy of the container is stored in the volatile memory of the launchpad window in the browser. Therefore, no roundtrip is necessary for reloading a container at a later point in time. Only if the launchpad itself is reloaded, the copy is lost and a roundtrip is necessary.
Parameters controlling the browser caching of personalization data
The following parameters control whether personalization data stored in a container is cached.
Property |
Value |
Default Value |
Description |
Access to Enum Constants |
---|---|---|---|---|
keyCategory |
FIXED_KEY | GENERATED_KEY |
GENERATED_KEY |
FIXED_KEY is a static hard-coded key which does not change. This value is required for caching to take place. GENERATED_KEY is for all other cases. |
constants.keyCategory.FIXED_KEY = "FIXED_KEY" constants.keyCategory.GENERATED_KEY = "GENERATED_KEY" |
writeFrequency |
HIGH | LOW |
HIGH |
Use LOW if the key is typically rarely updated, for example in explicit table personalization by end users. |
constants.writeFrequency.HIGH= "HIGH" constants.writeFrequency .LOW = "LOW" |
clientStorageAllowed |
true | false |
false |
Security-relevant data must not be stored on client side, for instance in local storage or in the HTTP browser cache. Applications should set this parameter to true only if the data is not critical from a security point of view. |
n/a |
Caching of personalization data reduces read calls to the front-end server. The cache buster uses one key for all cached containers. As a consequence, if one cached personalization container is changed, the cache for all personalization containers is invalidated.
The component object of the current app is stored together with the personalizaton data. It can be retrieved in a controller object as follows:
var oComponent = sap.ui.core.Component.getOwnerComponentFor(this.getView());
You can use the component ID as a query parameter for selective cleanup of personalization data.