Understanding Modeling

This chapter discusses:

• Basic model concepts.

• Relationships between objects

• Relationship properties.

• Expressions in relationships.

• Default values within expressions.

• Quantities in Modeling.

• Creating parameterized explanations.

• Optimizing performance and minimizing model maintenance

• Using the sample models.

• The modeling process.

• Model Tester.

• Interfacing with third-party tools.

Basic Model Concepts

The PeopleSoft Visual Modeler is a graphical hierarchical modeling tool for designing complex configuration solutions. You use it to create a model of a product or a service that then serves as the “blueprint” for specifying actual instances of the product or service that are customized to a customer's needs.

Advanced Configurator models represent products and services using three concepts:

• The hierarchy—a logical structure that identifies and organizes its components.

• Relationships—how the components relate to each another and interact.

• Components—a product's parts are represented by classes, attributes, domain members, and selection points.

Visual Modeler

Advanced Configurator technology supports configuration modeling and runtime configuration processing.

Using the concepts of hierarchy, components, and relationships, Visual Modeler allows you to describe even complex products and services:

• Uses a multi-paned window to simplify model navigation and the creation of classes, attributes, and relationships.

• Uses a “no programming” paradigm.

  All modeling is accomplished through drag-and-drop operations and table selections.

• Integrates easily with existing customer data.

• Provides support for team development.

• Separates the UI design from the product modeling problem.

  Modelers don’t need to create a UI in order to test their model logic.

Model data can be defined in the model (internal data), or obtained from a relational database.

The Configurator engine uses a compiled version of the Visual Modeler model to process user picks, ensuring a valid configuration at runtime.

In this document, a general reference to the Advanced Configurator includes both design-time and runtime components.

You can use Visual Modeler stand-alone or with the Advanced Configurator engine. The Visual Modeler interface uses common hierarchical concepts:

• A model is built from objects. An object is a functional component such as a class, attribute, relationship, or domain member.

• A class is a group or category of like things; for example, products or services.

  A class defines common attributes such as color, weight, power requirements, or price.

• A class hierarchy applies a hierarchical organization to a group of classes.

  Attributes are defined on a class. A new class that inherits attributes from an existing “ancestor” class is a “subclass” or “child.” The nearest ancestor class is referred to as the “parent.”

• A class member, or “domain member” is an instance of a class that assigns specific values to class attributes.

• A relationship, such as compatibility or incompatibility, can be defined between classes or class attributes, and between selection points.

Visual Modeler Objects

Visual Modeler employs standard object-oriented principles for class and inheritance. A model includes an automatically generated Root class, and any classes, subclasses, domain members, and relationships that you define. Inheritance moves from left to right, such that child classes and domain members inherit attributes from parent classes. Hierarchical modeling makes a large configuration task more approachable. Classes can be grouped in meaningful ways, and inheritance capabilities can greatly reduce the work of explicit value assignment.

The compiled model provides basic configuration functionality. To visually organize the display of controls at run time, use DreamWeaver with the Advanced Configurator Extensions. Using DreamWeaver reduces the need to hand-code JSP pages. Model functionality can be further extended with custom Java code that manipulates the controls and options displayed at run time.

Object Properties and Attributes

All Visual Modeler objects (classes, domain members, or relationships) have properties, also referred to as system properties. Classes can have both properties and attributes.

• Properties are part of the object definition and cannot be removed.

  For example, classes, domain members, and relationships all have a Name property. You supply a string to define this property. A property setting is specific to an object.

• Attributes can be thought of as optional user-defined extensions to a class description.

  Attributes can be changed or deleted at any time. Attributes are inherited by subclasses. Domain members assign values to attributes, creating an instance of a class.

Classes and Class Attributes

A class is a group of related objects—items or characteristics a user can order, specify, or require.

• The Root class is a special class defined in every model.

  It behaves like any other class, except it can’t be deleted and can’t have domain members.

• Any number of attributes can be added to a class.

  Attributes can be of type Boolean, Float, Int, String, and Date. User-defined class attributes appear on all subclasses and subsequent domain members.

• Class attributes can be assigned default values only in the class on which they are defined (class attribute values cannot be altered in subclasses).

  An attribute value can be assigned on a domain member instance as well.

• The Internal flag is a class property that determines whether internal domain members will be used, or if domain members will be obtained from a database. A list of class properties follows.

