Author: Dennis

In this blog I’ll explain the concept of table constraints as it is implemented in Constraint-based product configuration in Microsoft Dynamics AX 2012.

 

Definition

A table constraint lets you specify the valid combinations of attribute values that can be assigned when configuring a product configuration model. The structure of a table constraint consists of one or more columns and one or more rows. Each column is assigned to an attribute type that specifies the attribute values that can be combined in the rows. Each row defines a valid combination of the attribute values for the attribute type.

 

Constraint based product configuration for Microsoft Dynamics AX 2012 supports two types of table constraints:

 

• User-defined – You can manually specify the combinations of attribute values that are valid for the product configuration model.
• System-defined – You can specify the table in the Application Object Tree (AOT) that will define the combinations of attribute values that are valid for the product configuration model.

 

Example

The following example shows a table constraint that could be used for a television. The table constraint is described as an expression and as a table. The expression describes the attribute types and values for Color, Size, and IsLCD. The table constraint contains three columns with the valid combinations of the attribute values for each attribute type.

 

Attributes types and values written as an expression

 

IsLCD : { True, False }      

 

Color : { “Red”, “Green”, “Blue”, “Black” }     

 

Size : [ 42 .. 55 ]   

 

Table constraint

 

The Color, Size and IsLCD attribute types serve as the column headings in the table constraint definition. The rows specify the valid combinations of attribute values.

 

Column_Color = Color

 

Column_Size = Size

 

Column_IsLCD = IsLCD

 

Column_Color	Column_Size	Column_IsLCD
Red	42	True
Red	55	True
Green	42	True
Blue	55	False

Written as a Boolean expression, the table would look as follows: 

 

(Color == “Red” And Size == 42 And IsLCD == True )

Or

(Color == “Red” And Size == 55 And IsLCD == True )

Or

(Color == “Green” And Size == 42 And IsLCD == True )

Or

(Color == “Blue” And Size == 55 And IsLCD == False )

 

There are some important things to note about the attribute types that are used in the example:

 

• Color:  This attribute type includes the attribute value “Black.” However, because Black is not specified in a row it cannot be assigned. In a case like this, consider whether the table constraint or attribute type are incorrect. The two rows for the attribute value “Red” implies that if Red is assigned then Size can either be 42 or 55. This also means that the IsLCD attribute is always True because the values for Red and IsLCD is True are not combined in a row.
• Size:  Although the attribute type is defined as an integer with an interval from 42 to 55, only the values 42 and 55 are valid attribute values because these are the only values within the interval for which a row is defined.
• IsLCD:  If False is assigned to an attribute value that is included in the IsLCD column, then only “Blue” and 55 are valid assignments for the respective attribute values that are included in the Color and Size columns.

 

The difference between System and User defined table constraints

Although the same rules apply to both system-defined and user-defined table constraints, there are some differences in behavior. In this section I’ll elaborate on the key differences, but focus primarily on system defined table constraints.

 

User defined

User defined table constraints let you manually define the combinations of attribute values that you want to allow for a product configuration model. In Figure 1, the Table fields and Allowed combinations FastTabs of the Edit table constraint form show an example how attribute types and values are combined in a user defined table constraint.

 

Figure 1

System defined

For system defined table constraints, you select a table or view which is defined in the AOT. You then specify the relation between the columns of the table constraint and the fields that are included in the table or view in the AOT. This table or view provides the value combinations for the table constraint. You can also add a filter on the AOT table or view by adding a database query that selects rows by adding ranges to query.

 

One important thing to know about system defined table constraint is that at runtime the system changes the type definition of any attribute that is associated with a column. For example, the value for an enumerated text attribute will be replaced with the set of distinct values for the column in the AOT table. For an integer-based attribute, the ranges will be replaced with the maximum and minimum values for the column.

 

 

Figure 2

Example

The InventTable table in Microsoft Dynamics AX 2012 contains the following data in the AltItemId and BOMLevel fields.

 

AltItemId	BOMLevel
LCD_42	3
Plasma_55	1
LCD_55	7

 

In order to use the InventTable as the source of a system defined table constraint for a component in a product configuration model, the following must be set up:

 

• Two attribute types, one of the type Text and another of the type Integer. The Text attribute type must have at least one value. The Integer attribute type must have a value range.
• A table constraint definition, as illustrated in Figure 2. The table constraint that will reference the definition must be created for a component. The component must have attributes that match the attribute types that are referenced by the columns of the table constraint definition.

 

For a component that uses a system defined table constraint, the system replaces the following values:

• For the attribute type of the attribute that is matched to the AltItemId column, the values are replaced with { “LCD_42”, “Plasma_55”, “LCD_55” }.
• For the attribute type of the attribute that is matched to the BOMLevel, the range is replaced with [ 1 .. 7 ].