@plugtreelabs: First of all, thank you very much for your response and hints. @all: As I'm still not quire sure how to realize my scenario: Please, could someone provide me with some diagrams or architectural sketches of a typical rules-based e-commerce web application? -- Or at least point me to online resources on that topic, especially showing the integration of the RBMS in a web app? This would really help me out a lot at the moment. _Recap: The main goal is that endusers shall, on the one hand, define almost the whole set of entities and rules in an initial shop specification/configuration process, and on the other hand, this set shall be modifiable later on (primarily through enhancements, not restrictions). The entity set basically is: customer types, product categories, products, product packages, customer(type)-to-product(type) price assignments (i.e. pricing rules), and inter-product/package selection rules, ...all of these dynamically definable via a WebUI and in a manner appropriate for non-technical end-users (considering declarative programming a good approach for this(?)). The most dynamic parts will be the multi-dimensional pricing tables in terms of (a) their schema -- when new pricing parameters (=dimensions) like delivery distance are added -- and (b) their value contents -- when concrete prices change. Another quite dynamic part will be the inter-product selection rule specifications from which a "smart" e-catalog will be generated for the client-side. Such rules will state sth. like: "Prod A must always be ordered with Prod B", "Prod B can never be ordered when Package C is selected", and similar. -- Currently, some "high-level architectural layouts" of a simple, rules-based e-commerce web app (Which components are necessary in which place? And which components are already delivered by Drools?) would be very helpful for me. Thank you very much for your help in advance. Best regards Sebastien -- View this message in context: http://drools-java-rules-engine.46999.n3.nabble.com/Is-Drools-appropriate... Sent from the Drools - User mailing list archive at Nabble.com.

Sebastien, I have built an e-commerce site [www.stoneside.com] with some if not all of the things you are talking about. If you go there and design a product you can see the rules working. Drools is being used for: Pricing rules and discounts within a product. Rules regarding what components of a product can exist with other components. [the end-user is custom designing something to purchase] Rules determine how to display the product as the end-user designs their product. Rules generate the BOM once the user ultimately orders the product that they designed. All the rules are managed using excel spreadsheet templates. We [the developers] defined the templates and the business enters the rules into the spreadsheet. This has worked pretty well. The biggest hurdle being defining the templates correctly and populating the initial sets of rules. Some of the more complex products have at least 5K rules [across all 4 areas of rules] that needed to be defined. So, I think it is appropriate for your app scenario. You will need to think about what you need as rules and what those rule 'templates' need to look like. Jeff -----Original Message----- From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Sebastien Chevalier Sent: Wednesday, January 26, 2011 6:28 AM To: rules-users(a)lists.jboss.org Subject: Re: [rules-users] Is Drools appropriate for this app scenario? @plugtreelabs: First of all, thank you very much for your response and hints. @all: As I'm still not quire sure how to realize my scenario: Please, could someone provide me with some diagrams or architectural sketches of a typical rules-based e-commerce web application? -- Or at least point me to online resources on that topic, especially showing the integration of the RBMS in a web app? This would really help me out a lot at the moment. _Recap: The main goal is that endusers shall, on the one hand, define almost the whole set of entities and rules in an initial shop specification/configuration process, and on the other hand, this set shall be modifiable later on (primarily through enhancements, not restrictions). The entity set basically is: customer types, product categories, products, product packages, customer(type)-to-product(type) price assignments (i.e. pricing rules), and inter-product/package selection rules, ...all of these dynamically definable via a WebUI and in a manner appropriate for non-technical end-users (considering declarative programming a good approach for this(?)). The most dynamic parts will be the multi-dimensional pricing tables in terms of (a) their schema -- when new pricing parameters (=dimensions) like delivery distance are added -- and (b) their value contents -- when concrete prices change. Another quite dynamic part will be the inter-product selection rule specifications from which a "smart" e-catalog will be generated for the client-side. Such rules will state sth. like: "Prod A must always be ordered with Prod B", "Prod B can never be ordered when Package C is selected", and similar. -- Currently, some "high-level architectural layouts" of a simple, rules-based e-commerce web app (Which components are necessary in which place? And which components are already delivered by Drools?) would be very helpful for me. Thank you very much for your help in advance. Best regards Sebastien -- View this message in context: http://drools-java-rules-engine.46999.n3.nabble.com/Is-Drools-appropriat e-for-this-app-scenario-tp2303204p2353169.html Sent from the Drools - User mailing list archive at Nabble.com. _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

