Populating the CZ Schema

This chapter provides an overview of why and how to import data from Oracle Applications and non-Oracle Applications databases. It describes the import processes, the import tables used during data import, how to import data into the CZ schema, data import verification, the process for refreshing or updating imported data, and customizing data import.

This chapter covers the following topics:

Overview

This chapter provides an overview of why and how to import data from Oracle Applications and non-Oracle Applications databases. It describes the import processes, the import tables used during data import, how to import data into the CZ schema, data import verification, the process for refreshing or updating imported data, and customizing data import. The import processes discussed are:

For information about the CZ schema, see the CZ Schema chapter.

Introduction

Populating the CZ schema usually begins by importing data. There are three types of data import:

Once the CZ schema is populated with imported data, that data is then available in Oracle Configurator Developer and the runtime Oracle Configurator.

This section lists:

Types of Data Stored in the CZ Schema During Development and Runtime

The data stored in the CZ schema includes:

See Means of Populating the CZ Schema for information on how this data is inserted. See Standard Import for more details about the specific kinds of Inventory and BOM Model data stored in the CZ schema.

Means of Populating the CZ Schema

The CZ schema is populated with data by the following means:

CZ_IMP Tables

The CZ_IMP tables store imported data and keep track of the success or failure when importing data into the CZ schema. The CZ_IMP tables correspond to the equivalent CZ online tables. The imported data becomes available to Configurator Developer when the Populate and Refresh Configuration Models Concurrent Programs or Execute Populators in Model Concurrent Program, or a custom import moves the data from the import tables into the corresponding online tables. Configurator Developer and the runtime Oracle Configurator read the imported data from the CZ online tables.

For example, when an Item in the CZ_ITEM_MASTERS table is imported into the CZ schema, the Item data also appears in the CZ_IMP_ITEM_MASTER table. For a list of tables that store imported data, see ITEM Item-Master Tables. For more information about where various kinds of data are stored in the CZ schema, see The CZ Schema and the CZ eTRM on MetaLink, Oracle’s technical support Web site.

Standard Import

A standard import consists of transferring data from Oracle Applications Bills of Material (Releases 10.7, 11.0, 11i, or Release 12) to Oracle Configurator Release 12. Data Flow in the Import Process shows the data flow when importing a BOM Model.

Data Flow in the Import Process shows the flow of data during import. The data is extracted from the BOM tables such as BOM_EXPLOSIONS into the CZ Interface tables such as CZ_IMP_PS_NODES and then transferred to the CZ Online tables such as CZ_PS_NODES.

Data Flow in the Import Process

the picture is described in the document text

When developing a configuration model, Oracle Configurator Developer accesses the CZ schema, not the Oracle Applications Inventory and Bills of Material schemas. However, when ordering Items that have been configured based on a configuration model, the runtime Oracle Configurator accesses the CZ schema.

The CZ schema must contain an exact replication of the BOM Model’s structure, rules and Item data. This exact replication is necessary to create configurations of BOM Models that participate in downstream processes such as ordering.

This standard import section describes:

Inventory and BOM Data That Can Be Imported

A standard import involves importing Oracle Applications Inventory and BOM Model data into the CZ schema. Specifically, the imported data is:

Overall Standard Import Procedure

The overall procedure for a standard import is:

  1. Determine the import source and target (see Database Instances)

  2. Prepare the data (see Preparing the Data for Import).

  3. If the import source is a remote database:

    1. The Configurator Administrator must define and enable the source server for import (see Defining and Enabling a Server for Import).

    2. Explode the BOM Models that you want to import (see Exploding BOM Models in Oracle Applications).

  4. Optionally identify specific data to be ignored during the import (see Controlling the Data for Import).

  5. Run the Populate and Refresh Configuration Models Concurrent Programs in Oracle Applications to import the BOM Model’s data into the CZ Schema.

  6. Verify that the data import succeeded (see Verifying the Data Import).

  7. If you re-import the same BOM Model from a different source, you must first synchronize your BOM-based configuration models with the new source (see Synchronizing Data).

  8. Because repeated data imports can result in large amounts of logically-deleted Items in the CZ schema, run the Purge Configurator Tables concurrent programs to improve database performance. For more information, see Purging Configurator Tables.

Determining the Import Data Source Instance and the Target Instance

The source of imported data is also called the import source or remote server. The import source should be a production database. Oracle Configurator supports importing BOM Model data from only one Oracle Applications database. This is because the information used to refresh imported Oracle Applications BOM Models can overlap among multiple Applications databases. See Defining and Enabling a Server for Import for information about changing the import source.

You cannot test a published BOM on a local server if the BOM is defined remotely. When you publish a Model, synchronization takes place. If a Model is published locally but the source BOM is defined remotely, then synchronization does not occur.

