Runtime Behavior of the Fusion Configurator Engine

This chapter covers the following topics:

Domain Display and Availability

For background information, see Domain Ordering Setting.

As an Oracle Configurator end user makes selections that affect a node's specified domain, Oracle Configurator dynamically updates the domain range that is displayed in the UI. For example, if an Integer Feature's domain is set at 1-10 in Configurator Developer, then its range appears as 1-10 at runtime. If the end user or the propagation of a constraint makes a selection that cause the values 6-10 to be invalid, then the Feature's range changes to "1-5".

When a variable (node) is bound at runtime, its range no longer appears. This is true regardless of whether it was bound by the end user or by the propagation of a constraint.

Logic State Display

At runtime, distinctive icons appear in the Status column of the Configuration Summary page to identify end user selections, system selections (options selected by rule propagation), and Proposed selections (options selected either by a Default or by Search Decisions, or by Auto-Complete). Proposed selections have a logic state of Recommended (Proposed Selected).

Options may also be excluded from a configuration by Defaults or Search Decisions, or by Auto-Complete. These options have a logic state of Not Recommended (Proposed Excluded), and are also indicated by a distinctive icon during a runtime configuration session. For details, see Runtime Icons and Images.

See also Logic States and Selection State.

Runtime Configurator Flows and Behavior

This section describes end user actions and runtime behavior that is specific to FCE Models. It includes the following sections:

Auto-Complete Configuration

By default, UIs that you generate in Configurator Developer provide a button labeled Finish. Clicking this button in an FCE Model invokes Auto-Complete when the configuration:

Is incomplete
Does not contain any items that are invalid or require end-user input

When none of the options in the configuration require end-user input and the end user invokes Auto-Complete, the process applies all search decisions that you have defined in Configurator Developer, binds all variables in the configuration (except Text Features), and presents a completed configuration to the end user. For details about the page that appears when Auto-Complete finishes processing, see Auto-Complete Status Dialog.

After reviewing a configuration that was created by Auto-Complete, an end user can do one of the following:

Save the configuration and return to the host application (by clicking Finish)
Undo the results and continue making selections manually (by clicking Undo Auto-Complete)

See the Undo Auto-Complete action in User Interface Actions.
Modify the completed configuration (by clicking Return to Configuration, which places the user into Adjust Mode)

In order to perform the Undo Auto-Complete action, the configuration session must return True for one of the system properties AutoCompleteSuccessful or InAdjustMode.

It is also possible that Auto-Complete will be unable to find a solution. For details, see Aspects of Auto-Complete Behavior.

If an end user clicks Finish when one or more options in the configuration require end-user input, then Auto-Complete does not run. This can occur, for example, when the configuration contains a required Text Feature, which can only be bound by the end user. In this case, Oracle Configurator displays a message at the top of a page that contains at least one invalid or required option. After addressing all invalid or required options in the configuration, the end user can invoke Auto-Complete again, by clicking Finish.

When a configuration contains options that require end-user input, Oracle Configurator displays the Input Required Message Box by default. You can display different content by specifying a different UI Content Template for the Input Required on Finish setting in your UI Master Template (before creating the UI), or in the UI Definition (after creating the UI).

Important: To invoke Auto-Complete from a custom UI page, you must add a control that invokes the Auto-Complete UI action. For example, create a Custom Button and specify Auto-Complete Configuration as its associated UI action.

Aspects of Auto-Complete Behavior

There are aspects of the runtime behavior of Auto-Complete that may appear to be limitations to its ability to complete a configuration.

There may be some options in your Model that you have specified must be bound by the end user (see Require End-User Input Setting). If the end user clicks Finish (or invokes Auto-Complete using a custom UI control) when one or more options require end-user input but cannot be bound by Auto-Complete, Oracle Configurator displays a message listing those option(s). This behavior is by design, and is intrinsic to the capabilities of the FCE.
A blank Text Feature may exist in a completed configuration only when it does not require a value. Consider this behavior carefully if you use custom UI templates, and test the UI thoroughly to ensure that end users can manually create a complete configuration by entering values for all required blank Text Features. For more information, see Text Features.
It is possible that Auto-Complete will be unable to find a solution to the configuration problem. This can occur, for example, when a combination of Model Constraints and end-user selections prevents Auto-Complete from binding one or more variables. In this situation, Oracle Configurator displays a message suggesting that the end user modify some previous selections and then re-invoke Auto-Complete. The scenarios in which Auto-Complete may be unable to create a complete and valid configuration are described in Conflict Handling and Resolution.
For important information about Configurator Extensions and Auto-Complete, see Configurator Extensions.

Instance Management

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 for the FCE.

This section describes actions and behavior related to managing component instances at runtime.

