[rules-users] Rules that cumulate on consequence
Michael Anstis
michael.anstis at gmail.com
Wed Nov 23 11:40:00 EST 2011
Yay, a great improvement :)
2011/11/23 Vincent Legendre <vincent.legendre at eurodecision.com>
> It will work properly in a stateless session ... in sequential mode ...
> may be.
> This rule for instance, will loop by itself (and all other will also
> loop), in a stateless or statefull session :
>
>
> rule "one"
> when
> $r : Result( $score : score )
> Applicant( numberOfLoans > 1 )
> then
> $r.setScore( $score + 5 );
> update( $r ); // update $r, so re-trigger the rule, which
> re-update $r, etc etc etc ...
> end
>
> May be a no-loop could work, but no-loop is dangerous (hard to
> debug/maintain, and does not handle cycles between rules firing, ie "rule
> one" will trigger "rule two", which will trigger "rule one" again etc etc)
>
> The second set of rules could be better, if modified that way (test is the
> updated field is null in conditions)
>
> rule "one"
> salience 100
> when
> $r : Result(*numberOfLoans == null*)
>
> Applicant( $nl : numberOfLoans )
> then
> $r.setNumberOfLoans( $nl );
> update( $r );
> end
> ...
>
> Another option is to add some flags in the Result object, holding the fact
> that a rule (or a rule group, for instance the rule group that manage the
> numberOfLoans, another the income ...) has been fire, meaning that the
> corresponding applicant attribute has been taken into account. This flag is
> used in the conditions to exclude all other rules in the same group.
>
> May be a last option is something that I already use for a use-case close
> to this one. This was about computing counter (agregate a value in a single
> object, and avoiding infinite loop), then check them (so I need the updated
> value). My solution was a rule-flow with 3 boxes : [compute
> counter]->[update counters in RETE]->[check counters].
> The main trick is to update the value but not the object in [compute
> counter] group, like this
>
> rule "one"
> when
> $r : Result()
>
> Applicant( numberOfLoans > 1 )
> then
> $r.addScore( 5 );
> end
>
> -> $r fact is not updated in RETE here, so no infinite loop problem
> -> The main point to care about is to avoid getting the actual score in
> condition, but uise the getter in the action part. Indeed, as the $r fact
> is not updated, the original binding would be kept and all "computing"
> rules will update the same initial value (so forget about agregate).
>
>
> Then update all Results in [update counters in RETE] group :
> rule "update_results"
> when
> $r : Result()
> then
> update ( $r );
> end
>
> -> this will update all object for their further use for validation rules
>
> And finally, use your Result object with score updated to perform other
> actions in the [check counters] group :
>
> rule "decide_reject"
> when
> $r : Result(decision == null, score < 25)
> then
> $r.setDecision( Decision.REJECT );
> update ( $r );
> end
>
> -> Note the null check to avoid loops, again ...
>
>
>
> Le 23/11/2011 11:22, Geoffrey De Smet a écrit :
>
> Good idea,
>
> but note that it will only work properly in a stateless session (which is
> most likely in his case).
>
> In a stateful session, with multiple fireAllRules and when the applicant's
> properties change between those fireAllRules call,
> the trick is to do an insertLogical of a ScoreDiff instead of setScore()
> and then add 1 general rule to accumulate all those ScoreDiffs and put the
> resulting score into the Result.
>
> Op 23-11-11 10:56, Michael Anstis schreef:
>
> Why not use a Fact that contains your result?
>
> In DRL terms it'd look like this:-
>
> rule "one"
> when
> $r : Result( $score : score )
> Applicant( numberOfLoans > 1 )
> then
> $r.setScore( $score + 5 );
> update( $r );
> end
>
> rule "two"
> when
> $r : Result( $score : score )
> Applicant( disposableIncome < 20000 )
> then
> $r.setScore( $score + 10 );
> update( $r );
> end
>
> The result could equally just contain the factors influencing the score
> with a low salience rule then calculating the final score:-
>
> rule "one"
> salience 100
> when
> $r : Result()
> Applicant( $nl : numberOfLoans )
> then
> $r.setNumberOfLoans( $nl );
> update( $r );
> end
>
> rule "two"
> salience 100
> when
> $r : Result()
> Applicant( $di : disposableIncome )
> then
> $r.setDisposableIncome( $di );
> update( $r );
> end
>
> rule "calculate score"
> salience 200
> when
> $r : Result( $nl : numberOfLoans > 1, $di : disposableIncome <
> 20000 )
> then
> $r.setScore( 20 );
> update( $r );
> end
>
>
> On 23 November 2011 09:44, lansyj <lansyjp at gmail.com> wrote:
>
>> hi folks
>>
>> We are working on a requirement that requires us to have multiple rules
>> that
>> could fire for a given input and for all the rules that fire, we would
>> want
>> to cumulate the consequence to reach the final consequence.
>>
>> As an example, if we want to identify the credit score for a person, based
>> on his gender you might want to assign/increment/decrement the score, then
>> based on nationality, and so on.
>>
>> So, considering the long list of such criteria, having rules that cover
>> all
>> scenarios and are still mutually exclusive isnt a scalable solution. Could
>> you please advice on how this could be achieved.
>>
>> We run Drools 5.1.1 and Guvnor; rules are made using the guided editor
>> with
>> DSLs.
>>
>> Awaiting your support,
>>
>> Best Regards
>>
>> -lj
>>
>> --
>> View this message in context:
>> http://drools.46999.n3.nabble.com/Rules-that-cumulate-on-consequence-tp3530214p3530214.html
>> Sent from the Drools: User forum mailing list archive at Nabble.com.
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>
>
> _______________________________________________
> rules-users mailing listrules-users at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users
>
>
> --
> With kind regards,
> Geoffrey De Smet
>
>
>
> _______________________________________________
> rules-users mailing listrules-users at lists.jboss.orghttps://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/20111123/eff0ba7d/attachment.html
More information about the rules-users
mailing list