This chapter describes at a high level the main features and benefits of the FCE. The remainder of this document describes the various settings that enable you to build FCE Models in Configurator Developer, how to convert existing Models to FCE Models, and the general behavior of FCE Models in a runtime Oracle Configurator.
This chapter covers the following topics:
The Fusion Configurator Engine (FCE) is written in the Java programming language and is based on Constraint Programming technology. In the constraint-based programming paradigm, relations between variables can be stated by defining constraints. Constraints specify the characteristics of a desirable solution to a configuration problem, rather than a step or sequence of steps that must be executed to create such a solution. After a user makes selections, the FCE automatically finds a solution that includes the user's selections and satisfies all of the constraints.
Compared to Models that use the Original Configurator Engine (OCE), FCE Models provide a greater degree of guidance in a runtime User Interface. This helps Oracle Configurator end users make better, more educated choices, resulting in fewer errors and allowing products to be configured more quickly.
FCE Models also enable end users to complete a configuration automatically using preferences that you define in Oracle Configurator Developer. These preferences consist of Defaults and Search Decisions, and are described in more detail in Rule Classes.
The benefits of using the FCE and leveraging its constraint-based technology include reduced time spent developing configuration models, the ability to lead end users to the Modeler's preferred solution, and a product architecture that is easier to maintain.
Note: The Telecommunications Services Ordering (TSO) functionality is not available in the current release of the Fusion Configurator Engine. For information about TSO in previous releases, see the Oracle Telecommunications Service Ordering Process Guide.
Important: Connectors are not supported in the current release of the Fusion Configurator Engine. The information about Connectors provided in this document is only for planning purposes. However, Connectors continue to be supported for models using the Original Configurator Engine.
This section describes functionality related to configuration rules that is available only when using the FCE.
When using the FCE, you can:
Classify configuration rules as Constraints, Defaults (also called soft constraints), or Search Decisions.
For details, see Rule Classes.
Specify the order in which Oracle Configurator evaluates rules that are defined as Defaults or Search Decisions.
For details, see Specifying a Sequence for Defaults and Search Decisions.
Control the relative and absolute quantity of a BOM Model node by defining constraints in Configurator Developer.
Define a rule that requires an end user to connect an optional Connector, or prevents a Connector from being connected.
For details, see the examples using the System Property ConnectionCount under Model Node System Properties and Connectors and Configuration Rules.
Define rules that control how many instances of a component can be created at runtime.
For details, see the examples using the System Property InstanceCount under Model Node System Properties and Instance Management.
Define Accumulator Rules, which add or subtract a value from a variable at runtime, and which replace Numeric Rules.
For details, see Accumulator Rules.
Define rules that specify default values for Numeric Features, Boolean Features, Totals, and Resources.
See Initial Values.
Important: See Oracle Configurator Release Notes, Release 12.1.1 on the Oracle Support Web site for background on important enhancements and changes to runtime instance management.
This following are true at runtime in FCE Models that support instantiation:
Instances can be created automatically to satisfy a constraint. This is called dynamic instantiation.
For example, an instance may be created when no target instance exists for a required Connector, or when the minimum instances setting on an Instance Set is increased.
(In the OCE, instances can only be created by the end user or by a Configurator Extension (CX).)
An end user can remove an instance from an Instance Set without deleting it from the configuration.
An end user can add an existing instance to an Instance Set, rather than creating an entirely new instance. See The Unassigned Instance Pool for background.
An end user can copy an instance in an Instance Set and later add it to a set of the same type.
For details, and examples using the System Property InstanceCount, see Model Node System Properties and Instance Management.
An important feature of the Fusion Configurator Engine is the ability to complete a configuration automatically. This process, which end users can invoke at runtime by clicking the Finish button, is known as Auto-Complete. Auto-Complete is useful, for example, when end users care only about a subset of all available items and want to quickly create a valid and complete configuration. In this case, end users can manually provide the inputs that they care about, supply any inputs that are explicitly required by the Model definition, and then allow Auto-Complete to complete the configuration. After examining the result of Auto-Complete, the end user can save and exit, or make further changes before exiting. Details about how the process functions at runtime are explained in Auto-Complete Configuration.
When an Oracle Configurator end user invokes Auto-Complete, the FCE searches for a solution to the current configuration problem by providing inputs of the appropriate type for all unbound variables in the configuration and applying requirements and (optionally) preferences that you define for the Model in Configurator Developer.
Requirements, which must be satisfied for a complete solution, are necessary for Auto-Complete to bind the variables. You define requirements by defining rules with an associated Rule Class of Constraint.
Preferences, which can be unsatisfied in a complete solution, are not necessary for Auto-Complete to bind the variables, but enable you to shape the final solution in a given direction. You define preferences by:
Defining rules with an associated Rule Class of Default or Search Decision
Indicating how you want Auto-Complete to provide values for unbound Numeric and Boolean Features (see Domain Ordering Setting)
Specifying minimum and maximum values for all Model nodes (see Tip, below).
Tip: For optimal performance of the Auto-Complete process, Oracle strongly recommends narrowing the domains to be searched. To narrow the search domains, set maximums as low as possible and minimums as high as possible for the following node types: Numeric Features, Totals, and Resources (set the values); instantiable Components and Model References (set the number of instances); Option Features (set the number of selections); BOM components (set the quantities, in Oracle Bills of Material).
The term "variable" is used in this document to refer to any item that must be bound; that is, that requires selection or a value at runtime. For example, a BOM Option Class that requires at least one of its children to be selected, or a Numeric Feature that requires a value. A variable is bound when it is selected or excluded (or a value is entered) by the end user, the propagation of a rule, or the Auto-Complete process. A configuration is not complete until all variables are bound.
Note: Text Features are the only type of variable that Auto-Complete cannot bind. For details, see Aspects of Auto-Complete Behavior.
Other examples of variables include:
Boolean Feature: This type of node is bound at runtime when its domain is reduced to a single value (true or false).
Note: The term "domain" is explained in Domain Ordering Setting.
Option Feature: This type of node is bound at runtime when its Selection Count is reduced to a single value that is equal to the number of selected options.
For example, OF1 has a Minimum and Maximum Selections of 1 and 4, respectively. At runtime, the valid input range (domain) for OF1 is 1 - 4. If the end user selects two options, OF1 is not yet bound, but its input range changes to 2 - 4. If the end user selects two more options, OF1 is bound because its Selection Count equals the number of selected options.
See SelectedCount.
Instance Set: An Instance Set is bound at runtime when its Instance Count is reduced to a single value that is equal to the number of instances in the set.
The InstanceCount System Property is described in the Oracle Configurator Developer User's Guide.
Connector: This type of node is bound at runtime when its number of connections is reduced to a single value that is equal to its Connection Count.
See ConnectionCount.
This section lists additional FCE functionality and describes several known limitations of the Original Configurator Engine that do not exist in FCE Models.
You can require end-users to explicitly enter a value for a Numeric or Text Feature. (The OCE allows you to require input, but only for Text Features.)
For details, see Require End-User Input Setting.
The range defined for a Resource in Configurator Developer is enforced at runtime. In other words, an end user's actions cannot cause a Resource to become "over-consumed."
For details, see Totals and Resources.
At runtime, Connectors can be bi-directional and may allow multiple connections.
For details, see Connectors.
The FCE provides the following enhancements in the areas of performance and usability:
Improved modeling techniques: The ability to specify a preferred order for executing Search Decisions and Defaults makes it easier to design and build configuration models that meet your needs.
See Specifying a Sequence for Defaults and Search Decisions.
Reduced Model maintenance: FCE Models provide more predictable behavior than the Original Configurator Engine, making it easier to debug model design and runtime issues.
Additionally, the FCE's ability to automatically create component instances, complete a configuration, and perform complex defaulting greatly reduces the need for Configurator Extensions.
Improved end-user experience: End users can see the valid input range for Numeric inputs (which results in fewer contradictions) and can allow Oracle Configurator to complete a configuration automatically. As a result, your end users can create complete and valid configurations much more quickly, with fewer errors.
See Auto-Complete.
This section lists known issues and limitations of Models that use the Original Configurator Engine that do not exist in FCE Models.
NotTrue Logical Function: The use of the NotTrue operator in Models that use the Original Configurator Engine imposes an order for rule propagation that causes configuration models to be more difficult to design and use, and may result in a "locked" state for the initial values of some items. In FCE Models, these problems do not exist because items in the configuration can never be "Unknown" and all items are bound eventually. In other words, rules that the FCE supports are never based upon the condition that an argument within a rule is unknown. Thus, the NotTrue operator is not necessary, and is therefore not available for use in FCE Models.
When you convert an existing Model to use the FCE, each occurrence of the NotTrue operator changes to NOT. To achieve behavior similar to the NotTrue operator when creating rules in an FCE Model, use the NOT operator.
Numeric Rules: In Models that use the Original Configurator Engine, Numeric Rules can "push" (propagate) only one way: from the Operand A side of the rule to the Operand B side of the rule.
In an FCE Model, Numeric constraints propagate in both directions.
For example, a Model contains IntegerFeatureX, which has Minimum and Maximum Values of 0 and 20, respectively. The Model also contains the following rule:
(IntegerFeatureX > 10) REQUIRES BooleanFeatureY
In a Model that uses the Original Configurator Engine, selecting or deselecting BooleanFeatureY does not cause IntegerFeatureX to have a value greater than 10; in fact, the action has no effect on IntegerFeatureX at all.
In an FCE Model, selecting BooleanFeatureY changes the domain of IntegerFeatureX to '11 to 20' (this range is visible to the end user at runtime). If the end user then deselects BooleanFeatureY, the domain of IntegerFeatureX changes to '0 to 10'.
Comparison Rules and Intermediate Values: When configuring a Model that uses the Original Configurator Engine, it is possible for unexpected contradictions to occur due to the use of intermediate values with Comparison Rules. This limitation is described in detail in the Oracle Configurator Modeling Guide (part number B13605-03). It is not possible for this scenario to occur in an FCE Model, since the FCE and the Original Configurator Engine propagate rules very differently.
Repetitive Rule Patterns, Redundancy, and Circular Propagation (Numeric Cycles): For details about each issue, see the Oracle Configurator Modeling Guide (part number B13605-03).
Due to the manner in which rules propagate in the FCE, none of these problems can occur in an FCE Model.
Optional Connectors: In Models that use the Original Configurator Engine, optional Connectors cannot participate in Logic Rules. This is not the case in an FCE Model.
Modifying a Feature's Minimum and Maximum at Runtime: In a Model that uses the Original Configurator Engine, you cannot create rules that dynamically change a Feature's Minimum and Maximum number of selections. You can create this type of rule in an FCE Model.
BOM Internal Quantity Computation and Visibility: In Models that use the Original Configurator Engine, the parent node is not updated when a Numeric Rule changes the child BOM node's internal quantity, and the end user is not informed of the error.
In FCE Models, the quantity relationship between a parent BOM node and its children is always maintained when the quantity of the parent or child is modified at runtime (this is true whether the value is changed by the propagation of a rule or by the end user).