When an end user is configuring an FCE Model, Oracle Configurator automatically may create one or more instances if additional instances are required to satisfy a constraint. For example, your company sells network servers and equipment racks that hold up to 5 servers. To ensure that enough instances of the Rack component exist in the configuration, you define the following Statement Rule:

rack.instanceCount() = ceiling(server.instanceCount() / 5)

At runtime, when the end user specifies 2 Servers, Oracle Configurator creates 1 instance of the Rack component. If the end user specifies 7 servers, then Oracle Configurator creates 2 Racks, and so on.

Other examples of when an instance may be created automatically include:

The minimum number of instances required is greater than the number of instances that currently exist in an Instance Set.
The Model contains a required Connector, but no potential target instance for that Connector exists in the configuration. (This is projected functionality.)

For more information, see Add Instance UI Action.

Terminology for Instance Management

The following terminology is related to instance management.

generic instance: A generic instance has no characteristics that identify it as being different from other instances of the same component. An instance that is added by Oracle Configurator and not yet configured or renamed is considered generic. The FCE's dynamic instantiation capability can generate generic instances in response to constraints that require their creation. Constraints can also prevent the user from deleting such required generic instances.
identifiable instance: An identifiable instance has an identity produced by some explicit end user action. An instance that is added, configured, or renamed by a user is considered to have an identity distinct from that of any other instances of the same component.
placeholder: A placeholder is a UI element indicating that an instance is required in that location, but that no identifiable instance has been specified for it. A placeholder usually represents a generic instance. (Under some circumstances, a placeholder represents no instance at all, but this distinction is not communicated to the end user.)

UI Actions in Instance Management Tables

For working with FCE Models, the UI templates named Instance Management Table and BOM Instance Management Table provide the actions described in the following table.

UI Actions in Instance Management Tables
Action	Description
Placeholder rows Note: This functionality is not a UI action, but is an essential complement to UI actions.	Placeholder rows represent required instances in the table. When a constraint increases (or decreases) the minimum number of instances of a component required in an instance set (its minimum cardinality), any additional instances that must be created to meet that minimum are represented by placeholder rows. Generic instances added to the Instance Management Table for a component are represented by placeholder rows, which are visually distinguished by the automatically generated label "[To be Configured]". When the user selects a placeholder and chooses the Configure action, the placeholder is replaced by an identifiable instance. Note: The Auto-Complete action changes placeholders into identifiable instances.
Add Instance	Adds an instance. The Add Instance action always results in an increase to the minimum cardinality, and does not replace any existing placeholder rows. If there are any existing candidate instances in the instance pool, the Instance Chooser is presented, allowing the user to select one of them to use, rather than creating a new instance. The Instance Chooser also provides a row labeled "[New Instance]"; selecting this row creates a new identifiable instance. If there are no candidates, then a new identifiable instance is created. If adding an instance causes a non-overridable conflict, then no instance is added, either generic or identifiable.
Copy Instance	Creates a copy of the selected instance and places it in the instance pool (thus making it available to the Instance Chooser). The instance copied into the instance pool is given a name of the form "Copy of component_name". If additional copies are made of the original instance, they are named with the form "Copy n of component_name", with incrementing values of n, to show the chronological order of the copies. The Copy Instance action is provided by an icon in the Copy column in the Instance Management Table UI templates that support Copy And Remove. The Copy icon is never displayed in placeholder rows, since no identifiable instance is there to be copied.
Configure Instance	Configures an instance. When this action is selected on a placeholder row, the placeholder is replaced with a new identifiable instance. This action maintains the cardinality of the instance set, by increasing the number of identifiable instances and equally decreasing the number of placeholders.
Delete Instance	Deletes an instance permanently, and also always reduces the cardinality of the set, leaving one or more fewer rows in the table, depending on the circumstances. Deleting a placeholder row only reduces the cardinality of the set, since there is no identifiable instance to delete.
Remove Instance	Removes an identifiable instance and replaces it with a placeholder row, but does not reduce the cardinality of the set. The removed instance is placed into the instance pool (thus making it available to the Instance Chooser). The Remove Instance action is provided by an icon in the Remove column in the Instance Management Table UI templates that support Copy And Remove. The Remove icon is never displayed in placeholder rows, since no identifiable instance is there to be removed.

The Unassigned Instance Pool

At runtime, it is possible for instances to be removed from an Instance Set and automatically put into a collection of unassigned instances. (In this context, "unassigned" means the instance does not belong to an Instance Set and it is not attached to a Connector.) This collection of unassigned instances is not visible to the end user and is known as the "instance pool."

An example of how an instance can become unassigned is when one configuration rule causes an instance to be created (or "contained") in an Instance Set, and the resolution of a conflict with another configuration rule overrides the containment, thus putting the instance into the instance pool, unassigned to any Instance Set.

