R12 Oracle Configurator

About this white paper:

Dear readers, I am planning to publish a series of articles which will help you understand and use Oracle Configurator Module in Oracle E-Business Suite. This is the fi rst article which gives first glance information about Oracle Configurator Module. The main objective of this article is to simplify the learning process of Oracle Configurator Module. If the one goes through Oracle User Guides for this module then a person can easily get lost i n 4-5 separate 200+ pages document, making the learning more difficult. Of course this series of Configurator articles will contain 3-4 more articles but information presented will be on the spot which is necessary for working on this module.

Prerequisite for using Oracle Configurator is knowledge of Oracle Inventory and Oracle Bills of Material modules.

After going through this white paper reader should understand following things:



Oracle Configurator Components



Important Profiles and Concurrent Programs



Relationship of Oracle Configurator with Oracle Inventory Inventory/Bills /Bills of Material



Overview of Most Importance component Oracle Configurator Developer

I will be using Oracle E-Business Suite R12 for screen shots but I will be discussing features which are present in Oracle EBS 11.5.10.2 11.5.10.2..

Overview: Oracle Configurator Module can be treated of as a selling machine if there is a model bill against which to configure by selecting options. It can also be thought of as an engineering machine if there is no model bill. An engineering machine could generate a bill. Configuration Configurations s created with Oracle Configurator are standard bills based on an already existing model bill. Configurator does not have to be based on bills of material, although that is currently necessary for ordering and downstream ERP. Oracle Configurator is an application or part of an application that lets a user configure products and services. The configuration model, which is typically based on a BOM model, consists of structure, rules, and UI definition. Oracle Configurator Components Oracle Configurator consists of the following main elements:



Runtime Oracle Configurato Configuratorr



Oracle Configurator Servlet (OC Servlet)

o

UI Server

o

Configuration Interface Object (CIO)



The Oracle Configurator Schema within an Oracle Applications database



Oracle Configurator Developer

With Oracle E-Business Suite 11.5.10.2 all above components come as integral part Oracle EBS installations. In Previous version, Oracle Configurator Developer used to be a separate desktop application. Runtime Oracle Configurato Configuratorr The runtime Configurator provides a means of selecting options to create a configuration. It is presented to end users by the OC Servlet as an Oracle Configurator window. Although Configurator Configurator can be deployed as a standalone application, application, the Oracle Configurator window is usually launched from within a host application. From Oracle Order Management runtime Configurator can be invoked if ATO/PTO model is entered on Order Line and Configure button is clicked. Oracle Configurator Servlet This consists of UI Server and Configuration Interface Object. The OC Servlet runs on Oracle Internet Application Server (iAS), which includes the Apache Web Server. The behavior of the OC Servlet can be customized by setting Servlet properties.

Oracle Configurator Schema The Oracle Configurator schema consists of Configurator (CZ) tables in the Oracle EBS 11i database that is accessed by both the runtime Oracle Configurator and Oracle Configurator Developer. Oracle Configurator Developer With Release 11.5.10 this comes as integral part of EBS. This i s used to develop various configuration rules, user interface, add non-BOM items w hich are necessary for guided selling. The user interface (UI) can later be published to various hosting applications like Order Management, iStore etc. Important Responsibilities



Oracle Configurator Administrator



Oracle Configurator Developer



Inventory (For defining MODEL, Catalogs)



Bills Of Material (for defining MODEL BOM)

Both Oracle Configurator responsibilities see the same user interface except using Administrator responsibility one can edit/change MODELs created by other users while Developer responsibility can edit MODELs created by same user. So we will be using Oracle Configurator Administrator only.

Important Profiles

Profile Name

Value

Description

CZ: Generic Configurator UI Type

HTML Hierarchical Table

This displays DHTML user interface created in Oracle Configurator Module

CZ: Use Generic Configurator UI

Yes

BOM:Configurator BOM:Configura tor URL of UI Manager

http://:/OA_HTML/configurator/UiServlet

This will launch Configurator UI

Item Related Setups in Oracle Inventory

Oracle Configurator is driven by the MODEL (ATO or PTO) type of items. Generally Oracle Configurator is used for guided selling i.e. user is presented with various questions and based on user inputs respective components are selected. So user should be allowed to select various product properties. These properties are stored as Item Catalog values in Oracle Inventory.

Item Properties are grouped into Catalog Groups. Each Catalog group can have m ultiple catalog elements (properties). At the most one catalog group can be assigned to a given item. W hile defining product structure for ATO Model and related Option classes one must design option class and its properties i n such a way that end user should be able choose various property value in Configurator. In Configurator, these catalog groups are termed as Item Types. We can define property based rules to choose components for various option classes.

There are multiple ways of defining or designing catalog groups. We can have separate catalog groups defined for each option class/compo class/component nent items. Let‟s discuss this with example of Model “Sentinel Custom Desktop” Item Code CN -92777. This model has various components viz. Software, Memory, Hard Disk etc. Each option class and its related i tem can have related catalog group attached to it. E.g. Hard Disk Catalog Group can have properties (elements) like Manufacturer, Size, type etc. All items which come under hard disk options can have this catalog group assigned to it. Finally the MODEL item can have a new catalog group e.g. CTO Sentinal or Laptop which will contain all the catalog elements of individual option classes.

Second type of Product design can be MODEL and all its option classes/components can have the same catalog group assigned to them e.g. Desktop Catalog and individual components have values only for related properties/catalog elements.