• When external domain members are used, an attribute must exist for each column pulled from the database. This includes the Name. The name defined when the class was created exists internally, so it is not available if the Internal attribute is set to False. (Attribute names should begin with a letter. Attribute names starting with “_” and “$” are reserved for use by the Advanced Configurator system.)

Visual Modeler supplies the following default properties for each class:

You must consider the effect of inheritance principles as you build a model. Click anywhere in the Model Structure View to ensure focus on the modeling area.

See Creating a Class.

Domain Members

A domain member is an instance of a class that describes a particular item, service, or decision. Domain members assign values to class attributes. A class can have either internal or external domain members, but the Internal flag determines the source of the domain members used in the model.

Internal Domain Members

If a domain member is internal, values are assigned as part of the domain member definition. An internal domain member has only one property: its name. A domain member can instantiate attributes from the parent class.

See Creating Internal Domain Members.

External Domain Members

External domain members populate the model based on the SQL Query defined for the class. Values extracted from a database are assigned to a corresponding class attribute. External domain members can be internalized using the menu command Project, Internalize Model. This tool is primarily for use when you need to package a model with its data, such as for transfer and setup at an off-line location for support and testing.

See Setting Up Binding for External Domain Members.

Selection Points

A selection point is an object in the model that will be exposed at run time. A class or a class attribute can become a selection point (sometimes referred to as a decision point). Only selection points shown in the model structure view are available for display at run time.

In addition, a selection point:

• May or may not be visible and selectable at run time.

• May or may not be required to satisfy the runtime completeness check.

By default, a selection point is created for every leaf class that participates in a relationship.

It also participates in all relationships that refer to the original parent class. If a relationship is made directly between a selection point and another object, that relationship is confined to the selection point.

Relationships Between Objects

The relationships you can define between objects in Visual Modeler are:

• Compatibility constraints

• Requirement constraints

• Dynamic defaults

• Resource constraints

• Summation

• Elimination

• Comparison

Compatibility

A non-directional compatibility constraint explicitly identifies all valid combinations and eliminates all other possibilities. Consider the example of an eyeglass product in which Sport frames are compatible with plasticShatterproof lenses. Thus, a pick on either Sport or plasticShatterproof eliminates all other choices. The single remaining choice will be computer-selected if the control is not optional.

Note. Any options not explicitly marked as compatible are assumed to be incompatible. There is no neutral state in a compatibility constraint.

Directional Compatibility

A directional compatibility constraint has a left-hand side (LHS) and a right-hand side (RHS). It identifies compatible combinations, and eliminates all other selections. In the relationship editor, the constraint is expressed in a table with a directional bar separating the LHS arguments from the RHS arguments. The bar indicates that the combined LHS selections are compatible with one of the RHS items; the RHS items are considered separate and unrelated.

• At run time, the constraint can’t eliminate all incompatible items until a pick or a computer selection is made on all but one of the controls. In other words, given N columns in the constraint, the constraint is not “bound” until a user or computer pick is made on N-1 controls. Then the remaining pick is calculated and all incompatible items are eliminated.

• If a RHS object is optional, elimination will occur but a computer selection cannot be made. If the RHS object is required and there is only one valid selection on the RHS, it will be computer-selected.

• Do not use directional compatibility if any RHS object is multi-select. A directional compatibility cannot eliminate items from a multi-select control. Since nothing is eliminated, nothing is computer-selected so the constraint has no effect. If a RHS argument is set to multi-select, you will see the following message at compile time:

  multi-select decision point <nameSelection> in RHS of ​
  directional compatibility⇒
   constraint <constraintName> ​
  will be ignored

The following figure shows and example of relationship dialog settings and the HTML result of a directional compatibility:

Non-Compatibility

A non-compatible constraint enumerates all invalid combinations. If any member of an invalid combination is selected, all members are eliminated. This is true for both single- and multiple-select controls.

• If a control is not optional and only one option remains, that option will be computer-selected.

• Generally, in a non-compatibility constraint, when there are more than two arguments in a constraint (that is, more than two columns in a relationship editor table), the full set of eliminations will not appear unless there is a user pick or a computer-selection for all but one selection. In other words, given N columns in the constraint, the constraint is not “bound” until a user or computer pick is made on N-1 controls. Then the remaining pick is calculated and all incompatible items are eliminated. In some cases, however, it's possible for fewer than N-1 selections to cause eliminations to appear. For example, in a three-column, non-compatibility constraint, if a value from the first column along with a value from the second column are incompatible with every value from the third remaining column (and that column is a required selection), then selecting the value from the first column will eliminate the corresponding value from the second column (since the additional selection of the value from the second column would eliminate all selections for the third column).

