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-routi...
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(a)lists.jboss.org
[mailto:rules-users-bounces@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(a)lists.jboss.org
>[mailto:rules-users-bounces@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(a)lists.jboss.org
>[mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Olenin, Vladimir
>(MOH)
>Sent: Thursday, February 01, 2007 4:04 PM
>To: rules-users(a)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(a)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
>_______________________________________________
>rules-users mailing list
>rules-users(a)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