Introduction

Visual 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 products
to specify configurable selections
to define the rules that control what constitutes a valid configuration
to 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

Term
Definition
Ancestor
The entities that precede an entity in a hierarchical chain, back to the root model group. The ancestral chain.
Sterling Configurator
The application that enables specifying the available configurations of products and enables customers to select the configuration that best meets their needs.
Constraint Table
A means of specifying which selections of option items are compatible with each other. Constraint tables provide a simple way to manage the selections that end-users can make as they configure a product.
List
An object that allows the Sterling Configurator to validate a selected item by comparing the item to a list.
Model
A configurable combination of product options. Rules can be added to models to restrict the choice of combinations.
Model Group
A collection of models, option class groups, option item groups, or even other model groups.
Option Class Group
A collection of option classes or nested option class groups that represent entities that can be reused without change in any number of models and option classes.
Option Item Group
A collection of option items that can be reused in any number of option classes or option class groups in any number of models.
Option Class
A collection of option items, option class groups, option item groups, or other option classes that have a common purpose.
An option class is a configurable part of a model. For example, an engine is a configurable part of a car. The option items in the engine option class are 4-cylinder, 6-cylinder, and 8-cylinder.
Option Item
A member of an option class or an option item group. It is an orderable part or service for a model. Option items are usually associated with properties.
Property
A descriptive element used as the basic entity for rule creations. Properties are associated with models, option classes and option items.
A quantity or attribute of an item that indicates interdependencies (for example, a property could be "uses 5 MB of memory" or "provides 5 expansion slots").
Rule
A constraint that is attached to some part of a model hierarchy to enforce a technical requirement or business rule.
Sub-Model
A model that is used as part of another model.

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:

  1. Create a list called ShirtSizeList. Enter values for the list: SM, M, L, and XL.
  2. Create a property called AvailableShirtSizes whose type is List and assign it the value ShirtSizeList.
  3. Create the ShirtSize property and assign it to option items as appropriate.
  4. 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 display
an expansion action: products that will be added
an assignment action: properties that will be assigned

Rules 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.

Function
Definition
checkwslookup
Checks that the correct properties exist to invoke a Web service.
childsum
Sum of the specified property values defined at this node and any of the node's children (and recursively down to children of child nodes and so on).
count
Counts the number of objects (selected option items, models, or groups) having the specified property.
isselected
Returns true if the option item is selected; otherwise returns false.
length
Returns the length of a string property. If there is more than one instance of that property in the property pool, length returns the length of the first one it finds. To restrict the search to the parent hierarchy of the item to which the rule is attached, use the parentlength function.
list
Used with the operators "in" and "not in" to check if a property value is included or not included in a specified list of values.
literal
Exact match of the literal value.
lookup
Used to look up values specified by name from a properties file: the lookupValues.properties configuration file. A string property containing the key is used to find the entry in the property file. This entry defines the properties for this key and the values that each of these properties should be set to when the function is invoked. For example: suppose the following is defined in the properties file:
Color=blue,green,red
Color.blue=#0000FF
Color.green=#00FF00
Color.red=#FF0000
Then if the lookup(Color) function is invoked, the corresponding properties blue, green, and red will be attached at the appropriate node.
max
Returns the maximum property value from all selected items having the specified property.
min
Returns the minimum property value from all selected items having the specified property.
parent
This function walks up the tree from the current location to see if the property has been defined anywhere at or above the current location. For example, if the rule is attached at an option item level, then the property will be looked for on the option item itself. If it is not defined there, then the option class to which the option item belongs will be looked at to see if the property is defined there.
parentlength
Returns the length of a string property, checking only for properties in the current item's parent hierarchy. For example, in the following scenario:
Model
|
|-- OC1 - prop = "short"
|
|-- item1 (rule if (parentLength(prop) > 6), do something)
|-- OC2 - prop = "string that is exactly 42 characters long!"
|
|-- item2 (rule if (parentLength(prop) > 6), do something)
When the rule attached to item1 is evaluated, parentLength will return 5 and the rule will not fire.
When the rule attached to item2 is evaluated, parentLength will return 42 and the rule will fire.
path
Returns the relative path of a property from the root node of the model. The root node is replaced with an asterix (*). For example, if the path to the property is MXDS7500.Software.Applications.MSOffice.MX75_Mem_Required, path returns *.Software.Applications.MSOffice.MX75_Mem_Required.
propval
Returns the value of a property even if the option item has not been selected.
rawpath
Returns the actual path of the property without stripping off the root node. For example, if the path to the property is MXDS7500.Software.Applications.MSOffice.MX75_Mem_Required, rawpath returns MXDS7500.Software.Applications.MSOffice.MX75_Mem_Required.
sum
Sum of the property values from all selected items having the specified property.
value
Uses the property value for comparison. If multiple items exist on the order with the given property, then the maximum value is used.
wslookup
Invokes a specified Web service by calling its handler class. use this in conjunction with the checkwslookup function.

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 list
 
 

For 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:

Message Type
Definition
Suggest
Suggest messages create a message for the user indicating that a rule has failed or passed. These types of messages provide details about the suggestion (for example; "You may want to add more memory"). The configuration can continue.
Warn
Warn messages are similar to Suggest messages. The configuration can continue.
Error
Error messages prevent further configuration until the error is cleared.

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 Lists
The 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-Models
At 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 Lists
The 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-Models
At 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 property
Model hierarchy: display settings, attached properties, attached rules, whether or not to expand groups, whether or not to show complete paths
Constraint tables

© 2011 IBM Corporation. All Rights Reserved