Directional Non-Compatibility

A directional, non-compatible constraint evaluates a pick and then eliminates all the incompatible items. In the relationship editor, the constraint is expressed in a table with a directional bar separating the LHS arguments from the RHS arguments. Row by row, the combined LHS selections are incompatible with one of the RHS items. The RHS items are separate and unrelated as shown in the figure.

Because RHS items are unrelated, a directional non-compatibility is equivalent to many constraints. For example, row 3 equates to:

• Caleb and Carol are incompatible with Amigo.

• Caleb and Carol are incompatible with Blazer.

• Caleb and Carol are incompatible with Anteater.

• Caleb and Carol are incompatible with Bird.

Expressions in the Left-Hand Side of the Relationship

Using expressions in the LHS of the relationship lets you to constrain against values that aren't known until run time. Since expressions name variables whose values are input at run time through user- or database input, by using expressions you can describe a condition or set of conditions that result in a desired default selection or quantity on a selection, or both.

For example, a model for financial services product offers differing plans based on the customer's marital status and the spouse's age. You can use an expressions on the LHS for a requirement constraint to determines whether the customer or their spouse is older and thus which partner is considered the principal applicant. The selection “Main applicant” is computer-selected if the customer is older than the spouse.

The example illustrates the two capabilities that using expressions in the LHS of a relationship allow you:

• Eliminate items (in the case of a compatibility constraint) and require items (in the case of a requirement constraint),

• Define a range of values that default a selection.

• Describe conditions that default a selection that can't be known at design time, especially in the case of external data.

In defining a range of values, you can describe the lower limit, the upper limit, or both. In addition, you can use more than one expression to define the default conditions.

Requirement Constraint

A requirement constraint makes a computer selection on items that meet the LHS criteria. The figure below shows a simple Requirement, where selecting “photogray” causes “glass” to be computer-selected.

Requirement constraints have these characteristics:

• Requirement constraint behavior is unaffected by optional/required status on a selection point.

• If an RHS control is single-select, the selection is made and the rest of the items are eliminated. In the multi-select case, the computer selections on the RHS are made, but no eliminations occur.

• Given the constraint shown in the figure, if the RHS item “glass” is eliminated (by a different constraint), then the LHS item “photogray” will also be eliminated.

• Externs can be used on the LHS and the RHS of a requirement constraint.

When the Requirement is written on a Selection Point, you can define default quantities on the selections. If the Selection Point has Quantity property set to True, settings appear in the column.

See Editing Requirement Constraints.

Dynamic Default

As mentioned earlier, a Dynamic Default is not a true constraint because it is not considered in the model verification process. There are some similar traits, however. A Dynamic Default is directional. When the LHS criteria is met, a computer-select occurs on the item on the RHS, provided it is available and selecting it will not cause a violation. The RHS can have multiple arguments (multiple columns in the relationship table), in which case a default pick can be made on each control.

See Editing Dynamic Defaults.

A dynamic default has these characteristics:

• If a default item has been eliminated, nothing is done.

• Once the default pick exists, any constraint reference to the item can eliminate it. There is no violation when a Dynamic Default is superseded.

  The following figure shows a simple default with two rows. Each LHS argument has a different pick on the RHS. “Plastic” picks “anti-scratch,” and “plasticShatterproof” picks “anti-reflective.”

• As with Requirement constraints, when the default is written on a selection point, you can define quantities for the selection. If the selection point flag Quantity is set to True, settings appear in the column.

Resource Constraint

A Resource constraint evaluates numeric attribute values. A constraint designates one or more provider attributes and one or more consumer attributes. If the sum of the consumers exceeds the sum of the providers, a conflict occurs and an explanation, if defined, is displayed at the page level. This behavior can also be achieved with a numeric Comparison.

See Editing Resource Constraints.

Summation

The summation relationship adds the value of numeric attributes. The sum can be displayed at run time. The summation relationship does not affect model verification.

See Editing Summation Relationships.

Elimination

An elimination compares a specific attribute value on a selection point with the value of a numeric, boolean, string, or date expression. The following figure shows an elimination where domain members of the selection point “HardDriveSelection” are eliminated if the value of the selected hard drive’s Watts attribute exceeds the value passed in by externExpression. An explanation appears at the page level when the constraint is violated.

See Editing Elimination Constraints.

Comparison

