Excelent! Thanks for your input. I suppose separate KnowledgeBase-s are the best pattern in this scenario. I got the point, the the product identification is required since the rules are executed in the same space, no matter what package name is. This would complicate my rules a lot. When executing a KnowledgeBase with a single product that problem is not relevant. I thought about multi-channel and brand differences and that is one of the reasons I love drools. Eg. when there is a special discount for a broker X in channel Y all I have to do is to add additional file with rules that apply this change only. I organize rules in folders corresponding with packages.
I haven't thought about using RuleFlow yet :) I've also came to the conclusion that separating rules into many KnowledgeBases has an additional advantage, when a calculation for a single product fails for an unknown reason. It allows other calculations to finish their job. Bye, Bartosz Ross H wrote: > > Funny you should mention that, I have not got my head around packages yet. > Maybe it's just a namespace thing - I'm still learning. > > I think there may be two parts to this problem. How do your rules know > that > it is product x for the common customer information, I suppose you might > have the product id in the rules! Of course for future flexibility you > might > want to consider multi-brand, multi-channel differences in pricing as > well, > so that can complicate the picture. Even worse you might have to consider > date effective pricing and grandfathering of rules as the business changes > their pricing rules. > > So it depends yet again, if you want to get a set of prices from a single > set of customer info, you need to differentiate based on conditions. On > one > hand you could have a single KnowledgeBase with rules that have complex > conditions regarding product etc, or you can manage multiple > KnowledgeBases > and submit the same customer info to them to get your set of prices and > use > your app to manage this. > > Even more interesting is to have your pricing service route and transform > the customer information as necessary to call different KnowlegeBases > depending on the context. You could even use a RuleFlow to manage this for > you and use different ruleflow agendas. > > The problem with Drools is that it is just so flexible :-) > > In summary I'm probably in favour of separating out KnowledgeBases and > having the app know the context. This may result in some duplication but > gives a degree of flexibility for changes and independence and simplifies > your rulesets. > > Happy for others to shoot me down, so I can learn more too. > > On Mon, Dec 7, 2009 at 6:10 PM, Torfox <[email protected]> > wrote: > >> >> Hi Ross, >> >> Thank your for your response. >> >> Here is a wider context of my application. I'm implementing insurance >> premium comparison system. So the system applies the same fact (customer >> information) to many sets of rules. Every set of rules represents a >> single >> insurance product. The result of execution of every rule set is an object >> describing premium value and some calculation logs. By clearing the >> context >> I re-initiation of this resulting object in WorkingMemory, before the >> next >> set of rules is activated. I don't know yet if that kind of action is >> possible in drools - does drools execute rules package after package? I >> haven't found yet an explanation of package role in the rule execution >> process. >> >> Bye, >> Bartosz >> >> >> Ross H wrote: >> > >> > Hi Bartosz, >> > >> > I think the answer is "it depends", and that is in the context of the >> > application you are trying to develop. I don't quite understand your >> > statement about clearing the calculation context when the session is >> > stateless. >> > >> > Whichever approach, I would wrap it as a pricing service with business >> > methods, and then under the covers you can use whatever strategy you >> like >> > and change that without impacting your application. >> > >> > I'm also not sure if you are asking from a perspective of performance, >> so >> > is >> > it better to have number of smaller KnowledgeBases or one large one >> from >> a >> > memory/response aspect, and that depends on the number of rules, >> > complexity >> > of conditions, and of course your fact model. >> > >> > On the other hand if you want to manage the lifecycle of your products >> > independently (say the pricing rules change frequently), and as you say >> > the >> > rulesets are independent, then it might be better to have separate >> > KnowledgeBases from a management perspective. How do you deploy the >> rules, >> > embedded, Rule Agent, BRMS ... >> > >> > Maybe some more info on your solution space would help others to give >> you >> > a >> > better response. >> > >> > Regards Ross >> > >> > On Sun, Dec 6, 2009 at 7:43 PM, Torfox <[email protected]> >> > wrote: >> > >> >> >> >> Hi, >> >> >> >> I'm trying to achieve the following result. There are many rule sets, >> >> every >> >> set is responsible for insurance premium calculation and these sets >> are >> >> independent (every set applies to a single product). I have organized >> the >> >> rules into packages, where package identifies product. >> >> After calculation of every rule set I have a resulting object >> insurance >> >> premium and calculation log. >> >> >> >> What is the best pattern to execute those rules. E.g. can I put all >> >> packages >> >> into a single KnowledgeBase and execute StatelessKnowledgeSession >> >> providing >> >> that the last rule of every rule set clears the calculation context? >> >> Or is it better to create separate KnowledgeBase for every single >> >> product? >> >> >> >> Thanks for the hints. >> >> >> >> Bartosz >> >> -- >> >> View this message in context: >> >> http://n3.nabble.com/Multiple-packages-approach-tp69223p69223.html >> >> Sent from the Drools - User mailing list archive at Nabble.com. >> >> _______________________________________________ >> >> rules-users mailing list >> >> [email protected] >> >> https://lists.jboss.org/mailman/listinfo/rules-users >> >> >> > >> > _______________________________________________ >> > rules-users mailing list >> > [email protected] >> > https://lists.jboss.org/mailman/listinfo/rules-users >> > >> > >> >> -- >> View this message in context: >> http://n3.nabble.com/Multiple-packages-approach-tp69223p69839.html >> Sent from the Drools - User mailing list archive at Nabble.com. >> _______________________________________________ >> rules-users mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/rules-users >> > > _______________________________________________ > rules-users mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-users > > -- View this message in context: http://n3.nabble.com/Multiple-packages-approach-tp69223p69914.html Sent from the Drools - User mailing list archive at Nabble.com. _______________________________________________ rules-users mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-users
