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: [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
