Decision engine

The decision engine is designed to optimize the execution performance of your ruleset. The decision engine works in a similar way to the classic rule engine, although there are differences in the compilation and loading of the rules.

Before the deployment of a decision service with the XOM enabled in Decision Center, the rules are compiled by default to executable code (Java™ bytecode). For a classic rule project, or a decision service that does not have the XOM enabled, Decision Center compiles the rules to intermediate code that requires only a final translation into executable code at run time.

Rule Designer compiles the rules by default to executable code. Clear the Optimize ruleset loading (Java bytecode generation) option on the Export a Ruleset Archive page to compile the rules to intermediate code.

Although there are differences in their implementation, the decision engine has most capabilities of the classic rule engine: With both engines, you can choose either Fastpath, sequential, or RetePlus execution modes. The working memory and agenda features enable you to store and manipulate application objects. The working memory contains references to the application objects. The agenda lists and orders the rule instances that are eligible for execution.

Workflow for running rules with the decision engine

To run rules with the decision engine, do the following steps:

Create a rule project to encapsulate the business logic of your legacy applications.
If these applications are based on COBOL, use COBOL management features in Rule Designer. For more information, see Designing a BOM for a COBOL model.
If necessary, change the Rule Engine property of the rule project to Decision engine instead of Classic rule engine. When the rule project contains a BOM-to-XOM mapping in ILOG® Rule Language (IRL), the mapping migrates to a BOM-to-XOM mapping in Advanced Rule Language (ARL). The migration happens only once. For more information, see BOM-to-XOM mapping migration.
Test the execution of the rules in Rule Designer. For more information, see Testing the execution with a Java application, and (Deprecated) Running and debugging classic rule projects.
Deploy the ruleset to the persistence layer of either Rule Execution Server for distributed platforms, Rule Execution Server on WebSphere® Application Server for z/OS® or zRule Execution Server for z/OS. For more information, see Deploying business rules.
Call the ruleset:
- On Rule Execution Server for distributed platforms, use the Rule sessions API.
- On Rule Execution Server on WebSphere Application Server for z/OS, use the Rule sessions API.
- On zRule Execution Server for z/OS, use the Decision Server for z/OS API. For more information, see Adding API calls to a z/OS client application.
To run rules with Rule Execution Server, the API to call the ruleset is the same for the classic rule engine and the decision engine. The Rule Engine property that is defined in the ruleset determines the engine that runs the rules.

BOM-to-XOM mapping migration

The migration of the BOM-to-XOM mapping is carried out the first time you change the Rule Engine property of the rule project to Decision engine instead of Classic rule engine.

The migration does not modify the original BOM-to-XOM mapping in IRL (.b2x file), but creates a new file (.b2xa) to store the migrated code, which enables the user to switch back and forth between engines.

Once created, each file separately retains the changes you make for a particular engine, but there is no synchronization of the changes between the two files. If you switch to Classic rule engine and modify the BOM-to-XOM mapping, the .b2x file is modified. If you switch back to Decision engine the BOM-to-XOM mapping is not modified; the .b2xa file remains unchanged.

Some IRL statements cannot be migrated, so the migrated code might contain methods that have no body. You must code these missing lines in the .b2xa file in ARL .

Compilation and execution

The decision engine compiles rule artifacts into an archive that contains compiled and optimized code that becomes executable when translated to Java bytecode.

In comparison, a ruleset that is built with the classic rule engine contains a set of textual files that must be parsed before any compilation and optimization. Parsing, compiling and optimizing code are demanding tasks when you load a ruleset.

Therefore, the ruleset loading in the decision engine is faster because no code is parsed or interpreted at run time. All the code is already compiled (to intermediate code or Java bytecode) and fully optimized for rule execution.

The following figure shows the process of compilation and execution for the classic rule engine and the decision engine, with or without Java bytecode generation. This process goes through different stages from the initial compilation of rules until the execution of rules.

Comparison between the classic rule engine and the decision engine.

Important: Bytecode generation improves the loading time of rulesets that are built with the decision engine. In Rule Designer and Decision Center, the bytecode generation option is selected by default. However, for Decision Center, you must have enabled the XOM management to be able to activate the bytecode generation. With Rule Execution Server, there is a way to optimize the translation from intermediate code to Java bytecode. You can use the compiled archives cache to limit this bytecode generation to the first time that a decision engine ruleset is loaded. For more information, see Setting the compiled archives cache.

The following table compares the differences between the classic rule engine and the decision engine.

Table 1. Differences between the rule engines
Classic rule engine	Decision engine
The rules are converted to IRL, which is a low-level textual representation of the rules.	This implementation of the engine does not rely on IRL. The BAL rules are converted to the Advanced Rule Language (ARL) instead. In Rule Designer, the IRL tab for BAL rules or ruleflows is therefore not available in the rule editor. However, in the BOM editor, you can work directly with ARL to define the BOM-to-XOM mapping for rule projects that are designed for decision engine. Also, you can still use IRL in technical rules, ruleflow action tasks, and functions, as with the classic rule engine.
Doubles are converted to BigDecimal objects by using the following statement: `new java.math.BigDecimal(java.lang.Double.toString(java.lang.Math.exp(value.doubleValue())));`	Doubles are converted to BigDecimal objects by using the following statement: `scoreResponse.cpScore = new java.math.BigDecimal(Math.exp(value.doubleValue()));`
The classic rule engine processes the rule artifacts in different ways: The ruleflow and the RetePlus rule actions are interpreted. The RetePlus rule conditions that use the useJit property are compiled to bytecode. The rules that use the sequential and Fastpath algorithms are compiled to bytecode.	The rules and ruleflow are fully compiled to intermediate code or Java bytecode before deployment.
The ruleset archive .jar file contains the rules in IRL text files.	The ruleset archive .dsar file consists of binary files that contain execution code for the rules and ruleflows.