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. This data should be taken into consideration whenever users or roles are changed.

Another aim was to integrate existing user-specific tables in the concept using a given interface.

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.

A key must be assigned for personalization data to be stored in the central repository. This can be done with registration transaction PERSREG.

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.

The data types used need not be stored in the 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 the fields to be used as keys for the modification must be defined when the data is written.

The type check when reading or writing is not very 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, e.g. 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 administration or from role administration. Transactions SU01 and PFCG were enhanced to cope with this situation.

You can also access the data from a maintenance transaction for personalization.

The use of the generic repository for personalization data is explained in the following documentation: