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:

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:

  1. 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.

  2. 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.

  3. After synchronizing the BOM-based configuration model with the source BOM Model, you can proceed with any of the following:

    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:

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:

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.

Fields That Must Be Synchronized
Table Field Import Publication
CZ_DEVL_PROJECTS ORIG_SYS_REF includes back pointers to EXPLOSION_TYPE:ORGANIZATION_ID:TOP_ITEM_ID Yes Yes
CZ_ITEM_MASTERS ORIG_SYS_REF includes back pointers to INVENTORY_ITEM_ID:ORGANIZATION_ID Yes Yes
CZ_ITEM_TYPES ORIG_SYS_REF includes back pointers to ITEM_CATALOG_GROUP_ID Yes Yes
CZ_LOCALIZED_TEXTS ORIG_SYS_REF includes back pointers to COMPONENT_ITEM_ID:EXPLOSION_TYPE:ORGANIZATION_ID Yes No
CZ_MODEL_PUBLICATIONS PRODUCT_KEY includes back pointers to ORGANIZATION_ID:TOP_ITEM_ID Yes Yes
ORGANIZATION_ID Yes Yes
TOP_ITEM_ID Yes Yes
CZ_PS_NODES ORIG_SYS_REF includes back pointers to COMPONENT_CODE:EXPLOSION_TYPE:ORGANIZATION_ID:TOP_ITEM_ID Yes Yes
COMPONENT_SEQUENCE_PATH Yes Yes
  COMPONENT_SEQUENCE_ID Yes Yes
CZ_XFR_PROJECT_BILLS ORGANIZATION_ID Yes No
TOP_ITEM_ID Yes No
COMPONENT_ITEM_ID Yes No
SOURCE_SERVER Yes No

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

After changing databases in these ways, you must synchronize the publication data so that inconsistencies are corrected. Examples of data inconsistencies are:

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.

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:

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:

In the publication record on Target B:

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.

Original Publication

the picture is described in the document text

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:

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.

Publication After Cloning

the picture is described in the document text

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

the picture is described in the document text

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.

Example of Missing Source 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:

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

the picture is described in the document text

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.

CZ_SERVERS Entries on Source A Before Cloning
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.

CZ_SERVERS Entries on Target C Before Cloning
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:

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

the picture is described in the document text

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.

CZ_SERVERS Entries on Server B After Synchronization
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.

CZ_SERVERS Entries on Target C After Publishing a Model from Source B
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.