An Oracle White Paper

September 2014 (updated)

Use of Oracle Business Rules (OBR) to Tailor

Order Fulfillment for DOO
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

Introduction ......................................................................................... 1 
Oracle Business Rules Basics ............................................................ 2 
OBR Components ........................................................................... 4 
OBR Use in DOO Rules ...................................................................... 5 
User Interface to Construct Rules ................................................... 6 
Nonembedded Interface ......................................................................... 6 
Embedded Interface ............................................................................... 8 
Preparing to Build Rules ............................................................... 10 
Guidelines ..................................................................................... 12 
DOO Facts............................................................................................ 12 
Creating a Simple Rule ........................................................................ 12 
Use of Advanced Mode and Tree Mode .............................................. 12 
Maintaining Object Hierarchy ............................................................... 17 
Use of Extensible Flexfields ................................................................. 19 
Custom DOO Functions ....................................................................... 22 
Use of Bucket Sets ............................................................................... 26 
Use of Date Arithmetic ......................................................................... 27 
Accessing PIM Data ............................................................................. 29 
Error and Conflict Management ........................................................... 40 
Migration, Upgrades, Patches .............................................................. 42 
Release 6 Enhancements .................................................................... 43 
Release 7 Enhancements .................................................................... 43 
Release 8 Enhancements .................................................................... 44 
OBR Use for Transformation ......................................................... 45 
OBR Use for Orchestration Process Assignment.......................... 49 
OBR Use for Orchestration Process Run Time ............................. 51 
Creating a Branching Condition Rule ................................................... 53 
Creating a Line Selection Criteria Rule using EFFs ............................. 54 
Creating a Start After Condition Event Rule......................................... 59 
Creating a Start After Condition Timer Rule......................................... 61 
OBR Use for External Interface Routing ....................................... 65 
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

Figure 1: OBR components .............................................................................................................................. 2 

Figure 2: Hypothetical nodes from order management rules ....................................................................... 3 
Figure 3: Decision table for process assignment ............................................................................................ 6 
Figure 4: If... Then... rules for fulfillment routing (Release 5) ...................................................................... 7 
Figure 5: If... Then... rules for fulfillment routing (Release 7) ...................................................................... 8 
Figure 6: If... Then... rule for orchestration (Release 5)................................................................................ 9 
Figure 7: If... Then... rule for orchestration (Release 8).............................................................................. 10 
Figure 8: Setting advanced mode .................................................................................................................... 13 
Figure 9: Defining collections of objects within rules (Release 5) ............................................................. 13 
Figure 10: Defining collections of objects within rules (Release 7) ........................................................... 14 
Figure 11: Creating tests................................................................................................................................... 14 
Figure 12: Available advanced rule actions.................................................................................................... 15 
Figure 13: Completed advanced rule using if… then… else ...................................................................... 16 
Figure 14: Tree mode and root object setting ............................................................................................... 17 
Figure 15: Object declarations for advanced pretransformation rule ........................................................ 18 
Figure 16: Tests and result for advanced pretransformation rule .............................................................. 19 
Figure 17: Object declarations for EFF use in rules .................................................................................... 20 
Figure 18: Tests and result for EFF use in EIL rules .................................................................................. 21 
Figure 19: Examples of custom functions for embedded rules (Release 5) .............................................. 25 
Figure 20: Examples of custom functions for embedded rules (Release 7) .............................................. 26 
Figure 21: Orchestration rule with date arithmetic ...................................................................................... 28 
Figure 22: Advanced parameter section of getItemData example ............................................................. 30 
Figure 23: Condition section of getItemData example................................................................................ 30 
Figure 24: Action section of getItemData example ..................................................................................... 31 
Figure 25: getItemData parameters ................................................................................................................ 31 
Figure 26: Completed getItemData rule ........................................................................................................ 32 
Figure 27: Advanced parameter section of use item data example ............................................................ 32 
Figure 28: Condition section of use item data example............................................................................... 33 
Figure 29: Action section of use item data example .................................................................................... 34 
Figure 30: Completed assignment rule using item data ............................................................................... 34 
Figure 31: Advanced parameter section of getFusionAppsData example ................................................ 35 
Figure 32: Condition section of getFusionAppsData example................................................................... 35 
Figure 33: Action section of getFusionAppsData example ........................................................................ 36 
Figure 34: getFusionAppsData parameters ................................................................................................... 36 
Figure 35: Completed getFusionAppsData rule ........................................................................................... 37 
Figure 36: Advanced parameter section of line selection rule using Fusion Apps item data ................. 37 
Figure 37: Condition section of line selection rule using Fusion Apps item data .................................... 39 
Figure 38: Condition section of line selection rule using Fusion Apps item data .................................... 39 
Figure 39: Completed line selection rule using Fusion Apps item data .................................................... 40 
Figure 40: Error management ......................................................................................................................... 41 
Figure 41: Conflict identification and resolution .......................................................................................... 42 
Figure 42: Cut, copy, paste actions ................................................................................................................. 43 
Figure 43: Filtering attributes by contained string ........................................................................................ 44 
Figure 44: Advanced parameter section of advanced transformation example ....................................... 46 
Figure 45: Declaration section of advanced transformation example ....................................................... 47 
Figure 46: Decision table section of advanced transformation example................................................... 48 
Figure 47: Completed advanced transformation decision table ................................................................. 49 
Figure 48: Process assignment object declarations....................................................................................... 50 
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

Figure 49: Process assignment tests ............................................................................................................... 51 

Figure 50: Completed advanced process assignment rule ........................................................................... 51 
Figure 51: Simple orchestration branching rule ............................................................................................ 54 
Figure 52: Advanced line selection rule mode selection .............................................................................. 55 
Figure 53: Advanced line selection rule object declarations ....................................................................... 56 
Figure 54: Advanced line selection use of custom function ....................................................................... 57 
Figure 55: Advanced line selection tests ........................................................................................................ 58 
Figure 56: Advanced line selection result ...................................................................................................... 59 
Figure 57: Start after condition event rule 1.................................................................................................. 60 
Figure 58: Start after condition event rule 2.................................................................................................. 61 
Figure 59: Start after condition timer pattern ............................................................................................... 62 
Figure 60: Start after condition timer condition ........................................................................................... 63 
Figure 61: Start after condition timer result .................................................................................................. 64 
Figure 62: Start after condition timer else result........................................................................................... 65 
Figure 63: Advanced settings for routing rule............................................................................................... 66 
Figure 64: Object declaration section of advanced routing rule ................................................................. 66 
Figure 65: Test section of advanced routing rule ......................................................................................... 67 
Figure 66: Action section of advanced routing rule ..................................................................................... 67 
Figure 67: Completed advanced routing rule ................................................................................................ 67 
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

Introduction

Oracle Business Rules (OBR) is a technology provided by Oracle Fusion Middleware to allow customers to
include complex business processing decisions into the overall product architecture. Oracle Fusion
Distributed Order Orchestration (DOO) enables OBR in every aspect of processing. This document
presents an overview of the underlying functionality that OBR provides as an introduction to the
technology. Then the focus moves to how DOO has implemented OBR to solve its rules requirements.
Screenshots are provided throughout the document to provide setup details and specific syntax
requirements are described where appropriate to the rules being constructed. Within the overall guidelines,
specific topics in the building of rules include:

Maintaining object hierarchy

Use of EFFs

Custom DOO functions

Use of bucket sets

Use of date arithmetic

.Note that the original examples provided in this document were constructed in a Release 5 environment.
Enhancements were added in Release 6 and Release 7, including changes to the user interface. Additional
enhancements were added in Release 8, but there were no changes to the OBR user interface. References to
enhancements will contain the application version number where the enhancement is first available.

Note also that additional worked examples can be found in the Oracle Fusion Applications Order
Fulfillment, Order Orchestration Guide, and the Oracle Fusion Applications Order Orchestration
Implementation Guide.

1
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

Oracle Business Rules Basics

Figure 1 provides an overall diagram of the interaction of the various objects that are required for use
of OBR. ‘Facts’ are the data that are supplied to the rules engine, such as the items on an order. These
are used in formulating the rules themselves and are some of the objects held in rule dictionaries
(repository). In addition to facts, rule dictionaries contain the rules themselves, organized into rule
sets, as well as other supporting objects, such as rule-specific variables and custom functions used in
rule actions. Decision services are used to access the rules engine from BPEL processes.

Figure 1: OBR components

In OBR the rule-based system is a data-driven forward chaining system. The facts (data input)
determine which rules can fire. When a rule fires that matches a set of facts, the rule may add new
facts. These new facts are once again run against the rules. This process repeats until a conclusion is
reached or the cycle is stopped or reset. Thus, in a forward-chaining rule-based system, facts cause
rules to fire, and firing rules can create more facts, which in turn can fire more rules or re-fire rules that
have fired before. This process is called an inference cycle. Because OBR action is based on an
inference cycle, the firing of rules cannot be considered sequential and it is possible to create rules that
are in conflict with one another based on complex interactions. Also, because the rules can be
executed more than once, depending on the impact on the condition data resulting from each cycle, it
is important to make sure that there are no cyclical dependencies that may cause infinite looping.
A rule-based system using the Rete algorithm is the foundation of OBR. The Rete algorithm is an
efficient pattern matching algorithm for implementing production rule systems. A Rete-based expert
system builds a network of nodes, where each node (except the root) corresponds to a pattern
occurring in the left-hand-side (the condition part) of a rule. The path from the root node to a leaf

2
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

node defines a complete rule left-hand-side. Each node has a memory of facts which satisfy that
pattern. As new facts are asserted or modified, they propagate along the network, causing nodes to be
annotated when that fact matches that pattern. When a fact or combination of facts causes all of the
patterns for a given rule to be satisfied, a leaf node is reached and the corresponding rule can be
triggered. Figure 2 provides an example of nodes that may be generated by a hypothetical set of order
management rules.

Figure 2: Hypothetical nodes from order management rules

A rule-based system consists of the following:

• Rule base: Contains the appropriate business policies or other knowledge encoded into If-Then rules.
The rule base consists of the rules in the rule dictionary.

3
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

