use of oracle business rules (obr) to tailor order ... · oracle business rules (obr) is a...

An Oracle White Paper September 2014 (updated)

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


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


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


1

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.


2

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


3

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.


4

• 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


5

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.


6

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


7

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


8

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.


9

• Orchestration

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


10

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.


11

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.


12

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.


13

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)


14

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”


15

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


16

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


17

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.


18

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


19

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])


20

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


21

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”


22

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.


23

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


24

• 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).


25

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


26

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.


27

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


28

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)


29

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


30

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.


31

• 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


32

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.


33

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:


• 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”)


34

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.


35

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:


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.


36

• call DooSeededOrchestrationRules.getFusionAppsData(“InventoryItemId”,FLine.inventoryItemId.toString(), “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


37

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


38

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


• ItemResult,customKey is Fline.fulfillLine.toString()

• Header.SubtractFromDate(ItemResult.outputAttributeTimestampValue1) more than -30


39

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


40

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.


41

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.


42

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.


43

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.


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.


44

Figure 43: Filtering attributes by contained string


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.


45

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.


46

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


47

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


48

• 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


49

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


50

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(“”)


51

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


52

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


53

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”)


54

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


55

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


56

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”)


57

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


58

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)


59

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.


60

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


61

• 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).


62

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”


63

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 )


64

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 )


65

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.


66

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”


67

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


68

White Paper Title April 2013 Author: Leah Reed Contributing Authors: Anup Pani

Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A.

Worldwide Inquiries: Phone: +1.650.506.7000 Fax: +1.650.506.7200

oracle.com

Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

This document is provided for information purposes only, and the contents hereof are subject to change without notice. This 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 liability with respect to this document, and no contractual obligations are formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior written permission.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and 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

use of oracle business rules (obr) to tailor order ... · oracle business rules (obr) is a...

Documents