Product Administration Guide > Configuration Constraint Template Reference >

About Configuration Constraint Processing

Unlike procedural languages like Siebel eScript or C++, constraints are elements of constraint programming. Constraint programming differs from procedural logic in several important ways.

In a procedural language, you write statements that are executed one after another. Control can be transferred to other parts of a program, but the method of execution remains serial. Procedural logic relies on groups of statements executed in order.

In constraint logic, you write constraints that describe what must be true about the solution. The Siebel Configurator engine organizes these constraints into a search plan and then searches systematically, trying different item values, until a solution that satisfies all the constraints is found. Constraints are evaluated in parallel rather than serial fashion. Their order of evaluation is unimportant.

For example, you write a series of configuration constraints that define all the ways a desktop computer can be configured. This is called the declarative portion of the customizable product, and the constraints are constraints on every solution. The Siebel Configurator engine requires that all constraints are observed in every solution. This is the key to understanding constraint programming: all constraints must be observed in every solution.

You then release this customizable product to users. Users interact with it by selecting components to configure a computer. Each item the user selects is treated by the Siebel Configurator engine as another constraint on the solution. These user-constraints are added to the constraints in the declarative portion of the product and are used to further narrow down the solutions the engine can create. If a user-constraint conflicts with a constraint in the declarative portion of the product, the user receives a message that provides options for resolving the conflict.

The Siebel Configurator engine must find a configuration that satisfies all the constraints in the declarative portion of the product, plus all those created by the user's choices (user-constraints). After the user adds or removes an item, the Siebel Configurator engine searches until it finds a solution that satisfies all the constraints, including the constraint created by the user's action. The Siebel Configurator engine then presents the solution. In many cases, the only thing that changes is that the item is added or removed.

However, other items may be added or removed depending on constraints in the declarative portion of the product. If the user selects an item and the Siebel Configurator engine cannot create a solution that satisfies all the constraints, the user is presented with an option to undo the current selection or previous selections so that all constraints can be satisfied.

Note that constraints are created both by the modeler and by the user. In the declarative portion of the product, the product administrator writes configuration constraints that define the relationships between items. For example, if item A is picked, item B is required. The user creates constraints by adding items. For example, picking item A creates a constraint that item A must be in the solution. The constraints that drive the solution are thus jointly provided by both the product administrator and the user.

It is important to understand that to produce a solution, the Siebel Configurator engine is free to do what is necessary to find a valid solution that satisfies all the constraints (declarative portion constraints and user-constraints). For example, the following are the only two constraints on items A and B in a customizable product:

The quantity of A < the quantity of B

The quantity of B != 4

If the user picks one A, the Siebel Configurator engine will require that there are at least two Bs in the solution. If the user then increases the quantity of A to two, the Siebel Configurator engine generates a solution in which there are at least three Bs. However, when the user adds the third A, instead of a solution that increases B by one, the new solution will have two more Bs, making the total number of Bs at least five. This occurs because both constraints must be satisfied, and because there is no constraint preventing the Siebel Configurator engine from generating solutions that increment B by more than one.

The following example illustrates that when there are several possible alternatives, the Siebel Configurator engine may choose any one of them. You have a customizable product with only the following two constraints on items A, B, and C:

Constrain A + B = C to be true
Constrain C = 1 to be true

In this example, either A or B can be zero, but not both. Neither can both be 1. The Siebel Configurator engine will choose either A or B and will actively exclude the other from the solution. For example, it could choose A and actively exclude B from the solution. It could also choose B and actively exclude A.

It is important when creating constraints to consider the domain of solutions the engine could produce. Otherwise, users may encounter unexpected results when they make selections. In the example above, you could write a constraint that prints a message to the user that A + B must equal 1 and then let users choose which one they want.