The target of the imported data is the database instance you have designated for developing your BOM-based configuration model. You run the Populate and Refresh Configuration Models Concurrent Programs in Oracle Applications in the target database instance.

For more information about selecting or changing which database instance should serve as import source and which should be the target, see Database Instances.

Preparing the Data for Import

For purposes of consistency with other processes in your business, use production data. Preparing the data for standard import involves creating a BOM Model using Oracle Inventory Items. Only Oracle Inventory Items that are associated with a BOM Model in Oracle Bills of Material can be imported into the CZ schema. If you are importing other data or data from non-Oracle Applications databases, see Custom Import. If you are importing rule data from non-Oracle Applications databases or standalone rules, see Rule Import.

Determine which version of Oracle Applications is the import source. You can import BOM Models only from Release 10.7, 11.0 and 11i to Release 12. Standard import requires that BOM Models be complete and identified at the top level. Identifying the BOM Model at the top level insures that all child BOM Models are imported. If a BOM Model is not complete, then a warning message is displayed. For information on importing BOM Models with child BOM Models, and BOM Models with a Common Bill, see BOM Model with a Common Bill.

Note: Items for standard import must be defined in Oracle Applications Inventory and then specified for inclusion in a BOM Model in Oracle Bills of Materials.

To create a BOM Model in Oracle Applications, you must first define the Items (see Defining Inventory Items for Configuration) and then their hierarchical relationship in a BOM Model (see Creating BOM Models for Configuration).

Defining Inventory Items for Configuration

Begin data preparation by defining Inventory Items that can be used to build a BOM Model and provide the Item data needed for implementing a configuration model.

If you are using Multiple Language Support (MLS), you should enter translated descriptions of BOM Model Items before importing data to the CZ schema. See Multiple Language Support.

In Oracle Applications Inventory:

BOM Item Type determines whether an Item can be a component in a bill of materials, may contain child components, or can also be a BOM Model. A BOM Option Class typically contains one or more Standard Items. See Importing Decimal or Integer Quantities for details about importing Standard Item quantities as integers or decimals. For more information on Standard Items, see the Oracle Bills of Material User’s Guide.

Any Item that is defined as a Model in Oracle Inventory and exists as a component in another BOM Model (for example, a PTO BOM Model that contains an ATO BOM Model), must also be defined as a BOM Model in Oracle Bills of Material to be imported into the CZ schema.

When an Item is a component of a PTO or ATO BOM Model and at the same time is the parent of other component Items, the BOM Allowed check box must be selected for that Item. When a Standard Item is defined this way, it can be a "kit" containing other Standard Items. Standard Items included in a kit are always required (mandatory); they are never optional. The BOM Allowed check box must be selected for all of the component Items within the kit.

Item Catalog Descriptive Element values do not have a data type in Oracle Inventory. When you import BOM Model data into the CZ schema, Descriptive Elements become Item Properties. These Item Properties have a data type of Text, or Decimal Number.

By default, the Descriptive Element’s value is imported as a decimal number if the value is a number; otherwise, the value is imported as text. However, you can modify how these values are imported using the ResolvePropertyDataType setting in the CZ_DB_SETTINGS table. For details, see ResolvePropertyDataType.

For more information about imported BOM Models and Properties, see the Oracle Configurator Developer User’s Guide.

For more information about defining Items, see the Oracle Inventory User’s Guide.

Creating BOM Models for Configuration

After defining Inventory Items, you must continue in Bills of Material to create the BOM Model.

When the Mutually Exclusive option is selected, the optional child components of that Option Class mutually exclude one another based on the minimum and maximum number of components allowed in a valid configuration.

Required Items do not participate in the configuration process and therefore are not imported into the CZ schema. (An exception is when a required component contains optional components; in this case, it is imported into the CZ schema). Required Items are added automatically to the configured work order by the AutoCreate Configuration Items concurrent program.

For more information about creating a BOM Models, see the Oracle Bills of Material User’s Guide.

Defining and Enabling a Server for Import

The local database instance is the default import server, meaning if you do not specifically enable a server for import, the database instance in which you run the import is used as the source.

If you are transferring data to the CZ schema from a Bills of Material schema in a different database instance, you must define that import source as a remote server. See Server Administration for information about defining and enabling a remote server. Several servers can be defined and enabled, but only one server is Import Enabled.

If you need to define and enable a remote server for import, you must first submit a Modify Server Definition concurrent request to disable the local server for import, and then define and enable the remote server where the import source data is stored.

Oracle requires that you define only one server for import. If an import server is changed after BOM Models have been imported, then the configuration models must be synchronized to the BOM Models on the new import server. For details on synchronizing the configuration models with the BOM Models on the newly defined remote server, see BOM Model Synchronization Process.

Exploding BOM Models in Oracle Applications

Prior to importing or refreshing a BOM Model into the CZ schema from Bills of Material (Releases 10.7, 11.0, 11i, or 12) in another instance (remote server), you must explode the BOM Model.

The following sections explain how to explode a BOM Model in different releases of Oracle Applications.

Exploding a BOM Model in Release 12

To explode a BOM Model in Oracle Applications, Release 12:

  1. Log in to Oracle Applications using the appropriate username and password.

  2. Select the Order Management responsibility.

  3. Select Orders, Returns > Sales Orders.

  4. Enter all required data in the Main tabbed region.

  5. Click the Line Items tabbed region.

  6. On the Order Line, select the root Model that you want to import into Oracle Configurator from the Item list of values. This is the same Model that you select when creating a new object in Oracle Configurator Developer or running the Populate Configuration Models concurrent program in Oracle Applications.

    The BOM Model explosion process is called recursively for as many levels as necessary in the root Model.

  7. Enter 1 in the Qty field, then click Configurator.

  8. After all the BOM Model’s components are displayed, click Cancel to close the Configurator page.

Exploding a BOM Model in Release 10.7 or 11.0

To explode a BOM Model in Oracle Applications, Release 10.7 or 11.0:

  1. Log in to Oracle Applications using the appropriate username and password.

  2. Select the Order Entry responsibility.

  3. Navigate to the Sales Orders page, enter all required fields.

  4. On the Order Line, select the Model that you want to import into Oracle Configurator from the Item list of values. This is the same Model that you select when creating a new object in Oracle Configurator Developer or running the Populate Configuration Models concurrent program in Oracle Applications.

  5. Enter 1 in the Qty field, then click Configurator.

  6. After all the BOM Model’s components are displayed, select Cancel to close the Configurator page.

  7. Repeat steps 1 through 6 for each BOM Model that you want to import into the CZ schema.

Controlling the Data for Import

Controlling data import involves identifying or customizing what data gets imported.

To do this you run concurrent programs to set the values in the CZ_XFR_ control tables in the CZ schema that control import. See Control Tables for more information about the control tables. See Importing the Data for information about identifying what data gets imported.

Importing Data Into Specific Tables

When you import data, you must be aware of the dependencies between the import tables. For more information, see Dependencies Among CZ Schema Import Tables.

You may want to specify only a group of tables from which extracted data is loaded into the import tables. The CZ_XFR_TABLES.DISABLED field determines whether a specific table is enabled or disabled for import.

For general information on running concurrent programs, see Running Configurator Concurrent Programs. For details on importing data into specific tables, see Select Tables to be Imported.

In Oracle Applications, you can also display the current tables to be imported by selecting the concurrent program, Show Tables to be Imported. For more information, see Show Tables to be Imported.

Importing Data from Specific Fields

You can customize which fields in the tables listed in CZ_XFR_TABLES are extracted and imported. See the CZ eTRM on MetaLink, Oracle’s technical support Web site for more information about CZ_XFR_TABLES and other control tables.

There is no concurrent program to complete this customization. Modification of specific fields can only be accomplished by using SQL.

Populating Import Tables

The import tables below are listed in the order in which the concurrent programs and SQL*Plus import procedures populate them. This order must not be modified.

Modifying EXPLOSION_TYPE

You can modify the CZ_XFR_PROJECT_BILLS.EXPLOSION_TYPE field for previously imported bills to indicate how the BOM Model exploder should handle standard Items. The possible values for this field are OPTIONAL (default), ALL, or INCLUDED. The EXPLOSION_TYPE refers to whether the component is mandatory (ALL or INCLUDED) or optional (OPTIONAL). See the CZ eTRM on MetaLink, Oracle’s technical support Web site for more information about CZ_XFR_PROJECT_BILLS and other control tables.

Identifying a BOM Model for Import

CZ_XFR_PROJECT_BILLS.TOP_ITEM_ID is the Oracle Inventory identifier of the BOM Model imported into the CZ schema. Every imported BOM Model must be represented in CZ_XFR_PROJECT_BILLS.

The TOP_ITEM_ID and ORGANIZATION_ID for each imported BOM Model are read from the CZ_XFR_PROJECT_BILLS table. The PS_NODE import updates the CZ_XFR_PROJECT_BILLS table with the timestamp, ID, and description of the most recent import.

The ORGANIZATION_ID also identifies which BOM Models are imported. Oracle Configurator uses the ORGANIZATION_ID when adding a configured line Item in Order Management. An order line is only valid if it contains the ORGANIZATION_ID that corresponds to the ORGANIZATION_ID on BOM Model Items in Oracle Applications.

For detailed information about the control tables, see the CZ eTRM on MetaLink, Oracle’s technical support Web site.

