[rules-users] advice is needed: rule based processing ofinter connected facts
Edson Tirelli
tirelli at post.com
Fri Feb 2 14:50:22 EST 2007
Vlad,
- JBRules 3.1 is the DROOLS 3.1 (which is currently under dev-t), correct?
Yes, that is correct.
- Is there a way to achieve the same functionality using existing release
(unless DROOLS 3.1 would be released within next month or so)?
Yes, it is just a bit more verbose. Primitive types are automatically boxed in 3.0, so to make calculations you need to call the respective doubleValue(). intValue(), etc methods. Also, Accumulate is a new CE in 3.1. You can achieve the same functionality though with a simple helper class that will serve as your "accumulator" object.
Release 3.2 final (3.1 is the development release) is scheduled for the end of march. Milestone 1 is supposed to be out any time now.
- The '$' prefixed variables have some special meaning, correct? What
section of the manual can I find more details on what it means? (is it part
of Drools 3.0 or 3.1 only?)
No, it is just a best practice to make clear it is a bound variable and not a plain java variable or object field. You don't need to use $ if you don't want to. I like it for readability reasons.
- Performance-wise, would DROOLS (or any other RETE based engine) give any
substantial benefit vs plain 'line-by-line' processing of the rules (eg,
implemented in SQL, providing facts are loaded from the DB)? Ie, putting
aside 'configurability' aspect. And providing there are around 400
'templated' rules, each having ~15 fields/conditions to be analyzed? I can
understand how DROOLS can optimize 'static' network (when facts are
evaluated against static conditions), but not sure if the same would be
valid when facts are evaluated against each other.
There is almost no difference if you have just a few rules, but as you
grow the number of rules, Rete optimize the execution. Look at this:
http://markproctor.blogspot.com/2006/11/rush-hour-and-content-based-routing.html
There is a table showing some numbers. Forget the absolute numbers. Just
pay attention to the relative performance as the number of rules grow
from 10 to 100 to 1000. Replace XPath for the technology of your choice
and you will have a similar behavior if your technology simply tries to
apply all rules in sequence. This is because Rete does not try to apply
all rules. It only apply rules that do have a matching tuple.
[]s
Edson
Olenin, Vladimir (MOH) wrote:
>Thanks for the tip, Edson.
>
>Looks promising. Can you give some more details on the following:
>
>- JBRules 3.1 is the DROOLS 3.1 (which is currently under dev-t), correct?
>
>- Is there a way to achieve the same functionality using existing release
>(unless DROOLS 3.1 would be released within next month or so)?
>
>- The '$' prefixed variables have some special meaning, correct? What
>section of the manual can I find more details on what it means? (is it part
>of Drools 3.0 or 3.1 only?)
>
>- Performance-wise, would DROOLS (or any other RETE based engine) give any
>substantial benefit vs plain 'line-by-line' processing of the rules (eg,
>implemented in SQL, providing facts are loaded from the DB)? Ie, putting
>aside 'configurability' aspect. And providing there are around 400
>'templated' rules, each having ~15 fields/conditions to be analyzed? I can
>understand how DROOLS can optimize 'static' network (when facts are
>evaluated against static conditions), but not sure if the same would be
>valid when facts are evaluated against each other.
>
>Thanks.
>
>Vlad
>
>-----Original Message-----
>From: rules-users-bounces at lists.jboss.org
>[mailto:rules-users-bounces at lists.jboss.org] On Behalf Of Edson Tirelli
>Sent: 02 February 2007 11:13
>To: Rules Users List
>Subject: Re: [rules-users] advice is needed: rule based processing ofinter
>connected facts
>
> Hi Vlad,
>
> This is a case where you can apply business rules with good results.
> In the end, it all depends on how you model your Business Objects,
>but lets get some examples:
>
>
>
>>1) for all primary accounts 'zxxy' where y < 5, there should be a matching
>>primary account '(z+1)xxy'
>> - [this one is true for the dataset above]
>>
>>
>
> My understanding is that you are validating your accounting plan, so
>you may have an Account object in your model. So, if you want to report
>inconsistencies, you can do something like:
>
>rule "missing accounts"
>when
> $a : Account( $number : number -> ( number % 10 < 5 ), number < 9000 )
> not Account( number == ( $number + 1000 ) )
>then
> // $a does not have a matching primary account
>end
>
> Please, note that the "formulas" I used above may not be the best way
>to do it... they are only a possible representation of what you said.
>
>
>
>>2) sumOfDebit(primary + matching_primary + secondary_account) -
>>sumOfCredit(primary + matching_primary + secondary_account) must be = 0
>> - [this one is also true]
>>
>>
>
> Here, it seems you are refering to a set of transactions, so you
>might have a set of transaction objects to represent the transaction in
>your sample. So, a possible representation would be:
>
>rule "transaction consistency"
>when
> Transaction( $id : id )
> $credits: Double( )
> from accumulate( TransactionEntry( id == $id, operation ==
>"credit", $amount : amount ),
> init( double balance = 0 ),
> action( balance += $amount ),
> result( new Double( balance ) ) );
> $debits: Double( )
> from accumulate( TransactionEntry( id == $id, operation ==
>"debit", $amount : amount ),
> init( double balance = 0 ),
> action( balance -= $amount ),
> result( new Double( balance ) ) );
> eval( ! $credits.equals( $debits ) )
>then
> // inconsistency for transaction $id
>end
>
> Again, this is not the only way or the best way... it is just an example.
>
> Also, for the above examples, I used syntax/features of the jbrules
>3.1 version.
>
> Hope it helps.
>
> []s
> Edson
>
>
>Olenin, Vladimir (MOH) wrote:
>
>
>
>>Ok, approx data set:
>>
>>Primary Account | Secondary Account | Operation | Amount | Type | Owner
>>------------------------------------------------------------------------
>>0001 | | debit | 100 | A | M
>>1001 | | credit | 80 | A | F
>>1001 | | credit | 20 | X | F
>>0002 | 2002 | debit | 50 | B | M
>>2002 | | dedit | 20 | B | M
>>1002 | | credit | 70 | C | M
>>
>>Rules:
>>
>>1) for all primary accounts 'zxxy' where y < 5, there should be a matching
>>primary account '(z+1)xxy'
>> - [this one is true for the dataset above]
>>2) sumOfDebit(primary + matching_primary + secondary_account) -
>>sumOfCredit(primary + matching_primary + secondary_account) must be = 0
>> - [this one is also true]
>>3) OwnerOf (primary_account, matching_primary, secondary_account) must be
>>
>>
>of
>
>
>>the same gender
>> - [this one is false - 0001 owner must be 'F']
>>
>>.... The kind of the rules above... The dataset is more complex and the
>>rules are a bit more involved, but this should give an idea.
>>
>>Thanks for all suggestions!
>>
>>Vlad
>>
>>-----Original Message-----
>>From: rules-users-bounces at lists.jboss.org
>>[mailto:rules-users-bounces at lists.jboss.org] On Behalf Of Michael Rhoden
>>Sent: 01 February 2007 17:49
>>To: 'Rules Users List'
>>Subject: RE: [rules-users] advice is needed: rule based processing
>>ofinterconnected facts
>>
>>Can you post a couple of example conditions with a dataset you want to
>>check?
>>
>>-Michael
>>
>>-----Original Message-----
>>From: rules-users-bounces at lists.jboss.org
>>[mailto:rules-users-bounces at lists.jboss.org] On Behalf Of Olenin, Vladimir
>>(MOH)
>>Sent: Thursday, February 01, 2007 4:04 PM
>>To: rules-users at lists.jboss.org
>>Subject: [rules-users] advice is needed: rule based processing
>>ofinterconnected facts
>>
>>Hi,
>>
>>
>>
>>I need some pointer as to where to start with the problem below.
>>
>>
>>
>>The system should be able to validate the balancing data based on around
>>
>>
>400
>
>
>>different rules. To simplify the task, the data facts are essentially the
>>debit/credit transactions on different accounts. The rules describe the
>>correlation between different facts:
>>
>>- eg, all debit transactions minus all credit transaction must be
>>equal 0
>>
>>- if one account got credited, there should be another account
>>(within the same dataset) which was debited
>>
>>- if there are accounts starting with some letter combination,
>>there also should be
>>
>>- etc
>>
>>
>>
>>In other words, each rule describes
>>
>>- the subset of facts to be analyzed
>>
>>- the rules to be checked against this subset
>>
>>
>>
>>It seems basically like each fact is a set of Account Number, Transaction
>>Type, Transaction Amount information, Secondary Account Number (which
>>sometimes needs to be validated against some other account number within
>>
>>
>the
>
>
>>same data set). But I couldn't find a way to relate between multiple data
>>facts.
>>
>>
>>
>>On one hand rule engine seems to be a good solution in here, but I'm not
>>sure how to deal with 'dynamic selection' of the subset of facts. Can this
>>kind of task be reformulated somehow?
>>
>>
>>
>>Any pointers into the DROOLS documentation or hints on a general approach
>>would be greatly appreciated!
>>
>>
>>
>>Thanks.
>>
>>
>>
>>Vlad
>>
>>_______________________________________________
>>rules-users mailing list
>>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
>>_______________________________________________
>>rules-users mailing list
>>rules-users at lists.jboss.org
>>https://lists.jboss.org/mailman/listinfo/rules-users
>>
>>
>>
>>
>>
>
>
>
>
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3124-6000
Mobile: +55 11 9218-4151
JBoss, a division of Red Hat @ www.jboss.com
More information about the rules-users
mailing list