Davide, Thanks for the suggestions. I was considering using the MetaData as well, since it allows both evaluation on the LHS (just like the example you have) as well as on the RHS where I can get the MetaData through code and use it in the application. And like you have suggested I can use dedicated Fact Types for the RHS, the requirement for us is also for our business users to be able to set these attributes/properties when creating or updating a rule in Guvnor, so having a predefined list (attribute name as well as the values) to choose from makes it easier and error free, and since its not possible with MetaData I was wondering if there is another way to achieve this with Custom Attributes. Also thanks for the heads up on "Rule Overridability" features being added. The current scenario I was trying to solve is where certain rule would generate a Hard Stop for the application process (Non Overridable), while others would generate a Confirmation message for the users to acknowledge and continue or to abandon processing (Overridable). And since all rules in our environment have to set this property I was wondering if we could do this with a Custom Attribute that could be set by the rule (only when it fires) and evaluated in the application to determine the course of action to take. Again thanks for your response, and I now understand the options available. dme -- View this message in context: http://drools.46999.n3.nabble.com/Cutom-Attributes-in-Drools-tp4019692p40... Sent from the Drools: User forum mailing list archive at Nabble.com.

It is not a myth ... but indeed, it's hard. Most of times, you have to find one guy at client's side who is ready to learn at least the main principles of expert-systems. For my experience, it works well enough (ie most of rules dev time is done by the BA) in about 1 proj out of 3. For the others, an IT guy is still needed to help the BA (which is something doable if you have enough rules to author). DSL are hard to set, and harder to maintain, especially while using guvnor (using DSL in a dsrl rule is fine, but dsrl rules for non-IT guys is a myth). Usually I try as much as I can to set a business-compliant POJO model (ie simple, almost flat, with fields named in a way they understand what is behind) and no DSL at all... For the rules' firing control, it is harder ... @dme1 : May be you can think on an agenda filter that looks for the rule's package ? Or use "category rules", which is a rule binded to a category, which acts as a parent rule for all rules under this category (so all rules of the same category will have the same common first conditions, which can be the test of your control fact). But beware of that, there was a bug on sub-categories, or when a rule has more than one category (one the first category is taken if I remember well). A last thing could be to use verifier to ensure that all rules have a first condition that test the control fact . @GPatel : your approach sounds great. How much time did you spent to write such a Guvnor alternative ? ----- Mail original ----- De: GPatel(a)tsys.com À: "Rules Users List" <rules-users(a)lists.jboss.org&gt; Envoyé: Jeudi 13 Septembre 2012 18:47:52 Objet: Re: [rules-users] Cutom Attributes in Drools " I would not store the result of the (missed) activation of a rule in a rule attribute, anyway. Can't you just use a dedicated fact(s) for that?" I face a similar issue where the target audience are "business" users i.e users that dont really understanding or wish to get into logic. I am finding myself having to resort to all sorts of tricks (using categories/packages/standlone rule editor) to allow business users to easily specify which rules are for what purposes and when they should fire. I just cant rely on them using facts correctly to disable rules that should not fire. In fact, I am now down to using only the standalone editor and saving the rule xml in my tables (not guvnor) so that i have full control over itemized rule display, rule search, knowledgebase creation for different execution profiles, etc. Overall, I increasingly tend to think rules for business users is a myth. The business users wants rule-driven systems, yet they dont want to learn drools. And drools DSL just doesnt cut it. From: Davide Sottara <dsotty(a)gmail.com&gt; To: rules-users(a)lists.jboss.org, Date: 09/13/2012 01:57 AM Subject: Re: [rules-users] Cutom Attributes in Drools Sent by: rules-users-bounces(a)lists.jboss.org You can add any metadata using the format @name( "value" ) or @name( key=value ). You can then look them up using rule.getMetaData(). Please notice that there's a bug (solved by an open pull request) that does not let you write just @name. In order to use those attributes to control whether a rule fires or not, you can use the "declarative agenda", i.e. add meta-rules to your knowledge base such as: rule "Meta" @activationListener('direct') when // assuming the attribute is @region( [value] ) $a : Activation( rule.metaData[ "name" ] != "MyDesiredRegion", $objs : objects ) // any condition on the tuple here, if needed then drools.cancelActivation( $a ); end notice that you'll have to enable the corresponding option first: KnowledgeBaseConfiguration kconf = KnowledgeBaseFactory.newKnowledgeBaseConfiguration(); kconf.setOption( DeclarativeAgendaOption.ENABLED ); KnowledgeBase kb = KnowledgeBaseFactory.newKnowledgeBase( kconf ); If you want to have rules override each other, watch out for an upcoming feature, "Defeasible logic". I would not store the result of the (missed) activation of a rule in a rule attribute, anyway. Can't you just use a dedicated fact(s) for that? Best Davide -- View this message in context: http://drools.46999.n3.nabble.com/Cutom-Attributes-in-Drools-tp4019692p40... Sent from the Drools: User forum mailing list archive at Nabble.com. _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ----------------------------------------- The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

