OpenRules^® Release 6.3.0 essentially simplifies the OpenRules expression language by introducing macros, enhancing the standard decision templates, and making all decisioning constructs thread-safe. Here is the list of changes introduced by the release 6.3.0

• Decision Constructs are Thread-Safe
• Modified Decision Templates
• Simplified OpenRules Expression Language
• New Standard Conditions for Comparing Decision Variables
• Defining and Using Rule Identification
• Extended Decision API
• Changes in Rule Solver
• Sample Decision Projects
• Backward Compatibility

Decision Constructs are Thread-Safe

OpenRulesEngine has been thread-safe for at least last 5 years with that has been proven by very serious stress-tests and the real-world use of OpenRules in the various multi-threaded environments. However, when we introduced decision templates in the Release 6, we defined the global method "decision()" within the standard file "DecisionTemplates.xls". While it was convenient to refer to the currently running decision object, it made different decision runs not thread-safe.

To make the decision constructs thread-safe, in the release 6.3.0 we deprecated this method and replaced it with the keyword "decision". This keyword is actually defined as a parameter of every decision table - see all templates in the modified files "DecisionTableExecuteTemplates.xls" and "DecisionTemplates.xls". So, now if you stop using "decision()" your application that use our standard decision templates will also be thread safe.

The release 6.3.0 includes a sample project "DecisionHelloMultiThread" that demonstrates how to create only one instance of the OpenRulesEngine and then use multiple decisions created in different threads based on the same engine. 

Modified Decision Templates

We made the following changes inside the standard template files "DecisionTemplates.xls" and "DecisionTableExecuteTemplates.xls":

• First of all, now all templates DecisionTemplate, DecisionTableTemplate, DecisionTable1Template, and DecisionTable2Template have one parameter "decision", e.g. DecisionTableTemplate(Decision decision). It allowed us to replace the old method "decision()" with the keyword "decision" everywhere within any Decision and Decision Table templates. We made the proper changes inside template snippets, so these changes should not affect your existing decision tables created based on these templates. You just need to update your template files and "openrules.all.jar".

• We deprecated all get/set/compare methods from the file "DecisionTemplates.xls" and created methods with the same signatures in the Java class Decision. The deprecated methods will be removed in the future releases. So, instead of calling these methods directly in your Excel-based snippets, you need to add the qualifier "decision." in front of them, e.g. instead of getInt("Total Amount") you need to write decision.getInt("Total Amount") or better use a newly introduced macro $I{Total Amount}

• We added a new column of the type "#" for rule identification

• We added several more convenient conditions to the decision table templates

• The file "DecisionTableValidateTemplates.xls" became obsolete and has been eliminated.

Simplified OpenRules Expression Language

To simplify an access to the decision variables inside expressions (formulas) within decision tables, the release 6.3.0 introduces several convenient macros that start with the dollar sign. For example, an old decision table with the following concatenation formula

now can be presented as

The macro ${Greeting} actually replaces decision.getString("Greeting") that is a new correct syntax for getting a value of the decision variable "Greeting".

Here is the list of currently available macros that can be used inside Java snippets within Excel tables of the type "Decision", "DecisionTable" with various extensions, and "Method":