A product can be configured (by calling Configurator) from Oracle Order Management, Order Entry screen. This order can be progressed to create a new configured item (typically called STAR item because the new item code is Model item code and a sequence number separate separate by „*‟). Newly created item is

standard item with standard bill of material containing actual components components (as against the option classes for MODEL item). The new star item also get the catalog group assigned to Model and the catalog element values come from individual component‟s catalog ele ment values. For example, newly configured star item CN92777*12245 has “CTO Sentinal or Laptop” group of which is same as base MODEL and individual value like Memory, H ard Disk Size etc will get values from i ndividual components. components.

While designing catalog element one has to take care that all option class catalog elements names are unique. E.g. Manufacturer property will be present for all option class catalog groups, to make it unique we should name it like HD. Manufacturer for Hard Disk, FD. Manufacturer for floppy disk, RM. Manufactu Manufacturer rer for RAM etc. So when final star item gets created all catalog elements for individual components get clubbed to gather automatically.

Populating Oracle Configurator Schema (CZ)

Enterprise Item data is created and maintained in t he Oracle Inventory and Bills are maintained in Oracle Bills of Material. This data imported into the Oracle Configurator schema as read-only data for access by Configurator Developer and the run-time Configurator.

The Oracle Configurator schema includes a specialized control table CZ_DB_SETTINGS for custom data import.

The data stored in the CZ schema includes:



Configuration models



Item and Model structure data



Configuration rules



User interface definitions



Publication records



Configurations

Item and BOM data can be imported into CZ schema using following concurrent programs (registered under Oracle Configurator Administrator responsibility)



Populate Configuration Models



Refresh a Single Configuration Model



Refresh All Imported Configuration Models



Disable/Enable Refresh of a Configuration Model

Oracle Inventory-Bills Of Material-Oracle Configurator:

Data Setup and Movement The first step of Configurator Data setup i s prepare item data (MODEL) and its bills of Material containing various components and option classes. One needs have a confort level with Oracle Inventory and Oracle Bills of Material Modules.



Login to Oracle Applications using Inventory responsibility and navigate to Master Item Screen. Create new item/MODEL by using Copy from functionality. Use existing ATO MODEL item code CN92777.



Assign Inventory/Child Organizations



Change Responsibility to Bills Of Material and navigate to Create Bills Screen. Use Copy Bills functionality to copy BOM data from CN92777 and create BOM for PB-CN92777



From Tools Menu Create Common Bill



Next step is to transfer Item/BOM information for a given model to Oracle Configurator Schema (CZ). To perform t his activity, change responsibility to "Oracle Configurator Administrator" and submit concurrent job Populate Configuration Model with Item PB-CN92777 as input parameter. Please note there is similr CONC job available under Bills of Material Responsibility, please don't use that CONC program as its errors out (may be its older version of Populate Configuration Model)



After successful completion of Populate Configuration Models Concurrent Program, we can check the population of CZ schema through SQL*Plus or through Oracle 11i front end by cli cking Configurator Developer Menu and navigate to Repository (Main) Tab to see newly populated item PB-CN92777

Oracle Configurator Developer Overview Oracle Configurator Developer is the most important component where Configuration Rules are defined and DHTML user i nterface is created. This is accessible from Oracle Configurator Developer menu through Oracle Configurator Administrator Responsibility. This tool (now integrated with Oracle EBS 11.5.10.2 installation) is used for following Oracle Configurator Setups viz. Create NON-BOM Items for guided selling, Create Numeric Rules, Create Logic Rules, Create Statement Rules, Create Configurator Extension Rules to allow customizations, Create User Interfaces and finally publish these user interfaces (UIs) as runtime UIs to hosting applications like Order Management, iStore, Oracle Telesales or third party custom order entry applications. This consists of two HTML tabs viz. Repository and Workbench. Repository consists of Main, Item Master and Publi cation sub-tabs. Oracle configurator developer is used for defining following things:

Repository-Main

The hierarchical table in the Main are of the Repository contains a root folder in which all Configurator Developer objects are created, maintained, and organized.

You use the Select checkbox to apply an Action, such as copy or move to one or more objects at a time. The Edit icon opens an object for editing. If the object is a Model, clicking the Edit icon opens the Workbench for working on that Model. The Create icon is for creating a new child object. In other words, if you want to create a new Property to appear within a certain Folder, you select the Create icon appearing in the row for that Folder. In this case, the Folder would be the parent object, and the new P roperty to be created and stored within that folder would be the child object.

Repository-Item Master

This screen is used to maintain item/catalog groups. You can create Items which are not present in Oracle Inventory using this area. All Items are grouped into various Item Types which are nothing but Catalog Groups defined in Oracle Inventory. Catalog Elements form the various properties of items in Configurator.

Repository-Publications

This section is used after Rules definition and UI creation is completed i.e. when Configurator UI for a given model is ready to be deployed to host application. You can also publish the UI to same Oracle apps instance or any different instance.

Work Bench-General

This section gives all information about the model. You typically access the Workbench from the Repository Main area by selecting the Edit icon in the hierarchical table row for a particular Mode

Work  Workbench-Structure

The Workbench also has areas for defining the Model's Structure, Rules, and User Interfaces. The Model structure area i s shown here. It contains a table displaying a hierarchical tree of Model structure nodes. In this section you can create Non-BOM Items f or a given model. Such items are typically required for building guided selling type of user interface.

Work Bench-Rules

