I need to record the results of each of the conditions as a side effect in a list. But in case condition1 is false, condition2 would not be evaluated. This would prevent me from knowing whether or not condition2 was true/false. 5.8.3.3.12. Operator precedence at http://docs.jboss.org/drools/release/5.2.0.Final/drools-expert-docs/html/... lists & as an operator. But it somehow doesn't work. -- View this message in context: http://drools.46999.n3.nabble.com/Non-short-circuit-ANDing-tp4021928p4021... Sent from the Drools: User forum mailing list archive at Nabble.com.

Thanks Laune. I really appreciate the help. -- View this message in context: http://drools.46999.n3.nabble.com/Non-short-circuit-ANDing-tp4021928p4021... Sent from the Drools: User forum mailing list archive at Nabble.com.

This request turns up a lot. If you dig deeper into the Rete algorithm and examine how it works, you'll find that the node relations and redundancy elimination greatly abstracts away from what we think of as the LHS of a rule. In the node network, it's no longer a set of conditions grouped together for each rule that are checked for true/false collectively. I can't think of a way to accomplish this without severely impacting performance as I think you'd essentially end up evaluating all of your rules with a secondary algorithm. However, I only claim to know that I know very little, so grain of salt. On Wed, Jan 30, 2013 at 8:35 AM, Cotton, Ben <Ben.Cotton(a)morganstanley.com&gt;wrote:

Ø I can't think of a way to accomplish this without severely impacting performance as I think you'd essentially end up evaluating all of your rules with a secondary algorithm Agreed. Such a "when do rules fail to fire?" accounting capability should not be a burden to the Drools runtime. But what about a .DRL "enrichment " tool that generates explicit accounting .DRL code? Leaving the run-time unburdened, but liberating the .DRL author from all the key-stroke labor? Ø However, I only claim to know that I know very little, so grain of salt I don't even claim to know very little! (But do claim to be excited to "do the work" necessary to learn). From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Jeremy Ary Sent: Wednesday, January 30, 2013 9:57 AM To: Rules Users List Subject: Re: [rules-users] Non short circuit ANDing This request turns up a lot. If you dig deeper into the Rete algorithm and examine how it works, you'll find that the node relations and redundancy elimination greatly abstracts away from what we think of as the LHS of a rule. In the node network, it's no longer a set of conditions grouped together for each rule that are checked for true/false collectively. I can't think of a way to accomplish this without severely impacting performance as I think you'd essentially end up evaluating all of your rules with a secondary algorithm. However, I only claim to know that I know very little, so grain of salt. On Wed, Jan 30, 2013 at 8:35 AM, Cotton, Ben <Ben.Cotton@morganstanley.com<mailto:Ben.Cotton@morganstanley.com>> wrote: Would it be reasonable to suggest that the Drools team provide the user community with some tool, API, or other framework construct that might assist us when we are faced with this exact task? I mean, yes, what you suggest here works (and it works perfectly). But, for such an important and common user concern, we currently face a lot of "Drools .DRL keystroke labor" to get us completely where we need to be wrt to coding this tactic completely. Does your Intellifest white paper (today is the day? HOORAY!) comment at all on strategies to achieve this pattern in .DRL code? It would be way cool if the framework itself liberated us with a "just add water and out comes the .DRL code you want" capability. Such a capability would deliver to users a full answer wrt to our "when do rules fail to fire?" accounting needs. Admittedly, I don't know of a best way to proceed wrt to potentially providing that capability. But I do know it would be nice. As always, thank you very much for this forum's superb support. -----Original Message----- From: rules-users-bounces@lists.jboss.org<mailto:rules-users-bounces@lists.jboss.org> [mailto:rules-users-bounces@lists.jboss.org<mailto:rules-users-bounces@lists.jboss.org>] On Behalf Of Wolfgang Laun Sent: Tuesday, January 29, 2013 2:07 PM To: Rules Users List Subject: Re: [rules-users] Non short circuit ANDing [Groundhog Day] If you need to know all the reasons why a rule doesn't fire you'll have to evaluate all relevant conditions individually and keep track of the positives. (See a very recent thread on this list.) -W On 29/01/2013, mp <meitreyi.panchmia@morganstanley.com<mailto:meitreyi.panchmia@morganstanley.com>> wrote: > rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org _______________________________________________ rules-users mailing list rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ________________________________ NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing. _______________________________________________ rules-users mailing list rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users ________________________________ NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing.

