18Siebel Configurator Rule Assembly Language
Siebel Product Configurator Rule Assembly Language
This chapter explains how to create configuration constraints using Rule Assembly Language. You can use Rule Assembly Language to enter constraints instead of using constraint templates.
This chapter includes the following topics:
Why Use Rule Assembly Language?
Rule Assembly Language (RAL) is intended for those users who are more comfortable working in a programming environment rather than using templates. Those with experience using this language in previous releases can continue to use it in this release.
In many cases, a combination of RAL and constraint templates can be effectively employed as follows.
Use the existing templates to create basic configuration constraints.
Create specialized templates and use them to create constraints to handle configuration areas that are similar.
Use RAL to create highly complex or unusual constraints not easily handled by templates.
About Rule Assembly Language
All rules in the Rule Assembly Language (RAL) consist of expressions. Expressions consist of an operator and its operands. The number and type of operands depend on the operator. All expressions have the following form:
operator(A,B...)
For example, the following expression evaluates to the sum of A plus B.
+(A,B)
Most operators allow their operands to be expressions. In the expression above, both A and B can themselves be expressions.
Spaces, tabs, and new-lines are ignored in expressions.
In Rule Assembly Language, a constraint is a list of one or more top-level expressions. A top-level expression is the top-level operator and its associated operands in RAL statements.
For example, in the following statement, +(A,B) is a sub-expression and is not a top-level expression. The top-level expression is "==" and its operands. So the constraint on all solutions is that the sum of the quantities of A and B must equal the quantity of C in all solutions.
==(+(A,B),C)
A sub-expression is an expression that functions as an operand. Depending on the operator, a sub-expression returns a quantity or a logical true or false. The sub-expression itself is not a constraint.
Creating Constraints Using the Assisted Advanced Constraint Template
A special constraint template is provided for creating constraints using Rule Assembly Language. This template provides a dialog box for picking components, resources, and links. It also provides a list of RAL operators.
When you create a constraint and save it using this template, the Constraints view displays the constraint syntax in the Constraint field. The Constraints view capitalizes the first letter of operator names in the constraint for display purposes only. Operator names are case-sensitive, and the Constraints view stores them in the correct format.
To create a constraint using the Assisted Advanced Constraint template
Navigate to the Administration - Product screen.
Select and lock the desired customizable product or product class.
Navigate to the Constraints view for the Work Space version.
Click New Constraint.
The Pick a Constraint list appears.
In the Pick a Constraint list, select the Assisted Advanced Rule template, and click Continue.
The Rule Statement and "Insert a" tabs appear.
Select operators and arguments from the displayed lists to build a rule.
The operators list contains all the operators in the Rule Assembly Language. The arguments list changes depending on the operator you select and contains all the items in the customizable product. Use the Compound Field button to create sub-expressions.
Click Save Constraint to save the constraint.
The Save Rule form appears.
Fill out the fields in the Save Constraint form, and then click Save. Some fields are described in the following table.
Field Comments Name
Enter a name for the constraint.
You must use names that help you to locate the constraint using the Find button. For example, consider including the constraint type (excludes, requires and so on) in the constraint name, so you can search the Name field to find groups of constraints having the same constraint type, for example, all the exclude constraints.
Explanation
Enter an explanation of how the constraint works.
You must enter explanations that help you to locate the constraint using the Find button. For example, consider including information that uniquely identifies the constraint, such as item names, so you can search the Name and Explanation fields to find a specific constraint.
Rule Statement
Displays the constraint statement that you built.
Start Date
Optionally, specify a start date on which the constraint becomes effective.
End Date
Optionally, specify an end date after which a constraint becomes inactive.
Active
Select this checkbox to activate the constraint, so it is used to compute solutions.
Use this feature in the current work space to simulate the behavior of constraints that will have a start date, end date, or both when you release the product. You can also use this feature to deactivate a constraint but retain it in a released version of the product.
From the Constraints List menu, select Validate.
This starts a configuration session. Verify that the new rule works correctly.
Creating Constraints Using the Advanced Constraint Template
The Advanced Constraint template is similar to the Assisted Advanced Constraint Template. You can create constraints using Rule Assembly Language with either template. The Advanced Constraint template does not provide a dialog box for picking products, resources, or links. It also does not provide a list of operators.
The Advanced Constraint Template is intended primarily for upgrade users who want to edit the rules in models created in release 6.x.
You must manually enter the path to items when using this template. The following table provides examples of paths.
When you create a constraint and save it using this template, the Constraints view displays the constraint syntax in the Constraint field. The Constraints view capitalizes the first letter of operator names in the constraint for display purposes only. Operator names are case-sensitive, and the Constraints view stores them in the correct, format.
Table Examples of Paths
| Path | Explanation |
|---|---|
@.[Relationship A]([Product SubClass]) |
All the products in SubClass in Relationship A. |
@.[Relationship A]([Product 1]).[Color] |
The color attribute of all the instances of Product 1 in Relationship A. |
@.[Relationship A].[Color] |
The Color attribute of all the products in Relationship 1. |
$.[Resource 1] |
Resource 1. |
$.[Link 1] |
Link 1. |
Observe the following guidelines when writing paths:
The @ sign specifies the instance of the product or group of products on which the constraint is defined. Use the @ sign at the beginning of paths that refer to items inside the structure of a customizable product.
The $ refers to a special object called the basket that is associated with each customizable product. This object maintains a non-hierarchical, flat view of the whole customizable product. Use the $ at the beginning of a path to specify links and resources. Since links and resources are defined for the whole customizable product, they are stored in the basket.
Upgrade Users. Users upgrading from release 6.x will have rules containing paths that include syntax such as $.[product]. These paths must function normally. However, you must avoid using this syntax to create new rules. This syntax can cause solutions that contain unintended instances of products.
Use periods (.) to specify the next property in the path. A property can be a relationship name or attribute name. Do not put spaces before or after the period.
Use parentheses immediately after a relationship name to specify a subset of the items in a relationship. Parentheses act as a filter. The most common use for parentheses is to specify a subclass within the relationship. Do not put a period before the parentheses. For example @.[P]([X]).[Color] refers to the Color attribute of all the products in subclass X within relationship P.
Enter names exactly as they are displayed in the lists where they were defined. Do not use display names. You can use subclass names to filter products within a relationship even though the subclass names do not display in the Structure view.
The path syntax always refers to the actual set of items specified in the path, however many instances are present. For example, @.[X]. [Color] refers to the color attribute of all the instances of products actually present in relationship X in a given configuration. A path only refers to actual instances, not the possible instances as defined by cardinality settings.
If you create a constraint containing a path to location that contains no items, the constraint is ignored until items are present.
All paths you specify in rules must be unique and unambiguous. For example, if you have multiple relationships with the same name, paths to them may be ambiguous. If this occurs, use the Assisted Advanced Constraint template to write rules. This template uses underlying, unique identifiers to identify items.
The maximum length of a constraint is 900 characters. The UI allows rules that are longer, but they cannot be stored in the database. Using Oracle's Web Tools, you can revise the UI to enforce the 900 character limit. See Enforcing the Field Length for Entering Advanced Rules.
To create a constraint using the Advanced Constraint Template
Navigate to the Administration - Product screen.
Select and lock the desired customizable product or product class.
Navigate to the Constraints view for the Work Space version.
Click New Constraint.
The Pick a Constraint list appears.
In the Pick a Constraint list, select the Advanced Rule template, and click Continue.
The Rule Statement and "Insert a" tabs appear.
Select operators and arguments from the displayed lists to build a constraint.
The operators list contains all the operators in the Rule Assembly Language. The arguments list changes depending on the operator you select and contains all the items in the customizable product. Use the Compound Field button to create sub-expressions.
Click Save Constraint to save the constraint.
The Save Rule form appears.
Fill out the fields in the Save Constraint form, and then click Save. Some fields are described in the following table.
Field Comments Name
Enter a name for the constraint.
You must use names that help you to locate the constraint using the Find button. For example, consider including the constraint type (excludes, requires and so on) in the constraint name, so you can search the Name field to find groups of constraints having the same constraint type, for example, all the exclude constraints.
Explanation
Enter an explanation of how the constraint works.
You must enter explanations that help you to locate the constraint using the Find button. For example, consider including information that uniquely identifies the constraint, such as item names, so you can search the Name and Explanation fields to find a specific constraint.
Rule Statement
Displays the rule statement that you built.
Start Date
Optionally, specify a start date on which the constraint becomes effective.
End Date
Optionally, specify an end date after which a constraint becomes inactive.
Active
Select this checkbox to activate the constraint, so it is used to compute solutions.
Use this feature in the current work space to simulate the behavior of constraints that will have a start date, end date, or both when you release the product. You can also use this feature to deactivate a constraint but retain it in a released version of the product.
From the Constraints List menu, select Validate.
This starts a configuration session. Verify that the new rule works correctly.
Managing Constraints Written in Rule Assembly Language
Use the same procedures for copying, editing, and deleting constraints written in Rule Assembly Language that you use for constraints written using constraint templates.
You can modify the Constraints list to display the RAL version of each constraint you create using constraint templates. This is a useful way to learn RAL and to understand more fully how constraint templates work. To modify the Constraints list, see Displaying RAL in the Constraints View.
About Specifying Data in Rule Assembly Language
This topic describes how to specify numbers, strings, names, data types, and property types in Rule Assembly Language.
Numbers
You can use both integers and floating point numbers. Floating point numbers contain a decimal point.
Example of integers:
1, 100, -239Example of floating point:
3.14, 1.0, 10.567
Strings
Enclose strings in double quotes. For example:
"Parker Data Systems recommends a DSL modem"
White space in a string is treated as a character. Use a back-slash (\) as an escape character to include double quotes or a back-slash in a string. For example:
"Install these fonts in C:\\psfonts on your system"
If you put quotes around a number or anything else, it is treated as a string.
Links
Links store data extracted from Siebel databases. Links can also store the value of specific system variables. Links can be used only to define conditions. Enclose link names in square brackets.
About Operators in Rule Assembly Language
In expressions, operators define operations or relationships between operands. Operator names are case sensitive. For example, Req(A, B) is not the same as req(A, B) and will result in a syntax error.
Most operator names are entirely lowercase. However, a few contain capital letters and are noted in later topics.
Some operators expect logical operands. Others expect numeric operands. When an operand is of a type different than the operator expects, the Siebel Product Configurator engine forces the operand to the correct type.
When integers are used where floating point is expected, integers are converted to their double-precision floating point equivalent.
When floating point numbers are used where integers are expected, floating point numbers are rounded to their nearest integer value.
Numbers greater than zero are interpreted by logical operators as true.
Numbers less than or equal to zero are interpreted by logical operators as false.
When used as numeric operands, true is 1 and false is 0.
The different types of Rule Assembly Language operators are described in the following topics:
Data Operators in Rule Assembly Language. Data operators support expressions involving data that originates elsewhere in the Siebel Business Application.
Boolean Operators in Rule Assembly Language. Boolean operators take logical operands and return logical results. For example: and(A, B).
Comparison and Pattern Matching Operators in Rule Assembly Language. and pattern matching operators take numeric operands and return logical results. For example: >(A, B).
Arithmetic Operators in Rule Assembly Language. Arithmetic operators take numeric operands and return numeric results. They provide math operations such as addition and subtraction.
Attribute Operators in Rule Assembly Language. Attribute operators do comparisons and particular math operations on attribute values.
Conditional Operators in Rule Assembly Language. Conditional operators provide conditional logical and numerical relationships, such as if-then-else.
Special Operators in Rule Assembly Language. Special operators interpret their operators in a special way. Some provide access to the configuration session: for example, to signal messages or retrieve property values. They also provide binding and iteration services.
Customizable Product Access Operators in Rule Assembly Language. Customizable product access operators allow you to obtain information about other areas of the customizable product.
Data Operators in Rule Assembly Language
Use the following operators, shown in the following, when working with Siebel data types.
Table Siebel Data Operators
| Operator | Syntax | Properties |
|---|---|---|
Number |
Number(A) |
Converts the operand to a number. Operand can be an expression. |
String |
String(A) |
Converts the operand to a string. Operand can be an expression. |
Date |
Date(A) |
Converts string to a date. Operand can be an expression. |
Time |
Time(A) |
Converts the operand to a time. Operand can be an expression. |
UtcDateTime |
UtcDateTime(A) |
Converts the operand to the UTC date and time. Operand can be an expression. |
DateTime |
DateTime(A) |
Converts the operand to a date and time. Operand can be an expression. Not recommended for use. Use UtcDateTime instead. |
Currency |
Currency(A) |
Converts the operand to currency. Operand can be an expression. |
Phone |
Phone(A) |
Converts the operand to a phone number. Operand cannot be an expression. Can be used only with Equals (==) and Not Equal To (!=) operators to compare two phone numbers. |
Boolean Operators in Rule Assembly Language
When you specify this type of operator, the Siebel Product Configurator engine interprets it as true when the item is in the solution, and as false if the item is not in the solution. If you specify a resource or an arithmetic sub-expression as an operand, the Siebel Product Configurator engine interprets it as true if the expression is greater than zero, and false if the expression is less than or equal to zero.
The requires operator (req()) is an example of this type of operator. The Siebel Product Configurator engine interprets the following constraint to mean item A requires item B. In other words, if A is in the solution, B must be in the solution.
req([A], [B])
The Siebel Product Configurator engine does not interpret this constraint to mean the current quantity of item A requires the same quantity of item B. That constraint would be written as follows:
==([A], [B])
The Boolean operators are shown in the following.
Table Boolean Operators
| Operator | Syntax | Properties |
|---|---|---|
Not |
!(A) |
Logical negation. True when A is false and false when A is true. A can be an item or sub-expression. |
Requires |
req(A, B) |
A implies B. False only when A is true and B is false. B does not require A. However, excluding B, excludes A. A and B can be items or sub-expressions. |
Excludes |
excl(A, B) |
A excludes B and B excludes A. Same as "not both A and B." False only when A and B are both true. A and B can be items or sub-expressions. |
And |
and(A, B) |
Both A and B. True only when both A and B are true. When used as a top-level constraint, means that only solutions where both A and B are true are allowed. A and B can be items or sub-expressions. |
Inclusive Or |
or(A, B) |
Either A or B or both. False only when both A and B are false. A and B can be items or sub-expressions. |
Exclusive Or |
xor(A, B) |
A or B but not both. A and B must have opposite truth states. False when A and B are either both true or both false. A and B can be items or sub-expressions. |
Logically Equivalent |
eqv(A, B) |
A requires B and B requires A. True only when A and B are either both true or both false. A and B can be items or sub-expressions. |
The following table provides the truth-state definition of how the Boolean operators work. The first two columns contain the operands A and B. These could be items or arithmetic expressions, in which case A>0 means that A is in the solution.
Table Truth Table for Boolean Operators
| A >0? | B>0? | req(A, B) | excl(A, B) | and(A, B) | or(A, B) | xor(A, B) | eqv(A, B) |
|---|---|---|---|---|---|---|---|
T |
T |
T |
F |
T |
T |
F |
T |
T |
F |
F |
T |
F |
T |
T |
F |
F |
T |
T |
T |
F |
T |
T |
F |
F |
F |
T |
T |
F |
F |
F |
T |
More on the Requires Operator
The requires operator is not an incremental add. For example, you write the constraint req(A, B). If the user picks A and there are no B's in the solution, the Siebel Product Configurator engine will add at least one B. The next time the user picks A, the engine does not add another B.
If you want to add a B each time an A is added, use the inc() operator.
More on the Logical Equivalence Operator
As a top level constraint, the logical-equivalence operator (eqv()) creates a mutually-requires relationship between its operands. The operands can be either items or sub-expressions. For example eqv([A], [B]) means than if item A is in the solution, then at least one item B must be in the solution. Also, if item B is in the solution, then at least one item A must be in the solution. Note that the relationship between [A] and [B] is noncumulative. (Use the inc() operator to create cumulative-requires relationships.)
For example, the following constraint states that if the quantity of [A]>2, then [B] is required.
eqv(>([A],2),[B])
This expression constrains the solution as follows:
If there are more than two A's in the solution, there must be at least one B.
If there cannot be any B's in the solution, there cannot be any more than two A's.
If B is in the solution, there must be more than two A's.
If A is limited to two or less, B is excluded.
More on the Excludes Operator
As a top-level constraint, the excludes operator (excl(A, B)) creates a mutually exclusive relationship. The expression excl([A], [B]) means that if item A is in the solution, item B cannot be in the solution. It also means that if item B is in the solution, item A cannot be in the solution.
The exclude constraint can also be used with sub-expressions. For example, the following constraint excludes item B when item A's quantity is greater than 2. It also prevents item A from being greater than 2 when item B is in the solution.
excl(>([A],2),[B])
Multiple Operands for Require and Exclude Operators
You can use multiple operands in requires and exclude constraints. For example, you could write the following constraint:
excl([A],[B],[C])
This syntax is interpreted by the Siebel Product Configurator engine as if you had written two constraints:
excl([A],[B])
excl([A],[C])
In other words, [A] excludes both [B] and [C]. Note that [A] is the first operand in both the constraints. Siebel Product Configurator takes the first operand and creates expressions between it and each remaining operands.
This works the same way for require constraints:
req([A],[B],[C])
This syntax is interpreted by the Siebel Product Configurator engine as if you had written two constraints:
req([A],[B])
req([A],[C])
In other words, [A] requires both [B] and [C]. There is no limitation on the number of operands you can use in this type of expression.
Comparison and Pattern Matching Operators in Rule Assembly Language
Comparison operators expect numeric operands. This means when you specify an item or arithmetic expression, the Siebel Product Configurator engine uses the quantity of the item or the value of the expression. These operators produce a logical result. This means the operator evaluates and compares the quantities of the operands and returns a true or false result.
The greater-than operator (>) is an example. The Siebel Product Configurator engine interprets the following top-level constraint to mean the quantity of item A must be larger than the quantity of item B in the solution. The Siebel Product Configurator engine enforces this constraint by adjusting the quantity of A or B as needed to make sure that the constraint is always true.
>([A],[B])
When used as sub-expressions, comparison operators return true or false. For example, if the quantity of item A in the solution is not greater than the quantity of item B, the previous example returns false. This is then acted on by the associated top-level expression.
Pattern matching operators compare two strings. You can test whether the strings are a match or a mismatch. Pattern matching operators return true or false.
Comparison operators are shown in the following.
Table Comparison and Pattern Matching Operators
| Operator | Syntax | Properties |
|---|---|---|
Greater than |
>(A, B) |
A and B can be items or sub-expressions. |
Not less than |
>=(A, B) |
A and B can be items or sub-expressions. |
Equals |
==(A, B) |
A and B can be items or sub-expressions. |
Not equal to |
!=(A, B) |
A and B can be items or sub-expressions. |
Not greater than |
<=(A, B) |
A and B can be items or sub-expressions. |
Less than |
<(A, B) |
A and B can be items or sub-expressions. |
Selected |
sel(A) |
Returns true if A is positive, false if A is not. Same as >(A, 0). If used as top-level expression, means that A must be in the solution in any quantity. A can be an item or sub-expression. |
Multiple Operands for Comparison Operators
You can use multiple operands in constraints containing comparison operators. For example, you could write the following constraint:
>([A],[B],[C])
This syntax is interpreted by the Siebel Product Configurator engine as if you had written two constraints:
>([A],[B])
>([A],[C])
Note that [A] is the first operand in both the constraints. Siebel Product Configurator takes the first operand and creates expressions between it and each remaining operands. There are no limitations on the number of operands you can use in this type of expression.
Note that the expression are interpreted by the Siebel Product Configurator engine as pairs that always include the first operand. This type of expression does not create implied constraints between other operands. For example, you write the following constraint:
!=([A],[B],[C])
This constraint expression is interpreted as A !=B and A!=C. It does not imply that B !=C.
Arithmetic Operators in Rule Assembly Language
Arithmetic operators expect numeric operands and produce a numeric result. They are most frequently used in sub-expressions. The following top-level expression means that the quantity of item C in the solution must be the same as the sum of the quantities of items A and B.
==(+([A],[B]),[C])
Assuming no other constraints on item A, B, or C; if you add A or B to the solution, then C will be added as well to match the sum. If you add a large number of C's, the Siebel Product Configurator engine will add A and B in arbitrary quantities so that their sum equals the amount of C.
When used in sub-expressions, these operators must return a numeric result. If a sub-expression returns a logical result, true is interpreted as a 1, and false is interpreted as a 0. In the example above, if B is an expression that returns the logical result true, then the expression is equivalent to the following:
==(+([A],1),[C])
Arithmetic operators are shown in the following.
Table Arithmetic Operators
| Operator | Syntax | Properties |
|---|---|---|
Addition |
+(A, B) |
Sum of A and B. A and B can be items or sub-expressions. Result is floating point if A or B is floating point. |
Subtraction |
-(A, B) |
Subtracts B from A. A and B can be items or sub-expressions. Result is floating point if A or B is floating point. |
Negation |
-(A) |
Additive inverse of A. Uses only one operand. A can be an item or expression. |
Multiplication |
*(A, B) |
Product of A and B. Result is floating point if A or B is floating point. A and B can be items or sub-expressions. |
Division |
/(A, B) |
Quotient of A divided by B. Truncates ratio to integer if both A and B are integers. Result is floating point if A or B is floating point. A and B can be items or sub-expressions. |
Modulo |
%(A, B) |
Remainder of A divided by B. For example, %(1900, 72) results in 28. If A or B is floating point, the value is first rounded to the nearest integer; then the remainder is computed as for integers. A and B can be items or sub-expressions. |
Minimum |
min(A, B) |
Result is the smaller of A and B and is floating point if A or B is floating point. A and B can be items or sub-expressions. |
Maximum |
max(A, B) |
Result is the larger of A and B and is floating point if A or B is floating point. A and B can be items or sub-expressions. |
The following operators, shown in the following table, also take numeric arguments and produce numeric results. Use them to control numeric accuracy or change numeric characteristics.
Table Additional Arithmetic Operators
| Operator | Syntax | Properties |
|---|---|---|
Quantity |
qty(A) |
Result is the quantity of A rounded to nearest integer. For example, if A is 6.7, returns 7. If A is 6.3, returns 6. A can be an item or sub-expression. Useful only with resources. |
Integer |
int(A) |
Truncates A down to an integer. For example, if operand is 6.7, returns 6. A can be an item or sub-expression. |
Float |
flo(A) |
Converts A to floating point. Same as multiplying operand by 1.0. A can be a sub-expression. Not useful with resources. |
Absolute value |
abs(A) |
Returns the absolute value of A. A can be an item or sub-expression. |
Sign test |
sgn(A) |
Returns -1 if the quantity of A <0, 0 if A=0, 1 if A>0. A can be a sub-expression. |
Attribute Operators in Rule Assembly Language
Rule Assembly Language includes special operators for doing comparisons and particular math operations on attribute values. These operators extract information about the attributes of all the products that have been selected in a relationship. For example, you can determine the number of relationship items that have been selected that have an attribute value greater than a specified amount.
Attribute Comparison Operators
These operators return the number of relationship items that have been selected for which the comparison is true. For example, you can use numAttr> to find out how many items with Length greater than 5 feet in a relationship have been selected.
The operators count all the items selected from the relationship, not the number of different items. In the preceding example, if the user selects two of the same item and enters a length greater than 5 feet, the numAttr> operator will return 2.
The operators take two arguments, A and B. Argument A is the full path from the root of the product to the attribute. Argument B is the comparison value. This value can be of type Integer, Number, Date, or Time. Type DateTime is not supported. Argument B can also be a sub-expression that resolves to one of these data types.
In addition, for the numAttr== and numAttr!= operators, argument B can be a text string.
Use attribute comparison operators to create subexpressions that form conditions. Attribute comparison operators are shown in the following.
Table Attribute Comparison Operators
| Operator | Syntax | Properties |
|---|---|---|
Greater than |
numAttr>(A, B) |
Returns the number of items in the relationship for which the value of attribute A is greater than B. |
Not less than |
numAttr>=(A, B) |
Returns the number of items in the relationship for which the value of attribute A is greater than or equal to B. |
Equals |
numAttr==(A, B) |
Returns the number of items in the relationship for which the value of attribute A is equal to B. |
Not equal to |
numAttr!=(A, B) |
Returns the number of items in the relationship for which the value of attribute A is not equal to B. |
Not greater than |
numAttr<=(A, B) |
Returns the number of items in the relationship for which the value of attribute A is less than or equal to B. |
Less than |
numAttr<(A, B) |
Returns the number of items in the relationship for which the value of attribute A is less than or equal to B. |
You can use the numAttr operators to create "any/all" conditions in constraints involving attributes:
You create the condition "any instance of products in R has attribute A=X" as follows:
>=(numAttr==(@.[R].[A], X), 1)
You create the condition "all instances of products in R have attribute A=X" as follows:
==(numAttr==(@.[R].[A], X), @.[R])
For example, you want to write the constraint, when all the instances of products in P have attribute A=X then exclude any instance of products in Q that have attribute B =Y. You would write this constraint as follows:
excl(==(numAttr==(@.[P].[A], X), @[P]),
>=(numAttr(==(@.[Q].[B], Y), 1)))
Attribute Arithmetic Operators
The arithmetic operators allow you to determine the maximum and minimum value of an attribute for items that have been selected in a relationship. You can also sum the values of the attributes.
The operators take one argument, which is the path to the attribute. Attributes can be of type Number, Integer, Date, or Time. DateTime and Text are not supported. If the type is Date or Time, minAttr returns the time or date closest to the present. The maxAttr operator, returns the time or date furthest from the present.
Use attribute arithmetic operators to create subexpressions that form conditions. Attribute arithmetic operators are shown in the following.
Table Attribute Arithmetic Operators
| Operator | Syntax | Properties |
|---|---|---|
Minimum |
minAttr(A) |
For items selected from a relationship, returns the smallest value for attribute A. |
Maximum |
maxAttr(A) |
For items selected from a relationship, returns the largest value for attribute A. |
Sum |
sumAttr(A) |
Returns the sum of attribute A for all items selected from a relationship. |
Conditional Operators in Rule Assembly Language
Conditional logic operators are shown in the following.
Table Conditional Operators
| Operator | Syntax | Properties |
|---|---|---|
Logical conditional |
if (A, B, C) |
If A then B, else C. If C is not specified, it defaults to true (1). |
Numeric conditional |
?(A, B, C) |
If A then B, else C. If C is not specified, it defaults to false (0). This means the expression returns false if A is false and C is not specified. Rarely used. |
Special Operators in Rule Assembly Language
Special operators provide functions that manipulate the Siebel Product Configurator 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 constraints. It has two important characteristics:
It returns a null value.
When it is evaluated in a subexpression, this causes the Siebel Product Configurator engine to contribute the value requested.
This means that writing constraints 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 constraint.
req(X, inc(Y, Z))
The Siebel Product Configurator engine will contribute the value of Y to Z, regardless of whether X is present in the solution. This is because the Siebel Product Configurator 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 constraint meaningless.
To write constraints that contribute conditionally, use the numeric conditional operator, ?().
Special operators are shown in the following.
Table 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 |
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 constraint type or with any user selections. The priority determines the order in which multiple preference constraints for an item are evaluated. Preference constraints 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 constraint. 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 pick applet in the Assisted Advanced Constraint 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 constraints. 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 constraint. |
More on withTuples
The withTuples operator lets you provide more than one set of operands to a constraint. It has the following syntax:
withTuples (((A, B, C),(D,E F),...), ruleA(%1,%2,%3,...),...)
For example, you have the following two constraints:
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 previous two constraints can be considered one required constraint that has two sets of operands. The withTuples operator lets you write the constraint in this fashion. This makes constraint maintenance easier. If the operands change, you can edit them in one location, rather than having to locate all the constraints in which they appear. Here is one way to combine the two constraints 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 constraints. For example, you have the following two constraints:
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.
These two constraints are different but they make use of the same operands. You could use the withTuples operator to show that these two constraints 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 constraint from the root of the customizable product to a specified location within the product. This means the constraint 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 constraint CPU requires Hard Drive and enforce the constraint 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 constraint as follows:
withMembers(@.Relationship A, req(@.CPU, @.Hard Drive))
This constraint 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 constraint is not enforced for PCs that appear elsewhere in the customizable product other than Relationship A.
Customizable Product Access Operators in Rule Assembly Language
Customizable Product access operators, shown in the following table, allow you to obtain information about other areas of the customizable product. For example, you can obtain the name of an item's parent.
Table Customizable Product Access Operators
| Operator | Syntax | Properties |
|---|---|---|
Product root |
root() |
Result is root of the customizable product. Takes no arguments. |
Examples of Constraints Using Rule Assembly Language
This topic contains examples of how to use the Siebel Product Configurator Rule Assembly Language to create constraints. Some of the constraints show item names consisting of both the product name and its configuration ID (Cfg ID).
Basic Constraints
The following table shows how create basic constraints using Rule Assembly Language.
| Constraint Type | Advanced Rule Language |
|---|---|
A requires B noncumulatively |
req(A, B) |
A requires B cumulatively |
inc(A,B) |
A excludes B |
excl(A,B) |
A provides the amount B to C |
inc(*(A,B),C) |
A consumes the amount B from C |
inc(*(A,-(B)),C) |
A's minimum quantity is B, enforced |
>=(A,B) |
A's maximum quantity is B, enforced |
<=(A,B) |
A recommends B |
rec(req(A,B)) |
Boolean and Comparison Operators
The following table shows how to create constraints using Boolean and comparison operators.
| Constraint Type | Advanced Rule Language |
|---|---|
A AND B =C |
==(and(A,B),C) |
A OR B = C |
==(or(A,B),C) |
NOT (A = B) |
xor(A,B) |
(A < B) requires C |
req(<(A,B),C) |
(A <= B) requires C |
req(<=(A,B),C) |
(A = B) requires C |
req(==(A,B),C) |
(A != B) requires C |
req(!=(A,B),C) |
(A >=B) requires C |
req(>=(A,B),C) |
(A >B) requires C |
req(>(A,B),C) |
(A + B) contributes to C |
inc(+(A,B),C) |
(A - B) contributes to C |
inc(-(A,B),C) |
(A * B) contributes to C |
inc(*(A,B),C) |
(A/B) contributes to C |
inc(/(A,B),C) |
(A MIN B) contributes to C |
inc(min(A,B),C) |
(A MAX B) contributes to C |
inc(max(A,B),C) |
Constraint Template Translations
The following table shows examples of the constraint templates translated into Rule Assembly Language.
Table Constraint Template Translations to Rule Assembly Language
| Template | RAL Equivalent | Explanation |
|---|---|---|
Constrain |
con(>(Item A),1)) |
Constrain (quantity of Item A> 1) to be true. |
Constrain Conditionally |
if(>(Item A), 1), >= (Item B), 2), excl(Item C, Item D)) |
When (quantity of Item A> 1)(quantity of Item B >= 2), otherwise Selection of Item C excludes selection of Item D. |
Constrain Product Quantity |
==(Item A, 2) |
The quantity of Item A = 2. |
Consume |
inc(*(Item A), -(1)), Resource B) |
Each Item A consumes 1 from Resource B. |
Exclude |
excl(Item A, Item B) |
Selection of Item A excludes selection of Item B. |
Exclude List |
excl(Item A, Item B, Item C)) |
Item A excludes (selection of Item B, selection of Item C). |
Message |
msg(>(Item A, 1)) |
When (Item A > 1), display this constraint's description. |
Preference |
prefer(Item A, 1) |
When possible, constrain Item A is selected to be true with a priority of 1. |
Provide |
inc(*(Item A), 1), Resource B) |
Each Item A provides 1 to Resource B. |
Recommends |
chk(req(Item A, Item B), "Item B is recommended") |
Selection of Item A recommends selection of at least one Item B by displaying "Item B is recommended". |
Requires |
req(Item A, Item B) |
Item A requires Item B. |
Requires (Mutual) |
eqv(Item A, Item B) |
Item A requires Item B AND Item B requires Item A. |
Constrain Attribute Value |
==(@.[Class A] ([Item B]).[Day], "Monday") |
The attribute Class A "Item B" Attribute C = Monday. |