Rule Classes

A rule's class determines when and how it's applied at run time, not its run time behavior.

The rule classes available in configurator rules are described in the following table.

Rule Class

Description

Constraint

A rule with a class of Constraint must always be true.

See the fuller description in the information about Constraints.

Default

A rule with a class of Default is like a less strict constraint. The constraint engine will try to make the rule true but if that's not possible the rule will be ignored.

A Default rule gives you some control over the sequence of rule evaluation

Some operators can't be used in Default rules.

See the fuller description in the information about Defaults.

Search Decision

Like Default, but but applied during the process of finishing a configuration (the autocompletion process).

See the fuller description in the information about Search Decisions.

Choosing Rule Classes

When defining a rule in the Configurator Models work area, you must assign the rule to a Rule Class. Configurator refers to a rule's Rule Class when an end user is manually configuring a product and when the autocompletion process is running.

A rule's Rule Class determines the following at run time:

  • The rule's general behavior

  • Whether the rule is mandatory (meaning that it must always be True in the configuration)

  • At what point in the configuration session the rule is applied (Defaults and Search Decisions only)

Caution: New Defaults and Search Decisions appear at the end of their respective sequence, and changing an existing rule's Rule Class from Default or Search Decision to Constraint may adversely affect a well-defined sequence. Therefore, be sure to review and unit test the sequence of Defaults and Search Decisions after modifying a rule's Rule Class.

Constraints

Constraints are applied at run time while an end user manually selects options and enters values during a configuration session.

Constraints must always be true in the context of a configuration. For example, when the end user makes a selection that violates a Constraint at run time, Configurator displays a contradiction message informing the user that the previous action can't be applied.

A Constraint may be expressed as a logical expression, a numeric comparison, or a compatibility expression.

Unlike Defaults and Search Decisions, you can't specify the order in which you want Configurator to consider Constraints at run time.

Relational operators can be the primary operator within a Constraint. Consider the following examples that use the equals ( = ) and greater-than ( > ) relational operators:

x = y + (q*z)
a > b

In these simplified expressions of rules, the left-hand side of the expression can propagate (or "push") numeric information to the right-hand side. In the constraint engine, the right-hand side of the expression can also propagate ("push back") to the left-hand side. The ability to define such Constraints allows rules to be bidirectional, meaning that they can propagate in both directions.

Defaults

Like Constraints, Defaults are also applied at run time while an end user manually selects options and enters values during a configuration session. However, unlike Constraints, Defaults are:

  • Flexible, and they don't lead to a contradiction at run time when, for example, the end user deselects an option that was selected by the rule.

  • Applied at run time, on the initialization of the configuration, before the user makes any selections, in the order specified in the rule definition. Defaults act like initial selections that can be overridden as the user proceeds through a configuration.

A Default can fail due to a conflict with one of the end user's inputs or the propagation of a Constraint. You can specify the order in which Defaults propagate.

You can use Defaults to guide end users toward a preferred solution by defining several contradictory rules that will be processed in the order you specify at run time.

For example, a manufacturer of laptop computers prefers that their customers purchase the lightweight version of a laptop instead of the heavier model, and the Deluxe carrying case rather than the Basic version. To guide buyers toward purchasing the lightweight laptop with the Deluxe case, without preventing them from selecting alternative options, the manufacturer defines the following rules and sequence:

1. Laptop 900 Implies 900-LTW 
2. Laptop 900 Implies Deluxe Case
3. Laptop 900-HVW Implies Deluxe Case 

With these rules in place, the lightweight version of the laptop (900-LTW) and the Deluxe Case will be selected by default when the end user selects the Laptop 900 model. If the end user then selects the heavier model (the 900-HVW), the Deluxe Case will still be selected.

Many constraints can be defined as a Default. For example, your Model contains a Numeric Feature called Weight which has a range (domain) of 1000 - 5000. You prefer a solution in which the value of this item is less than or equal to 3000, so you defined the following Statement Rule and assign a Rule Class of Default:

Weight <= 3000

When this rule propagates at run time, the range for the Weight item is reduced and appears as follows in the run time UI:

Range: 1000 to 3000

If the user makes some selections that result in a Weight outside this range, the default is retracted (overridden) without consequence.

Rules classified as Defaults may be expressed as assignment functions.

Search Decisions

Rules that you classify as Search Decisions are applied:

  • During the autocompletion process

  • After all user selections, Constraints, and Defaults have been applied and propagated

  • Before the application of the constraint engine's inherent Search Decisions

  • In the order that you specify in the rule definition

Rules classified as Search Decisions may be expressed as assignment functions, logical expressions, or numeric comparisons.

Specifying a Sequence for Defaults and Search Decisions

At run time, the autocompletion process applies rules classified as Defaults and Search Decisions according to the sequence that you specify in the rule definition. When you define a rule and classify it as either a Default or Search Decision, Configurator assigns a default sequence number which places the rule at the end of its respective list. For example, you have five existing rules with the "Defaults" Rule Class. When you create a new rule and specify a Rule Class of Defaults, the new rule appears at the end of the list of Defaults rules, and its sequence number is 6.

If you want a rule to appear earlier in its respective sequence, click either Reorder Defaults or Reorder Search Decisions in the Rules area of the Edit Model page..

Note: At run time, any rules that have cross-model or cross-instance participants won't necessarily be applied in their specified sequence relative to the other rules defined in the Model. The order of a set of such rules that apply to the same scope (combination of Models or instances) will remain as defined relative to one another, but as a group they will be applied after instantiation of the scope (all the rule's participants) and application of all the rules of that class defined within the various instances of the scope.

To modify the order in which Defaults or Search Decisions are applied at run time:

  1. On the Rules tab of the Configurator Models work area, click Reorder Default Rules or Reorder Search Decision Rules.

  2. Click one of the arrow controls to move the selected rule up or down in the sequence.

  3. Review the updated sequence.

  4. If you're satisfied with the changes, click Save.