[rules-users] executing ruleflow with AgendaFilter

Edson Tirelli tirelli at post.com
Tue May 26 12:34:19 EDT 2009


   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.jboss.org/repos/labs/labs/jbossrules/trunk/drools-compiler/src/test/resources/org/drools/integrationtests/test_enabledExpression.drl

    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 at gmail.com>

> 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 at cs.kuleuven.be> 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 at gmail.com>:
>>
>> > 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20090526/7aa61f56/attachment.html 


More information about the rules-users mailing list