Yes, the site is pure java. UI is done with Wicket, DB is done via hibernate, Rules - drools core and guvnor. 1) As I said in my original email, the shop owner UI was realized by excel spreadsheet templates. The Guvnor allows rules to be written via an excel file template. Ideally, it would be a GUI based app but the spreadsheets work and are more cost effective in this case. The spreadsheets can also be moved around to different systems [dev, test, staging, production] and allow rules to be written disconnected from the web. 2a) not sure what you are asking 2b) We have the following rule types: Pricing - computes price for a product based on configuration Configuration - rules which tell which option is required, default values for options, and when a particular option or value is not available based on other configuration choices BOM - based on the configuration generate a BOM Presentation - only used to determine how to display the picture of the configured product. All these rules are in our service tier. The presentation tier knows nothing about the rules and just knows what to present to the user. 3) Our rules are pretty simple. A bunch of when clauses and a few consequence clauses. There are not too many rules which cause other rules to fire since we only allow the user to select valid choices in the UI. The default value rules do cause a cascade of firing and these are always run first and only run if a default value needs to be set. 4) We do not use rules for entity metadata definition. We certainly could have but we maintain that via a database and a front-end GUI app. This is not something that can be done in a couple of weeks. The UI, rules, etc... took months [and more months] to develop. There were lots of refactoring of code and rules to get it right. Let me know [off-line] if you need more information or want to discuss specific information. Jeff -----Original Message----- From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Sebastien Chevalier Sent: Thursday, January 27, 2011 8:10 AM To: rules-users(a)lists.jboss.org Subject: Re: [rules-users] Is Drools appropriate for this app scenario? Dear Jeff: First, thank you very much for your quick reply. Concerning your StoneSide shop, yes indeed this is pretty much the functionality that I target, and it is a proof that it works well for a *web* app. If I got it right, you used a pure *server*-centric rules-based architecture based on Java, Drools (Expert, Guvnor(?)) and Wicket, right? (1) ...But, how did you realize the shop owner UI, the one where (s)he can define the rules? Is it a web interface too, probably reusing Guvnor components, or a separate stand-alone app? Relative to the internal architecture: (2) Could you please give me some more hints on which arch components are working under the covers? -- Especially: (2a) Which top-level components are used and which interface type do they provide? (2b) Which rule "types" must be in place? (please, see next paragraph for details) I suppose that, following a layered architecture, you'll need rules at every of the arch layers, most obviously "data/entity based rules" and "presentation based rules". Less obvious to me is, if actually necessary (?), the "data-to-presentation mapping mechanism" which extracts facts from the data layer and places the required artifacts onto the presentation, probably having also some rules for injecting custom presentation and/or collection/storage behavior into the components (i.e., rules in the controller layer). Are these assumptions correct? (3) How do your rules (rule types) typically look like, and how work they together (map on each other)??? (4) Do you also use rules for "entity metadata definition" (i.e., dyn. compositions of entity types from predefined property components)? I'd really be very grateful for the clarification of these issues and/or any further-helping descriptions. Thank (all of) you very much in advance. Best regards Sebastien -- View this message in context: http://drools-java-rules-engine.46999.n3.nabble.com/Is-Drools-appropriat e-for-this-app-scenario-tp2303204p2362526.html Sent from the Drools - User mailing list archive at Nabble.com. _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users