Hi,
Please read Wolfgang's advices. They are all good.
On top of that, I think it is time to look at the problem as a whole.
You have a pretty big rule set (20k rules you mentioned) and each rule, if
loosely defined as in your example will have a huge number of patterns (for
a rule). You also mentioned you have some kind of front-end where users
input data and that generates rules.
I am not sure what the other engine is doing with all that data you are
setting as AND/OR conditions for the rules, but I doubt it is any better
than generating java code and using java code as boolean checks on wheter to
apply a set of actions or not (actually, it might be doing exactly that
behind the scenes). I am saying that because the Rete algorithm achieves
it's performance from a set of optimizations (for instance, the fact type
discrimination, node sharing, memory indexing, etc) that are simply
impossible to derive from custom data structures and method calls as you
mention you are doing.
For instance, from an execution performance perspective, it would be
simply better (**I am not recommending this** :)) to have a single huge eval
using && and || among your constraints, than having the up to 100 evals/rule
you mentioned in your first example. That is because even if you use the 100
evals, you will still not trigger any of the above mentioned optimizations,
while severely burdening the execution environment with overhead of separate
code blocks, context switches, etc.
Now, I understand you are trying to move your use case to another
solution and properly take advantage of the features available. You mention
several requirements you have and that you need to handle them
appropriately. The first thing you need to do is consider the proper
representation (or metaphor) that would best suit you. Since you have a
front end for rules authoring, that should not be a problem for you as it
would be hidden from the users anyway. It might just make things easier when
generating code, be it, DRL, decision tables, or whatever you choose.
Then, there are your questions:
i) we have to iterate whole valueName not only [0]. How we can do it.
Wolfgang already pointed you to the documentation on "from". Although,
specially with a model like yours, I would strongly recommend inserting all
the facts into the session, not only the top level fact. Usually, for a
constant model like yours, it is a matter of a simple procedure that
iterates your model and insert all the dependent facts into the working
memory, but that will benefit all of your rules that will be simpler to
express and much more performant, since you trade iteration by
hashing+indexing when you do that.
ii) we have not only simple valueCode matching, we can have
a) Range in code such as 428.0 - 428.9, so any thing in WM having
valueCode b/w this range should match.
b) but we can't use simply numbers , we have to use String as we can
have
code having alphabet such as "V32.4"
c) we can have wild card usage too. e.g code in Rule can be "V2*" which
can be match any thing at the place opf asterik in WM valuCodes.
It seems to me that what you need is just to use some custom
evaluators. For instance, you could implement an "inRange" evaluator that
takes a range an matches when the given value is included in the range.
Example:
MyFact( myValue inRange "428.0-428.9" )
Behind the scenes, you are still calling a method that is doing the
range matching verification (not much different than calling the method in
an eval block), but this has several advantages over the use of eval,
starting by the simplicity on rules authoring, improved testability and
*specially* the ability to improve node sharing among rules. Developing
custom evaluators for Drools requires a developer to write a class that
contains some boiler plate code, but even someone that never implemented one
before should be able to develop and test the operator in less than a day.
After it is done, you can simply start using it everywhere.
For letter (c) above, you can simply use the built-in "matches"
operator, if you use java compliant regexps, or again, build your custom
operator. Using matches would be:
MyFact( myValue matches "V2.*" )
I see that Rule engine do introspection & call get methods of the
fields &
can do simple condition maching like ==, <, >etc. But mostly we have some
complex logic in matching like I told you in pt ii) of valuecode matching.
I think only sol is to call methods which will comes inside eval() & If we
start usig it for long rules. rules will never load & stuck :(...
See comments above on custom operators. "eval" is supported on the rules
engine because it is an excellent fallback mechanism, i.e., whenever the
engine can't do what you need, you just use an eval() to do that. Although,
it obviously should be the *exception* and not the *rule* (no pun intended).
If your rules are composed mostly of evals, then the engine is clearly not
the best tool for you to do what you need.
Also, regarding your "temporal" constraints, I am curious about what
kind of constraints are that. Drools has the whole set of 13 temporal
operators defined by Alen that enable you to easily represent any temporal
constraint (check Drools Fusion docs, but the operators are available to use
in rules even if the rules don't use events). Also, I am working on a Drools
feature set to support what is usually called "Effective Dated Models",
where facts only match if their effective/expiration dates overlap (well, a
bit more complex than that, but this is a good summary).
So, to be brief, in your case I think it is just a matter of using the
proper features and expressing the rules in the proper way. You will be
pleasantly surprised with the results if you take the time to do so, I am
sure.
Edson
2010/1/30 kashif10 <kash452(a)yahoo.com>
>
> Thanks edson for you nice advise.
> It really reduce the memory uage from 400 mb 70 mb..
>
> compareDiagnosis( valueName[0] in ("Heart Failure") ||
> (valueCode[0] in
>
>
("402.01","402.11","402.91","402.01","402.03","402.11","402.13","402.91","402.93",
> "428.0 - 428.9") , valueCodeSystem[0] == "2.16.840.1.113883.6.2"
) )
>
>
> Here I have some questions.
>
i) we have to iterate whole valueName not only [0]. How we can do it.
>
> ii) we have not only simple valueCode matching, we can have
> a) Range in code such as 428.0 - 428.9, so any thing in WM having
> valueCode b/w this range should match.
> b) but we can't use simply numbers , we have to use String as we can have
> code having alphabet such as "V32.4"
> c) we can have wild card usage too. e.g code in Rule can be "V2*" which
> can be match any thing at the place opf asterik in WM valuCodes.
>
> I see that Rule engine do introspection & call get methods of the fields &
> can do simple condition maching like ==, <, >etc. But mostly we have some
> complex logic in matching like I told you in pt ii) of valuecode matching.
> I think only sol is to call methods which will comes inside eval() & If we
> start usig it for long rules. rules will never load & stuck :(...
>
> Need your expet advise for those long & complex rules.
>
> Thanks
>
>
> --
> View this message in context:
>
http://n3.nabble.com/Weblogic-rules-to-Drools-rules-tp126265p178895.html
> Sent from the Drools - User mailing list archive at
Nabble.com.
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/rules-users
>
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @
www.jboss.com