Skip Headers

Oracle Configurator Implementation Guide
Release 12.1 for
Part Number E14322-03
Go to Table of Contents
Go to previous page
Go to next page

Database Instances

This chapter describes the uses to which databases are put when implementing Oracle Configurator, and specifics about using multiple database instances.

This chapter covers the following topics:


Whether your implementation project uses a single or two separate Oracle Applications database instances, the database serves multiple purposes during an Oracle Configurator implementation. The topics in this chapter include:

For details about the CZ schema within an Oracle Applications database instance, see Configurator Architecture and The CZ Schema.

Database Uses

During an Oracle Configurator implementation, the Oracle Applications database is used for:

During an Oracle Configurator implementation and deployment, Oracle supports using either a single database instance for all operations, or multiple development instances and one production instance.

The Single Database Environment illustration shows that a single database environment can be used to import Oracle Application data into the CZ schema , as well as publish and synchronize data.

Single Database Environment

the picture is described in the document text

A publication’s details and applicability parameters determine a configuration model’s unique deployment. For more information on deploying a configuration model, see Publishing Configuration Models.

To support Oracle Configurator implementations on separate development and production database instances, Oracle provides the means for moving and synchronizing data across the instances. For more information about moving data, seePopulating the CZ Schema and Migrating Data. For more information about synchronizing data, see Synchronizing Data.

For more information about implementing Oracle Configurator in two separate database instances, see Multiple Database Instances.

Multiple Database Instances

Once a configuration model is deployed, separate database instances can ensure that maintenance or instabilities in the operations of the development database instance do not interfere with end-user access or ongoing maintenance of the application that is in production use.

Note: Publishing Models from more than one development instance to the same production instance can cause unresolvable problems with data synchronization.

Although the following operations can be accomplished on a single database instance, they commonly involve separate development and production database instances:

When working with multiple database instances, the instances in which the user runs Oracle Configurator Developer to create and develop models, are the local or source database instances. The database instance to which Models are published and used in production is the remote or target database instance.

Model Availability on Multiple Database Instances

Although it is possible to implement and deploy Oracle Configurator using only one database instance, many projects use multiple database instances to distinguish between Model development and production use. Models can be copied into multiple development instances. Copying Models from any instance to a development instance is known as migrating Models. Models are published to a production instance, but should not be migrated to a production instance.

Once a Model is migrated, its structure, rules and User Interfaces can be uniquely expanded in each development instance. A single Model from a designated instance is then published to the production environment. See Migrating Models for more information.

The illustrationTwo Database Environments shows that a production database is used to import Oracle Application data into a development database. After creating rules, UIs, and extending the Model structure, the Model is published to the production database. Synchronization is done from the development database with the production database.

Two Database Environments

the picture is described in the document text

The Multiple Database Instances illustration shows Oracle Application data can be imported from a production database to development databases. It also shows that Models can be migrated from one development database to another. After creating rules, UIs, and extending the Model structure, the Model is published to the production database. Synchronization is done from the development database with the production database.

Multiple Database Instances

the picture is described in the document text

See Synchronizing Migrated Model Data for information on synchronizing a migrated Model's data.

See Migrating Models for scenarios using separate development and production database instances.

Import Source and Target

To develop a BOM-based configuration model, BOM Model data must be imported into the CZ schema. The imported data used to develop a runtime Oracle Configurator should be production data. The production database serves as the import source. The development instance serves as the import target. For information about data import, see Populating the CZ Schema.

Publication Source and Target

Configuration models must be published from the development database instance to be available for system testing or production use in the same or a different database. You can delete publications on the target instance from Oracle Configurator Developer. See the Oracle Configurator Developer User’s Guide for additional publishing information. For information about publishing, see Publishing a Configuration Model.

Oracle strongly recommends that all source and target instances which participate in publishing be located on the same local area network. When publishing over a wide area network, performance can be degraded by network factors.

If you change the publication source or target (by running the Modify Server Definition concurrent program) or use a cloned source or target, then you must synchronize the publication data. See Synchronizing Data. If the BOM Model data changes in Oracle Bills of Material, or you modify the Model structure or UI in Configurator Developer, then you must republish the Model.

A previously defined remote publishing target instance can be converted to a development instance. See Converting a Remote Target to a Development Instance. For information about what happens to existing publications when a remote target is converted to a development instance, see Source and Remote Publications.

