[rules-dev] Possible Bug: Nodes of inherited types with drools.getActivation().remove()

[Edson Tirelli]

   Arjun,

   Did you tried to use agenda-groups and/or rule-flow to control the
sequence of execution (assuming of course you are using 4.0MR2 or later)?

   Basically the idea of these features is to implement phased rules firing,
or as the name says, "rule flows"... so, for instance, if you are using
agenda-groups, you can have all your rules for each table in a different
agenda-group: "table 1", "table 2", etc... when the condition to move focus
from one agenda-group to other is met ( for instance, table1->table2), you
change the focus to the table2 agenda-group and then, even doing modify in
objects that would usually trigger rules from table 1, the agenda group
prevents that from happening. So you have your phased execution.
   Rule-flow kind of does the same thing, but is more flexible and powerful
(a bit more complex too), allowing conditional transitions and a graphical
design of you rule groups.

   Unfortunately there are not many docs out there, but you can get some
info from the wiki and the blog... also, keep asking your questions in the
list and maybe give us a hand on documenting the features you eventually use
so others can benefit too.

   Think that using agenda.remove(), besides being conceptually
inappropriate, will only cause you headaches. I'm sure there are ways of
expressing your rules without incurring in such "technical rules-engine
specific hacks".

   Hope it helps,
        Edson

2007/6/2, Arjun Dhar <dhar_ar at yahoo.com>:
>
> >     So, may I suggest you open a JIRA with your example for us to
> investigate
> the bug? Also, I'm tempted to refactor the interface if possible to not
> expose
> the method remove() in the consequence...    What removes does is to
> remove the
> activation from the agenda, but the activation already fired, so what's
> the
> point of removing it? It may be the case that this is also creating an
> inconsistent state in the engine, so we need to check if that's the case
> and
> not expose the method anymore...
> >     Also, maybe you can show us a more complete example of what you are
> trying to achieve, so we can advise you on how to do it without calling
> the
> activation remove() method.    Thank you for reporting!    Regards,
> Edson
>
> Hi Edson,
> For a large number of rules comming from decison tables, when arranging
> them
> sometimes it is helpful to modularize tables; with the result of one
> rule-table
> driving another rule table. The preferred method is Decision table. Also
> this
> allows a person to lazy load rules over a set of base rules (part of the
> reason
> is business process and stability around an established concept. The
> format
> makes sense accoring to the business model also) <-- Background, so now
> i'll
> get to the point!
>
> So there is a need of one set of rules (outcome) to influence another
> (using
> tables). Scenario is like this:
>
> Table 1:
> -----------
> Rule 1.1
> Rule 1.2.
> Rule 1.3.
>
>
> Table 2:
> ----------
> Rule 1.2.1 (If fires will influence 1.2)
> Rule 1.2.2 (If fires will influence 1.2)
>
> >From this point on, you could suggest anything you see is not fit <----
>
> ... Thre preferred way to influence the connection = Change an attribute
> of the
> same object (Since the specific rule in the top table cannot fire till its
> conditions are not fullfilled); so when the attribute is set then only the
> rules in the above table will become active for that object.
>
> So when the "Business Object" is modified in Table 2, and hence modify()
> is
> called.
>
> You are right, the activation fires and is removed but due to modify() it
> causes a re-firing and puts some already fired activation back in the
> Agenda.
>
> Initally it hung, I realized the reason and put "no-loop". That stopped
> the
> recursion but I noticed certain activationse firing multiple times
> (Ideally I'd
> like the activation to fire and get out but here it would add it back
> again)
> which is not acceptable.
>
> I used "drools.getActivation().remove()" and it stopped the repeats, but
> then
> it was removing subsequent activations as well. I know why now. What I
> want to
> do is prevent this rule from firing again but inturn remove is removing
> the
> next activation. So the question is how to prevent the activation for that
> object not to fire again????
>
> My problem ends here (I understand it better now, not sure it should go
> into
> JIRA yet. Would like your comments one more time)
>
> About your comment about removing it. Due to the declrative nature of
> rules
> there are lot of conceptual barriers. So conceptual workarounds are
> restricted
> by the technology so we need every advantage. But then again, if you show
> me a
> better path to a solution I'd be more than happy.
>
> Thanks Edson, Appreciate it!
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>



-- 
  Edson Tirelli
  Software Engineer - JBoss Rules Core Developer
  Office: +55 11 3529-6000
  Mobile: +55 11 9287-5646
  JBoss, a division of Red Hat @ www.jboss.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20070602/8ccaf682/attachment.html