Each instance in the instance pool can be added to another Instance Set later in the configuration session. An instance cannot be reassigned to the Instance Set from which it was removed (except in very rare circumstances). See Instance Chooser Page.

Unassigned instances may be also created in a Connector and then later added to an Instance Set. Additionally, only configured instances are displayed, which means instances that contain user inputs (including non-defaulted instance names), or instances that are connected to a component within the configuration. (Configured instances are also called identifiable instances.)

Default Instance Names

When configuring a Model that uses the Original Configurator Engine (Release 12.0 and earlier), a newly created instance is given an instance number based on its order of creation in a particular Instance Set. A default instance name is generated from this number along with the Display Name of the Component or Model Reference that represents the containing Instance Set. An instance cannot move from one Instance Set to another when using the Original Configurator Engine; therefore the default instance name and number are always similar to the containing Instance Set. However, this is not necessarily true when using the FCE.

When using the FCE, the name of all referenced Model instances defaults to the Display Name of the root node of the parent Model, appended with a 1-based ordinal number. For example, Hub Model-1, Hub Model-2, and so on. The name of each instance is unique throughout the configuration, rather than within the specific container, and it does not change as the instance's status changes within the configuration (for example, when it is assigned to another Instance Set or is attached to a Connector).

Oracle Configurator uses a similar convention when naming Component instances, but in this case the default name of each instance is derived from the Component name (this is the same behavior as the Original Configurator Engine). Similar to referenced Model instances, the ordinal number assigned to each instance is unique among all instances of the Component in the configuration.

Add Instance UI Action

This action enables the end user to add an instance of a component to an Instance Set. An end user can create a new instance only if the number of instances in the configuration has not yet reached the Maximum Instances specified in Oracle Configurator Developer, or the propagation of a rule has increased the Maximum Instance value specified in Configurator Developer.

If any unassigned instances of the same type exist in the instance pool when the end user invokes this action, Oracle Configurator displays the Instance Chooser Page. The end user can then select an existing instance from a list and add it to the Instance Set. (The term "instance pool" is defined in The Unassigned Instance Pool.)

If no instances of the same type exist in the instance pool when an end user invokes the Add Instance action, then the Instance Chooser Page does not appear and Oracle Configurator creates an entirely new instance.

By default, the Add Instance UI action is assigned to a button that appears in the Instance Management Table UI Content Template.

Add and Go To Instance UI Action

This action is similar to the Add Instance UI action, but Oracle Configurator navigates to the new instance immediately after the end user adds it to the Instance Set.

For more information, see Add Instance UI Action.

Create Instance UI Action

If the maximum number of instances allowed in the configuration has not been reached, then invoking this action creates a new instance of the specified component.

This action does not allow the end user to select an existing instance of the same type from the instance pool and add it to an Instance Set. See Add Instance UI Action.

Create and Go to Instance UI Action

This action is similar to the Create Instance UI action, but Oracle Configurator navigates to the new instance immediately after the end user creates it. See Create Instance UI Action.

BOM Instantiation and Selection

When an end user is configuring an FCE Model and creates an instance of a BOM Model, the new instance is selected (added to the configuration) automatically. In Models that use the Original Configurator Engine, the end user must manually select a newly created BOM Model instance to add it to the configuration.

Finish Configuration

If the configuration is incomplete and does not contain any items that are invalid or require end-user input, clicking the Finish button invokes Auto-Complete. If Auto-Complete finishes successfully, and the process does not change any of the orderable items, does create any new instances containing required Text Features, and causes no new validation failures to occur, then the completed configuration is displayed in the Configuration Summary page.

At this point, the end user can click:

Undo: Rolls back the changes made by Auto-Complete, returns the end user to the configuration
Return to Configuration: Keeps the changes made by Auto-Complete and returns the configuration session to edit mode so the end user can make changes
Finish: Saves and returns configuration data to the host application

Note: If the order has not yet been booked in the host application, then it is still possible for an end user to modify a configuration that was created by Auto-Complete. See Restoring a Completed Configuration.

