Synchronizing Data
This chapter describes when and how data is synchronized. This includes synchronizing BOM data after the import server has changed and synchronizing publication data after a database has been cloned.
This chapter covers the following topics:
Overview
This chapter describes when and how data is synchronized. This includes synchronizing BOM data after the import server has changed and synchronizing publication data after a database has been cloned. This chapter explains how to restore the identity and linkage of mismatched data by:
Introduction
The kinds of data and circumstances requiring synchronization are:
-
BOM Models
-
The import server has changed to a different database instance (for example, you previously imported BOM data from instance A, but you now import BOM data from instance B)
-
The production database instance is not the import server
-
The import source or import target data has been migrated to another database instance
-
-
Configuration model publication records
-
The Publication source or target database instance has been cloned
-
Publication data has been migrated to another database instance
-
Publication synchronization must be run after BOM Model synchronization only when data is migrated from one database instance to another. In all other scenarios, the two kinds of synchronization are independent from one another. For more information on migration, see Migrating Data.
For information about synchronizing BOM Model data, see Synchronizing BOM Model Data.
For information about synchronizing publication records on cloned database instances, see Synchronizing Publication Data after a Database Instance is Cloned.
Synchronizing BOM Model Data
The configuration model in the CZ schema is an extension of the source BOM Model that participates in Oracle Applications processes such as ordering. For a BOM Model to be orderable, the BOM Model in the CZ schema must match certain criteria with the BOM Model in Oracle Bills of Material. Synchronization causes the BOM-based configuration model in the CZ schema to be modified to match the production BOM Model.
Data synchronization is not the same as data refresh (see Refreshing Imported Data ).
The concurrent programs for synchronizing BOM Model data are described in Model Synchronization Concurrent Programs.
The BOM Model Synchronization Process
The process for synchronizing BOM Model data is as follows:
-
Check the similarity between the production BOM Model you wish to use as the new import source or publication target, and the BOM Model represented in your configuration model.
For more information, see Checking BOM and Model Similarity.
-
Synchronize the BOM Model in the configuration model with the source BOM Model by running the Synchronize All Models concurrent program. For more information, see Result of Synchronizing BOM Models.
-
After synchronizing the BOM-based configuration model with the source BOM Model, you can proceed with any of the following:
-
Reimport or refresh the BOM Model in the CZ schema (see Populating the CZ Schema)
-
Publish the configuration model (see Publishing Configuration Models)
Running the publication concurrent programs includes BOM Model synchronization. For details, see Publishing a Configuration Model.
-
Checking BOM and Model Similarity
The two concurrent programs available for checking if the BOM Model in the CZ schema sufficiently matches the source BOM Model are:
-
Check Model/Bill Similarity
-
Check All Models/Bills Similarity
For details about these concurrent programs, see Check Model/Bill Similarity and Check All Models/Bills Similarity.
Running the Check Model/Bill Similarity and Check All Models/Bills Similarity concurrent programs creates a Check Model/Bill Similarity report, which describes the fields that do not match and must be corrected before synchronization can occur. For more information, see Criteria for BOM Model Similarity. For more information about the report, see Model/Bill Similarity Check Report.
Criteria for BOM Model Similarity
The Check Model/Bill Similarity and Check All Models/Bills Similarity concurrent programs use validation criteria to determine if a BOM-based configuration model is similar enough to be synchronized with the source BOM Model:
-
Both structures use the same Inventory Items. For example: The bill’s Item identity is identified by the concatenated values of segments 1 through 20 in MTL_SYSTEM_ITEMS of the corresponding Item. CZ_PS_NODES are identified by the corresponding value of CZ_ITEM_MASTERS.REF_PART_NBR.
-
Parent-child relationships are the same in the source and target BOM Models. For example, each imported parent node has the same imported children Items as in the BOM Model structure. The order of the children may be different.
-
Certain Item characteristics are the same. For example, the value of minimum or maximum default quantities, or the ’Required when parent is selected’ Property are the same.
-
A child’s effectivity range does not fall outside the effectivity range of its parent.
-
If there is only one child node with the given identity (CONCATENATED_SEGMENTS), then its disable date (effective to date) should be the same as the parent node and the effective dates (effective from date) should either be before SYSDATE or be the same for the child node and the parent.
-
If there is more than one child node with the given identity (CONCATENATED_SEGMENTS), then the previous scenario is only valid for the child node that has the earliest effective date. For the other child nodes the ranges should be exactly the same.
-
-
When creating a BOM Model through an interface, records may not be recognized by Oracle Configurator during the synchronization process if the BOM_INVENTORY_COMPONENTS.IMPLEMENTATION_DATE field is null. If this field is null, then it is automatically populated with either the EFFECTIVITY_DATE or the SYSDATE.
Fields That Must Be Synchronized lists the configuration model’s data fields that must be synchronized with the import source BOM Model or publication target.
The following table lists the appropriate table for synchronization and the fields that are synchronized for import.
Organization information is mapped by matching ORG_ORGANIZATION_DEFINITIONS.ORGANIZATION_CODE. If the matching Organization is not found, then an error occurs.
Note: It is important that the Item flexfield structure and the concatenation characters for the Item flexfield be the same on all database instances and not updated.
BOM Model synchronization checks the Models that are candidates for synchronization but results in an error if a Model does not have an EXPLOSION_TYPE of OPTIONAL. See Modifying EXPLOSION_TYPE for more information about the EXPLOSION_TYPE setting. BOM Model synchronization does not check the mandatory fields.
Result of Synchronizing BOM Models
After determining that the source BOM Model and the BOM-based configuration model are sufficiently similar, based on the report generated by the Check Model/Bill Similarity and Check All Models/Bills Similarity concurrent programs, the BOM Models can be synchronized either by running the Synchronize All Models or the publication concurrent programs.
Attempting to synchronize mismatched BOM Models results in errors.
BOM synchronization causes the Item identification in the BOM-based configuration model to be matched with the import source or publication target BOM Model. During data import, the CZ schema is populated with the source BOM Model’s ORIG_SYS_REF identification. However, the same BOM Model in Bills of Material of two different database instances may have different ORIG_SYS_REF identification.
If the database instance from which the BOM Model was imported into the CZ schema is replaced with a new instance containing the same BOM Model, it is likely that the ORIG_SYS_REF identification longer will no longer match the original source BOM Model. Likewise, if the configuration model is being published to an instance that did not serve as the import server, the ORIG_SYS_REF identification may not match the source BOM Model.
Because CZ_ITEM_TYPE_PROPERTIES and CZ_ITEM_PROPERTY_VALUES do not have the ORIG_SYS_REF field, there is no way for the Check Model/Bill Similarity and Check All Models/Bills Similarity concurrent programs to verify that the imported Properties and Property values correspond to the Descriptive Elements and their values on the target instance. Runtime Models use the imported Property values. You must manually verify that the Descriptive Elements and their values are the same on both the source and target of the BOM Model synchronization.
Synchronizing Publication Data
Publication data can become inconsistent when you
-
Clone a publication source or target database instance
-
Migrate data from one database instance to another
-
Decommission the production or target database instance
After changing databases in these ways, you must synchronize the publication data so that inconsistencies are corrected. Examples of data inconsistencies are:
-
Missing publications
-
Incorrect publications
-
Overlapping publications
-
Missing or incorrect entries in the CZ_SERVERS table
The concurrent programs for synchronizing publication data are described in Publication Synchronization Concurrent Programs.
See Publishing Configuration Models for details about creating publications, and about the relationship between the publication data on the source and target database instances.
Synchronizing Publication Data after a Database Instance is Cloned
Cloning can be done into a new empty database instance or into one that already contains work product data. In either case, the cloned database contains a copy of the original data, but publication data becomes inconsistent in the following ways.
-
References between the source and target publications can become lost or incorrect
-
Applicability parameters of publication records on the source and target can overlap
Publication data inconsistencies need to be resolved by updating data on both the cloned and the publication source or on the target that was not cloned. The following publication synchronization concurrent programs are available after cloning either a target or source database instance:
-
Synchronize Cloned Target Data synchronizes the publication data in the new cloned target database with the publication data on the source database.
-
Synchronize Cloned Source Data synchronizes the publication data in the new cloned source database with the publication data on the target database.
See Example of Synchronizing Publication Data on a Cloned Target for details about the circumstances and results of synchronizing a cloned publication target. See Example of Synchronizing Publication Data on a Cloned Source for details about the circumstances and results of synchronizing a cloned publication source.
Warning: After cloning a publication source, do not clone the target until you have first synchronized publications on that cloned source, or vice versa.
Example of Synchronizing Publication Data
The example illustrating publication synchronization uses CZ_SERVERS and CZ_MODEL_PUBLICATIONS data to illustrate where inconsistencies occur between a publication source and target after cloning or restoring a source or target database instance from backup.
CZ_SERVERS Table
Publication synchronization updates the CZ_SERVERS table to ensure that the local and remote servers are listed correctly to associate the cloned publication source or target with the appropriate publication records on the unchanged target or source, respectively.
CZ_MODEL_PUBLICATIONS Table
The following columns in the CZ_MODEL_PUBLICATIONS table help identify target publications relative to their source so they can be republished:
PUBLICATION_ID
PUBLICATION_ID is the publication’s generated identifier in the database instance containing the configuration model. This identifier is generated when a publication record is created in the Create Publication page.
REMOTE_PUBLICATION_ID
REMOTE_PUBLICATION_ID on the source database instance points to the PUBLICATION_ID on the target database instance. The REMOTE_PUBLICATION_ID on the target database instance points to the PUBLICATION_ID on the source database instance. See Original Publication.
SERVER_ID
SERVER_ID associates the publication record with a database instance in the CZ_SERVERS table.
Example Publication Data Before Cloning
The following examples of publication data presume a publication source database, A, with PUBLICATION_ID 1000 and a publication target database, B, with PUBLICATION_ID 2000. Original Publication shows the original publication records on Source A and Target B.
In the publication record on Source A:
-
REMOTE_PUBLICATION_ID is 2000 because it points to the PUBLICATION_ID on the publication target
-
SERVER_ID of the publication record is B because it points to the LOCAL SERVER_ID on the publication target
In the publication record on Target B:
-
REMOTE_PUBLICATION_ID is 1000 because it points back to the PUBLICATION_ID on the publication source
-
SERVER_ID of the target publication record is B, because it identifies itself as the LOCAL entry in the CZ_SERVERS table
Original Publication illustrates a publication record on the source and target databases. Source A’s REMOTE_PUBLICATION_ID 2000 references Target B’s PUBLICATION_ID 2000, and Target B’s REMOTE_PUBLICATION 1000 references the Source A’s PUBLICATION_ID 1000. Source A’s server ID points to the Target B’s server. Target B’s server ID points to itself, not to Source A’s server.
Publication records on the target assume only one publication source and do not identify the source publication record by the SERVER_ID of the source.
Example of Synchronizing Publication Data on a Cloned Target
Synchronizing publication data on a cloned target resolves the following issues caused by cloning the publication target:
-
The CZ_SERVERS table on the source does not include a listing for the cloned target.
-
A database link must be established between the publication source and the cloned target.
-
References to the publication record on the source database instance are lost, wrong, or have overlapping applicability parameters.
Original Publication shows the original publication records on Source A and Target B.
Target B is then cloned to create Target C. Publication After Cloning illustrates the resulting cloned Target C copy. The publication record on Source A does not point to the cloned publication record on cloned Target C. Source A still references Target B as the target server for the publication record (SERVER_ID:B).
Publication After Cloning illustrates a publication record after Target B is cloned to Target C. Target C’s publication record has the same values as the original target publication record. The original Target B’s REMOTE_PUBLICATION_ID 1000 refers to Source A’s PUBLICATION_ID 1000. The cloned Target C’s REMOTE_PUBLICATION_ID 1000 does not have any indication that this is referencing a record on Source A.
Source A is then synchronized with Target C. Publication After Synchronization illustrates the resulting publication information after synchronization. A new publication record is created on Source A referencing the record on cloned Target C. The publication record on cloned Target C is also updated so that it references the new publication record on Source A as well as correcting the SERVER_ID that associates the publication record with a LOCAL database instance.
Publication After Synchronization illustrates a publication record after synchronizing Source A and Target Target C. Cloned Target C’s publication record is updated with a new REMOTE_PUBLICATION_ID that now references a new publication record created on Source A. The new publication record’s REMOTE_PUBLICATION_ID on Source A references the updated publication record on the cloned Target.
Publication After Synchronization
Example of Missing Source Publication summarizes the publication information from the original publication to the cloning, to the synchronization.
The following table is a summary of what happens after cloning and then synchronizing a publication.
| Source A | Target B | Target C (cloned from B) | |
|---|---|---|---|
| Original publication: | |||
| PUBLICATION_ID | 1000 | 2000 | |
| REMOTE_PUBLICATION_ID | 2000 | 1000 | |
| SERVER_ID | B | B | |
| After Cloning Target B to Target C: | |||
| PUBLICATION_ID | 1000 | 2000 | 2000 |
| REMOTE_PUBLICATION_ID | 2000 | 1000 | 1000 |
| SERVER_ID | B | B | B |
| After Synchronizing Source A and Target C: | |||
| PUBLICATION_ID | 1000 | 2000 | 2000 |
| REMOTE_PUBLÌCATION_ID | 2000 | 1000 | updated |
| SERVER_ID | B | B | updated |
| PUBLICATION_ID | 1001 | 2000 | |
| REMOTE_PUBLICATION_ID | 2000 | 1001 | |
| SERVER_ID | C | C |
For information on running the Synchronize Cloned Target Data concurrent program, see .
Example of Synchronizing Publication Data on a Cloned Source
Synchronizing publication data on a cloned source resolves the following issues caused by cloning the publication source:
-
The CZ_SERVERS table on the cloned source contains incorrect information in the LOCAL server entry of the clone.
-
The SOURCE_SERVER_FLAG on the publications target identifies the original source, not the cloned source as the publication source server.
-
A database link must be established between the publication target and the cloned source.
-
Target publication records require only one corresponding publication source.
Note: Oracle does not support publishing from multiple source database instances to a single target database instance. Oracle recommends decommissioning original source when synchronizing the cloned source.
Publication Before Cloning the Source Database illustrates a Model that is originally published from Source A to Target C.
Publication Before Cloning the Source Database illustrates a publication record before Source A is cloned. Source A’s REMOTE_PUBLICATION_ID 2000 references Target C’s PUBLICATION_ID 2000, and Target C’s REMOTE_PUBLICATION_ID 1000 references Source A’s PUBLICATION_ID 1000.
Publication Before Cloning the Source Database
CZ_SERVERS Entries on Source A Before Cloning illustrates some of the entries for database instances A and C in the CZ_SERVERS table of Source A before cloning.
The following table illustrates database instance entries on two servers prior to cloning the source server.
| Server | LOCAL_NAME | SERVER_LOCAL_ID | HOSTNAME | DB_LISTENER_PORT | INSTANCE_NAME |
|---|---|---|---|---|---|
| A | LOCAL | 0 | my_serv | 1521 | A |
| C | SALES | 1 | my_serv | 1521 | C |
CZ_SERVERS Entries on Target C Before Cloning illustrates some of the entries for database instances A and C in the CZ_SERVERS table of Target C before cloning.
The following table illustrates database entries on two servers before cloning the target server.
| Server | LOCAL_NAME | SERVER_LOCAL_ID | HOSTNAME | DB_LISTENER_PORT | INSTANCE_NAME |
|---|---|---|---|---|---|
| A | source | 1 | my_serv | 1521 | A |
| C | LOCAL | 0 | my_serv | 1521 | C |
The SOURCE_SERVER_FLAG on Target C is set to 1, meaning Target C recognizes Source A as its publication source.
If configuration models are published from Source A to Target C, and then Source A is cloned to create Source B, the following inconsistencies occur:
-
The LOCAL entry in the CZ_SERVERS table of Source B must be updated by removing the entry for Source A and completing the identification for Source B.
-
The publication record on Source A and its clone on Source B both point to Target C which is incorrect.
-
Publication records on Target C continue to identify Source A as the publication source server.
Source Server B is Cloned from Source Server A illustrates Source B as a clone of Source A.
Source Server B is Cloned from Source Server A illustrates a publication record after Source A is cloned to Source B. Source B’s publication record has the same values as the original source publication record. Both the cloned and the original Source A’s REMOTE_PUBLICATION_ID 2000 refers to Target C’s PUBLICATION_ID 2000. There is no way for the publication on Target C to know that its source is now Source B.
Source Server B is Cloned from Source Server A
After cloning, the clone’s CZ_SERVERS table is an exact copy of the original Source A (see CZ_SERVERS Entries on Source A Before Cloning). Source B must be synchronized because its CZ_SERVERS table does not have a LOCAL entry for Source B.
To synchronize existing publications records on Source B with Target C, and publish new Models from B to C, you must first run the Synchronize Cloned Source Data concurrent program on Source B.
Running the Synchronize Cloned Source Data concurrent program updates the LOCAL entry in the CZ_SERVERS table on Source B with correct information. CZ_SERVERS Entries on Server B After Synchronization shows the entries on the two servers in the CZ_SERVERS table on B after running the synchronization concurrent program.
| Server | LOCAL_NAME | SERVER_LOCAL_ID | HOSTNAME | DB_LISTENER_PORT | INSTANCE_NAME |
|---|---|---|---|---|---|
| B | LOCAL | 0 | my_serv | 1521 | B |
| C | SALES | 1 | my_serv | 1521 | C |
Synchronizing Source B has no effect on Target C. By publishing or republishing a Model from Source B to Target C, the CZ_SERVERS table on Target C is updated. CZ_SERVERS Entries on Target C After Publishing a Model from Source B shows Source B listed as the publication source in the CZ_SERVERS table on Target C, with the SOURCE_SERVER_FLAG enabled (set to 1). Both Source A and Source B can serve as publication source.
The following table illustrates the target server settings after publishing a Model from the source server.
| Server | LOCAL_NAME | SERVER_LOCAL_ID | HOSTNAME | DB_LISTENER_PORT | INSTANCE_NAME | SOURCE_SERVER_FLAG |
|---|---|---|---|---|---|---|
| A | source | 1 | my_serv | 1521 | A | 1 |
| B | source | 2 | my_serv | 1521 | B | 1 |
| C | LOCAL | 0 | my_serv | 1521 | C | 0 |
If a decision is made to not decommission Source A, and there are configuration models that were published from A to C, then running the Synchronize Cloned Source Data concurrent program on Source B removes any cloned publications to prevent conflict between the two publications sources and allows Source A to continue as the source for those publications.
Note: Republish and New Copy in the Model Publications page are disabled for a disabled publication record. Oracle Configurator Developer users can delete the disabled publication record or edit the publication’s applicability parameters to re-enable the publication in Production or Test mode.