Overview and guidelines for CDT

IBM® Sterling Order Management System provides a Configuration Deployment Tool (CDT) that enables you to migrate configuration data in cloud environments. This tool ensures data integrity and reduces the system downtime to transfer data and minimizing the effort needed to ensure accuracy.

During incremental configurations of Sterling Order Management System, changes are typically developed in a test environment and then they are rolled out into production. Migrating configuration data can be cumbersome and time-consuming.

The Configuration Deployment Tool is designed to migrate data that is modified as part of a normal day-to-day operation. Configuration Deployment Tool is used to deploy configuration data as the result of an upgrade. However, you should not perform the data upgrade itself.

Supported capabilities

Transfer data from databases to XML files or from XML files to databases.
Transform certain data such as IP addresses and port numbers that are different in two environments, based on the network configuration.
Deploy or ignore selective records using CDT between two databases.

Deploy or ignore selective records using CDT

Environment-specific values can be deployed or ignored in tables such as PLT_PROPERTY or YFS_COMMON_CODE and are not overridden when CDT is deployed from source to target. For more information, see Deploying and ignoring selective records while using CDT.

Transform data using the CDT

CDT enables you to automatically transform these data elements into target-appropriate values by letting you specify transformations to be carried out on the source data before it is deployed into the target.

Frequently, development and production environments have different values for network settings such as server names and IP addresses. Some configuration data tables in the Sterling Order Management System store host names, IP addresses, and URLs. While these are valid for your source environment, when deploying this data into the target environment, the configuration must be updated with the corresponding values that are applicable to the target environment.

Best Practices for importing data through CDT

While importing data from the source into target through CDT, the target data syncs with the source data. This means that the target data is updated for existing source data. The additional target data is deleted and complete data integrity is ensured.

You can use Ignore and AppendOnly modes to import CDT data. However, these modes do not guarantee integrity and must be used them with caution. You can also use other cloud environments instead of the external environment.

However, this might not work in some scenarios. So, you can use Ignore and AppendOnly modes.

Ignore

During CDT deployment, you can set a preference to ignore some selective tables during the deployment.

Ignoring a table or a driver entity also automatically ignores all its dependent tables. However, there are some tables that store data for multiple driver entities and are present in multiple groups. For example, the YFS_GRAPH_UI table that contains data for pipelines, services and statuses. If any one of these tables are ignored, CDT incorrectly marks the corresponding records for deletion.

AppendOnly

If some tables are partially maintained in other environment, specify the preferences to ensure the deployment of the tables an AppendOnly mode. There can be a lot of data with integrity issues in AppendOnly mode.

For AppendOnly tables, the dependent tables are not ignored. Marking a table as AppendOnly implies that only a few rows in the target database are maintained on the source system and other rows are externally imported. Ensure that there is no overlap between the data that is present in the source and the external system. For example, if you maintain your shipping nodes in the source database and import store information directly into the target, you must not have any stores in the source database. This leads to unpredictable results.

CAUTION:

Using Ignore or AppendOnly features in CDT does not guarantee the integrity of any external data. To ensure data integrity, CDT must have complete access to the configuration data.

<preferences>
    <configsynch>
        <Settings ReportsDir="">
            <AuditDeployment ValidateLockid="y" ValidateOldValues="y" ValidateRecordExistsBeforeDelete="y"/>
        </Settings>
        <SourceTargetPrefs>
            <SourceTargetPrefs>
                <SourceTargetPair SourceDatabase="DEFAULTXMLDB" TargetDatabase="SYSTEMDB">
                    <Transformations>
                    </Transformations>
                    <Ignore>
				<Table Name="YFS_USER"/>
	   		    <Table Name="YFS_USER_GROUP_LIST"/>
                     </Ignore>
                    <AppendOnly>
				<Table Name="YFS_CUSTOMER"/>
				<Table Name="YFS_CUSTOMER_ADDNL_ADDRESS"/>
                     </AppendOnly>
                </SourceTargetPair>            
            </SourceTargetPrefs>
        </SourceTargetPrefs>
    </configsynch>
</preferences>

Handing YFS_PERSON_INFO records

YFS_PERSON_INFO records require special handling in CDT. When reading the recurring records from YFS_PERSON_INFO, CDT does not require a query for YFS_PERSON_INFO table. In such cases, records are figured out from all the parent tables which has a relationship with YFS_PERSON_INFO. Thereafter, after reading through all tables and accumulating all the PERSON_INFO keys from these tables, it reads the PERSON_INFO records corresponding to the PERSON_INFO keys. This means that in a regular CDT run, the PERSON_INFO records pertaining to the config or master tables are read and deployed. However, the records pertaining to transaction tables are not dealt with.