Starting Your Model Design
Before reading this chapter, review the planning guidelines in Planning Your Model Design to help identify areas of special considerations 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.
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.
This chapter covers the following topics:
- 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?
- Are your configuration rules based on legacy rules?
- Do You Need to Express Compatibilities in Your Model?
- Do You Need to Express Comparisons in Your Model?
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?
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:
Rule Decisions
Apply the following best practices when optimizing the rule design of large numbers of options:
UI Decisions
Apply the following best practices when optimizing the UI design of large numbers of options:
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 as 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 Repeating Similar Product Elements graphic.
The graphic shows two BOM Option Classes, "Option Class 1," and "Option Class 2." Each BOM Option Class contains Options, some of which are repeated in the two BOM Option Classes, and some of which are not. "Option Class 1" contains Options A, B, C, and D, while "Option Class 2" contains Options A, B, C, E, and F. An arrow points to a third BOM Option Class that contains a union of the Options A, B, C, D, E, and F.
Repeating Similar Product Elements
Repeating Similar Product Elements shows that when the separate and duplicated structure is combined, the total structure that has to be loaded, instantiated, or maintained is smaller. In this example, the number of nodes has been reduced from 11 to 7, a reduction of 36%. 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.
Other Ways To Phrase This Question
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:
Are You Modeling Many Related Products?
Hundreds or thousands of separate products with similar or duplicate items cause maintenance, performance, and scalability problems.
Other Ways To Phrase This Question
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:
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.
Other Ways To Phrase This Question
Do end users expect to see default, initial, or recommended values already filled in when they start up Oracle Configurator?
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:
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.
Other Ways To Phrase This Question
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:
If your end users do not expect to see the BOM, use the following best practices to optimize your model design:
UI Decisions
If your end users do not expect to see the BOM, use the following best practices to optimize your model design:
Will Configurations Contain Instances of a Component?
The word "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.
Other Ways To Phrase This Question
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:
User Interface Decisions
Apply the following best practice when optimizing the design of UIs:
-
When adding instances programmatically, add them early in the configuration session, prior to the end user making many user selections. Each time an instance is added, the user's inputs are retracted and reasserted thus affecting performance. By adding them at the beginning of the configuration session, this performance problem can be mitigated.
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.
Other Ways To Phrase This Question
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:
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. Configuration attributes are explained in Oracle Configurator Methodologies.
Other Ways To Phrase This Question
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?
Is there non-item information on the order line before configuration that Oracle Configurator needs in computations?
Structure Decisions
Apply the following best practice when optimizing structure that includes passing attributes into Oracle Configurator:
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.
For more information about configuration attributes, see Oracle Configurator Methodologies.
Other Ways To Phrase This Question
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?
Are items used to represent non-manufacturable entities to indicate details about another item or operation? For example, modeling color choices as a set of options, or a range of allowable dimensions for a product as discrete items.
Structure Decisions
Apply the following best practice when optimizing structure that includes passing attributes out of Oracle Configurator:
Are Some Selections Disallowed Until Other Selections Are Made?
The purpose of this question is to find out whether you are implementing any Statement Rules that use the NotTrue operator. This is not recommended as using NotTrue may cause propagation issues under certain circumstances if it imposes order in the rules.
Other Ways To Phrase This Question
Do you have rules that make some options not selected until some other option is selected?
Are you planning on using NotTrue in Statement Rules (rules written in CDL)?
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 practice when optimizing a rule design that imposes order on option selections, or locks the initial value of components:
User Interface Decisions
Do not use the NotTrue operator to control the selection state or visibility of options in the runtime User Interface. For example, you may want to disallow some option selections in the UI when other options are not selected, or define specific dependencies among option selections. Such dynamic behaviors can be easily implemented in a User Interface created in Configurator Developer by using display conditions. For details, see the Oracle Configurator Developer User's Guide.
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.
Other Ways To Phrase This Question
Does your model require calculations that contribute to other calculations?
Are the same Options or Features that are used in AnyTrue or AllTrue expressions used in multiple rules?
Rule Decisions
Apply the following best practices when optimizing the rule design of models containing common subexpressions or repeated patterns:
Are your configuration rules based on legacy rules?
New rules that are based existing rules from a legacy system, or rules imported directly from a legacy system, are much less likely to perform well in Oracle Configurator. Often, legacy rules contain repeating patterns or introduce redundancy, which means that several rules include the same subexpressions or have the same result.
For best runtime performance, Oracle recommends defining constraints and relations in Configurator Developer, following the general recommendations described in Best Practices.
Rule Decisions
Apply the following best practices when optimizing the rule design of models containing common subexpressions or repeated patterns:
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.
Other Ways To Phrase This Question
Do you need to express incompatibilities in your model?
Are relationships between options or items documented as tables?
Do the Options or Items that are involved in compatibility relationships have relevant property or catalog data?
Rule Decisions
Apply the following best practices when optimizing a rule design that expresses compatibilities or incompatibilities among options:
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.
Other Ways To Phrase This Question
Does your model contain comparison logic?
Rule Decisions
Apply the following best practices when optimizing a rule design that expresses comparisons: