Configurator Modeling Course - Student Guide

1
Course Introduction
Configurator Modeling
Schedule: Timing Topic

05 minutes Lecture and Demonstration
00 minutes Practice
05 minutes Total
Course Objectives
After completing this course, you should be able to:

• Describe the integration between host applications and Configurator
• Outline the integration of Configurator with Product Information Management
• Explain concurrent model development
• Explain the various stages of development, editing rules and user interfaces
• Describe the concepts of release and versioning
in the Configurator Models work area
This slide lists the learning objectives for this course.
Oracle SCM Cloud: Configurator Modeling 1 - 2

Course Outline
• Lesson 1: Course Introduction

• Lesson 2: Overview of Configurator Modeling
• Lesson 3: Overview of Work Area and Integration by Snapshots
• Lesson 4: Workspaces
• Lesson 5: Modeling Concepts: Supplemental Structure
• Lesson 6: Modeling Concepts: Rules
• Lesson 7: Modeling Concepts: User Interfaces
• Lesson 8: Versioning and Release
• Lesson 9: Managing Supplemental
Structure and Rules Using ADFdi Integration
This slide lists the lesson topics included in this course.

Instructional Approach
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.
This slide describes the instructional approach for this course.

Intended Audience
This course is intended for:

• Functional Implementers
• Implementation Consultants
This slide describes the intended audience for this course.

Prerequisite Courses and Knowledge
Prerequisite Courses
• Prerequisite Knowledge
• Basic understanding of configurator modeling
• Intermediate understanding of ERP Cloud applications, technology, and navigation
This slide describes the prerequisites for this course.

Documentation Resources
• 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
Active links are in the Student Guide.
• 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

Additional Resources
• Cloud Customer Connect Community