• Working memory: Contains the information that has been added to the system. With OBR the user
adds a set of facts to the system using assert calls which are then assembled into nodes by the engine.
• Inference engine: The rules engine, which processes the rules, performs pattern-matching to
determine which rules match the facts, for a given run through the set of facts.
The Rete algorithm provides the following benefits:
• Independence from rule order: Rules can be added and removed without affecting other rules.
• Optimization across multiple rules: Rules with common conditions share nodes in the Rete
network.
• High performance inference cycles: Each rule firing typically changes just a few facts and the cost
of updating the Rete network is proportional to the number of changed facts, not to the total number
of facts or rules.
The OBR rules engine is a Java library that efficiently applies rules to facts and defines and processes
rules. The rules engine defines a declarative rule language, provides a language processing engine
(inference engine), and provides tools to support debugging.
The rules engine has the following features:
• High performance: Implements specialized matching algorithms for facts that are defined in the
system.
• Thread-safe execution suitable for a parallel processing architecture: Provides one thread that
can assert facts while another is evaluating the network.
• Agility: Allows rules to change without stopping business processes.

OBR Components
The following components are used in Oracle Business Rules:
• Dictionaries: A dictionary is an Oracle Business Rules container (repository) for facts, functions,
global variables, bucket sets, links, decision functions, and rulesets. A dictionary is an XML file that
stores the application's rule sets and the data model. Distributed Order Orchestration supplies a
number of pre-populated dictionaries that are accessed through Setup and Maintenance to create rules
for specific steps.
• Decision Tables: A decision table is an alternative business rule format that is more compact and
intuitive than the individual If… Then… format when many rules are needed to analyze many
combinations of property values. You can use a decision table to create a set of rules that covers all
combinations or where no two combinations conflict.
• Rule Conditions: The IF part of the rule is composed of conditional expressions, rule conditions that
refer to facts. For example: IF Ordered Quantity < 20. The conditional expression compares a
business term (Ordered Quantity) to the number 20 using a less than comparison. The rule condition

4
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

activates the rule whenever a combination of facts makes the conditional expression true. In some
respects, the rule condition is like a query over the available facts in the rules engine, and for every row
returned from the query the rule is activated.
• Rule Actions: The THEN part of the rule contains the actions that are executed when the rule is
executed. A rule is executed after it is activated and selected among the other rule activations using
conflict resolution mechanisms such as priority. A rule might perform several kinds of actions. An
action can add facts, modify facts, or remove facts. An action can execute a Java method or perform a
function which may modify the status of facts or create facts.
• Facts: In Oracle Business Rules, facts are the data objects that rules reason on. Distributed Order
Orchestration provides a hierarchy of facts based on the Distributed Order Orchestration transactional
order data for each rule dictionary. In Oracle Business Rules, facts that you can run against the rules
are data objects that have been asserted; i.e., submitted to the rule engine. Each object instance
corresponds to a single fact. If an object is re-asserted (whether it has been changed or not), the Rules
Engine is updated to reflect the new state of the object. Re-asserting the object does not create a fact.
To have multiple facts of a particular fact type, separate object instances must be asserted.
• Bucket Sets: You can create bucket sets to define a list of values or a range of values of a specified
type for rule conditions. After you create a bucket set you can associate the bucket set with a condition
fact of matching type. Oracle Business Rules uses the bucket sets that you define to specify constraints
on the values associated with condition facts in decision tables.

OBR Use in DOO Rules

Oracle Fusion Distributed Order Orchestration (DOO) enables OBR in every aspect of processing.
OBR is used in:
• Product transformation: The three sets of product transformation rules allow users to change the
order line and its associated product from a sales focus to a fulfillment focus in a granular manner. If
the sales view is the same as the fulfillment view, these rules are optional.
• Pre defaulting
• Transformation
• Post defaulting
• Process assignment: Process assignment rules are built to let DOO know which orchestration
process should be used to fulfill order lines.
• Orchestration processing: Once orchestration has begun, there are several rules attributes available
to direct processing, such as filtering lines from task actions, branching the process, complex planning
lead time calculations, and change management.
• External interface routing: External interface routing rules allow the user to designate which
fulfillment system should receive an individual request.

5
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

All of these rules used together provide a high degree of customization to automated fulfillment
processing.

User Interface to Construct Rules

Two basic types of user interface have been provided by OBR for rules management. For all of the
rules except those in orchestration, the DOO administration user interface is based on the web-
enabled SOA Composer user interface provided by Fusion middleware. This interface will be referred
to as ‘nonembedded’ in this document. The user interface for orchestration rules will be referred to as
‘embedded’ in this document.

Nonembedded Interface

Two kinds of formats are available in this interface to create rules, decision tables and if…then…
Decision tables allow multiple rules to use the same conditions and actions, while the if…then…
construct allows users to create rules individually. Both result in the same run time behavior.
• Decision Table: In a decision table the ‘If’ clauses are labeled ‘Conditions” and the ‘Then’ clauses are
labeled ‘Actions’. A decision table allows a number of rules to use the same conditions and actions in a
selective manner.

Figure 3: Decision table for process assignment

6
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

• If… Then…: This format represents how a single business rule would be stated, “If a condition is
true, then an action is taken”. Note that there are slight changes in the user interface between Release
5 and Release 7.

Figure 4: If... Then... rules for fulfillment routing (Release 5)

7
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

Figure 5: If... Then... rules for fulfillment routing (Release 7)

Embedded Interface

OBR is also used to manage the orchestration process at run time. These rules are set up as part of the
administration of the orchestration process definition using a popup component provided by Fusion
middleware. Only the If… Then… format is available for orchestration rules. Note that this latter set
of rules is versioned along with the process definition as part of release and deployment of the process.
Orchestration rules are migrated to other environments as part of the orchestration process definition.
(See section on Migration, Upgrades, Patches.)
Note that starting with Release 8, the rule-building window area has been expanded and an additional
button, ‘Validate’ has been added. Both ‘Save’ and ‘Validate’ will save the rule definition and run
syntax validation. However, ‘Validate’ leaves the window open for further rule development.

8
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

• Orchestration

Figure 6: If... Then... rule for orchestration (Release 5)

9
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

Figure 7: If... Then... rule for orchestration (Release 8)

While some of the DOO rule dictionaries are available in jDeveloper, DOO does not recommend the
use of jDeveloper because of issues with patching and object instantiation. DOO provides web-
enabled setup UIs through the Fusion Functional Setup Manager (FSM) for all rule setups. FSM also
provides the ability to migrate some setup data from one environment to another. It is recommended
that the rules be managed through these user interfaces rather than through jDeveloper. Rules used by
orchestration at run time can only be managed through the orchestration process definition user
interface to support process versioning requirements. These rules are migrated with the orchestration
process definition. (See section on Migration, Upgrades, Patches.)

Preparing to Build Rules

The following is a set of guidelines for designing business rules that will be implemented in OBR to
manage fulfillment processing in DOO.

10
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

1. Construct the set of rules in an “if…then…” format using natural language. For example, “If the
product type is server, then add extra packing to the shipping instructions.”
2. Identify which data objects contain the attributes needed for the rule. In this example, the product
type is represented in the DOO data model by Item Type, which can be found on the fulfillment
line. Shipping instructions are also contained in an attribute exposed on the fulfillment line. Oracle
Enterprise Repository (OER) provides information on DOO tables that are the foundation of the
data objects. More information on OER can be found in the support document “How To Get The
Most From Oracle Enterprise Repository For Troubleshooting Fusion Applications” (Doc ID
1399910.1).
3. Examine the set of rules to determine whether all required objects will always be populated or if
defaults or not-null provisions need to be made. For example, not-null provisions should always be
used with extensible flexfields (EFFs) because they are user-defined objects and therefore optional.
4. Examine the set of rules to identify any circumstances that might cause rule conflicts at run time. For
example, a general rule that assigns a fulfillment line with product type of server to one process will
be in conflict with another that assigns a specific server product to another process. The first rule
must be revised to specify fulfillment lines with a product type of server that are not the one specific
server product used in the second rule. The setup user interface provides some information about
potential conflicts after the rule is saved. Note that because of the nature of inference engines, you
should also check for circular dependencies, where the result of one rule changes the conditions for
another in a way that causes infinite looping. It is also a good idea to have a default or ‘catch-all’ rule
in circumstances where a value must be set.
5. If you are comparing one data object to another of the same type, use advanced mode and create two
variables to represent the data objects in the comparison. You must specify that variable one is not
the same as variable two by setting up a test for “variable1 isn’t variable2”. Otherwise OBR will also
use the circumstance where variable1 and variable 2 represent the same object instance in
determining if the rule applies.
6. Consider the outcome under a variety of data inputs. The “if… then…” construct is the most
common but advanced mode also provides “if… then… else”, although there are limitations to the
conditions that can be constructed in the secondary ‘if’ clause.
7. If you need the same set of conditions and actions for a number of rules, consider constructing a
decision table. Even if all conditions and actions are not used for every rule, setup may be simplified
and the group of rules may be displayed in a more readable format.. Also, bucket sets can simplify
the enumeration of condition options in a decision table. Actions can be parameterized to provide
different values for the same attribute in each rule.
8. Add the equivalent of an ‘otherwise’ rule or condition so that there is a specified alternative if other
rule conditions are not met. This is particularly important for process assignment and EIL routing
rules or processing may be interrupted.

11
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

Guidelines
This section provides specific guidance once you are working in a rules setup UI.

DOO Facts

‘Facts’ are the data objects that OBR uses to evaluate the rules at run time. All DOO facts are derived
from the DOO data model and do not include data external to DOO. DOO facts for transformation,
process assignment, and EIL are based on ADF business component objects, specifically view objects,
that expose the DOO data model. While these view objects, or VOs, provide a hierarchical view of
transactional data such as orders, when they are submitted to OBR they are converted to RL (rule
language) objects (facts), which have no hierarchy. Users are not required to manage the RL facts.
However, the point that this background conversion is required to submit facts to the rule engine has
implications in how rules are constructed. See the section on Maintaining Object Hierarchy.
In contrast to the use described in the previous paragraph, DOO facts for orchestration are based on
java facts. This is related to the way that the rule interface is implemented, as described previously.
Most of the differences in presentation and behavior of facts are related to the fact type that is used.

Creating a Simple Rule

