Comparison and Compatibility Rules

This chapter covers the following topics:

Comparison Rules

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

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.

Compatibility Rule Participants and Maximum Selections

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:

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:

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 Compatibilities

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:

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.

Requirements for Creating a Property-based Compatibilty Rule

Before creating a Property-based Compatibility Rule, be sure that:

Property-based Compatibility Requirement: Common Properties
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:

To create a Property-based Compatibility Rule, see Defining Property-based Compatibility Rules.

Explicit Compatibilities

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.

Compatibility Rule Example
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.

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:

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

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.

Behavior Using Gated Combinations

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:

Or, all of the following are true:

If you recently upgraded your Configurator Developer installation, you may notice that the behavior of Compatibility Rules has changed in the following circumstances:

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.

Rules that Depend on Unknown and False Logic States

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:

Propagation of False

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.