Oracle® Configurator: Modeling Guide Release 11i

Oracle® Configurator
Modeling Guide
Release 11i
Part No. B13605-03
May 2005
This book explores a variety of configuration problems and
the model designs that best solve them.
Oracle Configurator Modeling Guide, Release 11i
Part No. B13605-03
Copyright © 1999, 2005, Oracle. All rights reserved.
Primary Author: Tina Brand
Contributing Authors: Steve Damiani, Mark Sawtelle, Lois Wortley
Contributors: Ivan Lazarov, Marty Plotkin, Kiirja Paananen
The Programs (which include both the software and documentation) contain proprietary information; they
are provided under a license agreement containing restrictions on use and disclosure and are also protected
by copyright, patent, and other intellectual and industrial property laws. Reverse engineering, disassembly,
or decompilation of the Programs, except to the extent required to obtain interoperability with other
independently created software or as specified by law, is prohibited.
The information contained in this document is subject to change without notice. If you find any problems in
the documentation, please report them to us in writing. This document is not warranted to be error-free.
Except as may be expressly permitted in your license agreement for these Programs, no part of these
Programs may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any
purpose.
If the Programs are delivered to the United States Government or anyone licensing or using the Programs on
behalf of the United States Government, the following notice is applicable:
U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data
delivered to U.S. Government customers are "commercial computer software" or "commercial technical data"
pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As
such, use, duplication, disclosure, modification, and adaptation of the Programs, including documentation
and technical data, shall be subject to the licensing restrictions set forth in the applicable Oracle license
agreement, and, to the extent applicable, the additional rights set forth in FAR 52.227-19, Commercial
Computer Software--Restricted Rights (June 1987). Oracle Corporation, 500 Oracle Parkway, Redwood City,
CA 94065.
The Programs are not intended for use in any nuclear, aviation, mass transit, medical, or other inherently
dangerous applications. It shall be the licensee's responsibility to take all appropriate fail-safe, backup,
redundancy and other measures to ensure the safe use of such applications if the Programs are used for such
purposes, and we disclaim liability for any damages caused by such use of the Programs.
Oracle, JD Edwards, PeopleSoft, and Retek are registered trademarks of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective owners.
The Programs may provide links to Web sites and access to content, products, and services from third
parties. Oracle is not responsible for the availability of, or any content provided on, third-party Web sites.
You bear all risks associated with the use of such content. If you choose to purchase any products or services
from a third party, the relationship is directly between you and the third party. Oracle is not responsible for:
(a) the quality of third-party products or services; or (b) fulfilling any of the terms of the agreement with the
third party, including delivery of products or services and warranty obligations related to purchased
products or services. Oracle is not responsible for any loss or damage of any sort that you may incur from
dealing with any third party.
Contents
Send Us Your Comments ........................................................................................................................ xi
Preface ............................................................................................................................................................... xiii

Intended Audience.................................................................................................................................... xiii
Documentation Accessibility ................................................................................................................... xiii
Structure of This Book .............................................................................................................................. xiv
Related Documents ................................................................................................................................... xv
Conventions ............................................................................................................................................... xv
Product Support ........................................................................................................................................ xvi
Part I Modeling Guidelines
1 Planning Your Model Design

1.1 Overview of Designing a Configuration Model..................................................................... 1-1
1.2 Planning Guidelines Relevant to Model Design .................................................................... 1-1
1.2.1 BOM Model Design or Redesign....................................................................................... 1-2
1.2.2 End-User Expectations ....................................................................................................... 1-3
1.2.3 Business and Manufacturing Constraints ........................................................................ 1-3
2 Starting Your Model Design

2.1 Do You Expect Configurator to Display Large Lists of Options?........................................ 2-1
2.2 Are the Same Product Elements Repeated in Separate Models? ......................................... 2-2
2.3 Are You Modeling Many Related Products? .......................................................................... 2-3
2.4 Do You Need Default Values Set Automatically?.................................................................. 2-3
2.5 Does Your End User Need to See the Bill of Materials?........................................................ 2-4
2.6 Will Configurations Contain Instances of a Component? .................................................... 2-4
2.7 Will Your Configurator Collect Many End-User Inputs? ..................................................... 2-5
2.8 Does Configurator Depend on Information Collected Upstream?...................................... 2-5
2.9 Does Configurator Pass Non-Orderable Information Downstream? ................................. 2-6
2.10 Are Some Selections Disallowed Until Other Selections Are Made? .................................. 2-6
2.11 Will Your Rules Include Repeating Patterns or Redundancy? ............................................ 2-7
2.12 Do You Need to Express Compatibilities in Your Model? ................................................... 2-7
2.13 Do You Need to Express Comparisons in Your Model?....................................................... 2-7
iii
3 Best Practices
3.1 Explicit Model Structure Versus Abstractions........................................................................ 3-1
3.1.1 Explicit Structure ................................................................................................................. 3-2
3.1.2 Abstractions .......................................................................................................................... 3-3
3.1.3 Downstream Consequences in Other Oracle Applications ........................................... 3-4
3.1.4 Related Best Practices and Relevant Case Studies .......................................................... 3-4
3.2 Explicit Model Structure Versus References ........................................................................... 3-4
3.2.1 Explicit Structure ................................................................................................................. 3-5
3.2.2 Model References................................................................................................................. 3-5
3.2.2.1 Referencing BOM Option Classes .............................................................................. 3-5
3.2.2.2 Non-Imported Model References............................................................................... 3-6
3.3 Optional and Multiple Instantiation ........................................................................................ 3-6
3.3.1 Optional Instantiation of BOM Option Classes............................................................... 3-6
3.3.2 Setting Node Values After Adding Instances.................................................................. 3-8
3.3.4 Large Numbers of Instances............................................................................................... 3-8
3.4 Guided Buying or Selling .......................................................................................................... 3-9
3.5 Shallow Versus Nested or Deep Hierarchy ............................................................................ 3-9
3.6 Items Versus Alternatives to Items ....................................................................................... 3-10
3.6.1 Values Needed For Configuration Only ....................................................................... 3-10
3.6.2 Values Needed Downstream .......................................................................................... 3-10
3.6.3 Related Best Practices and Relevant Case Studies ....................................................... 3-12
3.7 Large Option Features and Option Classes ......................................................................... 3-12
3.7.1 Grouped Versus Ungrouped Items................................................................................ 3-12
3.7.2 Maximum Selections on Large Option Classes or Features ....................................... 3-12
3.7.3 Alternatives to Option Features With Many Options ................................................. 3-13
3.7.4 Relevant Case Studies ...................................................................................................... 3-14
3.8 Defaults Rules Versus Alternatives to Default Selections.................................................. 3-14
3.8.1 Evaluating the Need for Default Selections .................................................................. 3-14
3.8.2 Activating Defaults on End User Request..................................................................... 3-15
3.8.3 Boolean Features With Initial Values............................................................................. 3-15
3.8.4 The postConfigNew Configurator Extension............................................................... 3-15
3.8.5 Implies Relation Instead of Defaults Relation .............................................................. 3-16
3.9 Repetitive Rule Patterns and Redundancy .......................................................................... 3-17
3.9.1 Repetitive Patterns and Common Subexpressions ...................................................... 3-17
3.9.2 Redundancy....................................................................................................................... 3-18
3.9.3 Circular Propagation ........................................................................................................ 3-18
3.10 Number and Complexity of Rules......................................................................................... 3-19
3.11 NotTrue Logical Function Imposes Order and Causes Locking....................................... 3-20
3.11.1 Order Dependency Caused By NotTrue ....................................................................... 3-20
3.11.2 Locked States Caused By NotTrue................................................................................. 3-21
3.12 Compatibility Rules ................................................................................................................. 3-21
3.12.1 Expressing Compatibility Using Properties ................................................................. 3-22
3.12.2 Minimizing Participants in a Compatibility ................................................................ 3-23
iv
3.12.3 Using the Excludes Relation to Express Incompatibilities ........................................ 3-23
3.13 Comparison Rules.................................................................................................................... 3-23
3.13.1 Comparison Rules That Raise Warnings....................................................................... 3-24
3.13.2 Using Intermediate Values Effectively With Comparison Rules............................... 3-24
3.14 Connectors with Connection Rules ....................................................................................... 3-25
3.14.1 Connection Rules That Depend on End-User Input.................................................... 3-26
3.14.2 Order Independent Connection Rules .......................................................................... 3-26
3.14.3 Restoring Configurations With Connections................................................................ 3-27
3.15 User Interfaces With Optimal Usability and Performance ................................................ 3-27
3.15.1 Visibility Settings .............................................................................................................. 3-28
3.15.2 Graphics ............................................................................................................................. 3-28
3.15.3 Number and Type of Pages and Controls..................................................................... 3-28
3.15.4 Configuration Summary User Interface Template ...................................................... 3-28
3.15.5 Custom User Interface ..................................................................................................... 3-28
3.16 Large Amounts of End-User Data Collected Using Configurator Extensions ............... 3-29
3.17 Configurator Extension Design ............................................................................................. 3-29
3.17.1 Avoiding Unnecessary Interactions ............................................................................... 3-30
3.17.2 Accessing Runtime Nodes............................................................................................... 3-30
3.17.3 Components and Requests .............................................................................................. 3-31
3.17.4 Adding and Deleting Instantiable Components .......................................................... 3-31
3.17.5 Impact of Making Connections Among Components................................................. 3-32
3.17.6 Optimization of Configurator Extensions that Change Model Structure ................ 3-32
3.17.6.1 Detailed Sequence ..................................................................................................... 3-33
3.17.6.2 Comparison of Coding Approaches ....................................................................... 3-34
3.17.6.3 Code Example ............................................................................................................ 3-35
3.17.7 Optimization of Validation Configurator Extensions ................................................. 3-37
Part II Case Studies
4 Many Large BOM Models

4.1 Project Description...................................................................................................................... 4-1
4.2 A Deficient Modeling Approach .............................................................................................. 4-1
4.3 The Suggested Modeling Approach......................................................................................... 4-3
4.3.1 Applying Best Practices to Your Model Structure .......................................................... 4-3
4.3.2 Applying Best Practices to Further Optimize the End-User Experience..................... 4-5
4.3.3 The Resulting End-User Flow ............................................................................................ 4-6
4.3.4 Advantages of This Modeling Approach......................................................................... 4-6
5 Many BOM Items

5.1 Project Description...................................................................................................................... 5-1
5.2 A Deficient Modeling Approach .............................................................................................. 5-1
5.3 The Suggested Modeling Approach......................................................................................... 5-3
5.3.1 Applying Best Practices to Your Model Structure .......................................................... 5-3
5.3.2 Applying Best Practices to Further Optimize the End-User Experience..................... 5-5
5.3.3 The Resulting End-User Flow ............................................................................................ 5-6
5.3.4 Advantages of This Modeling Approach......................................................................... 5-6
v
Glossary
Index
vi
List of Examples
3–1 Model Design with Minimal Set of Features ....................................................................... 3-11
3–2 Maximum Selections Imposed by a Rule ............................................................................. 3-13
3–3 Redesigning Unconstrained Options as Boolean Features ................................................ 3-14
3–4 Defaults Rule Behavior at Runtime....................................................................................... 3-16
3–5 Configurator Extension That Simulates Defaults Rule ...................................................... 3-16
3–6 Implies Rule Provides Behavior of an Unoverridable Defaults Rule............................... 3-16
3–7 Rules With Common Subexpressions................................................................................... 3-17
3–8 Redundant Rules...................................................................................................................... 3-18
3–9 Circular Rules (Logic and Numeric) ..................................................................................... 3-18
3–10 Numeric Cycles ........................................................................................................................ 3-19
3–11 Rules With Common Subexpressions................................................................................... 3-19
3–12 Unexpected Contradictions from Intermediate Values...................................................... 3-24
3–13 Avoiding Unexpected Contradictions from Intermediate Values.................................... 3-24
3–14 Setting Components and Feature Values One at a Time (Slower).................................... 3-34
3–15 Setting All Components and Then All Feature Values (Faster) ....................................... 3-34
3–16 Detailed Slower Approach ..................................................................................................... 3-35
3–17 Detailed Faster Approach ....................................................................................................... 3-35
3–18 Setting Features (Slower Code).............................................................................................. 3-36
3–19 Setting Features (Faster Code) ............................................................................................... 3-36
3–20 Minimizing Validation Tests on a Configuration Model................................................... 3-37
3–21 Causing More Validation Tests on a Configuration Model............................................... 3-37
vii
List of Figures
2–1 Repeating Similar Product Elements ....................................................................................... 2-2
3–1 Explicit Model Structure ............................................................................................................ 3-2
3–2 Abstraction of Related Products ............................................................................................... 3-3
3–3 Another Possible Abstraction of Related Products................................................................ 3-5
3–4 Explicit Nested Hierarchy ......................................................................................................... 3-7
3–5 Referenced Nested Hierarchy ................................................................................................... 3-7
3–6 Model with a Connector ......................................................................................................... 3-26
3–7 Model Structure for Adding Components ........................................................................... 3-36
4–1 Many Explicit Ring Models ....................................................................................................... 4-2
4–2 Top-level Ring Model with Abstractions ................................................................................ 4-5
4–3 End User Flow for Configuring a Ring Model ....................................................................... 4-6
5–1 Model With Too Many Items .................................................................................................... 5-2
5–2 Redesigned Model With Fewer Items...................................................................................... 5-5
viii
List of Tables
3–1 Compatibility Table ................................................................................................................ 3-23
ix
x
Send Us Your Comments
Oracle Configurator Modeling Guide, Release 11i

Part No. B13605-03
Oracle welcomes your comments and suggestions on the quality and usefulness of this
publication. Your input is an important part of the information used for revision.
■ Did you find any errors?
■ Is the information clearly presented?
■ Do you need more information? If so, where?
■ Are the examples correct? Do you need more examples?
■ What features did you like most about this manual?
If you find any errors or have any other suggestions for improvement, please indicate
the title and part number of the documentation and the chapter, section, and page
number (if available). You can send comments to us in the following ways:
■ Electronic mail: czdoc_us@oracle.com
■ FAX: 781-238-9896. Attn: Oracle Configurator Documentation
■ Postal service:
Oracle Corporation
Oracle Configurator Documentation
10 Van de Graaff Drive
Burlington, MA 01803-5146
USA
If you would like a reply, please give your name, address, telephone number, and
electronic mail address (optional).
If you have problems with the software, please contact your local Oracle Support
Services.
xi
xii
Preface
Welcome to the Oracle Configurator Modeling Guide. This book contains information you
need for designing configuration models that are best suited to Oracle Configurator.
This book focuses on model design and does not present other information about
planning Oracle Configurator projects such as preparing your site and team for
implementation and scheduling tasks.
Use this document together with the other books in the Oracle Configurator
documentation set to prepare for and implement high performance configuration
model designs.
This preface describes how the book is organized, who the intended audience is, and
how to interpret the typographic conventions.
Intended Audience
This guide is intended for Oracle Consultants and implementers of Oracle
Configurator who have completed Oracle Configurator training or have experience
using Oracle Configurator Developer. Oracle Configurator training is available
through Oracle University.
Before using this book, you should already have a working knowledge of your
business processes, how to create configuration models using Oracle Applications, and
the other books in the Oracle Configurator documentation set.
Documentation Accessibility
Our goal is to make Oracle products, services, and supporting documentation
accessible, with good usability, to the disabled community. To that end, our
documentation includes features that make information available to users of assistive
technology. This documentation is available in HTML format, and contains markup to
facilitate access by the disabled community. Accessibility standards will continue to
evolve over time, and Oracle is actively engaged with other market-leading
technology vendors to address technical obstacles so that our documentation can be
accessible to all of our customers. For more information, visit the Oracle Accessibility
Program Web site at
http://www.oracle.com/accessibility/
Accessibility of Code Examples in Documentation JAWS, a Windows screen reader,

may not always correctly read the code examples in this document. The conventions
for writing code require that closing braces should appear on an otherwise empty line;
however, JAWS may not always read a line of text that consists solely of a bracket or
brace.
xiii
Accessibility of Links to External Web Sites in Documentation This documentation
may contain links to Web sites of other companies or organizations that Oracle does
not own or control. Oracle neither evaluates nor makes any representations regarding
the accessibility of these Web sites.
TTY Access to Oracle Support Services Oracle provides dedicated Text Telephone
(TTY) access to Oracle Support Services within the United States of America 24 hours a
day, seven days a week. For TTY support, call 800.446.2398.
Structure of This Book

This book contains a table of contents, lists of examples, tables, and figures, a reader
comment form, a preface, several chapters, a glossary, and an index.
Part I, "Modeling Guidelines"

Part I consists of a series of chapters designed to lead you from relevant planning
guidelines through important design questions to best practices that leverage the
strengths and requirements of Oracle Configurator.
Chapter 1, "Planning Your Model Design"

This chapter describes the high level flow of starting a project and designing
configuration models. The chapter also presents guidelines to help you plan your
Oracle Configurator project and determine which design questions you should ask.
Chapter 2, "Starting Your Model Design"

This chapter presents questions you should ask when you begin designing your
configuration model. The answers determine which best practices apply to your
project.
Chapter 3, "Best Practices"

This chapter explains best practices for designing a configuration model with optimal
usability, performance, maintainability, and scalability.
Part II, "Case Studies"

Part II presents some common configuration problems and optimal design solutions
best suited to an Oracle Configurator implementation.
Chapter 4, "Many Large BOM Models"

This chapter describes an Oracle Configurator project involving many large BOM
Models with much explicit and repetitive structure that is best modeled as a single
top-level BOM Model containing a deep hierarchy of generic structure and
abstractions.
Chapter 5, "Many BOM Items"