– Configurator Forum
– Supply Chain Management Events
• Order Management Release Readiness Material
• Manufacturing Release Readiness Material
• White Papers
– Updating the Workspace Release Threshold for Oracle Configurator Cloud
Cloud Customer Connect (https://cloudcustomerconnect.oracle.com/pages/home ) is Oracle's online cloud

community — specifically designed to promote peer-to-peer collaboration and sharing of best practices,
enable members to keep pace with product strategy, and provide a cloud solution feedback channel directly to
Oracle development. Within this community, members benefit by leveraging the collective knowledge of Oracle
Cloud customers and product experts.
• The Forum (https://cloudcustomerconnect.oracle.com/resources/8ff48b6562/summary) enables you to
network and collaborate on real-life challenges and solutions with fellow members. Share best practices as
you strive to deliver consistent, personalized customer experiences, and connect every customer
engagement with your brand.
• The Events (https://cloudcustomerconnect.oracle.com/resources/4cb7a01b8c/summary) tab lists upcoming
and replays of Supply Chain Management Events
The Order Management Release Readiness Materials page
(https://cloud.oracle.com/saas/readiness?offering=order-management) allows you to learn about the latest
innovations in our Supply Chain Planning products.
The Manufacturing Release Readiness Materials page
(https://www.oracle.com/webfolder/technetwork/tutorials/tutorial/readiness/offering.html?offering=manufacturin
g-manufacturing-20) allows you to learn about the latest innovations in Manufacturing products, specifically
details about configuration.
White Papers
• Updating the Workspace Release Threshold for Oracle Configurator Cloud
(https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=251658745180653&id=24712
88.1&_afrWindowMode=0&_adf.ctrl-state=12591npm9d_4)

Customer Connect Training Replays
• Customer Connect Training Replays:

• Oracle Supply Chain Management Integration Lesson
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.

Use Deep Links to Speed Navigation
• Provide easy navigation directly to application pages
without using the menu structure.
• Use in a variety of ways, such as in business
intelligence reports and third-party application pages.
• All available deep links are in the Deep Links work
area.
• Refer to these books on the Oracle Help Center
• See Oracle Applications Cloud: Configuring and
Extending Applications
• Oracle SCM Cloud: Implementing Common
Features for Oracle SCM
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
Oracle Procurement Cloud: Procurement Implementation 7 - 10

2
Overview of Configurator Modeling


0 minutes Practice
25 minutes Total
Learning Objectives
After completing this lesson, you should be able to:

• Outline the integration with Order Management and Configurator Modeling
• Create an order with a configurable product
• Use the Configurator runtime to configure a product
• Explain the actions available within the Configurator User Interface
• Identify the contents of the Review Configuration page
• Identify the contents of the View Components page
• Validate and submit an order with a configured product
This slide states the learning objectives for this lesson.

Topics
• Overview of Configurator Runtime

• Configurator Runtime User Interface
• Integration with Order Management, Pricing, and Configurator, Price, and Quote
This section discusses how Configurator is used by end users, such as order entry managers or order entry
specialists.

Centralized Management of Products Configured to Unique

Configurator Models Customer Needs
Simplified Configuration of Complex Cloud Enabled and Integrated with

Solutions Order Management
You use the functionality of Configurator Modeling in two distinct areas:

• Configurator runtime application: Used during order entry to enable you to configure products that
meet the unique needs of the customer. For example, you can configure a card for specific interior
colors, features or trim.
• Configurator Models work area: Provides a model building workbench that simplifies the building of
complex models by enabling you to write rules against a model. This workbench also enables you to
create multiple user interfaces for a configurable product by using images and styled text along with
the UI controls for configurable options.
• The Configurator runtime is integrated with Order Management (a host application), so that users
can configure and validate complex orders of items.

Overview of Configurator Runtime
• Dynamic runtime UI (embedded task flow)

• Validation service
• Seeded UI templates and template maps
• Runtime UI definition
UI conditions in UI editing
Configurator
•
User Interface
• Visual UI page editing Templates
• Testing of model behavior and user interfaces

• Transactional item attributes
• Integration with pricing cloud
• Configure Models and Related Items using Connectors
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.

• The Configurator runtime is integrated with Pricing, so that product prices are calculated and displayed
while an item is being configured. You can also:
- You can disable configurator model pricing using an Order Management system parameter. The
default behavior is always to call pricing in a configuration session to price all configurator model
nodes. You can choose to turn off pricing in a configuration session for all configurations.
- You can generate a user interface (UI) that optimizes user interface controls for large option classes.
UI template maps default to item selection tables for option classes with greater than 25 items. Item
Selection Table Templates also allow you to scroll to or search for items within the option class.
- You can skip configuration validation when it’s not required to optimize performance during order
import, submission, and validation for configurator models. Configurator models are defined within the
Configurator Models work area that add supplemental structure, rules, and pages to imported
snapshots.
- You can also skip configuration validation when it is not required to optimize performance during order
submission and validation for native PIM models. Native PIM models are those models that are based
solely on their item structure definitions defined within the Product Information Management work
area.
• You can configure models and related items using connectors:
- You can design configurator models with connectors to automatically add services or related items to
a configuration. You can also write extension rules that use connectors to select the items that may be
associated with the configured product. You can use REST services as well.
- You can copy connected items and services with expanded configuration REST service.
- You can display the price for connected items or services in the configurator running summary and
configuration summary. Connected items and services are displayed as root-level lines in the
configuration summary. The price for the connected items and services is included in the total net
price for the configuration.

Topics

• Configurator Runtime User Interface (UI)
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.

Configurator Runtime UI
The UI is dynamically assembled at
runtime by using templates.
• Templates provide look-and-feel and
interactivity.
• Seeded templates are available for all
major navigation and controls.
• Visual UI editing of pages is possible
in the Configurator Models work area.
Based on Oracle’s Application
Development Framework (ADF)
• Java Server Faces (JSF) UI
component technology
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.

Template-Driven User Interfaces
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.

Templates in the Runtime UI
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.

Topics

• Configurator Runtime User Interface
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.

Integration with Order Management
• The Configurator UI is embedded within the Order Management UI when a product is

being configured.
• Reconfiguration is supported during the revision of an order.
• Configuration and validation services are provided for models.
• Configuration details are not saved until the order is saved.
• Pricing Segment and Strategy information to price the configuration are obtained
from the order.
• For pick to order (PTO) models, Included Items are added to the order when
configuration details are returned to the order.
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.

Integration with Oracle Pricing Cloud
• Define configured item pricing in Pricing application

• Display accurate pricing at runtime
• Display prices for items
• Display prices and totals on the Review page
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 with Oracle Configurator, Price, and
Quote (CPQ)
• Configurator is integrated with Order Management System:
– For capturing configured orders directly in Order Management
– For modifying and revalidating configurations during the fulfillment cycle
– For EDI and back office channels
– With close connection to item structure and manufacturing
• CPQ configurator is integrated with Configure, Price, and Quote Cloud:
– For quoting and order capture in sales channels
– With close connection to deal configuration and CRM
• Configure to Order flow supported for both, through OMS.
Benefits of Configurator Compared to CPQ Configurator

Order Management System Cloud (OMS) and Oracle Configure, Price, and Quote (CPQ) Cloud use
different configurators, each with their own strengths.
Channels:
• OMS Cloud is a strong choice when directly entering orders in FOM, for electronic data interchange
(EDI), and for back office channels.
• CPQ Cloud is a strong choice for direct sales and reseller channels.
Strengths:
• Configurator is closely connected with item structure and product manufacturing.
• CPQ configurator is closely connected with configuration related to deals, and with customer
relationship management (CRM).
Order capture:
• If orders are captured through OMS Cloud, use the Configurator integrated with OMS.
• If orders are captured through CPQ Cloud, use the configurator integrated with CPQ.
Instructor Note
The CPQ configurator was formerly the BigMachines configurator. A future “mash-up” UI will add Fusion
Configurator into the CPQ Cloud UI.

Integration with External Applications
• The Configurator user interface can be embedded into third-party applications

– Modified or default configurator UI
• Configurator web services
– Initialize, create, or restore configurations
– Validation of orders being imported to Order Management
• UI enhancements
• You can obtain data from external web services
– Register the web service
– Define extension rules that invoke the service, using the invokeSoapService() API
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

expanded during validation, and values of TIAs are matched with configured items.
Oracle SCM Cloud: Configurator Modeling 2 - <#>

UI Enhancements
External applications can enhance the configuration by using:
• A continuous running summary of item selections and prices
• Modified UI captions for actions that terminate the configuration session, replacing default captions
such as Finish.
Obtaining Data from External Web Services
You can invoke an external web service from within an extension rule, to access an external source that
assists in the proper configuration of a model.
To invoke an external service:
• Register a connection to the web service using the task Manage External Service Details for
Extensions in the Setup and Maintenance work area.
• Define an extension rule that builds an XML payload and passes it to the web service using the API
invokeSoapService().

Demonstration: 2-1
• Creating an Order with a Configurable Product
In this demonstration, you create an order with a configurable product.

Summary
In this lesson, you should have learned how to:

• Outline the integration with Order Management and Configurator
• Create an order with a configurable product
• Use the Configurator runtime to configure a product
• Explain the actions available within the Configurator UI
• Identify the contents of the Review Configuration page
• Identify the contents of the View Components page
• Validate and submit an order with a configured product
This slide reviews the objectives you learned in this lesson.

3
Overview of Work Area and Integration by

Snapshots

0 minutes Practice
45 minutes Total
Learning Objectives

• Describe the Configurator Models work area
• Describe the integration of the Configurator Models work area with Product
Information Management
• Describe the function of snapshots
• Differentiate the various levels at which a snapshot can be refreshed

Topics
• Configurator model life cycle

• Item structures
• Snapshots
• Refreshing snapshots
This section discusses some fundamentals about the Configurator Models work area.

Configurator Model Life Cycle
Initial Product Definition to Configurator Model Release
Define Item Import Build your

Release
Structure in Snapshot into Configurator Test Model
Workspace
PIM CM Model
Structure Rules UIs
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
Import / Refresh Manage

Product Supplemental
Management Data Structure
Manage Model available

Rules in production
Release to be used from
Order
Management
Manage User
Interfaces
Test Model UI and

Behavior
Configurator Modeling Process

This diagram depicts the process of building configurator models in relation to the tasks that you perform in
the Configurator Models work area.
• After you import an item structure into the Configurator Models work area as a snapshot and
corresponding configurator model, you create a workspace in which to build a draft version of a
configurator model based on the item. You design versions of the model to provide specific types of
configuration behavior when an end user is configuring the item. A workspace is the container that
enables the development of a particular version of the model, where you manage supplemental
structure, rules, and user interfaces. (The term “manage” refers to creating, editing, and deleting
objects.)
• You can add supplemental structures to the configurator model, which is a set of additional options
that you add to the item structure, to facilitate better end-user experience. As we proceed in this
course, you will learn about the different types of supplemental structure.
• Almost every configurator model includes rules, which are constraints that you add to the model.
Rules can prevent the end user from selecting items that do not belong in a valid configuration. Rules
can also drive the selection of items based on the end user’s selection of other options.
• You can also create user interfaces that are driven by the structure of the configurator model, which
provide an intuitive end-user experience while configuring the model.
• You can test the behavior of the resulting configurator model in the Configurator Models work area
before releasing it into production.

Configurator Models Work Area
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.

Topics

• Item structures
• Snapshots
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.

Item Structures
Define Item Structure
(Items and Item Structures)
Structure Component Attributes
(Optional, Mutually Exclusive, Instantiation)
Create Items
Define Item Classes

Define UDAs, TIAs
Define Attribute Groups

Define Value Sets
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.

Car Model
Item structure defined in Product Information Management work area
Interior Options Mechanical Exterior Options

Options
• Seats • Wheels
• Seat Trim • Engine • Accessories
• Interior Color • Drive Type • Color
• Audio • Traction Control
• Interior • ABS
Accessories
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.

Car Model
Item structure defined in Product Information Management work area

Options
• Seats • Wheels
• Seat Trim • Engine • Accessories
• Interior Color • Drive Type • Color
• Audio • Traction Control
• Interior • ABS
Accessories
Seat Trim
• Leather
• Cloth
• Sport
Item Structure of Options

This diagram depicts the Seat Trim example. If you look further at the Seat Trim option, it is an option class
item with several possible items to select from: Leather, Cloth, or Sport.
An option class is a kind of container that holds together similar items from which the end user can make a
selection.
This example gives you an idea of how an item structure can be organized. In this example of the car, Seat
Trim is an option class within the Interior Options option class, which in turn, is part of the item structure of
the Car model item.

Topics

• Item structures
• Snapshots
This section discusses the concept of a snapshot in the Configurator Models work area.

Snapshots
• 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
Management work area

• Model Item Snapshot
– Item structure
– Structure component attributes
– Operational attributes
– User-defined attributes (UDAs)
Snapshots are read-only copies of Product entities.

• Only a single copy of a product master item is kept as a snapshot, duplicate copies of the item are
not allowed in the Configurator Models work area. Configurator models can use only the imported
snapshots that are part of the item structure in the Product Information Management work area.
• When there is a change to a PIM Item, the Product Configurator Manager (PCM) must explicitly
refresh the snapshot to bring the changes into the Configurator Models work area.
• Refreshed snapshot changes are not released directly to production. The PCM must add the
modified snapshots to a workspace to ensure that the changes are tested and considered in all
rules, before releasing the workspace with its constituents for production use.
• The Manage Snapshots task hosts the action to import a model item.
• The Import Model Item action runs as a scheduled job when it is invoked from the Configurator
Models work area.

Snapshots
• 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
This diagram highlights workspace and models created by snapshot import.

Snapshots and Versioning
Versioning is the process by which incremental changes to configurator models are controlled. When a
workspace is released into production, the models in it are assigned a new version number. Versioning is
explained fully in the Versioning and Release lesson.
Versioning has the following important relationship with snapshots:
• When a model item is first imported from Product Information Management into the Configurator
Models work area, a baseline version of the snapshot of that model item is released.
• This baseline version is also referred to as version zero, because its version number is 0.0.
• The baseline versions of all the constituents of the imported model item (option classes, standard
items, reference models, item classes, and value sets) are also released as version zero.
• If the model is configured from a transactional application before a completely developed
configurator model goes into production via a workspace release, the baseline version of the model
is used instead.

Snapshots Shared Across Models
Only one snapshot per item
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.

Snapshots Shared Across Models
All models use the same snapshot of that item.
4 Door Classic Sedan
4 Door Hybrid Sedan
Seat Trim
2 Door Coupe
4 Door Plug-in Sedan
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.

Topics

• Item structures
• Snapshots
This section discusses how snapshots are managed or maintained when there are updates to existing items
or structures in Product Information Management.

Purpose of Refreshing Snapshots
Brings updates from Product Model into Configurator Snapshot
Product Manager Product Configurator Manager
Seat trim Seat trim
Leather Refresh Leather
Cloth Cloth
Sport Sport
Limited Edition Limited Edition

Sep. 1 to Dec. 31 2015
Sep. 1 to Dec. 31 2015
Product Data Snapshot Data
This diagram depicts the following example:

Assume that the Seat Trim option class has an additional item called Limited Edition, which is added to its
item structure.
If end users need to see this option for selection, the snapshot item for Seat Trim that exists in the
Configurator Models work area needs to be refreshed.

Refreshing Snapshots
• User can run a refresh as a scheduled process, similar to import.

• The snapshot statuses include:
– Released
– Modified
• The snapshots that can be refreshed include:
– Items (models, option classes, and standard items)
– Item classes
– Value sets
• The snapshot Refresh Modes are:
– Refresh (single item snapshot)
– Refresh, including descendant structure
– Refresh, including descendant and reference structure
Running the Refresh Operation

Like Import, the Refresh operation runs as a scheduled process.
• Any new items that are brought into the Configurator Models work area by the refresh process are
immediately released to production, and have the status Released in the Configurator Models work
area. This immediate release is performed because new items have minimal impact on existing
models. Refresh brings in only changes that are approved in the Product Information Management
work area.
• Updates to existing items that are brought in by the refresh process, however, are shown with a
Modified status. The assumption is that the PCM would add these modified snapshots to a
workspace, test the behavior of the affected models, and release the workspace upon successful
testing. After the workspace is released, the snapshot status is changed from Modified to Released.
The refresh operation can be run in three modes, depending on how extensively you want to reflect the item
changes in your configurator model:
• Refreshing just the item itself. This is also available for item classes and value sets.
• Refreshing the item and its descendant structure of child items
• For items that have reference models in their structure, refreshing both the descendant and
reference structures

Manage Snapshots
Review the imported and refreshed snapshots.
Refreshed Snapshot, Status

New Snapshot, Status = = Modified
Released
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.

Snapshot Refresh Scenarios
Refresh single item snapshot.
Updated Snapshot
This screenshot depicts the following scenario.

Scenario: Refreshing a Single Item Snapshot
Refreshing an item snapshot, without including its descendant or reference structure, brings all approved
changes to that item into the snapshot in the Configurator Models work area, including the additional items
that are added to the item’s structure.
In the example shown in the slide, a product manager has added a new future-effective option class called
Accessories to the structure of the 4 Door Classic Sedan model item in the Product Information
Management work area. When the model item snapshot is refreshed in the Configurator Models work area,
the refresh brings in only the changes to the model item, namely:
• Operational attributes of the item itself
• Immediate item structure, meaning the immediate child items of a model item, or options of an option
class
• The operational attributes of the child items or options

Refresh item snapshot, including its descendant structure.

Updated Snapshot
Updated Snapshot

Scenario: Refreshing a Snapshot with Descendant Structure
Refreshing an item snapshot can be performed by selecting the option to include its descendant structure.
In the example shown in the slide, in addition to model item changes, the Seat Trim option class under the
Interior Options option class has changes in PIM that are not yet brought into the Configurator Models work
area. When the PCM user refreshes the 4 Door Sedan model item and chooses to include the descendant
structure, the refresh updates the status of two snapshots to Modified: the 4 Door Sedan model item and the
Seat Trim option class.

Refresh item snapshot, including its descendant and referenced structure.

Updated Snapshot
Updated Snapshot
Updated Snapshot

Scenario: Refreshing a Snapshot with Descendant Structure and Referenced Structure
Refresh can include not only the snapshot descendant structure but also its reference structure. It is typical
to use referenced models when you are working on a root model and you want to ensure that all the
changes in PIM that are related to this model are brought into the Configurator Models work area.
In the example in the slide, assume the following in the 4 Door Sedan model:
• The Drive Type option class had a change.
• The Engine Assembly referenced model had a change.
• The Accessories option class was added to the 4 Door Sedan model.
All these snapshot changes can be refreshed at the same time by using the refresh option to include the
descendant and referenced structures.

Refreshing an item class snapshot

• Changes to an item class can be refreshed without refreshing any item.
• When the updated item class snapshot is added to a workspace, the corresponding
changes are seen in the items in that workspace that belong to the item class.
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.

Summary

• Describe the Configurator Models work area
• Describe the integration of the Configurator Models work area with Product
Information Management
• Describe the function of snapshots
• Differentiate the various levels at which a snapshot can be refreshed

4
Workspaces

25 minutes Practice
45 minutes Total
Learning Objectives

• Describe the function of workspaces
• Create a workspace and add models to it

Topics

• Workspaces basics
• Workspaces and model development
This section discusses what a workspace is in the Configurator Models work area.

Configurator Life Cycle
Initial Product Definition to Configurator Model Release

Release
Structure in Snapshot Configurator Test Model
Workspace
PIM into CM Model
Structure Rules UIs
Ongoing Draft Model Management
Refine/Modify Refresh Modify your

Release
Item Structure Snapshot Configurator Test Model
Workspace
in PIM in CM Model
This diagram depicts the Configurator life cycle.

In the Work Area Overview and Integration by Snapshots lesson, you learned how the life cycle of a
configurator model progresses from the initial definition of a product item to the release of the configurator
model in a workspace.
After the workspace is released, there are likely to be ongoing changes to the model in the Product
Information Management work area, or to the supplemental structure, rules, and UIs in the Configurator
Models work area. These changes typically follow the following cycle:
• Refresh the items having changes in PIM.
• Add the items to a workspace in the Configurator Models work area.
• Make additional changes required to the supplemental structure, rules, and UIs.
• Release the workspace.

Workspace in the Configurator Modeling Process
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.

Topics

This section discusses what a workspace is and how models and snapshots can be added to a workspace.

Function of Workspaces
• 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.

Attributes of Workspaces
• 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.

Participants in Workspaces
• 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.

Locking and Unlocking Models in Workspaces
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.

Topics

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.

Workspace Effective Start Date and Snapshot
Effectivity
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.

Concurrent Model Development
Same models can be worked on simultaneously.
WS1 T0 – V0 Released WS1 Created
Classic WS2
Sedan
T1 – WS2 Created
Draft
Classic
Engine Sedan
Draft
Assembly
Engine
Baseline versions for the models Assembly
is V0
T2 – WS1 Released Baseline versions for the models is V0

Create a Step-by-Step UI to be used from
when WS2 is created at T1
Order Management
New Versions
At T2, the baseline versions for the models
is updated to the version created when WS1
is released
T3 – WS2 Released Add Model Rules; enhance the Step-by-

Step UI
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.

Practice: 4-1
• Creating a Workspace and Adding a Model to the Workspace
In this practice, you create a workspace and add a model to the workspace.
Note To Instructor: Please demonstrate this process in class first.

Summary

• Describe the function of workspaces
• Create a workspace and add models to it

5
Supplemental Structure

30 minutes Practice
60 minutes Total
Learning Objectives

• Describe Supplemental Structure and how you can use it
• View the item structure that is imported from Product Information Management and
add supplemental structure to models
• Edit a model in a workspace

Topics
• Elements of a configurator model

• Supplemental structure
This section discusses the elements of a configurator model.

Supplemental Structure, Rules, and UIs

Release
Workspace
Product Hub into CME Model
Structure Rules UIs
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
In this lesson, we will focus on managing Supplemental Structure.

Modeling Tasks
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
Model Management Tasks in the Configurator Modeling Process

In the Work Area Overview and Integration by Snapshots lesson, you were introduced to the tasks for
managing supplemental structure, rules, and user interfaces as parts of a configurator model, and for testing
the model before releasing it into production.
This diagram highlights the Model Management tasks, which are the focus of this lesson.
This diagram highlights how Product Management Data is imported into the Workspace, where model
management tasks are performed before releasing.

Topics
• Elements of a configurator model

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

Release
Workspace
Structure Rules UIs
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.

Car Model
• Model Item Structure

• PIM Item Structure
Interior Options Mechanical Options Exterior Options

• Seats • Engine • Wheels
• Seat Trim • Drive Type • Accessories
• Interior Color • Traction Control • Color
• Audio • ABS
• Interior
Accessories
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.

Car Model
• Model Item Structure: Sub-Options

• PIM 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

•Engine •Wheels
• Seats •Drive Type •Accessories
• Seat Trim •Traction Control •Color
•ABS
• Interior Color
• Audio
• Interior
Accessories
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.

Imported Structure Becomes Model Structure
PIM Item Structure Configurator Model 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.

Car Model
Adding Supplemental Features
Base Option Packages

•L- Base Trim
•LX - Luxury Package
•GLX - Super Luxury Package
•SX - Sports Package

•Seats •Engine •Wheels
•Seat Trim •Drive Type •Accessories
•Interior Color •Traction Control •Color
•Audio •ABS
•Interior Accessories
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.

Adding Supplemental Structure
• Start with imported model item snapshots.

• Add supplemental structure as needed
– Option features and options
– Boolean features
– Integer features
– Decimal features
– Text features
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.

Customer Options Modeled as Supplemental
Structure
In the Car model: In the configurator model:
Set of Base Option Packages Option feature with options

• L- Base Trim
• LX - Luxury Package
• GLX - Super Luxury Package
• SX - Sports Package
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.

Adding Supplemental Attributes in Structure
You can add Supplemental Attributes:

• To supplemental nodes, in the Configurator Models work area
• To item-based nodes, using the ADFdi interface to the Configurator Models work
area
• When creating a new supplemental attribute or adding an existing supplemental
attribute to a model node, the value set for the values of the supplemental attribute
must already exist.
To add a supplemental attribute to a node:

1. Open the model draft to which the supplemental attribute will be added.
2. Select the supplemental structure node, then select the Supplemental Attributes subtab.
3. Click the Add button.
4. Open the list for the name of the supplemental attribute to add. Search for and select the desired
supplemental attribute. When you select the supplemental attribute, the default values for its
description, value set, and data type are added, and the default value, if any, of the supplemental
attribute is selected. Optionally, you can also create a new supplemental attribute here, in addition to
selecting one.
5. You can specify a different value, but you can't change the other elements of an existing
supplemental attribute. You can't add the same supplemental attribute to a node more than once.
6. Save the model draft. SAs added using the steps above will be saved when you save the model
draft.

Demonstration: 5-1
• Creating Supplemental Structure
This demonstration shows how you add supplemental structure to a model in the Configurator Models work
area.

Practices: Overview
• 5-1: Creating Supplemental Structure
In these practices, you create supplemental structure, rules as well as create and modify user interfaces.

Summary

• Describe Supplemental Structure and how you can use it
• View the item structure that is imported from Product Information Management
and add supplemental structure to models
• Edit a model in a workspace

6
Modeling Concepts: Rules


30 minutes Practice
60 minutes Total
Learning Objectives

• Explain the differences between the default, constraint, and search decision rule
classes
• Create rules for a model
• Create extension rules

Rules

Release
Structure in Snapshot into Configurator Test Model
Workspace
Product Hub CME Model
Structure Rules UIs
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.

Car Model: Defining a Rule
Customer
selects a
package
•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

•Seats Options •Wheels
•8-way Power Seats •Engine •16" Steel
•Seat Trim •2.0L turbo DOHC Wheels
•Cloth •Drive Type •Accessories
Rules select •Interior Color •Traction Control •Color
options for that •Audio •ABS
package •Interior Accessories
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.

Creating Statement Rules
1. Create statement rules.

a. Defaults
b. Constraints
c. Search decisions
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.

• Search decisions are rules that are hints to the configuration engine to process certain selections
when the configuration is being finished.
- Continuing the hard drive example, assume that there is no supplemental structure to guide
the end user, but that a hard drive is required for a laptop to be assembled. The user has,
however, selected other options, such as the RAM and CPU speed. You can define a rule as
a search decision, which makes the configurator engine (the part of Configurator that
processes and enforces rules) to pick a 20 GB Hard drive automatically when the user
finishes the configuration.

Creating Statement Rules in the Rule Editor
Check rule status
Select rule class
Validate rule text

Create CDL rules for
this model draft
Use menus to insert CDL

Enter CDL rule text syntax
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.

Inserting Model Structure References into Rule Text
Structure Pane
Model node to be
referenced in rule
Inserted model node

reference
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()

Inserting Rule Text with Menus and Buttons
Insertion menus and

buttons
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.

Demonstration: 6-1
• 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.

Creating Extension Rules

– Base node
– Rule script
– Events and bindings
About Extension Rules

You create extension rules by writing code in the Groovy language and attaching the code to a model.
Extension rules:
• Extend the functionality of rules through code
• Use the Configurator Runtime Core API to interact with the model
• Are triggered by actions in the model during a configuration session
Extension rules enable you to:
• Modify behavior of the model
• Obtain external data through a web service
• Use complex calculations on model data

Extension Rules
Elements of extension rules

1. Script that defines behavior
a. Uses Groovy scripting language
b. Provides model interaction using established Java interfaces
2. Connection to model and configuration session
a. Events: Occur on the model during configuration
b. Base Node: Where the rule listens for events
c. Event Bindings: Connect methods to events
d. Argument Binding: Connect method arguments to model
About Extension Rules

There are two components of extension rules:
• The script code that provides behavior in the context of a model
• The elements of the rule that connect the behavior to the model, and define when and where it’s
triggered
The code is written in Groovy, a flexible and convenient language for the Java platform, using established
Java interfaces that provide interaction with Configurator models.
The connecting elements depend on events, which are identifiable actions or conditions that occur in a
model during a run time configuration session, such a change in the value of a node. Examples of events
are:
• postValueChange: occurs after the value of a node is changed
• postConfigInit: occurs after initializing a configuration session
• postConfigSave: occurs after a configuration is saved
• preAutoComplete: occurs before the autocompletion process runs
Each extension rule has a base node. When an event occurs on the base node, the extension rule is
triggered. A specified event, such as postValueChange, is connected to a method in the rule code by an
event binding. An extension rule can have multiple event bindings. If a code method has arguments, each
argument has an argument binding that provides its value.

Creating Extension Rules in the Rule Editor
Validate rule and script.
Validate rule and script
Set base node
Edit rule script, in

Groovy language
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.

Binding Extension Rules to the Model
Set event bindings
Set argument bindings
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.

Extension Rule Scripts
Scripts are written in the Groovy language.

1. Object-oriented, dynamically compiled scripting language for the Java platform
2. Flexible, convenient syntax that detects types at run time
3. Uses Configurator Runtime Core API
a. Designed expressly for interaction with configurator models
4. Example:
config = cxEvent.getConfiguration()
a. Get the configuration object that is associated with the event bound to the base
node of the rule.
Writing Extension Rule Scripts

Groovy is an object-oriented, dynamically compiled scripting language for the Java platform, widely
described elsewhere, at http://groovy-lang.org, and other public sources. Features for convenience and
flexibility include:
• Automatic import of many Java packages
• Declaration of variables without declaring their type, using the def keyword
• Global variable and method definitions
Objects and methods in the Configurator Runtime Core API for interacting with models include:
• IConfiguration: The active configuration
• ICXEvent.getConfiguration(): Get the configuration associated with the triggering event on
the base node
• IBomModelInstance: The root node of the configured model
• IIntegerFeature.setValue(): Set the value of an integer node
• IOptionFeature.select(): Select one of a set of options
• IBooleanFeature.toggle(): Switch value between True and False

Using Supplemental Attributes in Rules
You can use supplemental attributes in configurator rules.

For example, you can define an attribute-based compatibility rule between a user-
defined attribute of an item-based model node and a supplemental attribute of a
supplemental model node, to determine compatible options. The syntax for referring
to a supplemental attribute in CDL is:
Example:
<nodePath>.suppAttrs["attrName"]
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.

Practices: Overview
• 6-1: Creating Rules
In these practices, you create supplemental structure, rules as well as create and modify user interfaces.

Summary

• Explain the differences between the default, constraint, and search decision rule
classes
• Create rules for a model

7
Modeling Concepts: User Interfaces


30 minutes Practice
60 minutes Total
Learning Objectives

• 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

User Interfaces

Release
Workspace
Structure Rules UIs
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.

Creating User Interfaces
• Create user interfaces

– Create UI
– Edit or update UI
This slide highlights the key steps involved in creating user interfaces.

Building Blocks for UIs
Templates
• Shell templates Shell Layout
UI Templates Templates
Master
• Layout templates Template
Template
Map
• Control templates Control behavior

Control Message
Common content
Templates Templates
• Message templates Navigation Style
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.

Building Blocks for UIs
UI Template Maps Node Type Template
Option Class
• Map model node detail types to
templates that represent them
Radio button group with quantity
• Determine the navigation style

within the UI
Check box group with quantity
Model
Reference
Item Selection Control
Item Selection Control with Quantity
How Template Maps Map Structure to UI Elements

This screenshot depicts how template maps maintain the mapping between types of items (such as standard
items, option classes, or reference models) and the control templates that allow users to interact with the
items. Examples of such mapping are as follows:
• If an option class is defined as having mutually exclusive options, it is mapped to a radio button
group control template.
• If an option class is not mutually exclusive (that is, more than one item from its children can be
selected), it is mapped to a check box group control template.
• A required model reference is mapped to an item selection control template.
The item information from the model and the template map that maintains the mapping between the item
type and the control templates are read dynamically to assemble the Configurator runtime UI that is
presented to the end user to configure a model. The same logic is used when a UI is created in the
Configurator Models work area that the PCM can further modify by using a WYSIWYG editor.

Optional UI Templates
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
Enhancing Selection with Images

This screenshot depicts how you can use a selectable image UI template to represent items in the run time
UI with their images rather than with their names.
In the model structure, you associate standard items, or options of option features, with a set of image files
that show the item as being unselected (but available), selected, or excluded. The image files must be
stored in Universal Content Management. In the UI definition, you edit the UI page item representing the
selectable item, and specify the use of a Selectable Image Group template, with or without a header. You
can specify optional formatting to control the layout and CSS attributes of the image at run time.
During the run time configuration session, the options are initially displayed with the images for their
unselected states. Selecting an option displays the image for the selected state of that option. If a rule
excludes an option, then the image for the excluded state of that option is displayed. If you haven’t provided
one of the state images, then substitutes are displayed: a rectangle for selection; image dimming for
exclusion.

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.

Instance Management Table
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.

Single Page Navigation Style
• Content on a single page

• Scroll if required
• Drill down to reference model UIs
Referenced model Configure control
Single Page Navigation Style

Configurator supports three navigation styles in a default installation. These navigation styles are available
only when the Configurator Models work area is used to create UIs.
This screenshot depicts the Single Page navigation style that collects all the configurable options of a
model onto a single page. If a model has reference models, the user can drill down into the UI for the
reference model by clicking the Configure control on the reference to the reference model.
The UI-level actions that the 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 the remaining selections that required for a
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 Order Management
from where Configurator is invoked.
Note: In the event that a model is being configured in a host application, and no corresponding configurator
model with a UI exists yet, the Single Page UI is displayed for the end user to configure the model.

Dynamic Tree Navigation Style
• Navigate by using the tree links

Dynamic Tree Navigation Style

This screenshot depicts the Dynamic Tree navigation style that allows end users to navigate to a specific UI
page by using the tree links that are displayed in the left pane. When the UI is created, each of these tree
links is created as a page.
If a model has reference models, the user can drill down into the UI for the reference model by using the
configure icon that is displayed next to the reference model. There is no tree link available to navigate to
reference models, but the user can drill down into the UI for the reference model by clicking the Configure
control on the reference to the reference model.
This navigation style provides the same UI-level actions as the Single Page scheme.

Step-by-Step Navigation Style
• Navigate by using steps

• Train indicates the current step
Step-by-Step Navigation Style

This screenshot depicts the step by step navigation style that allows end users to navigate to a specific step
by using the train steps that are displayed at the top of the page. When the UI is created, each of these tree
links is created as a page.
If a model has reference models, the user can drill down into the UI for the reference model by using the
configure icon that is displayed next to the reference model. There is no train step available to navigate to a
reference model, but the user can drill down into the UI for the reference model by clicking the Configure
control on the reference to the reference model.
This navigation style provides the same UI-level actions as the Single Page scheme. In addition to those
actions, there are two additional buttons, Back and Next, which are available to enable navigation to the
previous or the next step.

Creating a User Interface
• Predefined template maps to

choose from when a UI is created
• Two maps for each navigation
style
• Special map only for testing
within work area
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.

UI Editing: WYSIWYG Editor
• Change layout or control

templates
• Add pages, regions, items,
text, images, spacers
• Move or delete UI content UI page
• 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.

Visualize Product Configurations in 2D and 3D
To ensure the final

configured product is
visually accurate, you
can add a third party
visualization tool to
your Configurator
User Interface to view
your configured
product in 2D or 3D.
This screenshot depicts a 3D model of the 4 door sedan at runtime.
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.

UI Editing: Display Conditions
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.

Modifying UI Element Captions
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 }
This table describes the tokens of the UI expression language.

Every expression is enclosed with the following delimiters: # { expression }. To override the default display
name of a UI element:
1. Select the UI element.
2. You can modify the following UI elements:
• Page Item Caption of a Page Item element
• List Item Caption of a List Item element, which can be part of a Page Item
3. Click the Edit control for UI element.
4. In the Edit dialog box, enter a UI expression for the Caption of the UI element.
5. Click OK in the Edit dialog, save the UI, and click Test Model.
6. In the test UI, the caption appears with the overriding expression text.

Using UI Facets
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.

8. Save your changes to the UI, and click Test Model.
Oracle SCM Cloud: Configurator Modeling 7 - <#>

Model Changes and UI Updates
• Ineffective and deleted nodes

– Filtered from the UI at run time
– Page based on an ineffective model node hidden
– Display conditions ignored
• Added nodes
– The added nodes must be manually added to the UI. Exceptions include:
— Options and items of an option feature or option class
— Transactional item attributes of an item
– New UIs created after the addition will include the new nodes.
• Changed nodes (instantiation type, quantity)
– Existing UI will work.
– The templates that are used for such items can be manually changed.
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.

Practices: Overview
• 7-1: Creating and Modifying User Interfaces
In this practice, you create and modify user interfaces.

Summary
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

8
Versioning and Release


45 minutes Practice
90 minutes Total
Learning Objectives

• Describe the concept of versioning in the Configurator Models work area
• Release a workspace
• Describe how concurrent drafts are affected with release
• Explain how existing models are impacted when a workspace containing a snapshot
or referenced model is released

Topics
• Versioning
• Releasing workspaces
• Concurrent development
• Referenced models
This section discusses the concept of versioning in the Configurator Models work area.

Release Workspace
Define Item Build your

Import into Release
Structure in Configurator Test Model
CSnapshotME Workspace
Product Hub Model
Structure Rules UIs
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

Version
Definition of an Object for a Time Interval
Version 1 – T1 Version 2 – T2 Version 3 – T3
Car Model Car Model Car Model
Packages Packages Packages
Base Trim Base Trim Base Trim
Luxury Luxury Luxury
Super Luxury Super Luxury
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.

What is Versioned in Configurator?
Models
• 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.

Versioning
Organizing changes by version

• How are model versions stored in Configurator Models work area?
– No data duplication
– Only deltas stored for each version
– Version start date = workspace effective start date
• Model drafts
– Created when added to the workspace
– Changes scoped under the workspace
– Changes not in production
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.

How Does Versioning Work?
Dynamic and Cumulative
Workspace: WS1 WS1Fix (created after WS1 is released)
ESD: A month Two months

from today from today
Model V1 V2
version:
• 1 supplemental
+ 10 supplemental node added
nodes • 1 supplemental
+ 8 rules node deleted
+ 2 UIs • 1 rule edited
Versions are dynamic and cumulative:

• Dynamic because their baseline can change as other versions are released
• Cumulative because the latest version accumulates all the prior released changes
This diagram depicts the following example.
• You have a model that you just imported from PIM. Version zero of the model was released by virtue
of that import.
• Now you create a workspace WS1 and add version zero of that model to the workspace. You add 10
supplemental nodes, 8 rules, and 2 UIs to the model in the workspace WS1.
• You release WS1 with an effective start date of a month from today. A new version of the model is
created when WS1 is released. We will call it V1. (Real version numbers look similar to 2.0.)
• Now you realize that you must make a fix to the model and release that fix a month after V1 has
been created.
• So you create a workspace WS1Fix and add the model to the workspace. The baseline version of
the model is V1. Now you add 1 supplemental node, delete a node, and edit a rule. Then you
release WS1Fix with an effective start date of 2 months from today.
• A new version of the model is created when WS1Fix is released. We will call it V2.
• From this point on, if you create a new workspace with ESD beyond that of WS1Fix and add the
model to the new workspace, V2 will be the baseline version of the changes to the model.

Topics
• Versioning
This section discusses how the release process works.

What Is Release?
• 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.

Workspace Release Threshold
Once you release the contents of a workspace, they cannot be unreleased and be brought into their
previous draft state. Furthermore, you can't release additional changes to a model until the effective start
date of the released model has passed. As a best practice, our guidance has always been to release a
workspace into production as close to the effective start date as is reasonably possible.
To safeguard users and prevent users from releasing model changes far out into the future, where those
changes would be frozen for an extended period of time, a workspace release threshold has been
established. This threshold is the number of days out from the current date beyond which no workspaces
can be released. By default this is set to one day but it can be adjusted according to your business needs.
The application now essentially enforces the best practice automatically to further protect and safeguard
users.
As an example with the default settings in place, if the current date and time is 12 pm on March 21st and the
effective start date of a workspace you plan to release is June 31st of that same year, you would be
prevented from releasing the workspace. The earliest you would be able to release the workspace would be
12 pm on March 20th.
For more information on how to modify the release threshold see Using workspaces in the following link:
https://docs.oracle.com/en/cloud/saas/supply-chain-management/19a/facmg/modeling-configurations-for-
scm.pdf
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.

What Is Released?
A workspace with all its contents

• Models
– Supplemental structure
– Rules
– UIs
• Snapshots with changes (releasing snapshots could affect models already in
production)
– Value set
– Item class
– Item
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.

Topics
• Versioning
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.

Concurrent Development
Workspace-Scoped Development
Workspace: WS1 WS1Fix WS2
ESD: Sep 1, 2015 Oct 1, 2015 Dec 1, 2015
Model version:
V1 Draft Draft
• WS1Fix: Short-term changes

• WS2: Long-term changes
Example of Concurrent Development with Releases: Introduction

You learned about concurrent development in the Workspaces lesson. This diagram depicts an example of
what might happen.
• You have just released WS1, after making changes to a model on top of the baseline version zero.
• You are already planning for the next release of the model, so you have created WS2 and added the
model to it. You have also started work: adding rules and making some UI changes towards the next
release.
• The end users that started to use V1 of the model in production complain about an issue they are
seeing, and need it fixed sooner than later.
• You can then create a new workspace WS1Fix with an effective start date as early as today (if you
can fix the issue immediately), add the model in question to the WS1Fix workspace, work on the
changes that you need to fix the issue reported by the end users, and test and release WS1Fix.
• Do you think that this release will affect anything in WS2? Let’s see.
Instructor Note
The instructor may have to change the dates in the slides if they become outdated. The idea is have WS1
released on an effective start date that is already past, the effective start date of WS1Fix in the immediate
future, and the effective start date for WS2 in the longer future.

Baseline Change of a Concurrent Draft
Release of a draft changes baseline version of its concurrent drafts.
Workspace: WS1 WS1Fix WS2
ESD: Sep 1, 2015 Oct 1, 2015 Dec 1, 2015
Model V1 Draft
V2 Draft
version:
Baseline • 1 node added

• 1 node deleted
• 1 rule edited
Example of Concurrent Development with Releases: Conclusion

The example is narrated in the following list. This diagram depicts the three workspaces that were discussed
in the previous slide.
• One of the workspaces is released, and the other two have draft versions of the models.
• When WS2 and WS1Fix were created and the model was added, the baseline version of the model,
called V1 in this example, was added to these workspaces while you were working on the changes
in WS2.
• As there was a need for a production fix, the workspace WS1Fix was created.
• The changes for the fix were made and WS1Fix was released before WS2. Now the version of the
model released with WS1Fix is called V2 in this example.
• You were asked the question: “would this change anything in WS2?”
• This is what happens to the draft in WS2: The baseline version for that draft is changed from V1 to
V2 and the work that you did in WS1Fix is automatically reflected in the model draft in WS2. You do
not need to do anything manually to bring the WS1Fix changes into WS2.

Topics
• Versioning
This section discusses the effects of releasing updated snapshots or reference models on models that are
already in production.

Referenced Models
• Common definition across all referring models

• Reusable item and supplemental structure, rules, and UIs
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.

Referenced Models Shared Across Models
• Only one configurator model per model Item
4 Door Classic Sedan
4 Door Hybrid Sedan
Engine Assembly
Model
2 Door Coupe
4 Door Plug-in Sedan
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.

Referenced Model Versioning
Referenced model versions are independent from referring model versions.
WS1Fix Jul 2013

WS1 Sep 1,2015 WS1Fix Oct 1, 2015 WS1Coupe Dec 1, 2015
Classic
Sedan SV1 Draft
SV2 Draft
WS1Coupe Dec 1, 2015
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.

Impact of Releasing a Referenced Model
Classic Sedan Model

• Rule: ‘Base Trim’ IMPLIES
‘Engine’.‘Engine
2 months from today
Type’.‘2.0L turbo DOIIC [259hp]’

Rule valid until 2 months from today
• Release does impact analysis and
warns PCM.
• Rule is no longer effective after 2
months from today.
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.

Demonstration: 8-1
• 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.

Practice: 8-1
• Generate a Prerelease Report
In this practice, you generate a Prerelease Report to simulate the release of a workspace.

Summary

• Describe the concept of versioning in the Configurator Models work area
• Release a workspace
• Describe how concurrent drafts are affected with release
• Explain how existing models are impacted when a workspace containing a snapshot
or referenced model is released

9
Managing Supplemental Structure and Rules

Using ADFdi Integration

15 minutes Practice
30 minutes Total
Learning Objectives

• Explain how to manage supplemental structure and rules using ADF Desktop
integration (ADFdi) with Microsoft Excel
• Perform various actions on a selected set of multiple models in a single operation
using ADFdi
• Describe the elements of ADFdi spreadsheets associated with a management task for
supplemental structure
• Perform rule management actions using ADFdi

Topics
• Overview of ADFdi integration

• Manage Supplemental Structure using ADFDi
• Manage Rules using ADFDi
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.

Overview of ADFdi Integration
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.
This slide describes a brief overview of ADFdi integration.

Management Preliminaries
Before using ADFDi Spreadsheets perform the following preliminary actions:

• Download and install the latest version of ADF Desktop Integration with Microsoft
Excel
• Download the unpopulated spreadsheets that you can use to manage supplemental
structure data
• The models containing the rules to be managed must be in Draft status and must be
participants in an unreleased workspace (a workspace with the status of In
Development).
Note: You can also download unpopulated versions of the spreadsheets by selecting a
task under File Based Data Management in the task panel of the Configurator Models
work area.
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.

Topics

This section discusses how you can manage Supplemental structure using ADFDi.

Supplemental Structure Management Actions
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
This slide discusses supplemental structure management actions.

Supplemental Structure Management Actions
• 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.
This slide discusses additional supplemental structure management actions.

Supplemental Structure Node Types
The following supplemental structure node types are available for ADFdi
management:
• Boolean features
• Decimal features
• Integer features
• Text features
• Option features and its options
This slide discusses supplemental structure note types.

ADFdi Spreadsheets
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
There are the following 3 ADFdi Spreadsheets.

Manage Supplemental Structure
• Single Model Download and Upload process
• Create / Update / Delete of Supplemental Structure
Manage Cross Model Option Feature
• Cross Model Upload of a common structure (Create / Update / Delete)
• Associate / Remove Supplemental Attributes and Values to common structure
Manage Item Snapshots Attribute Association
• Associate / Update / Remove of Supplemental Attributes and Values to Item Snapshots (PIM Nodes)

Manage Supplemental Model Structure
Elements for managing

Details
supplemental model structure
Command to download empty On the Manage Models page, select Download
spreadsheet Spreadsheet for Managing Model Structure from
the Action menu
Task to download unpopulated From the File-Based Data Management list in the
spreadsheet based on search task panel, click Manage Model Structure
Default spreadsheet name ManageModelNodes.xlsx
Tab with ADFdi buttons on Manage Supplemental Structure

spreadsheet ribbons
Spreadsheet columns for **Parent Name
entering data *Name
*indicates required input Description
**indicates conditionally *Node Type
required input **Domain Ordering
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”.

Manage Cross-Model Supplemental Structure
Elements for managing cross-

Details
model supplemental structure
spreadsheet Spreadsheet for Managing Cross-Model Structure
from the Action menu
Task to download populated From the File-Based Data Management list in the
spreadsheet based on search task panel, click Manage Cross-Model Structure
Default spreadsheet name ManageCrossModelOptionFeature.xlsx
Tab with ADFdi buttons on Manage Cross-Model Option Feature

spreadsheet ribbons
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”.

Manage Supplemental Structure
Elements for managing cross-

Details
model supplemental structure
Spreadsheet columns for **Parent Name
entering data *Name
*indicates required input Description
**indicates conditionally *Node Type
required input *Minimum Value
Maximum Value
Enable option quantities
The following columns are available in a separate

range of the spreadsheet. Enter data in them to
create associations of existing supplemental
attributes and values with the supplemental
nodes that you create.
*Name
Description
*Node Type
*Supplemental Attribute
*Supplemental Attribute Value
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”.

Manage Supplemental Attributes and Values of
Snapshots
supplemental attributes and Details
values of snapshots
spreadsheet Spreadsheet for Managing Item Snapshots from
the Action menu
Task to download populated From the File-Based Data Management list in the
spreadsheet based on search task panel, click Manage Item Snapshot Attributes
Default spreadsheet name ManageItemSnapshotSupplAttrValAssoc.xlsx
Tab with ADFdi buttons on Supplemental Attributes and Values to Item

spreadsheet ribbons Snapshots
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”.

Manage Supplemental Attributes and Values of
Snapshots
supplemental attributes and Details
values of snapshots
Spreadsheet columns for Structure Item Type
entering data Item Class
*indicates required input Organization
Name
Description
Effective From
Effective To
Snapshot Status
*Supplemental Attribute
*Supplemental Attribute Value
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”.

Topics

This section discusses how you can manage Supplemental structure using ADFDi.

Rule Management Actions
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.

Practices: Overview
9-1: Manage Supplemental Structure using ADFdi Spreadsheets

9-2: Manage Option Features using ADFdi Spreadsheets
9-3: Manage Rules using ADFdi Spreadsheets
9-4: Manage Item Snapshots using ADFdi Spreadsheets
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.

Summary

• Explain how to manage supplemental structure and rules using ADF Desktop
integration (ADFdi) with Microsoft Excel
• Perform various actions on a selected set of multiple models in a single operation
using ADFdi
• Describe the elements of ADFdi spreadsheets associated with a management task for
supplemental structure
• Perform rule management actions using ADFdi

Configurator Modeling Course - Student Guide

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Configurator Modeling Course - Student Guide

Uploaded by

Copyright:

Available Formats

1

Schedule: Timing Topic

After completing this course, you should be able to:

This slide lists the learning objectives for this course.

Oracle SCM Cloud: Configurator Modeling 1 - 2

• Lesson 1: Course Introduction

This slide lists the lesson topics included in this course.

Oracle SCM Cloud: Configurator Modeling 1 - 3

This slide describes the instructional approach for this course.

Oracle SCM Cloud: Configurator Modeling 1 - 4

This course is intended for:

This slide describes the intended audience for this course.

Oracle SCM Cloud: Configurator Modeling 1 - 5

This slide describes the prerequisites for this course.

Oracle SCM Cloud: Configurator Modeling 1 - 6

Active links are in the Student Guide.

Oracle SCM Cloud: Configurator Modeling 1 - 7

• Cloud Customer Connect Community

Active links are in the Student Guide.

Cloud Customer Connect (https://cloudcustomerconnect.oracle.com/pages/home ) is Oracle's online cloud

Oracle SCM Cloud: Configurator Modeling 1 - 8

• Customer Connect Training Replays:

Active links are in the Student Guide.

Oracle SCM Cloud: Configurator Modeling 1 - 9

Active links are in the Student Guide.

Oracle Procurement Cloud: Procurement Implementation 7 - 10

Overview of Configurator Modeling

Schedule: Timing Topic

After completing this lesson, you should be able to:

This slide states the learning objectives for this lesson.

Oracle SCM Cloud: Configurator Modeling 2 - 2

• Overview of Configurator Runtime

Oracle SCM Cloud: Configurator Modeling 2 - 3

Centralized Management of Products Configured to Unique

Simplified Configuration of Complex Cloud Enabled and Integrated with

You use the functionality of Configurator Modeling in two distinct areas:

Oracle SCM Cloud: Configurator Modeling 2 - 4

• Dynamic runtime UI (embedded task flow)

• Testing of model behavior and user interfaces

Oracle SCM Cloud: Configurator Modeling 2 - 5

Oracle SCM Cloud: Configurator Modeling 2 - 6

• Overview of Configurator Runtime

Oracle SCM Cloud: Configurator Modeling 2 - 7

Oracle SCM Cloud: Configurator Modeling 2 - 8

Oracle SCM Cloud: Configurator Modeling 2 - 9

Oracle SCM Cloud: Configurator Modeling 2 - 10

• Overview of Configurator Runtime

Oracle SCM Cloud: Configurator Modeling 2 - 11

• The Configurator UI is embedded within the Order Management UI when a product is

Oracle SCM Cloud: Configurator Modeling 2 - 12

• Define configured item pricing in Pricing application

Oracle SCM Cloud: Configurator Modeling 2 - 13

Benefits of Configurator Compared to CPQ Configurator

Oracle SCM Cloud: Configurator Modeling 2 - 14

• The Configurator user interface can be embedded into third-party applications

Oracle SCM Cloud: Configurator Modeling 2 - 15

Oracle SCM Cloud: Configurator Modeling 2 - <#>

Oracle SCM Cloud: Configurator Modeling 2 - 16

• Creating an Order with a Configurable Product

In this demonstration, you create an order with a configurable product.

Oracle SCM Cloud: Configurator Modeling 2 - 17

In this lesson, you should have learned how to: