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:
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.
Populating the CZ schema usually begins by importing data. There are three types of data import:
Standard import of Oracle Applications BOM Models and Inventory data into the CZ schema. For more information, see Standard Import.
Rule import of legacy rules written in Constraint Definition Language (CDL) format into the CZ schema. For more information, see Rule Import.
Custom import of data that is not handled by a standard import. For more information, see Custom 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:
The data stored in the CZ schema includes:
Configuration models:
Item and Model structure data
Configuration rules
Customized User Interface (UI) Templates
UI definitions
Publication records
Configurations
Configurator Extension Archives
Oracle Configurator system settings
Oracle Configurator transfer information
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.
The CZ schema is populated with data by the following means:
Concurrent programs in Oracle Applications import Item and Model structure data from outside sources into the CZ schema. For more information on preparing data for import, see Preparing the Data for Import. For more information, see Populate and Refresh Configuration Models Concurrent Programs.
Note: When you submit an Oracle Applications concurrent request to populate and refresh Models, the Model, any referenced Models, and any referenced UI Content Templates must either be unlocked or locked by you. For more information on locking, see the Oracle Configurator Developer User’s Guide.
A concurrent program in Oracle Applications imports rules written in CDL format into the CZ Schema. These rules may be legacy rules that are rewritten in CDL. For more information on preparing rules for import, see Rule Import Procedure. For more information about the concurrent program, see Import Configuration Rules.
Custom programs load data transfer files into the CZ schema. For more information see Identifying Data for a Custom Data Import.
Concurrent programs migrate Item and Model structure data from one CZ schema into another CZ schema. For more information, see Migrating Data and Migration Concurrent Programs.
Configurator Extensions populate CZ table fields with configuration data that cannot be directly inserted using the runtime Oracle Configurator. For more information, see the Oracle Configurator Extensions and Interface Object Developer’s Guide, and Migrate Functional Companions.
End users select certain nodes of configuration models that pass configuration attributes to the CZ schema. For more information, see the Oracle Configurator Methodologies documentation.
Oracle Configurator Developer populates the CZ schema with configuration model data, including rule, publishing, and UI definitions. For more information on the information in the CZ schema, see the CZ eTRM on MetaLink, Oracle’s technical support Web site.
Programmatic tools used to develop and maintain configuration models, and deploy a runtime Oracle Configurator populate the CZ schema. For more information, see Programmatic Tools for Development and Programmatic Tools for Maintenance.
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.
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
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:
A standard import involves importing Oracle Applications Inventory and BOM Model data into the CZ schema. Specifically, the imported data is:
Inventory data
Attributes in Oracle Inventory such as Item Catalog Group, Catalog Descriptive Elements and values
The overall procedure for a standard import is:
Determine the import source and target (see Database Instances)
Prepare the data (see Preparing the Data for Import).
If the import source is a remote database:
The Configurator Administrator must define and enable the source server for import (see Defining and Enabling a Server for Import).
Explode the BOM Models that you want to import (see Exploding BOM Models in Oracle Applications).
Optionally identify specific data to be ignored during the import (see Controlling the Data for Import).
Run the Populate and Refresh Configuration Models Concurrent Programs in Oracle Applications to import the BOM Model’s data into the CZ Schema.
Verify that the data import succeeded (see Verifying the Data Import).
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).
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.
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.
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).
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:
Define the Items of your BOM Model and specify a BOM Item Type of Standard, Option Class, or Model for each Item.
Select the Inventory Item check box to make each Item both configurable and orderable.
Select the BOM Allowed check box if the Item can be assigned as a component on a BOM Model or can be used to create a BOM Model.
Assign Item Catalog Groups and Descriptive Elements to Items for which you want imported Properties in Configurator Developer.
Indicate whether the Items that you want to be a BOM Model are a Pick To Order (PTO) or Assemble To Order (ATO).
Select the OM Indivisible check box if Item quantities should be treated as integers (see Importing Decimal or Integer Quantities).
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.
After defining Inventory Items, you must continue in Bills of Material to create the BOM Model.
Select an Inventory Item that has a BOM Item Type of Model, and add other BOM Models, Option Class Items, and Standard Items as components within the BOM Model.
In a multiple organization supply chain implementation, set the Item attributes Check ATP and ATP Components to control the extent of the search made by Global Order Promising for available-to-promise inventory.
For more information about the Check ATP and ATP Components settings, see the Oracle Advanced Supply Chain Planning and Oracle Global ATP Server User’s Guide.
Specify attributes for each component in the bill, such as whether a BOM Model or BOM Option Class contains Mutually Exclusive Items and whether the component is required.
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.
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.
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.
To explode a BOM Model in Oracle Applications, Release 12:
Log in to Oracle Applications using the appropriate username and password.
Select Orders, Returns > Sales Orders.
Enter all required data in the Main tabbed region.
Click the Line Items tabbed region.
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.
Enter 1 in the Qty field, then click Configurator.
After all the BOM Model’s components are displayed, click Cancel to close the Configurator page.
To explode a BOM Model in Oracle Applications, Release 10.7 or 11.0:
Log in to Oracle Applications using the appropriate username and password.
Select the Order Entry responsibility.
Navigate to the Sales Orders page, enter all required fields.
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.
Enter 1 in the Qty field, then click Configurator.
After all the BOM Model’s components are displayed, select Cancel to close the Configurator page.
Repeat steps 1 through 6 for each BOM Model that you want to import into the CZ schema.
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.
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.
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.
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.
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.
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.
During import, CZ_PS_NODES.DECIMAL_QTY_FLAG is set to 1 if all of the following conditions are true:
The BOM Model component is a Standard Item (CZ_IMP_PS_NODES.BOM_ITEM_TYPE=4 or CZ_PS_NODES.PS_NODE_TYPE=438)
The corresponding Oracle Inventory Item has MTL_SYSTEM_ITEMS.INDIVISIBLE_FLAG=’N’ or ’NULL’
The Model containing the Standard Item is an ATO Model (that is, CZ_DEVL_PROJECTS.MODEL_TYPE=’A’)
The profile option CZ: Populate Decimal Quantity Flags is set to 1 (Yes)
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 the profile option is set to No, then import populates the DECIMAL_QTY_FLAG column in both CZ_ITEM_MASTERS and CZ_PS_NODES with a value of 0.
If the profile option is set to Yes, then the value of MTL_SYSTEM_ITEMS.INDIVISIBLE_FLAG for an Item determines the value of the DECIMAL_QTY_FLAG column in both CZ_ITEM_MASTERS and CZ_PS_NODES.
If INDIVISIBLE_FLAG is 0 or NULL, then DECIMAL_QTY_FLAG in both tables is set to 1, which means that decimal quantities are allowed.
If INDIVISIBLE_FLAG is 1, then DECIMAL_QTY_FLAG in both tables is set to 0, which means that decimal quantities are not allowed. The minimum, maximum, and quantity are rounded during import. If the result of the rounding causes the minimum to be greater than the default or the maximum, then an error is returned.
If INDIVISIBLE_FLAG is 0 and a node cannot support decimal quantities based on the new restrictions, then any decimal values that occur in a BOM Model are rounded. This includes child Models and Option Classes within PTO Models.
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.
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.
Data can be imported into the CZ schema by:
Running the Populate and Refresh Configuration Models Concurrent Programs in Oracle Applications. These concurrent programs import BOM Model structure (ATO, PTO Models, structure and rules) and require that the BOM Models be complete and identified at the specified root. For more information, see Populate and Refresh Configuration Models Concurrent Programs.
Running the Import Configuration Rules concurrent program in Oracle Applications. This concurrent program imports rules written in CDL format into the CZ schema. For more information about rule import, see Rule Import.
Customizing your data import to run or suppress the transfer of some data. For more information, see Controlling the Data for Import.
Running the PL/SQL IMPORT_SINGLE_BILL procedure. For more information, see in Procedures and Functions in the CZ_modelOperations_pub Package.
Running the PL/SQL REFRESH_SINGLE_MODEL procedure. For more information, see Procedures and Functions in the CZ_modelOperations_pub Package.
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.
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.
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.
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.
If you are refreshing configuration models based on BOM Models that were previously imported from Oracle Bills of Material, you must:
Ensure that the refresh of the configuration model is enabled (see Disable/Enable Refresh of a Configuration Model)
Explode the BOM Models you want to import if you are not importing from the local server (see Exploding BOM Models in Oracle Applications)
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.
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
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:
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
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
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.
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.
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:
Logic rules
Numeric contribution and consumption rules
Comparison rules
Property-based Compatibility rules
You cannot write the following types of rules in CDL, and consequently you cannot import them into the CZ schema as Statement Rules:
Explicit Compatibility rules
Design Charts
Note: Rules cannot be imported from a remote database. The source and target tables must be in the same database instance.
Related Topics
The following fields must be populated in the CZ_IMP_RULES table before you can run the Import Configuration Rules concurrent program.
ORIG_SYS_REF: A user-defined character string that identifies the rule as an imported rule.
NAME: The name of the rule with a maximum of 255 characters
RULE_FOLDER_ID: A number that identifies where the rule information is stored in CZ_RULE_FOLDERS. If this field is null, then the rule is stored in the Model’s Configuration Rules folder.
Once a rule is imported into the Model’s Configuration Rules folder, you can move the rule to another rule folder associated with the Model.
Note: If you move a rule to another rule folder, then you must specify the RULE_FOLDER_ID when you refresh the rule. If you do not specify the RULE_FOLDER_ID, then the refreshed rule will be moved into the Model’s Configuration Rules root folder.
DEVL_PROJECT_ID: The numeric identifier of the Model that is associated with the rule. This is a foreign key into CZ_DEVL_PROJECTS. DEVL_PROJECT_ID and must be the same number as CZ_IMP_LOCALIZED_TEXTS.MODEL_ID.
RULE_TEXT: The actual CDL rule text
RULE_TYPE: The numeric identifier of the type of rule. The imported rule is a Statement Rule and the RULE_TYPE is 200.
You should not populate the following fields in the CZ_IMP_RULES table:
AMOUNT_ID
ANTECEDENT_ID
CHECKOUT_USER
CLASS_NAME
COMPONENT_ID
CONSEQUENT_ID
CREATED_BY
CREATION_DATE
DISPOSITION - See Import Configuration Rules for additional information
EFF_FROM
EFF_MASK
EFF_TO
EXPR_RULE_TYPE
FSK_COMPONENT_ID
FSK_DEVL_PROJECT
FSK_LOCALIZED_TEXT_2
FSK_MODEL_REF_EXPL_ID
GRID_ID
IMPORT_PROG_VERSION
INSTANTIATION_SCOPE
INVALID_FLAG
LAST_UPDATED_BY
LAST_UPDATE_DATE
LAST_UPDATE_LOGIN
MESSAGE
MODEL_REF_EXPL_ID
MUTABLE_FLAG
PERSISTENT_RULE_ID
PRESENTATION_FLAG
REASON_ID
REC_STATUS - See Import Configuration Rules for additional information.
RULE_FOLDER_TYPE
RULE_ID
SEEDED_FLAG
SEQ_NBR
SIGNATURE_ID
SUB_CONS_ID
TEMPLATE_PRIMATIVE_FLAG
TEMPLATE_TOKEN
UI_DEF_ID
UI_PAGE_ID
UI_PAGE_ELEMENT_ID
UNSATISFIED_MSG_ID
For more information about the CZ_IMP_RULES table, see the CZ eTRM on MetaLink, Oracle’s technical support Web site.
Related Topics
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.
ORIG_SYS_REF: A user-defined character string that identifies the rule as an imported rule.
LANGUAGE: The language code that is associated with the rule.
SOURCE_LANG: The language code of the LOCALIZED_STR field.
MODEL_ID: The DEVL_PROJECT_ID of the Model associated with the rule. The MODEl_ID must be the same number as CZ_IMP_RULES.DEVL_PROJECT_ID.
LOCALIZED_STR: The rule’s translated text.
You should not populate the following fields in the CZ_IMP_LOCALIZED_TEXTS table:
CHECKOUT_USER
CREATED_BY
CREATION_DATE
DISPOSITION - See Import Configuration Rules for additional information.
EFF_FROM
EFF_MASK
EFF_TO
INTL_TEXT_ID
LAST_UPDATED_BY
LAST_UPDATE_DATE
LAST_UPDATE_LOGIN
LOCALE_ID
MESSAGE
SEEDED_FLAG
REC_STATUS - See Import Configuration Rules for additional information.
FSK_DEVL_PROJECT_1_1
IMPORT_PROG_VERSION
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
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.
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:
|
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:
|
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
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.
CZ_IMP_LOCALIZED_TEXTS.ORIG_SYS_REF is null or belongs to a different Model
CZ_IMP_LOCALIZED_TEXTS.LANGUAGE is null
CZ_IMP_LOCALIZED_TEXTS.MODEL_ID - is null or refers to an invalid Model.
CZ_IMP_LOCALIZED_TEXTS.SOURCE_LANG is null
CZ_IMP_RULES.ORIG_SYS_REF is null
CZ_IMP_RULES.NAME is null
CZ_IMP_RULES.MODEL_ID is null or refers to an invalid Model
Importing rules into the CZ schema consists of the following steps:
Write the rule in CDL format.
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.
Populate the CZ_IMP_RULES table. See Populating CZ_IMP_RULES for a list of fields that must be populated for each rule.
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.
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.
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.
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:
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
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.
The following tables can be populated through a custom import:
CZ_DEVL_PROJECTS
CZ_INTL_TEXTS
CZ_ITEM_MASTERS
CZ_ITEM_PROPERTY_VALUES
CZ_ITEM_TYPES
CZ_ITEM_TYPE_PROPERTIES
CZ_LOCALIZED_TEXTS
CZ_PROPERTIES
CZ_PS_NODES
Minimally, the following tables are used for custom import and should be selected when you run the Select Tables To Be Imported concurrent program:
CZ_ITEM_MASTERS
CZ_ITEM_TYPES
CZ_ITEM_TYPE_PROPERTIES
CZ_ITEM_PROPERTY_VALUES
CZ_PROPERTIES
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.
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.
||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|||||||||||||||||||
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.
To import data that is not handled by a standard import:
Identify and cleanse data for import.
Create and run custom extraction programs for the data you want to import.
Creating a custom extraction program
Write queries to extract the data into the required data transfer file format required by the import tables.
Optionally create an ASCII file in that data transfer (DAT) format (see Required ASCII File Format for Custom Import).
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.
Optionally set up the CZ control tables to customize the transfer of data (see Controlling the Data for Import).
Run the cz_modeloperations_pub.import_generic PL/SQL procedure. For more information see IMPORT_GENERIC.
Verify your import as described in Verifying the Data Import.