Users have the ability to create both simple and complex rules in any of the rules setup UIs. A simple
rule would involve only one data object as a reference for conditions so that issues of hierarchical
placement do not arise. Figure 5 (If... Then... rule for orchestration branching) in the previous section
provides an example of a simple rule used as a branching condition in an orchestration process. It
examines the fulfillment line attribute, orderedQuantity, and if the value is greater than 1000, the
branch is chosen. Details of the setup are covered in the section on orchestration rules.
If more than one data object is needed in a rule, then additional setup is required so that the
relationships between the objects can be defined. Correct relationship definition increases
performance and can also have an effect on outcome, such as comparing the transactional item
attributes only for a specific fulfillment line vs. comparison across fulfillment lines.

Use of Advanced Mode and Tree Mode

If you click on the double arrow next to the rule name it opens a section where you can set additional
parameters for the rule. This is displayed in the screenshot below. Choices for effective date include
Always, Range, From, and To, with a default of Always. The ‘Range’ setting allows you to set both
‘from’ and ‘to’ values.
Priority is a setting that is rarely used in the DOO context. It affects how rules are fired when rulesets
become large. Note that priority is not an absolute setting because rules can be re-fired in the run time
session if their inputs change and the order in which the engine activates rules for firing also affects
priority. Priority is also not useful across rulesets.
The active flag when unchecked and released makes a rule inactive even if it has been previously
released as an active rule. Inactive rules do not participate in validation.

12
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

Creating an Advanced Pretransformation Rule

1. Set advanced mode by checking the box.

Figure 8: Setting advanced mode

Advanced mode provides the ability to set variable names for objects (rule test variables) as explicit
declarations; e.g., so that two instances of an object can be compared or hierarchical relationships can
be manually created. It also provides additional functionality such as the ability to define collections of
objects in conditions, using the values shown in the following screenshot – for each case where, there
is a case where, there is no case where, or aggregate. Define the patterns (object declaration plus
associated tests) in the advanced mode for each entity that the DOO order might have. Note that
entities that will be used in the Then… clause should also be declared in this section. In this example
we have used the following pattern, where fline represents the PreTransformationRules.FulfillLineVO:
• (for each case where) In order to enable the selection, click on the parentheses icon (Release 5) or
the gear icon (Release 7) next to the pattern (object declaration) so that the pattern and its tests are
enclosed in parentheses.
• fline is a PreTransformationRules.FulfillLineVO

Figure 9: Defining collections of objects within rules (Release 5)

13
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

Figure 10: Defining collections of objects within rules (Release 7)

2. After the last pattern (object variable) is declared, define the tests appropriately so that the patterns for
all the objects are linked together to match the order hierarchy if more than one object is used.
Make sure to include non-null tests in case you have optional objects, such as EFF objects to avoid
null pointer exceptions at runtime. In this example only the FulfillLineVO is used so its declaration
completes the pattern and the test represents the required condition for the rule. In business terms,
it is “If more than 1000 of the item are ordered”.
• fline.OrderedQuantity more than 1000

Figure 11: Creating tests

Advanced mode also provides a more extensive list of actions, such as If… Then… Else…, as
presented in the screenshot below. This rule provides an example where a specific action is taken
based on an additional condition in the action section and an alternative (else) is provided if the
additional condition is not true. It is always a good practice to provide a generic alternative for
conditions that may be unforeseen.
3. Add actions to the Then… clause of the rule to create the desired outcome; in this case, an additional
condition, “If the order is received from the legacy order capture system”, is checked before the
actions are specified.
• if fline.SourceOrderSystem is “LEG”

14
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

• then assert new PreTransformationRules.ModifyEntity(attrName:”Carrierid”,

attrValue:30000004511748L, viewRowImpl:flineViewRowImpl)
• else assert new PreTransformationRules.ModifyEntity(attrName:”Carrierid”,
attrValue:30000004433678L, viewRowImpl:flineViewRowImpl)

Figure 12: Available advanced rule actions

The screenshot below presents the completed pretransformation rule, which uses the advanced mode
options of ‘for each case where’ and object aliasing in the conditions section and If… Then… Else…
in the actions section.

15
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

Figure 13: Completed advanced rule using if… then… else

Tree mode requires the user to set a ‘root’ for the hierarchy and only objects at the root level or below
are then available for building the rules. Note that the best practice is to use advanced mode whenever
tree mode is selected.

Specifying the Root Object for Orchestration Line Selection Criteria

1. Define patterns, including specifying the root of the hierarchy for tree mode. In the following example
the root is the order header. The rest of the steps for this example are covered in the section on
orchestration rules.
• Root: DOOSeededOrchestration Rules.DOOHeader

16
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

Figure 14: Tree mode and root object setting

Maintaining Object Hierarchy

When ADF BC fact types are used in rules the view object (VO) hierarchy needs to be re-established in
every rule that uses more than one object type. This will ensure that the system performs optimally.
This can be done through the use of advanced mode with explicit joins or through the use of advanced
mode plus tree mode where the hierarchy is more apparent. If advanced mode alone is used, all the
VOs that are present in the DOO order that will be used in the rule conditions (if) or actions (then)
need to be joined in the right hierarchy to efficiently use the rules. The header VO needs to be joined
with the line VO, the line VO needs to be joined with the fulfillment line VO and so on for all VOs in
the hierarchy. However, if tree mode is also used, the objects can be selected within existing
hierarchies, such as Header/Line/FulfillLine. Note that additional joins may still be needed even in
tree mode if extensible flexfields (EFFs) are used.
Advanced mode also allows the user to set variable names for objects (rule test variables) as explicit
declarations; e.g., so that two instances of an object can be compared or hierarchical relationships can
be manually created. Tree mode requires the user to set a ‘root’ for the hierarchy and only objects at
the root level or below are then available for building the rules.

17
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

The ADF Business Components fact type also contains the following:
• A property named ViewRowImpl which points directly to the oracle.jbo.Row instance that each fact
instance represents. This property is often found in the result signature and is required for
transformation rules. It is optional for other rules.
• A property named key_values which points to an oracle.rules.sdk2.decisionpoint.KeyChain object.
You can use this property to retrieve the set of key-values for this row and its parent rows. DOO does
not require this property.
The steps and screenshots below present an example of a pretransformation defaulting rule definition
using advanced mode but not tree mode. This means that the hierarchy is explicitly defined in the rule.
The business rule statement is: If the source system is Oracle, then set the ship set name to Express
Shipment.
The setup sequence is:
1. Define the patterns in the advanced mode for each VO entity that the DOO order might have. In this
example we have used the following patterns:
• header is a PreTransformationRules.HeaderVO
• line is a PreTransformationRules.LineVO
• fline is a PreTransformationRules.FulfillLineVO

Figure 15: Object declarations for advanced pretransformation rule

18
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

2. After the last pattern (object variable) is declared, define the tests appropriately so that the patterns for
all the VOs are linked together to match the order hierarchy. Make sure to include non-null tests in
case you have optional VOs, such as EFF VOs to avoid null pointer exceptions at runtime. In this
example you need to join HeaderVO with LineVO and LineVO with FulfillLineVO,
• header.OrderLine contains line
• line.OrderFulfillLine contains fline
• Add your custom tests to represent your business rules; in this case, header.SourceOrderSystem is
“ORACLE”
3. Add actions to the Then… clause of the rule to create the desired outcome; in this case:
• assert new PreTransformationRules.ModifyEntity(attrName = “ShipSetName”, attrValue
“ExpressShipment”, viewRowImpl = fline.ViewRowImpl.)
Note that fline is the declared variable for the PreTransformationRules.FulfillLine object.
PreTransformationRules.ModifyEntity is a custom function that DOO provides to update ADF-BC
facts.

Figure 16: Tests and result for advanced pretransformation rule

Use of Extensible Flexfields

Extensible flexfields (EFFs) can be used in all DOO OBR rules. However, they do not show up as
attributes by name in some of the interfaces. DOO has provided custom functions in these interfaces
to facilitate the lookup of EFFs in order to aid in rules setup. Examples will be provided in each
section to demonstrate the setup of rules with EFFs in each interface. Additional worked examples
can be found in the white paper, Oracle Fusion Distributed Order Orchestration: Extensible Flexfield
Usage. (See DOO: Oracle Fusion Distributed Order Orchestration White Papers [Article ID
1536633.1])

19
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

Nonembedded UI Syntax

Use the following syntax for accessing EFFs when building rules for transformation, process
assignment, or EIL. The screenshots below are from an EIL rule definition that uses fulfillment line
EFFs. These guidelines for EFF use can be applied to all other rules although an additional test needs
to be added in process assignment rules cover the grouping of fulfillment lines. An explicit example of
a process assignment rule is presented in the corresponding section of this document.
Here are the steps, using _ShippingInstruction as the EFF field. For the purposes of this example, an
EFF has been created that carries additional information related to shipping from non-Fusion systems.
ThePackShipInstruction element of this EFF provides packing details. The business rule statement is:
If the fulfillment line is a return line, and the shipping instructions have been specified (not null), then
send the line to the non-Fusion receiving system for processing.
1. Define patterns using advanced mode for the relevant VO entries. In this example we have used the
following patterns for the order header, fulfillment line, and fulfillment line EFF category of
DooFulfillLinesAddInfo and context of PackShipInstruction. Note that ‘header’, ‘fline’,
‘flineEFFCtgry’, and ‘flineEFFCntx’ are object variable names chosen for this example. You can use
other object variable names.
• header is a DOOExternalInterfaceLayer.HeaderTLVO
• fline is a DOOExternalInterfaceLayer.FulfillLineTLVO
• flineEFFCtgry is a
DOOExternalInterfaceLayer.j_FulfillLineEffDooFulfillLinesAddInfoprivateVO
• flineEFFCntx is a DOOExternalInterfaceLayer.FulfillLineEffBPackShipInstructionprivateVO

Figure 17: Object declarations for EFF use in rules

20
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