Importing Decimal or Integer Quantities

During import, CZ_PS_NODES.DECIMAL_QTY_FLAG is set to 1 if all of the following conditions are true:

CZ_PS_NODES. DECIMAL_QTY_FLAG is set to false if the imported Model Item is an Option Class, the Standard Item’s parent is not an ATO Model, or the CZ: Populate Decimal Quantity Flags is set to No. Only Standard Items within ATO BOM Models support decimal quantities. Models, Option Classes and Standard Items within PTO BOM Models do not support decimal quantities.

You can specify whether Items are imported as integers or decimals using the profile option CZ: Populate Decimal Quantity Flags. The CZ: Populate Decimal Quantity Flags profile option specifies whether and how the MTL_SYSTEM_ITEMS.INDIVISIBLE_FLAG for an Item should determine the value of the DECIMAL_QTY_FLAG column in both CZ_ITEM_MASTERS and CZ_PS_NODES.

If you change the profile option from No to Yes, then you must refresh all existing Models so they reflect the decimal quantity setting for each Oracle Inventory Item. You must also republish any existing publications.

For general information about using CZ: Populate Decimal Quantity Flags, see the Oracle Configurator Installation Guide.

Warning: Not all Oracle Applications that are integrated with Oracle Configurator support decimal quantities for BOM Model Standard Items. Additionally, Oracle Configurator offers limited support for using decimal quantities. See specific product documentation and MetaLink to find out whether an application supports decimal quantities.

See the Oracle Configurator Developer User’s Guide for additional information on the impact of decimal quantities on configuration models and rules. For information about how decimal quantities affect the CIO, see the Oracle Configurator Extensions and Interface Object Developer’s Guide.

Importing Minimum and Maximum Instances

The first time a BOM Model is imported, the minimum and maximum Instance setting is 1. Subsequently, the BOM Model’s minimum and maximum Instance may be changed in Oracle Configurator Developer, but refreshing the BOM Model does not override the minimum and maximum Instance values. The minimum and maximum Instance settings can only be set on a referenced BOM Model, never on the root Model. Refreshing the BOM Model does update the Quantity. See Refreshing Imported Data for more information on refreshing Model data.

Importing the Data

Data can be imported into the CZ schema by:

If you are not importing from the same remote (import) server from which you originally imported the BOM Models, then you must synchronize your BOM-based configuration models with the BOM Models on the new import server. For more information, see Synchronizing Data.

Imported BOM Models are read-only in Oracle Configurator Developer, although you can add Properties, create additional Model structure, and define rules when defining your BOM-based configuration model.

See Importing a BOM Model That Contains Other BOM Models and the Oracle Configurator Developer User’s Guide for the specific results in Oracle Configurator Developer when importing BOM Models.

Verifying the Data Import

After you import data into the CZ schema, view the Item Master and updated Model(s) in Oracle Configurator Developer. All Items imported into the CZ schema are displayed in the Oracle Configurator Developer Item Master. All imported CDL rules are displayed in either the Model’s Configuration Rules folder or the folder that you specify in CZ_IMP_RULES.FOLDER_ID. All imported rules appear as Statement Rules. Imported BOM rules as mentioned in Inventory and BOM Data That Can Be Imported do not appear in the Model’s Configuration Rules folder. For more information on importing rules, see Rule Import.

The status of the import can be determined by examining the DISPOSITION field in the CZ_IMP tables. For more information about the DISPOSITION field see Import Control Fields.

Refreshing Imported Data

When changes are made in a production instance, it is necessary that the Models in the development instance be refreshed so that they reflect the changes. Refreshing configuration models only refreshes the data on the development CZ schema (target database instance).

Oracle Configurator’s Refresh All Imported Configuration Models concurrent program updates all configuration models in the development CZ schema with changes that have been made in the production CZ schema. When you refresh BOM Models that have submodels, all changes that were made in the BOM Model and its submodels are reflected in Oracle Configurator Developer.

The refresh concurrent programs ensure that existing production data, such as saved configuration data, is preserved. The procedures that perform the refresh prevent customer-specific groups of fields in the CZ schema from being altered or nulled out even when other fields in the row are replaced during a refresh request. After the Refresh All Imported Configuration Models or Refresh a Single Configuration Model concurrent program is run, the Models must be republished to the production CZ schema. See Publishing Configuration Models and the Oracle Configurator Developer User’s Guide for additional publishing information.

Warning: If you are using a separate development database, then you must never Generate Logic, Refresh or Create a User Interface, or run any schema maintenance scripts against a production database. Never use Oracle Configurator Developer for any development work on a production database.

Refreshing Imported Data Recommendations

