OpenRules allows its customers to create executable business decision models. To execute decision models OpenRules provides two rules engines:
- Sequential rule engine (the default one)
- Inferential rule engine.
The default, sequential rule engine will execute all decisions and rules starting with the main decision that may invoke other sub-decisions and decision tables. Thus, the execution sequence of different decisions and sub-decisions is specified by a user.
Contrary, the inferential rule engine execute decision models in a way similar to famous RETE-based rule engines but utilizes more powerful, off-the-shelf constrain solvers. This engine automatically resolves rule sequencing between different decisions and decision tables and rules ordering inside decision tables. Additionally, the inferential rule engine can find not one but multiple solutions and even an optimal solution. To change the execution mode, you need to set the system variable "OPENRULES_MODE" before creating an instance of OpenRulesEngine or Decision, e.g. System.setProperty("OPENRULES_MODE", "Solve"). Read more about the Solve mode in the Rule Solver. However, this engine does not support all decision modeling capabilities supported by the standard rule engine.
The majority of the decision models included in the standard OpenRules installation work with the default rule engine. For the majority of these decision models you even do not have to create and run an instance of a rule engine: you only create your decision models in Excel and double-click to the default batch file "run.bat".
Rule Engine in Multi-Threaded Environments
OpenRulesEngine is thread-safe and works very efficiently in multi-threaded environments supporting real parallelism. Contrary to many other rule engines, OpenRules' rule engine is stateless. It allows a user to create only one instance of the class OpenRulesEngine, and then share this instance between different threads - there are no needs to create a pool of rule engines. A user may also initialize the engine with application data common for all threads, and attach this data directly to the engine using the methods setAttachment(Object attachment). Different threads will receive this instance of the rule engine as a parameter, and will safely run various rules in parallel using the same engine.
installation includes an example "HelloFromThreads" that
demonstrates how to organize a parallel execution of the
same OpenRulesEngine's instance in different threads and
how to measure their performance.
OpenRules as a component of complex multi-transactional and multi-user applications for years applications has a proven record of high performance and scalability. These days most Rule Engines demonstrate a high level of performance, but OpenRules is frequently chosen over major commercial BR products because of the following differentiators:
- High performance
- High scalability for multi-user environments
- Efficient use of memory.
Consider the results cited in a a report OpenRules received from a major international bank. The bank created a series of performance and scalability tests before selecting OpenRules as the BR product of choice. They demonstrated that OpenRules scales to more than 300 concurrent users on a hyper-threaded server. Each concurrent user executed its rules 10,000 times with the following results:
Note that initially OpenRulesEngine takes more time to download all rules into the memory. However, there is no need to create a pool of concurrent rule engines: being stateless, the same instance of OpenRulesEngine can handle different concurrent requests.
Dynamic Rules Updates
If a business rule is changed, OpenRulesEngine automatically reloads all needed rules when necessary. Before any engine's run, OpenRulesEngine checks to determine if the main Excel file associated with this instance of the engine has been changed. Actually, OpenRulesEngine looks at the latest modification dates of the file xlsMainFileName. If it has been modified, OpenRulesEngine re-initializes itself and reloads all related Excel files.