Configuring data version labels
To make it easier to track versions of configuration data, or sets of changes to configuration data, use the Configuration Data Versioning Tool , which is part of the Configuration Deployment Tool (CDT).
Configuration data is an integral part of all implementations. Often, there is a need to track changes to an implementation's configuration. Furthermore, if the changes in configuration data are found to be inadequate, there is no easy way of rolling back changes to their original states.
In an offsite and onsite implementation model, master configuration data is maintained onsite, which is where the production environment is hosted. When a patch must be applied to the production environment, offsite test developers must write instructions regarding any configuration data changes for the patch and pass it to the onsite configuration manager; that is, certain values of business rules need to be changed. The onsite configuration manager has to replicate the configuration changes onto the production environment.
To make it easier to track versions of configuration data, or sets of changes to configuration data, use the Configuration Data Versioning Tool , which is part of the Configuration Deployment Tool (CDT). It enables you to capture changes from a source database, compare and deploy them onto a target database (this can be the same or a different database).
The config table must have AuditRequired set to Y and the table name must exist in config_db.xml
AuditRequired flag set to Y.
By default, most of the configuration tables have AuditRequired flag
set to Y.You can create version labels in the Applications Manager to represent timestamps in a time line when changes occur in configuration data. The system can then identify any changes in the configuration data between timestamps of version labels based on the audit information in the system.
The Configuration Versioning Tool allows you to select different version labels from a source database and compare the data and apply them to a target database. You can see the details of each difference and detect conflicts. Once all conflicts are resolved, you can deploy the changes.