This chapter covers the following topics:
The General area of the Workbench appears when you open a Model for editing or viewing from the Main area of the Repository. This area of the Workbench displays general information about the selected Model and allows you to perform Model-specific operations such as generating logic, refreshing User Interfaces, editing Configurator Extension Archive Paths, creating a Model Report, and running Populators.
To modify the Model’s structure, rules, or UIs, navigate to the appropriate area of the Workbench by clicking the corresponding link at the top of the page.
Generate a Model Report to create a portable document format (PDF) file containing detailed information about a configuration model. When submitting the report, you specify whether it includes details about the Model structure, User Properties, rules, Item Master data, and any referenced Models. You can generate and print a Model Report at any time during the configuration model development process.
You must have Oracle XML Publisher installed at your site to generate a Model Report. This is because Configurator Developer uses Oracle XML Publisher to generate and format the report’s content.
To generate a Model Report:
Open a Model for editing.
In the General area of the Workbench, click Model Report.
In the Report Contents page, specify the data you want to include in the report. Choose from the following:
Model Structure: Select Include to include details about the Model structure in the report. Otherwise, select Exclude. For details, see Model Report Content and Column Headings.
Deselect Include Property Data to exclude the names and values of any User Properties from the report.
Rules: Select Include All to include all rules in the Model, or select Include if Enabled to include only rules that are currently enabled.
Select Exclude if you do not want the report to provide details about any of the Model’s rules.
Item Master: Choose whether to include Item Master data for the Model, or for the entire Repository (that is, the CZ schema).
Select Exclude if you do not want the report to include any Item Master data.
Note: The report may take a long time to complete if you include Item Master data for the entire Repository. You may want to generate a separate report that includes only Item Master data.
Deselect Include Property Data if you do not want to list the names and values of any associated User Properties.
Referenced Model Data: Indicate whether the report criteria also applies to all of the Model’s referenced (child) Models.
For example, if you chose to include details about Model structure and rules, the report also contains details about the Model structure and rules for each referenced Model.
When you are satisfied with the report criteria, click Generate Report.
When the report is complete, a link appears at the bottom of the page. Click this link and then choose whether to save the report locally (as a PDF file), or open it using Adobe Acrobat.
Important: Oracle Configurator Developer does not automatically save Model Reports for future reference. Oracle recommends that you save reports locally so you will not have to generate them multiple times.
A Model Report displays information in several sections that correspond to the criteria you specified when submitting the report. Within each section, the configuration model data appears in separate tables for the Model structure, Properties, rules, and Item Master data.
An empty table cell indicates that either the value does not apply to a specific node, or no value exists.
This section appears if you chose to include Model Structure when defining the report’s content.
This section contains two sub-sections: Model Hierarchy View and Model Detail Views. The Model Hierarchy View lists only the root parent node and its children, which includes Components and referenced Models. The table in the Model Detail Views section also lists each Component and referenced Model, but shows all of their child nodes. This view is similar to viewing the Model structure in Configurator Developer when it is fully expanded. In other words, it contains details about all nodes in the Model, including BOM Option Classes, BOM Standard Items, Features, Options, and so on.
Following is a description of the various column headings that appear in the Model Structure section:
Level: The level at which the node appears in the Model structure. The root Model node is level 1, the root node’s children are level 2, and so on.
Node Name: For details, see Name.
Description: The node’s description. See Description.
Type: The node’s type. For details, see Introduction to Model Structure.
Instances: The values in this column reflect the Instantiability settings defined for a Model Reference or Component node. For details, see Instances.
Quantity: For BOM items, the Quantity column displays the node’s minimum and maximum quantity. For example, "1/3" means a minimum quantity of 1 and a maximum quantity of 3. For details, see Quantity Cascade Calculations.
For non-BOM items, this column refers to the Minimum and Maximum Selections values for an Option Feature, and the Minimum and Maximum values for Decimal and Integer Features.
Initial Value: Initial values are explained in Initial Values.
Properties: This column lists the name and value of all User Properties assigned to each node (if you chose to include Property data in the report).
For details, see User Properties.
This section appears only if you chose to include Item Master data when defining the report’s content.
This section lists the name and description of each Item Type and Item used in the Model, or in the Repository (depending on the report criteria). It also displays the User Properties assigned to each Item Type and Item, if you chose to include Properties in the report.
For details about Item Types and Items, see Introduction to the CZ Schema.
This section appears if you chose to include rules when defining the report’s content.
This section contains two main sections: Folder Hierarchy View and Rule Folder Views. The Folder Hierarchy View section displays the names and descriptions of all of the Model’s Rule Folders and, if you chose to include referenced Model data, any referenced Model Rule Folders.
A "1" in the Level column indicates that the Folder is a top level Folder for either the parent Model or a referenced Model. Levels 2, 3, and so on indicate sub-Folders.
The Rule Folder Views section provides details about each Rule Folder listed in the Folder Hierarchy View, such as the rules that each Folder contains and each rule’s name, type, and definition. All rules or only enabled rules may be included, depending on the criteria you specified when submitting the report.
The rule definitions for Logic, Numeric, Property-based Compatibility Rules appear in the Rule Text column, and are displayed in the Constraint Definition Language (CDL).
Because Explicit Compatibility Rules and Design Charts cannot be expressed in CDL, their definitions appear separately, in tabular format. Functional Companions and Configurator Extensions are also displayed in a separate table.
For details about CDL, see the overview of the Constraint Definition Language, Oracle Configurator Constraint Definition Language Guide.
This section lists the Configurator Developer user who created the selected Model, and the date the Model was originally created. It also indicates when any part of the Model was last modified, and the Configurator Developer user who made the changes.
If the selected Model is a BOM Model, or is a non-imported Model that references a BOM Model, the Product Key is read-only, and consists of the BOM Model’s Oracle Inventory Item ID followed by its Inventory Organization ID. For example, 452:1534.If the selected Model was created in Developer, or was imported from a source other than Oracle Bills of Material, and does not contain any BOM Models, you can enter or modify the Product Key by clicking Edit Details.
To modify the Model name, description, or related notes, click Edit Details. To open the Model for editing, navigate to the Structure area of the Workbench.
If the selected Model is an imported BOM Model, this section lists information about the Oracle Inventory Item on which the Model is based. If a responsibility that provides access to Item Management is assigned to your Oracle Applications user name, you can navigate to Item Management to view additional details about the Item in that application.
For example, if Item Manager is one of the responsibilities that is assigned to your user name, you can click the button provided to navigate to Item Management.
For more information about Item Management, refer to Oracle Item Management documentation.
If the Model you are viewing was imported from Oracle Bills of Material, this section indicates the last time the BOM Model data was updated. You must refresh a BOM Model whenever the BOM Model changes in Oracle Bills of Material. For details about refreshing a BOM data, see the Oracle Configurator Implementation Guide.
For more information about BOM Models, see Imported BOM Models.
This section indicates the last time any Populators defined for the Model were executed and whether the Model needs to be repopulated. A Model must be repopulated when Items or Item Types have been added to or changed in the CZ schema’s Item Master.
Click Repopulate to run all Populators defined for the selected Model.
For more information about Populators, seeIntroduction to Populators.
This section indicates the last time logic was generated for the selected Model and whether logic needs to be regenerated. For example, you must regenerate logic whenever you define new or modify existing rules. It is also recommended that you generate logic before unit testing the Model. For more information, see Generating Logic.
To update logic for the selected Model, click Generate Logic. A status message indicates whether logic was generated successfully with Warnings, or if it failed with errors. Refer to the following sections for details.
It is possible for logic to be generated successfully but still display warning messages. In this case, you can unit test the configuration model.
The logic generation status message includes warnings when:
A rule is incomplete or defined incorrectly (in this case, the rule is ignored when unit testing)
Model structure is missing or a node is defined incorrectly
Examples of logic generation warning messages:
"Compatibility rule must have at least two participating features, rule ‘Test Exp Rule’ ignored"
"The Model structure has changed and the rule ‘My Test Rule’ now contains the deleted node ‘Color Feature’. "
The logic generation status message includes errors when Model structure is missing or invalid. You cannot unit test or publish a configuration model until all of the errors caught by logic generation are resolved.
Examples of logic generation errors include:
“Node ‘SI1142’ must allow decimal quantity since its parent ‘OC5231’ allows decimal quantity.”
“Invalid Model structure: Multiple references exist to the trackable instance ‘CN4321Z’ ”
"Project does not exist for the specified ID: ‘512342’. No logic generated.’ ”
This section lists any User Interfaces that need to be refreshed. A UI must be refreshed when the Model structure changes. For details, see Changes that Require a User Interface to be Refreshed.
To refresh all UIs that are out of date, click Refresh UIs.
You can also refresh one UI at a time in the User Interface area of the Workbench. For details, see Refreshing a User Interface.
Note: Configurator Developer does not update a UI if the Refresh Enabled setting is set to No in the UI’s UI Definition. This is true even if the Model structure has changed. See The Refresh Enabled Setting.
This section indicates how the runtime Oracle Configurator generates the default UI captions for BOM and non-BOM Model structure nodes. To modify how Configurator Developer generates these captions, click Edit Display Names. You can create default UI captions using node names, descriptions, a User Property, or a text expression that you enter.
The default Display Name setting for BOM nodes is Description, while the default for non-BOM nodes is Name. If you select Description, be sure that all nodes in the Model have a description; otherwise, some UI elements may appear without a caption at runtime.
The Display Name setting determines each node’s DisplayName System Property. When you generate a UI, the Text Source setting in each UI element’s details page is set to "Display Name" by default; this means the runtime UI will generate the caption using the associated Model node’s DisplayName System Property. For example, if you set Display Name to Description for BOM nodes, and you do not modify the default Text Source for any UI elements after generating a UI, BOM node descriptions are used as UI captions for all elements that represent BOM items at runtime.
For more information about System Properties, see System Properties. The Text Source setting is described in User Interface Element Captions and Details.
You can also create default UI captions using a User Property or a text expression that you enter. The User Property setting is not recommended unless all nodes in the Model share a common Property. Additionally, specifying a User Property whose value can change at runtime is not recommended because instance names may not appear as expected when the Property’s value changes and new instances are created. For details about User Properties, see User Properties.
A text expression can include System and User Properties and any text you enter. For more information, see Defining a Text Expression.
If you are implementing Multiple Language Support (MLS), set Display Name to Description for both BOM and non-BOM nodes. For more information about MLS, see Introduction to Multiple Language Support .
Use this section to edit the Archive Path for the selected Model. A Model’s Archive Path affects the execution of the Configurator Extensions that are defined in the Model. For information on Configurator Extension Archives and the Archive Path, see:
Related Topics
Editing a Model's Archive Path
Adding Archives to a Model’s Archive Path
Modifying the Archive Path for a Model
To add Archives to a Model’s Archive Path, or modify the current Archive Path, you must edit the Archive Path.
In the Main area of the Repository, locate the Model that you want to associate with a Configurator Extension Archive.
In the same row as the Model, click the icon in the Edit column.
In the General area of the Workbench, the Archive Path for the Model appears in the Configurator Extension Archive Path section. For an explanation of the Archive Path, see The Archive Path.
You can click a name in the Archive Name column to go to the main page for redefining the selected Archive.
Click Edit Archive Path.
The Edit Archive Path page lists all Configurator Extension Archives in the Main area of the Repository, subject to the current focus level. For each Archive, the list includes the name and location of the corresponding Java class archive file. If the Archive’s classes have been uploaded to the database, then the Archive Location column shows the name of the uploaded Java class archive file, and the Uploaded column contains a mark.
To add Archives to the Archive Path, see Adding Archives to a Model’s Archive Path.
To modify the Archive Path, Modifying the Archive Path for a Model.
Before you can bind a Java class to your Model, you must add the Configurator Extension Archive containing that class to the Archive Path of the Model.
On the Edit Archive Path page, select the Configurator Extension Archive that you want to add to the Archive Path, then click Add to Selected List.
When you do this, the selected Configurator Extension Archives appear in the Selected List. The most recently added Archive appears at the end of the list, meaning that it occurs at the end of the Archive Path.
Continue to add Archives to the Selected List, as desired.
If you need to change the list of Archives in the Archive Path, see Modifying the Archive Path for a Model.
When you are satisfied with your definition of the Archive Path, click Apply.
When you add an Archive to the Archive Path of a Model, that fact is reflected on the Configurator Extension Archive page for that Archive, where there is a table listing Models Referencing This Archive. This table contains links to the Models that include the Archive on their Archive Path. You can click a link to go directly to the General Workbench page for the Model, where you can edit its Archive Path. This is convenient when you change the classes in an Archive, and wish to make changes to the order in which the classes are loaded by the Configurator Extension Rules of the Models that use those classes.
The Edit Archive Path page provides the Selected List, which lists the Archives that currently constitute the Archive Path for the Model.
The Selected List is numbered, to indicate the search order among the Configurator Extension Archives.
The Path column in the Selected List displays the path to the Configurator Extension Archive in the Main area of the Repository.
Use the Selected List to remove, reorder, or add Archives to the Archive Path.
To remove one or more of the Archives from the Selected List, select them, then click Remove.
To change the order of the Archives in the Selected List, click Reorder.
The Reorder Archives page appears. To move an Archive higher or lower in the Selected List, select it and click the arrow controls.
The order of the Selected List affects the Archive Path. See The Archive Path for details on why you might need to change the order of the Archive Path.
When you are satisfied with your modifications to the Archive Path, click Apply.