A letter after the dollar sign "$" points to the type of the variable. The default type is "String" - nothing between $ and {. 

Consider the old calculation formula that still remains valid in the version 6.3.0:

Now it may be replaced with a more compact formula using macros for real and integer variables:

Pay attention that you do not need to put variable names in quotes: you use curly brackets to indicate the beginning and the end of the variable name (that may contain spaces).

Inside the expressions you may use any operator "+", "-", "*", "/", "%" and any other valid Java operator. You may freely use parentheses to define a desired execution order. You also may use any standard or 3rd party Java methods and functions, e.g. ::= Math.min( $R{Line A}, $R{Line B} ).

Note. If the content of the decision table cell contains only a value of the text variable, say "Customer Location", then along with ::= ${Customer Location} you may also write $Customer Location even without ::= and {..} - this capability was available in previous releases as well.

OpenRules^® 6.3.0 also makes several small but helpful improvements:

• You do not need anymore adding additional brackets around an expression defined within ::= like in was necessary in the old decision table "CalculateTotalPayments" above;

• When defining intervals for comparison of integer and real numbers, along with intervals like [5;15] you also may use intervals like [5..15] as specified by the DMN standard.

New Standard Conditions for Comparing Decision Variables

We have added 3 new condition types to the standard decision table templates:

-  ConditionIntOperInt
-  ConditionRealOpenReal
-  ConditionDateOperDate

They allow you to easily compare integer, real and date variables inside your decision table like in the first column of the following example:

 

Defining and Using Rule Identification

Now you may define a rule ID and later on refer to it. We added a new column of the type "#" to the decision table templates. If you put any ID inside your first column of the type "#", then this ID will be assigned to the actually executed rule and to it in the action column of the same row like in the following example: 

If you look at the implementation of the column "Message" in the file "DecisionTableExecuteTemplates.xls", you will see the following Java snippet:

                  String out = decision.macro(message);
                  decision.log(out + " from " + $TABLE_TITLE);

Here the method "macro" replaces $RULE_ID with the actual ID of this rule within "message". You may similarly use this method inside your own custom templates, e.g. to save rule tracing information in your own desired way.

 

Extended Decision API and Javadoc

The Java class Decision now includes all get/set/compare-methods that have been deprecated (but still exist) in the Excel-based decision templates. The proper Java API for the classes Decision and OpenRulesEngine is now available from the following JavaDoc.

 

Changes in Rule Solver

The standard file "DecisionTableSolveTemplates.xls" that contains templates for Rule Solver has been modified. The main change is the removal of the method "solver()" that could have the same negative effect in multi-threaded environments as the old method "decision()" had. These changes are transparent for users who will simply switch to  the new template file.

Sample Decision Projects

All sample decision projects have been updated. The main necessary change was invocation of decision tables within Decision without := and parenthesis. For example, tables like

were changed to

 

You should make the proper changes in your tables of the type "Decision".

As the DMN 1.0 standard has been recently approved by OMG, we have improved the first implementation of the DMN10.Primer and added a new example "DecisionCreditCardApplication" discussed at this LinkedIn discussion.

 

Backward Compatibility

As always, we tried to keep the release 6.3.0 backward compatible. The only places where you may get syntax errors (after the upgrade to the 6.3.0) are you own Java snippets, in which you call decision tables using a snippet like := myDecisionTable(). They should be either replaced to := myDecisionTable(decision)  or better be called directly by name myDecisionTable without any snippet - this useful feature was introduced in the release 6.2.6.

If you used special Excel-based methods to access decision parameters, you need to pass a decision as a parameter of such methods. For example, to access an object-parameter Customer, you may have the following method customer():

However, the use of the global decision() prevented you from correctly running the same decision in parallel threads. So, you need to modify this method as follows:

Now, when you invoke this method from any decision table, you may simply write customer(decision) - remember that in the version 6.3.0 any decision table has a parameter "decision".

The old constructions are being deprecated but they still are working. However, we strongly recommend you to get rid of all references to "decision()" and other deprecated methods as they will not be available in the future releases. If your application is multi-threaded you must do it now. 

We expect that people who write their own Java methods in Excel should not have problems to quickly fix syntax errors caused by the latest changes in templates. However, we sincerely apologize for any inconvenience and would be glad to help you with all related requests - feel free to contact us at support@openrules.com and we will help ASAP. Hopefully, the fact that your decision application will be thread-safe and better organized will justify these efforts.

 

The product documentation has been properly updated. After downloading the latest complete OpenRules^® release 6.3.0 from here, you need to update your "openrules.config" project.

Please post your comments and suggestions to the Google Discussion Group or send them to support@openrules.com.