JBoss Drools to ODM migration path – assets perspective

Authors: Raj Chenna (IBM) & Anping (Mike) Cai (IBM)

Executive Summary

Business Rules Management System (BRMS) is an essential technology enabling organizational policies – and the repeatable operational decisions associated with those policies, such as claim approvals, pricing calculations and eligibility determinations – to be defined, deployed, monitored and maintained separately from application code. The key benefits BRMS provides to organizations is reduced or removed reliance on IT departments for changes in live systems, providing the ability for non-technical business users to be directly involved in business rules management, enabling flexible decision automation for applications and processes that are subject to complex, variable and evolving business rules. This is essential to compete effectively and to respond quickly to changing business needs.

There are many rules solutions available for organizations to choose from, such as IBM’s Operational Decision Manager (ODM), Progress’s Corticon, Microsoft’s BizTalk, FICO’s Blaze Advisor and JBoss’s Drools. A BRMS must be able to capture the knowledge of teams of business experts and manage those rules effectively. To achieve this, the BRMS must provide lifecycle management and rule governance. For lifecycle management the BRMS must offer an environment in which business experts, developers, testers, and administrators can create, modify, test, and deploy business rules. With the large number of rules that the BRMS would support, it must also make it easier for its non-technical users to locate rules and report on them so that its stakeholders can understand the function and interdependence of the rules within the system. Rule governance ensures only authorized teams and roles can create or change rules even when there is a large number of rules. Moreover, with so many rules that may change, governance allows experts to control which versions of rules are active and when they are in effect. Governance also identifies potential problems, such as conflicts that may occur when diverse teams create rules that are incompatible with each other.

All the rules solutions named above can handle simple business rules in an application or process. However, some complex application decisions require a more comprehensive rules solution that caters to evolving and dynamic business needs. These applications seek to improve efficiency by capturing the knowledge of business experts, automating tasks that previously needed human intervention. For these applications, business experts, working in teams, must capture their knowledge without depending on IT developers, using business rules solutions that are capable of holding thousands of related rules. With such a large number of rules, these solutions must be able to effectively manage and govern the roles and responsibilities of business experts, developers, testers, and administrators, while ensuring that rules do not conflict with each other. Only rules solutions with these strengths could be considered viable enterprise BRMS. IBM ODM offers the most advanced features that can handle simple as well as complex business scenarios and is considered the best BRMS solution available that meets the business needs of modern enterprise.

IBM ODM advantage over JBoss Drools

IBM ODM is the market leading BRMS with a proven, unparalleled ability to handle large, diverse teams in the creation of hundreds of thousands of complex rules. IBM ODM allows business experts to capture their business policies in a natural, non-technical manner. With this ease of use, they do not need to depend on an IT developer to translate their knowledge into programming language, thus saving time and, cost, improving accuracy and increasing agility. IT technical skill is needed only to setup or administer the Decision Manager environment, allowing business experts to focus on what they know best, and, at the same time, frees IT developers to focus on execution and integration aspects of applications.

