This chapter covers the following topics:
Use the Rules area of the Workbench to define rules and modify existing rules. To modify how Model structure nodes are displayed in this area of the Workbench, see Preferences.
When you create a rule, Oracle Configurator Developer creates a new node in the rule Folder you specified. You can create as many Folders as you need, and a Folder can contain any type of rule. Use the Move and Copy actions to move or copy a rule from one Folder to another. Creating rule Folders is described in Creating a Rule Folder.
When you need to define more complex configuration rules, create a Statement Rule. For details, see Defining Statement Rules.
You can also extend the abilities of Configurator Developer and define custom behavior by creating Configurator Extensions. Configurator Extensions enable you to implement custom runtime rules, access information outside the configuration model, perform engineering calculations and integrate with an alternative user interface. Configurator Extensions are described in more detail in Introduction to Configurator Extensions.
For general information about rules, see Introduction to Configuration Rules. For details about defining each type of rule, see Defining Rules.
Follow these general steps to define any type of configuration rule:
Navigate to the Rules area of the Workbench.
In the same row as either the predefined Model Name Rules Folder, or a user-defined Folder, click the icon in the Create column.
Select the type of rule you want to create, then click Continue.
Enter the following for the rule:
Unsatisfied Message (available only for Logic and Numeric Rules)
When the rule’s definition is complete, optionally generate logic and test the rule in the Model Debugger, or a runtime UI. For details, see:
Refer to the following sections for information on defining a specific type of rule:
For an overview of Logic Rules, see Logical Relationships.
The following procedure assumes you have a Model open for editing.
To define a Logic Rule:
Navigate to the Rules area of the Workbench, and then click the icon in the Create column.
Choose a rule type of Logic, then click Continue.
Enter a Name and optionally a Description of the rule.
Under Operand 1, click Choose Nodes.
Select the node(s) to add to the rule, and then click either Choose Properties or Apply.
Click Apply to add the node(s) and return to the rule details page.
Click Choose Properties if you want to specify a System Property to use in the rule. After selecting a Property for each node, click Finish.
For more information, see Introduction to Rules, Node Types, and System Properties .
Select a Condition of Any True or All True.
For details, see Using AllTrue and AnyTrue.
Choose one of the following rule operands: Implies, Excludes, Requires, Negates, or Defaults.
For a description of each operand, see Logical Relationships.
Use the procedure described above to select rule participants for Operand 2.
If you need to define a more complex expression, click Convert to Statement Rule.
For details, see Defining Statement Rules.
Optionally define the following: Violation Message, Unsatisfied Message, Effectivity, and Notes.
For more information about these settings, see Modifying Rule Details.
Click Apply or Apply and Create Another.
Important: Accumulator Rules are only available when using the Fusion Configurator Engine (FCE). The FCE is an alternative to the configuration engine described in this document. For all information about Accumulator Rules, and the procedure for creating them see the Oracle Configurator Fusion Configurator Engine Guide.
This section describes how to define a simple Numeric Rule. To define more complex Numeric Rules, create a Statement Rule. For details, see Overview of Statement Rules.
For an overview of Numeric Rules, see Introduction to Numeric Rules.
The following procedure assumes you have a Model open for editing.
To define a Numeric Rule:
Navigate to the Rules area of the Workbench, and then click the icon in the Create column.
Choose a rule type of Numeric, then click Continue.
Enter a Name and optionally a Description of the rule.
Under Operand 1, click Choose Nodes.
Select the node(s) to add to the rule, and then click either Choose Properties or Apply.
Click Apply to add the node and return to the rule’s details page.
Click Choose Properties if you want to specify a System Property to use in the rule. After selecting a Property for each node, click Finish.
For more information, see Introduction to Rules, Node Types, and System Properties.
Indicate whether the result of Operand 1 will Contribute to or Consume from the participant in Operand 2 (you select this node in the next step).
Repeat the previous steps to select a single node under Operand 2.
Enter either an integer or decimal value as the Quantity Multiplier, or accept the default value of 1.
For example, you enter a Quantity Multiplier of 5. When the rule propagates at runtime, the value of the node under Operand 1 is 10. Therefore, a value of 50 will be contributed or consumed from Operand 2.
If the node in Operand 2 is not an Integer Feature, optionally select one of the following Integer Conversion methods:
Accept the default value of None if the node in Operand 2 is an Integer Feature, or if the node has a data type of Decimal and you do not want to convert the result to an integer.
Select Round to convert the result to the nearest integer.
Select Floor to convert the result to the next lower integer.
Select Truncate to convert the result to an integer by removing any numbers after the decimal. For example, 4.5687 becomes 4, and 12.879 becomes 12.
Floor and Truncate produce the same result when applied to a positive value. The difference between the two methods is apparent when the value is a negative number. For example, when the value is 4.3, it is converted to 4 regardless of whether you select Floor or Truncate. However, if the value is -4.3, the result is –5 when you select Floor but –4 when you select Truncate.
Select Ceiling to convert the result of Operand 1 to the next higher integer.
If you need to define a more complex expression, click Convert to Statement Rule.
For details, see Defining Statement Rules.
Optionally define the following: Violation Message, Unsatisfied Message, Effectivity, and Notes.
For more information about these settings, see Modifying Rule Details.
Click Apply or Apply and Create Another.
For an overview of Comparison Rules, see Comparison Rules.
The following procedure assumes you have a Model open for editing.
To define a Comparison Rule:
Navigate to the Rules area of the Workbench, and then click the icon in the Create column.
Choose a rule type of Comparison, then click Continue.
Enter a Name and optionally a Description of the rule.
Under Operand 1, click Choose Node.
Select the node to add to the rule, and then click either Choose Properties or Apply.
Click Apply.
Click Choose Properties if you want to specify a System Property to use in the rule. After selecting a Property for each node, click Finish.
For more information, see Introduction to Rules, Node Types, and System Properties.
Select one of the following Conditions from the list:
= (Equals)
< > (Not equals)
> (greater than)
>= (greater than or equal to)
<= (less than or equal to)
< (less than)
Indicate whether the result of Operand 1 Implies, Excludes, Requires, Negates, or Defaults the node in Operand 2.
For details about each type of relation, see Logical Relationships.
Click Choose Nodes to add one or more nodes to Operand 2.
Select a Condition of AnyTrue or AllTrue.
For details, see Using AllTrue and AnyTrue.
If you need to define a more complex expression, click Convert to Statement Rule.
For details, see Defining Statement Rules.
Optionally specify a Violation Message, Unsatisfied Message, Effectivity, and Notes for the rule.
For more information about these settings, see Modifying Rule Details.
Click Apply or Apply and Create Another.
For an overview of Property-based Compatibility rules, see Property-based Compatibilities.
The following procedure assumes you have a Model open for editing.
To define a Property-based Compatibility Rule:
Navigate to the Rules area of the Workbench, and then click the icon in the Create column.
Choose a rule type of Property-based Compatibility, and then click Continue.
Enter a rule Name and optionally a Description.
Under Operand 1, click Choose Node.
Select a BOM Model, BOM Option Class, or Option Feature node, and then click Apply.
Select a Child Property from the list.
Select one of the following comparison operators from the list:
= (equals)
<> (not equals)
> (greater than)
>= (greater than or equal to)
< (less than)
<= (less than or equal to)
See Equals, Contains, and Like Operators for more information about the equals (=), Contains, and Like operators.
Note: You can use any of these operators when comparing either numeric Properties or text Properties.
Under Operand 2, click Choose Node.
Select a Feature or BOM Option Class node from the Model structure, and then click Apply.
Select a Child Property from the list.
Optionally define the following: Violation Message, Effectivity, and Notes.
For more information about these settings, see Modifying Rule Details.
If you need to add another Property comparison to the rule or define a more complex expression, click Convert to Statement Rule.
For details, see Defining Statement Rules.
Click Apply or Apply and Create Another.
These operators are used when comparing Properties that consist of text, rather than numeric values. For example, a Property for the BOM Standard Item Copper Pipe is Diameter.
Properties may contain the percent sign (%) and underscore (_) characters. By using these characters, the equals (=), Contains, and Like operators enable you to apply the Property-based Compatibility Rule to only specific options. For example, when using the equals operator (=), the rule checks whether the Property in Operand 2 contains the percent sign or underscore character itself.
When defining a Property-based Compatibility Rule that uses the CONTAINS operator, the First Operand specifies the Option Feature or Option Class Property whose value is searched and the Second Operand provides the [Option Feature or Option Class Property] value to search for in Operand 1.
For example, when configuring a car, your interior color choices are limited by the exterior color you choose. In the Exterior and Interior Car Color Options example, you want to search the First Operand’s (Exterior Color) Property value for the available interior colors that are provided by the Second Operand’s (Interior Color) Property values.
Exterior and Interior Car Color Options
Exterior Color (Option Feature)
Option1 White
Interior Color (Property)
Gray (Value)
Option2 Red
Interior Color (Property)
Tan, Gray (Value)
Option3 Black
Interior Color (Property)
Black, Gray (Value)
Interior Color (Option Feature)
Option1 Tan
Color (Property)
Tan (Value)
Option2 Gray
Color (Property)
Gray (Value)
Option3 Black
Color (Property)
Black (Value)
Some color combinations are compatible, while others are not. The compatible color combinations for the above example can be expressed in a compatibility table as shown in the Compatible Color Combinations Table.
| Exterior | Interior |
|---|---|
| Red | Tan |
| Red | Gray |
| White | Gray |
| Black | Black |
| Black | Gray |
When defining the Property-based Compatibility Rule using the CONTAINS operator, the rule tests whether the value in Operand 1 contains the value in Operand 2. For example, to determine which interior colors are available for a car, the Property-based Compatibility Rule must be:
Exterior Color.Interior Color CONTAINS Interior Color.Color
During logic generation, the Property-based Compatibility Rule is parsed and validated. If there are no valid combinations, then a warning message is displayed and the rule is ignored. Depending on your other rules, this could prevent the configuration model from loading.
At runtime, if the end user selects the exterior color Red, then the above rule returns the interior colors Tan and Gray for selection because the value "Tan, Gray" of the Red Option's Interior Color Property contains the Interior Color Option Feature's Color Property values "Tan" and "Gray." Both a Tan and Gray interior are compatible with a Red exterior.
However, when the operands are reversed (Interior Color.Color CONTAINS Exterior Color.Interior Color) the rule tests whether the value of the Color Property of the Interior Color Feature contains the value of the Color Property of the Exterior Color Feature. At runtime, if the end user selects the interior color Tan, then there are no compatible exterior colors available.
The key concept with the CONTAINS relationship is that it does not work in both directions. The string "Tan, Gray" contains "Tan", but the string "Tan" does not contain the string "Tan, Gray".
When used with the Contains or Like operators, the percent sign and underscore characters act as "wildcards." The percent sign can represent zero or more characters, while the underscore represents a single character. For example, "Dia%" will find a match for any word that begins with "Dia", while "_eight" will find a match for both "Height" and "Weight".
For example, the rule AddressFeature.address Contains "De" is the same as AddressFeature.address Like %De%. Both rules find a match if the Property in Operand 1 contains "De".
The equals operator does not use the percent sign or underscore characters as wildcards. So, the rule AddressFeature.address = "Diam%" does not find a match if the Property in Operand 2 is Diameter; it finds a match only if the Property is "Diam%".
For an overview of Explicit Compatibility rules, see Explicit Compatibilities.
The following procedure assumes you have a Model open for editing.
To define an Explicit Compatibility Rule:
Navigate to the Rules area of the Workbench, and then click the icon in the Create column.
Choose a rule type of Explicit Compatibility, then click Continue.
Enter a Name and optionally a Description of the rule.
Click Choose Nodes to select the rule’s participants.
Select one or more Option Features, BOM Models, or BOM Option Classes, and then click Apply.
The Compatible Combinations table displays each node you selected in a separate column.
Use the cells of the table to specify compatible combinations of Feature Options, BOM Option Classes, and BOM Standard Items.
Click Add Another 5 Rows to define additional combinations.
The same option can appear in a column as many times as necessary to define the compatibility table you need.
Optionally specify a Violation Message, Unsatisfied Message, Effectivity, and Notes for the rule.
For more information about these settings, see Modifying Rule Details.
Click Apply or Apply and Create Another.
For an overview of Design Charts, see Introduction to Design Charts.
To define a Design Chart:
Go to the Rules area of the Workbench, and then click the icon in the Create column.
Choose a rule type of Design Chart, then click Continue.
Enter a Name and optionally a Description of the Design Chart.
Click Choose Primary Feature, and then select an Option Feature or BOM Option Class node.
Click Apply.
Click Add Defining Feature, and then select one or more Option Features or BOM Option Class nodes.
Note: There is no limit to how many Defining Features you can include in a Design Chart. However, Defining Features should always have a Minimum Selections = 0 or 1, and Maximum Selections = 1. This is because allowing the end user to choose more than one option from a Defining Feature can make it difficult to map choices to a particular Primary Feature selection.
Click Apply. A table row is automatically populated for each of the Defining Feature’s Options.
Configurator Developer populates the Design Chart table with a column for each of the Primary Feature’s options and a row for each of the Defining Feature’s options.
A Primary Feature must be defined before the table is saved and you can activate the compatibility cells.
Click Add Optional Feature and then select one or more Option Features or BOM Option Class nodes. There is no limit to how many Optional Features you can include in a Design Chart.
Click Apply.
Configurator Developer populates a table row for each of the Optional Feature’s options.
When the table contains all of the Defining and Optional Features, select the check box in the appropriate table cells to specify compatibilities between the Defining Feature options and the options of the Primary and Optional Features.
An Optional Feature Option can be compatible with multiple Primary Feature Options, and multiple Options of a given Optional Feature can be compatible with a given Primary Feature Option.
To remove an Optional Feature and all of its options from the table, click the icon in the Delete column.
You cannot delete individual Options from a Design Chart.
Click Validate Chart to ensure the rule’s definition is valid.
If a message indicates that the rule’s definition is invalid, modify its definition and then click Validate Chart again. Repeat this step until the rule’s definition is valid.
Optionally specify a Violation Message, Effectivity, and Notes for the rule.
For more information about these settings, see Modifying Rule Details.
Click Apply or Apply and Create Another.
For general information about this type of rule, seeOverview of Statement Rules.
The following procedure assumes you are have either performed the initial steps to create a new Statement Rule, or are converting a Logic, Numeric, Comparison, or Property-based Compatibility Rule into a Statement Rule. In other words, you are viewing a Statement Rule’s details page.
To define a Statement Rule:
Enter a Name and Description of the rule.
Enter the rule’s Definition using the Constraint Definition Language (CDL)
You can also add Model structure nodes as rule participants by clicking Choose Nodes. When you do this, the name of the node appears at the end of the rule’s definition.
For details about using CDL, as well as required syntax and validation criteria, see the overview of CDL elements, Oracle Configurator Constraint Definition Language Guide.
Click Validate Rule Text to ensure the rule’s syntax is correct.
Optionally define the following: Violation Message, Unsatisfied Message, Effectivity, and Notes.
For more information about these settings, see Modifying Rule Details.
Click Apply or Apply and Create Another.
For general information about Rule Sequences, seeIntroduction to Rule Sequences.
All rule types except Configurator Extensions can participate in a Rule Sequence. However, a Rule Sequence cannot contain another Rule Sequence.
To create a Rule Sequence:
Navigate to the Rules area of the Workbench, and then click the icon in the Create column.
Choose a rule type of Rule Sequence, then click Continue.
Enter a Name and optionally a Description, and then click Apply.
Add rules to the Rule Sequence.
There are two ways to add rules to a Rule Sequence. You can either create a new rule within the Rule Sequence, or add an existing rule to the Rule Sequence.
To create a new rule within a Rule Sequence:
In the same row as the Rule Sequence, click the icon in the Create column.
Select the type of rule to create, then click Continue.
Define the rule.
For details, see Defining Rules.
To add an existing rule to a Rule Sequence:
Select a rule.
You can move only one rule at a time into a Rule Sequence.
Select Move from the Actions list, and then click Go.
Select the Rule Sequence, and then click Apply. You might need to expand one or more rule Folders to be able to select the Rule Sequence.
Configurator Developer places the rule at the end of the sequence and sets it to Never Effective.
To modify the rule’s effective dates, click the icon in the Edit column.
For additional steps, see Effectivity.
Click Apply.
For an overview of Configurator Extensions, see Introduction to Configurator Extensions.
Before you can bind any Java methods to your Model, you must create a Configurator Extension Rule in which to define the bindings. The Configurator Extension Rule specifies the node and the Java class for which the binding will be defined.
Configurator Extension Rules have many of the same settings as other rules, and the procedure for defining them is similar. For general information about defining configuration rules, see Defining Rules.
To create a Configurator Extension Rule:
In the Main area of the Repository, locate the Model containing the node that you that you want to associate with a Configurator Extension and click the icon in the Edit column in the same row as the Model.
Navigate to the Rules area of the Workbench, and then click the icon in the Create column.
Choose a rule type of Configurator Extension, then click Continue.
Enter the Name and Description of the rule.
Optionally, you can click Disable to prevent the rule from operating.
Disabling a Configurator Extension Rule can be useful when the Java class for your Configurator Extension is not yet ready for testing. Otherwise, if you leave the rule unfinished, it will cause a runtime error when you test the Model.
Optionally, you can use the Effectivity section to set the effectivity of the rule.
See Effectivity for details.
Configurator Extension Rules do not have settings for a Violation or Unsatisfied Message. These messages should be generated by the Configurator Extension itself.
Associate the Configurator Extension Rule with a node in your Model. See Associating a Node.
A Configurator Extension must be associated with a node in your Model. This node determines the event binding scope, which is explained in Events.
In the Definition section of the rule, click Choose Node.
On the Choose Node page, select the node that you want to associate with the Configurator Extension.
You can associate Configurator Extensions with any type of node. The node must belong to the Model that contains your Configurator Extension Rule.
Click Apply.
You are returned to the Configurator Extension Rule page. In the Definition section, the name and path of the node you chose is displayed, identified by the label Model Node.
Now you can choose a Java class for the rule. See Choosing the Java Class.
A Configurator Extension Rule must specify the Java class that contains the method that implements the functionality for your Configurator Extension.
To choose a Java class for a Configurator Extension Rule:
In the Definition of the rule, click Choose Class.
On the Choose Class page, a table lists the Java classes that are available to the Configurator Extension Rule for use in a binding.
This list of bindable classes contains only the classes that are in the Archive Path of the current Model. The list of bindable classes consolidates all of the classes in all of the Configurator Extension Archives that are in the Archive Path of the current Model.
Note: Do not confuse the list of bindable classes for a Model, described here, with the list of classes in a Configurator Extension Archive. The latter is described in Viewing the Classes in an Archive.
If a class with the same name exists in more than one Configurator Extension Archive, Oracle Configurator loads the class that occurs first in the Archive Path.
For details on Configurator Extension Archives, see Configurator Extension Archives. For details on how to set the Archive Path, see Adding Archives to a Model’s Archive Path.
Expand the table to display the names of the Java classes.
Each Java class in the Archive is represented by a row in the table.
The package hierarchy of the bindable classes, if any, is represented by the hierarchy of the table. Each package is represented by a row in the table that includes a Focus control and a hide/show toggle. Click the hide/show toggle to view the next level of the package. To view the complete hierarchy of the archive, click Expand All. To narrow the focus of the view to a particular package, click its Focus control. To expand the focus again, click on a package name in locator links in the table heading.
If the archive also contains Java source files for the classes, their names are shown too, but they are not enabled for selection.
Select the class that you want to bind to the Model node that you chose.
When you have chosen a class, click Apply.
You are returned to the Configurator Extension Rule page. In the Definition, the name of the class you chose is displayed, identified by the label Java Class.
The class name is editable, so that you can enter the fully qualified name of a class that is in the class path of the host application. See The Archive Path for background.
If the Model Node that you chose is one that can be instantiated multiple times, then you must choose the instantiation scope for the Configurator Extension. Do this by choosing one of the options for Java Class Instantiation, which are described in the following table. See Introduction to Configurator Extensions for background.
| Option | Meaning |
|---|---|
| With Model Node Instance | The Configurator Extension is instantiated with each separate instance of the Model node. |
| With Model Node Instance Set | The Configurator Extension is instantiated once, with the entire set of instances of the Model node. |
If the Model Node that you chose cannot be instantiated multiple times, then no choice of instantiation scope is available. The Configurator Extension is instantiated at runtime with each separate instance of the Model node.
Now you can create an event binding for the rule. See Creating Event Bindings.
Once you have chosen a Java class from for the Configurator Extension Rule, you create one or more event bindings for the rule. See Events for background.
Creating an event binding consists of binding an event to a Java class method. The available events are predefined or custom. The available methods are contained in the Java classes accessed by the Model’s Archive Path.
To create one or more event bindings for a Configurator Extension Rule:
In the Definition of the rule, click Create Binding.
On the Add Event Binding page, the Event control lists the events to which you can bind a method of a Java class.
Choose the Event to which you want to bind the execution of the Java method.
See Predefined Events for Binding for a description of the available events.
If the event that you choose is a command event (onCommand), then the Command Name field appears.
In this field, type the character string that is the name of the command that you wrote your Configurator Extension’s Java method to handle. Do not enclose the string in quotation marks. The string can contain spaces.
The Event Scope control lists the event binding scopes that can be used to bind the event that you chose. Event binding scopes are described in Event Binding Scopes. The scopes that apply to each event are listed in Predefined Events for Binding.
Set the event scope for this binding, by choosing one of the options for Event Scope. The list of available scopes is restricted to those that apply to the chosen event.
A table lists the public Java methods contained in the class that you chose (as described in Choosing the Java Class). Each method is displayed with its parameters and their data types, as defined in the Java class. The arguments are automatically assigned names indicating their order in the method’s parameter list, such as Arg1, Arg2, and so on.
Select the Java method that is appropriate for the Configurator Extension functionality that you are defining.
Methods selected for Configurator Extensions cannot have names longer than 30 characters. If you want to use a method with a longer name, then the Java class must be modified and then included in a fresh version of your Configurator Extension Archive.
Click Continue.
Now you can proceed to bind arguments to the parameters of the Java method. To do this, see Binding Arguments to Parameters.
Note: After you have created a binding, you cannot modify its attributes. However, you can delete the binding and create another, to set the attributes as you require.
Once you have selected an event and a Java method, you bind each of the parameters of the method to arguments related to your configuration model. See Argument Binding for background.
On the Bind Method Arguments page, each argument of the method is represented by a row in the Argument Bindings table. The columns of this table are described in Elements of an Argument Binding. Configurator Developer generates this list of arguments by performing a Java introspection of the class, which is contained in a Configurator Extension Archive. See Configurator Extension Archives and Choosing the Java Class for background.
| Column | Meaning |
|---|---|
| Argument Type | The Java type of the argument (showing the package and class name), as specified in the definition of the method. Generated by introspection of the class. |
| Argument Name | The name of the Java argument specified in the definition of the method. |
| Argument Specification | The type of the argument being bound to the method parameter. These types are described in Parameter Types for Argument Specification. |
| Binding | The value that you are binding to the argument. The type of field presented here is determined by the type of Argument Specification. |
| Select Node or Property | If the Argument Specification is Model Node or Property, this control opens the Choose Node pages so that you can select one. |
To bind an argument to a method parameter:
Locate the desired argument in the Argument Bindings table. Each argument is identified by its Java type (in the Argument Type column) and its name (in the Argument Name column). The arguments have names that are automatically assigned to indicate their order in the method’s parameter list, such as Arg1, Arg2, and so on.
In the Argument Specification column, select the type of argument that you are binding to the parameter, from the following list:
These types are described in Parameter Types for Argument Specification.
In the Binding column, apply an option that applies to the type of Argument Specification you chose.
| For this Argument Specification ... | Choose This Type of Binding ... |
|---|---|
| System Parameter | Choose a system parameter from the options displayed. For descriptions, see Parameter Types for Argument Specification. |
| Event Parameter | Choose an event parameter. Only the event parameters for the selected event are displayed. For descriptions, see Predefined Events for Binding. |
| Model Node or Property | Click the Select Node control for this argument. On the resulting Choose Node page, expand the Model to locate the desired node. Select the desired node, then click Apply, which returns you to the Add Event Binding page. |
| Literal | Type an unquoted character string. |
The Java types of the parameters of your method must agree with the types of Model entities that are eligible for event binding. For a list of the Java classes that you can use in event bindings, see the Oracle Configurator Extensions and Interface Object Developer's Guide.
Repeat this process for each argument in the table. The order in which you bind the arguments is not significant.
Click Finish to complete the binding of the arguments. You can leave some arguments unbound, but doing so will cause errors when you generate logic, and at runtime.
You are returned to the Configurator Extension Rule page. Click Apply to finish your definition of this Configurator Extension Rule.
As with other configuration rules, after you create or modify a Configurator Extension Rule, you must generate logic before testing or using your configuration model. See Defining Rules and Logic Generation Status.
There are some special considerations when generating logic for Configurator Extensions:
If some part of the definition of a Configurator Extension Rule is omitted or invalid, then Configurator Developer produces warnings when you generate logic for the Model, and marks the Rule as invalid. During a configuration session, the runtime Oracle Configurator ignores this Configurator Extension.
The logic generation process does not examine the contents of Configurator Extension Archives. If you modify a Java class in a way that affects the definition of the Configurator Extension Rules that use that class (for example, to add a parameter to a method) and upload the changed Archive containing the class, then you must make corresponding changes to the affected Configurator Extension Rules. When you generate logic, Configurator Developer is not able to warn you about differences between the Java class and Configurator Extension Rules. During a configuration session, the Configurator Extension may fail.
For details about rule Folders, see Rule Folders.
To create a rule Folder:
Open a Model for editing, and then navigate to the Rules area of the Workbench.
In the same row as the Configuration Rules Folder or any user-defined rule Folder, click the icon in the Create column.
Select Folder, then click Continue.
Enter a Name and optionally a Description of the Folder.
Click Apply or Apply and Create Another.
You can delete a rule at any time as long as it resides within the Model that is open for editing (in other words, it cannot belong to a referenced Model). Deleting a Folder deletes all of the rules it contains
The following procedure assumes you have a Model open for editing.
To delete a rule or rule Folder:
Navigate to the Rules area of the Workbench and locate the rule or Folder you want to delete.
Select the rule or Folder, and then select Delete from the Actions list.
Click Yes to confirm the action.
The Actions list in the Rules area of the Workbench includes Copy, Move, Delete, Rename, Enable, and Disable. The procedures for copying, moving, deleting, and renaming rules are the same as for objects in the Main area of the Repository.
For details, see:
For more information about this procedure, see Enabling and Disabling Rules.
When you enable or disable a rule, be sure to generate logic before unit testing the configuration model. Generating logic is described in Logic Generation Status.
You can disable and enable all rules in a Folder by selecting the Folder and then choosing the appropriate action from the Actions list.
To enable or disable a rule:
Select the rule.
Select Enable or Disable from the Actions list.
Click Go.
Alternative method:
Open the rule for editing.
Select or deselect the Disable check box.
Click Apply.
When you change the order of rules in a Rule Sequence, Configurator Developer displays a message that tells you how the effective dates for each rule will be affected. You can then either make the change or cancel the operation. If you click Yes, Configurator Developer changes the effective dates of the rules. If you click No, the sequence of rules and their effective dates do not change.
For more information, see Reordering Rules and Rule Effective Dates.
The procedure below assumes you are working in the Rules area of the Workbench
To change the order of rules in a Rule Sequence:
In the same row as the Rule Sequence you want to modify, click the icon in the Edit column.
In the same row as a rule, click the icon in the Reorder column.
In the Move Rule page, select a rule, and then click either Move Rule Above or Move Rule Below.
Configurator Developer moves the rule to the new location in the Rule Sequence, and changes the effective dates of each rule as necessary.
Click Apply.
In the rule’s details page, click Apply.
You can remove rules from a Rule Sequence at any time by selecting Move from the Actions list, or by deleting the rule. If you want to keep the rule, be sure to move it out of the Rule Sequence, rather than deleting it. Deleting a rule from a Rule Sequence also deletes the rule from the configuration model. Additionally, use caution when deleting a Rule Sequence, as this also deletes all of the rules it contains from the configuration model.
When you move a rule out of a Rule Sequence, its effective dates do not change. However, Configurator Developer adjusts the effective dates of the remaining rules in the Rule Sequence so no gaps exist between them. Additionally:
To move a rule out of a Rule Sequence:
In the Rules area of the Workbench, expand the Rule Sequence.
Select the rule in the Rule Sequence, and then select Move from the Actions list.
Select the destination Folder for the rule, then click Apply.
To remove a rule from a Rule Sequence by deleting the rule:
In the Rules area of the Workbench, expand the Rule Sequence.
Select the rule to delete, and then select Delete from the Actions list.
Click Yes to confirm the deletion.
When unit testing a Model, you may want to enable or disable specific rules in a Rule Sequence to view the affect at runtime. You can also disable or enable all rules in a Rule Sequence simultaneously, depending on your needs. Any rules that are disabled are ignored at runtime.
Before viewing the affect of your changes in a runtime UI or the Model Debugger, be sure to regenerate logic. To do this, see Logic Generation Status.
To enable or disable only one rule in a Rule Sequence:
In the Rules area of the Workbench, expand the Rule Sequence and then select the rule.
Click the icon in the Edit column.
In the rule’s details page, select or deselect the Disable check box as appropriate.
To enable or disable all rules in a Rule Sequence:
In the Rules area of the Workbench, select the Rule Sequence.
Select Disable from the Actions list, and then click Go.
This section describes the settings and information that appears in a configuration rule’s details page. The following sections provide a description of each setting and indicate whether it applies to only specific types of rules, or all rules.
You can define Effectivity and enter Notes for any rule. For details, see:
This section is available for all rule types and describes the selected rule by listing its participants and operator, where applicable.
How you define a rule depends on its type. For details, refer to the following sections:
Use the settings in this section to enter text that appears when an end user makes a selection that violates the rule.
If you are viewing a rule’s details page, select one of the following:
Select Rule Name display only the name of the rule.
Select Rule Description to display the rule’s description.
Select Custom Text and then enter the text you want to display at runtime when the rule is violated. Choose this option to provide specific, detailed information so the end user understands why a selection is invalid and how best to proceed.
You can enter a custom violation message for any type of rule. For an example of how a custom violation message appears in a contradiction message at runtime, see Contradiction Message.
Note: If you are implementing Multiple Language Support (MLS), rule violation message text is stored in a database table so it can be translated more easily. For details, see Introduction to Multiple Language Support.
Use this section to define the message that appears when the rule is "unsatisfied" at runtime. You can specify an unsatisfied message only for Logic Rules and Comparison Rules. By default, Configurator Developer does not display a message when a rule is unsatisfied.
For more information, see Unsatisfied Rules and Creating an Unsatisfied Rule Message.
To create an Unsatisfied Rule Message:
In the rule’s details page, specify the information to display at runtime when the rule is unsatisfied. Select Nothing, Rule Name, Rule Description, or Custom Text.
Select Custom Text to enter detailed information about the rule, such as the available options that may cause it to be unsatisfied.
Click Apply.
These settings control whether a rule is active or ignored in a runtime UI, or when unit testing a configuration model using the Model Debugger. When you create a rule, its effectivity is set to Always Effective.
For general information about effectivity, see Introduction to Effectivity.
The following procedures assume you have a Model open for editing and are working in the Rules area of the Workbench.
To specify a range of effective dates for a rule:
Open the rule for editing.
In the Effectivity section of the rule’s details page, choose Explicit Dates from the Action list, and then click Go.
Select No Start Date or No End Date, or specify a From and To date and time.
You can specify a very wide range of dates when entering a start and end date, but this range is limited. For more information, see the Oracle Configurator Implementation Guide.
Click Apply.
To assign an Effectivity Set to a rule:
Open the rule for editing.
In the Effectivity section of the rule’s details page, select Choose Effectivity Set from the Action list, then click Go.
The Select Effectivity Set page lists all Effectivity Sets in the CZ schema.
Select an Effectivity Set, and then click Apply.
To assign a Usage to a rule:
Open the rule for editing.
In the Effectivity section of the rule’s details page, click Select Usage Exceptions.
Select the Usage(s) for which the rule is not effective, and then click Apply.
In the rule’s details page, click Apply.
For more information about Usages, see Introduction to Effectivity.