This chapter covers the following topics:
Effectivity allows you to model a product that changes over time. The effectivity you assign to Model nodes and rules determines whether a node is available or a rule is active in a runtime Oracle Configurator, or when unit testing a configuration model from Configurator Developer. Oracle Configurator and Oracle Configurator Developer use the database date and time when evaluating an object’s effectivity.
You control effectivity for a node or rule in Configurator Developer by indicating that it is either Always Effective or Never Effective, or by specifying either a date range or an Effectivity Set (see Effectivity Sets). You can also optionally assign one or more Usages to control effectivity of structure nodes and rules (see Usages).
The root node of a Model is always effective, and its Effectivity settings are read-only. The Effectivity settings on a BOM Model References are also read-only because they are imported with the BOM Model. However, you can modify the effectivity on a Reference to a non-imported Model. For more information about Model References, see Introduction to References.
Note: When you populate the CZ schema with BOM data, the effective dates defined for each BOM item in Oracle Bills of Material are also imported. Like other imported data, this information is read-only in Configurator Developer. Additionally, you cannot assign an Effectivity Set or specify a Usage to imported BOM nodes.
Tip: Oracle recommends that you end-date BOM items rather than deleting them. You end-date an item by setting its effective dates in Oracle Bills of Materials. The effectivity of the BOM Item in Configurator is updated when the item's BOM Model is imported or refreshed. If you delete an item from a BOM model after it has been imported to Configurator, then the corresponding BOM Item in Configurator is deleted when you refresh the BOM Model, and you must update any configuration rules that use the BOM Item as a participant.
Defining effectivity for a Model node is explained in Effectivity. Defining effectivity for a rule is explained in Effectivity.
Effectivity also controls the availability of a Model publication to host applications. The application that is hosting the runtime Oracle Configurator specifies the date, time, and a Usage in an initialization message (for details about the initialization message, see the Oracle Configurator Implementation Guide). All nodes that are not effective when the Model is invoked do not appear in the runtime UI, and all configuration rules that are not effective are ignored. However, it is important to note that ineffective Model nodes that have logic state (that is, Options, Option Features, all BOM nodes, and Boolean Features) are False at runtime. If such an ineffective node participates in a rule that is effective, it participates with a False logic state. For more information, see Configuration Rules and Logic State.
For important information about the behavior of ineffective Model nodes and their associated UI elements in a customized UI, see the note in Runtime Conditions and User Interface Elements.
For details about effectivity and publishing, see Applicability Parameters.
To specify effectivity when unit testing a configuration model using the Model Debugger or a runtime User Interface, see Introduction to Unit Testing .
To control whether ineffective Model structure nodes and rules are displayed when working in Configurator Developer, use the Effectivity Date Filter setting. For details, see Effectivity Date Filter.
The effectivity for imported BOM nodes is defined as a date range in Oracle Bills of Material, and cannot be changed in Configurator Developer.
You can specify an effective date range for a rule or any node created in Configurator Developer. A date range may include both a start date and an end date (day, month and year) and time (hours, minutes, and AM or PM), or you can select either No Start Date or No End Date. (Selecting both No Start Date and No End Date is the same as selecting Always Effective).
To specify an effective date range for a node or rule, see Effectivity.
Create an Effectivity Set to define an effectivity date range that can be shared by many Model structure nodes and configuration rules simultaneously. When you modify an Effectivity Set’s date range, the change affects all nodes and rules that are assigned to the Effectivity Set. Therefore, if you expect to use a specific effectivity date range for more than a very limited number of nodes, it is better to define and assign an Effectivity Set rather than specifying an effective date range for each node and rule in your Model.
You can assign Effectivity Sets to rules, Components, Features, Options, Totals, Resources, Model publications and References to non-imported Models. The effectivity assigned to imported BOM nodes is read-only in Configurator Developer, and can be changed only in Oracle Bills of Material.
An Effectivity Set can be always effective, never effective, or effective only within the range of dates that you specify.
You can also assign an Effectivity Set to rules that are part of a Rule Sequence. See Rule Sequences and Effectivity Sets .
See Creating an Effectivity Set.
Like effective dates and Effectivity Sets, Usages provide a method of controlling the effectivity of Model structure, rules, and the availability of Model publications to a host application. A host application may pass a Usage as a parameter in its initialization message, but it is not required. You can assign Usages independently or in addition to date effectivity (in other words, either an explicit date range or an Effectivity Set).
Usages consist of any text string that you specify, and you create them in the Main area of the Repository. You can create a maximum of 64 Usages.
By default, all Model structure nodes and any rules that you define are effective for all Usages. Setting a Usage on a node or rule means that it is effective for all Usages except the Usage(s) that you specify.
For example, Component A and Logic Rule X are effective for all Usages except the Usage called "Experienced User." At runtime, Oracle Order Management specifies this Usage in the initialization message. As a result, Component A does not appear in the UI and Logic Rule X is ignored.
Usages are a powerful tool for manipulating the effectivity of Model structure, rules, and Model publications based on a variety of business requirements. Therefore, be sure to plan for and implement Usages very carefully when developing configuration models. For example, it is not advisable to assign a Usage on a Reference to a required BOM Model because the item will not be available when the host application passes the Usage at runtime.
For an example of how you can use Usages to limit the effectivity of Model structure, rules, and Model publications, see the Oracle Configurator Implementation Guide.
If you are implementing Multiple Language Support (MLS), you can enter alternate translations for a Usage’s description. For details, see Translatable Usage Descriptions.
To create a Usage, see Creating a Usage.
To make a node ineffective for a specific Usage, see Modifying Effectivity.
To make a rule ineffective for a specific Usage, see Modifying a Rule's Effectivity.
Important: If you have published one or more Models that use Usages, do not rename Usages in Configurator Developer. Renaming a Usage that is in use with a published Model can cause the publication source instance to have a different Usage name than the publication target instance.
Effectivity is typically used when unit testing a configuration model in a generated UI or the Model Debugger, or in a deployed Oracle Configurator in a production environment. However, you can also hide ineffective Model structure nodes and rules when building a configuration model in Configurator Developer.
The Effectivity Date Filter setting in the Configurator Developer Preferences page controls whether Configurator Developer considers effectivity when displaying Model structure nodes and rules. For more information, see Effectivity Date Filter.
Following are some examples of how effectivity affects a configuration model in a runtime Oracle Configurator or when unit testing from Configurator Developer:
Model structure nodes that are not effective do not appear, and therefore are not available for selection.
For example, a specific item in the Model will be obsolete as of May 1, 2004. You want to automatically discontinue that item as of that date so it will not be offered as an option to your end users. By specifying an effective end date of 05/01/2004 for the item, it no longer appears in the configuration model on that date or in any future configuration sessions.
Configuration rules that are not effective are ignored (do not propagate) at runtime.
For example, your configuration model contains a Logic Rule that selects several options based on a guided buying or selling question. However, several of these options will not be available (are no longer effective) after the end of the fiscal year. You define effectivity for the rule so it is ignored as of the date you specify. This prevents your end users from seeing any unnecessary warnings or error messages that may appear because some items are unavailable.
Rules that contain ineffective participants may be unable to perform their intended actions at runtime.
For example, your Model is an air compressor which includes a compression gauge and feeder hose as selectable options. You define a Logic Rule that automatically selects a compression gauge when the end user selects a feeder hose. However, when an end user configures the Model, the compression gauge is unavailable due to its effectivity. In this case, the rule is triggered when the end user selects the feeder hose, but Oracle Configurator displays a message informing the end user that the compression gauge is not available.
For an example of how to implement Usages in a configuration model, see the Oracle Configurator Implementation Guide.
Configurator Developer always displays dates and times according to the time zone that you specify in the Preferences page. This is typically your local time zone. The settings on this page are described in Preferences.
All dates that you enter and that appear in Configurator Developer are stored in the time zone of the database on which Configurator Developer is running, and this might not be the same as your local time zone. (The default client and server time zones are controlled by Oracle Applications profile options. For details, see the Oracle E-Business Suite System Administrator’s Guide.)
For example, your business maintains a Wide Area Network (WAN). This enables you to work in New York while running Configurator Developer on a database that is physically located in California. In this case, the date and time you enter in Configurator Developer appears in Eastern Standard Time (EST). However, it is converted to Pacific Standard Time (PST) and is stored in the database this way (that is, 3 hours earlier than EST).
Dates and times are converted to the server’s time zone because all configuration model data and Model publications are also stored in the database (this includes pricing information and Available to Promise dates). When an end user launches Oracle Configurator, the host application selects a publication and applies effectivity based on the server’s time zone, rather than the end user’s time zone.
All dates that are visible or are entered in Configurator Developer appear in your local time zone, including:
Creation and modification dates for Models, rules, and UIs.
Effectivity start and end dates (and times) for Model structure nodes and rules.
Publication dates, which include the start and end applicability dates, the date when the publication was created, and so on.
Effective date and time when launching the Model Debugger or a generated User Interface.
Date and times that you specify when defining a Rule Sequence.