[rules-users] Rules that cumulate on consequence

[Vincent Legendre]

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 
>> <mailto: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 <mailto: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
>
> -- 
> With kind regards,
> Geoffrey De Smet
>
>
> _______________________________________________
> 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/00dc89e7/attachment.html