Siebel Product Administration Guide > Releasing Products and Other Versioned Objects >

About Avoiding Duplicate Versioned Objects During Product Data Migration


Starting in Siebel 7.8, the import function for product data uses the object identifier to determine whether records being imported already exist in the target database. In earlier versions, the import function used a name-based identifier.

The object identifier refers to the value in the OBJECT_NUM column of the versioned object table, S_VOD, for the corresponding versioned object. Object identifiers are initially set as the value of the row ID. They are always persistent and are referenced in other tables, including S_PROD_INT. For this reason, it is now absolutely mandatory to preserve the object identifiers of versioned objects across multiple environments in order to consistently export and import these object definitions across different environments. This behavior affects all versioned objects: Products, Classes, Attributes, Signals, and Variable Maps.

Guidelines to Avoid Duplicate Versioned Object Records

Follow these guidelines to avoid creating duplicate versioned object records:

  • Use a single master database for product administration. This database ensures that object identifiers of objects can be preserved and easily migrated to different environments.
  • All other databases must have the same object identifier for products, attribute and class records as the master database. As needed, data from the master product administration database must be replicated to other environments, ensuring that the object identifiers are preserved across the databases.
  • Never manually create objects with the same name in two databases. They are different objects and do not merge into one record, using the import function or Application Deployment Manager (ADM). If the object identifier is different for the same object in the two databases, the versioned object is treated as a different object during the import even if the names match, hence the two objects are not merged. Instead, an existing object definition can be moved from one database to another using import or ADM, so that the object identifier is preserved.
  • The product, attribute, and class master must initially be a copy of the upgraded production database.

How Duplicate Objects Are Created

When you migrate customizable product (CP) data using product export and import or Application Deployment Manager (ADM) and the joint workspace data type, you can create duplicate records in the destination environment database when the CPs in the two environments have the same name but have different object identifiers. The S_PROD_INT.CFG_MODEL_ID column stores the versioned object identifier.

For example, assume that the source environment includes the product records shown in Table 42, and the target environment includes the product records shown in Table 43.

Table 42. Example of Data in Source Environment
Product Name
Row ID
CFG_MODEL_ID

Product A

1-A

1-A

Product B

1-B

1-B

Table 43. Example of Data in Target Environment
Product Name
Row ID
CFG_MODEL_ID

Product A

1-A

1-A

Product B

1-C

1-C

After the data migration, the target application includes the records shown in Table 44.

Table 44. Example of Data in Target Environment After Migration
Product Name
Row ID
CFG_MODEL_ID

Product A

1-A

1-A

Product B

1-C

1-C

Product B (1-B)

1-B

1-B

Product A is imported correctly to the target environment, because it has the same identification number in both environments.

Product B has different identification numbers in the two environments. Therefore, when it is imported, a duplicate product with the name Product B (1-B) is created. Product B (1-B) contains the latest changes of the product that were made in the source environment, while the original Product B in the target environment is unchanged.

NOTE:  All run-time data, such as quote line items, order line items, and assets, still refer to the original Product B. If a user customizes the product, Siebel Configurator will use the obsolete product definition based on the original Product B rather than the updated product definition of Product B (1-B).

Possible Symptoms of Duplicate Records

The following symptoms probably mean you have duplicate records:

  • The original versioned object definitions are not updated.
  • New object definitions with the imported object identifier are created and have a long name made up of the product name and row ID.
  • The quote and order transaction data refer to outdated product definition.
  • If you customize these products in a quote or order record, the quote uses the outdated definitions instead of the updated product definitions that you imported.
  • Duplicate product, attribute and class records are in the target environment.

Name-Based Import

If you have failed to create a master product database and you already have multiple databases with different object identifiers for the same objects, object identifier-based import fails. In this case, you can use name-based import. Name-based import is not recommended. Use it only as a last resort.

Name-based import is done using the ISS Authoring Import Export business service. For more information, see Siebel Order Management Guide.

Siebel Product Administration Guide Copyright © 2015, Oracle and/or its affiliates. All rights reserved. Legal Notices.