The Rules area of the W orkbench contains many pages for defining rules in a streamlined flow. The first page of the Rules area contains a hierarchical table displaying a hierarchical tree of Rule folders and rules. You can create various types of rules viz. Numeric Rules, Logical Rules, Statement Rules, Configurator extension rules by clicking “Create” icon.

Work Bench-User Interface

This section is used to build user interface which can be displayed in host applications. UI elements representing screens and UI controls are added, edited, copied, moved, or deleted here. The User Interfaces structure can be rearranged completely independently of the Model structure. Any model content can be displayed multiple times on either the same screen or on different screens.

Summary

I hope this article gave you an overview/idea about Oracle Configurator features and components involved in Oracle Configurator. In the upcoming articles we will talk about defining Configuration Rules, Creation of User Interface, Creating Configurator Extensions (Customizations) and various handy PLSQL APIs related to Configurator.

Stay tuned for upcoming Configurator Articles.........

Oracle Configurator Articles -II Monday, 02 June 2008 20:09 Prasad Bhogle

User Rating:

/3 Rate

Poor

Best Oracle Configurator Developer-Repository & Structure

About this white paper

In continuation with previous article, now we will start discussing about creating the model structure with in Oracle Configurator Developer. In this article we are going to cover maximum types of nodes which can be created and their usages. This will include imported BOM and non-BOM Models, features, properties, populators, effectivity sets, model references, totals, resources etc. Please note, for screen shots I am using Oracle EBS R12 but Oracle Configurator features discussed are also present in Oracle EBS 11.5.10.2. Configuration Model

A configuration model is Model structure, configuration rules, and optionally a User Interface from which an Oracle Configurator end user makes selections to configure a valid, orderable item. There are two kinds of Models: Models that you create in Configurator Developer, and imported BOM Models. Models that you create in Configurator Developer are often created to provide guided buying or selling questions and may reference, or be referenced by, other Models. Within a Model you can create any type of structure node, including Components, Features, Options and so on. You can also create References to other Models, or to a BOM Model. Imported BOM Model

This BOM model is imported from Bills of Material using concurrent program "Populate Configuration Models" using Oracle Configurator Administrator Responsibility. The imported data is read-only in Configurator Developer because it must correspond to the BOM Model defined in Oracle Bills of Material throughout the business process. However, you can use Configurator Developer to add Components, Resources, Totals, and so on to meet your configuration requirements and achieve guided selling structure. Guided buying/selling structure provides a way to derive valid configurations from customer requirements or needs assessment questions. When BOM is imported into Oracle Configurator following item attributes get imported in CZ schema 

Item Name



Item Description



Definition - Basic definition about item viz. BOM Item Type, Minimum and Maximum Quantity, Default Quantity, and BOM Information like

o

The item‟s optional children are mutually exclusive

o

The item is required in the configuration when its parent is selected

o

The item allows decimal quantities

o

The item is Trackable



Properties and Property Values- In item structure, properties are stored in Catalog Elements and Catalog Element Values. Many Catalog Elements are grouped into Catalog groups. Only one Catalog group can be attached to an Item.



Effective Dates

In Oracle Configurator, Item Type represent Item Catalog Group while properties represent individual catalog elements. In Configurator heirarchy items are children of item types. For imported items since Oracle Bills of Material data must remain consistent in Configurator Developer, you cannot delete or modify imported Items, Item Types, or Properties. You can add Properties to imported Items or Item Types. However, if you add an imported Property to an Item or Item Type, Configurator Developer does not allow you to delete the Property. Extending Imported BOM

Importing a BOM Model creates a model and structure automatically in Configurator Developer, but you can also create models from scratch. All nodes, whether imported with a BOM or created from scratch, can participate in configuration rules. The imported BOM can be extended by adding item within configurator developer. This is generally required for guided selling or giving more information about the MODEL/order being placed etc. The top level root node must be an imported BOM to be orderable in OM. Internally, the ORIG_SYS_REF of the configuration model root must match the

INVENTORY_ITEM_ID/ORG_ID of the BOM being configured. Guided selling structure m ust be a child of the BOM Model root. MODEL structure

Model structure contains various type of nodes viz. 

BOM Models



BOM Option Classes - A BOM Option Class is typically a group of related BOM Standard Items



BOM Standard Items - A BOM Standard Item is any Oracle Inventory Item that can be a component on a bill,including purchased items, subassemblies, and finished products. A BOM Standard Item is analogous to a Feature Option in Configurator Developer.



Components - A Component is a configurable part of a Model



Feature - A Feature can either be selected or accept input (depending on its type) at runtime when configuring a Component. There are various types of features viz. Option Feature, Integer Feature, Decimal Feature, Boolean Feature and Text Feature

BOM Models have Option Classes and may also contain other BOM Models (for example, a PTO that contains an ATO). Each Option Class contains Inventory items marked as Optional in Oracle BOM. Required items are not configurable, so they are not imported into Configurator Developer. However, these items are added to the sales order automatically when the model is configured. Components have Count parameter that determines: Whether an instance of the Component is required (minimum is 1 or more) or optional (minimum = 0) within the configuration The maximum number of instances of the Component that can exist in a valid configuration In Configurator Developer: A BOM Model is equivalent to a Component A BOM Option Class is equivalent to a Feature A BOM Standard Item is equivalent to an Option Each BOM Item is imported with a Minimum Quantity, Maximum Quantity, and Default Quantity. The Minimum Quantity is the smallest number of the selected Item allowed per parent. The Maximum Quantity is the largest number of the selected Item allowed per parent. The Default Quantity is the number of the selected Item per parent if not modified in the selection process. Properties

