Expression constraints and table constraints in product configuration models
This topic describes the use of expression constraints and table constraints. Constraints control the attribute values that you can select when you configure products for a sales order, sales quotation, purchase order, or production order. You can use expression constraints or table constraints, depending on how you prefer to build the constraints.
Constraints are used to control the attribute values that you can select when you configure products for a sales order, sales quotation, purchase order, or production order. You can use expression constraints or table constraints, depending on how you prefer to build the constraints.
What are expression constraints?
Expression constraints are characterized by an expression that uses arithmetic and Boolean operators and functions. An expression constraint is written for a specific component in a product configuration model. It can't be reused by or shared with another component. However, the expression constraints for a component can reference attributes of the component's subcomponents.
What are table constraints?
Table constraints list the combinations of values that are allowed for attributes when you configure a product. Table constraint definitions can be used generically. When you create a table constraint for a component in a product configuration model, you select a table constraint definition. To create the combinations that are allowed, you add attributes of specific types to the components. Each attribute type has a specific value.
Example of a table constraint
This example shows how you can limit the configuration of a speaker to specific cabinet finishes and fronts. The first table shows the cabinet finishes and fronts that are generally available for configuration. The values are defined for the Cabinet finish and Front grill attribute types.
Attribute type  Values 

Cabinet finish  Black, Oak, Rosewood, White 
Front grill  Black, Metal, White 
The next table shows the combinations that are defined by the Color and finish table constraint. By using this table constraint, you can configure a speaker that has an oak finish and a black grill, a Rosewood finish and a white grill, and so on.
Finish  Grill 

Oak  Black 
Rosewood  White 
White  Black 
White  White 
Black  Black 
Black  Metal 
You can create systemdefined and userdefined table constraints. For more information, see Systemdefined and userdefined table constraints.
What syntax should be used to write constraints?
You must use Optimization Modeling Language (OML) syntax when you write constraints. The system uses Microsoft Solver Foundation constraint solver to solve the constraints.
Should I use table constraints or expression constraints?
You can use either expression constraints or table constraints, depending on how you prefer to build the constraints. You build a table constraint as a matrix, whereas an expression constraint is an individual statement. When you configure a product, it doesn't matter what kind of constraint is used. The following example shows how the two methods differ.
When you configure a product by using the following constraint setups, these combinations are allowed:
 A product in the color Black, and in size 30 or 50
 A product in the color Red and in size 20
Table constraint setup
Color  Size 

Black  30 
Black  50 
Red  20 
Expression constraint setup
(Color == "Black" & (size == "30"  size == "50"))  (color == "Red" & size = "20")
Should I use operators or infix notation when I write expression constraints?
You can write an expression constraint by using either the available prefix operators or infix notation. For the Min, Max, and Abs operators, you can't use infix notation. These operators are included as standard operators in most programming languages.
What operators and infix notation can I use when I write expression constraints?
The following tables list the operators and infix notation that you can use when you write an expression constraint for a component in a product configuration model. The examples in the first table show how to write an expression by using either infix notation or operators.
Operator  Description  Syntax  Examples 

Implies  This is true if the first condition is false, the second condition is true, or both.  Implies[a, b], infix: a : b 

And  This is true only if all conditions are true. If the number of conditions is 0 (zero), it produces True.  And[args], infix: a & b & ... & z 

Or  This is true if any condition is true. If the number of conditions is 0 (zero), it produces False.  Or[args], infix: a  b  ...  z 

Plus  This sums its conditions. If the number of conditions is 0 (zero), it produces 0.  Plus[args], infix: a + b + ... + z 

Minus  This negates its argument. It must have exactly one condition.  Minus[expr], infix: expr 

Abs  This takes the absolute value of its condition. It must have exactly one condition.  Abs[expr]  Operator: Abs[x] 
Times  This takes the product of its conditions. If the number of conditions is 0 (zero), it produces 1.  Times[args], infix: a * b * ... * z 

Power  This takes an exponential. It applies exponentiation from right to left. (In other words, it's rightassociative.) Therefore, Power[a, b, c] is equivalent to Power[a, Power[b, c]]. Power can be used only if the exponent is a positive constant.  Power[args], infix: a ^ b ^ ... ^ z 

Max  This produces the largest condition. If the number of conditions is 0 (zero), it produces Infinity.  Max[args]  Operator: Max[x, y, 2] == z 
Min  This produces the smallest condition. If the number of conditions is 0 (zero), it produces Infinity.  Min[args]  Operator: Min[x, y, 2] == z 
Not  This produces the logical inverse of its condition. It must have exactly one condition.  Not[expr], infix: !expr 

The examples in the next table show how to write infix notation.
Infix notation  Description 

x + y + z  Addition 
x * y * z  Multiplication 
x  y  Binary subtraction is translated the same as binary addition where there is a negated second. 
x ^ y ^ z  Exponentiation that has right associativity 
!x  Boolean not 
x : y  Boolean implication 
x  y 
x & y & z  Boolean and 
x == y == z  Equality 
x != y != z  Distinct 
x < y < z  Less than 
x > y > z  Greater than 
x <= y <= z  Less than or equal to 
x >= y >= z  Greater than or equal to 
(x)  Parentheses override default precedence. 
Why aren't my expression constraints validated correctly?
You can't use reserved keywords as solver names for attributes, components, or subcomponents in a product configuration model. Here is a list of the reserved keywords that you can't use:
 Ceiling
 Element
 Equal
 Floor
 If
 Less
 Greater
 Implies
 Log
 Max
 Min
 Minus
 Plus
 Power
 Times
 Slot
 Model
 Decision
 Goal
See also
[Create an expression constraint (Task guide)(tasks/addexpressionconstraintproductconfigurationmodel.md)
Add a calculation to a product configuration model (Task guide)