Prerequisite for using Oracle Configurator is knowledge of Oracle

Inventory and Oracle Bills of Material modules.

Oracle configurator:
A configurator is a tool configuring products and services. This configuration process
can include accessing customer needs, selecting product and service component,
and viewing configurations. Oracle configurator can be integrated with the following
applications,
-iStore
-Order management
-TeleSales
-sales Online
-Quoting
-A custom Web Application
Oracle configurator Supports:
-Configuration for simple to complex product and services
-Guided buying or selling for non-expert users
-Real-time validation during option selection
-multiple user interfaces for different types of users accessing the same model.
-Batch validation of configuration models.
-Custom rule extensions to the configuration models
-BOM synchronization
-Multiple Instantiation in solution-based Models
-Model Networks and Connectivity
-Configuring Attributes

Oracle Configurator Architecture:

I. Three-Tier Architecture
Data tier for Oracle Applications Database Server
Application Tier for the Oracle Configurator Servlet and Internet or Web Server
UI Tier for Configurator Thin Client UI
II. Runtime Oracle Configurator and Oracle Configurator Developer use the same
data tier architecture.
III. Production Oracle Configurator and the test runtime Configurator. User Interface
invoked from Oracle Configurator Developer are thin Client UI is using the same
application tier architecture

Oracle Configurator Developer (OCD) is the development tool in the Oracle

Configurator family of products. It provides a convenient drag-and-drop interface
that enables you to rapidly develop a configurator.

Building Model Structure (Using Model Window):

Model structure is built using Model window component. It in turn uses Item master,
properties and imported data to create model structure. Item master is a
subschema in CZ schema for storing product data. OCD uses data in Item Master to
create configuration models. The items in Item Master are either created from
scratch in Configurator Developer or are imported from legacy product data (e.g.:
Bills of Material or Pricing information).
Model Structure is a hierarchical tree representation of the Model. Model Structure
consists of nodes of different types at different level. Following is the list of different
node types.
Node Type

Description

Model

The highest level of structure. A Model can contain Components and References
to other Models.

Component

A configurable part of a Model. A Component can contain Components,

Features, Resources, and Totals.

Connector

Enables an end user to link two components at runtime by selecting from a list
of instantiated Models. A Model can have one or more Connectors.

Feature

A Feature can be a List of Options, an Integer Number, a Decimal Number, a

True or False value, or a Text value. A Feature of type List of Options can contain
Options.

Option

An Option is part of a List of Options in a Feature. It is often an object

represented by an Item in the Item Master.

Total

A Total keeps track of a quantity. A Total can have a positive or negative value.
Use Numeric Rules to contribute to and consume from Totals.

Resource

A Resource also keeps track of a quantity. The value of a Resource can be

positive or zero, but a Resource is violated if its value becomes negative at
runtime (that is, it is over-consumed). Use Numeric Rules to contribute to and
consume from a Resource.

BOM Model

Equivalent to a Component in Configurator Developer. Can be either an

assemble to order (ATO) or pick to order (PTO) Model created in Oracle Bills of
Material and may include other BOM Models. Typically contains BOM Option
Classes, which include BOM Standard Items.

BOM Option Class

A group of related BOM Standard Items. BOM Standard Items are imported with
the BOM from Oracle Bills of Material, and are Equivalent to a Feature Option in
Configurator Developer.

BOM Standard Item

Any Oracle Inventory Item that can be a component on a bill, including

purchased items, subassemblies, and finished products. Equivalent to a Option
in Configurator Developer.

Building Rules and Constraints (Using Configurator Rules Module):

One of the most critical activities in constructing configuration model is to design

and construct the rules that govern what the end user can select to make a valid
configuration.
Rules express relations among the Components, Features, Options, BOM Option
Classes, and BOM Standard Items of your Model.
At runtime, the Configurator accesses your rules to determine the state of each
option before and after the end user makes a selection. The rules alert the end user
when an invalid selection is made and selects or deselects other options to ensure a
valid configuration is created.

OCD allows to create 8 different types of rules which are as listed below
Rule Type

Description

Logic Rules

Define logical relationships between Features, Options,