Imported properties come from Item Catalogs in Oracle Inventory. As discussed in earlier, Item Types in Configurator are equivalent to Item Catalog Groups in Oracle Inventory and Item Properties are same as Item Catalog Elements. You can add properties to Item Types in the Item Master using Configurator Developer. You cannot edit or delete properties added to the Model from the Item Master using Populators. You can add properties directly to nodes in the Model, but they are not added to the Item Master. Repository

Creating various types of objects in Repository. Folders are generally created to group the items/properties etc. To start with one should first create a folder where all components, option features and other nodes reside. Folder

Move the related imported BOM in newly created folder using Move Action.

Define MODEL

Define Model in new folder by clicking Create Icon infront of folder PB8104 and select Model as Object Type. This is a non-BOM model which will be used for guided selling of imported BOM Model. This non-BOM model can contain components, option features, text features etc. which may or may not be based on items. This can contain Non-BOM items which are necessary for guided selling.

Define Option Feature and Options

Navigate to Model Structure of newly created Model.

Click on Create Icon in MODEL (PB-Referenced Customer Requirements) line and select Node type as Option Feature. This type of Feature contains Options, which appear as children of the Feature node in Configurator Developer. End users select Options at runtime when configuring the Feature. An Option Feature is also known as a List of Options Feature. So after creating Option Feature we

need to add valid Options to the structure.

Create Options for newly created Option Feature by clicking Create icon structure view infront of Option Feature Line.

Create multiple options for a given option feature. This will display the structure as follows

Item Based Option Feature

Item based Option features are created in the similar manner except instead of Basic Node one has to select Item Based Nodes and select one of the Item Types. Later while adding Options to the option feature on has to select Item Based Options and select individual items under previously selected Item Types. Boolean Feature

As the name suggests, this type of feature can have two values True (Selected) or False (Not Selected). To Create Boolean Feature, Click Create icon at Model Line (PB-Referenced Customer Requirements)

Similarly all other types of features can be added to the MODEL. Other types of features are as follows: Integer Feature (Numeric Feature)

This can hold whole number at runtime. We can specify minimum and maximum values to validate the input data. Initial value can also specified at design time which is displayed at runtime when the session begins. Decimal Feature (Numeric Feature)

This is similar to Integer Feature except it can hold decimal values. Text Feature

This type of Feature appears as an input field in the runtime Oracle Configurator and accepts both alphabetic and numeric characters. Model References  A Model Reference node (or just Reference) indicates another Model‟s location in the structure of its

parent Model. The parent Model is the Model containing the child Model (that is, the Reference). You can create References manually, in Configurator Developer. This is generally used for guided selling. Non-BOM Models can be added to Imported BOM. Non-BOM Model can contain various option features, boolean features, text features representing various questions/answers being presented to user. To Create Model Reference click on the Create icon for imported MODEL line and select Model Reference Radio button on "Create Note:Select Type" Page.

Select the required NON-BOM Model on "Select Model" Page

Define Reference On next page

Components

A Component is a configurable part of a Model and can contain other Components, as well as Features, Resources, Totals, and Connectors. For example, a Computer Model may consist of Components called Hardware, Software, CD-ROM Drive, and Modem.

Totals and Resources

Totals and Resources can be children of a Model or Component node. A Total acts as a numeric variable in your Model, and can have either a positive or negative value. A Total an be used as a constant, or set when an Oracle Configurator end user makes a selection. A Resource is similar to a Total, but a Resource ensures that the quantity it is keeping track of does not fall below zero (that is, become over-consumed). In other words, the runtime Oracle Configurator displays a message when a Resource‟s value becomes negative, and flags the configuration as

invalid until it reaches 0 (zero) or a positive value. When the initial value of a Total is unknown, Configuration Rules that involve the Total do not propagate. Totals can have positive and negative values. Resources ensure the conservation of a quantity. A resource is violated if the quantity falls below zero and A violation message is displayed at run time. For Creating resource for a component, select the node type as Resource after click "Create" icon at the Component/Model Line in structure view.

For Creating Totals for a component, select the node type as Total after click "Create" icon at the Component/Model Line in structure view.

Populators and Its Usage

You can define a Populator on a non-BOM node to automatically create child structure for that node using Items, Item Types, and Properties in the CZ schema‟s Item Master. For example, you can

create a Populator on Component X and specify the following criteria: "Create Options from Items where the Item is of Type Processor Speed." Running this Populator creates a Feature for each Item that matches the specified criterion.

Populater maintains the link between item master data and Oracle Configurator. When data in the Item Master changes, you can update all nodes created using Populators simply by re-running the Populator. This statement holds good for deletes as well. In a MODEL structure, a given property can be marked as Imported or Inherited. Inherited Property indicates that a given property was attached by running populator. A Populator can create structure on any Configurator Developer node that can have children. These include viz. A non-imported Model, A Component and An Option Feature. You cannot define a Populator on a BOM Model, BOM Option Class, or BOM Standard Item. To define populate, click edit button of a Non-BOM model, component, option feature etc. In the node's details page, select the type of Item Master data you want the Populator to use when creating new Model structure from the Source list.

Click Repopulate button in Populator Status Block of General Tab and then navigate to the Structure window. Under the given Option Feature, where populator was defined, you will see Options automatically created from the Items based on given search criteria. e.g Processor Speed Option Feature which has a populator based on item type (catalog group) Processor Speeds

Effectivity and Effectivity Sets

