Oracle Configurator Implementation Guide Release 12.1 for Part Number E14322-03 | ![]() Contents | ![]() Previous | ![]() Next |
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.
During an Oracle Configurator implementation, the Oracle Applications database is used for:
Migrating or importing data into the CZ schema
Running Oracle Configurator Developer to create configuration models
Unit and system testing configuration models
Publishing configuration models
Running a production Oracle Configurator
Storing Items, BOM Models, and saved configurations
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.
Development instances can serve as:
Import target
Publication source and target
CZ schema migration source and target
Model migration source and target
BOM Model synchronization source or target
Production instances can serve as:
Import source
Publication target
Migration source
BOM Model synchronization source
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.
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.
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:
Importing or migrating data from a production database instance into the development CZ schema
Publishing configuration models from a development instance to a production CZ schema
System testing configuration models in a production database instance
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.
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.
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.
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.
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.
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 production database instance (target) causes synchronization problems. For more information on synchronization, see Synchronizing Data.
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.
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.
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.
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:
Target database for data migration
Target database for data import
Source database for publishing configuration models
Original database for creating a clone
Remote database instances can serve as:
Source database for data migration
Source database for data import
Target database for publishing configuration models
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.
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:
Publications with overlapping applicability parameters
Multiple development environments leading to confusing publication history. Publication history is maintained on the development environment.
Overwriting a configuration model’s snapshot of its Item Master. When a configuration model is published, the publication has a snapshot of the development environment’s Item Master. If a configuration model is published from a different development environment, then the snapshot of its Item Master overwrites the original Item Master.
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.
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:
Performance of the configuration model
End-user access
Security
Integration customizations
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.
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.
Copyright © 1999, 2010, Oracle and/or its affiliates. All rights reserved.