Ø It's usually worth going back to basics and challenging the 'users' to define exactly what they're looking for It is challenging! And we greatly appreciate that this forum is a place for us to express our challenges and learn of all the best ways that we can find remedy. The main thing our very-newbie team of Drools end-users want to share with the Drools providers is that based on our understanding of this specific reality = Ø If you need to know all the reasons why a rule doesn't fire you'll have to evaluate all relevant conditions individually and keep track of the positives. We feel that we may be enduring a "burden" of having to physically re-factor and keystroke lots of .DRL code to get what we want (i.e. account for the answer "why do rules fail to fire?") within that reality. Our newbie (naïve?) suggestion to "enrich .DRL (with add'l code that evaluates all relevant conditions individually and keep track of the positives) via a tool" was just our "Thinking out loud". Thanks for the recommendation to consider working memory listeners - doing our homework on this right now. From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Stephen Masters Sent: Wednesday, January 30, 2013 1:28 PM To: Rules Users List Subject: Re: [rules-users] Non short circuit ANDing The requirement does seem to come up from business users who don't understand what's going on inside a rules engine. For instance, if I create a trade request for account 15, then should I be logging that the "Account 188 is permitted to trade USD" rule (and 100 other similar rules) didn't fire and that it was because the request wasn't for account 188? Once the knowledge base reaches any kind of realistic size, this kind of auditing becomes meaningless. To be honest, I rather thought that this was the role of working memory event listeners. Just create a listener to the facts your rule is interested in and you can log the values of the properties your rule looks at over time, and you can log which rules fired. If a rule does't fire, then you can see the state of all the facts in the working memory at that time. It's usually worth going back to basics and challenging the 'users' to define exactly what they're looking for in an audit, and work out the most appropriate way to achieve that. On 30 Jan 2013, at 15:22, "Cotton, Ben" <Ben.Cotton@morganstanley.com<mailto:Ben.Cotton@morganstanley.com>> wrote: Agreed. Such a "when do rules fail to fire?" accounting capability should not be a burden to the Drools runtime. But what about a .DRL "enrichment " tool that generates explicit accounting .DRL code? Leaving the run-time unburdened, but liberating the .DRL author from all the key-stroke labor? I don't even claim to know very little! (But do claim to be excited to "do the work" necessary to learn). From: rules-users-bounces@lists.jboss.org<mailto:rules-users-bounces@lists.jboss.org> [mailto:rules-users-bounces@lists.jboss.org<mailto:users-bounces@lists.jboss.org>] On Behalf Of Jeremy Ary Sent: Wednesday, January 30, 2013 9:57 AM To: Rules Users List Subject: Re: [rules-users] Non short circuit ANDing This request turns up a lot. If you dig deeper into the Rete algorithm and examine how it works, you'll find that the node relations and redundancy elimination greatly abstracts away from what we think of as the LHS of a rule. In the node network, it's no longer a set of conditions grouped together for each rule that are checked for true/false collectively. I can't think of a way to accomplish this without severely impacting performance as I think you'd essentially end up evaluating all of your rules with a secondary algorithm. However, I only claim to know that I know very little, so grain of salt. On Wed, Jan 30, 2013 at 8:35 AM, Cotton, Ben <Ben.Cotton@morganstanley.com<mailto:Ben.Cotton@morganstanley.com>> wrote: Would it be reasonable to suggest that the Drools team provide the user community with some tool, API, or other framework construct that might assist us when we are faced with this exact task? I mean, yes, what you suggest here works (and it works perfectly). But, for such an important and common user concern, we currently face a lot of "Drools .DRL keystroke labor" to get us completely where we need to be wrt to coding this tactic completely. Does your Intellifest white paper (today is the day? HOORAY!) comment at all on strategies to achieve this pattern in .DRL code? It would be way cool if the framework itself liberated us with a "just add water and out comes the .DRL code you want" capability. Such a capability would deliver to users a full answer wrt to our "when do rules fail to fire?" accounting needs. Admittedly, I don't know of a best way to proceed wrt to potentially providing that capability. But I do know it would be nice. As always, thank you very much for this forum's superb support. -----Original Message----- From: rules-users-bounces@lists.jboss.org<mailto:rules-users-bounces@lists.jboss.org> [mailto:rules-users-bounces@lists.jboss.org<mailto:rules-users-bounces@lists.jboss.org>] On Behalf Of Wolfgang Laun Sent: Tuesday, January 29, 2013 2:07 PM To: Rules Users List Subject: Re: [rules-users] Non short circuit ANDing [Groundhog Day] If you need to know all the reasons why a rule doesn't fire you'll have to evaluate all relevant conditions individually and keep track of the positives. (See a very recent thread on this list.) -W On 29/01/2013, mp <meitreyi.panchmia@morganstanley.com<mailto:meitreyi.panchmia@morganstanley.com>> wrote: > rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org _______________________________________________ rules-users mailing list rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ________________________________ NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing. _______________________________________________ rules-users mailing list rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users ________________________________ NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing. _______________________________________________ rules-users mailing list rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users ________________________________ NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing.