2. After the last pattern (variable declaration), define the tests appropriately so that the patterns are linked
together to create the order hierarchy. Make sure to have not-null checks before using the EFF
category and context to avoid null pointer exceptions at runtime for scenarios where EFFs are not
present. Note that you can also place the tests with the corresponding object declarations as long as
you do not use objects that have not yet been declared. In this example we have the following EIL
rule tests:
• header.TaskTypeCode is "Return"
• header.FulfillLineTLVO1 contains fline
• flineEFFCtgry isn’t null
• flineEFFCntx isn’t null
• fline.FulfillLineEffCategories is flineEFFCtgry
• flineEFFCtgry.FulfillLineEffBPackShipInstructionprivateVO is not null
• flineEFFCtgry.FulfillLineEffBPackShipInstructionprivateVO contains flineEFFCntx
• flineEFFCntx._ShippingInstruction isn't null

Figure 18: Tests and result for EFF use in EIL rules

3. Finally, add the action (also shown in Figure 8):

• assert new DOOExternalInterfaceLayer.Result with the arguments resultObj:”NonFusionReturn”,
resultObjKey:”SERVICE-NAME”

21
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

Embedded UI Syntax

When building rules for orchestration, use the following syntax for accessing EFFs. The example
shows the result syntax for line selection criteria. The business rule statement is: If the line is a reward
item, then include it in processing for this step. Note that this example uses tree mode to maintain the
hierarchy rather than explicitly creating the hierarchy. You can identify the hierarchical version of the
object by the ‘/’ character; e.g., header/childFLines . A custom function on the flexContexts (EFF)
object, getFlexAttributeValue(), is used to look up the EFF value. Also note that ‘header’, ‘fline’, and
‘flineEFF’ are object variable names chosen for this example. You can use other object variable
names.
1. Patterns
• Root: DooSeededOrchestrationRules.DOOHeader
• header is a DooSeededOrchestrationRules.DOOHeader
• fline is a header/childFLines
• flineEFF is a header/childFLines/flexContexts
2. Tests

• flineEFF.context.equalsIgnoreCase("Item_Information") is
DooSeededOrchestrationRules.Boolean.TRUE
• flineEFF.getFlexAttributeValue("_Reward_Item") isn’t null
3. Action
• assert new DooSeededOrchestrationRules.Result (resultObjKey:FLine.fulfillLineId)
Note that the use of the function ‘equalsIgnoreCase’ in the third test is optional if the administrator
knows the absolute case of the argument. Additional examples of the use of EFFs in specific DOO
rule types are provided in later sections of this document.

Custom DOO Functions

DOO has provided a number of custom functions to provide extra capabilities within rule execution.
Most functions are specific to the user interface (UI) type, which can be simplified as non-embedded
and embedded. The former refers to all of the transformation UIs, process assignment, and EIL. The
latter refers to all of the orchestration UIs documented in later sections.

Functions Available in All UIs

DOO has added a set of functions that allow users to bring data from the item (PIM) tables into the
rule session. These functions can be used in rules created in both the non-embedded and embedded
UIs.

22
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

• getItemData – provides a lookup to three PIM entities represented in the OBR facts. These entities
are not populated when the session begins, but only for the entities and attributes specified when the
rule runs. Because the entities and attributes are part of the dictionary, results are saved to named
attributes. A rule using this function should be given the highest priority setting so that it runs at the
beginning of the session.
• getFusionAppsData – provides a lookup to additional PIM entities and attributes that are specified in
the rule. Results are saved to generic attributes that are not populated until the rule is executed. A rule
using this function should be given the highest priority setting so that it runs at the beginning of the
session.

Nonembedded UI Functions

DOO provides custom functions for the transformation rules to assist the user in altering an attribute
or adding or removing an order line. An additional function has been added to modify attributes
within the context of the DOO attributes. All of the functions are selected using the OBR ‘assert new’
action. The functions and their arguments are:
• ModifyEntity – available in Pretransformation, Transformation, and Posttransformation. This
function should be used instead of the standard OBR ‘modify’ action. The arguments are
attrName(String), attrValue(Object), and viewRowImpl(oracle.jbo.server.ViewRowImpl). Note that if
you populate attrName() from the object selection list, you must put the selected attribute in quotes.
The name of the attribute is the required data type, not the value of the attribute at run time.
• AddNewOrderLine – available in Transformation. This function is used to add another line to the
order. The arguments are newItemId(Long) and viewRowImpl(oracle.jbo.server.ViewRowImpl).
• DeleteOrderLine – available in Transformation. This function is used to remove a line from the
order. The arguments are fulfillmentLineId(Long) and viewRowImpl(oracle.jbo.server.ViewRowImpl).
Note that the viewRowImpl(oracle.jbo.server.ViewRowImpl) argument represents the current object
instance; e.g., the specific fulfillment line record.

Embedded UI Functions

DOO provides custom functions for use in orchestration rules to simplify the setup of rules for date
calculations, change management, and for the use of EFFs in rules, including during change
management. All of these functions work at the attribute level. They can be found on the Functions
tab of the Expression Builder popup as the first entries under each object. Note that there are
additional ‘native’ date functions that are available for each date attribute. These are documented in
the section on date arithmetic.
The custom date functions include:
• getAdjustedDate(Timestamp, Double) – adds or subtracts second argument (in days) from first,
depending on sign; returns Timestamp value.

23
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

• subtractFromDate(Timestamp, Timestamp) – subtracts second timestamp argument from first; if

second argument is null, subtracts current date from first argument; returns number of days as
BigDecimal() value.
The change management functions for attributes on the header, fulfillment line, or EFF include:
• hasChanges() – determines whether EFF values in the change order are different from the values in
the previous version of the order.
• attributeChanged(String) - determines whether the value of the selected attribute in the change order
is different from the value in the previous version of the order. Note that the attribute name is
preceded by “_” and must be in quotes. Available for header, fulfillment line, and EFF context.
There are additional fulfillment functions for header, fulfillment line, and EFFs, which can also be used
during change management:
• getFlexAttributeValue(String) – returns the value of the specified EFF attribute of data type ‘string’.
Note that the attribute name is preceded by “_” and must be in quotes. Available for EFF context.
• getFlexAttributeDateValue(String) – returns the value of the specified EFF attribute of data type
date (timestamp)’. Note that the attribute name is preceded by “_” and must be in quotes. Available
for EFF context.
• getFlexAttributeNumValue(String) – returns the value of the specified EFF attribute of data type
‘number’. Note that the attribute name is preceded by “_” and must be in quotes. Available for EFF
context.
• getAttribute(String) – returns the value of the supplied attribute name. Available for header and
fulfillment line. Also available for process and task.
• getTransactionalAttribute(String) – returns the value of the supplied transactional attribute name.
Available for fulfillment line.
• getFlexContext(String) – returns the EFF context based on the supplied name. Available for
fulfillment line.
The functions that can be used with EFFs in an orchestration rule are shown in Figure 18 (Release 5)
and Figure 19 (Release 7).

24
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

Figure 19: Examples of custom functions for embedded rules (Release 5)

25
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

Figure 20: Examples of custom functions for embedded rules

(Release 7)

Use of Bucket Sets

Bucket sets are used to specify values for the conditions in a decision table. They cannot be added by
the DOO Administrator to other facts. In a decision table, a bucket set defines a list of values or value
ranges in the condition expressions that are part of the decision table. The bucket set values or ranges
determine, for each condition expression, that it has two or more possibilities. Each rule can use one
or more values from the bucket set. For example, if a bucket set is defined for colors, then the buckets
could include a list of strings: "blue", "red", and "orange". A rule could be written for each color or
one rule for “blue” and another for both “red and “orange”. A bucket set that includes integers could
have three buckets, less than 1, 1 to 10, and greater than 10.
Bucket sets can also be used to provide aliases for less recognizable elements, such as ids. In this case
the .toString() function should be used in the condition expression to cast the value from the long
(numeric) type to a string alias, such as a product code. The bucket set would contain the mapping of
id to code.
There are three ways to generate a bucket set
• Local list of values/list of ranges: These are set up within the decision table itself.

26
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

• Global bucket set (manual): These are set up within a particular (nonembedded) rules setup UI and can
be selected in the local list of values list for all decision tables managed in that UI. Note that only
bucket sets with matching data types show up in the list.
• Global bucket set (scheduled service): These are set up using the Generate Bucket Sets scheduled
service. The scheduled service is particularly useful when a large bucket set needs to be generated from
transactional data.

Use of Date Arithmetic

While OBR does provide built-in functions for date arithmetic (e.g., scheduled ship date – 1), they
cannot be used with DOO’s facts because of data type and object hierarchy issues. However, it is still
possible to perform date arithmetic in orchestration rules. Note that DOO date attributes are actually
timestamps in terms of data type and that the path is considered by OBR to be part of the data type.
Here is an example of a condition where fline is the alias for the fulfillment line object and where the
scheduled ship date is compared to the current date. Note that time in milliseconds is the comparison
conversion.
• If fline.scheduleShipDate.time>=CurrentDate.date.timeInMillis
Here is an example of a condition where fline is the alias for the fulfillment line object and the desired
calculation is two days before the scheduled ship date. The calculation uses 3 days and then converts
the units based on the number of hours in a day, minutes in an hour, seconds in a minute, and then
milliseconds.
• If fline.scheduleArivalDate.time>= CurrentDate.date.timeInMillis+3*24*60*60*1000
Figure 18 provides a screenshot of a completed orchestration line selection criteria rule. The purpose
of the rule is to skip the step (no fulfillment lines selected) if the requested arrival date is earlier than
three days after the current date.
1. Test
• DooSeededOrchestrationRules.DOOFLine.requestArrivalDate.time more than
CurrentDate.date.timeInMillis+3*24*60*60*1000
2. Action
• Assert new
DooSeededOrchestrationRules.Result(DooSeededOrchestrationRules.DOOFLine.fulfillLineId)

27
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

Figure 21: Orchestration rule with date arithmetic

Note that the time calculation is in milliseconds (msec) – 3 days* 24 hours/day*60 minutes/hour *60
seconds/minute*1000msec/second.
If this kind of calculation is used in the outcome of a rule (Then clause), be careful not to modify the
original value or it may be overwritten. You may need to assign a transient variable to hold the
calculation before populating the result object.
DOO provides a Timestamp object that can be used to create transient variables to be used for date
arithmetic, such as where you want to provide an offset to a specific data attribute; e.g., ‘three days
before the scheduled ship date’. The action ‘assign new’ is used to instantiate this variable, provide an
alias, and set the initial value.
For example, for a lead time expression orchestration rule action where ‘fline’ represents the fulfillment
line object and ‘DateTime’ the transient variable:
• assign new DooSeededOrchestrationRules.Timestamp DateTime = fline.scheduleShipDate
• modify DateTime(time:DateTime.time-(2*24*60*60*1000))
• assert new DooSeededOrchestrationRules.Result(resultObj:DateTime)

