CX Tables
CI Views
The STGADM schema has the same table structures as CISADM. For example, the CI_ACCT table in STGADM is identical to the CI_ACCT table in CISADM.
When mapping from legacy source tables to the OUAF application’s target tables, the tool must generate the new primary key values and link them to their respective legacy values. A specific set of CX staging tables is utilized to facilitate this process. These tables closely resemble their CI counterparts but include an additional CX primary ID. For child tables, there is also a CX foreign key that links to the parent CX row. The CX IDs are defined with a VARCHAR2(128) data type, which provides ample space for any legacy key value and allows for the concatenation of legacy values to create unique keys if needed. To create a CX table, see create_cx_table in the Miscellaneous procedures.
When populating the CX tables, the new ID can be generated during the insert, depending on the conversion method. For high-volume conversions, it is better to first populate the tables without keys and then generate them separately. This way, CX ID values will link legacy and new keys as a cross-reference.
In the staging schema, the CX tables replace their corresponding CI tables. This means that a CX table is created, and the CI table is dropped. Instead of the CI table, a CI view with the same name is created, which selects all the original CI columns from the CX table. This view allows the application to continue working against the staging schema, as it can access the CX data via the CI views.
For example, the following diagram illustrates what was discussed above using the CX_PER and CI_PER tables.
In the above example, the CX_PER_ID on both tables will be populated with the legacy person ID. The CX_PER_NAME_ID is the primary index on the CX_PER_NAME table. Because a person can have more than one name, the CX_PER_NAME_ID can be made unique by concatenating the legacy client ID and any other field from the legacy data, such as the sequence number and name type code.
The PER_ID, which is the actual ID required by the OUAF application, can now be generated and updated in a subsequent conversion step without risking the integrity of the relationship between the person name and its parent person object. The CX_PER table also contains the cross-reference between the legacy ID and the newly generated ID, which may be necessary when updating the CX_PER_NAME and the other child PER_ID object fields.
The CI_PER and CI_PER_NAME views select only the original fields, not the CX ones. Thus, you can use the OUAF application to log in to the staging schema and view the data.
Services
The CX table is used regardless of whether the tables are directly populated with SQL statements or through OUAF service calls through business objects, business services, or services. When you use a service to populate the data, the CI views allow the service to access the CX tables. Since the service adds data through these views, the CX columns remain empty at that time. After a successful service call, the DIH tool updates the CX_PER_ID in the CX_PER table with the legacy key value. In this scenario, the service generates the real ID and updates it across all child objects, eliminating the need for the tool to modify the CX values for each child.