Configurator Modeling Course - Student Guide
Configurator Modeling Course - Student Guide
Course Introduction
Configurator Modeling
Each lesson in this course begins with your instructor presenting important concepts
related to the functional setup or functionality of Configurator Modeling.
Each lesson may also require you to do one or more of the following:
• Complete a portion of the setup in the application.
• Discuss key setup decisions and best practices.
• Complete a knowledge assessment quiz.
Prerequisite Courses
• Prerequisite Knowledge
• Basic understanding of configurator modeling
• Intermediate understanding of ERP Cloud applications, technology, and navigation
• Oracle Supply Chain Management Cloud documentation, available in the Oracle Help
Center
• Getting Started with Your Manufacturing and Supply Chain Materials Management
Implementation
• Modeling Configurations for SCM
• Oracle Supply Chain Management Cloud documentation, available in the Oracle Help Center:
• Getting Started with Your Manufacturing and Supply Chain Materials Management Implementation:
https://docs.oracle.com/en/cloud/saas/supply-chain-management/20d/
• Modeling Configurations for SCM:
• https://docs.oracle.com/en/cloud/saas/supply-chain-management/20d/facmg/index.html
• https://docs.oracle.com/en/cloud/saas/supply-chain-management/20d/facmg/modeling-configurations-for-
scm.pdf
Product experts schedule Customer Connect training. These sessions provide more information on topics
already discussed in this training or discuss topics relevant to the implementation and use of the product. The
replays of these sessions are listed in a single forum post to make them easy to find:
https://cloudcustomerconnect.oracle.com/resources/8ff48b6562/posts
You can also find replays of these sessions from the Events area. In the Find Events box, enter training and
Supply Chain Planning and click Find. This filters your results to list only Supply Chain Planning training
events.
You can also select one of the available Event Series. The event series filters the events by training and
product areas.
The Oracle Supply Chain Management Integration Lesson
(https://cloudcustomerconnect.oracle.com/posts/5d7d178db7) discusses core integration capabilities for
Supply Chain Management including external web services, integration with PaaS, business events, file-based
data import, ADFdi and common messaging framework.
The image shows the Deep Links work area. A search has been performed on the search term ‘Pay’. The
search results include deep links such as Collections (AR_TRANSACTION,PAY), Create Payment
(AP_PAYINVOICE,CREATE) and so on.
Navigator > Tools > Deep Links
When you add deep links to reports or third-party application pages, users can simply click those links to go
directly to the application pages they need to use, without any additional clicks or navigation. When a user
clicks a deep link, that user's security assignment is honored; that is, users can access application pages
only if they're assigned a job role that allows them access.
Some deep links, such as those assigned the NONE action, are ready to use as is. Other deep links, such
as those assigned the EDIT action, require you to edit the link details before you can add the deep link to a
report or third-party application page.
For details, refer to Oracle Applications Cloud:
• Configuring and Extending Applications
https://docs.oracle.com/pls/topic/lookup?ctx=fa-latest&id=OAEXT
• Oracle SCM Cloud: Implementing Common Features for Oracle SCM
https://docs.oracle.com/pls/topic/lookup?ctx=fa-latest&id=FAICF
This section discusses how Configurator is used by end users, such as order entry managers or order entry
specialists.
This diagram depicts how a user interface is dynamically assembled when a user chooses an order entry to
configure a product. This User Interface enables the user to select valid options for the product.
Runtime Features
• A validation service is triggered by specified events (such as submitting an order) to ensure that all
the options that are selected for a configured product are still valid, even after the initial configuration
session. This is especially useful if there are long lead times between when an order is created and
when it is submitted for fulfillment.
• Predefined UI templates enable dynamic assembly of runtime UIs, and simplify your UI.
• You can define multiple UIs to be used for configuring a product.
• The elements within the user interface can be displayed or hidden conditionally, based on other
selections that the user makes, making the whole configuration experience easy and relevant. Using
the Product Configurator Manager role, you can set up this conditional display in the Configurator
Models work area.
• You modify the dynamic UIs by using a WYSIWYG editor in the Configurator Models work area.
• You can test the runtime behavior of models and their UIs before deploying them in production.
• Product models include transactional item attributes (TIAs), so the user can provide inputs that are
specific to the current configuration. The TIA values that are provided during the configuration
session are stored with the order lines and are available to the downstream fulfillment process.
This section gives a high-level overview of the Configurator runtime application and its key constituents. It
helps you to understand where Configurator Modeling fits in the order management flow, and how it
configures and validates the options chosen for a particular product.
This screenshot depicts the Personal Choices train stop. Oracle’s Application Development Framework
(ADF) is the framework on which all Fusion Applications are built. Because Configurator runtime is also built
with ADF, its look-and-feel is consistent with the UI of the host applications that embed Configurator to
enable end users to configure products.
Shell Layout
UI Templates Templates
Template
Master
Map
Template
Configurator
Models
Control behavior
Control Message
Common content Templates Templates
Components
Items Navigation style
Utility
Templates
User Interfaces
This diagram depicts template-driven user interfaces that allow users to quickly generate runtime UIs. In the
Configurator runtime UI, the end user interacts with parts of the UI that are rendered by control templates. In
the underlying product model definition, these control templates are mapped to the model by a template
map, which governs the navigation style and the way in which product elements (such as standard items,
option classes, and reference models) are rendered in the Configurator UI.
At runtime, the product item information from the model, the control templates, and the template map that
maintains the mapping between them based on item type, are read to dynamically assemble the
Configurator runtime UI that is presented to the end user to configure a model.
This screenshot highlights the Shell template, Layout template, and Control templates.
Assembling the User Interface from Templates
In the runtime user interface, the UI templates are assembled to represent the selections that are possible
for a configurable item.
• Control templates present the selectable representations of items. For example, an option class
with mutually exclusive options is presented as a set of radio buttons from which the user can select
only a single button.
• The layout template determines the visual layout (such as form or stack) of the control templates or
elements within the layout region.
• The shell template keeps together all the other regions or parts of the UI, and provides the
navigation and actions for the UI, such as Finish or Cancel.
The UI-level actions that an end user can select are:
• Save for Later: This option saves the configuration as-is, in the state left by the end user without the
Configurator engine finishing the configuration.
• Finish and Review: The Configurator engine finishes the configuration and navigates the end user
to a Review page where all the selections are displayed for review.
• Finish: The Configurator engine automatically completes all the remaining selections that are
required for valid configuration of the item, and returns the selection information to the host
application.
• Cancel: The user is warned about losing any selections made, and is returned to the host
application from which Configurator is invoked.
This section discusses the integration between Configurator and Order Management that provides the
benefit of creating orders that can be fulfilled seamlessly, thus avoiding errors during order fulfillment.
Benefits of Integration with Order Management (Task flow embedded in the host application)
When an item is being added to an order and needs to be configured, the end user selects a Configure
action, which invokes Configurator to help select valid options for the item. Then the Configurator UI is
displayed, which is embedded within the UI of the host application, such as Order Management.
After the item has been configured and is valid within the order, if the user wants to go back and change any
existing selections, the user can still make those changes by selecting the Configure action again, on
individual order lines, and modifying the selections. The details of the configuration are not saved explicitly
until the entire order is saved.
The prices that the user sees for any product in the Configurator UI are always obtained from the pricing
data for the customer who the product is being ordered for.
Benefits of Integration with Pricing (End users see real time pricing at runtime)
• Prices are fetched from correct pricing data through the pricing integration.
• Configurator displays the prices in the UI when a price has been set up for an item.
• The configuration review page also displays the total price for the configuration, along with the price for
each selected item.
Integration by Embedding
Hosting applications in the Applications suite can invoke Configurator by passing it an initialization
message, producing a dynamic configurator UI embedded within the UI of the hosting application.
• If a configurator model has been created for the product model, in the Configurator Models work area
and released to production, the definition of that model, including a modified UI, is invoked by the
hosting application.
• If there is no released configurator model, a default configurator UI is presented to the user. The
default UI is based upon the model structure and rules defined as part of the common product
model.
End users interact with the configurator through one of these embedded UIs. When a user saves or
cancels the configuration session, control returns back to the host application.
Integration by Service
Configurations created in a hosting application can be validated against the latest definition of the
configurator model without direct user interaction. The Configurator runtime REST services enable external
applications to start new configurations or restore previously configured items for adjustment purposes
during order or quote processes.
Integration Components
Configurator provides a set of integration components:
• Runtime external endpoint: A standards-based runtime endpoint allows external applications to
invoke the Configurator runtime UI either as an embedded UI or as a punch-out UI.
• Runtime services: A set of RESTful APIs for Configurator enable external applications to initialize,
create, and restore configurations.
• Order import validation: The Configurator validation service supports validation of an order that
includes a Fusion configuration, prior to import into Fusion Order Management. The item structure is
This section discusses some fundamentals about the Configurator Models work area.
This diagram depicts the life cycle of a configurator model that progresses from the initial definition of a
product item to the release of the configurator model in a workspace.
• You use the Product Information Management work area to define the items and item structure. This
definition of item structure is the basis for the configurator model.
• You then import a snapshot of the item, which is a copy of the item structure at a point in time, into
the Configurator Models work area.
• After the snapshot is imported, an initial version of a configurator model for the item is automatically
created.
• You add the configurator model as a draft to a new or an existing workspace in order to add
supplemental structure, rules, or user interfaces to enhance or expand the model.
• The supplemental structure, rules, and UIs give you the ability to simplify the process of configuring
the product at the time of order entry.
• You then test the model to ensure that everything that was done by you or other Product
Configurator Managers is working as expected, in terms of the end user experience.
• On successful testing, you release the workspace that contains the model draft, so that the
completely developed model is available for order entry.
Workspace
Task List
Task Tabs
These screenshots depict how you can access the Configurator Models work area by logging in with the role
of Product Configurator Manager and selecting Configurator Models in the navigator.
• The Configurator Models work area opens on the Overview page, which lists your workspaces that
are currently in Development status.
• Select a task from the task list to open a tab for the task’s page.
• Manage Workspaces enables you to create new workspaces or search for existing ones.
• From the Manage Snapshots page, you can import item structures into the Configurator Models
work area.
• Manage Models enables you to search for a specific model and open any of its released versions or
drafts from any of the workspaces that contain that model.
This section discusses how an item structure in the Product Information Management work area is a
prerequisite to building or developing a configurator model in the Configurator Models work area.
Create Items
This diagram depicts the tasks that are the building blocks that lead up to an item structure. Some tasks are
optional.
• For example, if you do not want to classify your items, you would not need item classes, but that is
rarely the case.
• After the items are created, item structures can be created. An item structure can have other item
structures as its constituents.
• An option class can have an item structure that contains standard items, other option classes, or
model items (which become reference models in a configurator model).
For more background on creating items and structures in Product Information Management, see the Oracle
SCM Cloud: Manufacturing Foundation course. For more background on setting the attributes that make an
item configurable, see the Oracle SCM Cloud: Configure to Order Implementation course.
This diagram depicts a car as an example of a model item that illustrates the elements of an item structure.
Example Model Item: Car
• When a car is bought, customers choose the options they want in their car.
• For example, customers can pick interior features, mechanical options, or exterior options.
• Some car models provide mechanical options for the type of engine or the transmission.
• Customers can also select the exterior options, such as color or style of wheels.
• All these options are organized in the form of an item structure of the item called 4 Door Sedan in the
Product Information Management work area. This item has a Structure Item Type of Model.
• The 4 Door Sedan model item has a structure that includes option class items for Interior Options,
Mechanical Options, and Exterior Options. Each option class has its own item structure. For
example, Interior Options contains option class items for Seats, Seat Trim, Interior Color, and so on.
Seat Trim
• Leather
• Cloth
• Sport
This section discusses the concept of a snapshot in the Configurator Models work area.
• Imported from the Product Information Management work area into the Configurator
Models work area
• Read-only representation of approved product data from the Product Information
Point
• Import creates the initial baseline version of a model and creates corresponding
snapshots for all standard items and option classes beneath it.
• Any reference models that exist in the item structure arePoint
imported along with the
model item.
Workspace and
models created by
snapshot import
Name: WSYSClassic_Sedan
Classic Snapshot Import ESD : Date of Import
Sedan (Import Model) Status: Released, Version 0
Classic
Engine Sedan
Assembly
Engine
Assembly
Product Information
Management work area Configurator Models work area
Model 1
Model 2
Item Snapshot
Model 3
Model 4…
This diagram depicts that an item can be used in multiple configurator models as shown in the slide. They
all refer to the same snapshot.
There is only one snapshot of any given imported item kept in the Configurator Models work area.
Seat Trim
2 Door Coupe
This diagram depicts the example of Snapshots shared by models. The Seat Trim option class that has the
Leather, Cloth, and Sport items is used across all four of the car models. But only one snapshot of the Seat
Trim item is kept in the Configurator Models work area.
This section discusses how snapshots are managed or maintained when there are updates to existing items
or structures in Product Information Management.
Cloth Cloth
Sport Sport
This screenshot depicts the Manage Snapshots page. The Manage Snapshots page is where you:
• Import model items as new snapshots
• Refresh existing snapshots
• Query all snapshots to see the data that is available to you for building configurator models
The list of imported and refreshed snapshots shows you:
• The model items that can be added to a workspace, and then enhanced to provide a specific
configuration experience
• The item classes and value sets that can be added to a workspace containing a configurator model.
Updates to their values in Product Information Management can be reflected in the model by
refreshing the snapshots.
Updated Snapshot
Updated Snapshot
Updated Snapshot
Updated Snapshot
This screenshot depicts how you can refresh item classes and value sets, as well as model items and their
children.
For example, assume that the item class zCZ_CAR_IC2 has two new transactional item attributes (TIAs).
Refreshing this item class brings in the change (the two new TIAs) into the Configurator Models work area.
When you add the modified item class snapshot to a workspace, any items in that workspace that belong to
this item class will inherit the two new TIAs.
Similarly, Value Sets can also be refreshed when a new value is added to the enumerated set, or if a range
of values has been modified in the Product Information Management work area. The idea of these types of
refreshes is to be able to refresh at a granular level.
Workspaces
Configurator Modeling
This section discusses what a workspace is in the Configurator Models work area.
Workspace
Import / Refresh Manage
Product Supplemental
Management Data Structure
Model
Manage
available in
Rules
Release production
to be used
from Order
Management
Manage User
Interfaces
Workspace
Test Model UI and
Behavior
This diagram depicts Workspace in the Configurator Modeling Process. In the Work Area Overview and
Integration by Snapshots lesson, you were introduced to the workspace, which is where you develop drafts
of configurator models in the Configurator Models work area.
Workspaces are the focus of this lesson.
You can edit a configurator model only by adding a released model as a draft to a workspace. A released
model, after import, has the version number 0. In the workspace, you can edit the model draft and add a
supplemental structure, rules, and user interfaces, and release a new version of the model by releasing the
workspace.
This section discusses what a workspace is and how models and snapshots can be added to a workspace.
• Workspaces enable you to modify and test one or more draft models before they are
released into production.
• Modified snapshots can also be added to workspaces along with models.
• Multiple workspaces allow concurrent draft development.
• After testing, workspaces can be released into production. All changes made to the
models are effective as of the effective start date of the workspace.
Working in Workspaces
Workspaces enable you to develop new versions of configurator models in an incremental manner and
control their release into production.
• The Configurator workspace allows draft models to be edited together and tested as a group, without
affecting the definition of production data. When ready, the drafts in a Configurator workspace are
released as a group, with all versions inheriting the same effectivity date.
• Consider the process of working on an online tax return. You start a return, add the income and
deductions information, review your return, and then submit it. A similar process takes place in a
workspace.
• You create a new workspace and add all the models that you want to make changes to, or the
models that are affected by a snapshot update. The runtime behavior of these models can be tested
as a set or group. After the testing is complete, the workspace is released, which means that all the
changes to the models or the changes to the snapshots in the workspace become effective as of the
effective start date (ESD) of the workspace.
• Using workspaces allows for concurrent draft development that is driven by the effective start date of
the workspace. Concurrent draft development is covered later in this lesson, and the concept
becomes clearer when you learn about versioning and release.
• The workspace respects the item and component effectivity that is defined in PIM, congruent to the
workspace effective start date. For example, you may have a workspace with an ESD of June 1 that
contains a snapshot of an item that is effective on June 15. On release of the workspace, the item
would not be available for selection until June 15.
• Name
• Description
• Effective Start Date
– Date from when the changes in the workspace would be available to end users.
• Status
This screenshot depicts that when you create a workspace, you enter values for its attributes: name,
description, and effective start date.
After you have entered the attributes, you add models and related components as participants of the
workspace.
A workspace begins with the default status of In Development.
• Models
• Snapshots
– Items
– Item classes
– Value sets
This screenshot depicts how you can add the following to a workspace as participants: models, item
snapshots, item class snapshots, and value set snapshots.
Some example scenarios of when you add each of the participant types are as follows:
• Value Set: Some items in a model have a transactional item attribute (TIA) named Color. It is an
attribute with a list of values and uses the value set named External Colors. When a new color gets
added to the value set, you would refresh the Value Set snapshot and add that snapshot to a
workspace to verify that the new color is being shown to the end user when an item with the TIA
Color is being configured.
• Item Class: Items inherit TIAs from their item classes. So if a new TIA is added to the item class, the
item class snapshot can be refreshed and added to a workspace to verify that the new TIA is being
displayed in the runtime UI.
• Item: If an option class has a new component added, you can refresh its snapshot and add that
snapshot to the workspace to verify that the new item component is being displayed in the runtime
UI.
• Model: To be able to test changes to a value set, an item class, or an item snapshot, you must add
models with items that correspond to the respective changes to the workspace, so that you can test
those changes in the context of a model. Even when you do not have any such changes, if you want
to add a new rule to an existing model, or edit an existing UI, or create a new UI, you can add a
model to a workspace and proceed with making the changes.
This screenshot depicts how you can lock configurator models to prevent another user from making
changes that would conflict with the changes that you are making to the same model.
• Models added to a workspace are the only participants that can be edited.
• Before editing a model, you should lock it.
• When you add model to a workspace, it is locked by default.
• When a model is locked, it can be unlocked by clicking the Unlock button. When a model is
unlocked, the Lock button action is enabled, and can be used to lock the model for editing.
This section discusses how workspace effective start date and snapshot effectivity work together. In
addition, it discusses concurrent model development and how you can be sure that work done on a model in
a different workspace is always updated into a workspace with the same model.
This screenshot depicts a scenario in which you have set the effective date of a workspace as some future
date but the changes in a snapshot in the workspace are already effective.
The model shown in the example is a tablet computer (Tablet), which has a new option class added for color
selections. The option class is effective as of today, whereas the workspace was created with an effective
start date sometime next week. When the Tablet’s item snapshot is refreshed and added to the workspace,
the following warning is displayed: “One or more participants have changes that take effect before the
current date and time. This workspace will become effective immediately upon release.”
Earlier in this lesson, you learned about the congruence of workspace effective start date and snapshot
effectivity, and that the workspace respects the item and component effectivity defined in the Product
Information Management work area, congruent to the workspace effective start date.
Examples:
• The workspace ESD is June 1. A component snapshot in it is effective on June 15. On release of the
workspace (on or before June 1), the component is not available for selection until June 15.
• The same workspace, with an ESD of June 1, contains a component snapshot that is effective on
May 15. On release of the workspace, it is effective immediately and the component is available for
selection immediately.
To reiterate, the workspace effective start date works in tandem with snapshot effectivity. In fact, snapshot
effectivity could even end up altering the workspace effective start date. The driving factor here is to keep
the item that is used in the configuration in synch with the item definition in the Product Information
Management work area.
Classic WS2
Sedan
T1 – WS2 Created
Draft
Classic
Engine Sedan
Draft
Assembly
Engine
Baseline versions for the models Assembly
is V0
Earlier in the lesson, reference was made to concurrent development of model drafts. Concurrent
development is defined as two or more PCMs working on model drafts of the same model in different
workspaces, each workspace having its own effective start date. This diagram depicts how it works:
• When Classic Sedan and the model that is referenced by it, Engine Assembly, are imported, the
import process creates a workspace by default, adds the two models to the workspace, and releases
the workspace immediately. Version 0 of each model is created at that time. What this means is that
the Product Hub equivalent of the models are released as soon as they are imported for the first
time. Any further changes to the model must be done in workspaces.
• Workspace WS1 is created by one PCM (at point T0 on the example timeline) to create a step-by-
step UI for the Sedan model so that Order Management users, when they configure the sedan, can
use the step-by-step UI.
• After a few days (at T1), WS2 is created by another PCM to add more rules and enhance the step-
by-step UI.
• The changes to the model in WS1 and WS2 can occur concurrently.
• When WS1 is released (at T2) earlier than WS2 (at T3), the changes to the model in WS1, that is,
the step-by-step UI that was created will be visible in WS2 after the release of WS1 because the
baseline version for the models in WS2 has been updated.
• This ensures that work done in WS1 on the same model need not be manually repeated in WS2 to
keep up with the changes.
The example used here is a UI, but this concept applies to any work that is done on the model in WS1. The
work could be rule changes or changes to supplemental structure.
In this practice, you create a workspace and add a model to the workspace.
Supplemental Structure
Configurator Modeling
Now that you have learned how to create a workspace and add a your model to the workspace, the next
stage in the life cycle of the configurator model is to build your configurator model, and test it. This diagram
depicts the three elements of a configurator model:
• Supplemental Structure
• Rules
• User Interfaces
Workspace
Import / Refresh
Manage Supplemental
Product Management Structure
Data
Model available
Manage Rules
in production
Release
to be used
from Order
Management
Manage User
Interfaces
Model
Management Test Model UI and
Tasks Behavior
This diagram highlights how Product Management Data is imported into the Workspace, where model
management tasks are performed before releasing.
This section discusses how you view the item structure of the model as defined in Product Information
Management and add any supplemental structure that is required for your model.
Supplemental Structure
This diagram highlights Supplemental Structure as the first of three model management tasks.
After importing a model from the Product Information Management work area, to the Configurator Models
work area, you can now add some structure to it.
A complex item can have a substantial number of options for customers to choose from. Some options are
compatible with each other; some are not. You can simplify a customer’s shopping experience by reducing
the number of product items that appear in the UI of the Configurator run time. This is where adding a
supplemental structure to your model can come in handy. The nodes of the supplemental structure can be a
small set of questions or prompts with relevant options that the end user can choose from. The end user’s
responses can be used to drive selections for many other items, by means of rules.
You can combine several compatible sets of options into a set of buying packages. You can add a prompt to
select one of those packages, as a node of supplemental structure, to the model that is imported from the
Product Information Management work area. Then you can add rules that select the necessary set of items
as part of configuration of the model. You might also want to prompt the customer with Yes/No questions
that help determine a desired configuration, or obtain some numeric values that can be used to perform
calculations that help determine a desired configuration. You can model all these scenarios by adding
supplemental structure to your configurator model.
This diagram depicts an example of how you can use supplemental structure.
Consider the example of a car as the Model Item.
When you buy a car, you can select what it looks like on the outside. You can choose what color your car
should be and whether or not you want alloy wheels. You can also choose what the interiors look like or
what features you want in your car. With some models, you can also pick the type of engine or transmission.
In the Product Information Management work area, the Structure Item type of the Car item is Model. The
options that a customer can choose from, such as interior options, exterior options mechanical options and
so on are organized in the form of item structure for the Car item.
Each of these option classes have their own Item Structure.
Seats
•Manual Driver Seat
•Manual Passenger Seat 8-Way
•Power Driver Seat 8-Way
•Power Passenger Seat 8-Way
•Power Heated Driver Seat 8-Way
•Power Heated Passenger Seat
If you examine the Seats option, you see that it is an option class item with six possible items to select from.
An option class is a kind of container that holds together a set of similar items from which an end user can
select one or more items.
The diagram depicts an example of how item structure can be organized. In the example of the car, the
Seats option class, which has six seats as options, is a part of the Interior Options item structure, which in
turn, is part of the Car Model’s item structure.
These screenshots represent how the item structure of a PIM model item is replicated in the structure of the
configurator model that is initially created with the snapshot of the PIM model.
Given the large number of possible options to choose from when configuring the Car model, customers can
feel overwhelmed by the complexity.
This diagram depicts how you can simplify this complexity by combining compatible sets of options into
packages, such as:
• Base Trim Package
• Luxury Package
• Super Luxury Package
• Sports Package
These packages can be presented as the options of a single option feature, named Base Option Packages,
so that customers can make a single choice that automatically makes many of the necessary selections.
This screenshot depicts how you create supplemental structure for a configurator model on the Structure tab
of the Edit Model page of the Configurator Models work area.
In the Work Area Overview and Integration by Snapshots lesson, you learned that you can import model
items from the Product Information Management work area into the Configurator Models work area as
snapshots that become configurator models to which you can add structure, rules, and UIs.
The different types of supplemental structure that you can add are listed as follows. Use these to provide the
customer interaction that was discussed earlier under this topic.
• You can model questions and their answers as option features and their options, respectively.
• You can model inputs that require a Yes/No response as Boolean features.
• Input that requires a numeric value can be modeled as integer or decimal features.
This diagram depicts that the packaging of options in a complex product can be added to a configurator
model as supplemental structure by using an option feature with options.
To model the Base Option Packages for the car, you create an option feature named Base Option Packages
in the car model, and then add options to the option feature for each of the individual packages You can
optionally specify the display sort order of the options at runtime by name or description, in either ascending
or descending order. By default, the options appear in the order in which they were created.
This demonstration shows how you add supplemental structure to a model in the Configurator Models work
area.
In these practices, you create supplemental structure, rules as well as create and modify user interfaces.
Rules
This diagram depicts the next step in the process of building a configurator model is creating rules that
define the behavior of the model during configuration.
You decided to simplify customer shopping experience for a car by providing a set of Base Option
Packages. You can prompt a customer to select the right package by using the supplemental structure to
capture an answer to the question “What are you primarily looking for in your car: price, comfort, or
performance?” The answer by itself does not provide configuration information for use in the car
manufacturing process unless it is mapped to specific items and options. This mapping can be performed by
configurator rules.
For this example, you can envision a rule that says if the customer is seeking the car primarily for comfort, a
rule should select the Luxury Package by default. In turn, the Luxury Package selects options such as 8-way
Power Seats for the Seat type, Cloth as the Seat Trim, and numerous other compatible options.
So by using rules, you can help make the configuration process much simpler for end users by shielding
them from complexity.
Customer
selects a
package
Base Option Packages
•L- Base Trim
•LX - Luxury Package ‘LX - Luxury Package’ IMPLIES ‘8-way Power Seats’;
•GLX - Super Luxury Package ‘LX - Luxury Package’ IMPLIES ‘Cloth’; Package is
•SX - Sports Package ‘LX - Luxury Package’ IMPLIES ‘2.0L turbo DOHC’; participant in
‘LX - Luxury Package’ IMPLIES ‘16” Steel Wheels’; rules
The diagram depicts how to design the rules that map a selected buying package to options in the item
structure of the car model.
To model the Base Option Packages for the car, you create an option feature named Base Option Packages
in the car model, and then add options to that option feature for each of the individual packages. When a
customer selects one of the packages by selecting an option of the Base Option Packages option feature,
the rules associated with the option for that package automatically make selections from the other options in
the structure of the configurator model.
Next we will look at how to write rules such as these in the Configurator Models work area.
About Rules
You create rules by writing statement rules in the Constraint Definition Language (CDL) that is built into
Configurator.
The type of a CDL rule is classified by the operator or operation employed: logical, numeric comparison,
numeric accumulator, or compatibility. You determine the type of a rule by your choice of CDL operators in
the rule text.
The class of a CDL rule indicates how the rule is to be enforced during the configuration process. The
classes are Defaults, Constraints, and Search Decisions. You determine the class of a rule by selecting it in
the rule definition. You can change the class.
• Default rules create default selections at the beginning of a configuration session. The end user, or
constraint rules, can override the default selections. Logic and comparison type rules can be used as
defaults.
- For example, in configuring a laptop computer, assume that selecting an Intended Use as
Emails and Browsing should select a 20 GB hard drive, if there is no other rule requiring a
different hard drive selection. This rule can be defined as a default rule. On initialization of the
configuration, the 20 GB hard drive will be selected by default, but the user could instead
select the 40 GB hard drive.
• Constraint rules cannot be violated, if a configuration is to be valid at the end of a configuration
session. Unlike default rules, constraints cannot be overridden by the end user or by other constraint
rules. All rule types can be enforced as constraints.
- Continuing the laptop example, assume that if the end user selects an Intended Use of
Emails and Browsing, no other hard drive but a 20 GB one should be allowed. In that case,
you will set up the rule as a constraint.
This screenshot depicts how you can create statement rules in the Rule Editor.
General Procedure for Creating Statement Rules
To create a rule, you use the rule editor in the Configurator Models work area.
1. On the Rules tab of the Edit Model page, create a statement rule by using the Actions menu.
2. Select a rule class to govern how the rule is used during configuration.
3. Enter the text of the rule by using the Constraint Definition Language.
4. Use the menus to insert CDL syntactical elements into the rule text.
5. The Validate button checks the validity of the syntax and references in the rule text.
6. The Status indicator shows whether the rule has been modified, and whether it is valid or has an
error. Error messages provide details about any problems with the rule.
Note: The Constraint Definition Language is not described in this course.
Structure Pane
Model node to be
referenced in rule
This screenshot depicts how you can insert model structure references into Rule Text.
How to Refer to a Model Structure in Rules
Statement rules contain references to structure nodes in your configurator model.
The Structure pane of the rules editor enables you to access all the nodes of the model for which you are
writing rules. Both the imported item structure and your supplemental structure are shown.
You can insert the correct notation for a model node reference in your rule text by selecting the node in the
Structure pane and choosing Insert into Rule Text from the context menu.
You can also insert attributes associated with model nodes in your rule definitions:
• User-defined attributes:
‘Theater'.'Speakers'.userAttrs["PhysicalAttributes.Color"]
• Transactional item attributes: ‘Window'.'Frame'.transAttrs["Linear Length"]
• Configurator system attributes: ‘Theater'.'Speaker System'.'5.1'.Quantity()
This screenshot depicts how you can insert rule text with menus and buttons.
To assist you in entering the text for a statement rule, a set of menus are available to insert the names of
CDL keywords, functions, and operators. Hierarchical menus provide access to all members of the
categories of functions. A set of buttons enables you to insert the other valid syntactical elements that are
required to create a rule, such as comparison, arithmetic, and logic operators.
Selecting an option from one of these menus, or clicking a button, inserts the text shown on that menu or
button at the location of your cursor in the rule text. Arguments to functions are not inserted.
Tip: You can use the set of menus and buttons as a convenient basic reference to CDL elements.
• Create Rules
This demonstration shows how you add some rules to our car model and test it.
Tip: When you test a model in the Configurator Models work area, the Test Model operation saves,
validates, and compiles your rules for you. If any rules are invalid or incomplete, you receive error or
warning messages that those rules will be ignored during the test. After you acknowledge the messages,
you can still proceed with testing.
Note: Issues that surface while testing models that have large sets of complex rules can sometimes be
difficult and time-consuming to diagnose and troubleshoot. When such issues are encountered you can
choose to generate a trace file around the problematic runtime session, download the trace file (in XML
format) and open a service request with Oracle Support to jointly diagnose the problem to understand the
root cause.
This screenshot depicts the general procedure for creating extension rules in the Rule Editor.
General Procedure for Creating Extension Rules (part 1)
To create a rule, use the rule editor in the Configurator Models work area.
The first part of creating an extension rule is associating the rule with a model node, and adding the rule
script that defines the behavior.
1. On the Rules tab of the Edit Model page, create an extension rule by using the Actions menu.
2. Select a node from the model tree in the Structure pane, and choose Set as Base Node from the
context menu. An extension rule must have a base node.
3. If the base node can have multiple instances, then select an Instantiation Scope.
4. Enter the text of the rule script, using the Groovy scripting language.
5. Click Validate to check the validity of the syntax and references in the rule text.
6. The Status indicator shows whether the rule has been modified, and whether it is valid or has an
error. Error messages with line numbers provide details about any problems with the rule.
Note: The Groovy language is not described in this course.
This screenshot depicts the general procedure for creating extension rules in the Rule Editor.
General Procedure for Creating Extension Rules (part 2)
The second part of creating an extension rule is binding events on the model to methods in the rule script.
7. Still on the same Edit Model page, click Create in the Event Bindings table.
8. In the binding, select the Event on the base node to bind, and the scope for detecting the event.
Instructor Note: The current release of Configurator supports only the scope of Base node. Future
releases may provide additional scopes.
9. From the Class list, select the class that contains the method that you are binding to the event. If no
classes are defined in the script, select ScriptClass, which contains globally-defined methods.
10. Tip: Click Validate to refresh the Class and Method lists after any changes to the script.
11. From the Method list, select the method in the script that you are binding to the event. If the method is
not defined in a class, select run(), which executes globally-defined methods.
12. The Argument Bindings table presents a row for each argument of the bound method. Select a node
from the model tree in the Structure pane, and choose Set as Argument Value from the context menu.
You can also enter a literal value.
a. Get the configuration object that is associated with the event bound to the base
node of the rule.
COMPATIBLE
&color1 OF 'CAR4DRSDN'.'Packages', // supplemental node
&color2 OF 'CAR4DRSDN'.'Interior Options'.'Trim Colors' // item-
based model node
WHERE
&color1.suppAttrs["Color"] = &color2.userAttrs["Trim_AG.Color"];
This compatibility rule ensures that the color (supplemental attribute) of the car package is compatible with
the trim color (user defined attribute), and that incompatible options are excluded.
In these practices, you create supplemental structure, rules as well as create and modify user interfaces.
User Interfaces
This diagram depicts that Supplemental structure and rules are important parts of any configurator model,
but the user interface of the model is what the end user sees and interacts with to configure the model.
The Configurator Models work area enables you to create user interfaces and modify them to suit the
preferences of end users who are configuring products at transaction time, for example, from Order
Management when ordering a configurable item.
This slide highlights the key steps involved in creating user interfaces.
Templates
• Shell templates Shell Layout
UI Templates Templates
Master
• Layout templates Template
Template
Map
Utility
Templates
User Interfaces
Introduction to UI Templates
In the Overview of Configurator Modeling lesson of this course, you learned that Configurator user
interfaces consist of a set of templates, which are dynamically rendered at run time.
This diagram depicts the following templates are the building blocks of user interfaces:
• Control templates represent UI items and allow user interaction, such as selection or input.
• The layout template determines the visual layout (such as a form or stack) of the control templates
or elements within the layout region.
• The shell template keeps together all the other regions or parts of the UI and provides the
navigation and actions for the UI.
• Message and utility templates provide UI elements for specialized parts of a page.
Option Class
• Map model node detail types to
templates that represent them
Radio button group with quantity
Model
Reference
Item Selection Control
Selectable images
• Visually guide the user through
the product configuration
• Enhance the end-user
configuration experience
through the use of images in Set of selectable
Selected option
images
place of option names
Running summary
• Shows all orderable items selected
during the configuration session
• Displays the total net price for the
configuration
Running summary
Tracking Selections
This screenshot depicts how you can use a Running Summary template to provide the user with a high-level
view of the selections made during a configuration session.
In the Overview tab, you specify a Running Summary template that includes some combination of the Item
Description, Item Quantity ordered, or Item Amount for each of the selected orderable items in the
configuration.
During the run time configuration session, the summary is displayed in a pane on the right-hand side of the
UI. When the user selects an orderable item, that item is added to the summary, with its Quantity and
Amount, depending on which template you specified. The total configured net price (excluding shipping and
tax charges) is also displayed.
This screenshot shows the Instance Management Table with facets at runtime.
The Instance Management Table template provides you the ability to easily configure, and increase the
accuracy of multiple instances in model user interfaces at runtime. You can also override item display values
of options with all model node attributes and not just the name and description.
This template is only applicable to model nodes that can have multiple instances. Multiple instances are
specified in the Product Information Management work area, before the model is imported. These nodes
display the instantlibility setting as Multiple instances on the Details pane of the model's Structure tab. When
you create a user interface, any model nodes that can have multiple instances are rendered by default in the
new UI using the Instance Management Table template. You can also create UI page items using the template
by adding instantiable nodes from the model tree in the Structure pane.
To use the Instant Management Table template:
• Edit the reference model page Item in the UI
• In the Edit Item Page dialogue box, from the Templates list, select Item Instance Management Table
with Facets and click OK
When you test the model, one of the facets that now appear will display dynamic content about the
reference model. If you click the add button, the total number of instances will get updated automatically.
This screenshot depicts the Create User Interface page where you create user interfaces for a configurator
model on the User Interfaces tab of the Edit Model page of the Configurator Models work area. When you
create a UI, you must choose a template map as the basis for the UI pages.
Predefined template maps are provided for each of the navigation styles, in two versions for each style:
• Template map with ordinary selection controls
• Template map with enhanced selection controls, which show more detail about the state of the
selected items. For example, an icon indicates whether an item was selected by the end user or by a
rule.
There is also a template map named Single Page Navigation for Test UI with Enhanced Selection Controls.
This map is for use only when testing and debugging the behavior of a model with the Test Model operation
in the Configurator Models work area. It should not be applied to a UI that is intended for runtime use with
end users.
Note: You cannot modify the predefined template maps.
• Display conditions
Item rendered in
control template
This screenshot depicts that after you create a UI, you can edit the UI generated by the template map using
the Design tab. The generated UI will have the control templates mapped in the template map for the
respective node type.
The layout templates and control templates can be changed by editing the respective UI region or item.
For Dynamic Tree and Step by Step UIs, pages can be added, deleted, and moved (within the scope of the
same parent).
You can add styled text and images to make the UI the way you want it.
You can also control the display of items in the UI based on conditions.
A visual representation of a configured product ensures the accuracy of the final bill of materials. You can use
a third party visualization tool within the configurator UI to view your configured product in 2D or 3D.
You can enable the iframe basic UI element in your UI at design time to receive model node changes relative
to its associative model node and communicate them to the Iframe at runtime. This information is then
interpreted by the visualization tool to adjust and display those changes to the configured product in that
iframe.
Display conditions
• Use the associated model
node’s attributes (properties)
to control display
• Use attributes of other model
nodes to control display
• Use configurator session
attributes to control display
This screenshot depicts an example in which the option class Interior Color (zCZ_CARINTCLR) is displayed
only when the transactional item attribute (TIA) named cz_Car_color does not have a value assigned. When
the TIA value is set, the option class need not be displayed.
You define display conditions at design time, when you are modifying the user interface. A display condition
depends on the attributes of model items at run time.
For example, assume that you want to display an image of a red car when an end user selects a red exterior
color. You add an image of a red car to the UI and set a condition that it should be displayed only when the
Exterior color option Red is selected. When an end user is ordering the car from Order Management and is
configuring the car, the display condition on the image is evaluated. The image of the red car is displayed
only when the Exterior color option Red is selected.
You can also set up conditions to hide elements in the UI. Display conditions allow you to design the UI for
better end-user experience by controlling what needs to be displayed in the user interface for a given
product when it is being configured.
You can use the UI expression language to override the default item display name of a
given UI item, replacing it with a combination of static text and with Name and
Description attributes, with the exception of DisplayName.
UI Expression
Purpose of the token Example expression
Language Token
amn (case-sensitive) Establishes the # { amn.name }
reference to the
associated mode node
for the UI element
name The name of the # { amn.name }
associated mode node
description The description of the # {
associated mode node amn.description }
A UI facet is an area in the UI item where you can add additional content that is related
to the associated model node for the UI item or is reachable from the associated model
node.
Available user interfaces with facets are:
• Radio Button Group with Facets
• Radio Button Group with Quantity and Facets
• Check Box Group with facets
• Check Box Group with Quantity and Facets
• Boolean Feature Control with Facets
• Choice List with Facets
• Item Instance Management with Facets
Configurator Model node types that have UI templates and include UI facets are:
• Option Classes
• Option Features
• Boolean Features
• Referenced Models
To use a UI template with facets for a page item:
1. Select and edit a page item for an associated model node that can use facets.
2. Apply one of the templates that includes facets. After you click OK, the facets are added to the page item.
3. Select the first layout region under the header. This facet uses a Compact Slack layout which is ideal for
displaying messages related to the item. It is highly recommended to keep this layout template for
displaying messages.
4. From the list in the UI Elements tab in the Resources pane, select the Text element, then, from the
context menu or the UI Elements toolbar, click Add to Page.
5. Edit the basic Text element that you inserted into the facet. Add static text in the Text field to provide
messages about configuring the associated model node to the end user. Alternatively, you can use the
UI expression language to dynamically display information about the associated model node, or nodes
reachable from the associated model node. Use attributes that correspond to the node types for which
you can use UI templates with facets.
6. Select the second layout region under the header. This facet uses a Flow layout which can be used to
display relevant information from left to right or right to left (RTL Languages). It is highly recommended to
keep this layout template for displaying informational text about the model node.
7. Repeat the steps described for the messages facet, to add static or dynamic text in basic Text elements
in the information facet.
Models are not static. They go through changes and the changes are refreshed into the Configurator Models
work area by using the snapshot refresh process. Some of these changes could affect the existing UIs for a
model. To account for these model changes, you must create a new workspace and add the affected model
and the updated snapshots to the workspace.
• If an item is end dated or deleted in the Product Information Management work area, the existing UI
handles these changes without any updates. The ineffective or deleted items are not displayed in the
UI. Any display conditions that are written by using such items as Associated Model nodes or Other
Model Nodes are ignored.
• If new items or options are added to an existing option class or option feature, respectively, the
existing UI continues to work without any changes. This also applies to new TIAs for an existing
item, other than the model item itself.
• If new option classes, model references, or individual items are added to the existing model and
should be visible in the UI, they should be specifically added to the existing UI manually.
• If the snapshot changes involve changes such as instantiation type, or minimum and maximum
quantities, existing UIs work, but may not provide the best user experience. In such cases, it is good
to manually edit the control templates used for those items.
After completing this lesson, you should have learned how to:
• Outline the various navigation styles that are available for user interface creation
• Create and modify a user interface for a model
• Test the model during various phases of development
• Explain how snapshot changes impact existing UIs
• Versioning
• Releasing workspaces
• Concurrent development
• Referenced models
This section discusses the concept of versioning in the Configurator Models work area.
Release Workspace
This diagram highlights the last step in the life cycle of a configurator model - release. The model is not
released by itself, but as a participant of a workspace that is released.
In this lesson, the focus is to look in greater detail at releasing a workspace.
As we have discussed before, building a model involves adding supplemental structure, defining rules,
creating UIs, and then editing and testing them as needed.
After testing is successful, the workspace can be released so that the changes in the workspace are made
available for use in a transactional application such as Order Management.
Before the workspace is released, the model in the workspace is referred to as a draft.
When a workspace is released, new versions of any models in it are created. We will look at the details of
what a version means for a configurator model.
You can also unrelease models from production using a REST service call to revert to the previously
released versions of the models. Refer to the Release Readiness links for more information.
Handout:
http://download.oracle.com/ocomdocs/global/apps_20D/scm/Unrelease_Models_from_Production/Unreleas
e_Models_from_Production.doc
Video:
http://download.oracle.com/ocomdocs/global/apps_20D/scm/Unrelease_Models_from_Production/index.htm
l
Sports
A version of a model is its definition during a specified time period. The definition is made up of item and
supplemental structure, rules, and user interfaces. The version is set when a workspace with its participants
is released, and the version number of each participant is incremented.
The diagram depicts the following example. We see the car model going through changes where some
structure is being added or deleted through the various versions.
In version 1, the Packages option feature is added, which contains the Base Trim and Luxury options.
In version 2, another option, Super Luxury, is added to the Packages option feature.
In version 3, the Base Trim option is deleted and the Sports option is added to the Packages option feature.
Models
• Supplemental structure
• Rules
• UIs
The only workspace participants that are versioned are models. Supplemental structure, rules, and user
interfaces are part of a model. The versions of these constituents of the model are maintained with the
model, but are not accessible to you.
As discussed in earlier lessons, item structure that is imported from the Product Information Management
work area in snapshots has only a single copy of the snapshot in the Configurator Models work area.
When a workspace containing models is released, the models are versioned. A version is different from a
copy in the way its data is managed. There is no duplication of data in a version, unlike the data in a copy.
In versions, only the delta changes for each version are stored. In the Configurator Models work area, the
start date of any version is the effective start date of the workspace that contains the model that is
versioned.
When you create a workspace and add a model that has already been released in another workspace to the
new workspace, you are working on a draft of that model that is based on the released version, which is
considered the baseline version for your model draft. Remember that when a model is imported from PIM
the first time, it is automatically released and its first version, which is referred to as version zero, is created.
Any changes that you make in that workspace are now tracked as changes on top of the baseline version.
None of the changes to a draft appear in production until the workspace is released.
Model V1 V2
version:
• 1 supplemental
+ 10 supplemental node added
nodes • 1 supplemental
+ 8 rules node deleted
+ 2 UIs • 1 rule edited
• Versioning
• Releasing workspaces
• Concurrent development
• Referenced models
• Making the changes in the workspace available for use in a transactional application
such as Order Management
• Scheduled process
• Analysis done on previously released models before starting the scheduled process
• Feedback about impact
• Status updated (use Refresh)
Release the
workspace
Workspace Workspace
status status
This screenshot highlights the Release button and the Status field.
Now that we’ve looked into what a version is, let’s see what release means or what it entails.
To release a workspace, you click the Release button on the page on which you were working with your
workspace. Releasing a workspace is a scheduled process. When the Release action is invoked, the
process is scheduled and started. All the unmodified participants in the workspace are affected when the
workspace is released.
Before the scheduled process is started, an analysis of impact is also performed. What is the extent of
impact that is checked?
• Assume that the workspace that is being released contains a snapshot with an item that is being end
dated.
• This snapshot is used in other models that are already in production. There are rules in these other
models that work now but will not work after this workspace is released.
• This information will be presented to the Product Configurator Manager who intends to release the
model.
As release is a scheduled process, after the Release button is clicked, you need to click the Refresh button
to display the latest status of the release process. While the process is running, the Status is Release in
progress. After the workspace is successfully released, the status is displayed as Released. If there are any
errors during the release operation, the workspace is put back into Development status so that the PCM can
fix any errors.
Prerelease Reports
The act of releasing a workspace into production can potentially have an impact on other models already in
production and could result in undesirable behavior within those models. To understand this impact, you can
run the prerelease report, which simulates the release of the workspace participants into production, prior to
actual release.
The list of all workspace participants that can be included in a release is shown in the slide. All of them will
go into production on release.
You previously learned that releasing snapshots can potentially have an impact on other models that are not
part of the workspace that is being released currently.
The participants in a workspace are released only if they have changes in that workspace. If you have
added models to the workspace for the purpose of testing but have not made any changes to them since the
time they were last released as part of another workspace, you will be warned that they have not changed
and that they will be removed from the workspace when it is released.
• Versioning
• Releasing workspaces
• Concurrent development
• Referenced models
This section discusses how concurrent draft development is a useful tool and how the baseline versions are
changed when one of the workspaces is released.
Workspace-Scoped Development
Workspace: WS1 WS1Fix WS2
Model version:
V1 Draft Draft
Model V1 Draft
V2 Draft
version:
• Versioning
• Releasing workspaces
• Concurrent development
• Referenced models
This section discusses the effects of releasing updated snapshots or reference models on models that are
already in production.
Parent Model 1
Parent Model 2
Referenced Model
Parent Model 3
Parent Model 4
Just like a single snapshot of any item in the Configurator Models work area, there is only one version of a
configurator model for a model item in production, for a given point in time.
This diagram depicts that if a referenced model is referred to by multiple parent models, all of them are
using the same version of it.
Engine Assembly
Model
2 Door Coupe
This diagram depicts an example of how multiple parents use the same referenced model.
There are different car models that use the same Engine Assembly Model. This shared use is a significant
advantage in terms of reducing the data footprint and maintenance of the reference relationships.
Just like snapshots, as we saw earlier, the release of a referenced child model could impact the parent
models that are referring to it and are already in production.
Classic
Sedan SV1 Draft
SV2 Draft
Engine
Assembly EV1 Draft Draft
EV2
Coupe
Draft
CV1
If there is more than one model in the workspace that is being released, each model is versioned
independently. This applies to referenced models as well.
The diagram depicts the following example. You have a Classic Sedan car model, which refers to the
Engine Assembly model.
• You created WS1 and added both these models to it, and you added supplemental structure, rules,
and UIs to these models.
• Then you released WS1, creating new versions of each of these models: SV1 for the sedan and EV1
for the engine.
• Now you had to create another workspace, WS1Fix, to make a production fix. You added both the
models to the workspace.
• The baseline versions used by the drafts in WS1Fix are SV1 and EV1, for the sedan and the engine,
respectively.
• However, the fix involved making changes only to the sedan. The engine model was not touched. So
when WS1Fix is released, the engine is removed from the workspace, and version SV2 of the sedan
is released.
• Now a coupe is being added to your product line and it uses the same engine model as the sedan.
• You created a workspace WS1Coupe to build the coupe model and also to make some changes to
the Engine model.
• You have added the Classic Sedan model to the workspace because you wanted to test and ensure
that the changes to the engine will not break anything in the Sedan model.
• You complete the changes and release the workspace WS1Coupe. Now the Engine model has a
new version EV2 in production and the coupe model has its own version, CV1, as well. The Sedan
model was unchanged, so it was removed on release, without creating a new version.
Releasing a referenced model or an updated snapshot can impact the existing models that are being used
in production. The release process automatically performs an analysis of possible impacts and writes
messages about them to the log of the scheduled process for the release operation.
The diagram depicts the following example:
• The Classic Sedan model structure includes a version of the referenced model Engine.
• In the Classic Sedan model, a rule refers to one of the Engine Type options of Engine.
- The rule text is: ‘Base Trim’ IMPLIES ‘Engine’.‘Engine Type’.‘2.0L turbo
DOIIC [259hp]’
• The Engine Type option referenced in the rule is end dated two months from today.
• A workspace is released that contains:
- A new snapshot of the Engine model that includes the end-dated option
- The rule referring to the end-dated option
• The impact analysis for the release operation detects the effect of the end dating on the rule.
- The scheduled process writes a warning message about the impact in its log file.
- The release operation updates the rule so that it becomes invalid upon the end date of the
Engine Type option, and sets the End Date field for the rule definition in the configurator
model. When the rule becomes invalid, it is ignored at run time.
By analyzing the impacts of releases, the release process is able to help you to avoid later order errors or
unexpected exceptions. Nevertheless, it is always a good practice to add all the impacted models to the
workspace and test them when a reference model with changes, or a snapshot change, is being released.
• Release a workspace and Access the Model in the Released Workspace from Order
Management
In this Demonstration, you learn how to release a workspace and access the model in the released
workspace from Order Management.
In this practice, you generate a Prerelease Report to simulate the release of a workspace.
This section describes an overview of ADFDi Integration and discusses some prerequisites that you need to
follow before you begin supplemental structure management and rule management tasks.
You can use ADF Desktop integration (ADFdi) with Microsoft Excel to maintain a
common supplemental structure across multiple models in a single operation, in a
spreadsheet offline from your development environment.
You can create and update rules across multiple models, and download rules from one
environment and upload to another.
To download the template spreadsheets from the Configurator Models work area:
• On the Manage Models page, select Download Spreadsheet for Managing Model Structure from the
Action menu.
• On the Manage Models page, select Download Spreadsheet for Managing Cross-Model Structure
from the Action menu
• On the Manage Snapshots page, select Download Spreadsheet for Managing Item Snapshots from
the Action menu.
This section discusses how you can manage Supplemental structure using ADFDi.
You can use ADFdi to perform the following actions on a selected set of multiple
models in a single operation.
• Create an option feature and its options
• Associate supplemental attributes and their values to an option feature and its
options
• Manage the date effectivity of attribute values for item snapshots
• Add new options to an existing option feature
• Associate existing supplemental attributes and their values to an existing option
feature
• Update option feature attributes in an existing option feature and option descriptions
in existing options of that option feature
• Update existing supplemental attribute values and associate them with the options of
an option feature
• Delete existing option features and their options
• Remove supplemental attributes and their values associated with the options of an
option feature
• Create, update, or delete option features and their individual options, for multiple
models
• Migrate option features from one environment to another environment.
The following supplemental structure node types are available for ADFdi
management:
• Boolean features
• Decimal features
• Integer features
• Text features
• Option features and its options
Each ADFdi spreadsheet associated with a management task has its own set of
elements. The elements for each spreadsheet are described in the tables on the
subsequent slides.
• There are the following 3 ADFdi Spreadsheets.
• Manage Supplemental Structure
• Manage Cross Model Option Feature
• Manage Item Snapshots Attribute Association
This table describes the spreadsheet for managing supplemental model structure. There are two columns;
the headings are “Elements for managing supplemental model structure” and “Details”.
This table describes the spreadsheet for managing cross-model supplemental structure. There are two
columns; the headings are “Elements for managing cross-model supplemental structure” and “Details”.
This table describes the spreadsheet for managing supplemental structure. There are two columns; the
headings are “Elements for managing cross-model supplemental structure” and “Details”.
This table describes the spreadsheet for managing supplemental attributes and values of snapshots. There
are two columns; the headings are “Elements for managing supplemental attributes and values of
snapshots” and “Details”.
This table describes the spreadsheet for managing supplemental attributes and values of snapshots. There
are two columns; the headings are “Elements for managing supplemental attributes and values of snapshots”
and “Details”.
This section discusses how you can manage Supplemental structure using ADFDi.
You can perform the following operations while managing configurator rules:
• Search for a draft model – by name across all workspaces, or by name of the
workspace
• Create a rule – Enter the rule details in the spreadsheet and upload
• Update existing rule – Download rule data to an ADFDi spreadsheet, make changes,
and upload
• Migrating Rules – From one environment or instance of the Configurator Models
work area to another environment or instance
This slide discusses operations you can perform while managing configurator rules.
In these practice you learn how to manage supplemental structure, option features, rules and snapshots using
ADFGDI Spreadsheets.
Before using this feature, you must have downloaded and installed the latest version of ADF Desktop
Integration with Microsoft Excel, by selecting Download Desktop Integration from the Navigator menu.