28
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

Date Functions Available in Advanced Mode

The following date functions are available for all UIs when using advanced mode rules. The functions
are available for all of the DOO timestamp data type attributes, including transient variables declared
using the Timestamp object and are in addition to the custom date functions that DOO provides. The
function can be typed in after selecting the attribute or you can open the Expression Builder (icon on
the Condition Browser), select the Functions tab and open the folder by the date attribute.
• before(Timestamp|java.util.Date) – output is Boolean (true or false – no quote marks needed)
• example: If fline.RequestArrivalDate.before(fline.ScheduleArrivalDate) is true
• after(Timestamp|java.util.Date) – output is Boolean (true or false – no quote marks needed)
• example: If fline.RequestArrivalDate.after(fline.ScheduleArrivalDate) is true
• compareTo(Object|Timestamp|java.util.Date) – output is -1 if before, 0 if equal, 1 if after
• example: If fline.RequestArrivalDate.compareTo(fline.ScheduleArrivalDate) is -1
• equals(Object|Timestamp) – output is Boolean (true or false – no quote marks needed)
• example: If fline.RequestArrivalDate.equals(fline.ScheduleArrivalDate) is true

Accessing PIM Data

Distributed Order Orchestration provides the ability to access item-related data that are not stored on
the order tables so that the data can be used in rules. Two functions are provided: one that populates
seeded schema objects in the rule dictionary that match PIM entities and one that allows the user to
request additional attributes that are not part of these entities. Both rule setups require two rules, one
to bring the item data into the rule session and one (or more) to use the item data to create conditions
to take actions based on the item data.

Seeded Schema Objects

DOO provides three sets of facts – schema objects – that represent PIM entities, each with its own set
of attributes related to those in the corresponding PIM entity. These are:
• Item Definition
• Item Category
• Related Item.
In accessing PIM data, two rules are created - one to look up the specified data and one to use the data
in a DOO rule. For the example below, an orchestration process assignment rule is used for the
second rule.
The first rule specifies which additional data objects will be populated during the rule session. The rule
that looks up the item data must run before the rule that uses the item data, so the highest priority
setting is used for this rule. While the Priority setting does not determine the absolute order of rule

29
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

firing at run time, it does provide guidance to the rule engine. The rule also requires a test to determine
the conditions for which to look up the additional attributes; in this case, the value of the Shippable
Flag.
1. Set advanced mode by checking the box. Set the Priority to ‘Highest’. Note that there are additional
parameters where you can set effective dates for the decision table or set the rule as inactive (by
unchecking the Active box).

Figure 22: Advanced parameter section of getItemData example

2. Define patterns (object declarations) and tests appropriately so that the patterns are linked together to
create the order hierarchy and include not-null checks. In this example we have used the following
pattern, where Fline represents the AssignLaunchRules.FulfillLineVO.
Patterns:
• Fline is a AssignLaunchRules.FulfillLineVO
Tests:
• FlineShippableFlag is “Y”

Figure 23: Condition section of getItemData example

The action section uses the seeded function that looks up the additional item values when the
condition is true. For this example, the attribute needed for the rule is part of the Item Definition
entity. The viewRowImpl value specifies the order record that is of concern to the rule.
3. Add actions to the Then… clause of the rule to create the desired outcome; in this case, use of the
seeded function to query data from PIM.

30
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

• call AssignLaunchRules.getItemData(FLine.InventoryItemId, InventoryOrganizationId, “Yes”,

“No”, “No”, FLine.FulfillLineId.toString(),FlineViewRowImpl). Note that detailed setup of these
parameters is shown in the figure after the completed action section below.

Figure 24: Action section of getItemData example

Details for setting the parameters for the getItemData function are in the figure below. The
inventoryItemId and the inventoryOrganizationId together specify the item. The attribute needed for
the rule is part of the Item Definition entity. Attributes from the other entities are not needed. Note
that all attributes of an entity will be fetched if the value is “Yes”. The customKey is defined based on
the value of the Fulfillment Line Id. The viewRowImpl value specifies the order record that is of
concern to the rule.

Figure 25: getItemData parameters

31
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

The completed rule to access additional PIM data for the items in the order is shown below.

Figure 26: Completed getItemData rule

Now you will create the rule that uses the additional item data returned by the first rule. The business
rule states that the Controlled Shipping Process must be used if hazardous materials are being shipped.
1. Set advanced mode by checking the box. Leave the Priority at the default of ‘Medium’. Note that
there are additional parameters where you can set effective dates for the decision table or set the rule
as inactive (by unchecking the Active box).

Figure 27: Advanced parameter section of use item data example

2. Define patterns (object declarations) and tests appropriately so that the patterns are linked together to
create the order hierarchy and include not-null checks. Note that you can also place the tests with
the corresponding object declarations as long as you do not use objects that have not yet been
declared. In this example we have used the following patterns, where Fline represents the
AssignLaunchRules.FulfillLineVO, ItemDef represents the AssignLaunchRules.ItemDefinition, and
Result represents AssignLaunchRules.ResponseRL. The Result object will be used in the Action
section of the rule. Remember to include the test that was use in the rule that returns the additional
item data because there will be no data for the item attributes when those conditions are not true.

32
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

The customKey attribute was specified as a function of the Fulfillment Line Id in the previous rule
and links the item data to the appropriate fulfillment line. Then populate a test that uses the item
data attribute, in this case, the hazardousMaterialFlag.
Patterns:
• Fline is a AssignLaunchRules.FulfillLineVO
• ItemDef is a AssignLaunchRules.ItemDefinition
• Result is a AssignLaunchRules.ResponseRL
Tests:
• FlineShippableFlag is “Y”
• ItemDef.customKey is FLine.FulfillLineId.toString()
• ItemDef.hazardousMaterialFlag is “Y”

Figure 28: Condition section of use item data example

Now you will add the definition of the action to be taken at run time if the conditions you have
specified are true. This is an example of an orchestration process assignment rule. The necessary
action is to modify the value of the attribute that holds the orchestration process name.
3. Add actions to the Then… clause of the rule to create the desired outcome; in this case, use of the item
data from PIM to determine the orchestration process assignment.
• modify Result(processName:”ControlledShippingProcess”)

33
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

Figure 29: Action section of use item data example

The completed rule to assign an orchestration process based on additional PIM data for the items in the
order is shown below.

Figure 30: Completed assignment rule using item data

Additional Schema Objects

DOO provides one sets of facts – schema object – that represents a general entity, with the ability to
populate the entity attributes with user-specified requests for PIM data.
You will create two rules - one to look up the specified data and one to use the data in an orchestration
process Line-Selection Criteria rule.
The first rule specifies which additional data elements will be populated during the rule session. The
rule that looks up the item data must run before the rule that uses the item data, so the highest priority
setting is used for this rule. While the Priority setting does not determine the absolute order of rule
firing at run time, it does provide guidance to the rule engine. The rule also requires a test to determine
the conditions for which to look up the additional attributes; in this case, the value of the Shippable
Flag.

34
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

1. Set advanced mode by checking the box. Set the Priority to ‘Highest’. Note that there are additional
parameters where you can set effective dates for the decision table or set the rule as inactive (by
unchecking the Active box).

Figure 31: Advanced parameter section of getFusionAppsData example

2. Define patterns (object declarations) and tests appropriately so that the patterns are linked together to
create the order hierarchy and include any necessary not-null checks. In this example we have used
the following pattern, where Fline represents the DooSeededOrchestrationRules.DOOFLine.
Patterns:
• Fline is a DooSeededOrchestrationRules.DOOFLine
Tests:
• FlineShippableFlag is “Y”

Figure 32: Condition section of getFusionAppsData example

The action section uses the seeded function that looks up the additional item values when the
condition is true. A custom function has been provided to access the item data. Arguments for the
custom function are used to specify the name of each requested attribute as well as the parameters to
be used to identify the item for which the attributes are requested. The Inventory Item Id and the
Inventory Organization Id together specify the item. The attribute needed for the example rule is part
of the ItemPVO. The attribute that is needed for the rule is CreationDate. No other attributes are
needed. so the rest of the output attribute names will be set to null. The Custom Key is defined based
on the value of the Fulfillment Line Id. The DOOFLine value specifies the order record that is of
concern to the rule.
3. Add actions to the Then… clause of the rule to create the desired outcome; in this case, use of the
seeded function to query data from PIM.

35
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

• call
DooSeededOrchestrationRules.getFusionAppsData(“InventoryItemId”,FLine.inventoryItemId.to
String(), “InventoryOrganizatonId”, FLine.inventoryOrganizationId.toString(),“ItemPVO” ,
“CreationDate”,null,null,null,null, FLine.fulfillLineId.toString(),Fline). Note that detailed setup of
these parameters is shown in the figure after the completed action section below.

Figure 33: Action section of getFusionAppsData example

Details for setting the parameters for the getItemData function are in the figure below. The
inventoryItemId and the inventoryOrganizationId together specify the item. The attribute needed for
the rule is part of the Item Definition entity. Attributes from the other entities are not needed. Note
that all attributes of an entity will be fetched if the value is “Yes”. The customKey is defined based on
the value of the Fulfillment Line Id. The viewRowImpl value specifies the order record that is of
concern to the rule.

Figure 34: getFusionAppsData parameters

36
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

The completed rule to access additional PIM data for the items in the order is shown below.

Figure 35: Completed getFusionAppsData rule

Now you will create the rule that uses the additional Item data returned by the first rule. The business
rule states that the Fulfillment Line should be selected for the New Product Activity step if the Item
was created in the last 30 days.
1. Set advanced mode by checking the box. Note that there are additional parameters where you can set
effective dates for the decision table or set the rule as inactive (by unchecking the Active box).

Figure 36: Advanced parameter section of line selection rule using Fusion Apps
item data

37
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