Ø automatically rename each rule "part" (being a single-condition rule derived from the original) to some derivation of the original rule name, and need the consequence only in the fully-extended rule, thereby giving the same effect, but with rule "parts" that would reflect failure at the individual condition level This is *exactly* the ambition we are hoping that some Drools .DRL enrichment tool (or other Drools capability) can provide. Wish I had sufficient competency to comment on the merits of your different suggested approaches. Hopeful that the Drools gurus will comment explicitly on all these approaches (and/or the approach suggested by another of using Working Memory listeners). From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Jeremy Ary Sent: Wednesday, January 30, 2013 4:01 PM To: Rules Users List Subject: Re: [rules-users] Non short circuit ANDing Have had this in the back of my mind most of the day...the more I think on it, the more I suspect that you could abuse extends on the multiple conditions, automatically rename each rule "part" (being a single-condition rule derived from the original) to some derivation of the original rule name, and need the consequence only in the fully-extended rule, thereby giving the same effect, but with rule "parts" that would reflect failure at the individual condition level. I've been mucking with a migraine since lunch, so it's possible that I'm off with my thought process, but I might run with this on the weekend if it passes group litmus...any thoughts? rule "foo is bar" when TypeA ( ) TypeB ( ) then log.info<http://log.info>("foo indeed bar'd"); end translate to: rule "foo is bar_1" when TypeA ( ) then end rule "foo is bar_2" extends "foo is bar_1" when TypeB ( ) then log.info<http://log.info>("foo indeed bar'd"); end or, to better reflect the agenda rule name of the original rule set: rule "foo is bar_1" when TypeA ( ) then end rule "foo is bar_2" extends "foo is bar_1" when TypeB ( ) then end rule "foo is bar" extends "foo is bar_2" when then log.info<http://log.info>("foo indeed bar'd"); end On Wed, Jan 30, 2013 at 12:48 PM, Cotton, Ben <Ben.Cotton@morganstanley.com<mailto:Ben.Cotton@morganstanley.com>> wrote: It is challenging! And we greatly appreciate that this forum is a place for us to express our challenges and learn of all the best ways that we can find remedy. The main thing our very-newbie team of Drools end-users want to share with the Drools providers is that based on our understanding of this specific reality = We feel that we may be enduring a "burden" of having to physically re-factor and keystroke lots of .DRL code to get what we want (i.e. account for the answer "why do rules fail to fire?") within that reality. Our newbie (naïve?) suggestion to "enrich .DRL (with add'l code that evaluates all relevant conditions individually and keep track of the positives) via a tool" was just our "Thinking out loud". Thanks for the recommendation to consider working memory listeners - doing our homework on this right now. From: rules-users-bounces@lists.jboss.org<mailto:rules-users-bounces@lists.jboss.org> [mailto:rules-users-bounces@lists.jboss.org<mailto:rules-users-bounces@lists.jboss.org>] On Behalf Of Stephen Masters Sent: Wednesday, January 30, 2013 1:28 PM To: Rules Users List Subject: Re: [rules-users] Non short circuit ANDing The requirement does seem to come up from business users who don't understand what's going on inside a rules engine. For instance, if I create a trade request for account 15, then should I be logging that the "Account 188 is permitted to trade USD" rule (and 100 other similar rules) didn't fire and that it was because the request wasn't for account 188? Once the knowledge base reaches any kind of realistic size, this kind of auditing becomes meaningless. To be honest, I rather thought that this was the role of working memory event listeners. Just create a listener to the facts your rule is interested in and you can log the values of the properties your rule looks at over time, and you can log which rules fired. If a rule does't fire, then you can see the state of all the facts in the working memory at that time. It's usually worth going back to basics and challenging the 'users' to define exactly what they're looking for in an audit, and work out the most appropriate way to achieve that. On 30 Jan 2013, at 15:22, "Cotton, Ben" <Ben.Cotton@morganstanley.com<mailto:Ben.Cotton@morganstanley.com>> wrote: Agreed. Such a "when do rules fail to fire?" accounting capability should not be a burden to the Drools runtime. But what about a .DRL "enrichment " tool that generates explicit accounting .DRL code? Leaving the run-time unburdened, but liberating the .DRL author from all the key-stroke labor? I don't even claim to know very little! (But do claim to be excited to "do the work" necessary to learn). From: rules-users-bounces@lists.jboss.org<mailto:rules-users-bounces@lists.jboss.org> [mailto:rules-<mailto:rules->users-bounces@lists.jboss.org<mailto:users-bounces@lists.jboss.org>] On Behalf Of Jeremy Ary Sent: Wednesday, January 30, 2013 9:57 AM To: Rules Users List Subject: Re: [rules-users] Non short circuit ANDing This request turns up a lot. If you dig deeper into the Rete algorithm and examine how it works, you'll find that the node relations and redundancy elimination greatly abstracts away from what we think of as the LHS of a rule. In the node network, it's no longer a set of conditions grouped together for each rule that are checked for true/false collectively. I can't think of a way to accomplish this without severely impacting performance as I think you'd essentially end up evaluating all of your rules with a secondary algorithm. However, I only claim to know that I know very little, so grain of salt. On Wed, Jan 30, 2013 at 8:35 AM, Cotton, Ben <Ben.Cotton@morganstanley.com<mailto:Ben.Cotton@morganstanley.com>> wrote: Would it be reasonable to suggest that the Drools team provide the user community with some tool, API, or other framework construct that might assist us when we are faced with this exact task? I mean, yes, what you suggest here works (and it works perfectly). But, for such an important and common user concern, we currently face a lot of "Drools .DRL keystroke labor" to get us completely where we need to be wrt to coding this tactic completely. Does your Intellifest white paper (today is the day? HOORAY!) comment at all on strategies to achieve this pattern in .DRL code? It would be way cool if the framework itself liberated us with a "just add water and out comes the .DRL code you want" capability. Such a capability would deliver to users a full answer wrt to our "when do rules fail to fire?" accounting needs. Admittedly, I don't know of a best way to proceed wrt to potentially providing that capability. But I do know it would be nice. As always, thank you very much for this forum's superb support. -----Original Message----- From: rules-users-bounces@lists.jboss.org<mailto:rules-users-bounces@lists.jboss.org> [mailto:rules-users-bounces@lists.jboss.org<mailto:rules-users-bounces@lists.jboss.org>] On Behalf Of Wolfgang Laun Sent: Tuesday, January 29, 2013 2:07 PM To: Rules Users List Subject: Re: [rules-users] Non short circuit ANDing [Groundhog Day] If you need to know all the reasons why a rule doesn't fire you'll have to evaluate all relevant conditions individually and keep track of the positives. (See a very recent thread on this list.) -W On 29/01/2013, mp <meitreyi.panchmia@morganstanley.com<mailto:meitreyi.panchmia@morganstanley.com>> wrote: > rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org _______________________________________________ rules-users mailing list rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ________________________________ NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing. _______________________________________________ rules-users mailing list rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users ________________________________ NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing. _______________________________________________ rules-users mailing list rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users ________________________________ NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing. _______________________________________________ rules-users mailing list rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users ________________________________ NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing.

fyi - if you're just learning your way around working memory event listeners and the like, here's some example code. It's an extended version of something I found in the Drools docs. A tracking working memory event listener: https://github.com/gratiartis/sctrcd-fx-web/blob/master/src/main/java/uk/... Attach it to your session to keep track of all facts as they are inserted/updated/retracted. It also supports filtering for fact classes or handles so that you can pick out which ones are relevant. A tracking agenda event listener: https://github.com/gratiartis/sctrcd-fx-web/blob/master/src/main/java/uk/... Keeps track of and logs every rule which fires. I use them in this test helper class, which enables me to create unit tests which assert that specific rules have fired or that specific facts are in working memory. https://github.com/gratiartis/sctrcd-fx-web/blob/master/src/main/java/uk/... Between those, you should be able to knock up something which does an appropriate audit of what's going on in your rules without refactoring any of your DRL. I prefer using listeners like this to monitor what's going on, as they don't intrude on your code. I tend to think that the rules should be simple and specific to the decision being made, rather than needing them to be written in a specific way in order to achieve some side effects. Steve On 31 Jan 2013, at 00:53, Davide Sottara <dsotty(a)gmail.com&gt; wrote:

Ø On Thu, Jan 31, 2013 at 3:49 AM, Stephen Masters <stephen.masters@me.com<mailto:stephen.masters@me.com>> wrote: Ø Ø Ø Ø Ø Cool. Thanks for the code. Thanks indeed Stephen. Another very-quick newbie question (sorry if I should have done the work to research the answer myself): Is it at all possible for listeners, once they have established that a rule has failed, to provide any higher resolution information that could potentially help answer the question "why did this rule fail?" - e.g. identify the specific L-value predicate participant that failed to match, etc.? -----Original Message----- From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Grant Rettke Sent: Thursday, January 31, 2013 10:10 AM To: Rules Users List Subject: Re: [rules-users] Non short circuit ANDing On Thu, Jan 31, 2013 at 3:49 AM, Stephen Masters <stephen.masters@me.com<mailto:stephen.masters@me.com>> wrote: Cool. Thanks for the code. The discussion has got me curious, here is the conclusion that I had made about rules engines: 1. Start with normal code. Write it in a way that lets you achieve your goal. Performance is not the primary focus. Work with the business do agile. Get all the auditing you want because it is just normal code. Life goes on. 2. Life is good but the performance is too slow. This is where you cut over to a RETE based rules engine. Does that sound right? _______________________________________________ rules-users mailing list rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/rules-users ________________________________ NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing.

Yep that's pretty much it. Your listener gets callbacks from the session whenever facts are inserted/updated/retracted or whenever rules activate. You can keep the audit logic in the listener, and let the business rules do business rule stuff. And you can pinpoint the rules or facts that you are really interested in. When a rule activates, you can get at all sorts of information about it. Just run through that class in a debugger to see what's available to you. If you grab that project, there are a number of unit tests you can fire off, and set breakpoints in the listeners. Unfortunately, when a rule doesn't activate, you don't get so much for free. You can iterate through your knowledge base to see what rules exist. You can subtract the rules which fired from those, to get a list of rules which did not fire. You can examine the facts which were in working memory at the time. So if you know what your rule's constraints are, then you can pick the relevant facts out and examine their values. What's not so easy is automatically matching up the LHS of a rule with the facts that might be relevant to it. I had a dig through it in the debugger, and unfortunately, as far as I could tell, by examining a rule, the properties holding the facts that would be matched on the LHS were all private. From what I understand, it might be possible to use Drools Verifier to build up a model matching rules to the constraints they are interested in, but I haven't had chance to have a good dig into that. If anybody knows the tools better than me, I'd love to hear of thoughts on how this might be achieved. Steve On 31 Jan 2013, at 16:11, "Cotton, Ben" <Ben.Cotton(a)morganstanley.com&gt; wrote:

On 1/30/2013 1:47 PM, Wolfgang Laun wrote: Hi Wolfgang, is this paper available? if so, what is the public URL? Many thanks. -Ben

Got it. Just did my first pass cursory read. BEAUTIFUL WORK Wolfgang. Starting my 2nd pass deep-dive right now with "2.4 Handling Failure to Match". I see here that you have outlined a strategy for Collecting failures (and matches). Exactly relevant to this discussion. :-) IMHO, this paper looks like it may be the ideal bridge for those of us looking to take the next step from the "Drools Expert" paper's elementary use-case samples towards using Drools technology to solve more challenging (indeed classic) problems (ShortestPath, Zebra Puzzle etc.) and to implement real-world application design patterns. Lots of "homework" to do here, so much to learn. THANK YOU WOLFGANG! -----Original Message----- From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Wolfgang Laun Sent: Thursday, January 31, 2013 5:10 AM To: Ben.Cotton(a)alumni.rutgers.edu; Rules Users List Subject: Re: [rules-users] Non short circuit ANDing You can find it on my homepage: http://members.inode.at/w.laun/ -W On 31/01/2013, Ben.Cotton(a)alumni.rutgers.edu <ben.cotton(a)morganstanley.com&gt; wrote: _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users -------------------------------------------------------------------------------- NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers. If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing.

On Wed, Jan 30, 2013 at 8:35 AM, Cotton, Ben <Ben.Cotton(a)morganstanley.com&gt; wrote: I'm studying rules engines. This desire seems to go 100% against the intent of a rules engine. That said, maybe what people want is some like a rules engine, but different, which more such features.

On Wed, Jan 30, 2013 at 9:13 AM, Cotton, Ben <Ben.Cotton(a)morganstanley.com&gt; wrote: Definitely there is value in it; I like the suggestions to do code generation or the like to transform it into rules that would give you what you want.

This is more or less the outline of the design pattern I propose in this situation. Asserting individual facts for each property that's in range might be too heavy (and cause more work when they all need to be collected); an additional Collection item in or associated with the fact under investigation would be more convenient. Red Hat reps promised the White Paper for today. We'll see... Otherwise I'll put it on my home page. [Threat, threat, ;-) ] -W On 30/01/2013, Grant Rettke <grettke(a)acm.org&gt; wrote: