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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Olenin, Vladimir >(MOH) >Sent: Thursday, February 01, 2007 4:04 PM >To: [email protected] >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 >[email protected] >https://lists.jboss.org/mailman/listinfo/rules-users > > > >_______________________________________________ >rules-users mailing list >[email protected] >https://lists.jboss.org/mailman/listinfo/rules-users >_______________________________________________ >rules-users mailing list >[email protected] >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 _______________________________________________ rules-users mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-users _______________________________________________ rules-users mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-users