Advanced Configurator supports comparison relationships for the four data types string, numeric, boolean, and date. If the comparison is False, a conflict occurs, and an explanation, if defined, appears at the page level. Because comparisons operate on expressions, it does not pick or eliminate domain members.

A numeric comparison compares the value of one numeric expression with the value of another; a boolean comparison compares boolean values; a string comparison, strings; and a date comparison, dates. Or, you can compare the value of an expression with a constant rather than an expression with the “to the constant” option.

The figures illustrate examples of a string, numeric, and boolean comparison.

See Editing Comparison Constraints.

Effectivity Dates

Relationships and comparisons have optional date of effectivity ranges to indicate when they are to be considered active and thus used in a configuration session. With effectivity dates, you can define constraints and defaults that apply only during special sale periods, holiday periods, or other times when the valid or suggested configuration is slightly different.

In contrast, expressions and summations do not have effectivity dates because their results may be used in other, active relationships and expressions, and may be displayed on the UI. You can set effectivity dates on compatibility and incompatibility constraints, dynamic defaults, resource and requirement constraints, comparisons, and eliminations.

Effectivity dates are set in the relationship’s table editor using the Effectivity dialog. Click the Edit button to open the dialog.

You can enter multiple date ranges by clicking the Add button.

At run time, the server’s system date or a specific solve date is compared to the date ranges specified on each of the relationships in the model. If it falls within any date range specified on a relationship, then that relationship will be included in the configuration session. As soon as the Configurator engine detects at least one valid range on a relationship, it will cease further comparison against any remaining date range rows and the relationship will be enabled. If the date entered at run time does not fall within any date range specified on a relationship, then that relationship is disabled. Relationships that have no date ranges specified are considered to always be enabled.

Active relationships will be executed and propagated, and their results returned to the end-user UI. Disabled relationships will not be executed or participate in propagation, nor will they interact in any way with the configuration.

Any date can be entered at run time, however, if no date value is entered, the current date will be used.

To facilitate model testing, Visual Modeler allows you to specify a date to use as the solve date, so that when the model is run, the engine will use that date rather than the system date or a specified date. The model test solve date is set in the Projects Settings dialog. In addition, the Model Tester itself lets you change the solve date without recompiling the model.

Expressions in Relationships

Note that every expression you create appears at the bottom of the Model Tester with its current value. This will help you determine what is happening when you test your model.

Expressions will evaluate without selections or user entries. If a referenced object does not have a user selection or user-entered value, the default value for the object will be used. If you don't want the expression to evaluate, you can use the “bnd( )” function around the participating objects.

Note. The model will still verify as true when expression values are missing or incomplete. Because an unbound constraint is never evaluated, no conflict is generated. Use the “bnd( )” function with any objects that you want to remain optional.

A pick can be a user pick, None on a single-select, default picks, or computer-selections. This is a limiting factor if you want to use multi-selects or if you want items to be optional. This example shows a workaround for the multi-select case, where an extra domain member No Thanks has been added and is selected by default.

This figure also demonstrates explanations for relationships that use expressions. The total exceeds the budget amount specified, so a message is displayed at the top and the configuration evaluates to false.

Note. Advanced Configurator doesn't support date constants in expressions. Rather than using a constant, use the function date, toDate, or intToDate to generate the date.

For example, instead of

dateToInt(2002-10-24)

use one of these:

dateToInt(intToDate(20021024))

dateToInt(toDate("2002-10-24"))

dateToInt(date(2002,10,24))

Relationship Explanations

The relationship editors for constraints have a field named Explanations. For Compatibility and Requirement constraints, it appears on the Info View tab. For all others it is at the top of the form.

The Explanations field allows you to specify a message for display at run time. The explanation will only be displayed if the constraint is violated. (Text entered in the Explanations field is passed to the “Why Help” control if one is implemented for the page.)

• If the constraint is a Compatibility or Requirement constraint, the explanation will appear on all control(s) participating in the constraint and also at the page level.

• If the constraint is a Resource constraint, Elimination, or Comparison, the message appears at the page level only. In the Model Tester, this is at the top of the model.

• A parameter can be used to display the name of the pick as part of the explanation. The parameter format is $(N:$NAME). You can also show other values besides the name by replacing $NAME with an attribute value or one of a list of provided parameters. If the domain members are external, you must refer to the database column name instead of an attribute name.

  N is a number corresponding to a column in the relationship table. The left-most column is 0 and the number increments as you count to the right.

  See Creating Parameterized Explanations.