Use effectivity to define the availability of a node or configuration rule and determine the model‟s structure at run time. If a node is not effective, it does not appear in the run-time UI. You can define effectivity sets apply it to group of nodes viz.Models, Features, Components, Options, Rules, Totals, Resources, and model publications. Effectivity Sets m ay consists of 1.A range of dates or an Effectivity Set 2. One or more Usages 3. Both effective dates and Usage(s). Following screenshot show how effectivity sets are defined and used.

Conclusion

This concludes the Model Structure. I hope this will help you create various types of Nodes. In the next article we will discuss about creating various types of Configuration RULES using Oracle Configurator Developer. Stay Tuned....................

Oracle Configurator Articles-III Friday, 06 June 2008 00:00 Prasad B

User Rating:

/1 Rate

Poor

Best

Configuration Rules About this article

This article will give detail information about developing configuration rules using Oracle Configurator Developer. Prerequisite to read t his article is r eader should have read previous two articles on Oracle Configurator published on this website. After going through this article, reader should be able to define following types of rules viz. Logic Rules, Numeric Rules, Design Charts, Compatibility Rules, Comparison Rules, Statement Rules. We will also cover little bit of Constraint Definition Language (CDL) which is generally used in Statement Rule. These rules become backbone of Configurator UI and hold all the business logic behind configuration MODEL.

What are configuration rules? Configuration Rules can be thought of as computer-assisted selection of products, components, features, and options. These relieves user from making decisions of final components being selected in configurable product. Technically configuration rule can be defined as an explicit definition of all valid logical relationships a collection of configurable items and compatibility relationships among items One of the most criti cal activities in constructing a configuration model is to design and construct the r ules that govern what the end user can select to make a valid configuration. You need to define rules to express relations and compatibilities among the Components, Features, Options, BOM Option Classes, and BOM Standard Items in your Model.

Types of Configuration Rules Logic Rules: Relate one or more Features or Options to other Features or Options, using a logic relation Numeric Rules: Perform a numeric operation on one or more Features or Options and place the result in a Total or Resource Comparison Rules: Determine the logic state of an item based on a comparison of two numeric values Property-Based Compatibilities: Compare the values of Feature Properties i.e. it specifies matches between the options of one or more Features or BOM Option Classes that have a common Property/item catalog value. E.g. using a pr operty of each item within t he RAM Option Class, ensure that the amount of memory is adequate for the computer‟s intended use.This type of rules can be extensively used if product structure is designe d with catalog groups and elements Property-based Compatibility Rules require much less maintenance than E xplicit Compatibility Rules because they are updated automatically when their Properties change. Define a Property-based Compatibility Rule in Configurator Developer when you need to create a single comparison relationship between two structure nodes. To define more than one comparison among multiple nodes, define a Statement Rule using the COMPATIBLE keyword. Explicit Compatibilities: Specifies matches between the options of one or more Features or BOM Option Classes in explicit tabular form. E.g. ensure that the total amount of RAM supports the selected software applications. Design Charts: Express complex explicit compatibility relationships. E.g. Selecting the Basic system adds a 17” monitor, the small PC case, 128 megabytes

of RAM, and an 800 MHz processor to the configuration. Configurator Extension Rules: Are programming objects that are attached to a Model to extend the functionality of the run-time Configurator through established interfaces. The Functional Companion/Extension Rule communicates with your Model through an application programming interface (API) in Java programming language called the Configuration Interface Object (CIO).

Imported BOM rules ATO/PTO BOM Models and their Option Classes are used to automatically create model hierarchy. Models, Option Classes, and Standard Items are automatically populated into the Model. Implicit rules from an ATO/PTO model enforce the following: Mutually Exclusive: Rules apply to parent nodes from which you can choose only one of all optional child nodes Minimum/Maximum: At least x and at most y Options can be selected to create a valid configuration. Default Quantity (Quantity Cascade): Calculations determine the final quantity requirements for the selected child node Required: Rules apply to child nodes that are r equired with the parent node (whenever the parent is selected, the required c hild BOM Items are also selected) Please note that the imported BOM Model is read-only. However, you can construct additional entities to extend the Model (for example, add customer requirements, Totals, Resources, and so on).

Rule Sequences:

A Rule Sequence is a set of configuration rules ordered by their effective dates. It is useful when a model has rules that change over ti me.

Developing Configuration Rules To start developing rule, click on edit of the Imported BOM in Repository Screen. This will take you to Workbench for given Model Click on Rules Link. Logic Rules

Logic Rules enable you to express constraints among elements of your Model in terms of logical relationships. For example, selecting one Option A may require that Options B and C be included in the configuration. Logic rules define item to item relationships. Logic Rules can push both ways. For example, Side A can impact the logic state of Side B, and Side B can impact the logic state of Side A Either side of the rule can contain one or more Features, Options, and so on. Configuration validity at run time is ensured by Oracle Configurator. Click Create icon on Imported BOM line to create various rules/folders. It is better to create folders for each type of rules.

Types of Logic Rules

Requires The Requires Rule definition sets up a relationship that “pushes” both ways. That is, if you set either side to true or false, the other side is set to the same

state. Additionally, the selection of one item requires selection of another item. This is two-way kind of relationship.

Selection of an item selects another item, and vice versa. The two items are forced to have t he same logic state. If A is true, then B must be true If B is true, then A must be true If A is false, then B must be false If B is false, then A must be false

