Bookshelf Home | Contents | Index | PDF     

Product Administration Guide > Configuration Rule Assembly Language >

Special Operators

Special operators provide functions that manipulate the eConfigurator engine directly, rather than the underlying customizable product. They also provide defined types of access to the components of a customizable product.

The inc() operator is used to implement provide and consume rules. It has two important characteristics:

  • It returns a null value.
  • When it is evaluated in a subexpression, this causes the eConfigurator engine to contribute the value requested.

This means that writing rules with the inc() operator as a subexpression based on a condition do not work. The contribution will always occur. For example, you write the following rule.

req(X, inc(Y, Z))

The eConfigurator engine will contribute the value of Y to Z, regardless of whether X is present in the solution. This is because the eConfigurator must evaluate the two arguments to req() before determining what action to take. Evaluating the inc() argument causes the engine to contribute the value of Y to Z.

In addition, regardless of the value of X, the inc() argument always evaluates to null, which makes the rule meaningless.

To write rules that contribute conditionally, use the numeric conditional operator, ?().

Special operators are shown in Table 45.

Table 45.  Special Operators
Operator
Syntax                            
Properties

Constraint

con(A)

Makes A a constraint. Returns no result. A can be an item or sub-expression. Use to make sub-expressions into constraints. Redundant for top-level expressions. Rarely used.

Increment

inc(A, B,)

Each A requires a B. A can be a number, item, or sub-expression but must resolve to a number. B must be an item and cannot be a sub-expression. inc(1, B) increments the quantity of B in the solution by 1. Use inc(A,B), where A and B are items, to implement cumulative require rules.

Message

msg(A) "string"

Causes message signal when A is true (selected). User-defined message displays in user message area. Returns no result. A can be an item or sub-expression.

Check

chk(A) "string"

Causes a message-signal when A is false (not selected). User-defined message displays in user message area. Returns no result. A can be an item or sub-expression.

Preference

prefer(expression, priority)

The expression is enforced as a constraint only if it does not conflict with any other rule type or with any user selections. The priority determines the order in which multiple preference rules for an item are evaluated. Preference rules with priority 0 that apply to a specific item are evaluated first. Those with priority 1 that apply to that item are evaluated next, and so on.

With Members

withMembers(A,B)

Enforce the constraint B only on instances in A.

This operator allows you to move the context for enforcement of a constraint from the root of a customizable product to a location within it. For example, A can be a path to a relationship within the customizable product. This causes the constraint B to be enforced only within that relationship.

A can be a relationship, a class within a relationship, or a single product. B can be any expression or rule.

In B, the path must be specified relative to the path in A. For example, if A specifies relationship R1, the paths to items in B, must be specified relative to R1, not the product root. When specifying items in B, do not include any part of the path specified in A.

When adding items to B using the object picker in the Assisted Advanced Rule template, you must manually edit the item paths in B to make them relative to the path specified in A.

With Tuples

withTuples (((A, B, C), (D,E F), ...), ruleA(%1, %2, %3,...),...)

This operator allows you to specify multiple sets of operands for one or more rules. The first operand in a group is assigned to the variable %1, the second to %2, and so on. You can specify more than one rule.

More on withTuples

The withTuples operator lets you provide more than one set of operands to a rule. It has the following syntax:

withTuples (((A, B, C),(D,E F),...), ruleA(%1,%2,%3,...),...)

For example, you have the following two rules:

req(and([A],[B]),excl([C],[G]))

When both A and B are present, C and G exclude each other

req(and([D],[E]),excl([F],[G]))

When both D and E are present, F and G exclude each other.

The above two rules can be thought of as one require rule that has two sets of operands. The withTuples operator lets you write the rule in this fashion. This makes rule maintenance easier. If the operands change, you can edit them in one location, rather than having to locate all the rules in which they appear. Here is one way to combine the two rules using withTuples:

withTuples((([A],[B],[C]),([D],[E],[F])),req(and(%1,%2),

excl(%3,[G]))

Notice that each group of operands is enclosed in parentheses. Also notice that the whole section where the operands are specified is itself enclosed in parentheses.

You can also use the withTuples operator to specify the operands for multiple rules. For example, you have the following two rules:

req(and([A],[B]),[C])

inc([C], [Resource1])

If both A and B are present, C is required, and contribute the value of C to Resource1.

The above two rules are different but they make use of the same operands. You could use the withTuples operator to show that these two rules use the same operands as follows:

withTuples((([A],[B],[C])),req(and(%1,%2),%3),inc(%3,[Resource1]))

More on withMembers

The withMembers operator shifts the context for application of a rule from the root of the customizable product to a specified location within the product. This means the rule applies only to the items in the specified path, rather than wherever these items appear in the product.

The withMembers operator adds no other functionality and does not alter the function of other operators.

For example, you define Relationship A that contains only the customizable product desktop PC. The desktop PC includes two relationships: CPU and Hard Drive. You want to write the rule CPU requires Hard Drive and enforce the rule for each instance of the desktop PC. If the user adds a CPU and hard drive to a desktop PC but later removes the hard drive, you want the user to receive a configuration error for that PC.

You would write this rule as follows:

withMembers(@.Relationship A, req(@.CPU, @.Hard Drive))

This rule enforces "CPU requires Hard Drive" separately on each instance of desktop PC in Relationship A. All the desktop PCs from Relationship A must have a hard drive if they have a CPU. The rule is not enforced for PCs that appear elsewhere in the customizable product other than Relationship A.

    
Product Administration Guide