Re: [rules-users] Looking for a place to start with drools
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users