AnJoe Lite:Web Designers’ log

Drools, interesting name for a software isn’t it? Clever and catchy.

When JBoss changed their name from Drools to Rules Engine and back to Drools with the release of 4.0. I personally like this name. So anywayz, today I wanted to talk about something I’ve been struggling with. I’ve been using Drools 3.0.6 with FileNet Workflow system.  The rule I’ve implemented requires to modify certain value of an objects’ field within the working memory several times before spitting out the result.  With Drools 3.0.6, I’ve encountered infinite recurrsion when modifying the objects’ value.

I’ll step back for a bit and explain my situation.

The rule I have consists of multiple Agenda groups to control the rules flow.  Each agenda group contains its’ own activation group to fire one and only one rule from its’ group.  The salience is provided to control the execution order.  At any given point in the agenda groups, based on the business need, rules may need to modify the value of the fact and re-enter the working memory. The working memory does not automagically know of this changed values unless you implement the Property Change Listener.  So, in such case, after you set the value to an object, you must call modify(object); in the consequence (THEN) portion of the rule.

In the inner workings of the working memory, when Modify helper method is called, working memory will cancel any activated rule and re-enter the working memory.  Now, technically, you could set rules attribute, NO-LOOP to true and have the rule which called the Modify method not to be re-evaluated.  However, after looking at the audit log, I’ve noticed something interesting.  Everytime a Modify method is called from a rule, it does infact cancels any activated rule before re-entering the working memory. Once re-entered, the rule which called the Modify is infact not activated. However, if other rules call modify, it re-enters the working memory and reactivates any rules that matches.  NO-LOOP isn’t taken into account when reactived. 

I hope this explains my situation a bit.

Based on this, I’ve decided to come up with a “Hack”.  The business requirements I am using know when to end the rules evaluation.  If an incoming object contains certain values, rules engine should fired that rule and end the rules evaluation.  In FileNets’ term, it’s called “Dispatch Work Item”, as in send it to next step in the workflow process. 

I got lukcy in this sense.  So, in order to get rid of this, “POSSIBLE DEFECT” in drools, I implemented a very simple solution.  When the working memory is ready to Dispatch the incoming object, you “Retract” the object from the working memory.  The action of Retract cancels the entire activated list of rules.

If any of you “Droolers” encountered such behavior with Drools 3.0.6, please let me know of your solution.

 Happy Drooling!