Implies Rule The Implies Rule definition sets up a one-way relationship. That is, the selection of one item selects another item, but not the reverse. Selection of one item selects another item, but not the reverse. Implies Rule Definition If A is true, then B must be true If A is not true, then B can have any value If B is true, then A can have any value If B is false, then A can be either false or unknown, but not true For example, if you select a large monitor, you need a video card. Therefore, when you select a large monitor, it implies a video card, but it does not require the reverse to be tr ue. In other words, you should be able to buy the video card without also buying the large monitor. Negates Rule Selection of one item prohibits selection of another item, and vi ce versa. The two items are forced to have the opposite logic state. Negates Rule Definition: If A is true, B is false

If A is false, B is true If B is true, A is false If B is false, A is true Excludes Rule The Excludes Rule definition sets up a one-way r elationship. That is, the selection of one item prohibits another item, but not the reverse. Excludes Rule Definition: If A is true, then B must be false If A is false, then B can have any value If B is true, then A must be false If B is false, then A can have any value For example, if the end user selects software applications that exceed the amount of memory previously selected, the system displays a contradiction message. The user can then either remove one or more applications or increase the amount of memory to continue. Defaults Rule The Defaults rule definition sets a specified Feature Feature or Option to true as a result of another selection. A specified Feature Feature or Option is set to true only if it is available. The Defaults rule is similar to the Implies rule, only it is gentler. "A Defaults B" means that whenever A is selected and B is available, B is selected. The Defaults rule sets a specified Feature or Option to some value as t he result of another selection. Defaults rules are useful if you want to dri ve initial values at the beginning of a configuration session from customer requirements selections. Defaults rules do not display a violation message at run time since they just select default options and can always be overridden by t he end user. All True/Any True

All True

Any True

Logical AND

Logical OR

All of the entities need to be true for logical true

Any of the entities need to be true for logical true

Any of the entities need to be false for logical false

All of the entities need to be false for logical false

Implies Logic Rule

Numeric Rules

Numeric Rules express constraints between elements of your Model in terms of numeric relationships. With Numeric Rules, end-user selections can contribute to or consume from a Resource, Total, Numeric Feature, Option count, or the mi nimum or maximum number of component instances allowed in a runtime Oracle Configurator. Totals and Resources are used for: Accumulating values Example: Track the total amount of disk space available to ensure that you cannot consume more than you have of a resource Example: Prevent the end user from ordering m ore than the maximum number of memory slots available in a personal computer Adjusting the count of an option: Example: Ensure that a battery pack is provided with each laptop computer ordered Numeric Rule performs numeric operation on one or more Nodes viz. Totals or Numeric Features, Boolean expressions, Option Counts, Option properties and Constants. Values can be multiplied or divided before they are accumulated. The r esult is placed in: Total, Resource, Option Count, and Numeric Feature Numeric rule types: Contributes - Example, Each time a software application is selected, add a value to a Total called "Applications Disk Space" Consumes -Example, Each time the user selects a Hard Drive or CD-ROM, su btract 1 from a Resource called “Bay Slots”

Numeric rules follow the Quantity Cascade rules. For example, an Option cannot contribute to or consume from its parent node (a Feature). A rule defined this way produces an error at run time. Boolean expressions are expressions that can have a true/false value. A value of true is interpreted as a one (1) and a value of false is interpreted as zero (0). Use Numeric Features to make Advanced Expressions more readable. If you put a constant into an Advanced Expression, the meaning of the number is lost, so define a Numeric Feature and use that instead. You can exclude a Numeric Feature from the run- time user interface by setting the option “Display in User  Interface” to No. Values of Totals and Resources are stored a s decimal numbers. Multiply option counts by option properties to easily. Rule Name: Floppy CONSUMES from Bay Slots A Side: Floppy Drive - 1.44 MB (CM67433, from Disk Drive Option Class) * Constant = 1 CONSUMES FROM B Side: Bay Slots (Resource) When this rule comes into effect after selection of Floppy drive number of Bay Slots available are reduced by 1

Rule Name: Set 1GB RAM for Ultra A Side: Ultra * Constant (Quantity Multiplier) = 2 CONSUMES FROM B Side: Memory 512 (CM08512) to make 1 GB

When this rule is activated after selection of Ultra Option automatically 2 quantities of CM08512 (512 MB RAM) gets selected to make it 1 GB.

Comparison Rules

This type of rules compares and validate numeric values. e.g. following rule compares Application disk space to 120 GB and accordingly excludes certain hard disk components

Compatibility Rules

There are three types of Compatibility r ules: Explicit Compatibility rules: Express compatibility constraints among Options of your Model that cannot be described in terms of a shared Property. Specify explicit matches between the Options of one or more Features Set a logic state of False on Options that are incompatible with a selected Option Property-Based Compatibility rules: Perform a comparison between property values shared by Features or Option Classes. It can include multiple comparisons among the participating Features. It Specify the Properties to be checked for compatible values .It specify the type of comparison to be made between the Property values, using standard numeric and string comparison operators To create a Property-Based Compatibility rule, participants must be Features with Options that have Properties and All Options used in the rule must have a common property. These are easier to i mplement because individual options are actual inventory items which are maintained in Oracle Inventory and populated to CZ schema t hrough concurrent program. For example based on Memory Property o f Model Node "Which Application You want to run" the rule compares RAM property of Memory Option Class and selects the component accordingly. As you can see the relationship between to Options is not explicit. It is based on Property values (Catalog Values) of individual i tems/options.

Design Charts:

