[rules-users] Looking for a place to start with drools

Michael Anstis michael.anstis at gmail.com
Thu Sep 16 11:39:42 EDT 2010


Of course you could leverage the benefits of using Drools to directly
replace your hard-coded logic first and leave the enhancements around
permitting your users to define their own rules to a later date rather than
push into one release; if time is a concern. Would the Drools road be any
more different than allowing your users to define their own hard-coded rules
now using a proprietary mechanism?

>> 1.       How would you package these types of rules?  I have three
categories as stated above and it seems logical that I would package them in
that manner.  However within each group there are logical groupings of
rules.  In the customer rules I may have a couple dozen on how to populate a
field that deals with adding comments and another couple dozen having to
deal with setting certain fields with specific codes that are based upon
incoming data.  Two quite different logical areas within our software.

Horses for courses. Nothing stopping you deploying multiple packages if need
be, but it'll be harder to try and make course grained packages more fine
grained if you later wish you'd done this from the start.

>> 2.       How would you deal with the GUI? Is Guvnor truly something I can
setup in a way that my end users can manipulate without “damaging” the
custom ruleset?

With power comes responsibility. If users are given the power to define
their own custom rules they have to take responsibility for damaging them
too. There is the ability to run tests against rules in Guvnor, but that
won't stop somebody from mucking them up. I'd recommend providing for UAT. I
don't what exposure your clients have to "testing" new features now..

>> 3.       Within Guvnor, how would you handle the possibility of there
being over 2,000 fields to choose from to form a rule?

I believe there is functionality in 5.1 for Working Sets that allow subsets
of fields\fact types to be exposed.

>> 4.       What is the performance hit if we were to make each customer
rule part of once decision table or another? Would you even consider this as
an option?

One decision table for all users at all customers? One DT per rule is
normally the intent, or did I misunderstand.
Good luck.

Mike

On 16 September 2010 15:00, Gustavo Tenrreiro <gustavo at tenrreiro.com> wrote:

> Hi Dean,
>
> I ve only been working with Drools for about a couple of months.
> My first impression was that it was a great tool and very
> straightforward. But as I got deeper into it, I found a lot of
> gotchas, and things I didn't quite understand how they worked ( for
> many I still don't ). Finding definitive answers to those questions
> has been hard. Even though this forum, as well as the IRC chat are
> very helpful, the flow of information is somewhat limited.
> If what you are doing has some complexity beyond the simple examples
> provided by the documentation, and sample code, then you will probably
> get stuck at some point, and burn a lot of time trying to figure out
> the problem.
>
> So if you are on a tight budget that requires tight deadlines using
> Drools to replace your existing code would be a high risk proposition
> I believe.
>
> On the other hand, the Drools's potential to simplify, and streamline
> my system is great. if I manage to get it to do what I want it to do
> it would be a huge win for my organization, and the Drools system
> would be mostly responsible for that.
>
> So to summarise, jumping into the Drools bandwagon would be an
> "educated bet", but a bet nonetheless.
>
> Hope that helps.
>
> Thanks
>
>
> 2010/9/16 Dean Whisnant <dean at basys.com>:
> > I am investigating using Drools for our company’s EDI processing.  The
> > nature of our software system is that each of our clients (dozens) has a
> > full distribution of our base software and in the past we would make
> custom
> > changes to that base software at each of their sites based upon their
> > trading partners and business needs. For the most part these changes
> > involved nothing more than if-then statements for rather simple logic,
> but
> > that would become complicated at certain customers where there were large
> > numbers of trading partners and specific customer needs.  In general we
> saw
> > 2,000 lines of code swell to 4-6,000 lines of code.
> >
> >
> >
> > We are in the process of rewriting this portion of our code and are
> > entertaining using drools to allow us to 1) create a standard ruleset, 2)
> > create a ruleset specific to a trading partner (many customers share some
> > common trading partners), and 3) create a customer business ruleset that
> > they can maintain through some GUI tool (Guvnor).
> >
> >
> >
> > So far, I’ve created a sample java program that has classes representing
> > some of our data files (UniData environment using uniobjects) and have
> been
> > working with a single .drl file to test out general rules.  I appear to
> be
> > able to write just about any rule I’ve needed in the past with no issues,
> > including rules that spawn processes within my native software.
> >
> >
> >
> > These are my questions:
> >
> >
> >
> > 1.       How would you package these types of rules?  I have three
> > categories as stated above and it seems logical that I would package them
> in
> > that manner.  However within each group there are logical groupings of
> > rules.  In the customer rules I may have a couple dozen on how to
> populate a
> > field that deals with adding comments and another couple dozen having to
> > deal with setting certain fields with specific codes that are based upon
> > incoming data.  Two quite different logical areas within our software.
> >
> > 2.       How would you deal with the GUI? Is Guvnor truly something I can
> > setup in a way that my end users can manipulate without “damaging” the
> > custom ruelset?
> >
> > 3.       Within Guvnor, how would you handle the possibility of there
> being
> > over 2,000 fields to choose from to form a rule?
> >
> > 4.       What is the performance hit if we were to make each customer
> rule
> > part of once decision table or another? Would you even consider this as
> an
> > option?
> >
> >
> >
> > Thank you!
> >
> >
> >
> > --Dean
> >
> > _______________________________________________
> > rules-users mailing list
> > rules-users at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
> >
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20100916/c40576d4/attachment.html 


More information about the rules-users mailing list