Class sap.ushell.services.PersonalizationModule: sap/ushell/services/Personalization

Factory method to obtain an empty Data Context object. When data present in a prior context is not relevant (e.g. when using a "uniquely" generated key and planning to overwrite any colliding front-end server data).

The call always returns an cleared container().

Note that an existing container at the front-end server is not actually deleted or overwritten unless a save operation is executed.

An initial object is returned.

Asynchronously starts a deletion request for the given container identified by sContainerKey. Can be called without having ever called getContainer with the corresponding key

Note: After invoking this operation, the state of other Containers obtained for the same key is undefined! If you want to use the container after deletion, it is strongly recommended to obtain a new instance of a container for the given key *after* the promise has returned.

Note: Invoking this operation while another save or load operation is under way may result in failure.

Factory method to obtain a Data Context object, which is a local copy of the persistence layer data. The Container data is asynchronously read on creation if present, otherwise an initial object is created. The Container data can then be *synchronously* modified (getItemValue, setItemValue). Only on invoking the save()/saveDeferred() method the data is transferred to the persistence. This allows the application to perform multiple local modifications and delay the save operation.

Every getContainer operation returns a new local copy, containing the full data at the point of creation.

Executing load() on the container reloads the data from the persistence, discarding local changes.

Note that the container allows the application to control the round trips to the front-end server persistence. The factory method getContainer is asynchronous and loads the container via the connected adapter from the front-end server. All operations (but for the save operation) are executed synchronously, operating on the local data. This allows the application to control the round trips to the front-end server persistence.

A container can contain a set of items, identified by a key.

You can wrap a container in a VariantSetAdapter to read and write a more complex structure (with multiple keys (variantSet,variant,item)).

Do not mix up the usage of a personalizer and a container for one containerKey. Do not use a PersonalizationContainer and a Container for the same key except for migration scenarios.

scope / validity parameter (@since 1.22.0): An unspecified (undefined validity) or infinite (Infinity) validity indicates that data is persisted in the Personalization data of the front-end server. A round trip is executed on an initial get and at least every save operation. Data is stored per user and retained indefinitely at the front-end server.

The validity parameter allows a designated storage validity for the created container. A 0 validity indicates the data is only persisted within the Fiori Launchpad window. No round trips to the front-end server are executed. Data is lost if the Fiori Launchpad window state is lost (e.g. by navigating to a different page, pressing F5 (reload page) or duplicating the window).

For versions > 1.24 it may happen that for cross-app navigation a reload of the Fiori Launchpad is triggered. In this case a storage of the personalization data in the Fiori lauchpad window would lead to data loss. To overcome this a validity 0 is automatically changed to a validity 1440 (24h; storage on the front-end server). This is only done if a relaod of the Fiori Launchpad is triggered for a cross-app navigation.

Security: It is the responsibility of the application to not persist information relevant to auditing or security using the PersonalizationService with inappropriate validity models. No mechanisms exist to destroy or selectively destroy application-specific data in the front-end server persistence (especially for validity Infinity).

For non-zero validity scopes, data will be transmitted and persisted in the front-end server system.

For limited validity, actual deletion of data on the front-end server is subject to explicit cleanup execution of front-end server jobs and not guaranteed. The data may still be persisted and retrievable. The interface only assures that expired data is no longer exposed to the application code in the Fiori Launchpad.

The ContainerKey uniquely defines the Container, validity is not part of the key (there are no separate namespaces per validity).

In general, mixing different validity models for a given container key is not supported. Fast chaining of different methods may source arbitrary persistence layers. The validity of the resulting object in the done function of a promise is the last get validity.

The validity associated with the last getContainer or createEmptyContainer determines the current validity of the container and the validity used during the next save operation.

Naturally, if a delete or get with validity 0 is issued, it will *not* delete or retrieve a front-end server persistent storage Thus a sequence delete( [validity 0])/wait for promise, getContainer(sKey,{ validity : Infinity}) may return a valid dataset.

Returns a generated key

Returns a personalizer object which handles personalization by asynchronous operations storing the personalization data immediately via the connected adapter. For each operation a round trip is executed.

Do not mix the usage of a personalizer and a personalization container for one containerKey.

Returns a transient personalizer object which handles personalization by asynchronous operations storing the personalization data transiently as an object property. Primary usage of the transient personalizer is a personalization scenario with variants where the transient personalizer is used as a buffer for table personalization data.