Hi all,
we've faced the same problem in our application and we found that
writing DRL code into a StringBuffer using a template, then passing
the generated DRL back to Drools posed only little overhead. After
all, the compiler is very fast and optimizing the actual rules and
maybe fact collection can yield much more performance if it's needed.
Best regards
Marcus
On Mon, May 26, 2008 at 5:12 AM, Marina <ppine7(a)yahoo.com> wrote:
Thanks, Edson, Mark, for such a quick reply.
Mark, I'm not sure why you are saying that creating rules programmatically
would be too complex for users? Maybe by 'users' we mean different things.
In my case, a user will use a UI and create rules by selecting some
pre-defined properties (like contract_amount), then selecting an operator
(like <,==, > ...) then typing in a value to compare against, and then
specifying what is the resulting action (a few approvers, for example).
Easy. And then my code will transform this information into a rule like:
if (contract_amount > 5mil) then addApprover (user1). And so on.
So, the only part that is left is to transform this rule into DRL syntax,
or, as I was hoping would be possible, into Rules objects directly.
Something like:
Rule rule1 = new Rule()
rule1.addCondition(condition1)
rule1.addCondition(condition2)
rule1.setDependency (condition1, AND, condition2)
rule1.setAction(addApprover(user1))
As I understood from your response, it is not possible to do for now, unless
I use an unofficial API, which scares me off a lot as this is not a good
thing to base your application on an API that can change on you on a
minute's notice :-)
Still, I will take a look at the descriptor package and might consider going
this way if the performance of going through DRL turns out to be much worse.
Any plans on making this API public/published/stable? I would assume this is
not an uncommon feature request from those who wants to embed a rule engine
into their application.
Thanks a lot for all your suggestions!
Marina
----- Original Message ----
From: Edson Tirelli <tirelli(a)post.com>
To: Rules Users List <rules-users(a)lists.jboss.org>
Sent: Sunday, May 25, 2008 1:05:47 PM
Subject: Re: [rules-users] creating rules via API?
Marina,
My first advise for you is to forget JSR94. It is not worth to use it.
Regarding the creation of rules via API, you can use the descriptor
classes in the package: org.drools.lang.descr.
There is not much documentation (anyone up to help on that?) but it is
easy to understand how it works... just look at the result of parsing a DRL
file and you will easily figure out:
DrlParser parser = new DrlParser();
PackageDescr pkgDescr = parser.parse( source );
[]s
Edson
2008/5/25 Marina <ppine7(a)yahoo.com>:
>
> Hello,
>
> I am working on a project that requires a rules engine to handle numerous
> rules for approval chain determination. My main choice at the moment is
> JBoss Rules engine. One issue came up though that I could not find a good
> answer in the documentation:
>
> Is it possible to create rules programmatically via a public API? We
> already have a (pretty complex) admin screen as part of our application
> where users can build conditions and specify desired approval chains using
> the UI, integrated with all our back end stuff (domain objects, permissions,
> common look&feel, etc.). It would be a huge overhead to serialize these
> rules into DRL/XML files/streams and then have the rules engine parse them
> again....
>
> JSR94 solves the problem of handling rules once they are read from rule
> files, but there is nothing about creating and persisting rules, unless I
> missed it.
>
> thanks,
> Marina
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @
www.jboss.com
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users