Persisting Personalization Data
The personalization service allows you to store user-specific settings for your applications, like the column sequence of a table, or query parameters for data selection.
The functionality is implemented as a shell service and has two platform-specific adapters:
-
In the local development scenario, you can use the sandbox shell, which stores personalization data in the browser's local storage.
-
In a productive environment, like the ABAP shell or the HANA Cloud Platform, personalization data is stored on a front-end server.
"Personalization" in this context does not mean handling tiles on the user's home page. For this purpose the bookmark service is available. For more information, see Creating, Updating, and Deleting Tiles on the Home Page.
Do not use the personalization service to persist business data. As business data is typically related to a specific application, we recommend you persist it on the respective back-end system where the application data resides, using a specific OData service.
The personalization service can be used in either of the following modes:
-
Direct mode
-
Container mode
The following table lists criteria for when to use which mode:
|
Criteria |
Direct Mode |
Container Mode |
|---|---|---|
|
Personalization for ... |
One entity, for example settings for one table |
Several entities, for example settings for a table and query parameters for the content of this table |
|
Complexity |
Easy, one step |
Separate load and save operations |
|
Variants Available? |
No |
Yes |
You can use direct mode if you want to store one entity only. Personalization data should be one simple or structured value.
In this mode a personalizer object is the only object used. The personalization service has a factory method for it. Each personalizer is dealing with exactly one item. The value of an item is stored as a JSON object.
Use this mode if you want to store personalization data for more than one entity, if you want to store more than one value for an entity (several variants), or if you want to control the saving and loading of the data.
A container can contain several items. We recommend you assign items directly to the container if you do not need any variants.
A container can be mapped to a variant set adapter, which contains one or more variant sets. A variant set contains variants, which contain the actual personalization data as item values. In small applications you typically need only one variant set.
The container object is created by a factory method of the personalization service.
The container is the entity that is loaded and saved. You would usually have one container for one application - which is a hint for naming the container. The length of the container key must not exceed 40 characters. If you would like to use personalization data in several applications you can use the same container in those applications. The amount of data stored in one container influences the startup performance of an application, as personalization data is typically loaded during startup.
For personalization of tables, specific personalization functionality is available to make it easier for application developers..
Table personalization always needs a personalizer (see the section Direct Mode above). In container mode a transient personalizer object is used, which stores the table personalization data in its memory. To persist personalization data, you have to explicitly copy it to an item inside the container.
In addition to the code samples in this section, you can find a demo app in the SAPUI5 demo kit under the following path:
/test-resources/sap/ushell/demoapps/AppPersSample/App.view.xml
/test-resources/sap/ushell/demoapps/AppPersSample/App.controller.js
For example, on an ABAP server, the path may be as follows:
http://<server>:<port>/sap/public/bc/ui5_ui5/demokit/test-resources/sap/ushell/demoapps/AppPersSample/
You can find the JSDocs for the personalization service under the following path in the SAPUI5 demo kit:
#docs/api/symbols/sap.ushell.services.Personalization.html