Relationship Properties

Depending on their type, relationships can have these properties:

• Enabled

• Exclusive

• Format

• Effectivity Date

• Levels

Enabled

All relationships have the Enabled property. When Enabled is True (the default) the relationship is included in the model at compile time. If Enabled is False, the relationship is ignored. This setting is useful for testing relationships.

Exclusive

The Requirement constraint has a special field named Exclusive. Setting Exclusive to True means that a control will be reserved for the RHS element in a Requirement constraint. You must define a separate constraint for each selection point that requires a reserved RHS selection. At compile time, the selection point for the RHS argument will be “cloned” for each constraint that requires it. In this manner, a selection on the RHS can make a pick on the reserved control without eliminating that option for other constraints.

Format

Constraints can be stored in three formats. The format can be selected as shown in the figure.

Internal

In the Internal format, the constraint is stored in the .cms file specified when it was created.

Effectivity Date

Relationships and comparisons can be set to participate in a configuration session only during one or more specified time periods. The Effectivity property allows you to enter one or more “From” and “To” date ranges. If the configuration session’s “solve date,” taken from the end-user’s system, falls within one of the specified ranges, the relationship or comparison is made available for the session.

By default, relationships and comparisons have a single effective date with the range 1/1/1900 to 12/31/2099.

Levels

A constraint can have an arbitrary level number assigned to each argument. The level number is only returned when an item is eliminated, including when it is in violation. JSP page designers can use the level number to decide when to suppress display of certain selections.

To set a level, click the its Edit button in the Relationship properties editor to raise the Levels dialog. Select an argument, then click the dialog Edit button to change the level.

In the Model Tester, if the Show Elimination Level option is checked, the lowest level number for an eliminated item will be displayed. If no elimination level was defined for a selection, the Model Tester automatically returns 1.

Default Values Within Expressions

At run time, expressions are not evaluated until all the arguments used in the expression are bound. For selection points, binding occurs when a selection has been made; for an extern, when a value has been applied. However, preferred behavior is that expressions are evaluated all of the time unless there is a specific reason to delay evaluation until all arguments are bound.

In order to enable testing when there are unbound arguments, expressions use the defined default value for unbound arguments.

Default values allow an expression to evaluate regardless of whether all of the arguments are bound. However, if you don’t want the expression to evaluate unless particular arguments are bound, use the bnd() function within the expression. The bnd() function returns the value of the first bound argument or a “not bound” status if none of the arguments are bound. If bnd() is used within an expression and it returns the “not bound” status, the expression will not evaluate.

Example: The following expression always evaluates and returns a result even if the selection points don’t yet have selections:

SP1:attr1 + SP2:attr2

To cause the expression not to evaluate unless arguments are bound, use the bnd( ) function within it:

SP1:attr1 + bnd(SP2:attr2)

You can also use the bnd()function in cases where a different, non-bound value is required:

SP1:attr1 / bnd(SP2:attr2, 1)

In this case, the bnd()function is used to return the value “1” for the numeric attribute of SP2, if SP2 is not yet bound.

Quantities in Modeling

In a model, you can define quantities on a selection point and quantities for a selected domain member that allow you to implement a wide variety of quantity-dependent business logic.

Advanced Configurator quantity functionality lets you:

• Control how many different items on a control can be selected (single- and multi-select). The user or computer can select either ItemA1 or ItemA2, but not both. Or, the user can select any number of items in the control, up to the number displayed.

• Control the quantity of the domain members themselves. The user or the computer can select one or more of ItemA1.

• Do both of the above in combination:

  • One or more of ItemA1 and ItemA2.

  • One or more of ItemA1 and just one of ItemA2.

  • One of ItemA1.

  • One or more of ItemA2.

• Specify default selections based on quantities—if the user selects three of ItemA1, then select ItemB1 (or 3 of ItemB1, if desired).

• Specify default quantities based on selections—if ItemA1 is selected, then select three of ItemB2 (and ItemB3 and ItemC1, if desired).

• Limit or specify the number of items a user can select within a selection point. For example, the user can select up to three of ItemA3, and no more than one of ItemA4.

• Set up minimum default quantities to ensure that enough of ItemA3 is ordered when it is selected.

• Ensure that enough of ItemA3 is ordered when the user selects ItemB2 in another selection point, which requires a specific quantity of ItemA3.

• Use an expression to calculate the required quantity of an item that is dependent on user input.

• Determine item quantities based on domain member values.

