IntroductionVisual Modeler is the administration application for the Product Configurator. The Product Configurator displays configurable products to customers.
Use Visual Modeler:
to create models of configurable productsto specify configurable selectionsto define the rules that control what constitutes a valid configurationto control how the Product Configurator presents selections to the end-user
Mobile Configurator enables customers to configure and buy products using the product models on a standalone PC when they do not have Web access to the Sterling Multi-Channel Selling Solution.
Using the Visual Modeler
A configurable product offers a number of options from which a customer can select before buying the product. Technical or marketing concerns can constrain the choice of options or available combinations of options.
Configurable products enable a customer to start with a basic model, then navigate through a series of selections (option items) to configure the product to their specific needs. You create configurable products using Sterling Product Manager, but first, a product modeler must use the Visual Modeler to create a corresponding model.
To make a product configurable, mark it as configurable in the Catalog and associate it with a model that provides information about options and the possible combinations of options.
Terminology
Model Group Hierarchy
A model, with its option classes, option items, option class groups, and option item groups, represents all of the possible valid configurations for a single product. Every model created in the Visual Modeler belongs to a model group.
A model group is a way to associate similar models, model groups, option class groups, and option item groups. The top-level of the model group hierarchy is the root model group. Each model group belongs to a parent model group. Only the top-level, root model group has no parent. The following figure shows a sample model group hierarchy.
Associate a Product with a Model, an Option Class, or Option Item
When you create a product in Sterling Product Manager, you also associate the product with a price list. In Visual Modeler, you can select a product created with Sterling Product Manager and associate that product with a model, an option class, or option item. As the customer configures the product, Sterling Configurator uses either the price of the product associated with the model or the accumulated prices of the products associated with the option classes or option items to determine the price of the configured product.
For example, suppose that you have an option class that represents a selection of graphics cards. The option class consists of option items, and each option item represents a different graphics card. In Sterling Product Manager, you create a product for each graphics card, then associate the new graphics card product with a price list. In Visual Modeler, you associate each graphics card option item with a graphics card product, which also associates the graphics card option item with a price (through the price lists created with Sterling Pricing).
When you associate a product with an option item, customers see this option item only if the associated product is on one of the price lists assigned to their partner.
How the Visual Modeler Works
Properties define the characteristics of models, option classes, and option items. Rule definitions use properties to constrain customer selections and determine whether or not a configuration is valid. The Product Configurator uses the product model to guide customers' choices so that they can configure a build-to-order product. When a customer chooses an option item, a property attached to that option item can trigger a rule.
For example, suppose that a mountain bike model consists of the option classes frame, forks, and wheels. The model has a weight property that is attached to every option item in the model. Each item in each mountain bike option class is assigned a weight property value: each frame has a weight, each fork has a weight, and each wheel has a weight. After the customer makes choices about a frame, fork, and a wheel, the sum of the individual weights total the entire weight of the bike.
The modeler can define a weight rule to specify that the entire weight of the mountain bike must be under a certain amount, for example, 15 kilograms. The modeler can specify an error message to display to the customer if the weight is over the specified limit.
When a customer chooses an option item (frame, fork, or wheel), the Product Configurator uses the rule to determine the total weight value by adding the weights of all chosen option items associated with the weight property. If the total weight of all the option item(s) is over 15 kilograms, the customer sees the error message that their bike weight is over the recommended weight and they should choose another option item in one or more of the option classes.
Determine the User Interface
When you create a configurable model, you set display properties and select a JSP template to determine how the Product Configurator displays the model to the customer. The possible UI's are:
Normal: this UI displays the model and all its option classes on a single page.Tabbed: this tab-based UI groups the model's option classes within a series of tabs. An option class can be attached to zero or more tabs.Stepwise: this step-by-step UI leads novice users through the configuration process for a particular product. The modeler groups the model's options into a series of tabs, each of which represents one step of the configuration process. Each tab contains the option classes relevant to that step.Option Classes and Option Items
An option class is a configurable part of a model consisting of option items and nested option classes that have a common purpose.
An option item is a member of an option class. The option item can either be an orderable part or an intermediate selection in the process of determining an orderable part. Properties are usually associated with option items.
For example, if a car is a configurable product, an engine is a configurable part of the car. You can create a model called "car", then an option class called "engine". You can then create option items in the engine option class such as 4-cylinder, 6-cylinder, gas-electric hybrid, and hydrogen fuel cell.
Groups and Sub-Models
An option class group or an option item group enables you to reuse option classes and option items in a model group, so you do not have to re-create the same items each time you need them. You can create a single group at the model group level, add option classes (with their option items) to the group, and then attach the group as needed in the required locations. For example, several models might have the same support choices, such as warranty selections or hardware support choices. Rather than create the same option classes or options items for each model, you can create them once as part of an option class group or option item group, then attach the group to each model that requires them. You can nest groups within other groups.
If the elements of an option class or option item group require new properties, or if the elements require that existing properties be modified, you modify the group in the place in which you originally created it. The modifications appear in the group throughout its attached locations. The following figure shows examples of groups.
A model can be stand-alone and part of another model. A model that is part of another model is a sub-model.
The following table shows which groups can be attached to which elements.
Groups To Be Attached Attach to Model? Attach to Option Class Group? Attach to Option Class? Models No Yes Yes Option Class Groups Yes Yes Yes Option Item Groups No No Yes
Properties
A property is a characteristic that describes a model, option class, or option item.
You can define a property as part of a model group or as part of a specific model. A property defined for a model group is available to be attached to any model, option class, or option item within the model group hierarchy in which it was created. A property defined for a model is available only to the model itself, as well as option classes and option items within the model hierarchy.
Model Group Model Option Class Option Item Option Class Group Option Item Group Define Yes Yes No No No No Attach No No Yes Yes No No
For example, in the following figure, property X is defined in Model Group A and property Y is defined in Model A1. Property X can be attached to Model A1 and Model A2, as well as any models in Model Group B, such as Model B1. However, the property cannot be attached to Model C which is not a child of Model Group A. Property Y is defined in Model A1 and therefore cannot be attached to either Models B1, A2, or C.
The catalog of properties that you build up using the Visual Modeler can become extensive very quickly, so before defining a new property, check whether an existing property will suit your needs.
Property names should be descriptive. The property name must be unique within the model group.
Using Properties
When you create a property, you can also define a default value for that property. When you assign that property to a model, option class, or option item, the property has the default value unless you override it. You can assign the value of a property when you attach the property. For example, you can assign the default value 8 for the weight property of one of the bike forks and assign the default value 10 for the weight property of a different bike fork.
You must set up properties for each option class and option item that is included in a validity check and triggers an option item expansion.
Suppose that a model for a configurable computer requires a different amount of RAM for different types of software. You can create a property called memory_required to enable configuring the amount of RAM. When you attach the memory_required property to different software option items in the model, you determine the value of RAM memory required for the individual software. At the same time, RAM is an option class. The amounts of RAM that the customer can order are the option items in that class. You can create a property called memory_ordered, then set a value for this property or set it up as a calculated value triggered by a rule based on a quantity entered by the customer.
Property Names
Ensure that you give properties descriptive, unique names to avoid confusing properties that should be kept distinct, and to ease maintenance of models. For example, using Weight as a property name in a number of option classes can be confusing if you need to distinguish between the weight of items from two different option classes.
Attach Properties to Option Items
The option item to which a property is attached may be any component of an orderable item that has the characteristic represented by the property. For example, you can attach a frameWeight property to a frame since the frame has a specific, defined weight. The property value must match the property type: you cannot assign a value of "blue" to a property of type number. Depending on the property type, the value may represent either the quantity of the property represented (numeric), a specific instance of the property (character), or a list of many instances of the property.
Display Properties
Use display properties to control the model elements on the HTML page displayed to the customer by the Product Configurator.
Lists
When a property can have only certain pre-defined values, such as the days of the week or clothing sizes SM, M, L, or XL, define the property as type List. You can write rules to test that the value of the property is defined in the list.
For example, suppose that you have a property called ShirtSize. To restrict the consumer choices to SM, M, L, or XL:
- Create a list called ShirtSizeList. Enter values for the list: SM, M, L, and XL.
- Create a property called AvailableShirtSizes whose type is List and assign it the value ShirtSizeList.
- Create the ShirtSize property and assign it to option items as appropriate.
- Create a rule that specifies that the value of the ShirtSize property must be in the list of the AvailableShirtSizes property.
Rules in Visual Modeler
Rules determine which instances of a model are valid. You define and attach rules to appropriate places in the model hierarchy to ensure that customers can select only combinations of option items that are compatible or suitable.
Each time a model is validated (for example, each time a user picks an option item), the rules are fired. Rules evaluate to true (the rule succeeds) or false (the rule fails).
A rule consists of one or more fragments and one of the following types of actions:
message actions: messages that will displayan expansion action: products that will be addedan assignment action: properties that will be assignedRules enable the Product Configurator to guide a customer through the configuration experience by offering additional explanations and checking the selected options to ensure a correctly built product. Rules can also check when certain conditions will provide a customer with additional option items in the configured solution (expansion).
Rules can be simple: a particular option item must not weigh more than 100 grams. Rules can be complex: one option item must not weight more than 100 grams OR another option item must not weigh more than 50 grams AND the material must be carbon fiber.
Rules result in some kind of action being performed. A rule can check whether a condition exists, then display a message action as a result. For example, a rule can check the total weight of a bike and display a warning message if the bike is over a weight limit.
Rules can result in expansion actions. Based on a rule, additional selections can be provided for a customer. For example, a rule can determine whether additional memory is needed and how much.
Rules can result in assignment actions. Based on the calculations in a rule, a value can be assigned to a designated property.
You can design rules that display messages when a model instance fails to satisfy a rule or when a model instance satisfies the rule. You can also set the severity of the message.
Define Rules
You define rules at the model group level or the model level. Where you define rules depends on how you plan to use them. For example, if you want to attach the rule to any element in the model group hierarchy, define the rule at the root model group level. If you want to limit the use of a rule to elements within a certain model group (or to elements in sub-groups within that group), define the rule only at that model group level. If you want a rule for localized use by the elements in a particular model, define the rule at the particular model level.
Model Group Model Option Class Option Item Option Class Group Option Item Group Define Yes Yes No No No No Attach No Yes Yes Yes No No
Attach Rules
After you define a rule, you attach the rule to some level in the model (or group) structure. Where you attach the rule in the structure determines when the rule fires. By attaching a rule to a model, you ensure that the rule is processed to validate the model. A rule may be attached to any number of models (including sub-models). You can also attach rules at the option class and option item level, if the rule is specific to that level.
The point at which you attach a rule determines where messages display to end-users as they configure the product, and when, in the order of rule-firing, the rule fires.
Rule Fragments
A rule fragment is a component of a rule and comprises a function and property joined by an operator to another function and property or a literal value. The function determines a value for a property.
The functions listed here are the standard functions. The list of functions can be customized for your installation.
The following table lists the functions supported by the Visual Modeler.
Operators tie rule fragments together and define the fragments' relationship within the rule. The folllowing table lists the operators supported by the Visual Modeler.
Operator Description != Not equal to < Less than <= Less than or equal to = Equal to > Greater than >= Greater than or equal to in In the specified list not in Not in the specified listFor example, the rule "value(wheels selected) >= max (wheels required)" means: "the number of wheels selected in the configuration must be greater than or equal to the maximum number of wheels required by the configuration; otherwise this rule fails".
Single Fragments, Multiple Fragments, and Nested Fragments
A single fragment can consist of either of the following:
Two properties and their functions combined with an operator.A property, its function, an operator and a literal value.For example, suppose you have a rule that has a single fragment: Quantity of wheels ordered = Quantity of wheels required. In this example, Quantity of wheels ordered is the first half of the fragment with the property, wheels ordered, and the function, count (quantity). The second half of the fragment, Quantity of wheels required, has the property, wheels required, and the function is also count (quantity). The operator is equals ("=").
Single fragments can be linked together to form multiple fragments using Boolean operators, AND, OR, ANDNOT, ORNOT.
For example, you can add another single fragment to form a rule with multiple fragments (multiple lines in the Visual Modeler):
Quantity of wheels ordered = Quantity of wheels required
AND
Type of front wheels = Type of rear wheels
You can build complex rules such as:
(FragmentA AND (FragmentB OR FragmentC))
If Not Specified
A property can have an unspecified value. If a property is not assigned to an object that is part of the current configuration (a valid option item is not selected), the value for that property is defined as "not specified".
When creating a rule, you can select from four results for a fragment when the property is not specified:
Rule is true: The entire rule and all its fragments evaluate to true.Rule is false: The entire rule and all its fragments evaluate to false.Fragment is true: Treat the fragment result as a success, and move on to evaluate the next fragment.Fragment is false: Treat the fragment result as a failure.Triggering the Rule: Success or Failure
When you create a rule, you can specify whether action results if the rule succeeds or fails. For example, you can specify that the rule will be triggered on "failure": if the rule evaluates to "true", nothing happens: no message displays; if the rule involves expansion, no expansion occurs.
Rules and Messages
Messages help guide a user toward correct configuration choices. The rule message text can be up to 2000 characters in length.
For each message action, you can specify one of the following types of messages:
Expansion
Expansion means that additional items are added to the model configuration, based on a rule formula. The result of a rule formula is the starting point to determine which option item is expanded and included in the product configuration.
You can use properties to create rules that calculate the correct parts to expand on a model with additional option items, based on a user choice.
You can use rule formulas to create rules that calculate or determine the result of a rule. Rule formulas are usually based on values associated with properties. For example, a modeler can use a rule formula to compare the property quantity ordered by a customer with the property quantity required for the model. The rule formula calculates the difference and can automatically expand the model to include the option items that are needed to match the required quantity.
Numeric rule formulas must be valid mathematical expressions. A rule formula combines mathematical notation with the functions, operators, properties, and literal values to produce a value that is then measured against a minimum and maximum value to determine what and how much should be expanded. (Ranges are used only if a rule formula has been entered.)
In the following example, suppose that you want to create a rule to ensure that customers order the right amount of memory for a particular workstation configuration. The first fragment of the rule references a property called MX75_Mem_Auto_Select and is set to YES. The second fragment references two properties: MX75_Mem_Ordered and MX75_Mem_Required. If the MX75_Mem_Auto_Select is set to YES, and if the customer orders less memory (MX75_Mem_Ordered) than required (MX75_Mem_Required), the rule formula result is used to expand the configuration to include the right amount of memory. The customer is prevented from ordering an invalid workstation.
In this rule, the rule formula is written as shown in the following figure:
If the customer orders 64 MB of memory and the memory required is 128 MB, the rule formula returns a result of 64. Product Configurator evaluates this result against the min/max ranges for results. Since 64 is within the range of a minimum of 64 and a maximum of 128, according to the table, a quantity of 128MB of memory is selected (expanded).
Assignment
Another type of action that can result from a rule is Assignment. In this case, the modeler can define a rule that results in a value (based on the rule formula) being assigned to a property designated by the modeler.
Rule Firing
The Product Configurator processes rules by a two step process. Within each level in a model hierarchy, it processes rules according to the order defined by the modeler when rules are attached to that level.
Within the model hierarchy, the Product Configurator follows a process called "depth first traversal". At any node in the structure, the Product Configurator traverses down through that node's children to the lowest level, then traverses back, firing rules as it goes.
For example, in the following figure, the Product Configurator starts at the top and checks for any children, then traverses down to the first node. At this first node (Option Class 1), the Product Configurator checks for children. Since it finds none, the Product Configurator fires any rules attached to this option class: (1) in this case.
The Product Configurator proceeds to the next node, Submodel A, and finds two children, Option Class 2 and Option Class 4. Option Class 2 has a child, Option Class 3, so the Product Configurator traverses to that node. Since Option Class 3 has no children, the Product Configurator fires the rules attached to Option Class 3 (2), then traverses back up the structure to the parent, Option Class 2, and fires the rule (3) attached at that node.
The Product Configurator traverses to the next child of SubModel A, Option Class 4. There are no children, so it fires the rule attached to Option Class 4 (4). The Product Configurator traverses to the parent, Submodel A, and fires the rules attached to that level (5 and 6).
The Product Configurator moves to the next node (Option Class 5) and, since there are no children, fires the rule attached to Option Class 5 (7). All the rules attached to the children are fired, so the Product Configurator traverses back to the parent (Model B) and fires the rules attached to the parent (8 and 9).
Managing Option Constraints
You can manage the available option items based on other option items that your customers select. For example, a car dealer can specify that certain combinations of interior and exterior car colors not be sold together. Combinations of option items can constrain the selection of other option items. For example, if Option A and Option B are selected, Option C is not a valid choice.
To define these restrictions, you create a constraint table for a particular model. The constraint table consists of two or more columns. Each column represents an option class containing choices (option items) that may or may not be valid with the choices in the other columns. The constraints are defined by one or more constraint rows in the table. When you create the table, you can include a message (error, warning, or suggestion) to display if the customer makes an invalid choice.
You can also define a constraint row so that the choices for one column are not valid with the other columns. In this case, you want to constrain the customer's choices from matching any combination of items in an invalid row.
Testing and Compiling the Model
You can test the model as you create it. After you create the model, you click a button to compile the model into an XML file.
Copying and Embedding
You can copy or embed entities (model group, model, and so on) in the model group hierarchy. To copy an entity means to make a duplicate of a single entity (in the case of an option item) or of an entity and its structure (in the case of a model group, model, or option class group or option item group) within another location in the hierarchy. To embed an entity is to make a duplicate of the structure of an entity. For example, to embed a model is to take the model's structure and duplicate that structure (option classes, groups, and so on) within a destination in the model group hierarchy. Copying or embedding is performed at different locations in the Visual Modeler interface. When you copy or embed, attached properties follow certain rules:
If properties attached to the item are not defined anywhere among the ancestors of the destination, the property is defined locally.Where there is a conflict between a property attached to an item and a property attached to the destination, the property attached to the item being copied or embedded is dropped.The following figure shows a model group hierarchy before and after embedding. In this example, you embed Option Class Group 1 (OCG1) under Model 1 (MOD1). In OCG1, Property P1 (defined in Model Group 1 as INT) is attached to Option Class 1 (OC1). After embedding, a conflict will exist since, In MOD1, Option Class 3 (OC3) also has a Property P1 (defined in MG2.1 as STRING). Visual Modeler resolves the conflict by dropping the P1 attachment to the newly embedded OC1.
Importing and Exporting
You can import or export model groups or models in the form of XML files. You can import a model group or model to a specific destination or you can import the model group or model with its structure relative to its original root model group. When you import relative to the original model group, the model group or model is placed relative to the destination root model group in the same position relative to its original root model group. The integrity of the destination (such as existing paths) is not compromised.
For example, in the following figure, Model MOD1 is located in Model Group MG2.1 which is located in MG2. MOD1 is imported into MG2 on the right, relative to the root model group. In the destination hierarchy, there is a Model Group MG2. However, there is no Model Group MG2.1 within the destination MG2. The import process recreates the original structure relative to the root by creating a new Model Group, MG2.1, in the destination. This does not compromise any existing models under MG2.
In the following figure, Model MOD1 is located in Model Group MG2.1 which is located in MG2. MOD1 is imported into MG2 on the right, relative to its original root under MG2.1. In the destination hierarchy, there is a Model Group MG2. However, there is no Model Group MG1A. Creating MG1A above the existing MG2 would compromise the integrity of any entities within MG2, so the import process creates a new branch: MG1A, MG2, MG2.1, and the imported MOD1 with OC3.
Properties, Rules, Lists, Option Groups, and Sub-Models
The import process handles properties, rules, lists, and option groups differently, depending on whether you are importing a structure relative to its original root, or whether you are importing to a specific location without regard to its original root.
When you import a structure relative to its original root, the import process handles these items as follows:
Properties, Rules, and ListsThe import process examines the ancestral chain of the destination for definitions of entities that conflict with the imported entities' definitions. If it finds existing definitions, it prompts you for whether or not to overwrite the entities with the definitions of the to-be-imported entities. The entities do not have to be defined in the same location as in the imported structure. If existing definitions are not found in the destination, the import process creates them in the same location in the destination as in the original.Option Class Groups, Option Item Groups, and Sub-ModelsAt the destination, the process examines the path in the destination:If the path in the original exists in the destination, and if a definition of the entity already exists at the same location as in the original, the import process prompts you for whether or not to overwrite the definition.If the path in the original exists in the destination, but if a definition of the entity does not exist at the same location as in the original, the import process creates the entity at the same location in the path.If the same path does not exist, the import process creates the path, then creates the entity at the same location in the path.When you import a structure to a specific destination, the process handles properties, rules, lists, and groups as follows:
Properties, Rules, and ListsThe import process examines the ancestral chain of the destination for definitions of entities that conflict with the imported entities' definitions. If it finds existing definitions, it prompts you for whether or not to overwrite the entities with the definitions of the to-be-imported entities. The entities do not have to be defined in the same locations in the destination as in the imported structure. If the definitions do not exist in the destination, and if the structure does exist, the import process creates the entity at the same location in the structure as in the original. If the location does not exist, the import process creates the entity as part of the immediate parent to the structure being imported.Option Class Groups, Option Item Groups, and Sub-ModelsAt the destination, the import process examines the path in the destination:If the path in the original exists in the destination, and if a definition of the entity already exists at the same location as in the original, the import process prompts you for whether or not to overwrite the definition.If the path in the original exists in the destination, but if a definition of the entity does not exist at the same location as in the original, the import process creates the entity at the same location in the path.If the same path does not exist, the import process creates the location, then creates the entity at the same location in the path. For example, in the following figure, MOD1 is being imported into MG2. MOD1 has an option class group attached which is defined at MG2.1. MG2.1 does not exist under MG2, so the import process creates MG2.1 under MG2, then creates the option class group at MG2.1 and imports MOD1 under MG2.
Search the Model Hierarchy
You can search the model hierarchy for entities that contain property names or property values that you specify. You can search the entire hierarchy, or limit your search to model groups, models, option classes, option items, or rules. You can also limit your search to the currently selected model group, model, option class group, or option item group.
Reports
You can run a report on any of the models created with the Visual Modeler. You define the criteria to include:
Definitions: rule, list, and propertyModel hierarchy: display settings, attached properties, attached rules, whether or not to expand groups, whether or not to show complete pathsConstraint tables
© 2011 IBM Corporation. All Rights Reserved |