You will now add the patterns and tests that are necessary to the definition of the business rule. The
first test specifies that the FLine object is a child of the Header object. You will also create the test
that was used in the first rule because there will be no data for the additional item attributes when the
condition is not true. You must also specify that the Item Definition and the Fulfillment Line both
refer to the same (item) object by using the Custom Key that was specified as a function of the
Fulfillment Line Id. Now you will populate a test that uses the item data attribute, in this case, the
Creation Date. You will be using a custom function that compares dates. Note that this custom
function will default the second argument to the current date if a second value is not supplied. This
expression subtracts the current date from the Creation Date, which results in a negative number
because the Creation Date is always in the past. The business rule requires that the item be created
within the last 30 days.
2. Define patterns (object declarations) and tests appropriately so that the patterns are linked together to
create the order hierarchy and include any necessary not-null checks. In this example we have used
the following patterns, where Header represents the DooSeededOrchestrationRules.DOOHeader,
Fline represents the DooSeededOrchestrationRules.DOOFLine, and ItemResult represents the
DooSeededOrchestrationRules.Fusion EntityResult.
Patterns:
• Header is a DooSeededOrchestrationRules.DOOHeader
• Fline is a DooSeededOrchestrationRules.DOOFLine
• ItemResult is a DooSeededOrchestrationRules.Fusion EntityResult
Tests:
• Header.childFlines contains Fline
• FlineShippableFlag is “Y”
• ItemResult,customKey is Fline.fulfillLine.toString()
• Header.SubtractFromDate(ItemResult.outputAttributeTimestampValue1) more than -30

38
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

Figure 37: Condition section of line selection rule using Fusion Apps item data

Now you will add the definition of the action to be taken at run time if the conditions you have
specified are true. The assert new action creates a new object of the specified type so it was not
necessary to create a pattern for the result. Select the Fulfillment Line Id as the result if the conditions
are true. This fulfillment line will be selected for action by the New Product Activity step at run time.
3. Add actions to the Then… clause of the rule to create the desired outcome; in this case, use of the item
created date to determine if the line should be sent to the downstream system for processing.
• assert new DooSeededOrchestrationRules.Result(resultObjKey:fulfillLineId)

Figure 38: Condition section of line selection rule using Fusion Apps item data

39
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

Figure 39: Completed line selection rule using Fusion Apps item data

Error and Conflict Management

OBR provides design time error management in all UIs. When rules are saved, the syntax is validated
and errors are displayed in the error pane at the bottom of the page or popup. Note that this pane can
be minimized, so if it is not visible, click the arrow icon on the bottom right or the page or popup to
see the errors. If you double click on an error message, the rule containing the error will open and the
object affected by the error will be highlighted. The following figure demonstrates the results of
double-clicking on an error message.

40
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

Figure 40: Error management

OBR provides design time conflict management for decision tables. The section that displays conflicts
is placed between the condition and action sections and can be hidden if desired. The icon on the tool
bar that contains an exclamation point (!) can be used to toggle visibility of the conflict section. For
each rule involved in a conflict, the other rules in the conflict are identified. The figure below presents
a situation where a new rule has been added that is in conflict with three other rules. Note that the
conflicts are identified for each rule.
There is also an icon on the decision table toolbar that will identify if there are gaps in rule coverage:
i.e., if elements from the bucket sets have not been used in rules. If a gap is identified, OBR will
suggest the minimum number of rules to close the gap. Any of these rules that the user selects will be
automatically added. None of the suggested rules need be selected if the user wishes to construct rules
differently to close the identified gap. This functionality is particularly useful when bucket sets with a
large number of values are used. Note that bucket sets automatically include a choice of ‘otherwise’
that can be used when it is not necessary to specify each selection individually.

41
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

Figure 41: Conflict identification and resolution

Migration, Upgrades, Patches

OBR rules can be migrated from one environment to another as long as the environments are at the
same release level. The mechanism of migration differs depending on the user interface used to
construct the rules. A white paper is available that gives more detail on migration, Oracle Fusion
Distributed Order Orchestration – Importing and Exporting Data. (See DOO: Oracle Fusion
Distributed Order Orchestration White Papers [Article ID 1536633.1])
• Nonembedded rules are stored in the Metadata Services (MDS) Repository. They are migrated from
one application instance into another using WebLogic Scripting Tool (WLST) commands.
• Embedded rules are migrated along with the orchestration process definition in which they are
constructed. The Fusion Functional Setup Manager provides the ability to export the process
definition from one environment and to import it into another. For additional information, see
documentation on the Fusion Functional Setup Manager (for example, Frequently Asked Question on
Functional Setup Manager (FSM) (Doc ID 1308404.1)).
In most cases customer-defined rules should not be affected by upgrades or patches. Two exceptions
must be noted:
• If seeded rules or seeded decision tables have been modified, the modifications may be lost during
application of an upgrade or patch.
• If the underlying behavior of OBR is changed as a result of an upgrade or patch, behavior of customer-
defined rules may change.
It is always a good practice to plan regression testing when rules have been migrated or an upgrade or
patch has been applied that may affect the rules.

42
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

Release 6 Enhancements

An additional attribute, the Start After Condition, was added to the orchestration process definition in
release 6. This attribute is only available for the Pause task type. It allows the user to create rules that
specify the conditions for pausing processing before the next step is invoked as well as the conditions
to resume processing. Setup details are provided in the section OBR Use for Orchestration Process
Run Time.

Release 7 Enhancements

OBR added several features to all of the setup UIs in release 7. Users now have the ability to cut, copy,
and paste rules or sections of rules, including across dictionaries. In the figure below, the Reservation
Task Routing rule has been copied and the copy was pasted below the original rule. Note that you
have to change the name of the copied rule before saving or an error will occur. To select a rule or
section of a rule to be copied or cut, click the checkbox. To control the placement of a copied rule or
rule section when it is pasted, click the checkbox above where the pasted elements should be placed,

Figure 42: Cut, copy, paste actions

In addition, OBR has provided attribute filtering to the selection of objects and attributes in the
Condition Browser. In the figure presented below, the visible attributes all contain the string ‘date’,
which has been typed into the editable section of the condition browser.

43
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

Figure 43: Filtering attributes by contained string

Release 8 Enhancements

The ability to retrieve additional attribute data from PIM for use in rule conditions was added in
Release 8. This feature is available for all DOO rule applications and can be used with both the if…
then… and decision table formats. DOO now provides three product entities in the rule dictionary
plus a custom function to access the data. These entities are not populated at run time unless a rule is
created specifying the conditions under which to retrieve the data. Setup details are provided in the
section Accessing PIM Data.
An additional ability to retrieve attributes from PIM that are not part of the three product entities was
also provided in Release 8. This feature is available for all DOO rule applications and can be used with
both the if… then… and decision table formats. DOO now provides a general entity in the rule
dictionary plus a custom function to access the data. This entity is not populated at run time unless a
rule is created specifying the conditions under which to retrieve the data. Setup details are provided in
the section Accessing PIM Data.
Starting with Release 8, the rule-building window area in the embedded interface (orchestration rules)
has been expanded and an additional button, ‘Validate’ has been added. Both ‘Save’ and ‘Validate’ will
save the rule definition and run syntax validation. However, ‘Validate’ leaves the window open for
further rule development.

44
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

OBR Use for Transformation

Some companies have multiple order capture applications. The information that is captured on the
sales orders might be different in each application. Not only are sales orders from different
applications different from each other, sales orders are also different from DOO orders, known as
orchestration orders. An orchestration order is the business object that is created when a sales order
enters DOO. Orchestration orders capture fulfillment information such as warehouse and schedules,
while sales orders are sales-focused, in that they capture information that is important to sales
representatives and customers, such as color, quantity, and pricing.
To ensure that data are processed correctly, you can create custom product transformation rules to
determine how products are transformed when a sales order is converted, or transformed, to an
orchestration order. Product transformation rules automatically convert sales order data to the way
they should appear in DOO for fulfillment.
All transformation rules are optional and are based on a company’s need to have different sales and
fulfillment order pictures. DOO provides the following setup functionality for transformation:
• PreTransformation Defaulting Rules: These automatically populate specific attributes onto an
orchestration order before product transformation, as set up by the administrator. You can then use
the defaulted attribute value(s) in the product transformation rules. Note that the master inventory
organization and a number of other attributes are defaulted automatically to the orchestration order, so
that they are available for product transformation rules. EFF values cannot be defaulted by rules at
this time.
Example: You want to write a product transformation rule that converts the widget weight from your
company’s sales orders from kilograms to pounds, but first you must populate the fulfillment line with
the weight attribute. You write a pretransformation defaulting rule that says that if the product is a
widget then populate the fulfillment line with the weight attribute.
• Product Transformation Rules: These convert components of the product for use on the
orchestration order. Some product transformations can be set up as part of the product definition,
such as included items in structures. More complete transformations, such as customer-specific or
region-specific changes, might have to be done using OBR. EFF values cannot be modified by rules at
this time.
Example: You want to make sure the power cord is appropriate for the customer’s location. You
write a product transformation rule that adds a line containing the appropriate power cord to the order
based on the shipping location.
• PostTransformation Defaulting Rules: These automatically populate specific attributes onto an
orchestration order based on the product transformation that is applied to the orchestration order.
Example: Your company receives orders that display the requested date as month, day, and year. You
want to add the day of the week, so you write a posttransformation defaulting rule that populates this
attribute onto the new orchestration order. Note that EFF values cannot be defaulted by rules at this
time.

45
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

DOO provides these three sets of rules so that the processing can occur sequentially. You can set up
data defaults that will be required in transformation in the pretransformation defaulting rules, then add
additional data defaults once transformation is complete using the posttransformation defaulting rules.
This is required because the rules in a single call to the OBR engine cannot be said to operate
sequentially because of the inference capability.
Pretransformation, transformation, and posttransformation rules are carried out on the order as a
whole. Therefore order lines can be compared to one another and groupings of lines used to
determine a single outcome. Because transformation rules are not versioned, changes that are released
take effect immediately. However, you can save rules without releasing them.
The screenshots below show an example of how the above guidelines are used in product
transformation rules including using EFFs, where header, line, and fline are used as aliases for the
orchestration order header, line, and fulfillment line objects, respectively, and flineEFFctgry and
flineEFFcntx are the EFF category and context, respectively, for the ProductInfo EFF. Note the ‘_’
that is placed before the name of the EFF segment. This example uses a decision table to manage a set
of rules together. The purpose of this example set of rules is to replace a general item with a specific
item for product types of server, laptop, and handheld based on the product type and a flag set in an
EFF segment.
1. Set advanced mode and tree mode by checking the boxes. Note that there are additional parameters
where you can set effective dates for the decision table or set the rule as inactive (by unchecking the
Active box).

