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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
-- 
With kind regards,
Geoffrey De Smet
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users