JRules is not a graphical programming environment
I got to review a JRules project recently where the developer did used JRules as a graphical programming tool, and not implement rules leveraging the inference and the capability of the rule language. The ruleflow has around 15 subflows that look all like the picture below.
The approach chosen was to loop around a collection of expenses and to apply rules in the "Expense" rule task using a variable named 'current expense'. A rule in the Expense rule task, looks like the following statement:
if
'current expense' has attendee
then
<... do something >
else
print "Expense had no person attached to it" ;
First a ruleflow should be used to control the flow of execution of group of rules, grouped together to apply business logic. A ruleflow should not be used as a UI for programming logic. A rule flow stays simple. What is interesting is that JRules as the definitions part in the BAL rules with operator 'in' to navigate collection of objects. The logic addressed in this flow is in fact really one line in the definition part of the rule. Using this capability we can remove 15 subflow, makes the rules far more efficient and gain on execution performance.
definitions
set 'current expense' to an Expense in 'all expenses received';
if
it is not true that 'current expense' has attendee
then
add error: "Attendee not present" to 'list of errors';
In this rule the variable 'current expense' will get all the references to the instance of the Expense class in the list of expenses received. Therefore the pattern matching in the if part of the rule will be done on this local variable. No more need to complex loop in the ruleflow...
I just wanted to share this with you, as this may be helpful to others. As a rule of thumb as soon as your ruleflow looks like spaghetti code, there is something fishy in the implementation. Most of the time the developer did not understand how a rule engine is working and how to leverage the different rule language operators. The product documentation is very good, with samples, and tutorials. Spending some time to understand rule programming will help avoid such pitfall.
The approach chosen was to loop around a collection of expenses and to apply rules in the "Expense" rule task using a variable named 'current expense'. A rule in the Expense rule task, looks like the following statement:
if
'current expense' has attendee
then
<... do something >
else
print "Expense had no person attached to it" ;
First a ruleflow should be used to control the flow of execution of group of rules, grouped together to apply business logic. A ruleflow should not be used as a UI for programming logic. A rule flow stays simple. What is interesting is that JRules as the definitions part in the BAL rules with operator 'in' to navigate collection of objects. The logic addressed in this flow is in fact really one line in the definition part of the rule. Using this capability we can remove 15 subflow, makes the rules far more efficient and gain on execution performance.
definitions
set 'current expense' to an Expense in 'all expenses received';
if
it is not true that 'current expense' has attendee
then
add error: "Attendee not present" to 'list of errors';
In this rule the variable 'current expense' will get all the references to the instance of the Expense class in the list of expenses received. Therefore the pattern matching in the if part of the rule will be done on this local variable. No more need to complex loop in the ruleflow...
I just wanted to share this with you, as this may be helpful to others. As a rule of thumb as soon as your ruleflow looks like spaghetti code, there is something fishy in the implementation. Most of the time the developer did not understand how a rule engine is working and how to leverage the different rule language operators. The product documentation is very good, with samples, and tutorials. Spending some time to understand rule programming will help avoid such pitfall.
Comments