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
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 zRule Execution 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.
The following table compares the differences between the classic rule engine and the decision engine.
|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 ARL tab for BAL rules and
decision tables provides a preview of the compilation of the rule.
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:
||Doubles are converted to BigDecimal objects by using the following
|The classic rule engine processes the rule artifacts in different ways:
For information on the execution modes, see Engine execution modes.
|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.|