Oracle Configurator Developer
- It is an Oracle Application product which enables to develop a Configuration model and Configurator.
- Configurator Developer is a separate instance, DB link will establish the link between the instance and the database.
Oracle Configurator Developer (OCD): Source instance (BRYAN)
Order Management/ Inventory/ BOM: Target instance – Hosting Applications
Configuration Model
- It’s a model structure (based on a BOM model), Configuration rules, UI from which an Oracle Configurator end user makes selection to configure an orderable item.
- We build Configuration models in Configurator developer based on Products and services that can be configured according to the rules that we define.
- Model structure is the hierarchical view of the data (represents Products or services) and it is the starting point from which a Configure model is developed.
- We use Model structure to define Configuration rules and generate a runtime user interface.
Configurator
- A configurator provides custom configuration capabilities.
- A configurator is usually launched from a host application, such as Oracle Order Management and displays the selected configuration model to the end user.
- End user makes selections and specifies requirements for the product or service being configured.
- At the end, the Oracle Application dialog page is displayed.
- Oracle Configurator collects the customer’s requirements and using the Model definition and rules that we defined in Configurator Developer, ensures that the end user creates a valid configuration.
- Configurator -> selling machine
Two types of Model in configurator:
BOM Model: imported from BOM
Non-BOM Model: created/ built within the configurator
Runtime Oracle Configurator: Order Management (enables end users to select options)
OC Servlet
- UI Server, where the interface is being shown
- OC Servlet runs on Oracle Internet Application Server (iAS), which includes the Apache Web Server.
Important Responsibilities
- Oracle Configurator Administrator
- Oracle Configurator Developer
- Inventory
- BOM
Publishing activity: It will make the items available in target instance
Oracle Configurator Schema: Consists of the configurator (CZ) tables in the DB, it is accessed by both the runtime Oracle Configurator and Oracle Configurator Developer. (Read only Data)
CZ Schema stores the following data:
• Configuration Models
• Item and Model Structure Data
• UI Rules
• Configurations
• Publications Record – configurator to target
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 Mode
Oracle Configurator Developer consists of the following:
Repository
- organize models, and manage objects
- It is used after Rules definition and UI creation is completed (i.e. Configurator model is ready to be deployed)
Workbench:
- creating, modifying, and testing Model structure, rules, and UI definitions.
- Defining the Model's Structure, Rules, and User Interfaces. The Model structure area is shown here.
BRYAN instance to be used to navigate through Repository, Workbench, no changes are to be made.
Oracle Inventory
- Oracle Configurator is driven by the MODEL (ATO or PTO) type of items.
- Oracle Configurator - Guided selling
- User is presented with various options/questions and based on user inputs respective components are selected.
- User should be allowed to select various product properties and these properties are stored as Item Catalog values in Oracle Inventory.
- Item Properties are grouped into Catalog Groups. Each Catalog group can have multiple catalog elements (properties).
- Enterprise Item data is created and maintained in the Oracle Inventory and Bills are maintained in Oracle Bills of Material.
Oracle Inventory, BOM
Data setup and movement
- Prepare item data (MODEL)
- BOM containing various components and option classes.
- Login to Oracle Applications using Inventory responsibility and navigate to Master Item Screen.
- Create new item/MODEL
- Assign Inventory/Child Organizations
- Change Responsibility to Bills Of Material
- From Tools Menu Create Common Bill
- Transfer Item/BOM information to Oracle Configurator Schema (CZ).
- Change responsibility to "Oracle Configurator Administrator"
- submit concurrent job Populate Configuration Model
Oracle Configurator Developer
Configuration Model
- Model structure
- configuration rules
- User Interface
- There are two kinds of Models we create in Configurator Developer, and imported BOM Models.
- Models created in Configurator developer provide guided buying or selling questions and may reference, or be referenced by other models.
Imported BOM Model
- This BOM model is imported from Bills of Material using concurrent program "Populate Configuration Models" using Oracle Configurator Administrator Responsibility.
- Imported data is read-only data in Configurator Developer,
It must correspond to the BOM Model defined in Oracle BOM. - We use Configurator Developer to add Components, Resources, Totals, to meet our configuration requirements and achieve guided selling structure.
- Item Name
- Item Description
- BOM Item Type, Minimum and Maximum Quantity, Default Quantity,
BOM Information
- Item’s optional children are mutually exclusive
- item is required in the configuration when its parent is selected
- Items allows decimal values and it is Trackable
Properties and Property Values:
- 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.
In Oracle Configurator
Item Type -> Item Catalog Group
Properties -> Individual catalog elements.
In Configurator hierarchy items are children of item types.
Imported BOM
- Data must remain consistent in Configurator Developer,
- We cannot delete or modify imported Items, Item Types, or Properties.
- We can add Properties to imported Items or Item Types.
- BOM Item is imported with a Minimum Quantity, Maximum Quantity, and Default Quantity.
- Minimum Quantity is the smallest number of the selected Item allowed per parent.
Extending Imported BOM
- Importing a BOM Model creates a model and structure automatically in Configurator Developer
- We 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.
- Top level root node must be an imported BOM to be orderable in OM.
- Guided selling structure must be a child of the BOM Model root.
MODEL structure
Model structure contains various type of nodes
- BOM Models
- BOM Option Classes: Group of related BOM Standard Items
- BOM Standard Items: 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: configurable part of a Model, Components have Count parameter
Feature: selected or accept input at runtime when configuring a Component.
Types of features
- Option Feature
- Integer Feature
- Decimal Feature
- Boolean Feature
- Text Feature
Computer -> MODEL
CPU, keyboard, mouse, and monitor -> Option class (logical grouping of items together)
Option class CPU -> Hard disk, CD drive, RAM, Motherboard, etc -> Item (BOM, inventory item)
- Items are defined in Inventory.
- BOM creates a parent child relationship of the item.
- Configurator is an UI for BOM structure/ representation of BOM structure.
- BOM Models have Option Classes
- 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.
- These items are added to the sales order automatically when the model is configured.
In Configurator Developer:
- BOM Model -> Component
- BOM Option Class -> Feature
- BOM Standard Item -> Option
Properties
- Imported properties come from Item Catalogs in Oracle Inventory.
- Item Types in Configurator are equivalent to Item Catalog Groups in Oracle Inventory and Item Properties are same as Item Catalog Elements.
Repository
- Creating various types of objects in Repository.
- Folders are generally created to group the items/properties.
- create a folder: components, option features and other nodes reside.
Define Option Feature and Options
Navigate to Model Structure of newly created Model.
- Click on Create Icon in MODEL line
- Select Node type as Option Feature.
- Feature contains Options -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.
Model References
- The parent Model containing the child Model (that is, the Reference).
- 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.
Components
- A Component is a configurable part of a Model and can contain other Components, as well as Features, Resources, Totals, and Connectors.
Totals and Resources
- Totals and Resources can be children of a Model or Component node.
- A Total act as a numeric variable in your Model,
- Positive or negative value.
- Resource ensures that quantity does not fall below zero (that is, become over-consumed).
- If it becomes -ve then Oracle Configurator displays a message and flags the configuration as invalid. (Violation)
Populators and Its Usage
- We 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.
- Populator maintains the link between item master data and Oracle Configurator.
- When data in the Item Master changes, we can update all nodes created using Populators.
- We cannot define a Populator on a BOM Model, BOM Option Class, or BOM Standard Item.
Effectivity and Effectivity Sets
- Effectivity: availability of a node or configuration rule
It determine the model’s structure at run time. - If a node is not effective, it does not appear in the run-time UI.
CONFIGURATION RULES
Configuration Rules can be thought of as computer-assisted selection of products, components, features, and options
configuration rule -> valid logical relationships,
a collection of configurable items and compatibility relationships among items.
constructing a configuration model is to design and construct the rules that govern what the end user can select to make a valid configuration.
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.
Property-based Compatibility Rules require much less maintenance than Explicit Compatibility Rules because they are updated automatically when their Properties change.
Property-based Compatibility -> single comparison relationship between two structure nodes.
Statement Rule - COMPATIBLE keyword -> Multiple Nodes
- Explicit Compatibilities: Specifies matches between the options of one or more Features or BOM Option Classes in explicit tabular form.
- Design Charts: Express complex explicit compatibility relationships.
- Configurator Extension Rules: -> programming objects that are attached to a Model to extend the functionality of the run-time Configurator through established interfaces.
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:
- 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 required with the parent node (whenever the parent is selected, the required child BOM Items are also selected)
- 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 time
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.
Types of Logic Rules
Requires
- that “pushes” both ways. (two-way kind of relationship)
- the other side is set to the same logic state.
- Additionally, the selection of one item requires selection of another item.
Implies Rule
- The Implies Rule definition sets up a one-way relationship. That is, the selection of one item selects another item,
Negates Rule
- Selection of one item prohibits selection of another item,
Excludes Rule
- The Excludes Rule definition sets up a one-way relationship. That is, the selection of one item prohibits another item, but not the reverse.
Defaults Rule
- The Defaults rule definition sets a specified Feature or Option to true as a result of another selection. A specified Feature or Option is set to true only if it is available.
Numeric rule types: (follow the Quantity Cascade rules).
- Contributes: 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, subtract 1 from a Resource called “Bay Slots”
- Boolean expressions are expressions that can have a true/false value.
Design Charts:
- Express complex explicit compatibility relationships.
- It contains various features.
Primary Feature: Options define variations of the Model
Secondary Features: Unique combinations of options that define options of the primary Feature
Statement Rules
- We define a Statement Rule by entering text
- A Statement Rule must be written using the (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.
Constraint Definition Language (CDL)
- 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.
Guidelines for Configurator Rules
Contents
Types of Rules.
Logic Rules.
Comparison Rules.
Numeric Rules.
Compatibility Rules.
· Property-Based Compatibility rules.
· Explicit Compatibility rules.
· Design Chart is the last type of compatibility rule.
Statement Rules.
There are 3 major kinds of statement rules with their own format:
Place Rules into Folders by function.
Rule Examples.
Rule Names.
Example using a list of model nodes in a variable.
Never User a NotTrue rule.
Rule format for Decimal Quantities to BOM items.
This guide is intended to be used by all Configurator Modelers at Knolls so that standards will be used allowing all models for different lines of products to look and act the same. This will help give Knoll a common look and feel for all models and an aide for all future maintenance. It will also greatly help in debugging of any issues with rules and configurations outputs.
General statement about Configurator in general is that the runtime rules engine is re-evaluating or firing every rule every time a selection in made in Configurator. It does its best to make sure that all selections either by a user or by a rule or extension is valid and doesn’t break any other rule constraint. Determining the order of which rule is tested or re-evaluated is done internally by the Oracle Rule Engine and can’t be controlled or determined during the building of a model.
Statement rules are the only rule type which has an Oracle standard rule import function into Configurator. That said, most of the rules below have a button on each rule to automatically convert it into a Statement rule. This will allow us to export the rules and to also import rules into Configurator and into a specific model. Statement rules
Types of Rules
- Logic Rules
- Requires
- Implies
- Negates
- Excludes
- Default
- Comparison
- Numeric
- Compatibility
- Property-Based Compatibility
- Explicit Compatibility
- Design Chart
- Statement
- Configurator Extension
Logic Rules
Logic rules are basic rules which allow point to point or model node to model node interaction. The HTML form allows users to select one or more nodes on each side of the rule and to select the type of logic rule. All logic rules can be automatically converted to a Statement rule.
- Requires rules fire both directions for both True or False states. Meaning that if side A is False then Side B is set to False as well. This kind of rule can make the model hard to use and very hard to debug because it pushes logic states in both directions all of the time. It should NOT be used or used very carefully. I recommend that it not be used at Knolls.
- Side A = True makes Side B True
- Side A – False makes Side B False
- Side B = True makes Side A True
- Side B = False makes Side A False
- Implies rules are much safer and don’t fire in both directions as bad as a Requires rule does. For example:
- Side A = True makes Side B True
- Side A = False allows Side B to be anything
- Side B = True then Side A can be anything
- Side B = False allows Side A to be anything but True
- Negates rules fire in both directions like a Requires rule does except both sides of the rule tries to make the other side the opposite state. For example:
- Side A is True makes Side B False
- Side A is False makes Side B True
- Excludes rules fire more like an Implies rule where only the True State fires either direction. For Example:
- Side A = True makes Side B False
- Side B = True makes Side A False
- Default rules are very gentle in that they only fire from Side A to Side B and only if Side B is currently available to be selected. These rules should be used very carefully and only when we wish to allow users to override the rule selection by de-selecting the option. Also note that Default rules are the last to fire every time Configurator validates all of the rules at runtime. We still can’t control the sequence that the rules are evaluated and it also means that defaulting a selection to be True doesn’t always perpetuate a rule from Side B to another node either. Currently, I am only aware of a Default rule being used is when we default a matching Edgeband selection for the Laminate Tables. These should be used very sparingly.
Comparison Rules
Comparison rules do simple comparisons of 2 numeric values one of which may or may not be a constant value. So for example, on the left side of the rule you have an Integer Node where the user enters a number for drawers like 3 and on the right side the rule would select a cabinet with 3 Drawers. Comparison rules have the same types of rules as Logic rules. Comparison rules can also be automatically converted to Statement Rules.
- Simple comparison of number: <, >, = , <=, >=, <>
Numeric Rules
Numeric rules either contribute to or consume from a model node which allows numeric values. It can Contribute To or Consume From nodes like Totals, Resources, Integer Features, Decimal Features, Counted Options in an Option Feature, Standard Inventory Items or Standard Inventory Items in Option Classes, and Models or Option Classes. Numeric rules can also be automatically converted into Statement rule.
Numeric rules can use the following inputs into the rule as well:
- Totals, Resources or Numeric Features
- Boolean Expressions
- Option Counts
- Option Properties (assuming a numeric value)
- Constants placed inside the rule
Compatibility Rules
Compatibility rules in general are the fastest rules we have in Configurator because they are basically table driven rules. These rules have fully determined results as to which options are compatible with other options as design time instead of runtime. These rules are also better from a general maintenance point of view because they all require Option Features and or Option Classes as the inputs instead of Point to Point nodes in the rules.
All compatibility rules operate in the same fashion, which is that they never themselves select any Item or option. They instead only disable or turn to False status those items which are not compatible. Which means that when an item in an Option Feature or Option Class is selected or turned to True, then it will flag all non-compatible options to False.
Typically those options which are not compatible and are set to False are not displayed in the User Interface because they are no longer available for selection.
However, if all of the options in an Option Class or Option Feature are False except 1 and the Option Class or Option Feature is required to have a selection then the Option Feature or Option Class will automatically select the final available option, so the configuration is valid.
This is assuming that the Option Feature is set to a Maximum number of 1 or the Option Class is set as Mutually Exclusive in the Bills of Material. Also the first Option Feature needs to be set to a Maximum number of selections to a one and the Option Class should be required.
Note: Compatibility rule fires to set the non-compatible options to false once the maximum number of selections has been reached.
There are 3 types of Compatibility rules:
- Property-Based Compatibility rules have lease amount of maintenance required if an Option or standard item is added or deleted from the Option Feature and or Option Class. Because as long as any item being added to an Option Feature or Option Class has the same properties which are NOT Null, you don’t need to touch the rule. Simply just run the Generate Logic, refresh the UI and publish the model. Property Based Compatibility rules can also be automatically converted to a Statement rule. Below is a list of the types of comparison which can be made on the properties of an option:
- =, <>, <, >, <=, >=
- BeginsWith – Compares two operands of text literals and returns true if the first begins with the character(s) of the second
- DoesNotBeginWith - Compares two operands of text literals and returns true if the first doesn’t begin with the character(s) of the second
- EndsWith – Compares two operands of text literals and returns true if the first ends with the character(s) of the second
- DoesNotEndWith - Compares two operands of text literals and returns true if the first doesn’t end with the character(s) of the second
- Contains – Compares two operands of text literals and returns true if the first contains the second
- DoesNotContain - Compares two operands of text literals and returns true if the first doesn’t contain the second
- Like – Compares two operands of text literals and returns true if the first contains the second. Wildcards of % can be used
- Not Like - Compares two operands of text literals and returns true if the first doesn’t contain the second
- Matches – Compares two operands of text literals and returns true if they match
- NotMatches – Compares two operands of text literals and returns true if they don’t match
Statement rules are the preferred type of rules to use at Knoll. There is a special section just on the appropriate syntax which should be used when writing this kind of rule later in this section.
- Explicit Compatibility rules also require Option Classes or Option Feature as inputs into the rule setup. This is one of the visible rules where after you select the 2 Option Features and Option Classes, you select the options or standard items from a Dropdown list to indicate that the options are compatible by placing them on the same row. Like all compatibility rules explicit compatibility rules never select anything, they only deselect those items which are not compatible.
- You must list out all of the possible combinations of the 2 options which are compatible.
- Any combination you miss are automatically treated as false once the maximum number of selections have been made on at least one of the Option Features or Option Classes
- This type of rule can’t be turned into a statement rule
- Explicit Compatibility rules can require a lot of maintenance every time an Option Feature and or Option Class has had an update to the list of Options under either. This is because compatibilities for the new options has not been made, these options would not be available for selection.
- Design Chart is the last type of compatibility rule and like the others it is very fast at runtime it is also very user friendly visually during rule development. However, it still only sets the options which are not compatible to false. The design chart lists out all of the options for each Option Feature or Class in the form of a matrix. The developer then selects the intersections of the rows and columns the design chart creates, these are then compatible, the column, the row or rows. Design Chart rules allow the developers to pick Primary and one or more Secondary Options which will be part of the rule.
- Design Chart also can require a lot of maintenance every time an Option Feature or Option Class has had an update to the list of Options as new compatibilities need to be updated in the rule.
- Also with the model using Populators you have to use care to make sure the current selections don’t disappear and you have to rebuild them.
Statement Rules
Statement rules are the preferred rules to use at Knoll and should be used all of the time. You can use any of the rules which have the ability to automatically be converted to a statement rule but you must convert them to a statement rule. Tip, sometimes it is a great idea to do just that to get the commands or functions correct until you learn the different key commands.
Statement rules are the most powerful rules we have and it comes with its own programming language and a dedicated Oracle user manual. It is also the only type of rule which we can condition the rule so that it doesn’t do anything until all of the conditions are met.
Statement rules also allow for the use of “Iterators” which allows us to build a rule on the Option Feature(s) and or Option Class(es) which normally never change like the options or items do under the Option Feature or Option Class.
This means much lower maintenance of the model and reduced time spent testing and validating rules because a new item can be added or removed and when you run the Generate Logic the rule is recompiled again with the updated items. All you would need to do is just valid that the new item is working correctly and not then entire rule or list of items.
There are 3 major kinds of statement rules with their own format:
- Keywords
- CONSTRAIN (Logic Rule types) contains only one of the follow keyword operators
- IMPLIES
- EXCLUDES
- REQUIRES ( Try not to use unless you really intend this activity)
- NEGATES (Try not to use unless you really intend this activity)
- DEFAULT (use if required for user selection which allows overrides) it is slower than the rest and it doesn’t always drive additional rules from the defaulted node
- Rules can be conditioned by using one or more of the following logic functions
- AllTrue() – a logical AND expression, can be used on either side of the rule but should NOT be used on the right side of an EXCLUDES rule
- AnyTrue() – is a logical OR expression, can be used on either side, however if there is more than one node in the function on the right side it won’t pick one of them to set the state on
- NotTrue() – Should never be used in a function for Knolls. It returns True if the argument is False or Unknown, however Oracle recommends using a different type of function because this rule forces a rule order which we can’t rely on and is undependable.
- Not AnyTrue() – returns True if the AnyTrue function returns a value of False
- CONTRIBUTE TO (Numeric Rules) negative values will do the consumes
- This type of rule is used to place a numeric value to a Configurator node like Numeric Features, Totals, Resources and Inventory items of all sorts
- If the numeric calculation before the TO is a Decimal value and the node on the Right side of the “TO” is an Integer then you must include a Rounding function around the Numeric expression on the left side. For example:
- Round(numeric expression) – rounds to nearest Integer
- You can also contribute to a decimal node and or BOM item controlling the number of decimals as well using something like RoundToNearest( numeric expression, .01) – rounds to nearest 2 decimal value
- Others include RoundUpToNearest(x,y), RoundDownToNearest(x,y), Ceiling(), Floor()
- The left side of the “TO” can contain any of the keyword operators like the CONSTRAIN rules to allow for a logical condition to become turn before the numeric value to passed to the node on the Right side of “TO”
- CONTRIBUTE AnyTrue(Logical Expression) * Numeric Expression TO model node
- The logical expression returns a Value of 1 for TRUE and a 0 for a FALSE
- If you use a logical expression be sure to have the part of the expression which is FALSE most of the time to the Left side so the rule doesn’t have to evaluate the entire list of conditions before it decides if the total expression is TRUE or FALSE. This will help to keep rule performance as fast as possible.
- CONSTRAIN (Logic Rule types) contains only one of the follow keyword operators
- COMPATIBLE is the keyword which starts the compatibility rule. This is where you can define the list of variables you wish to have in the rule by giving a variable name followed by the key word “OF” followed by the full model path to the Option Feature and or Option Class. These are the only kind model nodes which can be used in Property Base Compatibilities
- Note all Options and Standard items in the Option Features or Option Classes must all have the same Properties used in the rule for each item used in this rule.
- FOR ALL IN – this is the command for defining an iterator and the list of items to be included in the variable. It is a good practice when designing a model and for debug issues to have meaningful names for each variable as to the type of items included in the variable. For example, &X1, &X, &Y1… really doesn’t have any meaning when reading the logical section or Where clause. It is better to use variables like &Lam, &TexSel or &TexColor – these mean something to the model making it easier to understand the rule. The following are examples to create the variables:
- FOR ALL &Lam IN {OptionsOf(‘Top Model’.’Laminate Selection’)} – means the same thing but is more formal
- FOR ALL &Fin IN {OptionsOf(‘Top Model’.’Laminates’), OptionsOf(‘Top Model’.’Veneer’)} – also allows you to have more than one list added together
- FOR ALL &Bom IN {‘BOM_MODEL’.’OPTION_CLASS’.Options()} – this format is used when we need to drive Decimal Quantities to a BOM item of an Option Class.
- FOR ALL &BOM IN { OptionsOf('AUTOSTRADA_TABLE_SUPPORTS'.'AOFL'.'LEG_OPN_FRM_VER_OC'), OptionsOf('AUTOSTRADA_TABLE_SUPPORTS'.'AOFL'.'LEG_OPN_FRM_TOP_OC'), OptionsOf('AUTOSTRADA_TABLE_SUPPORTS'.'AOFL'.'LEG_OPN_FRM_BTM_OC'), OptionsOf('AUTOSTRADA_TABLE_SUPPORTS'.'AOFL'.'CRNR_LEG_OPN_FRM_LH_OC'),
- FOR ALL &nodes IN {‘A’, ‘B’, ‘C’, ‘Top Model’.‘Feature Selections’….} – you can also use format to include standard Items, model nodes including Option Features or Option Classes directly and not their children
- WHERE – is the section to tell the rule how the items and their variables are related and how they can be matched or not matched and so on. Note: the WHERE clause is only for static values, property values and anything which can be determined at the time the rule is being created, NO Runtime Data. All runtime conditions including runtime values or selections is part of the rule definition before any FOR ALL statements.
- Statements inside the WHERE clause are separated by AND or OR keywords
- If using an OR keyword it is advisable to use open and close parenthesis to provide the correct grouping
- COLLECT – The COLLECT operator does what it sounds like, which is it returns a collection of items to be passed to a variable. The collect operator allows us to include a where clause inside the collection so that we can filter a large list of items down to a subset of list we really need to use in the rule. Below is the syntax for a rule using the COLLECT operator:
- FOR ALL &Leather IN {COLLECT &list FOR ALL &list IN OptionsOf(‘Top_Model’.’Textile Selections’) WHERE &list.Property(“Fabric_Type”) = “Leather”}
- The rule snippet above is only going to collect the list of 30 leathers instead of building the iterator with the 163 items that belong to Option Feature of Textile Selections.
- COLLECTS on iterator rules should be used when the sub-list of items is much smaller than the total number of items in the Option Feature or Option Class. This can greatly help increase the runtime performance of the model by reducing the total number of rules the rule actually creates in the system.
- Each Variable can have its own COLLECT operator and you can still have the normal WHERE operator to map the compatibility of all the variables in the rule.
- The WHERE clause inside the COLLECT operator must use only static values which can be identified at rule compile time just like the WHERE statement at the bottom of the rule.
Group rules into Folders and name the folders so that it is easy to understand what all of the rules in the folder are about. Add the folders by inserting a line in the Rules Tab using a different background color and provide a name for the folder as well.
Examples:
Mapping Rules to Left Handed Gables
Mapping Rules to Laminate Desk Top
Calculations mapped to Modesty Panel and Hardware
Rule Examples
It is better to use a Compatibility Rule in place of an Exclude Rule for a couple of reasons:
Point-to-Point rules typically cause more maintenance and testing than Compatibility Rules which are written on Option Features or Classes. These use properties assigned to the option where you can list kinds of items which are excluded for multiple chairs in a single rule and these can be easily updated without touching the rule. Also if one of the textile selections are remove which are part of the rule, the rule must be fixed before you can Regenerate the model and publish.
Compatibility Rules are generally faster than runtime logic rules
For Example:
AnyTrue('EWC'.'Chair Type'.'99WMBU') EXCLUDES AnyTrue('Seat Textiles Selection'.'K1236',
'Seat Textiles Selection'.'K1650', 'Seat Textiles Selection'.'HC1660', 'Seat Textiles Selection'.'K1025',
'Seat Textiles Selection'.'K1697', 'Seat Textiles Selection'.'K1800', 'Seat Textiles Selection'.'K1018',
'Seat Textiles Selection'.'K181', 'Seat Textiles Selection'.'K1657', 'Seat Textiles Selection'.'K1787',
'Seat Textiles Selection'.'K1106', 'Seat Textiles Selection'.'K1522', 'Seat Textiles Selection'.'K1325',
'Seat Textiles Selection'.'K242', 'Seat Textiles Selection'.'K113','Seat Textiles Selection'.'PR',
'Back Textiles Selection'.'K1236', 'Back Textiles Selection'.'K1650', 'Back Textiles Selection'.'HC1660',
'Back Textiles Selection'.'K1025', 'Back Textiles Selection'.'K1697', 'Back Textiles Selection'.'K1800',
'Back Textiles Selection'.'K1018', 'Back Textiles Selection'.'K181', 'Back Textiles Selection'.'K1657',
'Back Textiles Selection'.'K1787', 'Back Textiles Selection'.'K1106', 'Back Textiles Selection'.'K1522',
'Back Textiles Selection'.'K1325', 'Back Textiles Selection'.'K242', 'Back Textiles Selection'.'K113',
'Back Textiles Selection'.'PR');
This rule should be rewritten as so all 4 chair types in this model can be covered quickly by 2 rules covering 2 Textile Selections:
COMPATIBLE
&Chair Of 'EWC'.'Chair Type,
&Seat Of 'EWC'.'Seat Textiles Selection'
WHERE DoesNotContain (&Chair.Property ("EXCLUDED_SEAT_FINISHES"),
&Seat.Name());
COMPATIBLE
&Chair Of 'EWC'.'Chair Type,
&Back Of 'EWC'.'Back Textiles Selection'
WHERE DoesNotContain (&Chair.Property ("EXCLUDED_BACK_FINISHES"),
&Back.Name());
Example of adding Options from multiple Option Classes into a single variable
CONSTRAIN AnyTrue(&Leg) IMPLIES &BOM
FOR ALL &Leg IN OptionsOf('Autostrada Table Supports'.'Paint Finish Selection'),
&BOM IN OptionsOf ('AUTOSTRADA_TABLE_SUPPORTS'.'AOFL'.'LEG_OPN_FRM_VER_OC','AUTOSTRADA_TABLE_SUPPORTS'.'AOFL'.'LEG_OPN_FRM_TOP_OC','AUTOSTRADA_TABLE_SUPPORTS'.'AOFL'.'LEG_OPN_FRM_BTM_OC','AUTOSTRADA_TABLE_SUPPORTS'.'AOFL'.'CRNR_LEG_OPN_FRM_LH_OC','AUTOSTRADA_TABLE_SUPPORTS'.'AOFL'.'CRNR_LEG_OPN_FRM_RH_OC')
WHERE &Leg.Property("FINISH_CODE") = &BOM.Property("GEN_PHYS_SPECS.FINISH_CODE");
This rule should be written as follows:
CONSTRAIN AnyTrue(&Leg) IMPLIES &BOM
FOR ALL &Leg IN OptionsOf('Autostrada Table Supports'.'Paint Finish Selection'),
&BOM IN { OptionsOf('AUTOSTRADA_TABLE_SUPPORTS'.'AOFL'.'LEG_OPN_FRM_VER_OC'), OptionsOf('AUTOSTRADA_TABLE_SUPPORTS'.'AOFL'.'LEG_OPN_FRM_TOP_OC'), OptionsOf('AUTOSTRADA_TABLE_SUPPORTS'.'AOFL'.'LEG_OPN_FRM_BTM_OC'), OptionsOf('AUTOSTRADA_TABLE_SUPPORTS'.'AOFL'.'CRNR_LEG_OPN_FRM_LH_OC'),
OptionsOf('AUTOSTRADA_TABLE_SUPPORTS'.'AOFL'.'CRNR_LEG_OPN_FRM_RH_OC') }
WHERE &Leg.Property("FINISH_CODE") = &BOM.Property("GEN_PHYS_SPECS.FINISH_CODE");
Rule Names
Rule Names should explain what the rule is doing so when looking at all of the rules you can quickly see what each rule is doing. Also each rule should contain a single rule, unless it also takes another to complete the function. Examples:
Rule Name 028 - Overlap Tops Compatibility to Excluded Veneers of Y341, Y342, Y343
COMPATIBLE
&WP OF 'Worksurface Pattern',
&Ven OF 'Veneer Finish Selection'
WHERE
DoesNotContain (&WP.Property("EXCLUDED_FINISHES"), &Ven.Property("FINISH_CODE"));
Rule Name 029 - Antenna Top Finish Types Mapped to Available Finishes using Compatibilities
COMPATIBLE
&WP OF 'Worksurface Pattern',
&Top OF 'Top Surface Selection'
WHERE
Contains (&WP.Property("AVAILABLE_FINISHES"), &TOP.Property("PATTERN_ELEMENT"));
Example using a list of model nodes in a variable
Here a list of Option Features along with Properties on the type of Finish used to drive all combinations of Finishes. Also shows how to use Option Features directly and not the OptionsOf function
Rule Name 011 - Top Surface Selection IMPLIES required types of Finishes
CONSTRAIN AnyTrue(&Top) IMPLIES &Finish
FOR ALL &Top IN OptionsOf('Antenna_Top_Worksurface'.'Top Surface Selection'),
&Finish IN {'Antenna_Top_Worksurface'.'Laminate Top Finish Selection', 'Antenna_Top_Worksurface'.'Laminate Edgeband Finish Selection', 'Antenna_Top_Worksurface'.'Veneer Grade Selection', 'Antenna_Top_Worksurface'.'Veneer Finish Selection', 'Antenna_Top_Worksurface'.'Color Core Laminate Finish Selection', 'Veneer Edgeband Finish Selection'}
WHERE &Top.Property("PATTERN_ELEMENT") = &Finish.Property("PATTERN_ELEMENT");
Rule Name 012 - Top Surface Selection EXCLUDES non compatible types of Finishes
CONSTRAIN AnyTrue(&Top) EXCLUDES &Finish
FOR ALL &Top IN OptionsOf('Antenna_Top_Worksurface'.'Top Surface Selection'),
&Finish IN {'Antenna_Top_Worksurface'.'Laminate Top Finish Selection', 'Antenna_Top_Worksurface'.'Laminate Edgeband Finish Selection', 'Antenna_Top_Worksurface'.'Veneer Grade Selection', 'Antenna_Top_Worksurface'.'Veneer Finish Selection', 'Antenna_Top_Worksurface'.'Color Core Laminate Finish Selection', 'Antenna_Top_Worksurface'.'Veneer Edgeband Finish Selection'}
WHERE &Top.Property("PATTERN_ELEMENT") <> &Finish.Property("PATTERN_ELEMENT");
Never User a NotTrue rule. Here is an example from a model loaded from offshore
AllTrue('EWC'.'Chair Type', NotTrue('EWC'.'Shipping Requirement'.'ASMQ')) IMPLIES AllTrue('EWC_PACKAGING'.'7500900','EWC_PACKAGING'.'7527900',
'EWC_PACKAGING'.'7506900','EWC_PACKAGING'.'7510900','EWC_PACKAGING'.'7612800');
Instead you can use a Total node or Numeric Feature initialized to zero. Create a rule to contribute a one to this node when ASMQ is selected. Then use this numeric node instead of the NotTrue keyword which is cleaner and doesn’t have feedback issues.
Rule format for Decimal Quantities to BOM items
Example of a Contributes Rule applying a Decimal value to a BOM Item.
Note that the variable for the BOM items must be the first variable defined the FOR ALL statement or Oracle parser will not validate the rule.
Rule name - 002 - Selected Laminate Finish Options Contributes To BOM Options
CONTRIBUTE AnyTrue(&Lam) * RoundToNearest(('YT_TOP_L'.'COMMON_NODES'.'PreLaminate_Board_SQFT' * 'YT_TOP_L'.'Order_Qty'), 0.001) TO &BOM.Quantity()
FOR ALL &BOM IN {'YT_TOP_L'.'PREPRESSED_LAMINATE_BOARD_1.25_INCH'.'PRELAMINATE_1.25_INCH'.Options()},
&Lam IN OptionsOf('YT_TOP_L'.'COMMON_NODES'.'Laminate Top Finish')
WHERE &Lam.Property("FINISH CODE") = &BOM.Property("GEN_PHYS_SPECS.FINISH_CODE")
AND &Lam.Property("BACKER_TYPE") = &BOM.Property("VENEER_LAMINATE_LUMBER_SPECS.BACKER_TYPE")
AND &BOM.Property("VENEER_LAMINATE_LUMBER_SPECS.CORE_TYPE") = "PBD"
AND &BOM.Property("GEN_PHYS_SPECS.ITEM_CLASS_CODE") = "HPL PRELAM";
COMPATIBLE
&X1 OF 'Fabric Selection',
&X2 OF 'SAPPER_FABRIC_COLORS_1'
WHERE CONTAINS(",Abacus,Alignment,Arno,Atelier,Bank Shot,Baxter,Beacon,Belize,Biota
,Biscayne,Bocce,Cameo,Cato,Cats Cradle,Chance,Charm,Chroma,Chronicle,", &X1.Property("Textile Name"))
AND &X1.Property("Textile Name") = &X2.Property("TEXTILE_GENERAL.FABRIC_NAME");