This chapter covers the following topics:
Oracle Configurator Developer is an Oracle Applications product that enables you to rapidly develop a configuration model and a configurator. Configuration model is defined in What is a Configuration Model.
A configurator is the part of an application that provides custom configuration capabilities. A configurator is usually launched from a host application, such as Oracle Order Management or iStore, and displays the selected configuration model to the end user. During an Oracle Configurator session, an end user makes selections and specifies requirements for the product or service being configured. At the end of a configuration session, the Oracle Application dialog page is displayed before the host application returns to the foreground. Oracle Configurator collects the customer’s requirements and, using the Model definition and rules you defined in Configurator Developer, ensures that the end user creates a valid configuration.
A configurator can be thought of as a selling tool. The Model bill serves as a guide to selecting configuration options. A configuration created during an Oracle Configurator session is based on an already existing Model bill and results in a standard manufacturing bill of materials. Configurations do not have to be based on existing Model bills of material, although that is currently necessary for ordering and downstream ERP applications.
You begin an Oracle Configurator Developer session by logging into Oracle Applications and then choosing a responsibility that provides access to Configurator Developer. (The predefined Oracle Configurator Developer responsibilities are described in the Oracle Configurator Implementation Guide.) You then select Oracle Configurator Developer from the list of available applications.
Oracle Configurator Developer consists of a Repository and a Workbench. These areas provide the tools you use when creating and maintaining configuration models.
Use the areas of the Configurator Developer Repository to organize Models and manage objects such as Effectivity Sets, Usages, UI Templates, Items and Item Types, Properties, Configurator Extensions, and Model Publications.
For more information about the Repository, see:
The different areas of the Configurator Developer Workbench provide tools for creating, modifying, and testing Model structure, configuration rules, and UI definitions. In the User Interface area, for example, you can generate a User Interface that is based on the Model structure, and then edit it to meet your product’s unique requirements.
For more information, see:
Oracle Configurator Developer displays many objects, such as the Model, configuration rules, and a generated User Interface, in a hierarchy. This structure shows how elements are related to each other and indicates which objects contain other objects. When an object contains other objects, a parent and child relationship exists between them. For example, within a Model, Component A contains Feature X, Y, and Z. In this relationship, Component A is the parent and the Features are its children.
In this user’s guide, each object within the Model structure is called a node. The node at the top of this structure is always a Model, and is called the root node. The Rules area of the Workbench and the User Interface area of the Workbench also display objects in a hierarchy (for example, rules, Folders, and UI elements), to indicate how they are organized and their relationship to other objects.
By default, Configurator Developer displays hierarchical data in a "collapsed" state, so only the root of the structure and the first level of nodes beneath the root are visible. You can expand or collapse sections of the hierarchy using the plus (+) and minus (-) controls, or apply the action to the entire structure by clicking Expand All or Collapse All. In the Main area of the Repository, for example, you can expand any Folder that contains one or more Models, Effectivity Sets, Usages, or other Folders. Within the each area of the Workbench, these controls appear next to any node that has children. For example, a Component that contains Features, or BOM Option Class that contains BOM Standard Items.
The fundamental elements of a configurator built with Oracle Configurator Developer are:
Model structure that organizes the parts of your product, such as an imported BOM Model
Configuration rules that constrain the relationships among parts of your product
A User Interface (UI) that optionally reflects the Model structure, enables end users to interact with the configuration model, and defines the appearance of the runtime Oracle Configurator
Model structure, rules, and it UI(s) are stored in the CZ schema, which is a sub-schema of the Oracle Applications database (for details, see Introduction to the CZ Schema). The compiled configuration rules and Model structure exist as the generated logic in the CZ schema. This logic enforces valid configurations based on end-user selections. The User Interface definitions of the configuration model function as the runtime Oracle Configurator User Interface. The User Interface (UI) also interprets the data in the CZ schema and keeps the UI state current as the end user makes selections. In other words, when the end user configures an item in the runtime Oracle Configurator, the CZ schema, configuration rules, and the User Interface determine what is available for selection, what results from selections, and how the configuration model is displayed.
Oracle Configurator is integrated with Oracle Applications so that an end user can configure a product based on a Bill of Materials (BOM). Oracle Configurator dynamically creates a configuration model that reflects BOM Model rules, including parent-child, optional or required selections, mutually exclusive selections, and Quantity Cascade rules. In this case, the BOM Model is neither imported into the CZ schema nor published from Configurator Developer; an end user configures the BOM Model using the Generic Configurator User Interface. For more information about the Generic Configurator UI, see the Oracle Configurator Implementation Guide.
If you want to add additional Model structure to a BOM Model, define additional rules, and generate a User Interface, you must do so in Configurator Developer. In this case, you can deploy a runtime Oracle Configurator by generating and customizing an HTML-based User Interface in Configurator Developer. For more information, see Introduction to the User Interface Area of the Workbench .
Refer to the Oracle Configurator Implementation Guide for more information on the mechanics of deploying a runtime Oracle Configurator.
Implementing and maintaining an Oracle Configurator consists of the following steps:
Complete Oracle Configurator Developer training.
Ask your Oracle representative about training classes available through Oracle University.
Read the Oracle Configurator Modeling Guide to become familiar with recommended best practices when designing Model structure and configuration rules.
Plan your project. See Plan your Project.
Set up Configurator Developer. See Set Up Oracle Configurator Developer.
Build a configuration model in Configurator Developer. This step typically includes extending an imported BOM Model by adding structure, defining configuration rules, and creating one or more User Interfaces. See Build a Configuration Model.
Unit test the configuration model in Configurator Developer. See Unit Test the Configuration Model.
Deploy the configuration model. This step includes:
Publishing the configuration model
System testing the configuration model
Manage configuration models and publications. See Manage Models and Publications.
Plan carefully before beginning to build a configuration model in Oracle Configurator Developer. Consider the following points during planning:
Design your configuration model and consider what functionality your end users require. For example, you may need to add a customer needs assessment component to your Model. For more information, see the Oracle Configurator Modeling Guide.
Plan to express your requirements for valid configurations in terms of the rules that Configurator Developer provides. See Design Configuration Rules.
Establish standardized and meaningful naming conventions for Model nodes and rules.
Plan your User Interface. Configurator Developer provides several UI Master Templates and UI Content Templates that you can use to generate a User Interface. You can also perform many customizations to a generated UI using the User Interface area of the Workbench. For details, see Model Structure and Generated User Interfaces.
If you need to deploy configuration models in multiple languages, consider the requirements for implementing Multiple Language Support (MLS). See Introduction to Multiple Language Support .
For custom deployments that are not integrated with Oracle Applications:
Gather the requirements for needed outputs such as quotes, proposals, and order entry data, their format, and the data for populating them. Oracle Configurator provides predefined output for Oracle ERP orders.
Gather the requirements for integrating your system with other systems such as data synchronization and replication, quotes, and orders.
Develop a plan for publishing configuration models. For details, see the Oracle Configurator Implementation Guide.
To build configuration models using Configurator Developer, you may want to use enterprise data from Oracle Inventory and Oracle Bills of Material, or a legacy system. You populate the CZ schema’s Item Master in the Oracle Applications database with data from Oracle Bills of Material by running a concurrent program. For more information about the CZ schema’s Item Master, see Introduction to the CZ Schema. The import process is explained in the Oracle Configurator Implementation Guide.
If your data comes from Oracle Inventory Items and Oracle Bills of Material, or from an external data source, you must develop a mechanism for populating the Configurator import tables, and a plan for refreshing the import as required. Your Database Administrator (DBA) may prepare existing enterprise data for import. To import data from a legacy system, see the Oracle Configurator Implementation Guide.
You can also populate the CZ schema’s Item Master from Configurator Developer by manually creating Items, Item Types, and Properties. For details, see Building Model Structure Using Items and Item Types.
Oracle Configurator Developer is an Oracle Applications product and is installed along with other applications in the Oracle E-Business Suite by running Rapid Install. Rapid Install also provides default values for all profile options and Oracle Configurator servlet properties. For details, see the Oracle Configurator Installation Guide.
The user name you enter when logging into Oracle Applications must be assigned to at least one of the responsibilities that provides access to Oracle Configurator Developer. Defining Oracle Applications users is described in the Oracle E-Business Suite System Administrator’s Guide. For a list of the predefined Configurator Developer responsibilities, see the Oracle Configurator Implementation Guide.
To ensure that the CZ schema contains the data you need, see the Oracle Configurator Implementation Guide, or your DBA.
If you need to maintain User Interfaces created in a previous version of Configurator Developer, see the current release or patch information for Oracle Configurator on MetaLink, Oracle’s technical support Web site.
Note: If you maintain both a development and a production database, do not run Configurator Developer in your production instance. For more information, see the Oracle Configurator Implementation Guide.
There are two approaches to creating a configuration model in Oracle Configurator Developer:
Self-contained mode
Integrated mode
In both modes, you build a configuration model based on item structure and data. If you are working in the self-contained mode, you create the Item Master and build your Model, configuration rules, and User Interface entirely within Configurator Developer. You might choose to work this way if you are building a small-scale demonstration or prototype system.
Many real-world configuration models involve working in the integrated mode. Configuration models that are created in integrated mode are based on products defined in Oracle Bills of Material. You import the BOM Model into the CZ schema, optionally build Model structure and define rules in Configurator Developer, and then deploy the configuration model. After an Oracle Configurator end user configures the item, it is passed on to Oracle Order Management for order fulfillment and downstream processing by other Oracle Applications products. For details about the data import process, see the Oracle Configurator Implementation Guide.
Carefully consider what rules you need to build into your configuration model. The design step may include writing a functional specification and other design documents.
When you define the requirements for your configurator, you define the rules that make default selections, constrain options based on other selections, and guide end users in creating a valid configuration. You now need to determine how you can most effectively and efficiently apply these rules, using the kinds of configuration rules that Oracle Configurator Developer provides.
Ask yourself questions such as:
What components must be included in a valid configuration?
What components are optional?
What components are compatible with each other?
What selections affect another selection?
What are valid initial selections?
What rules define the configuration of product families?
What rules define the relations among product families?
Refer to the following documentation for additional things to consider when defining rules:
Oracle Configurator Modeling Guide
Oracle Configurator Performance Guide
For information about defining rules, seeIntroduction to Configuration Rules.
After building Model structure and rules, generate a User Interface to view and unit test the Model in a runtime Oracle Configurator. If necessary, you can generate a variety of User Interfaces from a single Model's structure, or create a User Interface that is not based on the Model's structure. Generating a User Interface is described in Creating a New User Interface.
Click the Test Model button to unit test a configuration model periodically during development. This button appears in all pages of the Structure and Rules areas of the Workbench and enables you to either unit test a User Interface created in Configurator Developer, or run the Model Debugger.
For more information about unit testing, see Introduction to Unit Testing .
After unit testing and model development is complete, deploy the configuration model for integration and system testing. See Deploy the Configuration Model.
Deploying a configuration model requires integration with other applications and rigorous system testing before making it available to customers in your production environment.
Oracle Configurator can be called from many different host applications. For a complete list of applications that support Oracle Configurator, see the current release or patch information for Oracle Configurator on MetaLink, Oracle's technical support Web site.
If the Oracle Configurator is embedded in an Oracle Applications product (such as Order Management or iStore), there might not be any additional setup required after running the Oracle Applications Rapid Install process. However, some additional setup may be required to launch the embedded configurator in a non-Oracle Applications product. For more information, see the Oracle Configurator Installation Guide.
If the Oracle Configurator is embedded in a custom Web application, the host application must generate the initialization and termination messages that start and stop the embedded configuration session. See the Oracle Configurator Implementation Guide for more information.
A configuration model itself should be periodically unit tested while building it in Configurator Developer. Unit testing is discussed in Introduction to Unit Testing. However, because a Model may use effectivity, contain References to other Models, or have multiple UI definitions, a unique permutation of the same configuration model may appear when accessed by a host application. For this reason, you should also thoroughly system test your Model for adequate performance, end-user access, security, and any integration customizations before making it available to end users in a production environment. System testing includes publishing the configuration model using different applicability parameters and accessing each publication from at least one host application. For more information about publishing, see Introduction to Publishing .
After unit testing and updating the configuration model in Configurator Developer, and system testing using one or more host applications, make the configuration model available to end users in your production environment.
Before deploying the configuration model in a production environment, test existing configurations against the new version to ensure that users can restore previously saved configurations. If you made changes during the unit testing phase, you can easily bring the new Model on line without interrupting end-user access.
Managing a Model in Configurator Developer includes updating the Model’s structure, rules, and User Interface as your product and business requirements change over time, and updating Model publications so your Oracle Configurator end users have access to the most up-to-date configuration model.
You create a Model publication by publishing a configuration model. This makes the configuration model and UI available to one or more host applications. When a Model is published to your production environment, it becomes the configuration model against which Oracle Configurator end users make selections to configure products and services. You also update existing publications as each configuration model’s definition changes over time. For more information, see Introduction to Publishing.
In examples, an implied carriage return occurs at the end of each line, unless otherwise noted. You must press the Return key at the end of a line of input.
The table below lists other conventions that are also used in this manual.
| Convention | Meaning |
|---|---|
| . . . | Vertical ellipsis points in an example mean that information not directly related to the example has been omitted. |
| . . . | Horizontal ellipsis points in statements or commands mean that parts of the statement or command not directly related to the example have been omitted |
| boldface text | Boldface type in text indicates a new term, a term defined in the glossary, specific keys, and labels of user interface objects. Boldface type also indicates a menu, command, or option, especially within procedures |
| italics | Italic type in text, tables, or code examples indicates user-supplied text. Replace these placeholders with a specific value or string. |
| [ ] | Brackets enclose optional clauses from which you can choose one or none. |
| > | The left bracket alone represents the MS DOS prompt. |
| $ | The dollar sign represents the DIGITAL Command Language prompt in Windows and the Bourne shell prompt in Digital UNIX. |
| % | The per cent sign alone represents the UNIX prompt. |
| name() | In text other than code examples, the names of programming language methods and functions are shown with trailing parentheses. The parentheses are always shown as empty. For the actual argument or parameter list, see the reference documentation. This convention is not used in code examples. |
| & | Indicates a character string (identifier) that can display text dynamically in Configurator Developer or a runtime Oracle Configurator. For example, "&PROPERTY" can be used to dynamically construct and display a Property of a Model structure node. |
| |_ | Used in graphics that show Model structure to indicate a parent-to-child relationship between two nodes. |
| |-> | Used in graphics that show Model structure to indicate a Model Reference node. |
| |~> | Used in graphics that show Model structure to indicate a Connector node. |
The mission of the Oracle Support Services organization is to help you resolve any issues or questions that you have regarding Oracle Configurator Developer and Oracle Configurator.
To report issues that are not mission-critical, submit a Technical Assistance Request (TAR) using MetaLink, Oracle’s technical support Web site, at:
http://www.oracle.com/support/metalink/
Log into your MetaLink account and navigate to the Configurator TAR template:
Choose the TARs link in the left menu.
Click on Create a TAR.
Fill in or choose a profile.
In the same form:
Choose Product: Oracle Configurator or Oracle Configurator Developer
Choose Type of Problem: Oracle Configurator Generic Issue template
Provide the information requested in the iTAR template.
You can also find product-specific documentation and other useful information using MetaLink.
For a complete listing of available Oracle Support Services and phone numbers, see:
http://www.oracle.com/support/metalink
Oracle Configurator Developer and Oracle Configurator use the standard Oracle Applications methods of logging to analyze and debug both development and runtime issues. These methods include setting various profile options and Java system properties to enable logging and specify the desired level of detail you want to record.
For more information about logging, see:
The Oracle E-Business Suite System Administrator’s Guide for descriptions of the Oracle Applications Manager UI screens that allow System Administrators to set up logging profiles, review Java system properties, search for log messages, and so on.
The Oracle E-Business Suite Developer's Guide, which includes logging guidelines for both System Administrators and developers, and related topics.
The Oracle Applications Framework Developer's Guide, which describes the logging options that are available via the Diagnostics global link. This document is available on MetaLink (see Product Support for the URL).
For more information about the Diagnostics link, see Global Links .