Hi Dean,<div><br></div><div>Re #2; take a look at KnowledgeBuilder (which I assume you may have already) which loads Decision Table files (XLS) and creates a KnowledgeBase wherefrom you create your KnowledgeSessions. If you really want DRL from your XLS's look at ExternalSpreadsheetCompiler in the drools-decisiontables project (the test shows how it can be used). </div>
<div><br></div><div>IMO, I'd read around MarshallerFactory and Marshaller regarding serialisation of your KnowledgeSession. Ideally you might like to cache the KnowledgeBase itself, but I couldn't find much about serialising it... :-( </div>
<div><br></div><div>The Mortgage example in the examples-brms folder shows how you could load rules from Guvnor - although it looks a little out of date referencing RuleBase and the like rather than KnowledgeBase, but the principle is the same. </div>
<div><br></div><div>Hope this helps a little.</div><div><br></div><div>Mike</div><div><br><div class="gmail_quote">2010/9/16 Dean Whisnant <span dir="ltr"><<a href="mailto:dean@basys.com">dean@basys.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">Mike,</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">I am working on this project in phases. The initial phase
is to label all of my current logic as either core code, trading partner
specific code, or customer specific code. Once these three levels are
determined, we will be recreating standard versions of the first two in a rules
engine, perhaps all in one package. Then at each customer we will
implements a package that has their specific requirements.</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">Looking at your responses below I have more explaining to do.</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p><span style="font-size:11.0pt;color:#1F497D"><span>1)<span style="font:7.0pt "Times New Roman"">
</span></span></span><span style="font-size:11.0pt;color:#1F497D">We are considering pulling the standard code and trading partner
rules out into a cloud, off the customer’s site, so that we do not have
deployment issues that we have today. But we would allow the specific customer
rules to execute on their local server. So at a minimum I would need to do two
packages (one for the rules in the cloud and the second for the rules on their
server). Perhaps I still need to understand the relationship of a .drl
file to a package, though in my mind this is a 1 to 1 relationship.</span></p>
<p><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p><span style="font-size:11.0pt;color:#1F497D"><span>2)<span style="font:7.0pt "Times New Roman"">
</span></span></span><span style="font-size:11.0pt;color:#1F497D">I hear you on the responsibility part for giving our users the
ability to author their own rules in Guvnor. Thinking back to the last
three points in my original mail I’m really looking to balance which way
would be best to expose this to our customers (guvnor vs. DTs). Perhaps there
is more I need to understand about the limitations of each. If I
understood your response to #4 below it is that I would want to create one
decision table for a logical rule (whether that rule is one simple if then else
or it is a longer case statements). That being said, would I then have 40
spreadsheets for them to manage and change for the different logical
rules? How would that be from a performance standpoint? Is there a
process to take these 40 spreadsheets and convert them into one .drl file? Or are
they each then a .drl file? From a performance standpoint, are these
loaded from spreadsheet each time a user runs an EDI load? Or are they
made binary once (or whenever there are changes) and thus not having to “recompile”
each time?<br>
<br>
You might read from this that the idea of packaging for production is something
I’m still struggling to understand. If anyone has a good source to
show an example of actual distribution that would be cool. I’ve
been reading through the manuals and everything seems to stop with the examples
as being .java and .drl files.</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">Thank you for your assistance.</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">--Dean</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt">From:</span></b><span style="font-size:10.0pt">
<a href="mailto:rules-users-bounces@lists.jboss.org" target="_blank">rules-users-bounces@lists.jboss.org</a>
[mailto:<a href="mailto:rules-users-bounces@lists.jboss.org" target="_blank">rules-users-bounces@lists.jboss.org</a>] <b>On Behalf Of </b>Michael Anstis<br>
<b>Sent:</b> Thursday, September 16, 2010 11:40 AM<br>
<b>To:</b> Rules Users List<br>
<b>Subject:</b> Re: [rules-users] Looking for a place to start with drools</span></p>
</div><div><div></div><div class="h5">
<p class="MsoNormal"> </p>
<p class="MsoNormal">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?</p>
<div>
<div>
<p><span style="font-size:10.0pt">>> 1.</span><span style="font-size:7.0pt"> </span><span style="font-size:10.0pt">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.</span></p>
<p><span style="font-size:10.0pt">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. </span></p>
<p><span style="font-size:10.0pt">>> 2.</span><span style="font-size:7.0pt"> </span><span style="font-size:10.0pt">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?</span></p>
<p><span style="font-size:10.0pt">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..</span></p>
<p><span style="font-size:10.0pt">>> 3.</span><span style="font-size:7.0pt"> </span><span style="font-size:10.0pt">Within Guvnor, how
would you handle the possibility of there being over 2,000 fields to choose
from to form a rule? </span></p>
<p><span style="font-size:10.0pt">I believe
there is functionality in 5.1 for Working Sets that allow subsets of
fields\fact types to be exposed.</span></p>
<p><span style="font-size:10.0pt">>> 4.</span><span style="font-size:7.0pt"> </span><span style="font-size:10.0pt">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?</span></p>
<p><span style="font-size:10.0pt">One decision
table for all users at all customers? One DT per rule is normally the intent,
or did I misunderstand.</span></p>
</div>
<div>
<p class="MsoNormal">Good luck.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Mike </p>
</div>
<div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">On 16 September 2010 15:00, Gustavo Tenrreiro <<a href="mailto:gustavo@tenrreiro.com" target="_blank">gustavo@tenrreiro.com</a>> wrote:</p>
<p class="MsoNormal">Hi Dean,<br>
<br>
I ve only been working with Drools for about a couple of months.<br>
My first impression was that it was a great tool and very<br>
straightforward. But as I got deeper into it, I found a lot of<br>
gotchas, and things I didn't quite understand how they worked ( for<br>
many I still don't ). Finding definitive answers to those questions<br>
has been hard. Even though this forum, as well as the IRC chat are<br>
very helpful, the flow of information is somewhat limited.<br>
If what you are doing has some complexity beyond the simple examples<br>
provided by the documentation, and sample code, then you will probably<br>
get stuck at some point, and burn a lot of time trying to figure out<br>
the problem.<br>
<br>
So if you are on a tight budget that requires tight deadlines using<br>
Drools to replace your existing code would be a high risk proposition<br>
I believe.<br>
<br>
On the other hand, the Drools's potential to simplify, and streamline<br>
my system is great. if I manage to get it to do what I want it to do<br>
it would be a huge win for my organization, and the Drools system<br>
would be mostly responsible for that.<br>
<br>
So to summarise, jumping into the Drools bandwagon would be an<br>
"educated bet", but a bet nonetheless.<br>
<br>
Hope that helps.<br>
<br>
Thanks<br>
<br>
<br>
2010/9/16 Dean Whisnant <<a href="mailto:dean@basys.com" target="_blank">dean@basys.com</a>>:</p>
<div>
<div>
<p class="MsoNormal">> I am investigating using Drools for our company’s
EDI processing. The<br>
> nature of our software system is that each of our clients (dozens) has a<br>
> full distribution of our base software and in the past we would make
custom<br>
> changes to that base software at each of their sites based upon their<br>
> trading partners and business needs. For the most part these changes<br>
> involved nothing more than if-then statements for rather simple logic, but<br>
> that would become complicated at certain customers where there were large<br>
> numbers of trading partners and specific customer needs. In general
we saw<br>
> 2,000 lines of code swell to 4-6,000 lines of code.<br>
><br>
><br>
><br>
> We are in the process of rewriting this portion of our code and are<br>
> entertaining using drools to allow us to 1) create a standard ruleset, 2)<br>
> create a ruleset specific to a trading partner (many customers share some<br>
> common trading partners), and 3) create a customer business ruleset that<br>
> they can maintain through some GUI tool (Guvnor).<br>
><br>
><br>
><br>
> So far, I’ve created a sample java program that has classes
representing<br>
> some of our data files (UniData environment using uniobjects) and have
been<br>
> working with a single .drl file to test out general rules. I appear
to be<br>
> able to write just about any rule I’ve needed in the past with no
issues,<br>
> including rules that spawn processes within my native software.<br>
><br>
><br>
><br>
> These are my questions:<br>
><br>
><br>
><br>
> 1. How would you package these types
of rules? I have three<br>
> categories as stated above and it seems logical that I would package them
in<br>
> that manner. However within each group there are logical groupings
of<br>
> rules. In the customer rules I may have a couple dozen on how to
populate a<br>
> field that deals with adding comments and another couple dozen having to<br>
> deal with setting certain fields with specific codes that are based upon<br>
> incoming data. Two quite different logical areas within our
software.<br>
><br>
> 2. How would you deal with the GUI? Is
Guvnor truly something I can<br>
> setup in a way that my end users can manipulate without
“damaging” the<br>
> custom ruelset?<br>
><br>
> 3. Within Guvnor, how would you handle
the possibility of there being<br>
> over 2,000 fields to choose from to form a rule?<br>
><br>
> 4. What is the performance hit if we
were to make each customer rule<br>
> part of once decision table or another? Would you even consider this as an<br>
> option?<br>
><br>
><br>
><br>
> Thank you!<br>
><br>
><br>
><br>
> --Dean<br>
></p>
</div>
</div>
<p class="MsoNormal">> _______________________________________________<br>
> rules-users mailing list<br>
> <a href="mailto:rules-users@lists.jboss.org" target="_blank">rules-users@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
><br>
><br>
<br>
_______________________________________________<br>
rules-users mailing list<br>
<a href="mailto:rules-users@lists.jboss.org" target="_blank">rules-users@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a></p>
</div>
<p class="MsoNormal"> </p>
</div>
</div>
</div></div></div>
</div>
<br>_______________________________________________<br>
rules-users mailing list<br>
<a href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
<br></blockquote></div><br></div>