Oracle recommends that you limit changes to the source data during construction of a configuration model to avoid potential problems introduced by interim data imports and updates. Oracle suggests that unit testing be completed before you import changes from Oracle Applications or legacy data, so that the test cases are up-to-date with the application that has been constructed. Your Model’s full system testing should include importing changed data and upgrading Oracle Configurator to match current enterprise or legacy data before deploying the runtime Oracle Configurator. Test cases may have to be updated to match the changes.

Although randomly updating imported data in the CZ schema during a development phase is not recommended, Oracle recognizes that project managers may need to synchronize with Oracle Applications data frequently. Refreshes and updates require careful control of what data gets imported. Likewise, corrections to the definitions of the configuration model in the runtime Oracle Configurator should be carefully controlled. A refresh may cause deletion of previously imported data. For example, if components are deleted from a BOM Model, they are also deleted from the configuration model during the next refresh. If components are added to the BOM Model, they are added to the configuration model during the next refresh. Oracle Configurator’s Disable/Enable Refresh of a Configuration Model concurrent program can be used to reduce the number of Models affected by a refresh by disabling or enabling specific configuration models. Oracle Configurator’s Refresh a Single Configuration Model concurrent program, updates the single imported BOM Model data in the CZ schema with changes that may have been made in the BOM Model.

Refreshing Procedures

If you are refreshing configuration models based on BOM Models that were previously imported from Oracle Bills of Material, you must:

  1. Ensure that the refresh of the configuration model is enabled (see Disable/Enable Refresh of a Configuration Model)

  2. Explode the BOM Models you want to import if you are not importing from the local server (see Exploding BOM Models in Oracle Applications)

  3. Run the appropriate refresh concurrent program (see Refresh a Single Configuration Model or Refresh All Imported Configuration Models)

After you refresh a BOM Model, all changes that were made in Oracle Bills of Material are reflected in Oracle Configurator Developer. For more information see the Oracle Configurator Developer User’s Guide.

Importing a BOM Model that Contains Other BOM Models

This section describes what exists in the CZ schema and is visible in Configurator Developer when you first import a BOM Model that contains other BOM Models from Oracle Bills of Material.

Example: Importing a BOM Model that Contains Other BOM Models

A BOM Model (B1) contains two child BOM Models (B2 and B3). Importing B1 results in three corresponding Models (M1, M2, and M3) in the CZ schema. All of these Models are visible in the Main area of the Configurator Developer Repository. Because B2 and B3 have child components in Oracle Bills of Material, M2 and M3 have corresponding children in Configurator Developer. See Initial Import of BOM Model with Submodels.

The Initial Import of BOM Model with Submodelsdiagram shows BOM Model B1 with children BOM Models B2 and B3. BOM Model B2 has children C1 and C2. BOM Model B3 has child C3. In Oracle Configurator Developer, Model M1 has References to Model M2 and Model M3. In Configurator Developer, Model M2 has two children, named C1 and C2. Model M3 has one child named C3.

Initial Import of BOM Model with Submodels

the picture is described in the document text

Refreshing a BOM Model that Contains Other BOM Models

This section explains what happens in Configurator Developer when you refresh a BOM Model in which the following changes have been made in Oracle Bills of Material:

BOM Model References Have Changed

Replacing one child BOM Model for another in a BOM Model causes the root Model to be refreshed as expected. However, the child Model that was previously referenced is no longer referenced, but remains in the Configurator Developer Repository.

BOM Model B1 no longer references BOM Model B3, but now references BOM Model B2 and a new BOM Model B4. B2 has been modified to contain C1 and C10 and no longer contains C2. The new BOM Model B4 contains C5 and C6. When you populate or refresh BOM Model B1 by running either the Populate Configuration Models or Refresh a Single Configuration Model concurrent program, the corresponding Models M1 and M2 are refreshed in Oracle Configurator Developer. Model M4 is created to correspond to BOM Model B4 and Model M3 remains unchanged. Populate and Refresh Modified BOM Model illustrates this result in Oracle Configurator Developer.

The Populate and Refresh Modified BOM Model diagram shows BOM Model B1 with children BOM Models B2 and B4. BOM Model B2 has child nodes C1 and C10. BOM Model B4 has child nodes C5 and C6. A refresh of the BOM Model B1 is reflected in Oracle Configurator Developer with Model M1 referencing Models M2 and M4. Model M2 is refreshed with child nodes C1 and C10. Model M3 is unchanged with child node C3. Model M4 is created with child nodes C5 and C6.

Populate and Refresh Modified BOM Model

the picture is described in the document text

BOM Models Referenced by Previously Imported BOM Model Have Changed

Modifying and refreshing a child BOM Model that is referenced by numerous parent Models in Oracle Configurator Developer may cause the logic and UI of those parent Models to become invalid.

