|Bookshelf Home | Contents | Index | PDF|
Unlike procedural languages like Siebel eScript or C++, the rules you create in the Rule Designer 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 rules, called constraints, that describe what must be true about the solution. The eConfigurator engine organizes these rules 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 rules that define all the ways a desktop computer can be configured. This is called the declarative portion of the customizable product, and the rules are constraints on every solution. The eConfigurator 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 eConfigurator 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 eConfigurator engine must find a configuration that satisfies all the rules (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 eConfigurator engine searches until it finds a solution that satisfies all the constraints, including the constraint created by the user's action. The eConfigurator 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 eConfigurator 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 rules 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 eConfigurator 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:
If the user picks one A, the eConfigurator 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 eConfigurator 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 rules must be satisfied, and because there is no constraint preventing the eConfigurator engine from generating solutions that increment B by more than one.
The following example illustrates that when there are several possible alternatives, the eConfigurator engine may choose any one of them. You have a customizable product with only the following two constraints on items A, B, and C:
In this example, either A or B can be zero, but not both. Neither can both be 1. The eConfigurator 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 rules in the Rule Designer, 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 rule that prints a message to the user that A + B must equal 1 and then let the user choose which one they want.
|Product Administration Guide|