1:04 a.m.
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users