Configuration Rules
About this article
This article will give detail information about developing configuration rules using Oracle Configurator Developer. Prerequisite to read this article is reader should have read previous two articles on Oracle Configurator published on this website.
After going through this article, reader should be able to define following types of rules viz. Logic Rules, Numeric Rules, Design Charts, Compatibility Rules, Comparison Rules, Statement Rules. We will also cover little bit of Constraint Definition Language (CDL) which is generally used in Statement Rule. These rules become backbone of Configurator UI and hold all the business logic behind configuration MODEL.
What are configuration rules?
Configuration Rules can be thought of as computer-assisted selection of products, components, features, and options. These relieves user from making decisions of final components being selected in configurable product.
Technically configuration rule can be defined as an explicit definition of all valid logical relationships a collection of configurable items and compatibility relationships among items
One of the most critical activities in constructing a 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 define rules to express relations and compatibilities among the Components, Features, Options, BOM Option Classes, and BOM Standard Items in your Model.
Types of Configuration Rules
Logic Rules: Relate one or more Features or Options to other Features or Options, using a logic relation
Numeric Rules: Perform a numeric operation on one or more Features or Options and place the result in a Total or Resource
Comparison Rules: Determine the logic state of an item based on a comparison of two numeric values
Property-Based Compatibilities: Compare the values of Feature Properties i.e. it specifies matches between the options of one or more Features or BOM Option Classes that have a common Property/item catalog value. E.g. using a property of each item within the RAM Option Class, ensure that the amount of memory is adequate for the computer’s intended use.This type of rules can be extensively used if product structure is designed with catalog groups and elements
Property-based Compatibility Rules require much less maintenance than Explicit Compatibility Rules because they are updated automatically when their Properties change. Define a Property-based Compatibility Rule in Configurator Developer when you need to create a single comparison relationship between two structure nodes. To define more than one comparison among multiple nodes, define a Statement Rule using the COMPATIBLE keyword.
Explicit Compatibilities: Specifies matches between the options of one or more Features or BOM Option Classes in explicit tabular form. E.g. ensure that the total amount of RAM supports the selected software applications.
Design Charts: Express complex explicit compatibility relationships. E.g. Selecting the Basic system adds a 17” monitor, the small PC case, 128 megabytes of RAM, and an 800 MHz processor to the configuration.
Configurator Extension Rules: Are programming objects that are attached to a Model to extend the functionality of the run-time Configurator through established interfaces. The Functional Companion/Extension Rule communicates with your Model through an application programming interface (API) in Java programming language called the Configuration Interface Object (CIO).
Imported BOM rules
ATO/PTO BOM Models and their Option Classes are used to automatically create model hierarchy. Models, Option Classes, and Standard Items are automatically populated into the Model. Implicit rules from an ATO/PTO model enforce the following:
Mutually Exclusive: Rules apply to parent nodes from which you can choose only one of all optional child nodes
Minimum/Maximum: At least x and at most y Options can be selected to create a valid configuration.
Default Quantity (Quantity Cascade): Calculations determine the final quantity requirements for the selected child node
Required: Rules apply to child nodes that are required with the parent node (whenever the parent is selected, the required child BOM Items are also selected)
Please note that the imported BOM Model is read-only. However, you can construct additional entities to extend the Model (for example, add customer requirements, Totals, Resources, and so on).
Rule Sequences:
A Rule Sequence is a set of configuration rules ordered by their effective dates. It is useful when a model has rules that change over time.
Developing Configuration Rules
To start developing rule, click on edit of the Imported BOM in Repository Screen. This will take you to Workbench for given Model Click on Rules Link.
Logic Rules
Logic Rules enable you to express constraints among elements of your Model in terms of logical relationships. For example, selecting one Option A may require that Options B and C be included in the configuration.
Logic rules define item to item relationships. Logic Rules can push both ways. For example, Side A can impact the logic state of Side B, and Side B can impact the logic state of Side A Either side of the rule can contain one or more Features, Options, and so on. Configuration validity at run time is ensured by Oracle Configurator.
Types of Logic Rules
Requires
The Requires Rule definition sets up a relationship that “pushes” both ways. That is, if you set either side to true or false, the other side is set to the same state. Additionally, the selection of one item requires selection of another item. This is two-way kind of relationship.
Selection of an item selects another item, and vice versa. The two items are forced to have the same logic state.
If A is true, then B must be true
If B is true, then A must be true
If A is false, then B must be false
If B is false, then A must be false
Implies Rule
The Implies Rule definition sets up a one-way relationship. That is, the selection of one item selects another item, but not the reverse. Selection of one item selects another item, but not the reverse.
Implies Rule Definition
If A is true, then B must be true
If A is not true, then B can have any value
If B is true, then A can have any value
If B is false, then A can be either false or unknown, but not true
For example, if you select a large monitor, you need a video card. Therefore, when you select a large monitor, it implies a video card, but it does not require the reverse to be true. In other words, you should be able to buy the video card without also buying the large monitor.
Negates Rule
Selection of one item prohibits selection of another item, and vice versa. The two items are forced to have the opposite logic state.
Negates Rule Definition:
If A is true, B is false
If A is false, B is true
If B is true, A is false
If B is false, A is true
Excludes Rule
The Excludes Rule definition sets up a one-way relationship. That is, the selection of one item prohibits another item, but not the reverse.
Excludes Rule Definition:
If A is true, then B must be false
If A is false, then B can have any value
If B is true, then A must be false
If B is false, then A can have any value
For example, if the end user selects software applications that exceed the amount of memory previously selected, the system displays a contradiction message. The user can then either remove one or more applications or increase the amount of memory to continue.
Defaults Rule
The Defaults rule definition sets a specified Feature or Option to true as a result of another selection. A specified Feature or Option is set to true only if it is available. The Defaults rule is similar to the Implies rule, only it is gentler. "A Defaults B" means that whenever A is selected and B is available, B is selected.
The Defaults rule sets a specified Feature or Option to some value as the result of another selection. Defaults rules are useful if you want to drive initial values at the beginning of a configuration session from customer requirements selections.
Defaults rules do not display a violation message at run time since they just select default options and can always be overridden by the end user.
All True/Any True
All True | Any True |
Logical AND | Logical OR |
All of the entities need to be true for logical true | Any of the entities need to be true for logical true |
Any of the entities need to be false for logical false | All of the entities need to be false for logical false |
Implies Logic Rule
Numeric Rules
Numeric Rules express constraints between elements of your Model in terms of numeric relationships. With Numeric Rules, end-user selections can contribute to or consume from a Resource, Total, Numeric Feature, Option count, or the minimum or maximum number of component instances allowed in a runtime Oracle Configurator.
Totals and Resources are used for:
Accumulating values
Example: Track the total amount of disk space available to ensure that you cannot consume more than you have of a resource
Example: Prevent the end user from ordering more than the maximum number of memory slots available in a personal computer
Adjusting the count of an option:
Example: Ensure that a battery pack is provided with each laptop computer ordered
Numeric Rule performs numeric operation on one or more Nodes viz. Totals or Numeric Features, Boolean expressions, Option Counts, Option properties and Constants. Values can be multiplied or divided before they are accumulated. The result is placed in: Total, Resource, Option Count, and Numeric Feature
Numeric rule types:
Contributes - Example, Each time a software application is selected, add a value to a Total called "Applications Disk Space"
Consumes -Example, Each time the user selects a Hard Drive or CD-ROM, subtract 1 from a Resource called “Bay Slots”
Numeric rules follow the Quantity Cascade rules. For example, an Option cannot contribute to or consume from its parent node (a Feature). A rule defined this way produces an error at run time.
Boolean expressions are expressions that can have a true/false value. A value of true is interpreted as a one (1) and a value of false is interpreted as zero (0).
Use Numeric Features to make Advanced Expressions more readable. If you put a constant into an Advanced Expression, the meaning of the number is lost, so define a Numeric Feature and use that instead. You can exclude a Numeric Feature from the run-time user interface by setting the option “Display in User Interface” to No. Values of Totals and Resources are stored as decimal numbers. Multiply option counts by option properties to easily.
Rule Name: Floppy CONSUMES from Bay Slots
A Side:
Floppy Drive - 1.44 MB (CM67433, from Disk Drive Option Class)
* Constant = 1
CONSUMES FROM B Side: Bay Slots (Resource)
When this rule comes into effect after selection of Floppy drive number of Bay Slots available are reduced by 1
Rule Name: Set 1GB RAM for Ultra
A Side:
Ultra * Constant (Quantity Multiplier) = 2
CONSUMES FROM B Side: Memory 512 (CM08512) to make 1 GB
When this rule is activated after selection of Ultra Option automatically 2 quantities of CM08512 (512 MB RAM) gets selected to make it 1 GB.
Comparison Rules
This type of rules compares and validate numeric values. e.g. following rule compares Application disk space to 120 GB and accordingly excludes certain hard disk components
Compatibility Rules
There are three types of Compatibility rules:
Explicit Compatibility rules: Express compatibility constraints among Options of your Model that cannot be described in terms of a shared Property. Specify explicit matches between the Options of one or more Features Set a logic state of False on Options that are incompatible with a selected Option
Property-Based Compatibility rules: Perform a comparison between property values shared by Features or Option Classes. It can include multiple comparisons among the participating Features. It Specify the Properties to be checked for compatible values .It specify the type of comparison to be made between the Property values, using standard numeric and string comparison operators
To create a Property-Based Compatibility rule, participants must be Features with Options that have Properties and All Options used in the rule must have a common property. These are easier to implement because individual options are actual inventory items which are maintained in Oracle Inventory and populated to CZ schema through concurrent program.
For example based on Memory Property of Model Node "Which Application You want to run" the rule compares RAM property of Memory Option Class and selects the component accordingly. As you can see the relationship between to Options is not explicit. It is based on Property values (Catalog Values) of individual items/options.
Design Charts:
Express complex explicit compatibility relationships. It contains various features.
Primary Feature: Options define variations of the Model
Secondary Features: Defining Features: Unique combinations of options that define options of the primary Feature
Optional Features: Options can be compatible or incompatible with Options of the primary Feature. It can have multiple secondary Features.
The example used is about prepackaged system
If you closely watch above screen shots, there are three options for "Select a Prepackaged System" viz. Basic, Work and Ultra. Now after adding Optional Option features, the define rule screen allows selection of individual components Based on Basic, Work or Ultra i.e. if User Selects Basic the one component of a given class gets selected while for Work there can be a different component.
Statement Rules
You define a Statement Rule by entering text rather than building the rule interactively by selecting Model structure nodes and operators. A Statement Rule must be written using the Constraint Definition Language (CDL). Statement Rules can define a Logic or Comparison relationship, a Numeric contribution or consumption, or a Property-based Compatibility relationship. Explicit Compatibilities and Design Charts cannot be expressed using a Statement Rule
Statement Rules enable you to:
Write a rule using multiple operands in a single CDL statement
Include multiple abstract relations in a single rule
Define both sides of a rule in a single expression
Examples:
Following statement rule uses FOR ALL key word and adds "Hard Disk Capacity" Property values of all hard disks selected to a Total type of node "Total Disk Space". Here &x represent all selected hard disk options.
Constraint Definition Language (CDL) and some examples
The Constraint Definition Language (CDL) is a modeling language. CDL allows you to define configuration rules, the constraining relationships among items in configuration models, by entering them as text. Valid data types when defining a rule in CDL are INTEGER, DECIMAL,BOOLEAN,TEXT,Node types.
Following examples can give you an idea about the power and usage of CDL in configurator
Following configuration rule calculates the size of glass to be put into a window frame for each Window instance. The glass is to be inserted into the Frame 1/2 inch at each side. To capture such a rule, you would provide a name, such as WindowGlassSize, a description, and then associate the rule with the Window Model.
CONTRIBUTE Frame.Width - 2 * Frame.Border + 2 * 0.5
TO Glass.Width;
CONTRIBUTE Frame.Height - 2 * Frame.Border + 2 * 0.5
TO Glass.Height;
An example configuration rule constrains the window frame color so that for some colors, the finish is glossy. An iterator lets you define a rule that selects the glossy finish based on a Property. The variable &color refers to all the Options of the Feature Color, in the Frame Component of the Window Model. The rule selects a glossy finish when one of those colors is selected AND the Property RequiresGlossyFinish is true.
CONSTRAIN &color IMPLIES Frame.Finish.Glossy
FOR ALL &color IN OptionsOf(Frame.Color)
WHERE &color.Property ("RequiresGlossyFinish") = "True";
To select a glossy finish for every Option of the Feature Color, make the Boolean Property RequiresGlossyFinish imply a glossy finish.
CONSTRAIN &color.Property("RequiresGlossyFinish") IMPLIES Frame.Finish.Glossy
FOR ALL &color IN OptionsOf(Frame.Color)
Please refer to Constraint Definition Language (CDL) Guide Release 11i for all the syntaxes of CDL.
Summary:
In this article we covered almost all types of rules and a brief about CDL. Configurator extension rules which will be covered in next article which will be more technical topic.
Technical folks stay tuned and brushup your JAVA skills for writing Java/SQL code in configurator using configurator extension rules and wait for next article.
Apps2Fusion Articles 
Comments
This person can sit anywhere and needs to be a TECHNICAL Oracle Configurator NOT functional. This position will call for 50% travel.
To learn more about this opportunity please send you resume to andrew.augustine
Job description:
T his position will be responsible for particular levels of effort of Configurator module of the Oracle Implementation. As a member of the global design team this position will work closely with local Configurator and Order Management resources to create configurable models and implement these for various sales and service modules including Order Management, Quoting, iStore, and Installed Base. In addition, this position will also be responsible with the Global footprint.
Thi s position will establish and TECHNICALLY lead the team that will develop and support Configurator models on an ongoing basis.
The ideal candidate for this position will have intimate knowledge of Configurator design and modeling, Bill of Material restructuring, and the Oracle Configurator to Order processes. It would also be beneficial if the candidate had some familiarity with and awareness of Advanced Pricing, Configurator attributes, and designing Configurator Extensions are also required.
Key Tasks
Provide solution design and validation testing around:
Bills of Material restructuring
C onfigurator model structure
Confi gurator rules
Configura tor user interfaces
Nami ng conventions
Dev elop Standards and Guidelines around Configurator Modeling
Lead and manage Configurator TECHNICAL development activities across sites, responsible to Project Management Office
After implementation should provide leadership towards continuous improvement
Tea ching and Developing users at the site on the Configurator functionality of Oracle, if necessary
Docum ent and review materials for setup and training
The hire categories will work with the Quote to Order technical team/support team to perform production support and new development in the area of Oracle 11i Configurator and related e-Business applications. Specifically, these individuals will serve as manager, researcher and developer on analysis, design, development, enhancements, and testing of the Oracle Configurator, Quoting, Sales Contracts, Install base and Order Management applications. These individuals will work directly with functional support team and Users to resolve production problems. Production support requires a 7x24 response for emergency conditions and off-hours work for build releases.
Andr ew Augustine
Disy s Corporation
Te chnical Recruiter
1425 Greenway Drive
Suite 650
Irving, TX 75038
(214)329 -0125 (office)
(972) 550-6036 (fax)
(972)849 -5785 (cell)
andrew.augustine
I hope somebody could help me with this?
In the configurator, I created 2 instances of BOM Model by setting Multiple or Variable Instances Min/Max to 2/2, and the Model have structure as:
BOM Model
+ Selections [Component]
+ Orentation [Option Feature]
+Left [Option]
+Right [Option]
Is there a way to set Left option for first instance, or Right option for 2rd instance by using CDL rules?
Thank you very in advance
Max
The Rules above are always refering or included two or more features or options.
Can't we have validation on a feature using rules like cant we make a feature or option selection mandatory without the help of another feture or option
can some one please respond and give some elaborated explanation of this with an example.
THank s
Ram
is there any automated process to migrate configurator customizations between instances?
tha nks,
Anindya
It kind of feels too complex and extremely vast for me.
I'm taking a look ahead to your next put up, I will try to get the grasp of it!
RSS feed for comments to this post