[rules-users] Why so many ACTIVATION/DEACTIVATION events?

[Wolfgang Laun]

Hi Tom,

your understanding of "Activation" is fine, so let's see what happens if
your rule "RS..." fires. (I'm abbreviating names.)

Initially, neither PolSet nor PolSetId are there, so "RS..." activation #1
is on the agenda, fires and executes the consequence.

Now, PolSet is created and inserted as a new fact. This causes reevaluation
of all rules, including "RS..." (with its activation #1 still executing).
The not(PolSet and PolSetId) is still true, and therefore the LHS yields
true, and "RS..." activation #2 is put on the agenda. Continuing with #1,
PolSetId is created and inserted, causing reevaluations of all rules. Now
the not(PolSet and PolSetId) is false, so that "RS..." #2 is removed again.

As for a remedy, you might consider several approaches. Notice that I have
to guess what else might be going on, so I could be way off with (3), for
instance.

(1) Is it really necessary to have PolSet and PolSetId as two separate
facts? (It might still be possible to have PolSet as an *object* for
establishing linkage to the parental TransDet, without being a *fact*.)
(2) Add the rule attribute no-loop true to "RS..."
(3) If the absences of PolSetId alone is sufficient for triggering the
rule(s), omit PolSet from rule "RS..." and add another rule which creates
the "missing link" when you have a TransDet, the existence of at least one
PolSetId and no matching PolSet, to create the latter.

Cheers
-W

2009/9/1 <Tom.E.Murphy at wellsfargo.com>

>  We have a fairly complex object model, but we’re still puzzled – I
> thought that the definition of “Activation” was that the data matched on all
> conditions of a rule, and therefore the rule was entered into the agenda
> (activated).
> If that is true, I cannot figure out why we’re experiencing this.
> As our number of rules increases, we’re seeing exponential increases in
> repetitive activation/deactivation pairs, even on rules where we know the
> data does not match the conditions.
>
> Example:
> The following rule (abbreviated here) creates an object of type PolicySet
> if there are none that match the conditions.
> I would expect this rule to activate once, then fire, wherein the matching
> PolicySet is created, and then never activate again since the absence of a
> matching PolicySet object is never again true.
> However, in a rule base of ~4,000 rules, we see this rule activating 975
> times and deactivating 975 times. This is just one example – nearly all our
> rules do this, and it is seriously impacting decisioning performance.
>
> Have I misunderstood the meaning of “activation”? Can anyone help me
> understand this?
>
> rule "RS6090.1.12_RF7007_50001012"
>         when
>                 LendingProduct ( $exitStrategyType1 : exitStrategyType )
>                 Features ( $lienPriority1 : lienPriority )
>                 DecisionResultsInfo ( $dealRiskCategory1 : dealRiskCategory
> )
>                 TransactionDetail ( $parentTransactionDetail1Id : myId )
>                 not
>                 (
>                         PolicySet ( $parentPolicySet_1_Id : myId, parentId
> == $parentTransactionDetail1Id )
>                         and
>                         PolicySetIdentifier ( parentId ==
> $parentPolicySet_1_Id
> ,  lienPriority == $lienPriority1
>                                 , exitStrategyType == $exitStrategyType1
> , dealRiskCategory == $dealRiskCategory1)
>                 )
>         then
>                 // Content removed… rule creates the policy set and the
> policy set identifier, and initializes all appropriate elements
>                 // After doing so, why does it activate/deactivate 1800+
> times in a rule base of 4000 rules?
>                 System.out.println("6090 fired.");
> End
>
> Thanks.
> *Tom Murphy
> **Business Process Consultant
> Wells Fargo HCFG - CORE Deal Decisioning Platform
> 800 S. Jordan Creek Parkway | West Des Moines, IA 50266
> MAC: **X2301-01B
> **Office: **515 324 4853** | Mobile: 941 320 8014
> **This message may contain confidential and/or privileged information.  If
> you are not the addressee or authorized to receive this for the addressee,
> you must not use, copy, disclose, or take any action based on this message
> or any information herein.  If you have received this message in error,
> please advise the sender immediately by reply e-mail and delete this
> message.  Thank you for your cooperation.*
>
>
>
>
> _______________________________________________
> 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/20090901/f4fabf51/attachment.html