3:44 a.m.
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.
3:56 a.m.
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> 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
4:02 a.m.
Thanks a billion mantis!
We do think this would work; let me try it and confirm.
--
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.
4:22 a.m.
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
<mailto: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-tp35...
Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org>
https://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
--
With kind regards,
Geoffrey De Smet
9:47 a.m.
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
> <mailto: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-tp35...
> Sent from the Drools: User forum mailing list archive at Nabble.com.
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org>
> https://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
--
With kind regards,
Geoffrey De Smet
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
10:40 a.m.
Yay, a great improvement :)
2011/11/23 Vincent Legendre <vincent.legendre(a)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(a)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-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
4779
days inactive
4779
days old
5 comments
4 participants
participants (4)
-
Geoffrey De Smet -
lansyj -
Michael Anstis -
Vincent Legendre