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 deployment, Decision Center and Rule Designer compile the rules to a much further state for the decision engine than for the classic rule engine.

Decision Center compiles the rules to intermediate code that requires only a final translation into executable code (Java™ bytecode) 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.

The decision engine has most capabilities of the classic rule engine although there are differences in their implementation.

Execution modes: With both engines, you can use the RetePlus, sequential, and Fastpath execution modes.

Working memory and agenda: These features are available in both engines 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 executing rules with the decision engine

To execute rules with the decision engine, perform the following steps:

Create a rule project to encapsulate the business logic of your legacy applications. If these are based on COBOL, use COBOL management features in Rule Designer. For more information, see Designing a BOM for a COBOL model.
Change the build mode of the rule project to use the decision engine instead of the classic rule engine. For more information, see Choosing a build mode.
Test the execution of the rules in Rule Designer. For more information, see Testing the execution with a Java application, and Running 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 execute rules with Rule Execution Server, the API to call the ruleset is the same for the classic rule engine and the decision engine. The engine build mode that is defined in the ruleset determines the engine that executes the rules.

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, the bytecode generation option is selected by default. However, ruleset archives that are generated from Decision Center for use with the decision engine do not contain the bytecode, which should therefore be generated at run time. 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 not converted to IRL. In Rule Designer, the IRL tab for BAL rules or ruleflows is not available in the rule editor. However, you can still use IRL in BOM-to-XOM mapping, technical rules, ruleflow action tasks and functions, as with the classic rule engine.
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.