Re: [rules-users] Rules that cumulate on consequence

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(a)gmail.com&gt; 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-tp35... > Sent from the Drools: User forum mailing list archive at Nabble.com. > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > _______________________________________________ rules-users mailing listrules-users@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users -- With kind regards, Geoffrey De Smet _______________________________________________ rules-users mailing listrules-users@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users