If the configuration is incomplete but there are one or more items that are invalid or require end-user input, then by default Oracle Configurator displays the Input Required Message Box when the end user clicks the Finish button. This message lists one or more items that are invalid or require end-user input, and is displayed at the top of the first page in the UI (based on the UI's navigation sequence).

Tip: You can display a different message or UI Content Template in this situation by specifying a different UI Content Template for the Input Required on Finish setting. This setting is available in:

All UI Master Templates
The UI Definition

For example, you may want to display the Input Required Dialog Page or a custom message instead of the Input Required Message Box.

Conflict Handling and Resolution

In FCE Models, several types of conflicts can occur at runtime. The following sections describe each type:

User Request Conflict

A User Request Conflict occurs when an end user's action conflicts with the constraints defined in the Model. By default, the consequences of overriding this type of conflict appear in the User Request Conflict Dialog Page.

When a User Request Conflict occurs, the end user can do one of the following:

Override: When possible, this action applies the end user's request and removes all conflicting requests. Some requests are not overridable.

For details, see Auto-Override.
Cancel: This action withdraws the request that caused the conflict, and returns the end user to the configuration.

Note: A User Request Conflict is similar to an overridable contradiction, which is a type of conflict that can occur when using the Original Configurator Engine. For details, see the Oracle Configurator Developer User's Guide.

Auto-Override

When a User Request Conflict occurs at runtime, Oracle Configurator displays the User Request Conflict Dialog Page. If Auto-Override is enabled, then this message displays the consequences of overriding the conflict. In this case, the end user can either override the conflict by clicking OK and return to the page where the conflict occurred, or click Cancel to undo the action that caused the conflict.

If Auto-Override is disabled, the end user must either click Continue to view additional information about how to resolve the conflict, or click Cancel to undo the action that caused the conflict. If the end user clicks Continue, Oracle Configurator displays the Confirm Override Dialog Page.

The Enable Auto-Override for Conflicts setting is available in all UI Master Templates, and it is enabled by default.

Note: This setting is available only if the profile option CZ: Enable Configurator Engine is set to either Both or Fusion.

Hidden Conflict

A Hidden Conflict occurs when Oracle Configurator is processing an end user's request, but the conflict is not caused by the request itself. This type of conflict is caused by an internal mechanism of the FCE that controls the assignment of instances to an Instance Set or to a Connector, and it is triggered when an end user's request is removed. For example, when the user clears a numeric value, deselects a prior selection, or modifies a numeric value or selection (which causes the old value or selection to be removed as an interim step).

Because the difference between a Hidden Conflict and a User Request Conflict is not obvious to the end user, and since the options for resolving each type of conflict are the same, Oracle Configurator displays the User Request Conflict Dialog Page when a Hidden Conflict occurs.

Fundamental Conflict

A Fundamental Conflict results when the root Model, one of its child Models, or a Component, is overconstrained. This means that no valid solution can be found using the constraints as they are currently defined in the Model. To resolve a Fundamental Conflict, you must modify the constraints for the component that caused the conflict in Configurator Developer, and then retest the Model.

Good model development practice requires that a Fundamental Conflict should be detected during system testing, and resolved before deployment of your application. This type of conflict, if it occurs at runtime, requires an end user to either exit the configuration, or continue without including the component that caused the conflict.

If the conflict exists in the root model or one of its required child Models, the Fundamental Conflict message appears when you attempt to unit test a configuration model from Configurator Developer. See Fundamental Conflict Message. In this case, Oracle Configurator does not initialize the unit testing session and you return to Configurator Developer.

If the problem exists in an optional component, it is possible launch a unit testing session successfully, but the User Request Conflict Dialog Page appears when the conflict occurs (for example, when you select or choose to configure the optional component). In this case, the end user will be able to continue, but the component that caused the conflict will not be included in the configuration. See User Request Conflict Dialog Page.

Fundamental Conflicts are easily detected when unit testing a Model from Configurator Developer. Therefore, it is unlikely that an overconstrained Model would ever be deployed in a production environment.

Restoring a Completed Configuration

When an end user restores a completed configuration, all of the selections and values from the original session are retained and the end user can navigate the configuration, select or deselect options, and change values. This is true regardless of whether Auto-Complete was invoked during the configuration session. An end user can also restore configurations that were created before a Model was converted to an FCE Model.

In a restored configuration, any instances that existed in the instance pool from the original configuration session are no longer available. This is because Oracle Configurator purges all instances in the pool when the end user saves the original configuration. For more information about the instance pool, see The Unassigned Instance Pool.

A restored configuration opens in a default state that is the equivalent of Adjust Mode, so it does not include an Undo Auto-Complete button. This button appears by default only in the Auto-Complete Status Dialog, which is displayed after Auto-Complete completes successfully.

Procedure

If you want end users to be able to return a configuration to the state it was in before running Auto-Complete, then perform the following before publishing the Model:

Open the UI for editing in Configurator Developer.
Create a UI control, such as a button, on the UI's first page. (Which page appears first at runtime depends on the UI's primary navigation style.)
In the UI control's details page:
- Assign the Undo Auto-Complete UI action.
- Define a display condition that uses the InAdjustMode System Property.
  
  For example:
```
Object: Session Data 
Property: InAdjustMode 
Comparison: Is Condition: True
```
Click Apply.

The UI control created in this example appears only when an end user is modifying a restored configuration.