Express complex explicit compatibility relationships. It contains various features. Primary Feature: Options define variations of the Model Secondary Features: Defining Features: Unique combinations of options that define options of the primary Feature Optional Features: Options can be compatible or incompatible with Options of the primary Feature. It can have multiple secondary Features. The example used is about prepackaged system

If you closely watch above screen shots, there are three options for "Select a Prepackaged System" viz. Basic, W ork and Ultra. Now after adding Optional Option features, the define rule screen allows selection of individual components Based on Basic, Work or Ultra i.e. if User Selects Basic the one component of a given class gets selected while for Work there can be a different component. Statement Rules

You define a Statement Rule by entering text rather than building the rule interactively by selecting Model structure nodes and operators. A Statement Rule must be written using the Constraint Definition Language (CDL). Statement Rules can define a Logic or Comparison relationship, a Numeric contribution or consumption, or a Property-based Compatibility relationship. Explicit Compatibilities and Design Charts cannot be expressed using a Statement Rule Statement Rules enable you to: Write a rule using multiple operands in a single CDL statement Include multiple abstract relations in a single rule Define both sides of a rule in a single expression Examples: Following statement rule uses FOR ALL key word and adds "Hard Disk Capacity" Property values of all hard disks selected to a Total type of node "Total Disk Space". Here &x represent all selected hard disk options.

Constraint Definition Language (CDL) and some examples

The Constraint Definition Language (CDL) is a modeling language. CDL allows you to define configuration rules, the constraining relationships among items in configuration models, by entering them as text. Valid data types when defining a rule in CDL are INTEGER, DECIMAL,BOOLEAN,TEXT,Node types. Following examples can give you an idea about the power and usage of CDL in configurator Following configuration rule calculates the size of glass to be put into a window frame for each Window instance. The glass is to be inserted into the Frame 1/2 inch at each side. To capture such a rule, you would provide a name, such as WindowGlassSize, a description, and then associate the rule with the Window Model. CONTRIBUTE Frame.Width - 2 * Frame.Border + 2 * 0.5 TO Glass.Width; CONTRIBUTE Frame.Height - 2 * Frame.Border + 2 * 0.5 TO Glass.Height; An example configuration rule constrains the window frame color so that for some colors, the fi nish is glossy. An iterator le ts you define a r ule that selects the glossy finish based on a Property. The variable &color refers to all the Options of the Feature Color, in the Frame Component of the Window Model. The r ule selects a glossy finish when one of those colors is selected AND the Property RequiresGlossyFinish is true. CONSTRAIN &color IMPLIES Frame.Finish.Glossy FOR ALL &color IN OptionsOf(Frame.Color) WHERE &color.Property ("RequiresGlossyFinish") = "Tr ue"; To select a glossy fi nish for every Option of the Feature Color, make the Boolean Property RequiresGlossyFinish imply a glossy finish. CONSTRAIN &color.Property("RequiresGlossyFinish") IMPLIES Frame.Finish.Glossy FOR ALL &color IN OptionsOf(Frame.Color) Please refer to Constraint Definition Language (CDL) Guide Release 11i for all the syntaxes of CDL. Summary:

In this article we covered almost all types of rules and a brief about CDL. Configurator extension rules which will be covered in next article which will be more technical topic. Technical folks stay tuned and brushup your JAVA skills for writing Java/SQL code in configurator using configurator extension rules and wait for next article.

Oracle Configurator Articles - IV Sunday, 15 June 2008 08:29 Prasad Bhogle

User Rating:

/0 Rate

Poor

Best

Configurator Extensions About this white paper This paper will talk about extending Oracle Configurator functionality by using extensions/programs written using JAVA language. This makes it mandatory for a developer to have knowledge of CORE Java. Before reading this white paper, make sure you have read through articles 1-3 on Oracle Configurator on this website.

We will be discussing about writing these java extensions and using them i n Configurator Extension Rules. Using Configurator extensions we can perform additional validations, defaulting of certain values etc. This w hite paper will talk about things which are generally required in Oracle Configurator Development and not the complicated stuff which is given in Oracle Configurator Guides as it keeps developers away thinking that extensions too difficult to understand.

Overview of Configurator Extensions Configurator Extensions extend your runtime Oracle Configurator by attaching custom code through established interfaces. These extensions are written using JAVA Language. The term Configurator Extension includes the following:



A Configurator Extension class is the Java cl ass containing the methods that implement desired behavior



A Configurator Extension instance is the event-driven execution (the Java object) of the Java class at runtime



A Configurator Extension Rule is the set of arrangements that you Oracle Configurator Developer to associate the CX class to a Model

Installation Requirements for Developing Configurator Extensions 

The latest version of Oracle JDeveloper



The latest patch release of JDK 1.4.2 for your platform

The Configuration Interface Object Before writing Configurator extensions it is important to understand Configuration Interface Object .The Configuration Interface Object (CIO) is an API (application programming interface) that provides programs access to the Model used by a runtime Oracle Configurator, The CIO is a top-level configuration server. The CIO is responsible for creating, saving and destroying objects representing configurations, which themselves contain objects representing Models, Components, Features, Options, Totals and Resources. The Oracle Configuration Interface Object is written in Java, and implemented as the Java package oracle.apps.cz.cio. To use the f unctionality of the CIO you must import classes from this package. All Configurator objects are represented as java class e.g

Object Name

Java Class

Component

oracle.apps.cz.cio.Component

TextFeature

oracle.apps.cz.cio.TextFeature

OptionFeature

oracle.apps.cz.cio.OptionFeature

Option