This chapter describes an Oracle Configurator project involving many BOM Items that
are not orderable and could be better implemented as Features or configuration
attributes.
Glossary
This manual contains a glossary of terms used throughout the Oracle Configurator
documentation set.
xiv
The Index provides an alternative method of searching for key concepts and product
details.
Related Documents
For more information about Oracle Configurator, see the following manuals in the
Oracle Configurator documentation set:
■ Oracle Configurator Implementation Guide (Part No. B13604-03)
■ Oracle Configurator Installation Guide (Part No. B13602-03)
■ Oracle Configurator Developer User’s Guide (Part No. B13603-03)
■ Oracle Configurator Documentation Master Index (Part No. B13610-03)
■ Oracle Configurator Extensions and Interface Object Developer’s Guide (Part No.
B13607-03)
■ Oracle Configurator Methodologies (Part No. B10618-01)
Be sure you are familiar with the information and limitations described in the latest
About Oracle Configurator documentation on Metalink.
For related topics, see the documentation for other Oracle Applications, such as:
■ Oracle Bills of Material User’s Guide
■ Oracle Configure To Order Implementation Guide
Conventions
In code 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.
In rule examples, the order in which the rules are presented does not indicate a
sequence in which Oracle Configurator processes the rules. You cannot assume a
particular sequence, and the sequence can differ each time the rules are processed by
the Oracle Configurator engine.
The following conventions 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.
xv
Convention Meaning
$ The dollar sign represents the DIGITAL Command Language prompt
in Windows and the Bourne shell prompt in Digital UNIX.
% The percent 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.
Product Support
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:
1. Choose the TARs link in the left menu.
2. Click on Create a TAR.
3. Fill in or choose a profile.
4. In the same form:
a. Choose Product: Oracle Configurator or Oracle Configurator Developer
b. Choose Type of Problem: Oracle Configurator Generic Issue template
5. 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:
www.oracle.com/support/
Troubleshooting
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 general information about the logging options available when working in
Configurator Developer, see the Oracle Configurator Developer User’s Guide.
For details about the logging methods available in Configurator Developer and a
runtime Oracle Configurator, see:
■ The Oracle Applications 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.
xvi
■ The Oracle Applications Supportability Guide, which includes logging guidelines for
both System Administrators and developers, and related topics.
■ The Oracle Applications Framework Release 11i Documentation Road Map
(Metalink Note # 275880.1).
xvii
xviii
Part I
Modeling Guidelines
Oracle Configurator provides tools for a wide range of solutions. Part I consists of the
following chapters, which are designed to lead you from relevant planning guidelines
through important design questions to best practices that leverage the strengths and
requirements of Oracle Configurator:
■ Chapter 1, "Planning Your Model Design"
■ Chapter 2, "Starting Your Model Design"
■ Chapter 3, "Best Practices"
1
Planning Your Model Design
This chapter focuses on model designing issues and presents the following:
■ Overview of Designing a Configuration Model
■ Planning Guidelines Relevant to Model Design
For information about planning and starting an Oracle Configurator project, see the
Oracle Configurator training available through Oracle University.
1.1 Overview of Designing a Configuration Model

A proven, repeatable methodology for designing and creating configuration models
includes the following design considerations:
1. Model structure design
2. User Interface design
3. Rule design
You start by designing the Model structure, which may involve leveraging BOM
Model data that already exists in Oracle Bills of Material, and adding guided buying
or selling Features and Options.
As you design your Model structure, consider your requirements for the user interface.
The runtime Oracle Configurator UI is automatically generated from your Model
structure, and your UI requirements often drive the structure of your guided buying or
selling components.
Once you have designed an initial Model structure, apply rules among its elements.
Rules typically represent the most complex aspect of your configuration model and
should be well thought-out during the design process.
The flow of steps to design a configuration model is often iterative, but by following
the suggestions in this Modeling Guide you should be able to reduce the number of
iterations during the design process. Section 1.2 describes a set of guidelines to follow
as you plan your implementation and identify what design decisions are necessary.
1.2 Planning Guidelines Relevant to Model Design

This section presents some of the planning guidelines that can help you make
appropriate model design decisions in the following areas:
■ BOM Model Design or Redesign
■ End-User Expectations
Planning Your Model Design 1-1

Planning Guidelines Relevant to Model Design
■ Business and Manufacturing Constraints

These planning guidelines are intended as a starting point for designing your
configuration model. You may need to make additional planning decisions that are
specific to your business or Oracle Configurator project and therefore not discussed
here.
Note: Even if your implementation does not leverage BOM

Models, review the design questions and best practices listed in
Section 1.2.1, "BOM Model Design or Redesign" before beginning
your configuration model design.
Once you have read through the following planning guidelines, you should read
through all the design questions presented in Chapter 2 to help identify best practices
in Chapter 3 that are relevant to your project.
1.2.1 BOM Model Design or Redesign

The guidelines provided for BOM Model design assume that your Oracle Configurator
project is integrated in the Oracle eBusiness Suite.
The BOM is what is configured and ordered. While it needs to be structured for your
Enterprise Resource Planning (ERP) process, it also may need to be simplified for end
user comprehension and usability during configuration. Even if you believe there is no
flexibility for changing your BOM Models, the consequences in implementation effort,
maintenance costs, usability issues, and performance may persuade you to make some
adjustments.
Planning Guidelines
Always begin your Oracle Configurator project by examining the structure of your
BOM Models. If your BOM Models exhibit any of the following characteristics, you
should refer to the design questions listed in Chapter 2 to determine the best practices
that are suitable to your project.
■ Many BOM Option Classes and BOM Standard Items, typically models with over
10,000 elements
■ Large BOM Option Classes, typically those containing over 100 BOM Standard
Items
■ Multiple BOM Models with similar structures
■ BOM Option Classes that are repeated in multiple BOM Models
The goal is to streamline your BOM Models so that the resulting configuration models
are highly maintainable and scalable as your business grows, with optimal usability
and performance at runtime.
Note: Both the name and description of BOM items are imported
into Configurator Developer with the BOM Model. If either is used
to generate UI captions, make sure they are meaningful to end
users.
Be aware that only BOM Standard Items that are defined as
optional in Oracle Bills of Material appear in Oracle Configurator;
BOM Standard Items that are mandatory are not displayed.
1-2 Oracle Configurator Modeling Guide

BOM Model redesign involves changes such as reducing repetitive or similar structure
into abstract elements that are referenced. This and other BOM Model redesign best
practices are presented in Chapter 3.
1.2.2 End-User Expectations

A single configuration model can support multiple User Interfaces (UIs). Most
end-user UIs are generated automatically from within Oracle Configurator Developer.
Since you may base the UI structure on the Model structure, keep UI considerations
and end-user expectations in mind as you design your configuration model.
Planning Guidelines
Examine and understand how your end users will interact with the configuration UI.
The following circumstances are relevant to model design:
■ Your runtime Oracle Configurator needs to exhibit any of the following behaviors:
– UI opens with options already selected
– Product complexity hidden from end users by high-level questions or minimal
required selections
■ Your end users need to perform any of the following actions in the UI:
– Select from a long list of values
– Enter as input the characteristics of a part (such as dimensions, instructions, a
monogram, or similar information)
– Add or remove elements of the configuration
1.2.3 Business and Manufacturing Constraints

One of the most critical activities in constructing your configuration model is to design
and construct the rules that govern what the end user can select to make a valid
configuration. You need to identify the rules that express relations among the
Components, Features, Options, BOM Option Classes, and BOM Standard Items of
your Model.
Planning Guidelines
The number and complexity of the rules are a factor in determining the size of your
configuration model. Independent of whether structure is a factor, fewer than 500 rules
is generally a small model, 500 to 2,000 rules is a medium model, and over 2,000 rules
is a large model. When working with models containing a large number of rules,
performance and usability can be a concern.
Examine and understand the rules that define your business or constrain your
products. The following circumstances are relevant to model design:
■ You have over 2,000 rules, or you have rules that exhibit any of the following
characteristics:
– Complexity with subexpressions, especially if the subexpressions are used in
multiple rules
– Specific order or sequence in which the rules must be executed
■ You use the following types of rules in your configuration model:
– Compatibility
– Comparison
Planning Your Model Design 1-3

– Defaults

2
Starting Your Model Design
Before reading this chapter, review the planning guidelines in Chapter 1 to help
identify areas of special consideration in an Oracle Configurator project.
This chapter presents the design questions you should ask yourself in order to identify
which best practices apply to your project:
■ Do You Expect Configurator to Display Large Lists of Options?
■ Are the Same Product Elements Repeated in Separate Models?
■ Are You Modeling Many Related Products?
■ Do You Need Default Values Set Automatically?
■ Does Your End User Need to See the Bill of Materials?
■ Will Configurations Contain Instances of a Component?
■ Will Your Configurator Collect Many End-User Inputs?
■ Does Configurator Depend on Information Collected Upstream?
■ Does Configurator Pass Non-Orderable Information Downstream?
■ Are Some Selections Disallowed Until Other Selections Are Made?
■ Will Your Rules Include Repeating Patterns or Redundancy?
■ Do You Need to Express Compatibilities in Your Model?
■ Do You Need to Express Comparisons in Your Model?
Read through the questions on the following pages to help you identify relevant
design decisions that are presented as some of the best practices and case studies in the
following chapters. This list of design questions is intended as a starting point and
does not include all the questions that are useful to ask as you begin your Oracle
Configurator project.
2.1 Do You Expect Configurator to Display Large Lists of Options?

Many options means more than 100 selectable items in one list of options. Hundreds
or thousands of selectable options displayed for end users cause usability and
performance problems.
Other Ways To Phrase This Question

Does your BOM Model contain any BOM Option Classes with more than 100
selectable items?
Starting Your Model Design 2-1

Are the Same Product Elements Repeated in Separate Models?
What is an efficient way to design a BOM Option Class or Option Feature containing a
large number of option selections?
Structure Decisions
Apply the following best practices when optimizing the design of large numbers of
options or inventoried parts:
■ Section 3.3, "Optional and Multiple Instantiation" on page 3-1
■ Section 3.7.1, "Grouped Versus Ungrouped Items" on page 3-12
Rule Decisions
Apply the following best practices when optimizing the rule design of large numbers
of options:
■ Section 3.7, "Large Option Features and Option Classes" on page 3-12
UI Decisions
Apply the following best practices when optimizing the UI design of large numbers of
options:
■ Section 3.15, "User Interfaces With Optimal Usability and Performance" on
page 3-27
2.2 Are the Same Product Elements Repeated in Separate Models?

Any identical or similar model structure that is duplicated at least twice in your Model
can be considered a repeating product element. For example, BOM Option Classes that
are similar share some options in common, but also contain different options, as
shown in Figure 2–1.
Figure 2–1 Repeating Similar Product Elements
Figure 2–1 shows that when the separate and duplicated structure is combined, the
total structure that has to be loaded, instantiated, or maintained is smaller. When
combining structure in this way, you need appropriate rules to ensure that only the
relevant options are visible or available where the abstraction appears in the runtime
Oracle Configurator.

Do You Need Default Values Set Automatically?

Are there high degrees of similarity across multiple models?
Are the same BOM Option Classes used in multiple BOM Models?
Where in your BOM Model structure can you take advantage of referencing?
Would combining several similar BOM Option Classes into one BOM Option Class
containing a union of all possible options decrease the overall number of options that
need to be loaded or instantiated in Oracle Configurator?
Structure Decisions
If the same product elements repeat in separate models, use the following best
practices to optimize your model design:
■ Section 3.1, "Explicit Model Structure Versus Abstractions" on page 3-1
■ Section 3.2, "Explicit Model Structure Versus References" on page 3-4
■ Section 3.5, "Shallow Versus Nested or Deep Hierarchy" on page 3-9
2.3 Are You Modeling Many Related Products?

Hundreds or thousands of separate products with similar or duplicate items cause
maintenance, performance, and scalability problems.

Do your end users configure similar products from a large product line?
Do your products contain many common elements, repetitive structure, or similar sets
of selections?
Do you use multiple BOM Models to represent different combinations of the same
general product?
When should you use generic BOM Models and when should you maintain a set of
explicit BOM Models for the same structure?
Structure Decisions
Apply the following best practices when optimizing the design of large numbers of
related products:
■ Section 3.1, "Explicit Model Structure Versus Abstractions" on page 3-1
■ Section 3.2, "Explicit Model Structure Versus References" on page 3-4
■ Section 3.5, "Shallow Versus Nested or Deep Hierarchy" on page 3-9
2.4 Do You Need Default Values Set Automatically?

Default values present suggested or likely values that end users could change if
desired but do not need to change to complete the configuration. There are many ways
to implement the effect of default values, some of which, such as Defaults rules, are
more costly to Configurator performance than others.

Do end users expect to see default, initial, or recommended values already filled in
when they start up Oracle Configurator?

Does Your End User Need to See the Bill of Materials?
Do end users expect to see default values filled in automatically to accelerate

completion of the configuration as they make selections?
When is it efficient to add defaults to end user requests?
Rule Decisions
Apply the following best practices when designing pre-selected or default values:
■ Section 3.8, "Defaults Rules Versus Alternatives to Default Selections" on page 3-14
2.5 Does Your End User Need to See the Bill of Materials?
If configurations are based on a BOM Model, you need to determine if end users need
the BOM items to appear in Oracle Configurator exactly as they appear in Inventory
and Bills of Material. With very large BOMs or novice end users, displaying the entire
BOM is not optimal or desirable.

Is the end user a product expert who expects to make selections of parts by their part
numbers or part descriptions?
Does the end user need guidance in making appropriate selections to create a valid
configuration?
When is it efficient to define a guided buying or selling model instead of exposing the
BOM items for selection?
Structure Decisions
If your end users expect to see the BOM, use the following best practices to optimize
your model design, especially if your BOM is large:
■ Section 3.7.1, "Grouped Versus Ungrouped Items" on page 3-12
If your end users do not expect to see the BOM, use the following best practices to
optimize your model design:
■ Section 3.4, "Guided Buying or Selling" on page 3-9
UI Decisions
If your end users do not expect to see the BOM, use the following best practices to
optimize your model design:
■ Section 3.15, "User Interfaces With Optimal Usability and Performance" on
page 3-27
2.6 Will Configurations Contain Instances of a Component?

In this question, component refers not only to Configurator Developer Components,
but any configurable element in a configuration model, including instances of BOM
Models, Models, and Components.
Hundreds or thousands of instances that end users must add interactively to the
configuration, or that must be instantiated at startup cause usability and performance
problems. Adding an instance is more costly to performance than selecting an option.

Does Configurator Depend on Information Collected Upstream?

Do you have many instances of a component with no constraints among the selections
within the configuration of each instance?
Do you need your end users to add many instances of a component, or can instances
be added programmatically?
Structure Decisions
Apply the following best practices when optimizing the design of adding instances:
Rule Decisions
Apply the following best practices when optimizing the rule design of adding
instances with a Configurator Extension:
■ Section 3.17, "Configurator Extension Design" on page 3-29
2.7 Will Your Configurator Collect Many End-User Inputs?

This question identifies hundreds or thousands of inputs that are only passed as
parameters and contribute to but are not constrained by rules in the configuration
session. Designing Oracle Configurator to include collecting such end-user inputs can
cause usability and performance problems. In some cases such data input can occur
more efficiently outside the configuration session.

Do you expect end-user interactions to be extensive and repetitive?
Do you have end-user inputs that do not participate directly in rules or calculations?
Do you feel that your end users would be able to enter data into a spreadsheet?
Will your end user enter data as option selections or as text or numeric inputs?
UI Decisions
Apply the following best practices when optimizing the UI design of models with
large numbers of end-user inputs:
■ Section 3.16, "Large Amounts of End-User Data Collected Using Configurator
Extensions" on page 3-29
2.8 Does Configurator Depend on Information Collected Upstream?

Information that is collected by the host application for the configuration session, but
is not needed in downstream processes, should be passed to Oracle Configurator as
configuration attributes. Structuring this information as orderable items can cause
usability and maintenance problems because it bloats the BOM and must be dealt with
as order line items.

Do you expect attributes or parameters to be passed into Oracle Configurator?
Is there data besides items and quantities of items that is needed for computation in
Oracle Configurator?

Does Configurator Pass Non-Orderable Information Downstream?
Is there non-item information on the order line before configuration that Oracle
Configurator needs in computations?
Structure Decisions
Apply the following best practices when optimizing structure that includes passing
attributes into Oracle Configurator:
■ Section 3.6, "Items Versus Alternatives to Items" on page 3-10
2.9 Does Configurator Pass Non-Orderable Information Downstream?

Information collected from the configuration session that is needed in downstream
processes should be passed as configuration attributes. Structuring this information as
orderable items can cause usability and maintenance problems because it bloats the
BOM and must be dealt with as order line items.

Do you expect attributes or parameters to be passed out of Oracle Configurator?
Is non-item information, meaning not items or their quantities, needed on the order
line?
Are the results of computations in Oracle Configurator needed in downstream
processing?
Structure Decisions
Apply the following best practices when optimizing structure that includes passing
attributes out of Oracle Configurator:
■ Section 3.6, "Items Versus Alternatives to Items" on page 3-10
2.10 Are Some Selections Disallowed Until Other Selections Are Made?
This means that you may be implementing rules with the NotTrue operator in CDL or
Statement Rules. NotTrue may cause rule propagation issues under certain
circumstances if it imposes order in rules.

Do you have rules that make some options not selected until some other option is
selected?
Are you planning on using NotTrue in CDL or Statement Rules?
Do you want to disallow some option selections when other options are not selected?
Do you need to impose dependencies among option selections?
Rule Decisions
Apply the following best practices when optimizing a rule design that imposes order
on option selections, or locks the initial value of components:
■ Section 3.11, "NotTrue Logical Function Imposes Order and Causes Locking" on
page 3-20

Do You Need to Express Comparisons in Your Model?
2.11 Will Your Rules Include Repeating Patterns or Redundancy?

Repeating patterns or redundancy means that several rules include the same
subexpressions or have the same result. This could cause performance issues.

Does your model require calculations that contribute to other calculations?
Rule Decisions
Apply the following best practices when optimizing the rule design of models
containing common subexpressions or repeated patterns:
■ Section 3.9, "Repetitive Rule Patterns and Redundancy" on page 3-17
2.12 Do You Need to Express Compatibilities in Your Model?

This means you have many options that require and exclude other options. There are
several ways to implement this to achieve optimal performance and maintainability.

Do you need to express incompatibilities in your model?
Rule Decisions
Apply the following best practices when optimizing a rule design that expresses
compatibilities or incompatibilities among options:
■ Section 3.12, "Compatibility Rules" on page 3-21
2.13 Do You Need to Express Comparisons in Your Model?

This means you need to compare, balance, or rate one set of options against another
set of options. Comparison rules could affect usability by requiring end users to retract
selections before being able to continue. Under specific circumstances involving initial
values, Comparison rules can also lock during propagation.

Does your model contain comparison logic?
Rule Decisions
Apply the following best practices when optimizing a rule design that expresses
comparisons:
■ Section 3.13, "Comparison Rules" on page 3-23

Do You Need to Express Comparisons in Your Model?

3
Best Practices
Before reading this chapter, review the design questions in Chapter 2 to help you
identify best practices that are relevant to your Oracle Configurator project.
Applying the following best practices in various combinations will improve the
performance, usability, maintenance, and scalability of your configuration models:
■ Explicit Model Structure Versus Abstractions
■ Explicit Model Structure Versus References
■ Optional and Multiple Instantiation
■ Guided Buying or Selling
■ Shallow Versus Nested or Deep Hierarchy
■ Items Versus Alternatives to Items
■ Large Option Features and Option Classes
■ Defaults Rules Versus Alternatives to Default Selections
■ Repetitive Rule Patterns and Redundancy
■ NotTrue Logical Function Imposes Order and Causes Locking
■ Compatibility Rules
■ Comparison Rules
■ Connectors with Connection Rules
■ User Interfaces With Optimal Usability and Performance
■ Large Amounts of End-User Data Collected Using Configurator Extensions
■ Configurator Extension Design
Many of these best practices include detailed instructions. You can gain useful
information by reading all of them, even though some are not directly connected to a
design question. To understand these best practices, you must be familiar with the
specifics of creating configuration models. See the Oracle Configurator Developer User’s
Guide for details.
3.1 Explicit Model Structure Versus Abstractions

Abstraction is a design approach used to optimize performance and usability of a
configuration model by reducing many related products or product elements to
generic elements and eliminating repetition.
Best Practices 3-1

Explicit Model Structure Versus Abstractions
Many companies define BOM Models as an explicit representation of their products

with no abstractions to streamline the structure or volume of items. See Section 3.1.1,
"Explicit Structure" on page 3-2 for an example. Loading all BOM Models and
presenting entire product lines to end users for selection may result in poor
performance and usability. An alternative approach transforms many explicit BOMs
into one root BOM referencing a smaller number of configurable components that are
abstractions of related structure. Such a model loads faster, representing improved
performance. Configurator usability is improved by confining end-user access to only
those optionally added instances of the configurable components that are needed in
the configuration.
3.1.1 Explicit Structure

Explicit Model structure contains no abstractions and no References. Figure 3–1 shows
a series of explicit Models, each containing the same BOM Option Class.
Figure 3–1 Explicit Model Structure
Figure 3–1 illustrates 1,000 Models repeating explicitly, each containing repeating
elements. One BOM Option Class in each Model contains Options that repeat across
the 1,000 BOM Option Classes, while another BOM Option Class contains Options
unique to each of the 1,000 BOM Model.
Duplicate structure or common elements that are explicitly repeated in hundreds or
thousands of Models do not scale well as your business grows. Many explicit Models
with repetitive structure require repetitive maintenance.
It may not be possible or necessary to change your explicit Models to take advantage
of abstractions and references, for any of the following reasons:
■ You wish to preserve existing BOM Model and routing definitions
■ You need to source each explicit Model to a different organization, supplier, or
flow line.
■ You can adjust your hardware and memory to accommodate many or large
explicit Models
■ The number of explicit Models is not large enough to significantly affect
maintenance, scalability, and performance

Explicit Model Structure Versus Abstractions
■ The explicit Models are not large enough to significantly affect maintenance,
scalability, and performance
3.1.2 Abstractions
An abstraction is a generic part that expresses all the essential characteristics of a
specific part. For example, the related models shown in Figure 3–1 can be redefined as
one top-level root Model containing a BOM Option Class or BOM Model submodel
whose contents is M1 through M1,000 redefined as ATO Items. Figure 3–2 shows M1
through M1,000 each containing their unique elements as BOM Standard Items. The
repeating elements occur only once as a child BOM Option Class under the top-level
root Model.
Figure 3–2 Abstraction of Related Products
The redesign with abstractions shown in Figure 3–2 is easier to maintain than the
Models in Figure 3–1. See Section 3.1.3, "Downstream Consequences in Other Oracle
Applications" on page 3-4 for a discussion of the possible trade-off when choosing this
kind of redesign.
Best Practices 3-3

Explicit Model Structure Versus References
Together with optional instantiation and referencing, abstractions perform and scale
better than structure containing explicit, related product definitions. For details about
referencing and optional instantiation, see Section 3.3 and Section 3.2. Additionally,
turning non-orderable items into alternatives such as Features could further optimize
the structure. For details about alternatives to items, see Section 3.6 on page 3-10.
3.1.3 Downstream Consequences in Other Oracle Applications

A separate, explicit ATO Model is sourced from only a single organization or supplier.
Multiple sources and option-dependent sourcing are not supported. In Figure 3–2, all
the configured items M1 to M1000 are sourced in the same organization. If you need
configurations of these Models to come from different organizations, you need to use
an explicit structure such as shown in Figure 3–1.
In Figure 3–2, all the configured items M1 to M1000 are built on the same flow line
defined in Flow Manufacturing. If you need configurations of these Models to be built
on different flow lines, you need to use an explicit structure such as shown in
Figure 3–1.
Models M1 to M1000 are unique because they contain components (such as Options
X1, X2, and so on) available only to one of the Models (M1). The abstraction of Models
M1 to M1000 as ATO items in Figure 3–2 must include those components as BOM
Standard Items under the Option Classes M1 to M1000. For a configuration to contain
selections from Options A to ZZ, as well as one of the ATO items, change the BOM
Models so Options X1, X2, and so on do not appear under an Option Class. In
configurator, you would only see options M1 to M1000 and A to ZZ. All mandatory
components (X1, X2, X3 and so on) just appear on the BOM under M1.
Each configuration of the explicit Models M1 to M1000 results in one bill of material
and routing definition to build the entire configuration. After moving the abstract
top-level root Model, each configuration receives its own bill of material and routing,
and each of the ATO item options (M1-M1000) maintains its own bill of material and
routing. This can be avoided if M1 to M100 are defined as phantom items. However,
phantom items do not participate in Available To Promise (ATP) and Advanced
Planning.
3.1.4 Related Best Practices and Relevant Case Studies

Top-level root Models typically access abstract structure through referencing. See
Section 3.2, "Explicit Model Structure Versus References" on page 3-4.
Referencing and abstractions alone do not address performance and memory issues
associated with instantiating many components at runtime. See Section 3.3, "Optional
and Multiple Instantiation" on page 3-6 and Section 3.7.1, "Grouped Versus Ungrouped
Items" on page 3-12. See also Section 3.6, "Items Versus Alternatives to Items" on
page 3-10.
The case study described in Chapter 4, "Many Large BOM Models" illustrates the use
of redesigning explicit structure as abstractions.
3.2 Explicit Model Structure Versus References

It is good modeling practice to use referencing instead of explicit structure if your
configuration models contain:
■ Duplicate or repeating product information
■ Common elements or product definition

Explicit Model Structure Versus References
3.2.1 Explicit Structure

Figure 3–1 on page 3-2 shows examples of many related products defined explicitly in
Models.
3.2.2 Model References

Models with References are easier to maintain and require less memory to load than
structure containing explicit common product definitions.
When importing BOMs, all submodels in the top-level root BOM Model are imported
as references. See the Oracle Configurator Implementation Guide for information about
BOM structure after it has been imported into the CZ schema.
3.2.2.1 Referencing BOM Option Classes

BOM Option Classes cannot be shared by reference. Redesigning the BOM Option
Class in M1 through M1,000 in Figure 3–1 so that it can be referenced requires turning
it into a phantom ATO model containing Option A through Option ZZ. Figure 3–3
shows the BOM Option Class redefined as a phantom ATO model so that it can be
referenced in M1 through M1,000.
Figure 3–3 Another Possible Abstraction of Related Products
Changing BOM Option Classes into BOM Models has the following consequences
within Oracle Configurator:
■ BOM Models cannot express a mutually exclusive relationship
■ BOM Model Items cannot participate in Compatibility Rules because
Compatibility Rules define compatible relationships only between Features or
BOM Option Classes
Best Practices 3-5

Optional and Multiple Instantiation
■ BOM Models with a logic state of true do not allow the last available Option to be
set to true
Note: If you have redesigned BOM Option Classes as phantom

ATO Models, you cannot specify a value greater than 1 to the
Instances Maximum.
3.2.2.2 Non-Imported Model References

Referencing is a technique used to optimize development and maintenance of a
configuration model in which the same submodel appears multiple times in the
structure. Replacing each explicit occurrence of the submodel with References to a
separate Model that represents the submodel can also improve runtime performance.
Additionally, it is a good idea to place a Component with repetitive structure within a
non-imported Model and then create References to that Model. See the Oracle
Configurator Developer User’s Guide for information about using Model referencing in
configuration models.

A BOM submodel behaves like a BOM Option Class in most of the Oracle Applications
if you leave the Supply Type of the BOM submodel set to phantom on its parent BOM
Model.
In Flow Manufacturing, some conveniences in defining BOM Option Classes are not
available when defining BOM Models. For example, you cannot create a common
routing for all BOM Models as you can for all BOM Option Classes under a parent
BOM Model.

Referencing is used when creating abstractions. See Section 3.1, "Explicit Model
Structure Versus Abstractions" on page 3-1.
See Chapter 4, "Many Large BOM Models".
3.3 Optional and Multiple Instantiation

Optional instantiation is an implementation approach used to optimize performance of
a configuration model by creating a component instance only if and when it is needed.
This prevents Oracle Configurator from loading model elements at initialization that
may not be selected or needed in the configuration session.
Multiple instantiation is an implementation approach used to optimize usability by
allowing end users to create and individually configure multiple occurrences of a
Model or Component at runtime, as needed. For more information about multiple
instantiation, see the Oracle Configurator Developer User’s Guide.
3.3.1 Optional Instantiation of BOM Option Classes

It is good modeling practice to convert a large hierarchy of BOM Option Classes to a
hierarchy of optionally instantiable BOM Models. For guidance in converting BOM
Option Classes into BOM Models, see Section 3.2.2.1, "Referencing BOM Option
Classes" on page 3-5. The selective instantiation improves runtime memory usage and
reduces caching of redundant data. For example, if M1 through M1,000 in Figure 3–1
contained more structure, as shown in Figure 3–4, the resulting large number of Model

elements that need to be loaded and instantiated could affect performance and
usability adversely.
Figure 3–4 Explicit Nested Hierarchy
Rather than load all the explicit, nested BOM Option Classes of Figure 3–4, define
them once as BOM Models and include them by reference in M1 through M1,000, as
shown in Figure 3–5. Be aware of the consequences of changing BOM Option Classes
into BOM Models, as described in Section 3.2.2.1, "Referencing BOM Option Classes"
on page 3-5.
Figure 3–5 Referenced Nested Hierarchy
To save additional memory and improve runtime performance, make the References in
Figure 3–5 optionally instantiable.
Not loading instances at start up and instead implementing optional instantiation can
result in significant performance improvement. However, requiring end users to
instantiate many components interactively one at a time may affect usability. Instead,
Best Practices 3-7

implement guided buying or selling to find out how many instances the end user
needs and implement a Configurator Extension that instantiates that number of
components all at the same time.
With optional instantiation, as with multiple instantiation, instances cannot be created
using rules. Either the minimum is set, the end user clicks an Add button, or a
Configurator Extension adds instances based on inputs. Using optional instantiation in
a generated UI of the BOM structure results in Add buttons that end users must
understand how to use to complete a configuration. If your end users are not product
experts, consider using guided buying or selling questions. See Section 3.4 on page 3-9
for details.
3.3.2 Setting Node Values After Adding Instances

Design your UI flow and Configurator Extension so that instances are added when
there are as few settings as possible. Adding an instance causes all previous requests to
be retracted, after which the requests are added and reasserted. This occurs with each
component addition. It is good modeling practice to delay setting the states or values
of nodes until after all instances are added either at startup (with a Configurator
Extension bound to the postConfigNew event) or early in the end-user flow of a
configuration session. See also Section 3.8.4, "The postConfigNew Configurator
Extension" on page 3-15.
Adding an instance is particularly expensive when there are default values set by
configuration rules. Retracting default assertions is time-consuming and iterative. See
Section 3.8, "Defaults Rules Versus Alternatives to Default Selections" on page 3-14 for
details. The initial values set in Configurator Developer for Boolean Features should
also be regarded as default values.

See Section 3.2.3 on page 3-6 for the effects on Oracle Applications of changing a BOM
Option Class into a BOM Model.
Multiple instantiation of submodels is only available if the parent ATO BOM Model’s
Supply Type is set to non-phantom. This means that each configured instance of the
Model receives its own configuration Item number, bill of material, and routing, and is
built or bought individually.
3.3.4 Large Numbers of Instances

If your Model has large numbers of instances, check for similarity among instances. If
many sibling components are nearly identical, meaning they only differ in the value of
their attributes and are not distinguished by connectivity, consider representing the
entire set of instances as a single instance. You can store the set of attribute values
offline or in a custom table.

See Section 3.2, "Explicit Model Structure Versus References" on page 3-4.
See Section 3.7, "Large Option Features and Option Classes" on page 3-12.
See Chapter 4, "Many Large BOM Models".

Shallow Versus Nested or Deep Hierarchy
3.4 Guided Buying or Selling

Guided buying or selling questions are intended to guide end users to specific
selections and valid configurations.
The size or complexity of your Model may cause usability or performance problems at
runtime. Large models, even if not complex, may require large amounts of memory to
load, or require end users to make many selections or page through many options.
Complex models, even if not large, may require long end-user think time and
complicated navigation. Under these circumstances, you can simplify or streamline the
end-user’s experience by defining guided buying or selling structure.
Guided buying or selling questions gather user inputs to accomplish any of the
following scenarios:
■ End users reach a valid configuration solely by answering guided buying or
selling questions
■ End users complete a configuration by making additional selections after their
answers to guided buying or selling questions make an initial set of selections
■ End users only see a narrowed set of selections after answering guided buying or
selling questions
You implement these behaviors by adding rules that tie the end-user inputs to the
selection or exclusion of options.
Generating a default UI for a large imported BOM may result in an unreasonably large
and poorly performing runtime session. You can use guided buying or selling UI
structure to control which elements of the imported BOM you want exposed and
visible in the UI. This requires defining rules that associate the guided buying or
selling UI structure to the BOM Model items and disabling the UI visibility attribute of
the BOM nodes before generating the UI.
3.5 Shallow Versus Nested or Deep Hierarchy

The depth of Model structure is determined by the levels of hierarchy contained under
the root node. Shallow structure is acceptable when not displaying BOM nodes in the
UI. A shallow structure generally decreases the size of the configuration model and
potentially eases downstream processing.
Deeply nested structure takes advantage of the performance gains made when using
optional instantiation to load only those parts of the Model structure that are needed.
Nesting items into deeper structure can also ease Model maintenance. However, deep
nesting may distribute end-user selections across UI pages in a manner that requires
end users to flip back and forth as they check previous selections. When this is the
case, guided buying or selling questions can significantly ease navigation flow. See
Section 3.4 for additional information about guided buying or selling.
Related Best Practices

See Section 3.2, "Explicit Model Structure Versus References" on page 3-4 for
descriptions of nested structure. Nested or deep hierarchy affects performance when
used with optional instantiation. See Section 3.3, "Optional and Multiple Instantiation"
on page 3-6.
Relevant Case Studies

See Chapter 4, "Many Large BOM Models" and Chapter 5, "Many BOM Items".
Best Practices 3-9

Items Versus Alternatives to Items
3.6 Items Versus Alternatives to Items

Items either need to appear on the order line, or they need to represent characteristics
that are needed as input somewhere in the process. Some item information is only
needed as a temporary value during configuration.
You should define Inventory Items only for elements of your structure that need to be
ordered or routed downstream from Oracle Configurator. For example, elements of
Model structure that must appear on an order line and are picked or assembled for
shipping need to be Inventory Items.
Alternatives to Inventory Items are Option Features or configuration attributes. For
upstream item information that is needed in Configurator computations or for
downstream processing such as calculations or passing along information about an
item, you should define an alternative to Items.
For example, if you have raw materials that are ordered by lengths, do not create an
item for each length. Instead, define a single item for each raw material with an
attribute: Length. Then capture the needed length from the end user by a numeric
input or from a List of Options, and associate that input with the attribute.
For another example of changing explicit items into Features, compare Figure 3–1,
"Explicit Model Structure" on page 3-2 with Figure 3–2, "Abstraction of Related
Products" on page 3-3.
3.6.1 Values Needed For Configuration Only

If the value is not needed in any way downstream but only for completing the
configuration, use non-BOM Features and Options. These values cannot participate in
downstream calculations.
For information about leveraging the power of Properties, see Oracle Configurator
Developer User’s Guide.
3.6.2 Values Needed Downstream

If the value is needed downstream, such as in Fulfillment or Billing Integration, and
represents a Configurator computation or inputs from the end user, you can define
configuration attributes to pass along those inputs. For performance reasons, it is
optimal to define as few attributes as possible. Omit Feature and attribute definitions
from your Model structure whose values can be referenced from other Model structure
or computed in custom code downstream from other attributes. If a value cannot be
referenced or computed using custom code, minimize the set of attributes and
Features you define in the Model structure. If an attribute is shared among multiple
components, use inheritance to share the Feature in which the attribute is defined.
See the Oracle Configurator Methodologies book for details about implementing
configuration attributes. Note that configuration attributes are not accessible to
downstream applications without customization.
For example, consider a Container Model that defines a configurable Public Switched
Telephone network (PSTN). The top-level Model contains two Components: Primary
Line (1/1) and Child Line (29/29). Each Component contains Items such as
Application date, Billing date that have been modeled as attributes of Features and are
required for downstream processing. All the Features are hidden in the runtime UI. A
Configurator Extension rule gets the required attribute values from custom code
outside Configurator and copies the values for the model and its submodels. The
duplication of data across many models and the process of copying the values causes

Items Versus Alternatives to Items
poor performance when the configuration is saved, restored, or during batch

validation.
Example 3–1, shows a better Model design that moves all the duplicated common
attribute Features to the top-level Container model.
Example 3–1 Model Design with Minimal Set of Features
The design includes attribute Features for unique attributes at the individual Model
level. A Configurator Extension copies the value from the custom application to the
top-level Features. Attribute Mode set to ALL propagates the value from the top-level
Model to all the submodels.
Best Practices 3-11

Large Option Features and Option Classes

See Chapter 5, "Many BOM Items".
3.7 Large Option Features and Option Classes

If your Model contains large BOM Option Classes or Option Features, evaluate the
following best practices for possible use in your project:
■ Grouped Versus Ungrouped Items
■ Maximum Selections on Large Option Classes or Features
■ Alternatives to Option Features With Many Options
If your design cannot eliminate the need for configuring BOM Option Classes with
large numbers (for example, hundreds) of Items, be aware that the Generic
Configurator UI does not perform faster than a generated Configurator UI. With the
generated Configurator UI you can use multiple screens to display BOM Option
Classes with large numbers of Items. If you are using guided buying or selling
questions, hide all the Items and have the guided selling questions drive the selections.
See Section 3.4, "Guided Buying or Selling" on page 3-9 for more information.
3.7.1 Grouped Versus Ungrouped Items

In cases where there are many options to choose from, the end user’s experience and
Oracle Configurator performance can be improved by grouping items into BOM
Option Classes. Typically, you can improve usability and performance by combining
grouping with the use of optional instantiation. This requires changing BOM Option
Classes into BOM Models. See Section 3.3.1, "Optional Instantiation of BOM Option
Classes" on page 3-6 for details.
For example, a manufacturer of upholstered furniture lets customers select fabrics
from a huge inventory, including solids, stripes, floral prints, and geometric patterns.
Rather than have end users flip through screen after screen of swatches in no
particular order, the configuration experience can be organized by types of fabrics, and
only the group that is selected needs to be loaded into memory. End users select one
from a subset of fabrics, thereby reducing the number of displayed options. The
inventory that does not need to be displayed to the end user is not instantiated.
Grouping items can also ease Model maintenance.
3.7.2 Maximum Selections on Large Option Classes or Features

Defining a Maximum Selections on a large BOM Option Class or Option Feature can
adversely affect performance. If an Option Feature contains an Option that participates
in a rule, propagation of that rule triggers a count of the current number of selected
Options. If the maximum number of Options specified by the value of Maximum
Selections is reached, this rule propagates Logic False to all unselected Options. If the
number of Options is large, propagating Logic False or retracting and reasserting the
logic state on all the Options can cause slow performance.
The best way to improve performance is to restructure the Model or BOM Model to
contain Option Features or BOM Option Classes with fewer Options or Items.
If your business requirements demand many options and a maximum number that can
be selected, and you need the remaining options to be Logic False after the maximum
is reached, then you must set the Maximum Selections and incur the performance
cost.

Large Option Features and Option Classes
However, since the runtime display icons for both Logic False (from maximum
reached) and Unknown states indicate that an Option is available for selection, your
logic requirements may permit you to set the Maximum Selections to no value and
define the number of allowable selections by using a rule that counts the selected
Options. For example, if you want only three Options to be selected from a Feature,
impose that maximum by defining a Total, a Numeric Rule, and a Logic Rule with
CDL or as a Statement Rule as shown in Example 3–2.
Example 3–2 Maximum Selections Imposed by a Rule

One Feature, F1, contains five Options, and a second Feature, AlwaysTrue, contains
one Option, as shown in the following design:
The rules:
Total T1 tracks the number of options selected.
Numeric Rule: EachOf (Options of F1) Contributes 1 to T1
Statement Rule expressing a Logic Rule with the following expression for Operand
2: AlwaysTrue Requires Total < 4
At runtime, when the end user selects O1, O2, and O3, the number of selections is less
than 4. When the end user selects O4, the Logic Rule displays a violation message. The
violation message can be customized to explain that the maximum number of
allowable selections has been exceeded.
If your business requirements demand many options and a maximum number that can
be selected, and it does not matter to your implementation whether Options are
Unknown or Logic False, then having them be Unknown is better. The Oracle
Configurator engine does not push the Unknown state to other options that are
connected through rules, except if NotTrue is used. Design your configuration model
so that valid configurations are allowed even when numerous Options are Unknown.
That way the CIO and the Oracle Configurator engine process fewer changes on each
end-user action. For example, use the suggested rule for counting selected options to
minimize the propagated Logic False states, instead of the regular Maximum
Selections.
3.7.3 Alternatives to Option Features With Many Options

When an Option from a large Option Feature participates in a rule, the propagation of
that rule triggers an evaluation of all that Feature’s other Options. (This does not apply
to BOM Option Classes and BOM Standard Items.) However, if no Options participate
in rules or the Option Feature is not constrained by a maximum number of Options
Best Practices 3-13

Defaults Rules Versus Alternatives to Default Selections
that can be selected, redesign the Options as Boolean Features. Create a Component
containing the Boolean Features or design all selectable Options as BOM structure.
Example 3–3 Redesigning Unconstrained Options as Boolean Features

A Feature called Finish contains four independent furniture finishing Options, as
shown in the following design:
Since end users can select any Option independent of the other Option selections, it is
better to define a Component containing a Boolean Feature for each Option.
3.7.4 Relevant Case Studies

See Chapter 5, "Many BOM Items".
3.8 Defaults Rules Versus Alternatives to Default Selections

Defaults Logic Rules reduce the number of required end-user selections by providing
the following:
■ Initial values when Oracle Configurator is launched
■ Filled-in values during the configuration session based on end user selections
■ Filled-in values at the end of the configuration session to complete the
configuration
Some implementations of Defaults relation can cause performance problems at
runtime, especially when propagation of the defaulted items affects many other items.
This is because the Oracle Configurator engine retracts default values before applying
or reapplying user requests or adding or deleting components.
3.8.1 Evaluating the Need for Default Selections

When designing a configuration model, add Defaults Logic Rules at the end of the
design process and weigh the performance cost of adding them against the perceived
benefit to the end user.
The following considerations can help you determine the usefulness of setting initial
values:
■ Analyze how often the end user changes the default selections that are
automatically made by these rules. If you expect that default selections are often
changed, then you will gain runtime performance by removing those Defaults
relations.

■ Analyze the runtime performance when Defaults relations are active, compared to
when the Defaults relations are disabled and end users have to make initial
selections explicitly.
3.8.2 Activating Defaults on End User Request

If you intend to apply default values to complete the configuration session rather than
set selections during the configuration session, design the Defaults Logic Rules so they
are not processed at runtime until the end user requests them. For example, create a
Boolean Feature at the root of the Model for this purpose. This Boolean Feature could
be called ApplyDefaults.
1. Create a Statement Rule with Operand 1 of the Defaults relation defining a
condition.
2. In every Defaults relation, replace
X Defaults Y
where X is the condition, and Y is the result, with

AllTrue (X, ApplyDefaults) Defaults Y
Note that it is enough to define this rule as AllTrue (Apply Defaults) if X is

always true.
3. Write a Configurator Extension bound to the preConfigSave event that sets the
ApplyDefaults Boolean Feature to True. This causes applicable Defaults to be
applied so their consequences appear in the output.
4. Write a Configurator Extension bound to the postConfigRestore event that
unsets ApplyDefaults. This allows the configuration session to proceed in the
absence of defaults. Since this Configurator Extension could cause unnecessary
work during batch validation, consider using Step 5.
5. Optionally, make the ApplyDefaults Boolean Feature visible in the User Interface
so the end user can turn it on and see the consequences of the Defaults. Since this
is expensive in terms of performance, the end user might elect to use it sparingly.
If you do not make the ApplyDefaults Boolean Feature visible, line items and prices
may appear in the order that the end user was not aware of during the configuration
session.
3.8.3 Boolean Features With Initial Values

Boolean Features with an initial value (True or False) cause slow performance because
they behave like Defaults Logic Rules. Leaving the initial value Unknown improves
performance.
3.8.4 The postConfigNew Configurator Extension

A Configurator Extension bound to the postConfigNew event simulates the behavior
of setting initial default values, but avoids the cost of repeatedly retracting and
reapplying default values after the end user makes selections involving Defaults
relation participants. However, there are consequences to using the Configurator
Extension that you should consider. Example 3–4 and Example 3–5 show the
differences in behavior during the runtime selection process between Defaults
relations and Configurator Extensions that simulate Defaults relations.
Best Practices 3-15

Example 3–4 Defaults Rule Behavior at Runtime

Two Features contain different Options, as shown in the following design:
The rules.
F1 has a Maximum Selections set to 1
F1 Defaults A
E Requires B
At startup, A is selected. The end user selects E. B is selected and A is set to Logic
False. No contradiction occurs when B is selected and A is deselected.
If you set Hide when unselectable, F1 displays A, B, and C. A is selected. B and C are
available for selection.
Example 3–5 Configurator Extension That Simulates Defaults Rule

Using the same two Features shown in Example 3–4, define the following rules:
Configurator Extension selects A
E Requires B
At startup, A is selected. The end user selects E. Oracle Configurator displays a

contradiction message asking the end user to override the contradiction to select
Option B. This is because settings made by the Configurator Extension have the status
of an end-user request.
In this case you cannot also use Hide when unselectable, because F1 displays only A.
A is selected. B and C are hidden.
3.8.5 Implies Relation Instead of Defaults Relation

In some rare cases, an Implies relation can be used instead of a Defaults relation if your
end users do not need the flexibility to change the default value.
Example 3–6 Implies Rule Provides Behavior of an Unoverridable Defaults Rule

Two Features contain different Options, as shown in the following design:

Repetitive Rule Patterns and Redundancy
The rules.
Option 1 Defaults Option 4
or
Option 1 Implies Option 4
At runtime, both rules cause Option 4 to become selected when the end user selects
Option 1. The Defaults relation gives end users the flexibility to override the default
value and select Option 5 or Option 6 when Option 1 is selected. If you your end users
do not need that flexibility, use the Implies relation and only Option 4 can be selected
when Option 1 is selected.
3.9 Repetitive Rule Patterns and Redundancy

Repetitive patterns or redundancy means that several rules include the same
subexpressions or have the same result. This could cause performance issues.
3.9.1 Repetitive Patterns and Common Subexpressions

The Oracle Configurator engine separately evaluates and propagates each instance of
the subexpressions of every rule, even if there are commonly used patterns of
operators and operands in those subexpressions. Consequently, a large number of
rules with common subexpressions impairs performance by triggering redundant
calculations of the subexpressions.
Subexpressions are defined within a pair of parentheses, and every pair of parentheses
is treated as a subexpression using the conventional order of operations.
Example 3–7 shows two rules containing a common calculation contributing to a
Resource.
Example 3–7 Rules With Common Subexpressions

[(A + B) * C] contributes to R1
[(A + B) * C] + D contributes to R2
Create an intermediate node (I1) to contain the value of the commonly used
subexpression and create an intermediate rule that contains the subexpression
[(A + B) * C] and the intermediate node:
[(A + B) * C] contributes to I1
The original rules can then be rewritten by replacing the common subexpression
with the new node that expresses the intermediate rule.
I1 contributes to R1
I1 + D contributes to R2
Although this technique creates an additional rule (the definition of the common
subexpression), the effect of replacing repeating patterns in rules with nodes that
represent those patterns is that Oracle Configurator only computes the subexpression
once, thereby reducing the calculation required for each rule containing the common
subexpression.
Best Practices 3-17

Repetitive Rule Patterns and Redundancy
Note: When you use the technique of replacing common

subexpressions with intermediate nodes, you must customize the
violation message of the intermediate rule to explain the
contradiction in terms of the rules that contain the intermediate
rule. In other words, the default violation message for I1 in
Example 3–7, which is displayed to the end user when Oracle
Configurator encounters a problem with R1 or R2, describes a
contradiction in I1 unless you customize the message to explain the
error in terms of R1 and R2.
3.9.2 Redundancy
Redundant rules create numeric cycles, which cause slow performance. Example 3–8
shows two redundant rules.
Example 3–8 Redundant Rules

Rule 1: A Implies B
Rule 2: A Contributes to B
In Example 3–8, Rule 1 results in the following behavior:

1. When A is selected, B is selected. The state of A and B is true.
2. When B is deselected, A is deselected. The state of A and B is false.
Rule 2 then results in the following behavior:
3. When A is selected, the count of B is set to 1 and the state of A and B are true.
4. When B is excluded, A is excluded
If you want the behavior described in Step 1 and do not care about the behavior
described in Step 2, then Rule 1 (A Implies B) is redundant and all you need is Rule 2
(A Contributes to B). If you want the behaviors described in Steps 1, 2, and 3, but you
do not care about the behavior described in Step 4, then Rule 2 (A Contributes to B) is
redundant. If you want all four behaviors, then you need to define both rules.
3.9.3 Circular Propagation

Circular rules involving both logic and numeric rules result in Oracle Configurator not
being able to settle on a final result. Example 3–9 shows four rules that are circular.
Example 3–9 Circular Rules (Logic and Numeric)

A Contributes to B
B Contributes to C
C Requires D
D Contributes to A
Examine all possible actions or inputs and their results to show where the propagation
path does not settle on a result but cycles through the rule again and again. In
Example 3–9, the following sequence of events occur when you set A to 3:
Set A =3
B is set to 3, and true
C is set to 3, and true
D is set to 1, and true
A is set to 4, and true

Number and Complexity of Rules
The circularity stops at this point, because D is already set to 1, and true.
Numeric Rules cause numeric cycles, as shown in Example 3–10.
Example 3–10 Numeric Cycles

A Contributes to B
B Contributes to C
C Contributes to A
In Example 3–10, the following sequence of events occur when you set A to 3:
Set A =3
B is set to 3, and True
C is set to 3, and True
A is set to 6, and True
Examining all possible actions or inputs and their results suggests that these rules
would continue to propagate without end. However, Oracle Configurator catches the
error in Example 3–10 as a runtime numeric cycle failure.
Optimize the configuration problem to avoid creating rules that create cycles.
One way to debug redundancy and cycles is to turn rules on or off by explicitly
disabling them at the rule or Folder level. For a review of logic states and other
information related to rules, see the Oracle Configurator Developer User’s Guide. See the
Oracle Configurator Performance Guide for a discussion about the effect of the quantity
and complexity of rules on runtime performance.
3.10 Number and Complexity of Rules

Complex or large numbers of rules within a configuration model could cause slow
performance. Whenever possible, use effectivity dates or Usages to turn off rules that
are not necessary in certain contexts of the calling application. That lets the Oracle
Configurator engine ignore those rules and propagate among the enabled rules more
efficiently. When debugging configuration models, disable rules explicitly at the rule
or rule folder level to let the Oracle Configurator engine ignore them.
Large numbers of rules with commonly used subexpressions also cause slow
performance. When the Oracle Configurator engine propagates such rules, even if
there are commonly used patterns of operators and operands, the engine needs to
evaluate and propagate each instance of the common subexpression separately.
Consider Example 3–11 showing two rules with a common calculation contributing to
a Resource.
Example 3–11 Rules With Common Subexpressions

[(A + B) * C] contributes to R1
[(A + B) * C] + D contributes to R2
Create an intermediate node (I1) for the commonly used subexpression and create
an intermediate rule that contains the subexpression [(A + B) * C] and the
intermediate node.
[(A + B) * C] contributes to I1
Best Practices 3-19

NotTrue Logical Function Imposes Order and Causes Locking
The original rules can then be rewritten by replacing the common subexpression
with the new node that expresses the intermediary rule.
I1 contributes to R1
I1 + D contributes to R2
Although this technique creates an additional rule, the net effect of replacing repeating
patterns in rules with nodes that represent those patterns is that the Oracle
Configurator only computes the subexpression once, thereby reducing the amount of
calculation required for each rule that contains the common subexpression.
WARNING: When you use the technique of replacing common

subexpressions with intermediate nodes, you must customize the
violation message of the intermediary rule to explain the
contradiction in terms of the rules that contain the intermediary
rule. In other words, the default violation message for I1 in
Example 3–11, which is displayed to the end user when Oracle
Configurator encounters a problem with R1 or R2, describes a
contradiction in I1 unless you customize the message to explain the
error in terms of R1 and R2.
3.11 NotTrue Logical Function Imposes Order and Causes Locking

The logical function NotTrue is used in CDL and Statement Rules.
3.11.1 Order Dependency Caused By NotTrue

Using NotTrue in CDL or Statement Rules can impose an order for rule propagation
that makes the configuration model harder to design and use. Rule order diminishes
the flexibility with which end users make selections. For example, if the intention is to
have one Option, Y, not be selected until another Option, X, is selected, then using
NotTrue achieves this result, but alternative rule definitions have a similar effect
without causing order dependency.
If the rule is NotTrue(X) Excludes Y, the following occurs at runtime:
1. Initially, X is unknown and Y is not available for selection (false).
2. When X is selected (true), Y becomes unknown, or available for selection. If Y is
selected, X remains true.
3. If X is deselected (false), Y becomes false.
If you want Y to be unavailable for selection until X is selected, you need to use
NotTrue(X) and incur the cost of imposed order in the rule propagation. If you only
need to make sure that Y is never selected when X is not selected, you can express this
with less restrictive alternative rules
For example, Not(X) Excludes Y preserves the original intent of ensuring that Y cannot
be true without X being true, but X can be true without Y being true. If the rule is
Not(X) Excludes Y, the following occurs at runtime:
1. Initially, X is unknown and Y is unknown, or available for selection.
2. When X is selected (true), Y remains unknown. If Y is selected (true), X becomes
selected (true).
3. If X is deselected (false), Y becomes deselected (false).

Compatibility Rules
Both these rules use a double negative (which may be difficult to understand) and a
subexpression (which compromises efficiency).
An optimal alternative rule is Y Implies X, which imposes no order and avoids the
double negative and subexpression of the previous alternative. If the rule is Y Implies
X, the following occurs at runtime:
1. Initially both X and Y are unknown and available for selection.
2. When Y is selected (true), X becomes selected (true).
3. If X is deselected (false), Y becomes deselected (false).
Although this rule preserves the original intent of ensuring that Y cannot be in a sales
order without X, it does not allow X to be in the sales order without Y.
3.11.2 Locked States Caused By NotTrue

Using NotTrue can result in a locked state for the initial values of some items. In the
following example, Model X contains the following structure:
Options Feature A, containing some Options
Options Feature B, containing some Options
Your project requires that Feature B should be false and not displayed to the end user
until an Option in Feature A is selected.
When an Option in Feature A is selected, Feature B should be true and displayed to
the end user. End users must select an Option from Feature B to satisfy the
configuration.
The following rules fulfill the requirements:

Rule 1: NotTrue(A) Excludes B
Rule 2: A Implies B
Initially, as a consequence of Rule 1, A is unknown and B is false. As a consequence of

Rule 2, A is made false when B is false. Rule 1 and Rule 2 together result in both A and
B being false, which is a locked state. Changing the state of either A or B results in a
contradiction.
To accomplish the intent of Rule 1 without locking, create a display condition in Oracle
Configurator Developer that hides Feature B until an Option in Feature A is selected.
Locking also results from embedding a NotTrue expression within a series of rules
involving the same operands. Consider the following rule:
NotTrue(A) Implies B
If A is an Option of a Feature whose other Options participate in other rules that side
effect A and B (such as through a maximum number of selections setting), then A
being NotTrue locks the series of rules from completing. To avoid this locking, do not
use the participants of a NotTrue expression in any other rules.
For a review of logic states and other information related to rules, see the Oracle
Configurator Developer User’s Guide.
3.12 Compatibility Rules

When you want to express compatibility, use Compatibility Rules instead of Logic
Rules. The Oracle Configurator engine performs calculations over a large number of
Options faster with Compatibility Rules than with any other rule type.
Best Practices 3-21

Compatibility Rules
However, consider the following when designing compatibilities or incompatibilities

among items in your Model:
■ Expressing Compatibility Using Properties
■ Minimizing Participants in a Compatibility
■ Using the Excludes Relation to Express Incompatibilities
These guidelines are explained in the following sections.
3.12.1 Expressing Compatibility Using Properties

Explicit Compatibility Rules defined with a large number of participants are difficult
to maintain and can cause performance problems at runtime. It may be better to
express the compatibility among options by using a Property-based Compatibility
Rule.
For example, power supply voltage for a personal computer is determined by the
voltage used in the country where the computer will be used. The United States is
compatible with a 110 volt power supply, while France and India are compatible with
a 220 volt power supply. You can create a Property-based Compatibility Rule to
enforce this relationship at runtime.
The Model for this example includes a Feature named "Country" and a BOM Option
Class named "Power Supply Type." Preliminary steps in creating this rule are to define
a Property named "Voltage Needed" for the Feature and to define a Property named
"Voltage Supplied" for the BOM Option Class.
A Feature “Country” contains the following Options, Properties, and values:
Option Name Property Value

USA Voltage Value 110
France Voltage Value 220
India Voltage Value 220
The Power Supply Type BOM Option Class contains the following Options, Properties,
and values:
Option Name Property Value

110V Voltage Value 110
220V Voltage Value 220
The final step is to create the following Property-based Compatibility Rule that links
the Country Feature selected at runtime to the Power Supply Type BOM Option Class
voltage specified for the computer:
Operand 1:
■ Feature: Country
■ Property: Voltage Value
Operator:
■ Equals
Operand 2:

Comparison Rules
■ BOM Option Class: Power Supply Type

■ Property: Voltage Value
At runtime, when the end user makes a selection for the Country (Feature), the value
for the Voltage Value Property is determined. The Property-based Compatibility Rule
matches the value of the BOM Option Class Voltage Value to the value of the Feature
Property Voltage Value.
In this example, a Property-based Compatibility Rule design performs better than an
Explicit Compatibility Rule defining particular power supply types and the voltages
or countries with which they are incompatible. Maintenance is also streamlined. For
example, when you add a new country, you add only the Voltage Value Property
rather than modifying the rule to add the new compatibility. Or if a country changed
its line voltage, the change could be reflected in your Model by changing the value of
the Voltage Value Property.
If you needed to express compatibility between country and currency, the problem
would be more complex and the maintenance advantages of the Property-based
Compatibility solution even greater.
3.12.2 Minimizing Participants in a Compatibility

To express compatibility among Options by using Compatibility Rules, it is better to
design several Compatibility Rules with fewer participants than to define one
Compatibility Rule with many participants.
3.12.3 Using the Excludes Relation to Express Incompatibilities

If your Compatibility Rule defines a larger number of compatibilities than
incompatibilities, consider defining the incompatibilities by using Excludes relations.
For example, a Compatibility table contains compatibility between six Features, each
with two Options. This is shown in Table 3–1.
Table 3–1 Compatibility Table
A B
A1 B1
A1 B2
A2 B1
A2 B2
A3 B1
In this Compatibility table, the only incompatibility exists between Options A3 and B2.
In this case, it would be better to express the incompatibility between A3 and B2 in an
Excludes relation.
3.13 Comparison Rules

Depending on your requirements, it is generally good modeling practice to avoid rules
that raise contradictions. Instead, define rules that cause only validation failures or
warnings and therefore allow end users to proceed.
Best Practices 3-23

Comparison Rules
When defining Comparison rules, avoid involving the initial value of a Total in the
comparison. The initial value can cause locking when retracted during a numeric
cycle.
3.13.1 Comparison Rules That Raise Warnings

When defining Comparison Rules, construct your rules so they lead to a resource
violation rather than a contradiction. Rules that raise contradictions are much less
flexible because they require one or more previous selections to be deselected before
the end user can continue. A resource violation, however, only displays a warning
indicating that a specific value has been exceeded, does not deselect any options, and
allows the end user to acknowledge the warning and proceed with the configuration.
3.13.2 Using Intermediate Values Effectively With Comparison Rules

Comparison Rules that raise contradictions can also lead to problems caused by an
intermediate value. Oracle Configurator triggers each rule in a configuration model
sequentially (that is, one after another), rather than propagating all rules
simultaneously. As a result, a rule may be violated when it reaches a specific value,
even if you defined another rule to prevent the violation from occurring in the first
place. However, since the intermediate value is reached before the other rule
propagates, a violation occurs. (See Example 3–12 on page 3-24.). See also Section 3.14,
"Connectors with Connection Rules" on page 3-25 for additional reasons to avoid rule
order.
Problems with intermediate values can also occur when involving the initial value of a
Total in the comparison.
Example 3–12 Unexpected Contradictions from Intermediate Values

Model A contains the following:
■ Boolean Feature: X
■ Options Feature: F1 containing one Option1
■ Options Feature: F2 (0,2) containing two Options: Option2 and Option3
■ Numeric Feature: Z
The rules.
Logic: Boolean Feature X Requires AllOf (OptionsOf (Option Feature F2))
Numeric: EachOf (OptionsOf (Option Feature F2)) Contributes to Numeric Feature Z
Comparison: Numeric Feature Z equalto 1 Excludes Option Feature F1
At runtime, the end user selects Boolean Feature X, making the state of X true. This
makes F2 true. Propagation of Option2 makes the value of Numeric Feature Z equal 1.
The Comparison Rule causes the propagation of Z=1 to try to push the value of Option
Feature F1 false. Even though the current value of Numeric Feature Z is an
intermediate value, and the propagation of Option2 will result in a value of Z=2, a
contradiction occurs. To avoid the contradiction, consume from a Resource to keep
Z=1 when Option2 is true.
Example 3–13 Avoiding Unexpected Contradictions from Intermediate Values

Model A also contains the following:
■ Boolean Feature: Temp
■ Resource: Res

Connectors with Connection Rules
The rules.
Logic: Boolean Feature X Requires AllOf (OptionsOf (Option Feature F2))
Numeric: EachOf (OptionsOf (Option Feature F2)) Contributes to Numeric Feature Z
Comparison: Numeric Feature Z equalto 1 Implies Temp
Numeric: Temp Consumes from Res
At runtime, the end user selects Boolean Feature X, making the state of X true. This
makes F2 true. Propagation of Option2 makes the value of Numeric Feature Z equal 1.
The Comparison Rule causes the propagation of Z=1 to push Boolean Feature Temp
true. Temp consumes 1 from Resource Res. Since Oracle Configurator checks
validation failures at the end of propagation, Option3 can become true without any
validation failures.
3.14 Connectors with Connection Rules

Connection rules that involve Connector nodes in the Model structure operate only
when component instances are connected at runtime, and only among the connected
instances. The logic generated by connection rules is not initially loaded with the
configuration model at runtime. Connection rules are loaded and executed only when
the Connectors in the parent instance have been assigned to corresponding instances
of the target Models.
When an end user makes a connection, the following happens:
1. All the end-user inputs are retracted.
2. The connection is made.
3. Connection rules are loaded and executed.
4. All the end-user inputs are applied again.
This process leads to changes in values and logic that conflict with the configuration as
it was before the connection was made. The sequence in which the rules are loaded
and the end-user inputs are reapplied could cause unexpected behavior due to invalid
intermediate values. Such situations could cause fatal errors and prevent the end user
from proceeding with the configuration.
To avoid inconsistency or errors, ensure that all component instantiations and
connections can be performed independent of end-user inputs. Additionally, as with
all configuration rules, write rules that are order independent.
Consider the two models in Figure 3–6.
Best Practices 3-25

Connectors with Connection Rules
Figure 3–6 Model with a Connector
The following sections use these Models to demonstrate:

■ Connection Rules That Depend on End-User Input
■ Order Independent Connection Rules
■ Restoring Configurations With Connections
3.14.1 Connection Rules That Depend on End-User Input

The rules in the Rack Model are as follows:
Rule 1: Total < 0 Excludes Always True
Rule 2: Each Of (Options Of(Rack Type)) * Property.Weight Contributes To Total
CDL Rule 1: CONSTRAIN (Total < 0) EXCLUDES "Always True"

CDL Rule 2: CONTRIBUTE (EachOf (OptionsOf(Rack Type)) * Property.Weight) TO Total
The intent of the CONSTRAIN rule ensures that the value of Total never drops below 0
(zero).
The rule in the Server Model is the Connection rule:
Rule 3: Always True * Constant(Value) Consumes From Total
CDL Rule 3: CONTRIBUTE ((Always True * Constant(Value))* -1) TO Total
At runtime, the end user selects a Rack Type. Oracle Configurator executes Rule 2,
contributing the selected Rack Type’s Property Weight to Total. The end user then
connects to the Rack Model in the Server Model. Oracle Configurator retracts the
selected Rack Type, which resets Total to 0. Oracle Configurator loads the connection
rule, Rule 3, and consumes Value from Total (0), causing Rule 1 to be invalid. This
results in a non-overridable contradiction and the connection fails.
3.14.2 Order Independent Connection Rules

You can avoid the dependence on end-user input described in Section 3.14.1 by
creating a rule rather than an end-user input that makes the contribution. Rewrite Rule
2 in the above case as:
Rule 1: Total < 0 Excludes Always True
Rule 2: Always True * Constant(Value) Contributes To Total

User Interfaces With Optimal Usability and Performance

CDL Rule 2: CONTRIBUTE "Always True" * Constant(Value) TO Total
When Oracle Configurator starts up, a configuration is created. The end user connects
the Server Model to a Rack Model. Oracle Configurator retracts all end-user inputs,
but does not retract the Value of Total because it has been set by a rule, not an end-user
input. Then Oracle Configurator loads the connection rule, Rule 3, and consumes from
Total without a contradiction occurring.
Rule 3: Always True * Constant(Value) Consumes From Total
CDL Rule 3: CONTRIBUTE (("Always True" * Constant(Value))* -1) TO Total
This solution avoids order dependence but may still encounter intermittent failures
when a configuration is restored. See Section 3.14.3 on page 3-27 for details.
3.14.3 Restoring Configurations With Connections

Restoring a configuration created using the rules described in Section 3.14.2
intermittently results in failures. When Oracle Configurator restores a configuration,
the Oracle Configurator engine activates all the rules and the order of assertions is no
longer guaranteed. In some cases, Rule 1 and Rule 3 might be executed before Rule2,
resulting in a fatal error.
You can avoid the fatal error either by populating Total with an initial value, or using a
Resource instead of a Total. Over-consuming a resource does not result in a fatal
validation failure, which allows the end user to proceed with the configuration
session.
Rule 1: Resource < 0 Excludes Always True
Rule 2: Always True * Constant(Value) Contributes To Resource
Rule 3: Always True * Constant(Value) Consumes From Resource

CDL Rule 2: CONTRIBUTE "Always True" * Constant(Value) TO Total
CDL Rule 3: CONTRIBUTE (("Always True" * Constant(Value))* -1) TO Resource
When Oracle Configurator starts up, a configuration is created. The end user connects
the Server Model to a Rack Model. Oracle Configurator retracts all end-user inputs,
but does not retract the Value of Resource because it has been set by a rule, not an
end-user input. Then Oracle Configurator loads the connection rule, Rule 3, and
consumes from Resource without a contradiction occurring. The connection is made.
Now, when the end user restores this configuration, only a validation failure would
occur if Rule 1 and Rule 3 were executed before Rule 2. The validation failure would
not prevent the configuration from being restored.
3.15 User Interfaces With Optimal Usability and Performance

The following UI design considerations can help you tune usability.
■ Visibility Settings
■ Graphics
■ Number and Type of Pages and Controls
■ Custom User Interface
For details about creating generated User Interfaces, see the Oracle Configurator
Developer User’s Guide.
Best Practices 3-27

User Interfaces With Optimal Usability and Performance
3.15.1 Visibility Settings

Using dynamic visibility for excluded items is generally more expensive than allowing
all options to be displayed. Hiding unavailable Options incurs additional server
processing because Oracle Configurator must distinguish between purely unavailable
(false) options and locally negated options (Logic False) based on the value for the
Maximum Selections of the Option Feature.
3.15.2 Graphics
The number and size of GIFs in a page does not increase the time needed to render the
screen on the server. However, reducing the number of controls and GIFs on the page
may improve the performance of rendering the browser page on the client machine.
3.15.3 Number and Type of Pages and Controls

The number of Oracle Configurator pages and the number of UI controls on each page
influences runtime performance. Increasing the number of controls increases the time
needed to render a page. This is due to browser resource limitations, not an inherent
limitation in Oracle Configurator. Oracle recommends a maximum of 8 to 10 UI
controls and 5 graphics per page.
The type of controls on a page does not influence server performance. Drop-down
Lists and Selection Lists take the same amount of time to render. When being painted
in the client browser, it is possible that Dropdown Lists paint faster than Selection
Lists. Painting time of a Selection List UI control is dependent on how many Options
are displayed.
3.15.4 Configuration Summary User Interface Template

By default, the predefined UI Master Templates use the Summary with Status Region
Content Template to display all selected items in the Configuration Summary page at
runtime. When an end user navigates to this page, the default template automatically
expands all selected items so all of the child items are also visible. The expansion can
negatively affect performance, especially in a large configuration consisting of many
options that have children.
To improve Configuration Summary page performance:
1. Create your own configuration summary UI Content Template.
When creating the Summary Table element, deselect Expand All Levels on Entry.
2. Create a UI Master Template.
3. In the Utility Templates section of your UI Master Template, select your custom
configuration summary template.
4. Use your custom UI Master Template to generate the UI.
3.15.5 Custom User Interface

A custom UI is not a UI that you create in Oracle Configurator Developer. You create a
custom UI by writing custom code that allows your configuration model to interface
with the Configuration Interface Object (CIO). Because it interacts with the CIO, it is
important to optimize the CIO calls for best performance. For more information, see
how Configurator Extensions use CIO calls effectively.
If you are using a custom UI, note that DHTML controls that use JavaScript for
browser events take longer to display on the client than straight HTML does. If the

Configurator Extension Design
dynamism of JavaScript is not needed in your application, then implementing straight

HTML using a custom HTML template could result in a significant performance gain.
3.16 Large Amounts of End-User Data Collected Using Configurator

Extensions
In rare cases, you may have unconstrained end-user data, meaning it is not
constrained by or does not participate in rules. Collecting large amounts of that kind of
data from end users, especially if it is repetitive, can degrade the usability of the Oracle
Configurator UI. If you can identify data that could be collected outside the main
interactive configuration session, especially if it lends itself to being collected in a
tabular or spreadsheet form and is not orderable or constrained by rules, consider the
following implementations:
■ If you only need to collect moderate amounts of end user data, design a
Configurator Extension bound to the onCommand event to launch a separate child
window during the main interactive configuration session that allows end users to
enter data. Moderate amounts of end-user data might be no more than 100 rows,
or take no more than a few minutes to enter.
■ If end users have to enter a large volume of data or do not have time to enter data
during configuration sessions, create a separate application for collecting the data
outside Oracle Configurator. Implement a Configurator Extension to collect this
data for inclusion in the configuration. In cases where the collected data needs to
be validated, consider the following possible implementations:
– Design a Configurator Extension bound to the onCommand event to launch a
separate child window that displays the previously collected data for editing
and then validates the modified data
– Design a Configurator Extension bound to the onCommand event that alerts
end users to the invalid data so they can correct entries in the separate
application used for collecting data and begin a new configuration session
with valid data.
3.17 Configurator Extension Design

The design of Configurator Extensions and how they interact with the configuration
model as well as other software may affect performance. This section presents the
following topics:
■ Avoiding Unnecessary Interactions
■ Accessing Runtime Nodes
■ Components and Requests
■ Adding and Deleting Instantiable Components
■ Impact of Making Connections Among Components
■ Optimization of Configurator Extensions that Change Model Structure
■ Optimization of Validation Configurator Extensions
See the Oracle Configurator Extensions and Interface Object Developer’s Guide for
additional information about the CIO and Configurator Extensions.
Best Practices 3-29

3.17.1 Avoiding Unnecessary Interactions

Design Configurator Extension to avoid any unnecessary interactions, such as
recursively processing unselected Model subtrees or creating large numbers of
Configurator Extension instances by associating Configurator Extension instantiation
component instances that occur in large numbers.
3.17.2 Accessing Runtime Nodes

■ The method RuntimeNode.getChildByID() is likely to cause slow
performance if used on runtime nodes with many children. It is better to use
RuntimeNode.getChildByName(), even on runtime nodes with few children.
■ Use Java HashMap objects to map names, IDs, and paths to RuntimeNodes so that
you can use RuntimeNode.getChildren(). If HashMaps cannot be used, use a
localized search by starting only at the Components where you can certainly find
the nodes. For better performance, use a localized search only once.
■ Keeping track of all changed runtime nodes after a user action is an expensive
operation. Use Configuration.getDeltaListIterator() immediately
before calling Configurator.commitConfigTransaction(). This iterator
returns only the changed nodes with their new and old states and counts.
■ Configurator Extension code invoking the CIO to make unnecessary state and
count assertions can be inefficient. Use IState.getState() or
IState.getCount() to determine the state or count, and do not reset it if it is
already as desired. Resetting nodes to the same state or count represents
unnecessary propagation.
Setting the state of a node may cause a contradiction. If you know this to be true
and you have no intention of overriding the assertion, then do not set the state so
that it causes the contradiction.
WARNING: When you use this technique of ignoring assertions,

the contradiction is not obvious for opposite states if the
contradictory state is due to defaults, in which case the assertion
might succeed.
■ Configurator Extensions and custom CIO code making many calls to

IState.getState() to check for certain states can be slow.
For each node on which to check the state, call IState.getState() only once.
Then use the following static methods on the returned int:
– StateNode.isTrueState()
– StateNode.isFalseState()
– StateNode.isUserState()
– StateNode.isLogicState()
– StateNode.isUnknownState()
You can also use the following methods to combine state checks:
– StateNode.isSelected()
– StateNode.isTrue()
– StateNode.isFalse()

– StateNode.isUser()
– StateNode.isLogic()
– StateNode.isUnknown()
■ Configurator Extensions and custom code invoking the CIO that makes many calls
to IState.getState() or OptionFeature.getSelectedOptions() to get
the Options selected as a result of a transaction can be slow. Instead, Use
Configuration.getSelectedItems(), which uses already-calculated
information about all the true items in the whole configuration.
If you are also making assertions (with setState(), setCount(), setValue(),
and so on), wrap all those assertions in a transaction.
In order for the CIO mechanism to be able to update the selected item list, make
sure you commit the transaction before calling
Configuration.getSelectedItems().
■ CIO methods may or may not be expensive, depending on the circumstances of
the configuration model. Making many calls to any CIO method that is expensive
can be slow. Instead, call the method once and then cache the results for reuse. For
example, the information from Configuration.getAvailableNodes()
should be queried only when necessary, such as on screen flips and after user
assertions. (Note that you can also obtain availability information by using
AvailabilityDeltaValidator.)
Use profiling tools (such as JProbe) to evaluate the performance cost of called CIO
methods.
3.17.3 Components and Requests

Programmatic changes to the configuration model are dependent on the sequence of
events. For example, to instantiate some Components and programmatically set some
Features in each Component, you could use either of these approaches:
■ Set the Features as you add each Component
■ Add all Components and then set all the Features
The second approach is faster, because the creation of each Component requires the
retraction of all previous inputs (all user selections and all default selections). In the
second approach, you can assert inputs and defaults only once, between when you
add all the Components and when you set all the Features in all the added
Components. The expensive events that you are avoiding in this second approach are
the retractions and reassertions of inputs and defaults, which are processed every time
that a Component is added.
If you are modifying the structure of a Model, you can improve performance by using
the technique described in Section 3.17.6, "Optimization of Configurator Extensions
that Change Model Structure" on page 3-32.
3.17.4 Adding and Deleting Instantiable Components

Adding or deleting an instance of a ComponentSet can be very expensive in terms of
performance. For example:
■ Adding an instance causes all previous requests to be retracted, then reasserted
(that is, added and asserted again).
■ Adding an instance is particularly expensive when there are default values set by
configuration rules. Retracting default assertions is time-consuming and iterative.
Best Practices 3-31

The initial values set in Configurator Developer for Boolean Features should also
be regarded as default values.
■ Deleting instances is a very expensive operation, and may not be necessary at the
end of the Configurator Extension event sequence, since the Configurator
Extension may need to add the same number of Components back into the
Component Set anyway.
To avoid these performance problems, follow these guidelines for adding instances of
a ComponentSet:
■ Try to delay setting the states or values of nodes until after all instances are added.
Add an instance when there are as few settings as possible.
■ When deleting instances (if you have retracted all the requests), you can reuse the
instantiated Components by computing the number of children in the
ComponentSet and keeping track of the index number of the Component that
you are setting Feature values for. You can then delete any Components that you
have not reused. To determine the number of children, you can use
IRuntimeNode.getChildren().size() or ComponentSet.getCount().
See Section 3.17.6, "Optimization of Configurator Extensions that Change Model
Structure" on page 3-32 for details.
3.17.5 Impact of Making Connections Among Components

Connectivity among components can add further complexity to the suggested
sequence described in Section 3.17.6.1 on page 3-33. The best approach depends on
understanding the number of connections you plan to make, and how many you
expect to fail. Completing a connection involves the creation and loading of logic
subnets. That means all current requests have to be retracted and reapplied after the
net is added.
The optimum point at which to make the connection is between the retraction of all
requests and adding or reusing component instances.
If you do not expect the end user requests or the new values to make a difference on
whether connection is allowed, then you need to add or reuse component instances, or
reassert applicable requests before the connection.
The number of connections may cause you to adjust your thinking, due to the impact
of retracting inputs.
3.17.6 Optimization of Configurator Extensions that Change Model Structure

Use the following general strategy to optimize performance of a Configurator
Extension that changes model structure:
1. Store all needed values.
2. Begin a transaction and call
ConfigTransaction.allowOnlyStructuralChanges().
3. Make changes to model structure. Model structure changes are defined as:
■ Adding or deleting instantiable components
■ Connecting or disconnecting component instances
4. Delete extra component instances.
5. Commit or roll back the transaction.

6. Set values on components.

The principle behind this strategy is that making structural changes in a block, inside a
transaction that suspends the usual retraction and reassertion of requests, optimizes
the event sequence. Section 3.17.6.1, "Detailed Sequence" on page 3-33 explains these
events in more detail.
3.17.6.1 Detailed Sequence

Based on the preceding guidelines, optimize the performance of a Configurator
Extension that changes model structure by designing it according to the following
sequence:
1. Store all needed values and logic states in temporary variables.
These are the values that are needed for later calculations and which would be lost
by retracting requests.
2. Begin a transaction. Use Configuration.beginConfigTransaction().
3. Call ConfigTransaction.allowOnlyStructuralChanges().
This method puts the configuration into a state in which the only changes allowed
are those that modify the structure of the Model. Model structure changes are
defined as:
■ Adding or deleting instantiable components
■ Connecting or disconnecting component instances
You cannot make any requests (changes to values or logic states in the
configuration) while in the structural-changes-only state. If you make a request, a
non-overridable logical exception is thrown.
The allowOnlyStructuralChanges() method retracts all user and
non-overridable requests. The requests are stored until your transaction is
committed or rolled back. If a contradiction occurs during the retraction, then the
retraction is aborted, and the transaction loses its structural-changes-only state.
Any nested transactions that you create inherit the structural-changes-only state of
the parent transaction.
Caution: Do not call any methods that get values or logic states in
the configuration while it is in the structural-changes-only state.
Because the allowOnlyStructuralChanges() method previously
retracted all requests, any values or states in the configuration
returned by a query will be incorrect.
4. Add or reuse component instances, as suggested in Section 3.17.4, "Adding and

Deleting Instantiable Components" on page 3-31. To add a component instance,
use ComponentSet.add().
5. If you know that you have extra component instances, you may be able to delete
them, as suggested in Section 3.17.4, "Adding and Deleting Instantiable
Components" on page 3-31. To delete a component instance, use
ComponentSet.delete().
6. Commit or roll back the transaction. Use
Configuration.commitConfigTransaction() or
Configuration.rollbackConfigTransaction().
Best Practices 3-33

When you commit or roll back the transaction, the CIO removes the configuration
from the structural-changes-only state, and reasserts all the previously retracted
user and non-overridable requests. If a contradiction occurs during the
reassertions, then a LogicalOverridableException is thrown. You can
override the exception and examine the failed requests. See the Oracle Configurator
Extensions and Interface Object Developer’s Guide for details on exceptions and failed
requests.
7. Set values on Component instances or their children. Use setState(),
setCount(), setValue(), and so on.
3.17.6.2 Comparison of Coding Approaches

Consider an example of creating instances of a certain number of instantiable
Components, and setting the values of Features in each one. Example 3–14 on
page 3-34 creates a Component, then sets its Features before creating the next
Component. Example 3–15 on page 3-34 creates all the Components, then sets all of
their Features.
Example 3–14 Setting Components and Feature Values One at a Time (Slower)
// Block for 1st component
Add Component1 to ComponentSet
Set Feature1 in Component1
// Block for 2nd component

...
Example 3–15 Setting All Components and Then All Feature Values (Faster)
// Block for all structure changes
Begin strucure-only transaction
Commit strucure-only transaction
// Block for all assertions

...
Example 3–14 is subject to the negative performance effects identified in Section 3.3,
"Optional and Multiple Instantiation" on page 3-6. Example 3–15 results in
significantly faster runtime performance.
The reason why Example 3–14 is slower is shown by comparing Example 3–16 with
Example 3–17. The operations that have to be performed by the CIO when adding
ComponentSet instances are highlighted in boldface. Detailed Slower Approach
repeats all of the operations for each addition of an instance, so that each addition takes
longer than the preceding one, and the total processing time is proportional to the
number of instances to be added. If there are many instances to be added, the impact is
great. Detailed Faster Approach performs the operations once, greatly lessening the
effect of adding many instances.

Example 3–16 Detailed Slower Approach

...
// Block for 1st component

Retract requests // (2 requests)
Reassert requests // (2 requests)
...
// Block for 2nd component
Retract requests // (2 existing + 2 new = 4 requests)
Reassert requests // (4 requests)
...
For n components added, this approach results in n retractions and reassertions, each
of which is an expensive operation. Note also that the queue of requests grows over
time, further increasing the expense of retraction and reassertion.
Contrast this with the result for Example 3–17, "Detailed Faster Approach" on
page 3-35.
Example 3–17 Detailed Faster Approach

...
Begin strucure-only transaction // retracts all existing requests (4 requests)
Commit strucure-only transaction // reasserts all existing requests (4 requests)
...
...
For n components added, this approach results in only 1 retraction and reassertion.
Contrast this with the result for Example 3–16, "Detailed Slower Approach" on
page 3-35. You could further improve performance by performing structural changes
before making requests, thus reducing the size of the queue of requests.
3.17.6.3 Code Example

Consider the simple runtime Model structure shown in Figure 3–7 on page 3-36. At
runtime, this Model contains a ComponentSet object and several BooleanFeature
objects.
Best Practices 3-35

Figure 3–7 Model Structure for Adding Components
Assume that you have written a Configurator Extension bound to the onCommand
event that sets the state of the Boolean Features as illustrated in Example 3–18, "Setting
Features (Slower Code)" on page 3-36.
Example 3–18 Setting Features (Slower Code)

...
for(int i=0; i<100; i++) {

comp = Comp1.add();
((BooleanFeature)comp.getChildByName("BoolFeat1")).setState(IState.TRUE);
((BooleanFeature)comp.getChildByName("BoolFeat2")).setState(IState.FALSE);
((BooleanFeature)comp.getChildByName("BoolFeat3")).setState(IState.TRUE);
}
...
You can significantly improve the performance of this operation by modifying the
code as shown in Example 3–19, "Setting Features (Faster Code)" on page 3-36. The
differences are highlighted in boldface.
Example 3–19 Setting Features (Faster Code)

...
ConfigTransaction tr = config.beginConfigTransaction();
ConfigTransaction.allowOnlyStructuralChanges();
for(int i=0; i<100; i++){
comp[i] = Comp1.add();
}
config.commitConfigTransaction(tr);
for(int i=0; i<100; i++){
((BooleanFeature)comp[i].getChildByName("BoolFeat1")).setState(IState.TRUE);
((BooleanFeature)comp[i].getChildByName("BoolFeat2")).setState(IState.FALSE);
((BooleanFeature)comp[i].getChildByName("BoolFeat3")).setState(IState.TRUE);
}
...
Example 3–19 improves performance by adding all the ComponentSet instances, then
setting all the BooleanFeature values. This follows the principles identified in
Section 3.3, "Optional and Multiple Instantiation" on page 3-6, and the example shown
in Setting All Components and Then All Feature Values (Faster) under Section 3.17.6.2,
"Comparison of Coding Approaches" on page 3-34.

3.17.7 Optimization of Validation Configurator Extensions

In general, Oracle Configurator applies validation tests and defaults more often than
would be expected. The onConfigValidate event is dispatched whenever the end
user selects an option or enters an input in the runtime Oracle Configurator. In a
Configurator Extension bound to this event, defaults should be used as judiciously as
possible, as described in Section 3.8, "Defaults Rules Versus Alternatives to Default
Selections" on page 3-14. Validation tests must be minimal. You should arrange the
code so that onConfigValidate is only dispatched when necessary, and the
condition test is quick.
Example 3–20 on page 3-37 and Example 3–21 on page 3-37 show two ways of
applying a validation test. Example 3–20 performs better because it performs the task
of setting up the validation (by finding the node in each call) in a method bound to the
postCXInit event, which occurs once, and then performs the validation test only
after all other calls are completed. Example 3–21 sets up the validation as part of the
validation test, so the setup is performed every time the onConfigValidate event
occurs.
Example 3–20 Minimizing Validation Tests on a Configuration Model

OptionFeature f = null;
doPostCXInit() { // bind to postCXInit event
f = (OptionFeature) root.getChildByName("feature_name");
}
doOnConfigValidate () { // bind to onConfigValidate event
if (f.isTrue()) {
}
}
Example 3–21 Causing More Validation Tests on a Configuration Model

doPostCXInit() { // bind to postCXInit event
// empty
}
doOnConfigValidate () { // bind to onConfigValidate event
OptionFeature f = (OptionFeature) root.getChildByName("feature_name");
if (f.isTrue()) {
}
}
Best Practices 3-37


Part II
Case Studies
To solve your configuration problem, Oracle Configurator may require a combination

of best practices that is not obvious. Part II presents some examples of common
configuration problems and optimal design solutions best suited to an Oracle
Configurator implementation.
Part II contains the following chapters:
■ Chapter 4, "Many Large BOM Models"
■ Chapter 5, "Many BOM Items"
Each chapter describes the project, a deficient modeling approach, and the suggested
model design.
4
Many Large BOM Models
This case study explores redesigning a project consisting of many large BOM Models
(such as 90,000), each with a large number of options for selection (such as 150,000).
The goal is to fulfill performance and usage expectations in a way best suited to the
strengths and characteristics of Oracle Configurator.
This project illustrates the following best practices:
■ Large Option Features and Option Classes
4.1 Project Description

A manufacturer and wholesaler of jewelry offers customers the opportunity to custom
configure rings and bracelets. Configuring a ring consists of placing stones with
characteristics such as shape, size, type, clarity, quality, into a specified location on the
ring. Each ring consists of up to 60 locations. For example, a customer orders a
3-setting ring by configuring a 2mm round ruby at location 1 and 3, and a 3mm square
emerald at location 2.
4.2 A Deficient Modeling Approach

An initial modeling approach might be to have a specific BOM for each ring model.
Each ring model contains explicit submodels for each of 60 possible locations. Each
Location submodel contains the specifications for the stone placed in that location.
Stone specifications are shape, type, and so on. The 60 locations can be arranged in one
of many possible settings. So for instance, if a ring is defined with three locations, the
locations can be arranged in a line with two bevels flanking a peg. The locations on a
60-location ring could be arranged in many more possible settings. Multiplying the 60
rings containing from 1 to 60 Location submodels by the various possible settings
results in 90,000 large, explicit BOM Models with up to 150,000 options in each BOM
Model. Figure 4–1 shows an example of such explicit, flat Model structure across many
Models.
Many Large BOM Models 4-1

A Deficient Modeling Approach
Figure 4–1 Many Explicit Ring Models
Each Location has the same kind of configurable characteristics, such as particular
stones of specific shapes and sizes. In the individual RingModels, the structure for
configuring Locations is repeated over and over again, up to the maximum number of
60 locations. For example, if 100 rings are defined with 3 locations and another 100
rings are defined with 4 locations, then in 200 ring models the submodel structure for
Location is repeated 700 times.
The ring configuration can contain the same configuration of a stone in several
locations or a stone with different characteristics in different locations.
Perceived Advantages
By defining each possible model explicitly, the manufacturer can maintain and sell
each model independently of all the other models. This includes sourcing items to
separate organizations and preserving existing routings

The Suggested Modeling Approach
By not defining abstractions, the manufacturer does not have to create a large number
of rules to capture the large number of valid combinations because each model
identifies explicit options.
Overwhelming Disadvantages
A design consisting of 90,000 individual Models, each representing a unique
combination, does not leverage the power of Oracle Configurator and causes the
following:
■ Performance problems when importing 90,000 BOM Models into Oracle
Configurator Developer
■ Performance problems at runtime caused by the large number of items (up to
150,000 options per model) that must be instantiated
■ Costly maintenance of 90,000 explicit Models with repetitive structure of many
similar items across many of the models
■ Costly memory usage during preload, initialization, and UI screen display
■ Scalability issues as the business expands to more models and more options within
those models
The runtime performance issues at a minimum are prohibitive.
4.3 The Suggested Modeling Approach

The suggested modeling approach avoids the problems presented in Section 4.2 and
applies numerous best practices described in Chapter 3. Rather than define separate
explicit models repeatedly for each possible ring, a well-designed implementation
defines the duplicated structure by references and abstractions, using optional
instantiation to optimize performance.
4.3.1 Applying Best Practices to Your Model Structure

This case involves several separate models that represent unique rings. However, the
ring models contain a large amount of similar structure, such as settings and locations
for mountings on the rings.
To leverage the advantages of deep hierarchy and optional instantiation, you need to
create abstractions of the structure that is similar across all ring models, as follows:
1. Combine the separate models into a single top-level model for configuring rings.
RingModel_1001 through RingModel_1800 in Figure 4–1 become an abstract
model called Ring Model in Figure 4–2. Instead of searching from a long list of
rings with many pre-defined characteristics in RingModel_1001 through
RingModel_1800, the end-user starts by selecting the characteristics of an
undefined ring. The undefined ring is represented by Ring Model and the
characteristics are the settings and the stones.
This step applies the best practice:
2. Creating a single top-level Ring Model containing the settings structure, initially
results in one huge, flat BOM Option Class containing all possible settings, of
which only one will be selected. Not only are all settings loaded when the
top-level Ring Model is loaded, but the end user is faced with selecting a setting
from this very large list of options.

To help end users see only those settings options that are relevant to their
configuration, organize settings into groups by some criterion such as popularity
or the ring’s intended function. A Settings Model contains not all possible settings
but BOM Option Classes of related or grouped settings.
Each group of settings is a BOM Option Class containing only those options that
belong in that group. Ideally, a specific Settings option should not appear in more
than one group.
Create a Settings Model that contains all the Setting Group BOM Option Classes.
This step applies the best practices:
3. To involve only that group of settings in the configuration that contains relevant
settings, change the Settings Group BOM Option Classes into BOM Models and
make them optionally instantiable, which means the value of Instance Minimum
is 0, Maximum is 1. See Figure 4–2.
■ Optional Instantiation of BOM Option Classes
4. In the top-level Ring Model, you can significantly decrease the amount of
repetitive structure by defining an ATO model for the various Stone Types, each
containing BOM Option Classes for the configurable characteristics of the Stone
such as size and quality.
5. To specify the location where the Stone will be placed, create a Location Option
Feature for the Stone Model. The Location List of Options contains the maximum
number of Locations allowed for any ring. Making Location an attribute of the
Stone Model rather than an Item in the Ring Model is appropriate because the
Stone is configurable and orderable, not the Location.
6. In the Stone Model, refine your design further by creating a Stone Type BOM
Model containing each stone type (Diamond, Ruby, and so one) as a separate
Model that is optionally instantiable. Each Model in the Stone Type BOM Model
contains BOM Option Classes of the configurable characteristics of that stone type,
such as shape and size.
This applies the best practices:

Figure 4–2 Top-level Ring Model with Abstractions
4.3.2 Applying Best Practices to Further Optimize the End-User Experience

After completing the steps in the previous section (Section 4.3.1), continue with the
following steps:
7. To allow end users to select only the Locations relevant to their ring
configurations, write rules that disallow selecting Locations that are not allowed
for a particular Setting. For example, when the end user has selected a 3-location
setting, only 3 Locations should be selectable.
8. To further enhance usability, set Hide when unselectable so only the Locations
that are allowed are displayed.
This applies the best practice:
9. You can also write rules to ensure that each required Location for the selected
Setting is selected and that, as the end user configures the Stones for a ring, only
those Locations remain available for selection that have not yet been selected.

4.3.3 The Resulting End-User Flow

In the Order Management Sales Order Pad, the end user selects the top-level Ring
Model and clicks the Configurator button to start configuring a ring. At start up, no
Settings or Stone Models are instantiated. In the Oracle Configurator UI, the end user
selects a Settings Group. For example, the end user picks a 3-setting ring. The end user
must then configure between one and three Stones for the 3 Locations of the 3-setting
ring. The first instance of the Stone Model allows the end user to configure the Stone
Type and select from the three available Locations. If the end users picks all three
Locations, the configuration is complete and the same Stone configuration will be set
in each of the three locations. If not all three Locations are selected, the end user adds
additional instances of the Stone Model, configures them and selects remaining
available Locations until the ring is fully configured.
The diagram in Figure 4–3 shows a typical end-user flow.
Figure 4–3 End User Flow for Configuring a Ring Model
4.3.4 Advantages of This Modeling Approach
Perceived Disadvantages
Creating deeper hierarchy and abstractions may require greater designing effort and
more rule definitions than an explicit design approach.

A single BOM Model can be sourced to only one organization.

Downstream ERP applications may require additional setup for option-dependent
routings or using configuration attributes.
Overwhelming Advantages
Comparing this approach to the deficient one presented in Section 4.2, a single
top-level BOM Model with structure that is only instantiated as needed provides the
following advantages:
■ Importing a single BOM Model with abstractions is significantly faster than
importing 90,000 large BOM Models with explicit, repetitive structure
■ Instantiating only the substructures required by the current configuration is
significantly faster at runtime than instantiating all items
■ Maintaining a single top-level BOM Model with abstractions is quicker, more
flexible to change, and less prone to error than maintaining 90,000 explicit models
with repetitive structure of many similar items across many of the models
■ Preloading, initializing, and displaying the UI screens for a single BOM Model
with optionally instantiated items uses significantly less memory than the same
operations for 90,000 explicit models
■ Scaling the single top-level BOM Model with abstractions to accommodate
exponentially more items as the business grows does not significantly affect the
performance baseline


5
Many BOM Items
This case study explores redesigning a project that contains a profusion of items not all
of which are part of the order.
This project illustrates the following best practices:
5.1 Project Description

A manufacturer and retail supplier of perforated metal sheets offers customers both
standard products available from local stock and custom-made products. When
ordering metal sheets, customers must specify the type and grade of the material, its
width, length, and thickness, and various characteristics about the perforations. From
this information, the manufacturer must determine the machines and tools to use to
produce the metal sheets.
5.2 A Deficient Modeling Approach

An initial modeling approach might be to define all possible characteristics of a metal
sheet as items in the BOM Model. This would result in a top-level BOM structure for
Metal Sheet, which contains submodels for specifying material and machines, and
contains BOM Option Classes for specifying width, length, thickness, material grade,
hole type, hole size, tools, and so on. Each BOM Option Class contains a large number
of selectable items. Widths, lengths, thicknesses, material grades, hole types, hole sizes,
and tools are all defined as items. For example, the Width BOM Option Class contains
items that represent every possible selectable width for the metal sheet. Figure 5–1
shows an excerpt of such a model.
Many BOM Items 5-1

A Deficient Modeling Approach
Figure 5–1 Model With Too Many Items
Perceived Advantage
■ By defining each characteristic of the product as an item, the manufacturer does
not have to create rules to capture a large number of valid combinations of
characteristics
■ Defining all of the information as part of the BOM Model ensures that all of the
information is passed back to Order Management and to the downstream
manufacturing applications.
■ Defining each characteristic as an item provides a straightforward means by which
to associate a price with each characteristic.
Overwhelming Disadvantages
A design that forces all of this information into the BOM Model inflates the size of the
model structure, does not leverage the flexibility of Oracle Configurator, and causes
the following problems:
■ Poor performance when importing large numbers of items into Oracle
Configurator Developer

■ Poor performance at runtime caused by the large number of items (more than
10,000) that must be loaded into memory and displayed
■ Poor usability of a UI that requires finding the desired item among a large number
of items
■ Insufficient scalability and maintainability as the business expands to more
characteristics and dimensions
5.3 The Suggested Modeling Approach

Rather than defining thousands of BOM items to capture the characteristics of the
configured item, a well-designed implementation reviews the requirement for this
large number of items and based on the item’s use, redefines it either as a
configuration attribute or Feature.
5.3.1 Applying Best Practices to Your Model Structure

The following suggested modeling approach applies best practices to achieve
improved performance and usability:
1. Redesign the BOM Model for perforated metal sheets by analyzing the purpose of
each submodel and BOM Option Class. By finding alternatives to items where
possible, you can make the BOM structure significantly smaller and improve
performance and maintainability.
a. Identify which items appear on an order line and will be picked or assembled.
For example, items in the Materials submodel must appear on the order line.
These items must remain in your model as BOM Standard Items.
b. Of the items that do not need to appear on the order line, determine whether
you need end user input for the value of the item, or if the item has static
value used in calculations or Compatibility rules. Define static values as
Properties of the items they define.
For example, the material grade has a static value (Premium, Medium, and so
on) which can be defined as Properties of the Materials items.
c. Define items whose values result from end user input as Features or as
attributes on items. For example, hole size and width.
d. Of the items that require end user input, determine whether they should be
defined as Features or as configuration attributes. Those inputs that are
required for downstream operations must be defined as configuration
attributes. Write attribute values collected during the configuration session
into the CZ_CONFIG_ATTRIBUTES table.
For example, width, length, and thickness contribute to items that specify
material. These values can be modeled as configuration attributes and
associated with the Materials items that need to go to manufacturing. For
details about implementing configuration attributes, see the Oracle
Configurator Methodologies book. Note that configuration attributes are not
accessible to downstream applications without customization.
e. If the items are only needed during the configuration session, define them as
Features.
For example, the hole size and type affect the selection of tools needed for
creating custom-made sheets. Tool selection occurs during the configuration
Many BOM Items 5-3

session. Add a Numeric Feature to get the hole size and a Feature with a List
of Options to get the hole shape from the end user.
f. Define Configurator Extensions for selecting the appropriate tool based on
end users selections for hole shape and size.
2. The Material submodel contains a large number of items. Organize these items
under some logical grouping by making each logical group a separate model. Add
non-BOM Features to get user inputs that determine which Material group to load.
Each group model contains only items belonging to that group. For instance, if the
group were based on material type, then add a Feature to capture a material type
selection such as aluminum or steel.

Figure 5–2 Redesigned Model With Fewer Items
5.3.2 Applying Best Practices to Further Optimize the End-User Experience

After completing the steps in the previous section (Section 5.3.1), continue with the
following steps:
3. To enhance the runtime performance, load only those groups of items that are
needed by making instantiation of each group model optional, which means the
value of Instance Minimum is 0, Maximum is 1. For example, a particular
submodel group of the Material model is instantiated based on certain end-user
criteria.
4. Hide the parts of the BOM that do not require user interaction. For example, hide
the Machine submodel.
Many BOM Items 5-5


■ User Interfaces With Optimal Usability and Performance: Visibility Settings
5.3.3 The Resulting End-User Flow

The end user starts the order in the Order Management Sales Order Pad, selects the
appropriate item to be configured, and launches Oracle Configurator. The Oracle
Configurator UI starts with a page or pages for entering high-level order
characteristics, such as material type, hole size, and hole shape. Based on the end
user’s selection of a material type, the Configurator Extension loads the appropriate
Material model. The end user selects the material and then enters the dimensions for
the material, such as height, width, and length. These dimensions are collected as
configuration attributes. The end user then selects a tool selection button which
invokes a Configurator Extension to determine the appropriate tool for processing the
ordered specifications.
At the end of the configuration session, the Configurator Extension writes the
dimension attributes to the CZ_CONFIG_ATTRIBUTES table and populates the order
line with the ordered material and tool.
5.3.4 Advantages of This Modeling Approach
Perceived Disadvantages
■ Differentiating whether items are orderable or merely participants in completing a
configuration may require greater designing effort and more rule definitions than
simply defining all characteristics as individual items.
■ Using configuration attributes requires customization to retrieve the dimension
attributes information from CZ_CONFIG_ATTRIBUTES for use in downstream
manufacturing applications. This customization must be reviewed for possible
modification when you upgrade Oracle Applications.
■ Associating prices with characteristics that are defined as configuration attributes
requires customization and the use of Advanced Pricing rules.
Overwhelming Advantages
Compared to the deficient approach presented in Section 5.2, the suggested approach
provides the following advantages:
■ Importing fewer BOM items is significantly faster
■ Instantiating only groups of items at runtime that are needed by the current
configuration is significantly faster than instantiating all items
■ Maintaining a smaller BOM Model with fewer items is easier
■ A relatively smaller BOM Model can be scaled better as the business grows
without irreparably degrading performance

Glossary
This glossary contains definitions that you may need while working with Oracle
Configurator.
API
Application Programming Interface
applet
A Java application running inside a Web browser. See also Java and servlet.
Archive Path
The ordered sequence of Configurator Extension Archives for a Model that
determines which Java classes are loaded for Configurator Extensions and in what
order.
argument
A data value or object that is passed to a method or a Java class so that the method can
operate.
ATO
Assemble to Order
ATP
Available to Promise
base node
The node in a Model that is associated with a Configurator Extension Rule. Used to
determine the event scope for a Configurator Extension.
bill of material
A list of Items associated with a parent Item, such as an assembly, and information
about how each Item relates to that parent Item.
Bills of Material
The application in Oracle Applications in which you define a bill of material.
binding
Part of a Configurator Extension Rule that associates a specified event with a chosen
method of a Java class. See also event.
Glossary-1
BOM
See bill of material.
BOM item
The node imported into Oracle Configurator Developer that corresponds to an Oracle
Bills of Material item. Can be a BOM Model, BOM Option Class node, or BOM
Standard Item node.
BOM Model
A model that you import from Oracle Bills of Material into Oracle Configurator
Developer. When you import a BOM Model, effective dates, ATO rules, and other
data are also imported into Configurator Developer. In Configurator Developer, you
can extend the structure of the BOM Model, but you cannot modify the BOM Model
itself or any of its attributes.
BOM Model node

The imported node in Oracle Configurator Developer that corresponds to a BOM
Model created in Oracle Bills of Material.
BOM Option Class node

Option Class created in Oracle Bills of Material.
BOM Standard Item node

Standard Item created in Oracle Bills of Material.
Boolean Feature
An element of a component in the Model that has two options: true or false.
bug
See defect.
build
A specific instance of an application during its construction. A build must have an
install program early in the project so that application implementers can unit test their
latest work in the context of the entire available application.
CDL
See Constraint Definition Language.
CIO
See Oracle Configuration Interface Object (CIO).
command event
An event that is defined by a character string, which is considered the command for
which listeners are listening.
Comparison Rule
An Oracle Configurator Developer rule type that establishes a relationship to
determine the selection state of a logical Item (Option, Boolean Feature, or
List-of-Options Feature) based on a comparison of two numeric values (numeric
Features, Totals, Resources, Option counts, or numeric constants). The numeric
Glossary-2
values being compared can be computed or they can be discrete intervals in a
continuous numeric input.
Compatibility Rule
An Oracle Configurator Developer rule type that establishes a relationship among
Features in the Model to control the allowable combinations of Options. See also,
Property-based Compatibility Rule.
Compatibility Table
A kind of Explicit Compatibility Rule. For example, a type of compatibility
relationship where the allowable combination of Options are explicitly enumerated.
component
A piece of something or a configurable element in a model such as a BOM Model,
Model, or Component.
Component
An element of the model structure, typically containing Features, that is configurable
and instantiable. An Oracle Configurator Developer node type that represents a
configurable element of a Model. Corresponds to one UI screen of selections in a
runtime Oracle Configurator.
Component Set
An element of the Model that contains a number of instantiated Components of the
same type, where each Component of the set is independently configured.
concurrent program
Executable code (usually written in SQL*Plus or Pro*C) that performs the function(s)
of a requested task. Concurrent programs are stored procedures that perform actions
such as generating reports and copying data to and from a database.
configuration
A specific set of specifications for a product, resulting from selections made in a
runtime configurator.
configuration attribute
A characteristic of an item that is defined in the host application (outside of its
inventory of items), in the Model, or captured during a configuration session.
Configuration attributes are inputs from or outputs to the host application at
initialization and termination of the configuration session, respectively.
configuration engine
The part of the runtime Oracle Configurator that uses configuration rules to validate
a configuration. Compare generated logic.
Configuration Interface Object

See Oracle Configuration Interface Object (CIO).
configuration model
Represents all possible configurations of the available options, and consists of model
structure and rules. It also commonly includes User Interface definitions and
Configurator Extensions. A configuration model is usually accessed in a runtime
Oracle Configurator window. See also model.
Glossary-3
configuration rule
A Logic Rule, Compatibility Rule, Comparison Rule, Numeric Rule, Design Chart,
Statement Rule, or Configurator Extension rule available in Oracle Configurator
Developer for defining configurations. See also rules.
configuration session
The time from launching or invoking to exiting Oracle Configurator, during which
end users make selections to configure an orderable product. A configuration session
is limited to one configuration model that is loaded when the session is initialized.
configurator
The part of an application that provides custom configuration capabilities. Commonly,
a window that can be launched from a host application so end users can make
selections resulting in valid configurations. Compare Oracle Configurator.
Configurator Extension
An extension to the configuration model beyond what can be implemented in
Configurator Developer.
A type of configuration rule that associates a node, Java class, and event binding so
that the rule operates when an event occurs during a configuration session.
A Java class that provides methods that can be used to perform configuration actions.
Configurator Extension Archive

An object in the Repository that stores one or more compiled Java classes that
implement Configurator Extensions.
connectivity
The connection between client and database that allows data communication.
The connection across components of a model that allows modeling such products as
networks and material processing systems.
Connector
The node in the model structure that enables an end user at runtime to connect the
Connector node’s parent to a referenced Model.
Constraint Definition Language

A language for entering configuration rules as text rather than assembling them
interactively in Oracle Configurator Developer. CDL can express more complex
constraining relationships than interactively defined configuration rules can.
Container Model
A type of BOM Model that you import from Oracle Bills of Material into Oracle
Configurator Developer to create configuration models containing connectivity and
trackable components. Configurations created from Container Models can be tracked
and updated in Oracle Install Base
Contributes to
A relation used to create a specific type of Numeric Rule that accumulates a total
value. See also Total.
Glossary-4
Consumes from
A relation used to create a specific type of Numeric Rule that decrements a total value,
such as specifying the quantity of a Resource used.
count
The number or quantity of something, such as selected options. Compare instance.
CTO
Configure to Order
customer
The person for whom products are configured by end users of the Oracle
Configurator or other ERP and CRM applications. Also the end users themselves
directly accessing Oracle Configurator in a Web store or kiosk.
customer requirements
The needs of the customer that serve as the basis for determining the configuration of
products, systems, and services. Also called needs assessment. See guided buying or
selling.
CZ
The product shortname for Oracle Configurator in Oracle Applications.
CZ schema
The implementation version of the standard runtime Oracle Configurator
data-warehousing schema that manages data for the configuration model. The
implementation schema includes all the data required for the runtime system, as well
as specific tables used during the construction of the configurator.
data import
Populating the CZ schema with enterprise data from ERP or legacy systems via
import tables.
data source
A programmatic reference to a database. Referred to by a data source name (DSN).
DBMS
Database Management System
default
A predefined value. In a configuration, the automatic selection of an option based on
the preselection rules or the selection of another option.
Defaults relation
An Oracle Configurator Developer Logic Rule relation that determines the logic state
of Features or Options in a default relation to other Features and Options. For
example, if A Defaults B, and you select A, B becomes Logic True (selected) if it is
available (not Logic False).
defect
A failure in a product to satisfy the users' requirements. Defects are prioritized as
critical, major, or minor, and fixes range from corrections or workarounds to
enhancements. Also known as a bug.
Glossary-5
Design Chart
An Oracle Configurator Developer rule type for defining advanced Explicit
Compatibilities interactively in a table view.
developer
The person who uses Oracle Configurator Developer to create a configurator. See also
implementer and user.
Developer
The tool (Oracle Configurator Developer) used to create configuration models.
DHTML
Dynamic Hypertext Markup Language
discontinued item
A discontinued item is one that exists in an installed configuration of a component (as
recorded in Oracle Install Base), but has been removed from the instance of the
component being reconfigured, either by deletion or by deselection.
element
Any entity within a model, such as Options, Totals, Resources, UI controls, and
components.
end user
The ultimate user of the runtime Oracle Configurator. The types of end users vary by
project but may include salespeople or distributors, administrative office staff,
marketing personnel, order entry personnel, product engineers, or customers directly
accessing the application via a Web browser or kiosk. Compare user.
enterprise
The systems and resources of a business.
environment
The arena in which software tools are used, such as operating system, applications,
and server processes.
ERP
Enterprise Resource Planning. A software system and process that provides
automation for the customer's back-room operations, including order processing.
event
An action or condition that occurs in a configuration session and can be detected by a
listener. Example events are a change in the value of a node, the creation of a
component instance, or the saving of a configuration. The part of model structure
inside which a listener listens for an event is called the event binding scope. The part
of model structure that is the source of an event is called the event execution scope. See
also command event.
Excludes relation
An Oracle Configurator Developer Logic Rule type that determines the logic state of
Features or Options in an excluding relation to other Features and Options. For
example, if A Excludes B, and if you select A, B becomes Logic False, since it is not
allowed when A is true (either User or Logic True). If you deselect A (set to User
Glossary-6
False), there is no effect on B, meaning it could be User or Logic True, User or Logic
False, or Unknown. See Negates relation.
feature
A characteristic of something, or a configurable element of a component at runtime.
Feature
An element of the model structure. Features can either have a value (numeric or
Boolean) or enumerated Options.
functional specification
Document describing the functionality of the application based on user requirements.
generated logic
The compiled structure and rules of a configuration model that is loaded into memory
on the Web server at configuration session initialization and used by the Oracle
Configurator engine to validate runtime selections. The logic must be generated either
in Oracle Configurator Developer or programmatically in order to access the
configuration model at runtime.
guided buying or selling

Needs assessment questions in the runtime UI to guide and facilitate the configuration
process. Also, the model structure that defines these questions. Typically, guided
selling questions trigger configuration rule that automatically select some product
options and exclude others based on the end user’s responses.
host application
An application within which Oracle Configurator is embedded as integrated
functionality, such as Order Management or iStore.
HTML
Hypertext Markup Language
implementation
The stage in a project between defining the problem by selecting a configuration
technology vendor, such as Oracle, and deploying the completed configuration
application. The implementation stage includes gathering requirements, defining test
cases, designing the application, constructing and testing the application, and
delivering it to end users. See also developer and user.
implementer
The person who uses Oracle Configurator Developer to build the model structure,
rules, and UI customizations that make up a runtime Oracle Configurator. Commonly
also responsible for enabling the integration of Oracle Configurator in a host
application.
Implies relation
An Oracle Configurator Developer Logic Rule type that determines the logic state of
Features or Options in an implied relation to other Features and Options. For
example, if A Implies B, and you select A, B becomes Logic True. If you deselect A (set
to User False), there is no effect on B, meaning it could be User or Logic True, User or
Logic False, or Unknown. See Requires relation.
Glossary-7
import server
A database instance that serves as a source of data for Oracle Configurator’s
Populate, Refresh, and Synchronization concurrent processes. The import server is
sometimes referred to as the remote server.
import tables
Tables mirroring the CZ schemaItem Master structure, but without integrity
constraints. Import tables allow batch population of the CZ schema’s Item Master.
Import tables also store extractions from Oracle Applications or legacy data that
create, update, or delete records in the CZ schema Item Master.
initialization message
The XML message sent from a host application to the Oracle Configurator Servlet,
containing data needed to initialize the runtime Oracle Configurator. See also
termination message.
Instance
An Oracle Configurator Developer attribute of a component’s node that specifies a
minimum and maximum value. See also instance.
instance
A runtime occurrence of a component in a configuration. See also instantiate. Compare
count.
Also, the memory and processes of a database.
instantiate
To create an instance of something. Commonly, to create an instance of a component
in the runtime user interface of a configuration model.
integration
The process of combining multiple software components and making them work
together.
integration testing
Testing the interaction among software programs that have been integrated into an
application or system. Also called system testing. Compare unit test.
item
A product or part of a product that is in inventory and can be delivered to customers.
Item
A Model or part of a Model that is defined in the Item Master. Also data defined in
Oracle Inventory.
Item Master
Data stored to structure the Model. Data in the CZ schema Item Master is either
entered manually in Oracle Configurator Developer or imported from Oracle
Applications or a legacy system.
Item Type
Data used to classify the Items in the Item Master. Item Catalogs imported from Oracle
Inventory are Item Types in Oracle Configurator Developer.
Glossary-8
Java
An object-oriented programming language commonly used in internet applications,
where Java applications run inside Web browsers and servers. Used to implement the
behavior of Configurator Extensions. See also applet and servlet.
Java class
The compiled version of a Java source code file. The methods of a Java class are used
to implement the behavior of Configurator Extensions.
JavaServer Pages
Web pages that combine static presentation elements with dynamic content that is
rendered by Java servlets.
JSP
See JavaServer Pages.
legacy data
Data that cannot be imported without creating custom extraction programs.
listener
A class in the CIO that detects the occurrence of specified events in a configuration
session.
load
Storing the configuration model data in the Oracle Configurator Servlet on the Web
server. Also, the time it takes to initialize and display a configuration model if it is not
preloaded.
The burden of transactions on a system, commonly caused by the ratio of user
connections to CPUs or available memory.
log file
A file containing errors, warnings, and other information that is output by the running
application.
Logic Rule
An Oracle Configurator Developer rule type that expresses constraint among model
elements in terms of logic relationships. Logic Rules directly or indirectly set the
logical state (User or Logic True, User or Logic False, or Unknown) of Features and
Options in the Model.
There are four primary Logic Rule relations: Implies, Requires, Excludes, and Negates.
Each of these rules takes a list of Features or Options as operands. See also Implies
relation, Requires relation, Excludes relation, and Negates relation.
maintainability
The characteristic of a product or process to allow straightforward maintenance,
alteration, and extension. Maintainability must be built into the product or process
from inception.
maintenance
The effort of keeping a system running once it has been deployed, through defect
fixes, procedure changes, infrastructure adjustments, data replication schedules, and
so on.
Glossary-9
Metalink
Oracle’s technical support Web site at:
http://www.oracle.com/support/metalink/
method
A function that is defined in a Java class. Methods perform some action and often
accept parameters.
Model
The entire hierarchical "tree" view of all the data required for configurations,
including model structure, variables such as Resources and Totals, and elements in
support of intermediary rules. Includes both imported BOM Models and Models
created in Configurator Developer. May consist of BOM Option Classes and BOM
Standard Items.
model
A generic term for data representing products. A model contains elements that
correspond to items. Elements may be components of other objects used to define
products. A configuration model is a specific kind of model whose elements can be
configured by accessing an Oracle Configurator window.
model-driven UI
The graphical views of the model structure and rules generated by Oracle
Configurator Developer to present end users with interactive product selection based
on configuration models.
model structure
Hierarchical "tree" view of data composed of elements (Models, Components,
Features, Options, BOM Models, BOM Option Class nodes, BOM Standard Item
nodes, Resources, and Totals). May include reusable components (References).
Negates relation
A type of Oracle Configurator Developer Logic Rule type that determines the logic
state of Features or Options in a negating relation to other Features and Options. For
example, if one option in the relationship is selected, the other option must be Logic
False (not selected). Similarly, if you deselect one option in the relationship, the other
option must be Logic True (selected). See Excludes relation.
node
The icon or location in a Model tree in Oracle Configurator Developer that represents
a Component, Feature, Option or variable (Total or Resource), Connector, Reference,
BOM Model, BOM Option Class node, or BOM Standard Item node.
Numeric Rule
An Oracle Configurator Developer rule type that expresses constraint among model
elements in terms of numeric relationships. See also, Contributes to and Consumes
from.
object
Entities in Oracle Configurator Developer, such as Models, Usages, Properties,
Effectivity Sets, UI Templates, and so on. See also element.
Glossary-10
OC
See Oracle Configurator.
OCD
See Oracle Configurator Developer.
option
A logical selection made in the Model Debugger or a runtime Oracle Configurator by
the end user or a rule when configuring a component.
Option
An element of the Model. A choice for the value of an enumerated Feature.
Oracle Configuration Interface Object (CIO)

A server in the runtime application that creates and manages the interface between the
client (usually a user interface) and the underlying representation of model structure
and rules in the generated logic.
The CIO is the API that supports creating and navigating the Model, querying and
modifying selection states, and saving and restoring configurations.
Oracle Configurator
The product consisting of development tools and runtime applications such as the CZ
schema, Oracle Configurator Developer, and runtime Oracle Configurator. Also the
runtime Oracle Configurator variously packaged for use in networked or Web
deployments.
Oracle Configurator architecture

The three-tier runtime architecture consists of the User Interface, the generated logic,
and the CZ schema. The application development architecture consists of Oracle
Configurator Developer and the CZ schema, with test instances of a runtime Oracle
Configurator.
Oracle Configurator Developer

The suite of tools in the Oracle Configurator product for constructing and maintaining
configurators.
Oracle Configurator engine

The part of the Oracle Configurator product that validates runtime selections. See also
generated logic.
Oracle Configurator schema

See CZ schema.
Oracle Configurator Servlet

A Java servlet that participates in rendering Legacy user interfaces for Oracle
Configurator.
Oracle Configurator window

The user interface that is launched by accessing a configuration model and used by
end users to make the selections of a configuration.
Glossary-11
performance
The operation of a product, measured in throughput and other data.
Populator
An entity in Oracle Configurator Developer that creates Component, Feature, and
Option nodes from information in the Item Master.
preselection
The default state in a configurator that defines an initial selection of Components,
Features, and Options for configuration.
A process that is implemented to select the initial element(s) of the configuration.
product
Whatever is ordered and delivered to customers, such as the output of having
configured something based on a model. Products include intangible entities such as
services or contracts.
Property
A named value associated with a node in the Model or the Item Master. A set of
Properties may be associated with an Item Type. After importing a BOM Model,
Oracle Inventory Catalog Descriptive Elements are Properties in Oracle Configurator
Developer.
Property-based Compatibility Rule

An Oracle Configurator Developer Compatibility Rule type that expresses a kind of
compatibility relationship where the allowable combinations of Options are specified
implicitly by relationships among Property values of the Options.
prototype
A construction technique in which a preliminary version of the application, or part of
the application, is built to facilitate user feedback, prove feasibility, or examine other
implementation issues.
PTO
Pick to Order
publication
A unique deployment of a configuration model (and optionally a user interface) that
enables a developer to control its availability from host applications such as Oracle
Order Management or iStore. Multiple publications can exist for the same
configuration model, but each publication corresponds to only one Model and User
Interface.
publishing
The process of creating a publication record in Oracle Configurator Developer, which
includes specifying applicability parameters to control runtime availability and
running an Oracle Applications concurrent process to copy data to a specific database.
RDBMS
Relational Database Management System
Glossary-12
reference
The ability to reuse an existing Model or Component within the structure of another
Model (for example, as a subassembly).
Reference
An Oracle Configurator Developer node type that denotes a reference to another
Model.
Repository
Set of pages in Oracle Configurator Developer that contains areas for organizing and
maintaining Models and shared objects in a single location.
Requires relation
An Oracle Configurator Developer Logic Rule relationship that determines the logic
state of Features or Options in a requirement relation to other Features and Options.
For example, if A Requires B, and if you select A, B is set to Logic True (selected).
Similarly, if you deselect A, B is set to Logic False (deselected). See Implies relation.
resource
Staff or equipment available or needed within an enterprise.
Resource
A variable in the Model used to keep track of a quantity or supply, such as the amount
of memory in a computer. The value of a Resource can be positive or zero, and can
have an Initial Value setting. An error message appears at runtime when the value of a
Resource becomes negative, which indicates it has been over-consumed. Use Numeric
Rules to contribute to and consume from a Resource.
Also a specific node type in Oracle Configurator Developer. See also node.
reusable component
See reference and model structure.
reusability
The extent to and ease with which parts of a system can be put to use in other systems.
rules
Also called business rules or configuration rule. In the context of Oracle Configurator
and CDL, a rule is not a "business rule." Constraints applied among elements of the
product to ensure that defined relationships are preserved during configuration.
Elements of the product are Components, Features, and Options. Rules express logic,
numeric parameters, implicit compatibility, or explicit compatibility. Rules provide
preselection and validation capability in Oracle Configurator.
See also Comparison Rule, Compatibility Rule, Design Chart, Logic Rule and
Numeric Rule.
runtime
The environment and context in which applications are run, tested, or used, rather
than developed.
The environment in which an implementer (tester), end user, or customer configures
a product whose model was developed in Oracle Configurator Developer. See also
configuration session.
Glossary-13
schema
The tables and objects of a data model that serve a particular product or business
process. See also CZ schema.
server
Centrally located software processes or hardware, shared by clients.
servlet
A Java application running inside a Web server. See also Java, applet, and Oracle
Configurator Servlet.
solution
The deployed system as a response to a problem or problems.
SQL
Structured Query Language
Statement Rule
An Oracle Configurator Developer rule type defined by using the Oracle
Configurator Constraint Definition Language (text) rather than interactively
assembling the rule’s elements.
system
The hardware and software components and infrastructure integrated to satisfy
functional and performance requirements.
termination message
The XML message sent from the Oracle Configurator Servlet to a host application
after a configuration session, containing configuration outputs. See also initialization
message.
Total
A variable in the Model used to accumulate a numeric total, such as total price or total
weight.
Also a specific node type in Oracle Configurator Developer. See also node.
UI
See User Interface.
UI Templates
Templates available in Oracle Configurator Developer for specifying UI definitions.
Unknown
The logic state that is neither true nor false, but unknown at the time a configuration
session begins or when a Logic Rule is executed. This logic state is also referred to as
Available, especially when considered from the point of view of the runtime Oracle
Configurator end user.
unit test
Execution of individual routines and modules by the application implementer or by
an independent test consultant to find and resolve defects in the application. Compare
integration testing.
Glossary-14
update
Moving to a new version of something, independent of software release. For instance,
moving a production configurator to a new version of a configuration model, or
changing a configuration independent of a model update.
upgrade
Moving to a new release of Oracle Configurator or Oracle Configurator Developer.
user
The person using a product or system. Used to describe the person using Oracle
Configurator Developer tools and methods to build a runtime Oracle Configurator.
Compare end user.
User Interface
The part of an Oracle Configurator implementation that provides the graphical views
necessary to create configurations interactively. A user interface is generated from the
model structure. It interacts with the model definition and the generated logic to give
end users access to customer requirements gathering, product selection, and any
extensions that may have been implemented. See also UI Templates.
user interface
The visible part of the application, including menus, dialog boxes, and other on-screen
elements. The part of a system where the user interacts with the software. Not
necessarily generated in Oracle Configurator Developer. See also User Interface.
user requirements
A description of what the configurator is expected to do from the end user's
perspective.
validation
Tests that ensure that configured components will meet specific criteria set by an
enterprise, such as that the components can be ordered or manufactured.
variable
Parts of the Model that are represented by Totals, Resources, or numeric Features.
verification
Tests that check whether the result agrees with the specification.
Web
The portion of the Internet that is the World Wide Web.
Workbench
Set of pages in Oracle Configurator Developer for creating, editing, and working with
Repository objects such as Models and UI Templates.
XML
Extensible Markup Language, a highly flexible markup language for transferring data
between Web applications. Used for the initialization message and termination
message of the Oracle Configurator Servlet.
Glossary-15
Glossary-16
Index
A attributes
instead of items, 3-10, 4-4, 5-3
abstractions
processing, 3-10
creating, 4-3 See also configuration attributes
definition, 3-1, 3-3 Available To Promise
downstream consequences, 3-4
See ATP (Available To Promise)
effect on Flow Manufacturing, 3-4
example, 3-3
issues, 3-2 B
sourcing, 3-4, 4-2 beginConfigTransaction()
Add button usage, 3-33
BOM structure, 3-8 bill of materials
adding display, 2-4
component instances, 1-3, 2-4 See also BOM
Components and Features, 3-31 BOM
configuration elements, 1-3, 2-4 definition, 1-2
Features, 5-4 design questions, 2-4
instances displaying, 2-4
expensive with defaults, 3-8 structure for ERP versus configuration, 1-2
node values not set, 3-8 See also BOM Models
instantiable Components, 3-31 BOM Models
Advanced Planning controlling display at runtime, 3-9
phantom items, 3-4 designing, 1-2
Advanced Pricing extending with guided buying or selling, 1-1
with configuration attributes, 5-6 importing
allowOnlyStructuralChanges() item names and descriptions, 1-2
usage, 3-33 performance, 4-7
AllTrue logical function large, 4-1
activating defaults, 3-15 leveraging in Configurator, 1-1
applications multiple with similar structure, 1-2
collecting data, 3-29 planning guidelines, 1-2
Assemble To Order redesigning, 1-2
See ATO (Assemble To Order), 3-5 References, 3-5
assertions sourcing, 3-4, 4-2
ignoring, 3-30 See also BOM Option Classes
retracting defaults, 3-8, 3-31 BOM Option Classes
state and count, 3-30 change into BOM Models, 4-4
wrapping in a transaction, 3-31 display of Standard Items at runtime, 3-9
ATO (Assemble To Order) grouped items, 3-12, 4-4
models improving
non-phantom, 3-8 performance, 3-12
phantom, 3-5, 3-6 usability, 5-5
ATO Items large
See Items best practices, 3-12
ATP (Available To Promise) definition, 1-2
phantom items, 3-4 example, 4-3, 5-1
Index-1
many, 1-2 Components
optional instantiation, 3-6 add or reuse instances, 3-33
redesigned as BOM Models, 3-5, 3-6, 4-4 adding, 3-31
References, 3-5 containing Boolean Features, 3-14
repetitive, 1-2 definition, 2-4
with many Items, 3-12 deleting, 3-31
See also BOM Standard Items instantiable, 3-31
BOM Standard Items instantiating, 3-31
many, 1-2 multiple instantiation, 3-6
optional, 1-2 requests, 3-31
runtime display, 1-2, 3-9 runtime node search, 3-30
Boolean Features versus components, 2-4
alternative to Options, 3-14 with repetitive structure, 3-6
example, 3-15, 3-24 components
initial values, 3-8, 3-15 connectivity among, 3-32
BooleanFeature object, 3-35 ComponentSet
browser performance effects, 3-31
resource limitations and UI performance, 3-28 configuration attributes
business CZ_CONFIG_ATTRIBUTES table, 5-3, 5-6
constraints, 1-3 input, 2-5
instead of items, 2-5, 3-10, 5-3
output, 3-10
C
downstream values, 5-3
caching example, 5-3, 5-6
reducing, 3-6 non-orderable information, 2-6
results of CIO methods, 3-31 Configuration Interface Object
CDL (Constraint Definition Language) See CIO
precedence of operators, 3-17 configuration models
using AllTrue, 3-15 complexity, 3-9
using NotTrue, 2-6, 3-20 creating, 1-1
change design
Model structure, 3-32 flow, 1-1
child questions, 2-1
windows, 3-29 starting, 2-1
CIO (Configuration Interface Object) guided buying or selling, 3-9
optimizing calls by custom UI, 3-28 interaction with Configurator Extension, 3-29
use by Configurator Extensions, 3-29 to 3-37 interaction with other software, 3-29
client maintainability, 1-2
graphics rendering, 3-28 scalability, 1-2
commitConfigTransaction() size
best practice, 3-30 large, 1-3
usage, 3-33 medium, 1-3
Comparison Rules number of rules, 1-3
best practices, 3-23 small, 1-3
design questions, 2-7 configuration session
using intermediate values, 3-24 collecting data, 3-29
Comparison rules completing, 3-15
Totals, 3-24 data collection for, 2-5
Compatibility Rules data input outside, 2-5
best practices, 3-21 data output, 2-6
definition, 3-5 design questions, 2-5
design questions, 2-7 filled-in values, 3-14
engine processing, 3-21 proceeding without defaults, 3-15
Explicit Configuration Summary page
engine performance, 3-21 performance impact, 3-28
Property-based configurations
engine performance, 3-21 restoring saved configurations
using static item values, 5-3 with connections, 3-27
versus Excludes relation, 3-23 Configurator
versus Logic Rules, 3-21 See Oracle Configurator
Index-2
Configurator Extensions in added instances, 3-8
allowOnlyStructuralChanges, 3-32 performance effects, 3-8, 3-14, 3-31
collecting end-user data, 3-29 setting values
design, 3-29 automatically, 2-4
design questions, 2-5 on demand, 3-15
example, 5-4, 5-6 Defaults relation (Logic Rule)
instantiating instances, 3-8 best practices, 3-14
interaction with configuration model, 3-29 design questions, 2-3
onCommand, 3-29, 3-32 evaluating need, 3-14
onConfigValidate, 3-37 example, 3-16
output configuration attributes, 5-6 simulation, 3-15
postConfigNew, 3-15 versus Implies rule, 3-16
postConfigRestore, 3-15 deleting
preConfigSave, 3-15 instance of ComponentSet, 3-31
sequence of events, 3-8, 3-31 instantiable instances, 3-32
settings made by, 3-16 deltas (from baseline)
simulate Defaults relation, 3-15 minimizing despite Unknown Options, 3-13
configuring Description
Option Classes, 3-12 BOM Items, 1-2, 2-4
connectivity design questions
assertions, 3-32 BOM
processing at runtime, 3-25 design, 2-4
Connectors display, 2-4
best practice, 3-25 Comparison Rules, 2-7
example, 3-25 Compatibility Rules, 2-7
constraints configuration session, 2-5
business, 1-3 Configurator Extension, 2-5
See also rules defaults, 2-3
contradictions guided buying or selling, 2-4
caused by locking logic states, 3-21 list of options, 2-1
versus resource violations, 3-24 designing
Contributes to BOM Models, 1-2
behavior, 3-18 configuration models, 1-1
example, 3-13, 3-17, 3-18 Configurator Extensions, 3-29
Count rules, 1-1
assertion, 3-30 See also redesigning
example, 3-18 DHTML
triggered by rule, 3-12 Configurator
customer requirements decision to use, 3-29
maximum selections, 3-12 control
customizing violation messages, 3-18 processing in OC Servlet, 3-28
CZ schema effect on performance, 3-29
imported BOM data, 3-5 display conditions
CZ_CONFIG_ATTRIBUTES prevent NotTrue locking, 3-21
table in CZ schema, 5-3, 5-6 downstream values output
configuration attributes, 3-10
Drop-down List
D
render time, 3-28
data server processing of, 3-28
caching, 3-6
import
item name and description, 1-2
E
performance, 4-3, 5-2 end users
redundant, 3-6 collecting data, 3-29
debugging collecting inputs from, 2-5
log files, xvi example flow, 5-6
defaults expectations, 1-3
apply on user request, 3-15 flow, 3-8
asserting, 3-31, 3-37 guided buying or selling questions, 3-8
design questions, 2-3 product experts, 3-8
Index-3
requests made by, 3-16 grouping
engine for performance, 5-6
See Oracle Configurator engine items in submodels, 5-4
Enterprise Resource Planning items into BOM Option Classes, 3-12, 4-4
See ERP (Enterprise Resource Planning) optional instantiation, 3-12, 4-4, 5-5
ERP (Enterprise Resource Planning) guided buying or selling
BOM structure, 1-2 controlling display of BOM Model, 3-9
errors definition, 3-9
troubleshooting, xvi design questions, 2-4
events determining what to instantiate, 3-8
circular propagation, 3-18 driven by structure, 1-1
Configurator Extension sequence, 3-31 easing navigation flow, 3-9
examples extending a BOM Model, 1-1
abstractions, 3-3 hiding Items, 3-12
Boolean non-expert end users, 3-8
Feature, 3-24 rules, 3-9
Boolean Feature, 3-15 scenarios, 3-9
Configurator Extension, 5-4, 5-6 simplifying complex models, 3-9
Contributes to, 3-13, 3-17, 3-18 See also User Interface
Count, 3-18
Defaults relation, 3-16
H
Implies relation (Logic Rule), 3-18, 3-21, 3-25
intermediate value, 3-24 HTML
list of options, 4-3 effect on performance, 3-29
onCommand Configurator Extension, 3-29, 3-36 HTML templates
output configuration attributes, 5-3, 5-6 modified to improve performance, 3-29
postConfigRestore, 3-15
preConfigSave, 3-15 I
Properties, 5-3
Property-based Compatibility Rules, 3-22 Implies relation (Logic Rule)
Resource, 3-17, 3-24 example, 3-18, 3-21, 3-25
setting values on demand, 3-15 versus Defaults rule, 3-16
typographical conventions in, xv importing
Excludes relation (Logic Rule) data
example, 3-20 item name and description, 1-2
expressing incompatibility, 3-23 performance, 4-3, 5-2
Explicit Compatibility Rules incompatibilities, 3-23
versus Property-based Compatibility, 3-22 expressed using Excludes relation, 3-23
with many participants, 3-22 inputs
collecting from end users, 2-5
configuration attributes, 2-5
F instances
Features adding
adding, 5-4 with Configurator Extension, 3-8
flow creating at runtime, 3-8
creating configuration models, 1-1 delaying state assertions, 3-8
end user, 3-8, 4-6, 5-6 deleting, 3-32
Flow Manufacturing many, 3-8
abstract structure, 3-4 with defaults set, 3-8
instantiable
Components
G adding and deleting, 3-31
generated Configurator User Interface setting Feature values, 3-34
comparative performance, 3-12 instantiation
Generic Configurator User Interface by Configurator Extension, 3-8
comparative performance, 3-12 guided buying or selling, 3-8
getAvailableNodes() limitations, 3-8
performance consideration, 3-31 multiple, 3-6
getDeltaListIterator() optional, 4-3, 4-4, 4-7
best practice, 3-30 creating instances, 3-8
Index-4
definition, 3-6 changes defined, 3-32
example, 5-5 deeply nested, 3-9
for usability, 3-2 explicit, 4-1
grouped items, 3-12 reasons, 3-2
of abstractions, 3-4 flat, 3-9, 4-1
of references, 3-4 grouping, 3-12, 4-4
performance, 3-9 guided buying or selling, 1-1
intermediate values nodes
definition, 3-24 intermediate, 3-17, 3-19
example, 3-24 Option, 3-28
Items Option Class, 3-12
alternatives, 5-3 shallow, 3-9
hiding, 3-12
naming, 1-2
N
number, 3-8
phantom, 3-4 Name
BOM Items, 1-2
navigation
J easing flow, 3-9
JavaScript guided buying or selling, 3-9
decision to use, 3-29 nested structure
effect on performance, 3-29 designing, 3-9
processing in OC Servlet, 3-28 non-phantom
setting Supply Type, 3-8
NotTrue logical function
L
causes order dependency, 3-20
limitations CDL operator, 2-6, 3-20
browser resources and UI controls, 3-28 display condition, 3-21
list of options locked initial values, 3-21
case study example, 4-3
design questions, 2-1
large
O
definition, 2-1 OC Servlet
example, 4-3 DHTML control processing, 3-28
grouping, 3-12 JavaScript processing, 3-28
usability, 3-9 onCommand Configurator Extension type
log files collecting end-user data, 3-29
troubleshooting errors, xvi example, 3-29, 3-36
Logic False optimization, 3-32
available for selection, 3-13 sequence of events, 3-33
logic states onConfigValidate Configurator Extension type, 3-37
caused by NotTrue, 3-21 operators
checking, 3-30 order in subexpressions, 3-17
locking, 3-21 Option Features
Logic False, 3-13 alternative to Inventory Items, 3-10
improving performance, 3-12
large, 3-12
M
with many Options, 3-13
maintenance optional
BOM Model design, 1-2, 4-3, 5-6 BOM Standard Items, 1-2
manufacturing See also instantiation
constraints, 1-3 Options
memory availability and performance, 3-28
usage hiding unavailable, 3-28
BOM Model design, 4-3 many
messages compatibility, 2-7
violation, 3-18, 3-20 example, 4-1
Model structure grouping, 3-12
abstractions Maximum Number of Selections, 3-12
advantages, 4-3, 4-7 usability, 3-9
issues, 3-4, 4-6
Index-5
maximum number, 3-12 postConfigNew
redesigning as Boolean Features, 3-14 usage
require and exclude other options, 2-7 simulating initial defaults, 3-8, 3-15
Selection List, 3-28 postConfigRestore
See also list of options example, 3-15
Oracle Applications preConfigSave
designing configuration models, 3-4, 3-6, 3-8 example, 3-15
Oracle Configurator pricing
collecting data, 3-29 customization with configuration attributes, 5-6
customization simple, 5-2
output configuration attributes, 5-6 unexpected, 3-15
engine Product Support, xvi
See Oracle Configurator engine Properties
leveraging BOM Models, 1-1 example, 5-3
log files, xvi instead of items, 5-3
project planning, 1-2 Property-based Compatibility Rules, 3-22
TAR template, xvi Property-based Compatibility Rules
Oracle Configurator Developer example, 3-22
designing rules, 3-1 versus Explicit Compatibility, 3-22
importing data to, 1-2, 4-3, 5-2
log files, xvi
R
product support, xvi
Oracle Configurator engine redesigning
adding Components, 3-31 BOM Models, 1-2
rule propagation behavior BOM Option Classes, 3-5, 3-6, 4-4
Comparison Rules, 3-24 Options as Boolean Features, 3-14
Compatibility Rules, 3-21 References
cycles, 3-18 in imported BOM Models, 3-5
subexpressions, 3-17, 3-19 optionally instantiable, 3-7
Oracle Configurator schema to repetitive structure, 3-6, 4-3
See CZ schema requests
output growth of queue, 3-35
configuration attributes, 2-6, 5-3 performance effects, 3-8, 3-31
resource violations
versus contradictions, 3-24
P Resources
parameters contributing to, 3-17
See also configuration attributes example, 3-17, 3-24
performance rollbackConfigTransaction()
due to many BOM Items, 5-2, 5-6 usage, 3-33
due to many BOM Models, 4-3 routing
effect of definitions, 3-2
adding ComponentSets, 3-8, 3-31 downstream from Configurator, 3-10
Boolean Feature, 3-15 preserving, 4-2
defaults, 3-8, 3-31 rules
deleting ComponentSets commonly used subexpressions, 3-17, 3-19
, 3-32 Comparison Rules, 3-24
requests, 3-8, 3-31 Compatibility Rules, 3-21
rule types, 3-14 complexity, 1-1, 1-3, 3-19
visibility settings, 3-28 connectivity, 3-25
HTML versus DHTML, 3-29 contradictions, 3-18, 3-20
phantom debugging, 3-19
ATO model, 3-5 designing, 1-1
Items, 3-4 disabling, 3-19
non-phantom ATO model, 3-8 folder, 3-19
setting Supply Type, 3-6 error messages, 3-18, 3-20
planning guidelines examining, 3-18
BOM Models, 1-2 factor in Model size, 1-3
rules, 1-3 flexibility, 3-24
User Interface, 1-3 folders
Index-6
disabling, 3-19 T
intermediate, 3-17, 3-19
intermediate values, 3-24 TAR (Technical Assistance Request)
for Oracle Configurator, xvi
locked initial values, 3-21
template, xvi
many, 4-3
number of, 3-19 Technical Assistance Request (TAR)
See TAR
order
Totals
dependency, 3-20
execution, 1-3 Comparison rules, 3-24
imposing a maximum, 3-13
overview, 1-3
initial value, 3-27
planning guidelines, 1-3
propagation using a Resource instead, 3-27
troubleshooting
in engine, 3-17, 3-18, 3-19
analyzing errors, xvi
issues, 3-20
paths, 3-18
redundancy, 3-18 U
relating guided buying or selling, 3-9
UI
subexpressions
See User Interface
repeated, 1-3
UI captions
violation messages, 3-18, 3-20
meaningfulness, 1-2
runtime Oracle Configurator
unknown values
displaying BOM Items, 1-2
available for selection, 3-13
generated UI, 3-12
usability
Generic UI, 3-12
BOM Model design, 5-2
loading connection rules, 3-25
User Interface
Configuration Summary template, 3-28
S custom
scalability definition, 3-28
default
BOM Model design
advantages, 5-6 large BOMs, 3-9
disadvantages, 4-3, 5-2 designing
DHTML versus Java applet, 3-12
planning, 1-2
recommendations, 3-28
Selection List
number of Options in, 3-28 dynamic visibility, 3-28
generating
render time, 3-28
UI captions, 1-2
server processing of, 3-28
server graphics
number, 3-28
processing
size, 3-28
Drop-down List, 3-28
Selection List, 3-28 type, 3-28
guided selling with hidden items, 3-12
sourcing, 4-2
performance
BOM Models, 3-4, 4-2
states due to browser, 3-28
planning guidelines, 1-3
assertions by custom code, 3-30
rendering
logic
checking, 3-30 guided buying or selling, 3-28
requirements, 1-1
false, 3-13
screen
setting, 3-8, 3-32
setting number of graphics per, 3-28
number of UI controls per, 3-28
after adding instances, 3-8, 3-32
types of, 3-28
subexpressions
common or repeating, 3-17 UI controls
Drop-down List, 3-28
defining, 3-17
Option, 3-28
order of operations, 3-17
Supply Type Selection List, 3-28
visibility settings, 3-28
non-phantom, 3-8
phantom, 3-6
Support, xvi V
validation
Index-7
tests, 3-37
values
attribute, 3-10
default, 2-3, 3-8
downstream processing, 3-10
Feature, 3-34
initial, 2-3
violation messages
Comparison Rules warning, 3-24
customization for intermediary rules, 3-18, 3-20
resource exceeded, 3-24
visibility
BOM nodes, 5-5
runtime nodes, 3-9
W
warnings
raised by Comparison Rules, 3-24
Index-8

Oracle® Configurator: Modeling Guide Release 11i

Uploaded by

Copyright:

Available Formats

Oracle® Configurator: Modeling Guide Release 11i

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Oracle® Configurator: Modeling Guide Release 11i

Uploaded by

Copyright:

Available Formats

Oracle® Configurator

Part No. B13605-03

Copyright © 1999, 2005, Oracle. All rights reserved.

Primary Author: Tina Brand

Contributing Authors: Steve Damiani, Mark Sawtelle, Lois Wortley

Contributors: Ivan Lazarov, Marty Plotkin, Kiirja Paananen

Send Us Your Comments ........................................................................................................................ xi

Preface ............................................................................................................................................................... xiii

Part I Modeling Guidelines

1 Planning Your Model Design

2 Starting Your Model Design

Part II Case Studies

4 Many Large BOM Models

5 Many BOM Items

Oracle Configurator Modeling Guide, Release 11i

Accessibility of Code Examples in Documentation JAWS, a Windows screen reader,

Structure of This Book

Part I, "Modeling Guidelines"

Chapter 1, "Planning Your Model Design"

Chapter 2, "Starting Your Model Design"

Chapter 3, "Best Practices"

Part II, "Case Studies"

Chapter 4, "Many Large BOM Models"

Chapter 5, "Many BOM Items"

1.1 Overview of Designing a Configuration Model

1.2 Planning Guidelines Relevant to Model Design

Planning Your Model Design 1-1

■ Business and Manufacturing Constraints

Note: Even if your implementation does not leverage BOM

1.2.1 BOM Model Design or Redesign

1-2 Oracle Configurator Modeling Guide

1.2.2 End-User Expectations

1.2.3 Business and Manufacturing Constraints

Planning Your Model Design 1-3

1-4 Oracle Configurator Modeling Guide

2.1 Do You Expect Configurator to Display Large Lists of Options?

Other Ways To Phrase This Question

Starting Your Model Design 2-1

2.2 Are the Same Product Elements Repeated in Separate Models?

Figure 2–1 Repeating Similar Product Elements

2-2 Oracle Configurator Modeling Guide

Other Ways To Phrase This Question

2.3 Are You Modeling Many Related Products?

Other Ways To Phrase This Question

2.4 Do You Need Default Values Set Automatically?

Other Ways To Phrase This Question

Starting Your Model Design 2-3

Do end users expect to see default values filled in automatically to accelerate

Other Ways To Phrase This Question

2.6 Will Configurations Contain Instances of a Component?

2-4 Oracle Configurator Modeling Guide

Other Ways To Phrase This Question

2.7 Will Your Configurator Collect Many End-User Inputs?

Other Ways To Phrase This Question

2.8 Does Configurator Depend on Information Collected Upstream?

Other Ways To Phrase This Question

Starting Your Model Design 2-5

2.9 Does Configurator Pass Non-Orderable Information Downstream?

Other Ways To Phrase This Question