Michal, A ruleset node only continues if the ruleflow group is it associated with is deactivated. A ruleflow group is deactivated automatically if it contains no more activations or if you deactivate it manually. By using an agenda filter, you are not executing the activation and thus the activation is never removed from the ruleflow group. Therefore, the process will keep waiting. This is expected behavior. Why were you expecting it to continue? I guess you would need some other kind of "filter" that not prevents the activation from firing but cancels activations that are not accepted by the filter? Kris Quoting Michal Bali <michalbali(a)gmail.com&gt;: > Hi, > If a rule is not allowed to fire by an AgendaFilter the whole > ruleflow > stops. > > I've created a small test case (attached). It contains: > - one DRL file with one dummy rule that is in some ruleflow-group. > - one RF file with three nodes ('start', 'ruleflow group' and > 'end') > - a program that starts the process, and calls fireAllRules with > custom > agenda filter. > > Once the program is executed the ruleflow will stop inside the > ruleflow-group. If I remove the agenda filter it works as expected > (the > ruleflow finishes). > > Tested with Drools 5.0.1. > > Is this a bug or am I missing something? > > Best regards, > Michal > Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Hey Michal, What about "enabled" attribute? Would that work for you? Of course that when I tried to find the docs on the enabled attribute I noticed someone actually removed it from there... :( Basically, "enabled" takes an MVEL expression as parameter. The expression can reference any globals, bindings from the LHS (user input), rule metadata and also are allowed to make external calls to arbitrary java methods. If the expression returns "true", the rule is activated as usual, while if it returns false, it will not activate for that given tuple. Since you mentioned "based on user input", I am assuming that the user inputs are either facts or globals. Example: http://anonsvn.le metadatajboss.org/repos/labs/labs/jbossrules/trunk/drools-compiler/src/te... So, I guess it would be like moving your logic from the agenda filter into the enabled expression. If you want, you can wrap that evaluation in a static method somewhere and call it, obviously. Hope it helps. On a side note, AgendaFilters were designed to be used mostly in unit tests and debug, not as a real modeling feature. Even then, I think we could improve this interaction between it and flow. Edson 2009/5/25 Michal Bali <michalbali(a)gmail.com&gt; > Hi Kris, > > Thank you for quick response and explaining the details. > > I thought that the AgendaFilter would cancel the activations and that the > ruleflow would continue. Otherwise it doesn't make much sense to use > AgendaFilter with ruleflow. But if it is not supported I'll have to live > with that :) > > My use case: I have lot of rules. I need to be able to turn some rules on > and off depending on user input. I know that I could modify rule conditions > to check if a rule is enabled or not but this means lot of duplicated > conditions that are hard to maintain. I could also use 'rule inheritance' > but it doesn't provide enough flexibility - it supports only single > inheritance. > > The problem is a crosscutting concern. It spreads across many rules. An > AgendaFilter seemed like the ideal candidate. > Alternatively, as you've indicated, I could use an AgendaEventListener and > in the activationCreated method cancel the activation. However this will > require use of some Drools internal APIs... > > Thanks for your help. > > Best regards, > Michal > > > On Mon, May 25, 2009 at 4:45 PM, Kris Verlaenen < > Kris.Verlaenen(a)cs.kuleuven.be&gt; wrote: > >> Michal, >> >> A ruleset node only continues if the ruleflow group is it associated >> with is deactivated. A ruleflow group is deactivated automatically if >> it contains no more activations or if you deactivate it manually. By >> using an agenda filter, you are not executing the activation and thus >> the activation is never removed from the ruleflow group. Therefore, the >> process will keep waiting. This is expected behavior. Why were you >> expecting it to continue? I guess you would need some other kind of >> "filter" that not prevents the activation from firing but cancels >> activations that are not accepted by the filter? >> >> Kris >> >> Quoting Michal Bali <michalbali(a)gmail.com&gt;: >> >> > Hi, >> > If a rule is not allowed to fire by an AgendaFilter the whole >> > ruleflow >> > stops. >> > >> > I've created a small test case (attached). It contains: >> > - one DRL file with one dummy rule that is in some ruleflow-group. >> > - one RF file with three nodes ('start', 'ruleflow group' and >> > 'end') >> > - a program that starts the process, and calls fireAllRules with >> > custom >> > agenda filter. >> > >> > Once the program is executed the ruleflow will stop inside the >> > ruleflow-group. If I remove the agenda filter it works as expected >> > (the >> > ruleflow finishes). >> > >> > Tested with Drools 5.0.1. >> > >> > Is this a bug or am I missing something? >> > >> > Best regards, >> > Michal >> > >> >> >> >> >> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm >> > > > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > > -- Edson Tirelli JBoss Drools Core Development JBoss, a division of Red Hat @ www.jboss.com _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users