This chapter covers the following topics:
Use Comparison Rules to compare two numeric values to produce a logical result. In this type of rule, two numeric values are compared to determine if the first value is greater than, greater than or equal to, less than, less than or equal to, equal to, or not equal to the second value. The result of this comparison is a logical value (true or false). For example, the numeric value of one Feature or Option compared to the numeric value of another may require that another option be included in the configuration.
For example, the following rule states that when Numeric Feature A is set to 100, Option X is selected:
Numeric Feature A equal to 100 Implies Option X
To define a Comparison Rule, see Defining Comparison Rules.
For important guidelines to consider when defining Comparison Rules, see the Oracle Configurator Modeling Guide.
Compatibility Rules include Property-based Compatibilities, Explicit Compatibilities, and Design Charts. Each type of Compatibility Rule defines what items are allowed in a configuration, when some other item is selected. A Compatibility Rule compares Options of one or more Option Features, and children of one or more BOM Option Classes (typically BOM Standard Items, but may also include other BOM Option Classes).
Note: In this section, the term "feature" (lowercase "f") refers collectively to Option Features and BOM Option Classes.
Explicit and Property-based Compatibility Rules enumerate all of the allowed combinations of options from the participant features. In other words, if a selection is made from each participant feature and those selections don't correspond to one of the rows of the compatibility table (in an Explicit Compatibility Rule) or satisfy the property-based criterion (in a Property-based Compatibility Rule), there is a contradiction. A Compatibility Rule does not constrain selections from only a subset of the participant features.
Unlike Logic Rules, Compatibility Rules do not actually select anything at runtime. In other words, they do not add a compatible option to the configuration by setting its logic state to Logic True. Compatibility Rules only set the logic state of any options that are incompatible with an end user’s selection to Logic False (which corresponds to the Auto-Excluded selection state).
Property-based Compatibilities define compatibility relationships in terms of the values of Properties shared by options within an Option Feature or BOM Option Class. For details, see Property-based Compatibilities. Explicit Compatibilities and Design Charts provide two different formats to explicitly define which options are compatible with each other.
For details, see:
For important information about the default runtime behavior of Compatibility Rules, see Gated Combinations.
A Compatibility Rule’s behavior is affected by how many of a participating node’s children can be selected at runtime. The action of Compatibility Rules is most clear when each Option Feature involved in the rule has a Maximum Selections of 1, or all of the children within each BOM Option Class are mutually exclusive.
For this reason, Oracle recommends that you use only the following when defining Compatibility Rules and Design Charts:
Option Features that have a Maximum Selections of 1
BOM Option Classes that have the Optional Children are Mutually Exclusive setting set to Yes
For example, when an Option Feature involved in a compatibility relationship has a Minimum Selections of 1 in Configurator Developer and all Options but one are excluded at runtime, Oracle Configurator selects the remaining Option (in this case, its selection state is Auto-Selected). Additionally, when an end user selects one of the Feature’s Options, the rule excludes the other Options (that is, their selection state is Auto-Excluded). Both examples also apply when an Option Class participates in the rule and all of its optional children are mutually exclusive.
If one or more participant Features have a Maximum Selections greater than 1, or the children of a BOM Option Class are not mutually exclusive, the rule’s behavior is more complex and may be confusing at runtime.
For example, Feature 1 and Feature 2 both have a Minimum Selections of 1 and a Maximum Selections of 1. Feature 1 has three Options: Option A1, Option B1, and Option C1. Feature 2 also has three Options: Option A2, Option B2, and Option C2. You define a Compatibility Rule that includes Feature 1 and Feature 2 as participants, and specify the following compatibilities:
Option A1 and Option A2
Option B1 and Option B2
Option C1 and Option C2
At runtime, when the end user selects Option A1, Options B2 and C2 become Logic False. If the end user selects Option B1, Options A2 and C2 become Logic False. If the end user selects Option C1, Options A2 and B2 become Logic False.
Now consider an example when the same Features both have a Minimum Selections of 1 and a Maximum Selections of 3. You define a Compatibility Rule that includes Feature 1 and Feature 2 as participants, and specify the same compatibilities as in the previous example.
In this case, an Oracle Configurator end user is not limited to only one compatible selection for each option. In fact, because the Maximum Selections for both Features is 3, the rule allows any combination of its participants.
For more information about the settings described in this section, see:
Property-based Compatibility Rules define compatible combinations of options based on User Property values. For example, word processing software has a RAM Required Property and a laptop computer has a RAM Supplied Property. You can create a Property-based Compatibility Rule to ensure that the amount of RAM that the software requires is less than or equal to the amount of RAM that the computer provides. For an additional example, see Property-based Compatibility Requirement: Common Properties.
Many types of Model structure nodes can have User Properties, but only BOM Models, BOM Option Classes, and Option Features can participate in a Property-based Compatibility Rule.
When an Oracle Configurator end user makes a selection at runtime, a Property-based Compatibility Rule excludes from the configuration all options that are incompatible with the end user’s selection. In other words, the incompatible options are set to Auto-Excluded, but compatible options are not automatically selected. For details about selection states, see Selection State.
Property-based Compatibility Rules require much less maintenance than Explicit Compatibility Rules because they are updated automatically when any of the participating node Properties are modified. If both participants in a Property-based Compatibility Rule are BOM Models or BOM Option Classes, the rule is updated when you reimport (refresh) the BOM Model. If the participants are Option Features, the rule is updated immediately when any Properties of either Feature change or, if the Feature has a Populator, when repopulating the Model adds or deletes child Options.
A Property-based Compatibility Rule:
Enumerates the BOM Models, BOM Option Classes, and Option Features that participate in the rule
Specifies the Properties to be checked for compatible values
Specifies the type of comparison to be made between the Property values, using standard numeric and string comparison operators, such as equals, greater than, contains, and like
Define a Property-based Compatibility Rule in Configurator Developer when you need to create a single comparison relationship between two Model nodes. To define more than one comparison among multiple nodes, define a Statement Rule using the COMPATIBLE keyword. For details, see Overview of Statement Rules.
Note: When defining Property-based Compatibility Rules, Oracle recommends that you do not use User Properties whose data type is Translatable Text. Using Properties with this data type in rules can cause the rule to become invalid when the text (the Property’s value) is translated.
Before creating a Property-based Compatibility Rule, be sure that:
Each Option Feature that participates in the rule contains Options, and each Option has one or more Properties.
Similarly, each BOM Model or BOM Option Class must have children (that is, BOM Models, BOM Standard Items, or other BOM Option Classes), and each child must have one or more Properties.
All of the children of the node that participates in the rule must share at least one common Property (the Property values can be different).
Additionally, when you select a node as a rule participant, only Properties that are shared by all of the node’s children appear in the list for selection and therefore can be part of the rule's definition.
For example, the participating nodes in a Property-based Compatibility Rule include a BOM Option Class called Door and a Feature called Door Trim. All of the Standard Items of the Door Option Class must have at least one Property in common, and all of the Options of Door Trim must also have at least one Property in common. Any Properties that are not common to all of the child nodes do not appear in the list. Refer to the example shown in Property-based Compatibility Requirement: Common Properties below.
Rule Participant | Child Nodes | Property Name and Value |
---|---|---|
Door (BOM Option Class) | Oak (BOM Standard Item) Maple (BOM Standard Item) |
Paint Color = Red Weight = 66 Paint Color = White Weight = 41 Panels = 6 |
Door Trim (Option Feature) | Standard (Option) Deluxe (Option) |
Trim Color = Red Trim Color = White |
When Door and Door Trim are participants in a Property-based Compatibility Rule:
The available child Properties for Door include Paint Color and Weight. The Property called Panels does not appear in the list because it is assigned only to the Maple BOM Standard Item.
The available child Property for Door Trim is Trim Color.
To create a Property-based Compatibility Rule, see Defining Property-based Compatibility Rules.
Explicit Compatibility Rules express compatibility constraints among options of your Model that cannot be described in terms of a shared Property. An Explicit Compatibility Rule allows you to specify, in tabular form, explicit matches between the options of one or more BOM Models, BOM Option Classes, or Option Features.
There can be no blank cells in a compatibility table. Options can be repeated in a column as many times as needed to define the available combinations.
For example, consider an automobile model line with several color choices. Compatibility Rule Example lists which colors (Options) belong to each Feature.
Features | Option | Option | Option |
---|---|---|---|
Exterior | Red | White | Black |
Interior | Tan | Gray | Black |
Trim | Gold | Chrome | Black |
Some color combinations are available, others are not. The available color combinations can be expressed in a compatibility table as shown in Compatibility Rule Table.
Exterior | Interior | Trim |
---|---|---|
Red | Tan | Gold |
White | Gray | Chrome |
Black | Black | Black |
Red | Gray | Black |
Black | Gray | Gold |
Each row in Compatibility Rule Table defines a valid combination of exterior, interior, and trim colors. In this example:
The Red exterior can have only a Tan or Gray interior, and either Black or Gold trim.
The White exterior can have only a Gray interior and Chrome trim.
The Black exterior can have a Black interior with Black trim, or Gray interior with Gold trim.
The Gray interior color goes with each exterior color and each trim color, but only three specific combinations of both.
To create an Explicit Compatibility Rule, see Defining Explicit Compatibility Rules.
Note: For important information about Compatibility Rule participants, see Compatibility Rule Participants and Maximum Selections.
Gated Combinations refers to the conditions at runtime that cause Oracle Configurator to propagate false in Explicit Compatibility Rules, Property-based Compatibility Rules, and Design Charts. These conditions are determined by a setting in the CZ_DB_SETTINGS table called GenerateGatedCombo.
The default value of this setting is Yes and it produces runtime behavior that is considered preferable as it causes Oracle Configurator to exclude more incompatible selections than it would otherwise. However, if you recently upgraded your Oracle Configurator Developer installation and your Compatibility Rules or Design Charts are producing different and undesirable results, you can restore the old behavior by setting GenerateGatedCombo to No. For details, refer to the section about the CZ_DB_SETTINGS table in the Oracle Configurator Implementation Guide.
Compatibility Rules are expected to propagate false along a row of an option that is selected (that is, included in the configuration) when all of the following are true:
There is only one Feature in this Compatibility Rule that is not selected
The option belongs to the remaining Feature that is not selected
The option is unavailable (false)
The option does not belong to another row of the Compatibility table that is invalid
Or, all of the following are true:
All of the Features of the Compatibility table have been selected
The option is unavailable (false)
The option does not belong to another row of the Compatibility table that is invalid
If you recently upgraded your Configurator Developer installation, you may notice that the behavior of Compatibility Rules has changed in the following circumstances:
One or more participant Features in the rule are optional. In other words, the Feature’s Minimum Selections setting is 0 (zero).
Setting GenerateGatedCombo to No may force available selections to be false based on the possibly incorrect assumption that the user will eventually make a selection from an optional Feature. But a Compatibility Rule should be interpreted to constrain only complete sets of selections from all of the participant Features; if an end user makes selections only from a subset of the participant Features, the Compatibility Rule should not affect their selections. That is why this behavior, which is preferable, is the default as it causes fewer Options to be set to false than it would otherwise.
For example, a Compatibility Rule constrains selections from Features X (Minimum Selections = 1 and Maximum Selections = 1), Y (Minimum Selections = 0, Maximum Selections = 1), and Z (Minimum Selections = 0, Maximum Selections = 1). Unless and until the end user makes a selection from Z, or a rule requires that they do so, the end user should be permitted to select Options X1 and Y1 even if no allowed combination of X, Y, and Z contains X1 and Y1.
The rule includes one or more participant Features with a Maximum Selections greater than one.
Setting GenerateGatedCombo to No prevents assumptions based on excluded Options from such Features until the maximum number of selections is reached. A Compatibility Rule should be interpreted to require that every selected Option must be part of a combination allowed by the rule. Any excluded (false) Option from such a Maximum > 1 Feature could be used to rule out Options from the other participants that are compatible only with the excluded Option, even if the maximum number of selections has not been reached.
The default behavior (GenerateGatedCombo set to Yes) permits this assumption and causes more Options to be forced false.
Note: For important information related to the following example and rules with participant Features that have a Maximum Selections greater than 1, see Compatibility Rule Participants and Maximum Selections.
For example, A Compatibility Rule constrains selections from Features A (Minimum = 1 and Maximum = 1) and B (Minimum = 1 and Maximum = 2). The rule allows the following combinations of selections from A and B: {A1, B1}, {A1, B2} and {A2, B3}. In addition, a Logic Rule states that Option X Excludes B3. When the user selects Option X, B3 becomes Logic False. Because of the Compatibility Rule, Oracle Configurator concludes that A2 must also be Logic False, because no other selection from B is compatible with A2.
The rule includes one participant Feature with Maximum Number of Selections greater than one.
For example, a Compatibility Rule constraints selections from Feature A (min=1, max=1) and Feature B (min=1, max=2). The rule allows the following combinations of selections from A and B: {A1, B1}, {A1, B2}, and {A2, B1}. If the user selects B1 and B2, the rule cannot exclude A2 (even though A2 cannot be part of the solution) at this point because there is no true propagation. If the end user then selects A2, Oracle Configurator displays a contradiction message. Otherwise, if the end user then selects A1, the configuration will be complete.
In most Models, the default behavior (GenerateGatedCombo set to Yes) provides more desirable behavior from the end user's perspective. It avoids invalid assumptions, and makes more valid ones.
If you upgraded from a previous release of Configurator Developer, the default behavior will affect the outcome of a configuration session only if your Model contains rules that depend on the distinction between Unknown and Logic False.
There are two types of rules that can do this:
Logic Rules that use the Negates relation, or Statement Rules with operands that contain the NOT operator. The consequences of these rules are propagated when the Negates or NOT operator's operand is Logic False but not when it is Unknown. See Propagation of False.
Note: This is not the case for rules that use the NotTrue operator.
Numeric or Comparison Rules involving Numeric Features or Totals with no initial values where the numeric result distinguishes between a value of zero and an Unknown value. See Rule that Contains a Total with No Initial Value.
A and B are Options. You define the following rule:
(NOT A) Implies B
In this case, B is True (selected) when A is false but not when A is Unknown.
Since it is difficult (and inadvisable) to force all not selected Options to be false, rules of this type are not recommended.
Rule that Contains a Total with No Initial Value
T is a Total with no initial value. A and B are options. You define the following rules:
(A*1) Contributes To T (T<1) Implies B
As in Propagation of False, B is True (selected) when A is false but not when A is Unknown.
Note that rules such as the one shown in this example are likely to produce unexpected results and should therefore be avoided. For more information, refer to the Oracle Configurator Modeling Guide.