JBoss Drools clients face several difficulties in developing and maintaining business rules. Below are to name a few:

    1. The object model for rules (Fact model) is typically shared with the application domain model. So any changes to the application domain, such as any addition, deletion or renaming of attributes, at the very least involves changes to the rules object model and potentially changes to rules. Also, the rules intertwined with application domain cannot be reused by other systems. For example, an application changes the domain attribute name from ‘customer’ to ‘client’ it affects all the references of ‘customer’ in the rules already implemented. Also, the rules intertwined with application domain cannot be reused by other systems like BPM or ESB.
    2. The business rule syntax is very cryptic. Deep technical expertise, extensive training and significant experiences are needed to understand the verbiage and semantics used in developing rules. The Drools Rule Language (DRL) is very much a programmer’s language pitched at Java programmers, and even the guided templates expose a lot of technical constructs and details that will probably confuse the average business user. For example, a simple rule to set error condition if the age of customer is more than 25 years, the Drools technical rule may look like below:
       package droolstest.testproject;
       import java.uti.*;
       import droolstest.test.model.Account;
       import droolstest.test.model.AccountType;
       import droolstest.test.model.Customer;
       rule “Student Account Customer Age more than 25”
       dialect “mvel”
         $customer:Customer(eval(yearsPassedSince(dateOfBirth >=25))
         error(kcontext, $account)

      The same rule using IBM ODM business language will look like below:

      the age of the customer is more than 25 and the account type 
        of the customer is ‘STUDENT’
       add “Age exceeds for the account type” to the messages of 
       ‘the account’
    3. The Guided Editor provided by Drools does not support developing rules in natural language as it involves a process of developing a Domain Specific Language (DSL) format that contains translation of text-like rules to actual Drools technical format of rules. Each part of a technical rule must have an equivalent of translated text in DSL in order to develop text-like rules. The tool does not create a default translation and has to be entered manually. The developed text-like rules cannot be deployed directly from the console environment. The result of this process is the business users are unable to implement, maintain or understand their own business decision logic.
    4. Lacks features to automatically propagate future changes to translation verbiage to the rules where the verbiage is used. Incorporating change is a manual process of identifying and modifying rules thus dramatically reducing business agility.
    5. If a DRL file is added that includes a rule name already present in the package, it replaces the previous file without alerting user. IBM ODM ‘refactor’ feature allows updating the rules with the changed verbiage automatically. For example a rule “Student Account Customer Age more than 25” already implemented in production and a new rule with the same name as part of a DRL file is implemented accidentally, the new rule will replace the previously implemented rule without any alert message. This scenario will not happen with IBM ODM as business users and IT team work using a synchronized version of rules.
    6. A rule may run into an infinite loop while execution until the WHEN condition is satisfied, unless no-loop property is added specifically to the rule.
      rule “Student Account Customer Age more than 25”
      no-loop true
      dialect “mvel”
        $customer:Customer(eval(yearsPassedSince(dateOfBirth >=25))
        error(kcontext, $account)
    7. Drools does not allow the rules to have an ‘else’ clause to set alternative consequences depending on the status of rule conditions. Drools allow only ‘when’ and ‘then’ constructs in rules. Capability of setting an ‘else’ clause in a rule may be very helpful in scenarios where setting Boolean attribute value to ‘on’ in the ‘then’ part of a rule and the value to ‘off’ in the else part of the rule, instead of creating two separate rules.
    8. Drools has no built-in collaboration in the DRL editor. It offers a “Discussion” section of its rule Metadata, but lacks the ability to follow rules of interest, mention colleagues, or view a stream that combines a record of comments and actions resulting in reduced productivity and accountability. The built-in collaboration feature of IBM ODM is covered elsewhere in this section.
    9. Drools does not provide the capability of comparing rules versions to identify the changes between versions making it difficult for the project managers to manage changes as they only have version history comments to go on. IBM ODM provides the capability to compare, work and merge different versions to rules and this feature is covered elsewhere in this section.
    10. Drools deployment package is a sensible combination of rules and decision tables, but the knowledge agents construct makes deployment complicated even for IT people. In fact, JBoss advises business users against trying to handle deployment themselves.
    11. JBoss Drools lacks business rule analytics and reporting. As a result, an application with a sizeable number of rules developed by different teams may inadvertently have rules that conflict or have gaps. Identifying the conflict and gaps manually by going through all the rules is error prone and manual effort intensive.
    12. Time-to-value may be reasonable for small projects of simple rules, but the lack of sophisticated graphical modeling tools for complex decisions and the extensive up-front work required by IT developers before business user involvement is causing difficulties.

IBM ODM, the industry leading BRMS addresses the above challenges and three other key challenges that JBoss Drools does not:

  1. Managing Change – Accelerating the ability of an organization to respond to evolving market demands, competitive actions and regulatory requirements. Enables subject matter experts to author and maintain decision logic and  improve collaboration between business and IT teams
  2. Maintain Control – Simplifying the visibility and Governance of automated business decisions within an organization. Separates decisions from processes and applications, improving the governance of change and facilitating re-use across business systems
  3. Achieve Precision – Ensuring that business systems deliver the right interactions at the right time. Executes precise, real-time decisions based on the context of specific interactions.

IBM ODM provides a comprehensive set of features which extends well beyond the basic ones offered by JBoss Drools. The table below enumerates the differentiating features offered by IBM ODM over and above the basic features offered by Drools.


Table 1: Feature comparison between JBoss Drools and ODM

IBM ODM enables decision logic to be based on a non-technical language with a customizable vocabulary that reflects the domain-specific terminology of an organization, allowing anyone to understand the exact conditions and actions of a decision definition. The customizable vocabulary is mapped to an underlying object model, which is used to deploy automated decisions to production systems. Business users do not have to worry about the translation of specifications into application code. Instead, they can author and maintain decisions directly, using intuitive editors to guide the user, with the ability to test and validate that those definitions meet their business requirements. While business rule definitions can use a standard ‘if-then-else’ text format (Business Action Language), business rules can also be defined using a variety of graphical formats, including decision tables, decision trees and scorecards, as well as rule flows to specify the execution order of rulesets for a given decision request. A ruleset is the end result of packaging the rule artifacts for execution. The rule artifacts are extracted from the rule project into a ruleset.

IBM ODM provides multiple rule execution algorithms that can be applied to individual rules, based on the decision service and other parameters. For example, the default RetePlus algorithm can be selected for a Stateful application comprised of many objects; a Sequential algorithm can be selected for applications with many rules and fewer objects, many customer cases in a multi-threaded environment; and a FastPath algorithm can be selected for an application with rules implementing a decision structure and many objects in a multi-threaded environment. JBoss Drools provides only a Rete algorithm and a limited capability of setting sequential mode for stateless applications.

The ability to author and maintain decision definitions is made available through ODM Decision Center Business Console, an out-of-the-box web environment which provides all the business user-facing capabilities of ODM. IBM Decision Center is a highly supportive, non-technical Web 2.0 style environment for business users to create, change and review decisions. The collaborative nature of this support together with its similarity to common user experiences like Facebook and Google results in delivering real empowerment to business users, enabling them to respond and innovate efficiently and productively. Decision Center gives business users the ability to participate directly in controlling the definition and governance of rule definitions that enforce their business policies. Business users can also associate metadata to decision definitions, such as effective and expiration dates, lifecycle status and relationships to other definitions, and provide additional context in how they are used in the production environment. Decision Center provides an enterprise repository for governing decision logic, and capabilities for testing, reporting and analysis of definitions. The collaborative, hand-holding approach of the console environment makes it quick and easy for business users to pick up the skills, and ensures decisions are based on consistent and high quality input.

IBM ODM provides a powerful search capability to locate rules of interest. The business user can search for the desired rule or rules using a keyword in the rule or browse through the recently changed rules or review the recent changes in the user ‘subscribed’ activities. Once the rule is located, the business user can edit the rule, post comments, reply to the comments of others to discuss possible changes, corporate policies, expert guidance or anything else related to a rule, decision table or project. Business users can define and run a query using natural language to extract rules based on a key word or to get a report of all currently deployed rules.

The ability to easily and efficiently change decision logic is only as effective as the ability to control those changes. Governance of changes enables both IT and business user teams to have confidence that they are correctly implementing decision logic, and that changes truly reflect business requirements. IBM ODM provides the perfect combination of business user empowerment and change governance to ensure easy, safe and reliable implementation of decision logic. The Decision Center’s repository is the foundation for change governance. The repository provides a single source of truth for automated decisions that are used across applications and processes, enabling business users to make a change in one place that can be deployed for use across multiple systems. Using role-based access controls, the repository allows business users specific access and management capabilities to the level of a single rule artifact, and provides multi-level versioning for rules, rulesets and entire rule projects.

Change governance requires the ability to handle both immediate and future changes at the same time. IBM ODM provides multiple release management capability which allows different teams to work in parallel on multiple versions of a rule project by creating branches off of a baseline version of the rule project. Multiple versions can be compared and merged rather than working with sequential versioning which speeds up time-to-value. This capability is useful particularly when working on groups of changes that are planned to be implemented together. Disparate branch versions can be viewed individually and compared side-by-side to see the differences between them. As and when versions are ready to be deployed, they can be used to create a new baseline and merged in whole or partially with other branch versions.

Rule testing is a crucial and intensive task within rule development, due to the nature of business rules working together and the value of having the business users maintaining the rules. IT and business managers want to ensure that newly deployed rulesets reach a level of quality that does not impact the production servers’ service level of agreement. IBM ODM provides a set of testing capabilities to validate and ensure that changes meet the needs of the business and the systems that use the results of the rules execution. These capabilities provide a wide range of testing functionality:

  1. Unit and regression testing to ensure individual rules execute as expected and do not affect other rules in an unexpected manner.
  2. Functional testing to execute rulesets against test data and capture the results. The test team can deploy the ruleset in a decision server and apply testing at decision service level.
  3. Simulation testing to measure the business results of rulesets against either historical or test data. IBM ODM provides a range of test and simulation options, where for example the user can review the results a particular rule would deliver against historical or created data, and then compare that side by side with the results from the proposed modifications. This allows business users to quickly validate and enhance their ODM changes.

Migration path to IBM ODM – Drools artifacts and approach of handling in ODM

Prior to analyzing the migration to ODM approach, it is important to thoroughly analyze each of the rule artifacts, types, functionality and usage in both Drools and ODM to understand the similarities and differences to quantify the advantages of ODM over Drools.

Fact Model

Facts are building blocks in Drools that define the object model for developing rules. The Facts model can be developed based on simple java POJO based JAR file or a declarative model using java types with rule-specific annotations. The fact model typically overlaps with the application domain model, but some solutions can have a decoupled fact model.


Figure 1: POJO Fact Model in JBoss Drools


Figure 2: Declarative Fact Model in JBoss Drools

IBM ODM uses two types of object models that form the basis for authoring rules:

  1. Execution Object Model (XOM): It is the model against which rules are run. It references the application objects and data, and is the base implementation of the Business Object Model (BOM) explained below. The rule project containing the rule artifacts references the XOM. IBM ODM provides flexibility in designing the XOM from compiled Java classes or from a XML schema. The facts model in Drools can be considered equivalent of ODM XOM

    Figure 3: Execution Object Model in IBM ODM Designer

  2. Business Object Model (BOM): The BOM is the object model for business rules. The BOM is the basis for the vocabulary used in business rules enabling business users to author business rues in natural language. It is an object model similar to a Java object model, and contains elements that map to those of the XOM. The BOM is an additional layer that can be generated automatically using Rule Project Map in ODM Rule Designer.



Figure 4: Business Object Model in IBM ODM Designer

Migration Approach:

Step 1: Copy the java POJO classes that from the Facts Model from JBoss IDE/Drools Eclipse IDE and create a java project with name xxxx-xom, where ‘xxxx’ denotes a meaningful name for the XOM. Paste the java class files in src folder. This will form the execution object model for the rules project in IBM ODM.


Figure 5: Java XOM using POJO classes in IBM ODM

Step 2: Create BOM using XOM. BOM creation, though not required to write business rules, is highly encouraged in order to facilitate business users maintaining their rules on an ongoing basis. In order to improve efficiency and to reduce BOM footprint on the server, only attributes used to define rules are selected for BOM creation. Other attributes not used in the rules are excluded by using XOM annotation @NotBusiness on XOM classes and attributes.


Figure 6: Creating BOM using Rule Project Map in IBM ODM

Drools Rule Language (DRL) & Domain Specific Language (DSL) files

A Drools language file can contain multiple rules, queries and functions as well as resource declarations like imports, globals and attributes that are assigned and used by the rules and queries. Except for the rules, all other elements are optional. Below is the sample structure of a .drl file:

rule “Maximum Amount”
                        $loan:Loan(amount > 1000000)

Figure 7: Sample rule using JBoss Drools DRL

A Domain Specific Language (DSL) enables writing rules in plain text-like form. This may be close to natural language. The motivation for using a DSL is to enable persons who are not programmers but experts in some application domain to read and write rules by themselves, but it is not a tool that business users can use to develop and maintain rules directly. A .dsl file contains series of regular expressions in sentences and its translation into regular DRL text. A .dsl file is associated with a .dslr file contains rules written in DSL and contains the statement expander pathname referring to the definition of its DSL language.

[when]There is a Loan application = $loan : Loan()
[when]-has a amount more than 1000000 = amount>1000000
# The possible actions in the ‘when’ part
[then]Process Loan Application= $loan.processApplication();
[then]Reject Loan=$loan.reject();

Figure 8: Rule translation using JBoss Drools DSL

IBM ODM supports two types of rules – Technical Rules (IRL files) which are written using The ILOG Rule Language (IRL) and Action Rules written using Business Action Language (BAL). Technical Rules are analogous to DRL files. However, the syntax is different.


Figure 9: IBM ODM Technical Rule using IRL

ODM Action Rules (BRL files) are written in business oriented language using the vocabulary defined in the BOM. An action rule defines the specific actions to take when certain conditions are met and uses an if-then statement to associate a condition (if) with an action (then). The rule states what action to perform when a condition is true.  Rules can be constructed using comprehensive list of BAL constructs and operators to perform arithmetic operations, associate or negate conditions, and compare expressions.  From a functionality perspective, ODM Action Rules are analogous to DSRL files in Drools.


Figure 10: IBM ODM Action Rule using BAL

Migration Approach:

Drools DRL and DSRL files can contain multiple rules, whereas in ODM each rule file – IRL or BRL will contain a single rule. ODM keeps all rules atomic, so that change in one rule will not impact others. The DRL needs to be broken into several small atomic IRL rules in ODM. If the file contains multiple rules, a Ruleset can be made in ODM to hold the rules contained in one DRL/DSRL file.

The rule constructs in ODM are similar to Drools.  The technical rules and action rules can be built using the IRL syntax and vocabulary defined in the BOM. Another approach is to update the BOM to match with the text and terminology used in existing DSRL rules. The IBM Competitive Migration team can make expert assessment of source code to determine the best approach for migration of DRL and DSL/DSRL files.

Decision Tables

Decision tables are a way of representing conditional logic. Drools support decision tables in spreadsheet formats (i.e. XLS and CSV). The conditions and consequences are represented in columns and each row is considered a rule. A spreadsheet can contain multiple decision tables as tabs. The spreadsheet file contains keywords; ‘RuleSet’ defines the name to be used in the rule package to hold all the rules and ‘RuleTable’ indicates to the rules engine the start of the rule table for generating DRL rules. Each row in a spreadsheet in the rule table is automatically generated as a DRL rule. Recent versions of Drools provide a guided editor to create and edit decision tables.


Figure 11: JBoss Drools Decision Table in Spreadsheet format

A decision table in ODM is analogous to the decision table in Drools and contains rows and columns that work together to form rules. The columns define conditions and actions and each row is considered a rule. Unlike the crude and error prone manual construction of decision tables in spreadsheet format, ODM has an IDE tailored for decision table construction that provides automatic input validation. Automatic input validation is not available in Drools versions prior to 6.3. Strings representing numbers can also be easily compared by modifying BOM verbalization and be used to define rules in ODM decision table. Such comparisons cannot be done in Drools decision tables and will be handled outside rules domain, which defeats the purpose of automated decision-making.

Migration Approach:

The rules rows in the spreadsheets in XLS, CSV, and guided editor format used in Drools can be used to create decision tables in ODM Rule Designer. Except for the ruleset name and package name, the Drools configuration information in the spreadsheet can be deleted as this information will not be used by ODM. If a spreadsheet contains multiple sheets as tabs, separate excel files should be created before creating decision tables in ODM.

Step 1: Open the spreadsheet in Microsoft Excel. The ruleset name can be used naming the package where the decision tables will be created in the rule project. The package name can be used to design the folder structure to store the decision tables within rule project. After capturing package and ruleset information, delete the header information (usually the first 17 rows).

Step 2: Create the package structure and rule package in ODM Rule Designer.


Figure 12: Package Structure for Rules Project in IBM ODM

Step 3: Create a new decision table in Rule Designer. Add condition columns and action columns to match the conditions and consequences columns in Drools decision table spreadsheet. Enter the conditions and actions using the BOM vocabulary.


Figure 13: Creating Decision Table directly in IBM ODM Rule Designer

Step 4: Copy the rules (rows) from Drools spreadsheet and paste into ODM decision table directly. Resolve any errors such as Boolean conversions, checking for string values etc.


Figure 14: Decision Table in IBM ODM migrated from Drools spreadsheet

Decision Trees

A Decision tree is a graphical representation of conditions and consequences. Decision trees provide an alternative and more convenient way of viewing and managing large sets of business rules, especially when these rules are asymmetric.

JBoss Drools provides a guided decision tree editor (Workbench) for modeling simple decision trees. The decision tree files can be identified with the extension .tdrl in the repository.


Figure 15: Decision Tree in JBoss Drools

In ODM decision tree, conditions are depicted as nodes, values are represented by branch lines, and actions are displayed in boxes at the ends of branches. Large sets of asymmetrical rules may be more easily understood using decision tree, where the path from the first condition to the end of the actions along any branch corresponds to one rule.


Figure 16: Decision Tree in IBM ODM

A decision tree in ODM contains a preconditions section that lets you:

  • Set variables that can be used in the decision tree.
  • Set a condition that is applied to an entire decision tree.

If the precondition is not satisfied, none of the rules in the decision tree can be evaluated. There is no such mechanism to set pre-conditions to evaluate a decision in Drools.

Migration Approach:

There is very limited usage of decision trees in JBoss Drools. The guided decision tree editor is available in version 6.2 and above versions only. The decision tree editor does not support nested data objects and should be used only with flat data object models.

IBM ODM supports simple and advanced modeling of decision tree representation of business rules and decision trees can be built using flat as well as nested data object models. The decision tress files (.tdrl) from Drools graphical editor can be re-created easily in ODM Rules Designer as decision trees. Edits need to be performed to validate the transition conditions, and actions matching with BOM verbalization. The IBM Competitive Migration team can make expert assessment of decision tree files to determine the best approach for migration.


Figure 17: Creating a Decision Tree in IBM ODM Rule Designer


Figure 18: Decision Tree palette in IBM ODM Rule Designer


A rule flow is a flow chart that describes the order in which a series of steps need to be undertaken. It consists of a collection of nodes that are linked to each other by connections. Each of the nodes represents one step in the overall process while the connections specify how to transition from one node to the other. The ruleflow can also deal with conditional branching, parallelism, synchronization, etc. The rules in Drools are grouped into ruleflow-groups using ruleflow-group attributes. JBoss IDE creates two versions of a ruleflow – one containing the ruleflow definition (*.rfm) and one containing additional graphical information (*.rf). When adding a ruleflow to a package, only the .rfm file is considered. Ruleflows in Drools are created by using the graphical Rule Flow Editor.


Figure 19: Ruleflow in JBoss Drools

Ruleflows in IBM ODM are a way of controlling rule execution. They are made of linked tasks that contain the instructions for 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 and to transfer information between the ruleflow and your application.

  • Ruleset parameters transfer information between ruleflow tasks and determine which path to follow through the transitions. For example, a status variable, such as isEligible, can be transferred to determine which task to go to next.
  • Ruleset parameters transfer information between the ruleflow and the application and the application obtains the results of ruleflow processing through ruleset parameters. For example, after the ruleflow ends the parameter can return an aggregated report, diagnostics, a set of compliance exceptions, or computed values, such as prices, rates, or taxes.


Figure 20: Ruleflow in IBM ODM

A start node and an end node are graphical markers for the start and end of a ruleflow. Every ruleflow has one start node and at least one end node. Ruleflow execution begins at the start node and stops at one of the end nodes, along the path defined by the ruleflow.

Between the start node and the end node, the ruleflow is made of tasks linked by transitions. The tasks of a ruleflow contain the instructions for what to execute and in what order.

Migration Approach:

Graphical representation of ruleflows is similar in both ODM and Drools. When a project contains multiple ruleflows, for efficient orchestration of rules one ruleflow is identified and named as the mainflow and rest of the ruleflows are connected as sub-flows executing from mainflow.

The ruleflow files from Drools graphical editor can be re-created easily using ODM Rules Designer as new ruleflows. Edits need to be performed to validate the transition conditions, tasks and the rule packages included within rule tasks. A mainflow needs to be identified and connected to test the ruleflows. Additional code may need to be included for start node to process special initialization logic. The IBM Competitive Migration team can make expert assessment of ruleflow files to determine the best approach for migration of Drools ruleflow files.

Test Scenarios

Test Scenarios in Drools are used to validate that the rules and knowledge base work as expected. As the knowledge base evolves Test Scenarios guard against regression. Each scenario has a ‘Given’ section that lists the facts needed for the behavior and an ‘Expect’ section that lists the expected changes and actions done by the behavior. Given facts are passed for the Test Scenario before execution. During the rule execution, changes in the knowledge base are recorded. After the execution ends the recorded actions, existing facts in the knowledge base and knowledge base output is compared against the expectations.

Test Scenarios can be executed one at the time or as a group. The group execution contains all the Scenarios from one module. Test Scenarios are independent – one Scenario can not affect or modify the other. After running all the Test Scenarios a report is shown. In a valid knowledge base all tests should pass and rule coverage should be 100%. Passing tests are marked with green while red shows failing tests and yellow notifies about missing rule coverage or missing expectations.

IBM ODM uses the Decision Validation Services (DVS) feature to test and simulate rulesets in Rule Designer and Decision Center. Testing and simulation in Decision Validation Services give users the ability to validate usage scenarios to ensure correctness of rulesets, or to see the potential impact of changes to rules. A scenario file generated from rule designer can be edited in Excel to populate the file with all scenarios necessary to validate the rules through testing and simulation. A scenario file contains a scenarios sheet used to enter data, an expected results sheet used to enter the expected results when running tests, and an expected execution details sheet used to enter the expected execution details when running tests.


Figure 21: Creating a Excel Scenario Template in IBM ODM Rule Designer


Figure 22: Test Scenarios tab in Scenario Template in IBM ODM


Figure 23: Expected Results tab in Scenario Template in IBM ODM 


Figure 24: Expected Execution Details tab in Scenario Template in IBM ODM

Migration Approach:

Testing using DVS in ODM works more effectively and provides important execution information not provided in Drools Test Scenarios like a list of rules fired, a list of executed rule flow tasks and duration of execution. DVS uses the BOM from the rule project to correctly generate columns and expected results using the BOM vocabulary.

The test scenarios existing in Drools can be easily recreated in ODM as the rules will have been successfully migrated to ODM in earlier steps. Using the BOM created for the rules from Drools a scenario file will be generated from Rule Designer. The Given facts and expected results from Drools scenarios are entered as scenarios details and expected results respectfully in the ODM scenario file.  The IBM Competitive Migration team can make expert assessment of test scenarios existing in Drools to determine the best approach for migration to ODM.

Applications and Application Servers

JBoss Drools business rules implementation is tightly integrated with Java application through knowledge-api, REST API and drools-core dependencies on application classpath (drools and mvel JARs). Exposing a rules service as a web service that can be accessed by any client application is complicated.

An IBM ODM Rules services can be accessed by virtually any kind of application. The rules can be invoked from Java applications through the ruleset path which acts as the entry point for clients to access the business logic encapsulated in the RuleApp. RuleApps deployed on a supported application server like IBM WebSphere or JBoss Application Server can be accessed by multiple, concurrent, distributed clients like JavaBeans (EJBs), Message-driven components, Web Services and RESTful Services.

The ODM rules can also be accessed from Mainframe COBOL applications by supplying the ruleset input parameter information (input data to rules) through a loader routine. A writer routine can be used to capture the output from rules service to be passed to downstream applications for consumption.

IBM ODM also offers a powerful easy-to-use feature to expose rules as web service using installed Hosted Transparent Decision Services (HTDS) application. Through this feature the rules services are published as WSDLs and can be readily accessible from wide range of different environments and applications, virtually any interface like BPM, ESB, and CC&B. There is no additional programming needed to achieve this functionality.

Migration Approach:

IBM ODM can be configured to use existing JBoss Application Server to host ODM rules services. Existing client applications should be modified to reference deployed business ruleset path by replacing knowledge-api calls. Thorough analysis of code is necessary to determine the extent of application code changes. The IBM Migration team can provide assistance through discovery sessions with your architect/development leads and through an on-site assessment, if required.


JBoss Drools involves tools that are too technical for business experts, cannot create rule flows to orchestrate the rules of interdependent teams, and lacks the governance that allows them to capture rules without conflict among teams of experts. JBoss Drools requires IT technical developers to analyze interpret and implement business policies on behalf of business experts. JBoss Drools clients wishing to increase line of business ownership of decision management, collaboration across the business and between business and IT and improve decision governance should consider the advantages that migrating to IBM ODM can provide them in today’s increasingly dynamic business environment. With IBM ODM organizations gain the power to adapt, align and act, improving their ability to take advantage of business opportunities and mitigate risk conditions. The table below summarizes the migration approach for various Drools rules artifacts to IBM ODM and the associated migration complexity.


Table 2: Summary of Migration Approach to Rule Artifacts

The IBM migration team has expertise in providing tools and knowledge to migrate existing Drools rules applications to IBM ODM that will enable your business experts to maintain and enhance their own business rules. The IBM Migration team conducts a migration methodology review involving three phases – Migration Discovery, Migration Assessment and Migration Implementation to successfully migrate your existing JBoss rule artifacts into IBM ODM. The migration team can perform a Proof of Concept (PoC) for a selection of rules to demonstrate its migration approach. Once the artifacts are in the ODM environment, the rules can be exposed in different ways to be invoked from Java, ESB and other interfacing applications.

IBM ODM, the market-leading BRMS, can help you achieve your business and IT objectives. The migration from Drools to IBM ODM is a technical endeavor, and the migration team of experts will apply best practices and proven methodologies gained over hundreds of other successful IBM product migrations to successfully migrate your rules solution to IBM ODM. Whether your objectives include reducing your total cost of ownership, protecting your software investment, or assuring your integration effort supports new use cases. IBM will deliver greater business agility to your stakeholders — and IBM will mentor and transfer skills to your team so that you can be confident in ongoing decision management projects.


  1. IBM Operational Decision Manager 8.7.0
  2. Drools Documentation Version 6.3.0
  3. JBoss Rules Reference Guide
  4. Drools JBoss Rules 5.0 Developer’s Guide – Michal Bali
  5. JBoss Drools Business Rules – Paul Browne

Categories: Migration

Tags: , , , ,

1 reply

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: