[rules-users] rule flow
Mark Proctor
mproctor at codehaus.org
Fri Sep 14 19:58:56 EDT 2007
ah yes I missed this. use the rule attribute "lock-on-active" to stop
this behaviour, it stops a rule re-activating while the ruleflowgroup is
active.
Mark
Kris Verlaenen wrote:
>
> > Now my understanding is that It should execute rule "Increment" 5
> times.... But instead it does it 10 times...
>
> > Is that a normal behavior?
>
>
>
> Well, actually, this is expected behaviour, let me try to clarify.
>
> Whenever a RuleSet node, like your "Up" node, is activated, it starts
> executing activations that are part of that ruleflow-group until no
> more activations can be found. Then the node will finish and the flow
> will continue with the next node. The problem is that your node, as
> it is implemented now, automatically increments your Integer 10 times
> in a row (you can easily test this by just executing this rule without
> a ruleflow present). The reason is, once you removed your old integer
> and inserted a new one, this new Integer will match the same rule
> again, so your "Up" node will not just continue after one increment,
> but will increment 10 times (until the integer does not match the <10
> pattern of your rule anymore) and then continue to the end.
>
> If I understand what you are trying to do, you should try to make sure
> that your "Up" rule only increments once. The best way I could think
> of right now is adding this at the end of your rule,
>
> drools.getWorkingMemory().getAgenda().deactivateRuleFlowGroup("Up");
>
> which will automatically deactivate your ruleflow-group and continue
> with your execution. But you'll have to use the latest svn code
> (or 4.0.2 which is released next week), as I found a small problem
> which would prevent you from doing this in 4.0.1 (.
>
> [Note: While using the no-loop rule attribute for your rule might
> solve the problem of reactivation of the same rule after an update
> outside the context of ruleflow, in this case, it will not be
> sufficient as it will not only block the reactivation of your rule for
> now but also for all future executions of your "Up" node in your flow,
> leading to an infinite loop.]
>
> When you are trying to implement a loop, you should also put your join
> first, and your split at the end. That way, you will decide what you
> want to do (in your split) every time AFTER your rule set has been
> executed. You can then decide to either go back (to the join in the
> beginning) or end.
>
> Also note that doing something like this will become much easier once
> we add support for ruleflow variables, as you would simply define a
> variable counter and you would be able to define an action like
> counter++, and use your ruleflow-groups for executing "real" rules.
>
> Kris
>
>
> ----- Original Message -----
> *From:* Manukyan, Sergey <mailto:SManukyan at lear.com>
> *To:* Rules Users List <mailto:rules-users at lists.jboss.org>
> *Sent:* Friday, September 14, 2007 9:19 PM
> *Subject:* [rules-users] rule flow
>
> Folks,
>
>
>
> Using 4.0.1. Trying to do use rule flow to manage the execution of
> rules. As I understood in Split node with type XOR I can set
> conditions for each destination that are executed against facts in
> working memory.
>
>
>
> Let's consider I have a rule that executes every time it finds
> Integer object in memory and increments it.
>
>
>
> rule "Increment"
>
> ruleflow-group "Up"
>
> when
>
> $i : Integer(intValue < 10)
>
> then
>
> System.out.println("INTEGER : " + $i);
>
> retract($i);
>
> insert(new Integer($i.intValue() + 1));
>
> end
>
>
>
> Now, I have the following rule flow in place:
>
>
>
>
>
>
>
> The Split to Up arrow has constraint : Integer(intValue < 5)
>
>
>
> And initially I am inserting this fact : insert (new Integer(0))
>
>
>
> Now my understanding is that It should execute rule "Increment" 5
> times.... But instead it does it 10 times...
>
>
>
> Is that a normal behavior? Why cannot Split understand that only
> when there is an Integer(intValue < 5) only then execute rule with
> ruleflow-group "Up"
>
>
>
> Thanks...
>
>
>
> -Sergey
>
>
>
>
>
>
>
> **********************
> ** LEGAL DISCLAIMER **
> **********************
>
> This E-mail message and any attachments may contain
> legally privileged, confidential or proprietary
> information. If you are not the intended recipient(s),
> or the employee or agent responsible for delivery of
> this message to the intended recipient(s), you are
> hereby notified that any dissemination, distribution
> or copying of this E-mail message is strictly
> prohibited. If you have received this message in
> error, please immediately notify the sender and
> delete this E-mail message from your computer.
>
> ------------------------------------------------------------------------
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20070915/4a4586c9/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 7191 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/rules-users/attachments/20070915/4a4586c9/attachment.jpe
More information about the rules-users
mailing list