oracle.apps.cz.cio.Option

BooleanFeature

oracle.apps.cz.cio.BooleanFeature

Totals

oracle.apps.cz.cio.Total

Resource

oracle.apps.cz.cio.Resource

To use this CIO objects we need to have package oracle.apps.cz.cio in classpath. You can copy the $JAVA_TOP/oracle/cz directory to desktop local directory C:\Prasad\CZ_Extension\oracle\cz and add C:\Prasad\CZ_Extension in Local JDeveloper Class Path. The java code should import these classes before using it as shown below:

package xxcz.oracle.apps.cz.extension;

import oracle.apps.cz.cio.Component; import oracle.apps.cz.cio.TextFeature; import oracle.apps.cz.cio.OptionFeature; import oracle.apps.cz.cio.BooleanFeature; import oracle.apps.cz.cio.Total; import oracle.apps.cz.cio.Resource;

public class SampleExtension { public SampleExtension() { }

public void setDefaultTextValue(TextFeature CustomerItem){ try { CustomerItem.setTextValue("Hello"); } catch (Exception e){

} } }

Using SQL in Configurator Extensions With Configurator extension code, we can connect to Oracle E-Business Suite Database and perform DML actions. T his is done by using java.sql package. To achieve this the import section of java extension should be as follows:

import java.sql.PreparedStatement; import oracle.apps.cz.cio.*; import oracle.apps.cz.cio.CIO; import oracle.apps.cz.cio.IRuntimeNode; import java.sql.Connection; import java.sql.SQLException; import java.sql.ResultSet; import java.sql.Statement;

Within Java Configurator Runtime there is no need to write statements to connect to Oracle using JDBC as we can get handle to Connection Object as follows: SQL Statements

public void queryData (TextFeature CustomerItem){ try { String sql = "Select SEGMENT1 from MTL_SYSTEM_ITEMS_B "; Connection conn = ((IRuntimeNode)CustomerItem).getConfiguration().getContext().getJDBCConnection(); Statement stmt = conn.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,ResultSet.CONCUR_READ_ONLY); ResultSet rset = stmt.executeQuery(sql); while(rset.next()) { } }catch(Exception e){

} }

Reading value for Configurator objects

public void readObjectData(TextFeature textItem, OptionFeature optionItem, BooleanFeature booleanItem ){ try { String textItemData = textItem.getTextValue(); String optionItemData = ((Option)optionItem.getSelectedOption()).getName(); double booleanItemData = booleanItem.getValue(); if (booleanItemData >= 1.0){  //True }else{  //false } }catch(Exception e){ }

Displaying Information OR Error Messages related to Validation

import oracle.apps.cz.cio.*; public void showMessage(OptionFeature sampleFeature) { String msg1 = "This is Sample Log Message"; InformationalMessage imsg1 = new InformationalMessage(msg1,frame); sampleFeature.getConfiguration().addInformationalMessage(imsg1); }

Selecting/De-Selecting Option Feature

public void SetOptionValues (OptionFeature currentFeature,String currentValue) {  //Set selected options within the model try{ ((Option)currentFeature.getChildByName(currentValue)).select(); }catch( Exception e) { } }

public void deSelectField (OptionFeature currentField){ if (currentField.getSelectedOption() != null){ try { currentField.getSelectedOption().deselect(); } catch (Exception e){ } } }

Capturing Additional Information (Non-BOM Information) in Configurator We can capture additional information for a given configuration by defining Configurator Descriptive Flexfield. This data is stored in CZ_CONFIG_ATTRIBUTES table. You can refer to Oracle Configurator Methodologies Guide to get the code of W riteAttributes.java and Attributes.java and use it as a part of your project. T hese java classes are used to wri te captured data in CZ_CONFIG_ATTRIBUTES table.

Setting Up Configuration Extension Rules 

Build the java classes you have developed and create a zip file with complete class directory.



Please note this zip file (e.g. xxcz.zip should have the complete directory structure i.e. xxcz/oracle/apps/cz/ext.Create a Configuration ExtensionArchive in Oracle Configurator Developer



Specify the JAVA Class Jar/Zip file



Assign this newly created Configurator Extension Archive to your MODEL

After Selecting the necessary archive the General Tab for given Model will look like

Create Configurator Extension Rules Creating Configurator Extension Rule is a multi-step process viz.



Create Rule



Choose Model Node



Choose Java Class



Create Binding-Binding is assigning methods in selected to java class to specific configurator events. Events are similar to triggers in forms. There events which are used frequently are as follows:

o

OnCommand- Creates a Push Button in User Interface and java method gets executed after clicking the button

o

postValueChange- Similar to when validate item in forms i.e. whenever value of selected object changes this event will fire

o

postConfigSave- This event will get fire after saving the configuration. e.g. writeattributes.class is attached whenever we need to save Configurator DFF information

o

OnInstanceLoad- Initialize variables

While creating binding you will see only those Model Nodes which as having same type as java method arguments/parameters. e.g. if java method has OptionFeature as parameter then Oracle Configurator Developer will allow only OptionFeature type of nodes to be selected in b inding. EventScope can be Global,Base Node or Base Node Subtree. This is similar to form level, block level and item level triggers in Oracle Forms. e.g. postValue Change event is selected for



If Eventscope is Global then any object is Configurator instance changes, this event will fire.



If its Eventscope is Base Node then any item with Base Model Node of Rule changes then a given event will fire.



If Base Node Subtree event scope is selected then event will fire only for selected node and its sub-nodes.