Using the example presented in Import a New BOM Model with References to Existing BOM Models, you create BOM Model B6 in Oracle Bills of Material. BOM Model B6 references BOM Models B2 and B3. When you import BOM Model B6 by running the Populate Configuration Models concurrent program, a new corresponding Model M6 appears in Oracle Configurator Developer as well as updated versions of Models M2 and M3. Model M1 now references the updated Model M2.

The Import a New BOM Model with References to Existing BOM Models diagram shows BOM Model B6 with two child BOM Models B2 and B3. BOM Model B2 now has 3 child nodes C1, C10, and C12. BOM Model B3 has one child node C3. In Oracle Configurator Developer, Model M6 has references to Models M2 and M3. Oracle Configurator Developer has Model M2 refreshed with child nodes C1, C10, and C12. Model M3 is refreshed with child node C3. Model M1 is unchanged with references to the new refreshed Model M2 and Model M4 is unchanged in Oracle Configurator Developer.

Import a New BOM Model with References to Existing BOM Models

the picture is described in the document text

Models M1 and M6 both reference Model M2. When BOM Model B6 is imported into the CZ Schema, Model M2 is refreshed with a new child node C12. Model M1 is not refreshed. Importing Model M6 might create problems for Model M1 because the logic and UI may no longer be valid with the changes and updates. In this case, you must regenerate both the logic and the UI for Model M1.

If Model M1 was published before Model M2 was refreshed, then the runtime Oracle Configurator end user can still use Model M1 that references the original Model M2, as well as the publication of Model M6 that references the refreshed Model M2. This scenario is possible because the publishing process creates a copy of the configuration model at the time of publication.

For more information on publishing, see Publishing Configuration Models and the Oracle Configurator Developer User’s Guide.

BOM Model with a Common Bill

When a BOM Model that references a common bill is imported into the CZ schema, the imported BOM Model is available in the Main area of the Repository, but the common bill is not. When the imported BOM Model is opened in Configurator Developer, the components of the common bill appear as if the BOM was created with those components. The common bill is only available to the organization that imported the BOM Model. But when a common bill is imported directly (not as a reference), then the common bill is available to all organizations.

When you open the imported BOM Model for editing in the Structure area of the Workbench, the common bill’s components are visible and available, but there are no visual clues indicating that the components are from a common bill.

When a BOM Model with references to BOMs is imported, the import procedure warns that a referenced BOM is being imported. When a BOM Model with references to a common bill is imported, there is no warning that the referenced bill is a common bill. For general information about common bills, see the Oracle Bills of Material User’s Guide.

Rule Import

Configuration rules from legacy applications can be imported into the CZ schema. Before these rules can be imported into the CZ schema, they must be written in Constraint Definition Language (CDL) format. For information about writing rules in CDL format, see the Oracle Configurator Constraint Definition Language Guide. Rule Import Procedure identifies the necessary tasks for importing these rules.

All rules imported in CDL format appear as Statement Rules in Oracle Configurator Developer. For more information about Statement Rules, see the Oracle Configurator Developer User’s Guide.

Most types of rules can be written in CDL and imported into the CZ schema as Statement Rules:

You cannot write the following types of rules in CDL, and consequently you cannot import them into the CZ schema as Statement Rules:

Note: Rules cannot be imported from a remote database. The source and target tables must be in the same database instance.

Related Topics

Rule Import Procedure

Populating CZ_IMP_RULES

The following fields must be populated in the CZ_IMP_RULES table before you can run the Import Configuration Rules concurrent program.

You should not populate the following fields in the CZ_IMP_RULES table:

For more information about the CZ_IMP_RULES table, see the CZ eTRM on MetaLink, Oracle’s technical support Web site.

Related Topics

Rule Import Procedure

Populating CZ_IMP_LOCALIZED_TEXTS

Multiple Language Support data for rule violations and unsatisfied messages are stored in the CZ_IMP_LOCALIZED_TEXTS table. A single rule may have several records in the CZ_IMP_LOCALIZED_TEXTS table. If a rule has multiple translations, then there must be a record in CZ_IMP_LOCALIZED_TEXTS for each translation. All translation records for a single rule must have the same ORIG_SYS_REF.

For information on Multiple Language Support, see Multiple Language Support, the Oracle Configurator Installation Guide, Oracle E-Business Suite Installation Guide: Using Rapid Install, and Oracle E-Business Suite Concepts.

After you have created your CDL rule, you must populate the following fields in CZ_IMP_LOCALIZED_TEXTS table before running the Import Configuration Rules concurrent program.

You should not populate the following fields in the CZ_IMP_LOCALIZED_TEXTS table:

For more information about the CZ_IMP_LOCALIZED_TEXTS and CZ_INTL_TEXTS tables, see the CZ eTRM on MetaLink, Oracle’s technical support Web site.