BOM Option Classes, and BOM Standard Items using
logicrelations.The logic
relations
available
are:
Requires, Implies, Excludes, Negates, and Defaults.

Numeric Rules

Perform a numeric operation on one or more numeric

Features, Option counts, or Totals placing the result in a
numeric
Feature,
Option
count,
Total,
orResource.The rules available are: Contributes to and
Consumes from, each with a variety of ways in which to
specify the numeric operation.

Comparison Rules

Perform a comparison between the value of a Property

of one or more Features and the value of another such
Property, or some constant value.

Property-based Compatibilities

Specify matches between the Options of one or more

Features that have a common Property.

Explicit Compatibilities

Specify matches between the Options of one or more

Features in explicit tabular form.

Design Charts

Specify compatibility matches between one Primary

Features Options and multiple Secondary Features
Options in explicit tabular form.

Rule Sequences

Specify an ordered set of rules whose effectivity dates

are set so that a rule in the sequence becomes
effective at the same time its predecessor ceases to be
effective.

Configurator Extension

Write java code to perform pre-selection or validation

functions that go beyond Oracle Configurator
Developers supplied functionality.

Building User Interface (Using UI Module):

User Interface is basically used for testing the Model or part of Model and is also
provides interface to end users while configuration using the Active Model. OCD can
automatically generate a User Interface derived directly from the Model. This

generated UI reflects the structure of Model and provides all the UI elements for
implementing a runtime Oracle Configurator.
OCD takes advantage of the Oracle Configurator architecture by storing the
complete definition of the User interface in the CZ schema, where it is available to
the Oracle Configurator Developer and the Active Model in a runtime Oracle
Configurator.
A User Interface is based on a single Model, which can contain sub-Models. SubModels can have their own UI or be included in a UI based on their parent Model (for
example, if a Model is referenced by another Model). Models, sub-Models, BOM
Models, BOM Option Classes, and Component nodes are represented by individual
screens in the runtime UI, and OCD creates a separate node for each in the UI tree.
Each Feature of a Component or Model node appears as a separate control within its
parent UI screen. The same is true for BOM Standard Items, which appear within the
same UI screen as their parent BOM Option Class. One can modify the type of
Feature control created for Feature nodes (Dropdown List or Selection List), but BOM
Option Classes generate selection lists and the control type is read-only.

Publishing:
Publishing is a process that creates a copy of a configuration models structure,
rules, and UI on a specific database to make it available for testing or production
use from different hosting applications. Publishing is typically the final phase of the
configuration model development process. When a configuration model is created in
OCD, it must under go unit testing, modification if any, and retest it before making it
available to users in either a system testing or production environment.
A publication is a unique deployment of a configuration model that enables to
control its availability when invoked by a hosting application and the UI that is
displayed to the end user. A configuration model can have multiple User Interfaces
and you can create many publications for the same Model. However, a publication
corresponds to only one configuration model and User Interface.

Full Cycle of Oracle Configurator.

-Create Items in Inventory Responsibility.

-Create Hierarchy in Bills of Materials Responsibility.
-Run Concurrent Program: Populate Configuration Models in Oracle Configurator
Developer (OCD) Responsibility.
-The models appear in the Repository tab of OCD.
-Click on the Lock icon beside the Models appearing in the Repository, so that
further changes can be made to the Models.
-Now the edit icons will be enabled besides the models. Click on Edit to enter the
model workbench.
-In the workbench tab there are 4 sub tabs: General, Structure, Rules & User
Interface.
-We can create the Non-BOM items in the Model as per our design in the Structure
tab. Non-BOM items
can be as follows: Option Feature, Boolean feature, Text
Feature, Integer Feature, Decimal Feature, Total, Resource, Component sets, etc.
-In the Rules tab we can create the Rules required to achieve the business
scenarios.
-In the User Interface tab we create the User Interface and align it as per it needs to
be visible when we launch the Oracle Configurator Runtime.
-We need to Publish the Model to be visible in the Run-time. This is done in the
Publication sub tab inside the Repository Tab of OCD.
-After doing this we have to Run a Concurrent Program named Publish a Single
Publication.