Figure 44: Advanced parameter section of advanced transformation example

2. Define patterns (object declarations) and tests appropriately so that the patterns are linked together to
create the order hierarchy and include not-null checks. In this example we use tree mode which
creates the hierarchy of the order/line/fline variables (patterns). The EFF variables must have
explicit hierarchy tests. The EFF used in this set of rules is ProductInfo, which contains the segment
_CoverageProduct used as a condition in the decision table.
Patterns:
• Root: DooSeededOrchestrationRules.DOOHeader
• header is a OrderTransformationRules.HeaderVO
• line is a header/OrderLine

46
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

• fline is a header/OrderLine/OrderFulfillLine
• flineEFFCtgry is a OrderTransformationRules.j_FulfillLineEffDooFulfillLinesAddInfoprivateVO
• flineEFFCnts is a OrderTransformationRules.FulfillLineEffBProductInfoprivate
Tests: (note that tests can be interspersed with patterns as long as the test variables have been declared)
• flineEFFCtgry is not null
• flineEFFCntx is not null
• fline.FulfillLineEffCategories is flineEFFCtgry
• flineEFFCtgry.FulfillLineEffBProductInfoprivateVO is not null
• flineEFFCtgry.FulfillLineEffBProductInfoprivateVO contains flineEFFCntx

Figure 45: Declaration section of advanced transformation example

3. Create conditions, actions, and rules in the decision table to use the declared variables (patterns) for
specific transformations.

47
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

• Conditions check the EFF segment _CoverageProduct and the attribute fline.ItemTypeCode.
• Actions modify the attribute fline.InventoryItemId (transform one product to another) and modify
the attribute fline.ReservableFlag. A custom function, ModifyEntity, is used to modify both
attribute values rather than the standard ‘modify’ action supplied by OBR. EFF values cannot be
modified by rules at this time. The ModifyEntity function has three arguments AttrName(String),
AttrValues(Object), and viewRowImpl(oracle.jbo.server.ViewRowImpl) which must be populated
for each rule where the action is used. If all of the rules use the same value, it can be set as part of
the condition. Otherwise the ‘Parameterized’ flag is set for the condition so that a specific value
can be set for each rule. Note that in the product transformation rules in the decision table shown
below some active actions return the existing product value instead of a substitution and for some
rules not all actions are active. An action is set to be active for a rule by checking the box above
the value.

Figure 46: Decision table section of advanced transformation example

48
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

Here is the completed advanced decision table. Note that the section of the rule where advanced
mode and tree mode are specified is closed.

Figure 47: Completed advanced transformation decision table

OBR Use for Orchestration Process Assignment

A process assignment rule is used to assign an orchestration process to one or more fulfillment lines of
an orchestration order. Process assignment rules are executed in the OBR engine. Process assignment
rules are built based on orchestration groups, lines that will be processed together, and using
orchestration order attributes. Groups are subsets of an order and are defined as ship sets, models, or
individual standard lines.
Because assignment rules are not versioned, changes that are released take effect immediately. You can
save rules without releasing them. You do not need to specify versions or effectivity dates for the
orchestration process in the process assignment rules because versions and effectivity dates are
controlled and checked at the orchestration process level when the process is launched.
Setup of process assignment rules is slightly different from that of the other rules because at run time
the assignment processes a group. Therefore we need to add an extra test to link the fulfillment line
object with the group object. This test is provided in the seeded process assignment rules.
1. Define patterns using advanced mode for the relevant VO entries. The screenshots below provide an
example of how the above guidelines are used in process assignment rules that include the use of
EFFs, where group and fline are used as aliases for the group (represented by the Response RL) and

49
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

fulfillment line objects, respectively, and FlineEFFdaip and FLineEFFpsi are the aliases for the EFF
category and context, respectively, for the Shipping Instruction EFF. Note the ‘_’ that is placed
before the name of the EFF. The business rule statement is: If the shipping instruction is populated,
use the Special Ship Order Process.
Patterns
• group is a AssighLaunchRules.ResponseRL
• fline is a AssignLaunchRules.FulfillLineVO
• FlineEFFdfaip is a AssignLaunchRules.j_FulfillLineEffDooFulfilllinesAddInfoprivateVO
• FlineEFFpsi is a AssignLaunchRules.FulfillLineEffBPackShipInstructionprivateVO

Figure 48: Process assignment object declarations

2. Define appropriate tests to link the hierarchy variables, ensure not null conditions for optional objects,
and provide business logic.
Tests
• FlineEFFdfaip isn’t null
• Fline EFFpsi isn’t null
• group.flines contains fline
• FlineEFFdfaip is fline.FulfillLineEffCategories
• FlineEFFdfaip.FulfillLineEffBPackShipInstructionprivateVO isn’t null
• FlineEFFdfaip.FulfillLineEffBPackShipInstructionprivateVO contains FlineEFFpsi
• FlineEFFpsi._ShippingInstruction isn’t null
• FlineEFFpsi._ShippingInstruction.equalsIgnoreCase(“”)

50
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

Figure 49: Process assignment tests

The outcome of process assignment rules is always the same – you modify the group (used as an alias
here) to specify the relevant process name, as shown here:
THEN modify group (processName:"SpecialShipOrderProcess")
Note that the standard OBR ‘modify’ action is specified here.

Figure 50: Completed advanced process assignment rule

OBR Use for Orchestration Process Run Time

There are six attributes in the orchestration process definition that utilize OBR to make run time
decisions for process behavior as of Release 6. Two attributes are used for change management (both

51
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

optional), one for planning (optional), one to filter lines for a step (optional), one to determine which
branch of a conditional node is executed (required for branches), and one to pause the orchestration
process (required for the Pause task type which becomes available in Release 6). All rules return the
result by asserting a new result object whose argument type is determined by the attribute on which the
rule is based.
• Cost of Change: Refers to the difficulty or cost in making a change to an order and is a ranking, not a
monetary amount. For example, if the item has only been sourced, the relative cost may be low while
if manufacturing has begun, the cost to the organization might be higher. At run time, the order
capture application can request that DOO calculate the cost of change and the order capture
application can then use the result to determine if a change order should be submitted. If the rule is
not populated, then the value defaults to 0. The outcome of the rule populates the result with a
numeric value.
• Compensation Pattern: Allows the administrator to set an override to processing of a step during
change management. For example, if a high value customer makes a change, the organization may
want to preserve the existing supply reservation in a scarce supply situation while for a lower value
customer, the supply can be released and resourced. The default behavior when compensating a step is
to update. If compensation is not warranted for a step, the compensation pattern is not used even if it
is set. The outcome of the rule populates the result with one of the following patterns: UPDATE,
CANCEL, NOOP, CANCEL_CREATE (Redo), UPDATE_CREATE and
CANCEL_UPDATE_CREATE.
• Lead-Time Expression: Defines the expected duration for a given unit of work (orchestration
process step) to be completed for planning calculations. For example, items that require extensive
packing may have a longer lead time for shipping than those that do not. If a lead-time expression is
not defined for a step, then the value of the default lead time attribute is used. If this field is left blank,
then it defaults to zero. The outcome of the rule populates the result with a numeric value
representing the lead time. The lead time UOM attribute is used to specify the time element as days,
hours, or minutes. Note that the ‘BigDecimal’ specification is required for this rule action; e.g.,
BigDecimal.valueOf((DooSeededOrchestrationRules.DOOHeader/childFLines.scheduleShipDate.tim
e - CurrentDate.date.timeInMillis)/(1000*60*60*24)), which determines the difference between the
current date and the scheduled ship date.
• Line Selection Criteria: Provides an expression used for filtering criteria when all of the
orchestration order lines or fulfillment lines are not needed for the fulfillment task service invocation
specified for the step. For example, only shippable lines are set to a shipping system. The outcome of
the rule populates the result with the id of the fulfillment line(s) that should be selected. The rule is
executed for each fulfillment line in the process. Note that if no line is selected, the step is skipped.
• Branching Condition: Provides criteria that must be met for steps in a branch to be executed. A
branch contains one or more steps with the branching condition placed on the first step of the branch,
that is, the first step that follows the conditional step. For example, high value orders may include a
branch with extra steps for customer communication or documentation. Branching conditions are
required on steps that follow a conditional step, unless the otherwise check box is selected. The

52
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

outcome of the rule populates the result with Boolean.TRUE for the branch to be executed. Note that
the evaluation stops when the first true result is found.
• Start-After Condition: (introduced in Release 6) Provides criteria that must be met both for the Pause
task to wait and to be released. A Pause task temporarily stops an orchestration process to wait until a
particular date or for a particular event. For example, a Pause task can be used to wait until all
payments are made before releasing an item from layaway or to wait for a specific date to arrive before
releasing pre-orders. There are two types of pause: one that waits for a release message (event type)
and one that waits for a specific date timestamp (timer type). The outcome of the rule populates the
result with the type and an event name (event type) or release date (timer type). The event name is
used in the Release Pause Tasks scheduled service to send a message to release the pause.

Creating a Branching Condition Rule

The screenshot below shows an example of a simple rule used to specify a branching condition. The
purpose of the rule is to execute a branch containing a reservation step if the ordered quantity is
greater than or equal to 1000. Note that orchestration order line attributes are not used in
orchestration rules. The data set for an orchestration process is one standard fulfillment line, ship set,
or model, and associated header and detail attributes. Advanced mode and tree mode are not used in
this simple rule, so patterns (object declarations) and the root definition are not required.
1. Test
• If DooSeededOrchestrationRules.DOOFLine.orderedQty same or more than 1000
2. Action
• Then assert new
DOOSeededOrchestrationRules.Result(resultObj:DooSeededOrchestrationRulesBoolean.TRUE;
resultObjKey:”1”)

53
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

Figure 51: Simple orchestration branching rule

Creating a Line Selection Criteria Rule using EFFs

