Product Administration Guide > Configuration Rule Template Reference >

About Constraints

The restrictions that define allowable configurations are called constraints. Constraints can take several forms:

• Picking one item requires that another item also be included.
• Picking one item excludes being able to pick another specific item.
• Picking an item from a group is mandatory.
• An item is available to be picked only after a certain date, or only if the user is a certain account.
• Picking an item consumes a configuration-related resource such as the total available slots in a chassis. Picking an item could also provide something to a resource.
• An item is required or excluded based on a defined condition.

Attribute definitions, cardinality, interface design, and configuration rules are the methods you use to create the configuration constraints that enforce business rules and logic.

You test these constraints by going to validation mode. In validation mode, you configure the product as if you were the end user. This lets you verify that the user interface works correctly and that all constraints are functioning properly.

Attribute Definitions

Attributes define the options for an individual component. For example, a component has the attribute Color. The Color attribute defines the set of colors that a user can choose for the component.

Attributes are defined at the class level in the class system and are inherited by all products assigned to the class. This means you can define and manage attributes for large groups of products and components from a single location. You do not have to define these options for each product or component individually.

Cardinality

You add components to a customizable product by defining relationships. A relationship can contain a single component, all or part of a product class, or a group of products from several classes.

When you define a relationship, you can specify a minimum, maximum, and default cardinality. The cardinality defines whether or not the user is required to select items and also how many items they can select.

• Minimum cardinality. Setting the minimum cardinality to greater than 0 means the user is required to make a selection from this relationship. This creates a "required selection." Setting the minimum cardinality to 0 means the user is not required to make a selection.
• Maximum cardinality. Setting the maximum cardinality constrains the quantity the user can select from the relationship. This creates a "maximum allowable selection." Setting the maximum cardinality to blank, means that the user can select an unlimited number of items from the relationship.
• Default cardinality. The default cardinality defines how many items from the relationship will be added by default to the configuration when the user first starts the configuration session. Depending on the settings for minimum and maximum cardinality, the user can remove the items or add more.

Cardinality is defined at the relationship level and applies to the relationship as a whole. It constrains the quantity of items you can select from a relationship. If the relationship contains one item, cardinality constrains the selection of that item. If the relationship contains a group of items, cardinality applies to selection of these items in any combination.

Upgrade users. Defining the cardinality of a relationship in this release is roughly equivalent to writing an enforced quantity rule on a category in previous releases.

User Interface Design

The way you define groups and choose controls for them in the Product UI Designer can create implicit constraints that control item selection. For example, choosing a radio button control for a group constrains the user to choosing only one item from the group, even if maximum cardinality for the relationship is blank. In other words, using a radio button control creates an implicit constraint: picking one item excludes all the others in the group.

By creating groups in the Product UI designer that contain more than one relationship, you can create more complex implicit constraints. For example, you have two relationships, A and B, that each contains three components. All of the items in the two relationships are optional (minimum cardinality = 0 for both relationships). The final configuration has the following constraint: if the user picks any item in either relationship, all the remaining items in both relationships are excluded from the final configuration. You can enforce this constraint by assigning a radio button control to this group that allows selection of only one item.

Upgrade users. In this release, you can define the configuration UI with the Product UI Designer. In previous releases, you had to use Siebel Tools to change the layout of Configuration Assistant, and this change applied to all products. If you do not define a configuration UI for a customizable product, the system provides a default configuration UI that displays all the items on one selection page.

Configuration Rules

The Rule Designer provides rule templates that allow you to create a wide variety of configuration rules. These explicit constraints differ from the implicit constraints you can create using attributes, cardinality, and the Product UI Designer in the following ways:

• Configuration rules can be based on conditions that occur during the configuration session. For example, you can write a configuration rule: if condition A is true, then Product B is required.
• Configuration rules can keep track of important consumables in a configuration session. For example, you can create a resource called slots available, and then write rules that increase or decrease slots available depending the items the user picks.
• Configuration rules can be complex. For example you can write rules that contain multiple levels of conditions or contain nested expressions.
• Configuration rules can override implicit constraints created by the physical construction of the user interface. For example, you have specified radio buttons to display the items in a relationship. This allows the user to pick only one item from the relationship. However, you could also write configuration rules that require additional items from the relationship when the user picks items elsewhere in the configuration.
• In the example regarding relationship A and B in the previous section, the user is constrained from selecting more than one item from the two relationships by the physical construction of the user interface. The radio button control allows only one item to be selected from the group. However, you could write a configuration rule that says that for each Component A that is picked, then Component C from Relationship B must be in the configuration. Each time the user picks Component A, the system will automatically add Component C to the configuration.
• Configuration rules can use Siebel data external to the customizable product. You can write rules conditioned on the date, the account that is configuring the product, or on other business component data. You access external data by defining links.

The configuration rules you write in the Rule Designer apply only to the current customizable product and are stored with it. You can also create rule templates. These are stored with the Rule Designer and can be used with any customizable product.

Upgrade users. The Rule Designer in this release replaces the Basic Rules Designer, Logic Designer, and Advanced Rules Designer in previous releases. The Rule Designer uses natural-language rule templates to let you write rules as simple or as complex as needed. You can also write rules in Advanced Rule Language if desired.

Resource Values

The value of a resource must exactly equal the sum of all its contributors (provides and consume rules). If you set a resource to an initial value, or constrain a resource within a range, there must be items in the solution that contribute to the resource. You do this by writing rules that contain contributors to the defined resources.

Be careful when using the equals operator [=] with these templates. It can cause unexpected results. For example, you write the rule:

Resource R = 10

In addition, the only contributor to Resource R is Product P, which has the following rule:

Product P provides 2 to Resource R

The eConfigurator engine will return a solution that contains 5 Product P. This is because Resource R must equal 10, and the only way to achieve this is to add enough contributors (Product P) to make this true.

If you had set Resource R to 11, instead of 10, you would receive a validation error. This is because there is no way to add enough Product P to make Resource R exactly equal to 10.