Related Topics

Rule Import Procedure

Rule Import Tables

Every imported rule in CZ_IMP_RULES has a corresponding record in the CZ_RULE_FOLDER. The imported rule is linked to the specified Model’s (DEVL_PROJECT_ID) Configuration Rules folder.

Tables for Importing Rules describes the CZ tables that are used when importing rules.

Tables for Importing Rules
Table Name Description
CZ_IMP_RULES The source rule’s data that is imported into the CZ_RULES in the CZ schema. The following columns are used when importing rules do not appear in the CZ schema:

  • MESSAGE - Is the error message if a rule is rejected during import. The rejection of a rule does not terminate the rule import request. A rejected rule is imported into the CZ schema.

  • RUN_ID - Is theParameter for the Import Configuration Rules Concurrent Program. It is a generated number when the RUN_ID is not specified.

  • DISPOSITION - Is the result of processing the rule in the stage specified in REC_STATUS. For more information, see Stages of Rule Import .

  • REC_STATUS - Is the stage that the rule has been processed. For more information, see Stages of Rule Import .

  • IMPORT_PROG_VERSION - Is the version of the import program that is used for importing data. The default value is 1.0.
CZ_IMP_LOCALIZED_TEXTS The rule’s translation data that is imported into the CZ schema. The following columns are used when importing rules and do not appear in the CZ schema:

  • MESSAGE - Is the error message if a rule is rejected during import. The rejection of a rule does not terminate the rule import request. A rejected rule is imported into the CZ schema.

  • RUN_ID - Is theParameter for the Import Configuration Rules Concurrent Program. It is a generated number when the RUN_ID is not specified.

  • DISPOSITION - Is the result of processing the rule in the stage specified in REC_STATUS. For more information, see Stages of Rule Import .

  • REC_STATUS - Is the stage that the rule has been processed. For more information, see Stages of Rule Import .

  • IMPORT_PROG_VERSION - Is the version of the import program that is used for importing data. The default value is 1.0.

Stages of Rule Import

Each rule goes through three processing stages before it is imported into the CZ schema. The rule’s processing stage is tracked in CZ_IMP_RULES.REC_STATUS and CZ_IMP_LOCALIZED_TEXTS.REC_STATUS. The result of each processing stage is tracked in CZ_IMP_RULES.DISPOSITION and CZ_IMP_LOCALIZED_TEXTS.DISPOSITION. For more information about REC_STATUS and DISPOSITION during rule import, see Import Control Fields.

After all rules have been processed, the rules that have REC_STATUS=XFR and DISPOSITION = I or M are parsed.

Related Topics

Rule Import Procedure

Rule Validation

During rule import, the following fields are checked. If the field meets the criteria stated below, then an error message is stored in CZ_IMP_LOCALIZED_TEXTS.MESSAGE.

Rule Import Procedure

Importing rules into the CZ schema consists of the following steps:

  1. Write the rule in CDL format.

  2. Verify that the Model associated with the rule exists in the CZ schema. Note the Model’s DEVL_PROJECT_ID. The DEVL_PROJECT_ID is used when you populate the CZ_IMP_LOCALIZED_TEXTS and CZ_IMP_RULES tables.

  3. Populate the CZ_IMP_RULES table. See Populating CZ_IMP_RULES for a list of fields that must be populated for each rule.

  4. Populate the CZ_IMP_LOCALIZED_TEXTS table. See Populating CZ_IMP_LOCALIZED_TEXTS for a list of fields that must be populated for each rule.

  5. Run the Import Configuration Rules concurrent program.

    The Import Configuration Rules concurrent program validates the rules and stores the CDL format in the Rules subschema. Rule Validation lists the fields that are examined when validating a rule during rule import.

    For more information about the concurrent program, see Import Configuration Rules.

  6. Edit the rules that had parsing errors as reported in the concurrent program log file.

    All rules processed by the Import Configuration Rules concurrent program are imported into the CZ schema regardless of whether they have parsing errors. Once the rules are in the CZ schema, they can be edited in Configurator Developer or in the legacy environment and then refreshed.

    Warning: If a rule is edited in both the legacy environment and the Configurator Developer environment and you refresh the rule, then the refreshed rule overwrites any changes that may have been made to the rule in the Developer environment.

Custom Import

A custom import is required for importing data not handled by a standard import, including legacy data from non-Oracle Applications databases. See Standard Import to determine whether your data requires a custom data import. This section describes:

Overview of Custom Data Import

Both the standard and custom data import processes use the import tables in the CZ schema to populate the online tables. However, while data extraction for a standard import is handled by the Populate and Refresh Configuration Models Concurrent Programs, a custom import requires custom extraction, transfer, and load into the import tables. Comparison of Custom and Standard Data Import shows where in the process the two kinds of data import are different.