Advanced Configurator default quantity definitions allow you to build flexibility into quantity determination for domain members that takes into account both predetermined quantity requirements and their interaction with runtime conditions. The following illustrates the problem:

Quantity determination in response to runtime events

Advanced Configurator lets you set limits on the final quantities, whatever quantity choices the end-user makes:

Dynamic process of determining the final quantity of a selected domain member

You must be able to set limits on the quantity of each domain member, yet allow for quantities that result from runtime processes, such as constraints and user entries. In addition, you may need to take into account quantities defined for its selection point.

Defining quantities in models depends on these basic concepts:

• Quantity defaults for individual domain members control how many of the selected item is chosen—2 of ItemA, or 0 of ItemB.

• A quantity defined for an entire control—in the model represented by the selection point—determines how many of the control’s items can be selected. If the quantity is one, it is a single-select control; more than one, a multi-select control.

• You can set default quantities at design time whose default values do not change during run time, acting as absolute values for calculating a final quantity that takes into account quantities generated by run time events such as user picks and constraints.

Static Default Quantities

The quantity of the selection DomainMemberX can be affected by static default quantities–the default value you assign to it during modeling. An example is the quantities assigned automatically when a domain member is selected.

For example, in a network model, NodeY always requires at least two Routers, more if certain other components are selected in combinations determined by various constraints. By setting a static default of 2 on the NodeY domain member, and giving it a Quantity Policy of MIN, you can ensure that if it is selected, it will be ordered in a quantity of at least 2. Static default information for a selection point is applied whenever a dynamic default or Requirement constraint selects any domain member of that selection point, provided there are no user selections.

In addition, if the other nodes in the Node selection point—NodeX and NodeZ—have the same MIN(2) requirement, you can set the Use Quantity Policy for all Domain Members option as a “blanket” default.

See Also

Interaction between Default Quantities and Min/Max Settings at Run Time

Dynamic Default Quantities

The value of dynamic default quantities is determined at run time in response to expressions or dynamic default constraints. Expressions can be included in a quantity policy—Overridable f(x), Min of f(x), Max of f(x), and Sum f(x).

The Requirement constraint and Dynamic Default relationships select domain members in response to user or computer picks during run time. Quantity for the default-selected domain member is 1, unless you specify a new quantity and a new quantity policy. Quantities are defined on the table editor for the relationship.

A dynamic quantity definition would be needed in the case of a computer model. The model specifies by a dynamic default that when BoardA is selected, the Advanced Configurator should select FanA as well. Thus, a computer-select occurs for FanA, with a quantity of 1. (This computer-select occurs unless the selection causes a conflict with another selection that is either required or user-selected.) However, BoardB requires 2 of a different fan, FanB, so quantity must be added to the default definition of the BoardB/FanB requirement. In the relationship editor, the constraint’s RHS for BoardB would be Min of 2 for FanB.

Only selection points with Quantity = True are settable.

Multiple Selections on a Single Domain Member

When there is the potential for multiple default selections on the same domain member, you must set up contingent definitions at design time that correctly calculate the final quantity no matter what or how many of the domain members are selected in response to runtime criteria. An example is a network model that contains server boxes requiring chassis. The chassis type (domain member) and quantity depend on the number of slots the server requires, as one chassis provides two slots and the other chassis provides four. When the user selects the desired server boxes, the proper chassis type(s), in the required number, are default-selected. In such a case, the quantity of chassis’ can be the largest of the default quantities (minimum value), it can be summed, or it can be a combination of the two.

Order of Evaluation

When a domain member has multiple default quantities, the Advanced Configurator evaluates the selections in a predetermined order.

Step 1—Default quantities for the domain members are evaluated first to arrive at a single value according to the policy: the least value (Min of); the greatest (Max of), and total (Sum). These are specified in the relationship editor:

Step 2—The domain member’s static Min/Max setting, if any, is applied: adjust up to the minimum value (Min of), adjust down to the maximum value (Max of), total (Sum). If Overridable is the policy, this step is not performed. Policies are specified in the Defaults editor:

Step 3—If Use Base Quantity Policy for All Domain Members is specified, it is applied against the result of Step 2 in the same way as the domain member’s static policy.

Step 4—Step 3 yields the final calculated value. If a user enters a value, it overrides this value.

Understanding Minimum and Maximum Selections and Limits

Advanced Configurator allows you to set constraints based on the minimum and maximum quantity entered for domain members and on the minimum and maximum number of selections made within a selection point.

