Controlling ODM Rules Execution Order: Utilizing the ruletask properties in IBM ODM
Ruleflows in IBM Operational Decision Management (ODM) control the rule execution order. There are two levels of granularity within the ruleflows to control the execution: The Ruleflow level and Ruletask level. Ideally business requirements would drive the ruleflow design in ODM. There are best practices around constructing ODM ruleflows and their properties. This article describes the best practices around constructing ODM ruleflows, configuration of ruleflow/ruletask through ruletask properties. I will also present a situation that frequently appears in “Legacy Modernization” projects, when dealing with nested “Evaluate-When” (If-Else) in COBOL.
Ruleflows are a way of controlling rule execution. They are made of linked tasks that contain instructions which rules to execute and in what order.
The links between the tasks are called transitions. A ruleflow specifies how tasks are chained together: how, when, and under what conditions they are executed. When a project contains several ruleflows, one of them is identified as the main ruleflow and can reference other ruleflows through subflow tasks.
Ruleset parameters are used to transfer information from one ruleflow task to another, as well as to transfer information between the ruleflow and your application.
There are industry best practices for ruleflow design and implementation:
- Ruleflows should be designed to represent not only the current flow, but also be generic enough to accommodate rule changes (new rules, updates) expected in the near future. The idea is that the ruleflows should NOT change as frequently as the Rules and Decision Tables do.
- The package (not individual rules) should be referenced wherever possible. The reason for this is that in the Decision Center (DC) the business users (rule authors) can add rules without having to have the rule developer change the ruleflow for them. The ruleflow artifact is not editable in DC.
- The flow should be high level and generic enough not to be changed unless there is a major change that would require IT involvement.
- No looping should be done in the ruleflow. Looping can be done in the rules.
Ruleflow controls the flow of the ruletasks. A ruletask can contain individual rule(s) and/or rule package(s). The question is how do you control the rules and rule packages execution within a ruletask. Answer – it is done though ruletask properties. I am going to concentrate on three of them: Algorithm, Exit Criteria and Ordering.
Algorithm: There are three algorithms available – Reteplus, Sequential and Fastpath. In this article I am not going to concentrate on the differences between and details of each of the three. I will just mention that Reteplus is a specific one; it is not applicable in many situations and can be the only solution in others. This article is about utilizing the ruletask properties in conjunction and Reteplus is not applicable for that. Fastpath and Sequential are very similar and for a case study I am going to use Fastpath.
Exit Criteria: This is used to control the rule exaction in the ruletask and determines when should the rule condition evaluation stop and exit the ruletask. Here are the values to choose from:
- None: The default setting that all rules are executed until conditions terminate the execution. The rules are executed in a particular order determined by the selected ordering.
- Rule: Execution terminates after the chosen rule is executed, according to the selected algorithm.
- RuleInstance: A single instance of one rule is executed. This rule is determined by the selected ordering.
Ordering: Controls the rule execution order. Note that this is not available for Reteplus. Here are the values to choose from:
- Default: The algorithm determines the execution order.
- Literal: The order of the rules in the rule task determines the order of rule execution.
- Priority: The rules are executed following a static priority in decreasing order.
In “Legacy Modernization” projects the rule requirements often do not come from Business SMEs and other traditional sources, but are directly harvested from COBOL code (often very old). Often the utilization of ruletask properties is not only convenient, but may be the only option for the quick implementation of the rules. Let us consider a situation of nested Evaluation Statements interrogating different data attributes. Let us discuss the following example:
Technically an Evaluate statement is equivalent to IF-ELSE. Nesting makes it quite complicated if we have to approach it the “standard” way, i.e. break it down to atomic rules and design the ruleflow to satisfy the COBOL version. The atomic rules are:
- If Attribute1=A then Call proc1
- If Attribute1=B and Attribute2=C then Call proc2
- If Attribute1=B and Attribute2=D then Call proc3
- If Attribute1=H then Call proc6
What makes it complicated is that the order of execution in the above rules becomes crucial. This is where the rule task properties come handy.
- Implement all of the rules above in a single rule package (ruletask)
- Put them in the order they execute in the COBOL code
- Change the ruletask property of Ordering to “Priority” (Recommended)
- In this case the rules are executed following a static priority in a decreasing order. Choosing this option, we have to go and assign a priority to the rules (rule property) based on the rule execution order. This will make the rules execute in priority order (High to Low).
Alternative to steps 3 and 4 would be to set the Ordering to “Literal”. In this case the rules within the ruletask will be executed in literal order. Choosing this option, we have to go and order the rules in the order we would expect them to run. Note that the first approach does not really require literally ordering of the rules.
- Change the Exit Criteria to “Rule”.
This will make the rule execution stop and exit the ruletask once it satisfies a single condition(s) (trying them in the literal or priority order).
- Change the Algorithm of ruletask property to “Fastpath”
Whether it is a mainframe (COBOL) modernization or any other ODM project, Zilker Technologies provides the best in the market resources to help you deliver quality solution and make you achieve your goal.
About the Author
is an IBM Operational Decision Management (ODM) Architect with over 7 years of experience working with the product. Artur’s background is mathematics (probability/statistics) and he has as strong knowledge in finance. He also has a profound knowledge of IBM Business Process Manager (BPM). Artur is IBM certified on latest versions of both products.
Don't miss out! Get updates on new webcasts, events, and blogs.