The feature is being implemented even now, I will make available incrementally over the next 10 days or so, unless I get preempted by too many other matters :) As you may know, I'm not part of the Drools team so I am not working 100% on this. It may take some more time to document and release it officially, but I can show you the principles once it's in place - and of course it really fits your requirements! It would be invaluable if you could provide some toy, deintified test cases to show your expected behavior. I'd like to better understand what kind of ovverrides you need exactly - and btw I'm struggling a bit to understand what you mean with "choice between multiple elements LHS and RHS"... Thanks Davide -- View this message in context: http://drools.46999.n3.nabble.com/Cutom-Attributes-in-Drools-tp4019692p40... Sent from the Drools: User forum mailing list archive at Nabble.com.

Hi, this is definitely something in scope for the type of "Defeasible rules" i'm working on right now. I have just one last question: do you need the second rule to override the activation of the first, or do you need the VALUE set by the second rule to override the value set by the first? In your example, the effect would be the same, but let me show two other examples: (Also please notice the currently proposed metadata) Example #1 rule "High" @Defeasible @Cuts( "Low" ) when $p : Person( age > 25 ) then $p.setPolicyType( "A" ); *log( "A policy" );* end rule "Low" @Defeasible when $p : Person( age > 25 ) then $p.setPolicyType( "B" ); log( "B policy" ); end If you just override the values, you'll see TWO logs and $p.policyType == "A". If you override the activations, only the consequence of "High" will fire. The attributes here would override the activations: notice that, unlike salience, the activation of High will prevent the activation of Low altogether Example #2 : rule "High" @Defeasible @Defeats( "Low" ) when $p : Person( age > 25 ) $c : Car( color == "red" ) then $p.setPolicyType_Logical( "A" ); // syntax to be determined yet! end rule "Low" @Defeasible when $p : Person( age > 25 ) then $p.setPolicyType_Logical( "B" ); end In this case, the override would be at the value level: unlike salience or the previous example, here the TMS will keep track of both attempts at setting the policy type value. This means that the policyType will be "A" BUT, should e.g. the Car be retracted, the policyType will automatically be modified to "B" since now that unblocked "set" would support the value. (This case will actually require some more time to support) Davide -- View this message in context: http://drools.46999.n3.nabble.com/Cutom-Attributes-in-Drools-tp4019692p40... Sent from the Drools: User forum mailing list archive at Nabble.com.

Thank you for reporting this user experience... and I think this is of interest for other users too. I would address your problem at different levels.. You basically are asking for a more declarative approach to writing business rules, and that is perfectly understandable. The DRL rules are "technical" rules and are somewhat in between a purely declarative language and a programming language. This said, "rules should fire or not depending on the context": if that context is part of the business logic, i.e. lives at the same level of the other preconditions, it should be added to the premises of the rules, and now the problem is finding a better language for your knowledge engineers to model business rules. If instead the logic can be understood to be a "meta-level" logic, so that you'd have to create "innatural" auxiliary control facts, you could possibly explore the meta-rule approach I outlined in my previous comment. Of course, this still suffers from the same technicality issue, but the rules would be written by the business users and the meta rules by the technical ones... (btw The reason for not updating metadata is that they are defined statically at the rule level, whereas you would actually be interested in the activations! and this is quite different) Also remember that Drools is community driven: if you think that there is some missing feature, please submit a proposal (e.g. would something like SBVR be more suitable for you?), maybe others will join you in supporting that. A "critical mass" may help to get it done, and of course you can help and contribute :) -- View this message in context: http://drools.46999.n3.nabble.com/Cutom-Attributes-in-Drools-tp4019692p40... Sent from the Drools: User forum mailing list archive at Nabble.com.