Decommissioning a Database Instance

Decommissioning a production database instance (target) causes synchronization problems. For more information on synchronization, see Synchronizing Data.

Migration Source and Target

When you need to move your Configurator implementation or deployment from one database instance to another, you may need to migrate configuration model data. The instance where the Model is migrated from is referred to as the source instance. The instance where the Model is migrated to is referred to as the target instance. For more information about migration, see Migrating Data.

Note: The installed languages must be the same on both the source and target instances.

For migration source and target patch level information, see the current release or patch information for Oracle Configurator on MetaLink, Oracle's technical support Web site.

BOM Synchronization Source and Target

In cases where the import source or publication target change, it may be necessary to synchronize the BOM-based configuration model with the corresponding production BOM. For more information about BOM synchronization, see Synchronizing Data.

Linking Multiple Database Instances

When creating an empty database or repurposing an existing one to serve as a source or target of data operations across two database instances, the databases must be linked. Defining and enabling the remote server sets up the necessary database links between the source and target databases.

See Server Administration for general information on setting up database links. For details on running the concurrent programs, see Define Remote Server, and Enable Remote Server.

Instance and Host System Names

Multiple database instances can exist on a single or separate host systems. Both the database instance and the host system have a name. The name of the database instance and host system are relevant in all the uses listed in Reasons for Multiple Database Instances.

In this book, the database instance you are connected to or logged into is the local or current database instance, and the local system is the local host. Other instances, whether on the local host system or a different remote system, are remote instances in relation to the local instance.

The local database instances can serve as:

Remote database instances can serve as:

The SID is used to identify the database instance that Oracle Configurator Developer uses. The database instance name is also known as the local name. The database instance and host names are required in various places for the correct operation of Oracle Configurator Developer, the CZ schema, and Configurator concurrent programs. The SID is specified during Rapid Install. For more information, see the Oracle E-Business Suite Installation Guide: Using Rapid Install guide.

Model Development

A development database instance is one in which you create your configuration model using Configurator Developer.

Note: There may be multiple development database instances. Configuration models that are available to end users should only be published from a single development environment. Publishing Models from multiple development instances to a single test or production instance could result in:

Unit testing is initiated from Configurator Developer by launching either the Model Debugger or a generated User Interface. Unit testing enables the implementer to test configuration rules and UI functionality in the development database instance. Unit testing ensures that rules and UI modifications work as desired. For additional information, see the Oracle Configurator Developer User’s Guide.

When you upgrade the release version of Oracle Configurator that your runtime Oracle Configurator runs against, you start by upgrading the CZ schema. For information about updating your CZ schema, see the Oracle Configurator Installation Guide.


Oracle Configurator data is maintained in the maintenance environment. A maintenance environment is similar to a development environment because it requires many of the same operations such as upgrading the CZ schema, refreshing configuration data, fixing and improving configuration models, and periodically republishing the models. It is important to synchronize any changes in the maintenance database instance with the development database instance for the next release of your runtime Oracle Configurator. For more information on synchronization, see Synchronizing Data.


A production environment is one in which runtime Oracle Configurator end users use the software in a production mode. The production environment is also used for system testing.

System Testing

The system testing environment is generally the production environment and used to verify that data transfers and modifications in a deployed scenario work as desired. For example, changes to the Model structure in Oracle Configurator Developer should propagate to the host application such as Order Management.

System testing includes publishing the configuration model and UI, accessing it using at least one host application, and specifying various effective dates. System testing tests:

Deploying a Model

To prepare for deploying the configuration model to your production environment, you must consider integration with other applications, perform unit testing, and system testing. For additional information see the Oracle Configurator Developer User’s Guide.

If the development database and the production database are not on the same machine, then the production database server must be defined and enabled. For more information on defining a remote server, see Define Remote Server.

Before you publish the configuration model, purging records flagged for deletion results in a more efficient use of computer resources. For more information about purging records, see Purging Configurator Tables.

For information about publishing a configuration model to a production CZ schema, see Publishing Configuration Models.

Converting a Publication Target Instance to a Development Instance

A publication target instance can be converted to a development instance. Once a remote target instance is converted to a development instance, it can no longer be specified as a remote instance for publishing. The converted instance can be used to publish locally. For more information, see the Convert Publication Target Instance to Development Instance concurrent program.

Note: Converting a publication instance to a development instance does not change any existing published data.