The Comparison of Custom and Standard Data Import shows that when doing a custom import, custom load programs load the data into the CZ schema import tables and then the data is imported into the CZ schema online tables. Importing from Oracle Applications the data from Inventory and BOM schemas is copied to the CZ import and online schemas.

This figure also shows the comparison of the custom import processes and the processes when importing a BOM Model from the Oracle Applications.

Comparison of Custom and Standard Data Import

the picture is described in the document text

When importing data not handled by a standard import, especially non-Oracle legacy data, the data must be custom loaded into the import tables. Custom programs then populate the online tables with the extracted data. The data that is imported depends on the settings in the control tables (CZ_XFR_ tables in the CZ schema) and the custom load program, if applicable. See Custom Import Procedure for information about performing a custom import.

After successfully importing any legacy data needed for modeling new configurations, Oracle recommends that you unit test your configuration model before transferring new or updated model data. Unit testing configuration models is performed in the Oracle Configurator Developer. See the Oracle Configurator Developer User’s Guide for more information.

Identifying Data for a Custom Data Import

The following tables can be populated through a custom import:

Minimally, the following tables are used for custom import and should be selected when you run the Select Tables To Be Imported concurrent program:

To know what data to extract for populating the import tables, you need to know what fields are available in the import tables for data population. See the CZ eTRM on MetaLink, Oracle’s technical support Web site, for detailed information about all import table fields. See also Dependencies Among CZ Schema Import Tables, for information about the dependencies among the import tables.

As with a standard data import, you can further control the data populating the online tables by using the control tables (CZ_XFR_). See Controlling the Data for Import for details.

Custom import programs should consider the setting of QUOTEABLE_FLAG in the CZ_PS_NODES table. This flag determines whether or not the OC Servlet’s UI Server displays a particular Item in the Configuration Summary page. For more information about the Summary page see the Oracle Configurator Developer User’s Guide.

Required ASCII File Format for Custom Import

The format of the data transfer files must exactly match the target import tables, field for field. The data transfer files include all data in text (ASCII) format, with fields separated by delimiters such as a vertical bar (|).

Data Transfer File Format shows a data transfer file that imports Item types.

Data Transfer File Format

||Memory Board|||||||||||||||||||
||Dual CPU|||||||||||||||||||
||Country|||||||||||||||||||
||System Console|||||||||||||||||||
||Server Console|||||||||||||||||||
||Disk Drive|||||||||||||||||||
||Storage Media|||||||||||||||||||
||Server Size|||||||||||||||||||
||Power Supply|||||||||||||||||||
||Matrix Printer|||||||||||||||||||
||SCSI Disk Drive|||||||||||||||||||
||Cache Memory|||||||||||||||||||
||Disk Array Model|||||||||||||||||||
||SCSI Type|||||||||||||||||||
||SCSI Cable|||||||||||||||||||
||SCSI Chaining|||||||||||||||||||
||SCSI Cabling Configuration|||||||||||||||||||
||Server Type|||||||||||||||||||
||System Size|||||||||||||||||||

Loading Property Values by Type

When preparing source data for custom import, your custom load programs should place Property data values into the import tables according to their data type. The CZ_IMP tables provide separate columns for numeric and non-numeric Property values, and for default values.

The table Columns for Imported Property Values shows which column to load Property values into, depending on the data type of the value.

Columns for Imported Property Values
Data Type If CZ_IMP_PROPERTY.DATA_TYPE is... Load default Property value into CZ_IMP_PROPERTY column ... Load value on the Item into CZ_IMP_ITEM_PROPERTY_VALUE column ...
integer 1 DEF_NUM_VALUE PROPERTY_NUM_VALUE
decimal 2 DEF_NUM_VALUE PROPERTY_NUM_VALUE
Boolean (values are 0 or 1) 3 DEF_NUM_VALUE PROPERTY_NUM_VALUE
text 4 DEF_VALUE PROPERTY_VALUE

Custom Import Procedure

To import data that is not handled by a standard import:

  1. Identify and cleanse data for import.

  2. Create and run custom extraction programs for the data you want to import.

    Creating a custom extraction program

    1. Write queries to extract the data into the required data transfer file format required by the import tables.

    2. Optionally create an ASCII file in that data transfer (DAT) format (see Required ASCII File Format for Custom Import).

    3. Write a load program that loads the data transfer file into the import tables, or loads the queried data directly into the import tables in the format required.

  3. Optionally set up the CZ control tables to customize the transfer of data (see Controlling the Data for Import).

  4. Run the cz_modeloperations_pub.import_generic PL/SQL procedure. For more information see IMPORT_GENERIC.

  5. Verify your import as described in Verifying the Data Import.