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

Mike, 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. Looking at your responses below I have more explaining to do. 1) 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. 2) 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? 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. Thank you for your assistance. --Dean From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Michael Anstis Sent: Thursday, September 16, 2010 11:40 AM To: Rules Users List Subject: Re: [rules-users] Looking for a place to start with drools 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? 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. 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.. I believe there is functionality in 5.1 for Working Sets that allow subsets of fields\fact types to be exposed. 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@tenrreiro.com<mailto:gustavo@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@basys.com<mailto:dean@basys.com>>: _______________________________________________ rules-users mailing list rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/rules-users