EFFs can also be used in orchestration rules. However, the syntax is slightly different. DOO has
provided a custom function to look up the EFF value. The screenshots below show an example using
EFFs in a line selection criteria rule. Both advanced mode and tree mode are utilized for this rule.
Note that tree mode does enable the EFF to be in the root hierarchy for orchestration rules. The
purpose of the rule is to allow selection for reservation processing of products that do not have the
_CoverageProduct attribute checked.
In the line selection criteria example below, header, fline, and flineEFF are the aliases used for the
order header, fulfillment line, and EFF, respectively. The business rule statement is: If the value of the
coverage product attribute has been set (not null), then process this fulfillment line in this step. The
rule is placed on the reservation step.
1. Set advanced mode and tree mode by checking the boxes. Note that there are additional parameters
where you can set effective dates for the rule or set the rule as inactive (by unchecking the Active
box).

54
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

Figure 52: Advanced line selection rule mode selection

Define patterns (object declarations) for objects that will be used in the rules. In this example we use
tree mode which creates the hierarchy of the order/fline variables (patterns). Note that line attributes
are not used in orchestration rules. The EFF variables are included in the hierarchy for orchestration
rules, so no additional tests are required to define the hierarchy. The EFF used in this set of rules is
ProductInfo, which contains the segment _CoverageProduct used as a condition in the rule. Note that
the best practice is to use advanced mode whenever tree mode is selected. Patterns:
• header is a DOOSeededOrchestrationRules.DOOHeader
• fline is a header/childFlines
• flineEFF is a header/childFLines/flexContexts

55
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

Figure 53: Advanced line selection rule object declarations

2. Create the expression that looks up the EFF value to be used in tests
• flineEFF.context.equalsIgnoreCase(“ProductInfo”)

56
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

Figure 54: Advanced line selection use of custom function

3. Create tests (IF) to use the declared variables (patterns) and supplied functions for specific business
conditions and include not-null checks. Note that the segment name must be preceded by “_”. The
second test serves two purposes – checking for null and also that the item is not a coverage product.
Tests
• flineEFF.context.equalsIgnoreCase(“ProductInfo”) is DooSeededOrchestration
Rules.Boolean.TRUE
• flineEFF.getFlexAttributeValue(“_CoverageProduct”) isn’t null

57
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

Figure 55: Advanced line selection tests

4. Create the action (THEN) that produces the result to use the fulfillment line that satisfies the
conditions. Set the resultObjKey to the run time value of the fulfillLineId by selecting the attribute
in the condition browser.
Action
• Assert new DooSeededOrchestrationRules.Result(resultObjKey:fulfillLineId)

58
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

Figure 56: Advanced line selection result

Creating a Start After Condition Event Rule

For this example, a Pause task is placed before the billing step in the process definition. This is an
event type rule that specifies that the process should pause until released by a scheduled process using
the event name "SOURCE_EVENT" for any orders that are submitted from the legacy system
("LEG"). The rule is placed on a pause step, which is prior to the invoice step. Other orders should
be sent to billing with no pause.
For start after condition rules, it is necessary to state explicitly what circumstances should result in a
pause and what circumstances should move processing to the next step. The pause type is used at run
time to determine the action. A pause type of event or timer will cause processing to pause. A pause
type of immediate will end the pause task and allow orchestration to move to the next step. For this
example, two simple rules will be used: one that specifies when and how to pause and the other with
the opposite condition to specify when not to pause.

Rule one – action to set event pause

1. Create tests (IF) to specify the specific business conditions.

59
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

Tests
• DooSeededOrchestrationRules.DOOHeader.sourceOrderSystem is “LEG”
2. Create the action (THEN) that produces the result to pause the task until a message with the specified
event name is received.
Action
• Assert new DooSeededOrchestrationRules.SACResult ( eventName:"SOURCE_EVENT",
reevaluateFlag:"N", sacType:DooSeededOrchestrationRules.SacResult.SAC_TYPE_EVENT )

Figure 57: Start after condition event rule 1

Rule two – action to move to the next step without a pause

3. Create tests (IF) to specify the specific business conditions.

Tests
• DooSeededOrchestrationRules.DOOHeader.sourceOrderSystem isn’t “LEG”
4. Create the action (THEN) that produces the result to not pause the task
Action

60
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

• Assert new
DooSeededOrchestrationRules.SACResult(sacType:DooSeededOrchestrationRules.SacResult.SAC
_TYPE_IMMEDIATE )

Figure 58: Start after condition event rule 2

Creating a Start After Condition Timer Rule

In the start after condition example below, header is the alias used for the order header. The business
rule statement is: If the order was submitted by the legacy order capture system, then pause the process
until two days before the scheduled ship date. The rule is placed on a pause step, which is located
before the shipping step.
For start after condition rules, it is necessary to state explicitly what circumstances should result in a
pause and what circumstances should move processing to the next step. The pause type is used at run
time to determine the action. A pause type of event or timer will cause processing to pause. A pause
type of immediate will end the pause task and allow orchestration to move to the next step. For this
example, advanced mode will be used. This provides the actions of if… then… else which can be used
to specify when to pause and when not to pause so that only one rule is required.

1. Set advanced mode by checking the box. Note that there are additional parameters where you can set
effective dates for the rule or set the rule as inactive (by unchecking the Active box).

61
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

2. Define patterns (object declarations) for objects that will be used in the rules. Note that line attributes
are not used in orchestration rules.
Patterns:
• fline is a DOOSeededOrchestrationRules.DOOFLine
3. Create tests (IF) to use the declared variables (patterns) and supplied functions for specific business
conditions and include not-null checks. Note that in this case, no tests are included in the condition
(if) section because they need to be bounded by the if… then… else construct in the action (then)
section. The test provided with the header pattern should be removed.

Figure 59: Start after condition timer pattern

4. Create the action (THEN) that adds the if… then… else construct
Actions
• if
5. Within the new ‘if’ section, create tests to specify the specific business conditions.
Tests
• fline.sourceOrderSystem = “LEG”

62
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

Figure 60: Start after condition timer condition

6. Within the new ‘then’ section, create the actions that produce the result to pause the task until the
specified event date timestamp occurs.
Actions
• Assign new Timestamp DateTime = fline.scheduleShipDate
• Modify DateTime( time:-(2*24*60*60*1000) )
• Assert new DooSeededOrchestrationRules.SACResult( reevaluateFlag:"N",
sacType:DooSeededOrchestrationRules.SacResult.SAC_TYPE_TIMER, waitDateTime:DateTime
)

63
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

Figure 61: Start after condition timer result

7. Within the ‘else’ section, create the action that produces the result to move to the next step without
pausing.
Action
• Assert new
DooSeededOrchestrationRules.SACResult(sacType:DooSeededOrchestrationRules.SacResult.SAC
_TYPE_IMMEDIATE )

64
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

Figure 62: Start after condition timer else result

OBR Use for External Interface Routing

Create rules to route fulfillment requests to connectors defined for fulfillment systems that are not a
part of Oracle Fusion. You can use order, fulfillment line, and process definition attributes to select
the fulfillment system connectors. Note that orchestration order lines are not used in EIL. The name
used to register the system (Manage External Interface Web Service Details task in FSM) is the one to
use in the selection rule. The rules are executed in the OBR engine. Create and update these rules on
the Manage External Interface Routing Rules page. Because routing rules are not versioned, changes
that are released take effect immediately. However, you can save rules without releasing them.
Here are two examples of the type of business condition that might be used in a routing rule:
Example 1 - Task Type Determines Routing of Request: You want orchestration orders that are ready
to be shipped to go to the shipping fulfillment system. You write an external interface routing rule that
requires that if the task type code of an orchestration order is Shipment, then route the request to the
ABCShippingSystem connector.
Example 2 - Customer Attribute Determines Routing of Request: Your company has two invoicing
systems. When it is time to send out an invoice, you want Widget Company always to be invoiced by
system ABC. You write an external interface routing rule that specifies that if the customer is Widget
Company and the task type code is Invoice, then route the request to the ABCInvoicingSystem
connector.

65
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

An example of an advanced EIL routing rule is presented below. The business rule statement is: If the
task is shipping and the order was received from the legacy order capture system, fulfill lines from the
legacy shipping system.
1. Set advanced mode and tree mode by checking the boxes. Note that there are additional parameters
where you can set effective dates for the rule or set the rule as inactive (by unchecking the Active
box).

Figure 63: Advanced settings for routing rule

2. Define patterns (object declarations) for objects that will be used in the rules. In this example we use
tree mode which creates the hierarchy of the order and fulfillment line variables (patterns). The
aliases are header and fline, respectively.
Patterns:
• Root: DOOExternalInterfaceLayer.HeaderTLVO
• header is a DOOExternalInterfaceLayer.HeaderTLVO
• fline is a header/FulfillLineTLVO1

Figure 64: Object declaration section of advanced routing rule

3. Create tests to use the declared variables (patterns) and supplied functions for specific business
conditions.
Tests
• header.TaskTypeCode is “Shipment”
• fline.SourceOrderSystem is “LEG”

66
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

Figure 65: Test section of advanced routing rule

4. Create the action that produces the result to send the fulfillment line that satisfies the conditions to the
appropriate fulfillment system. Use the short name that was specified in registering the system with
EIL for the resultObj value.
Action
• assert new
DOOExternalInterfaceRules.ResultRL(resultObj:”LegacyShip”;resultObjKey:”SERVICE_NAME
”)

Figure 66: Action section of advanced routing rule

Here is the completed EIL routing rule. The rule must be released before it is available for use.

Figure 67: Completed advanced routing rule

67
 Use of Oracle Business Rules (OBR) to Tailor Order Fulfillment for DOO

68
White Paper Title Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
April 2013
Author: Leah Reed This document is provided for information purposes only, and the contents hereof are subject to change without notice. This
Contributing Authors: Anup Pani document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in
law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any
Oracle Corporation
liability with respect to this document, and no contractual obligations are formed either directly or indirectly by this document. This
World Headquarters
document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our
500 Oracle Parkway
prior written permission.
Redwood Shores, CA 94065
U.S.A.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Worldwide Inquiries:
Phone: +1.650.506.7000 Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and
Fax: +1.650.506.7200 are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are
trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group. 0113
oracle.com