Min/Max limits can be specified on these Visual Modeler objects:

• Selection points

• Domain members

Selection Point Min/Max

Min/Max limits on a selection point determines whether its control is single-select or multi-select, and if multi-select, how many of the domain members can be selected.

You can use any of the following to input min/max limits:

• An absolute number (for a static, known check).

• A database reference.

• A reference to an expression defined elsewhere in the model.

Note. With dynamic inputs such as the result from a database query or an expression, it is possible for a single-select control to be re-specified a multi-select control during a configuration session when the SP Max changes from 1 to >1. When the Max limit is specified in this way, the control will behave like a multi-select that is limited to a single selection, versus a true single-select. Limitations that apply to multi-select selection points will apply even when the maximum number of selections is one. For instance, multi-selects do not allow violation explanation substitutions, and there are limitations on how they can be used in constraints.

Domain Member Min/Max

Min and Max limits on domain members determine how many of each domain member can be ordered if selected.

Values for domain member Min and Max limits are input from:

• An absolute number entered by the modeler.

• A reference to an expression.

• A domain member attribute whose type is Int or Float.

Note. The Min/Max function applies to the number of selections on a selection point that can be specified at the selection point level or the quantity that can be entered for a selected domain member at the domain member level, or both. It is a separate function from the Min of and Max of quantity policies of the Default Quantity functionality described in the previous section.

Interaction between Default Quantities and Min/Max Settings at Run Time

Min/Max settings add another aspect to the runtime process of determining final quantities on selected domain members.

When a selection point has both default quantity properties and Min/Max properties defined on it, specific runtime behaviors apply.

The Quantity policy—the manner in which to apply the default value—for a static default can be either Overridable, MIN, MAX, or SUM. If MIN, MAX or SUM is specified, then the static default is used in conjunction with any dynamic defaults and requirement constraints that select the same domain member. By default, the Quantity Policy for a static default is Overridable (meaning, “do not apply the value if run time selections assign a quantity”).

Static default information for a selection point is applied whenever a dynamic default or a requirement constraint selects any domain member of that selection point and there are no user-selects. A static default on a specific domain member applies only to that domain member.

Default quantities, whether static or dynamic, are not applied if they would cause any constraint to be in violation.

Ultimately, a user-specified quantity overrides any quantities specified by static defaults, or assigned by dynamic defaults during run time. Advanced Configurator allows the user to enter a quantity even if it violates a constraint, a quantity default, or min/max settings. However, the appropriate violation explanation will be displayed.

Note. When you use the Model Tester, you may observe that when you attempt to undo or back out of a configuration pick sequence, all picks on the control disappear rather than just the expected last pick. This occurs because the Configuration Engine is stateless; it receives all picks at one time, at each submission, and doesn’t know which was the last pick. By turning off Auto-Submit when you test the selection point on the Model Tester, you can observe true runtime behavior.

Minimum Violation Explanation and Incomplete Configuration Explanation

Advanced Configurator distinguishes between two very similar violation circumstances involving quantities on a selection point.

The project setting “Incomplete Configuration Explanation” is similar to the Min/Max violation explanation in that it alerts the user of a non-valid configuration condition.

These two explanations differ in the circumstances in which they are presented.

If a completeness check operation is requested, the Incomplete Configuration Explanation is shown when no selections have been made on a required selection point.

If selections have been made on the selection point, but the number of selections doesn’t satisfy the minimum value specified, the selection point Minimum Selection Explanation will be shown rather than the Incomplete Configuration Explanation.

See Also

Specifying Model Project Settings

Creating Parameterized Explanations

Advanced Configurator allows you to offer specific information to users when their picks violate a constraint based on a numeric relationship. Using the parameters representing objects such as maximum quantity allowed, you can write a violation explanation that describes the violation more specifically than does a generic text message.

You can include parameters in the Explanation fields of all constraint editors, and in the SP and DM Min/Max editor dialogs.

You can also represent external objects.

If the control is single-select, you can parameterize an explanation specific to the domain members in violation. Parameter substitution can not resolve the domain members in multi-select controls, so use on multi-select controls is limited to the selection point level Min and Max Value, selection point Name, or an expression value.

General syntax is:

$(replacement_specification)

replacement_specification is either

n:attribute_identifier or expr:expression_identifier.

n is the positional identifier for the class within the relationship (0 – n left to right in the relationship).

Note. Use n = 0 for SP Min/Max and DP Min/Max explanations.

