Automatic deployment of default customizing #42
Description
Requirement
In February 2025, abapGit was extended with a new feature that allows for the distribution of table contents.
This allows shipping default customizing via abapGit, which would simplify the installation process on new systems. Furthermore, changes to the default customizing would no longer have to be applied manually.
Currently, customizing is maintained manually after installation as described in the installation guide. It cannot be ruled out that individual users have modified the default customizing for their own purposes. Automatically distributing the default customizing could therefore lead to these modifications being overwritten every time the repository is cloned.
To distribute the default customizing risk-free via abapGit, the following customizing tables must be enhanced to create separate key areas for default customizing and modifications:
/USI/BAL_CX_MAP/USI/BAL_LV_DATA/USI/BAL_LV_LOBJ/USI/BAL_LV_RTIM
Possible Solution
A possible solution might be a new key field ROW_TYPE, which can take the values 0 (Default Customizing) or 1 (Modification).
Only entries with ROW_TYPE 0 (Default Customizing) would be shipped via abapGit. If a modification is required in the cloning system, the relevant customizing entry can be copied to a new entry with ROW_TYPE 1 (Modification) and then adjusted accordingly. At runtime records with ROW_TYPE 0 would be overridden by corresponding records with ROW_TYPE 1.
Records that only exist in the cloning system should be created with ROW_TYPE 1 for semantic reasons and to avoid accidents in case the default customizing gets enhanced later.
This would allow default customizing to be shipped via abapGit, and once-maintained modifications would be protected against accidental overwriting.
Open questions
Table /USI/BAL_LV_DATA defines the relevant data containers per log level. If a data container class is not maintained in this table, it will not be used at runtime.
The concept described above does not allow a logical deletion of a default customizing record, but some users might want to avoid using certain data containers for arbitrary reasons.
At the moment these users could simply not maintain the respective customizing records but shipping default customizing would force them to manually delete unwanted records every time they are cloning this repository.
This might be solved by adding a deletion flag to the table.
All other tables can be maintained in a way, that would be equivalent to a deletion from the logical perspective. But if /USI/BAL_LV_DATA gets a deletion flag, they should get one as well for the sake of consistency.