Importing externally maintained configuration data

In your implementation of Sterling Order Management System Software, you might import certain data into your target that is not part of your source Sterling Order Management System Software database.

Best practices

If you use the Configuration Deployment Tool to deploy externally maintained data, the recommended way is to import this data into the source and then use CDT to deploy it into the target. This guarantees data integrity.

If you cannot import this data into your source database, Sterling Order Management System Software supplies features that enable you to work with external data by ensuring that the target database either ignores these tables or appends them. Use the Ignore and Append-only features only if you have tried all other available options and only after subjecting your environment to rigorous testing.

CAUTION:

When using the Ignore or Append-only features, the CDT cannot guarantee the integrity of any external data. In order to ensure data integrity, CDT must have complete access to the configuration data.

Ignore

In cases where data in tables is maintained externally, you can omit these tables from the deployment operation by specifying a preference for them to be ignored.

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. An example of this is the YFS_GRAPH_UI table that contains data for pipelines, services and statuses. Ignoring one of these tables causes CDT to incorrectly mark the corresponding records for deletion.

Append-only mode

In cases where some tables are partially maintained externally, you can specify preferences to ensure that these tables are deployed in an append-only mode.

For append-only tables, the dependent tables are not ignored. Marking a table as append-only implies that only a few rows in the target database are maintained on the source system - other rows are externally imported. In such cases, it is extremely important that there is no overlap between the data 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.

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.