attribute_identifier is a class attribute name or one of the reserved names from the list in the table below. If the objects are external, you must refer to the database column name instead of an attribute name.

expression_identifier is an expression name.

The following table describes the reserved parameters and indicates whether each is available for single- and multi-select controls.

Note. Please observe letter case as shown in the syntax column for each variable (expression and attribute names are lower case; all others are upper case).

For example, in a requirement constraint, messages are:

In another example, in a DP Min, messages are:

Optimizing Performance and Minimizing Model Maintenance

To improve performance and minimize effort expended on maintaining a model, consider these tips:

• Plan your model hierarchy so that you can use attributes efficiently.

• Stabilize attribute names, class names, and selection point names before creating constraints or expressions.

• If a model uses numerous multi-select controls, it is possible for constraints against the same control to conflict with other constraints to the point that all items on a control are eliminated. The following practices can reduce the occurrence of this problem:

  • Articulate the class hierarchy to a greater degree. If a multi-select control contains many domain members that are known to conflict, create subclasses and group the domain members in compatible sets. Alternatively, separate single-select and multi-select items.

  • Write more constraints. Instead of writing a single large constraint with many columns and rows, write more specific classes and constraints.

• Do not use a directional compatibility constraint if a multi-select is on the right-hand side. A directional compatibility with a multi-select on the RHS is ignored because every combination is considered valid. If a multi-select is required on the RHS, write the constraint as a directional non-compatibility constraint or a Requirement constraint.

• If possible, use a Requirement constraint instead of a Compatibility constraint. Because a Requirement constraint does not eliminate, there is less chance of conflicts between constraints.

• For all directional constraints (compatible, non-compatible, requirement, and dynamic default), if there are multiple arguments on the RHS, there is no explicit relationship between them. So, instead of writing multiple constraints against a single class, it is more convenient to write a single constraint with multiple arguments on the RHS.

Using the Sample Models

Visual Modeler is shipped with these example models:

• A component model called Sample, which you can load by choosing the Sample button in the Visual Modeler launch screen.

• A telecommunications compound model called TelcoSampleCompoundModel, containing three component models TelcoComp, TelcoCompCircuit, and TelcoCompHub.

The Modeling Process

Defining a robust model of a product or service requires some or all of these steps:

1. Use Visual Modeler to:

   • Build a class structure that represents data relationships in a configuration problem.

   • Define class attributes, create domain members, and provide attribute values in the model, or bring in domain members and attribute values from an external source, such as a database or the user.

   • Write relationships between classes and class attributes on a component model.

   • Specify quantities for default selections and define quantity behaviors that calculate a quantity at run time.

   • If supported version control software is available and connected in the Visual Modeler, you can interact with the version control software at any time during model development.

   • If you are building a compound model, create configurable components and associate each with a component model, then create the relationships between the component models.

2. Connect to the Configurator engine to compile the model and launch the Model Tester.

3. In the Model Tester, verify that relationships work properly on runtime controls.

4. Using model information from the Visual Modeler source, use PeopleSoft Extensions for DreamWeaver to develop JSP pages or use those provided with PeopleSoft Order Capture.

See Also

PeopleSoft CRM Order Capture Integration

Building a Custom User Interface

Model Tester

Included with the Visual Modeler install is a web-based test tool that renders the selection points in a pre-formatted form when you compile and run the model. Using it, you can test most facets of model behavior without building your own test UI. The Model Tester lets you verify the validity and behavior of relationships, data input and handling, error recognition, and control behavior.

See Using the Model Tester.

Interfacing with Third-Party Tools

This section lists Advanced Configurator interfaces with industry-standard applications.

Microsoft SQL Server, Oracle Databases, and IBM DB2

Visual Modeler can query tables in Microsoft® SQL Server™, Oracle™, or IBM® DB2® databases. In addition to obtaining domain members from a database, you can write model constraint information to a database table, or read constraint information from a database.

MacroMedia DreamWeaver

Visual Modeler creates an XML file that contains information about the model that can be used to lay out controls at run time. Advanced Configurator provides extensions to MacroMedia® DreamWeaver® so that you can use this information to create JSP pages.

See Using the Page Editor Extensions for Dreamweaver.

Source Control Interfaces

The Visual Modeler uses a standard Microsoft interface to access compatible configuration management software. Microsoft® Visual SourceSafe™, Rational ClearCase®, and Merant™ PVCS are verified as being compatible.

See Source Control Software.