Introduction
This study outlines the process for migrating a project from IBM Operational Decision Manager (ODM) to Drools, offering a comprehensive guide for a seamless transition. Both ODM and Drools are Business Rule Management Systems (BRMS) that automate and manage business rules and decision-making logic within applications. A BRMS helps define, deploy, execute, monitor, and maintain complex decision logic, enabling the externalization of rules for enhanced flexibility and control.
Study context:
Berger-Levrault has a proprietary payroll engine, which contains rules that work well but were developed several years ago. Not many people are familiar with it, and it has limited generalization beyond the paid system. This proprietary tool faces challenges due to old technology, limited familiarity, and restricted application to payroll systems. To address this, there’s a need to migrate to a new BRMS. The migration will require time and resources. The decision is to target IBM ODM and achieve migration through rewriting.
Study question
| Vendor Lock-In Concern Does migrating to ODM potentially lock into the IBM ecosystem, necessitating significant effort for future migrations? |
|---|
Objectif of this study
This study aims to prevent the risk of lock-in with a proprietary or single commercial BRMS in the future. Therefore, the aim is to demonstrate that migrating from IBM ODM to Drools is feasible if necessary.
Methodology
Our methodology consists of four steps, presented in Figure 1:
- Select a Use Case: Choose a use case that includes a rule to be managed by the BRMS.
Implement the Use Case: Implement the selected use case in both IBM ODM and Drools.
Compare Project Artifacts: Study the similarities between the two implementations.
Define the Migration Process: Establish a process to migrate the complete project from IBM ODM to Drools.
Use case
For this study, we have chosen a use case to calculate the discount based on customer status, spending habits, and birthdays.
- Existing customers with low spending receive no discount.
Existing customers with high spending generally receive a 5% discount and 20% on their birthdays.
New customers with low spending receive a 5% standard discount and 10% on birthdays.
New customers with high spending receive a 10% standard discount and 20% on birthdays.
Implementation of the Use Case in ODM and Drools
Figure 2 illustrates the implementation of use cases in IBM ODM and Drools, highlighting the parallel structures between the two systems. This figure provides an initial, informal comparison of their respective architectures.
On the left-hand side of the diagram, we can see the structure of the IBM ODM system. The ODM structure features an independent Java project, named “Demo – XOM,” which is imported into the ODM project as an Executable Object Model (XOM). The XOM is used as the basis for a Business Object Model (BOM). The BOM provides a more abstract representation that can be used in the creation of rules, allowing the utilization of the Java model and its attributes. The rules are organized into folders, which include “Task Flow” and “Sub Task Flow.” A task flow represents a sequence of actions and rules to be executed in a specific order. A sub-task flow is a task flow that forms part of another task flow.
The Drools project on the right side takes a Java-centric approach. It includes source code directories where business logic is defined and rules are specified in DRL (Drools Rule Language) files. A DRL file can contain one or multiple rules, and a Drools project can include several DRL files.
Identification of Similar Artifacts
Based on the comparison of the two projects, we will proceed with a formal study to identify and analyze the artifacts and their similarities in a systematic manner. To this end, we propose a formal model for both the ODM and Drools projects, which highlights the artifacts that can be mapped. This is depicted in Figure 3. The figure illustrates the mapping between rules, showing how rules represented in ODM can be translated into Drools. In particular, it demonstrates how a Task Flow in ODM is converted into a DRL file in Drools, including the corresponding set of rules and their respective priority weight.
After establishing the project model representation, we conducted a formal study of rules and Task Flows to demonstrate their concrete migration process.
Rules in ODM can be expressed in three ways: Business Action Language (BAL), Advanced Rule Language (ARL), and Business Rule Language (BRL). BAL, illustrated in Figure 4, uses natural language, allowing users to write rules in either French or English. BRL, shown in Figure 5, is an XML-based representation, while ARL, depicted in Figure 6, is a domain-specific language similar to Java.
The ARL file does not physically exist; it is automatically generated from the BRL and is only present within the Integrated Development Environment (IDE). Based on this analysis, our initial step involves migrating the ARL representation of ODM rules to DRL, as illustrated in Figure 7, due to their similarities. For clarity, we present both rule models and their mapping.
Implementation of the migration process
The migration process will be carried out in three steps:
- Rules Migration: Transform ODM rules into DRL rules.
Flow Migration: Convert ODM Task Flows and Subflows into ordered rule groups in Drools.
POJO Migration: Transfer the required Java objects.
- Localize and transfer XOM from ODM project to Drools project. This is a copy past performed by a basic PowerShell script
Rule Migration
The process of migrating ODM rules to Drools rules comprises several key steps, as illustrated in Figure 10. Initially, the ARL files generated in the ODM environment are read. Subsequently, the content of these ARL files is parsed to extract rule information. Finally, the parsed ARL data is converted into DRL files compatible with Drools. The proposed process is based on the hypothesis that ARL rules are manually copied and pasted into ARL files.
Task Flow migration
A Task Flow is a sequence of actions consisting of a start action, an end action, and tasks that contain one or more rules applied based on a chosen algorithm (sequential, priority-based) and optimization strategy. Figure 11 (left) provides an overview of a Task Flow. The process for migrating Task Flows from ODM to Drools involves several steps. First, the Flow BRL file, which defines the Task Flow in ODM, is read. The task flow FRL (Flow Rule Language) file, equivalent to a BRL file for Task Flows, contains only the UUIDs of the different tasks. The relevant UUID information is extracted by parsing the FRL file. Next, we iterate through the BRL files to find those that correspond to each UUID from the FRL. The corresponding ARL files are then identified and converted into a DRL format suitable for Drools, following the rule migration process (Figure 10). Figure 11 (right) illustrates the Task Flow migration process.
POJO migration
The final step involves transferring the necessary business objects, typically POJO classes, from the ODM project to Drools. Figure 12 illustrates this process. It includes scanning all Java projects in the input directory, collecting the POJOs, and copying them to the Drools project using a PowerShell script.
Experimentation and Results
To test our approach, we propose automatically migrating the initial project used for the similarity analysis shown in Figure 2. The project’s repository can be accessed [here](insert link). According to our hypothesis, the physical ARL files in the project are manually created by copying and pasting the ARL rule descriptions generated in the IDE.
The experimentation consists of two steps:
- Rule Migration: This step involves reading the rule repository from the ODM project and generating DRL files in the Drools project, following the process described in Figure 10. Figure 13 shows the result of migrating a rule from ARL to DRL using our migration tool. On the left side is the ARL file content, and on the right side is the generated DRL file content.
- Task Flow Migration: This scenario focuses on migrating a complete task flow. Figure 14 presents the result of migrating a task flow from FRL to DRL using our migration tool. The left side shows the FRL file content, while the right side displays the generated DRL file content.
Démonstration
Conclusion
This study has provided a comprehensive methodology for migrating a project from IBM Operational Decision Manager (ODM) to Drools, aiming to mitigate vendor lock-in risks and demonstrate the feasibility of such a migration. By comparing the structures and artifacts of both systems, we devised a systematic approach to ensure a seamless transition of business rules and decision-making logic.
The migration process was structured into clear, defined steps: selecting and implementing a use case, comparing project artifacts, and defining the migration process. A case study involving customer discount calculation highlighted the similarities and differences between ODM and Drools implementations. Our focus was on migrating rules, task flows, and Java objects (POJOs), showcasing the transformation from ODM’s Advanced Rule Language (ARL) to Drools’ DRL format.
The results of our experimentation confirmed the practicality of the proposed migration process, as evidenced by the successful conversion of rule and task flow examples. This guide serves as a valuable resource for organizations considering a transition from IBM ODM to Drools, offering insights and practical steps to ensure a smooth and efficient migration. The open-source code project is provided for experiment reproduction.
