Central Repository for Personalization Data
The purpose of a central repository for personalization data is to provide storage for user-specific and role-specific data without having to create any additional database tables.
The functionality includes a generic repository for user-specific and role-specific data and for central access to this data by user and role maintenance. It also permits existing tables containing user-specific data to be linked to the central access using a fixed interface.
To use the framework, you create a key under which application saves its data. This can be done with registration transaction PERSREG. The data can then be stored in the application simply by calling an interface direct to a generic data repository. You can specify if changing the data for this key should also be performed with the user administration. To do this, the application must provide a dialog window for the personalization key that can be called by user maintenance application.
In addition to using the generic storage of personalization data, you can connect your own tables with user-dependent data to user administration using the framework.
This data should be considered whenever users or roles are changed.
The generic repository is used to store the personalization data. It can be accessed with the class methods of class CL_PERS_ADMIN.
The data can be stored either as simple values, structures, or internal tables. As fields, structures can only contain elementary data. Internal tables can contain structures or elementary data as rows.
Define internal tables as table types. Tables with a header line (for example: like tstc occurs 0 with header line) cannot be used.
The data types used do not need to be stored in the ABAP Dictionary.
If an internal table was selected as the data type for the personalization data, you can read only parts of the table when you access the data. Selection conditions can also be defined for any fields of the internal table. The conditions are passed in the form of field name-field value combinations when you read the data.
Similarly, you can update only parts of the stored internal table. In this case, define the fields to be used as keys for the modification when the data is written.
The type check when reading or writing is not strict. If the type with which the data was written in the repository is not the same as the type with which the data is read, there is only an error if the individual fields do not have the same length. If other changes are made to the type, for example, if the name of the field changes, the fields might not be completely defined.
A buffer can be used when the data is written. In this case the data is only written to the database when the corresponding method is called.
The data can be stored either for the user, for roles or for the system. In this case all the data assigned to a user (with the role or with one's own setting) can be read at one time.
You can access the personalization data from User Maintenance (transaction SU01) or from Role Maintenance (transaction PFCG).
You can also access the data from a maintenance transaction for personalization.