Ø
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@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("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("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("foo indeed bar'd");
end
On Wed, Jan 30, 2013 at 12:48 PM, Cotton, Ben <Ben.Cotton@morganstanley.com> wrote:
Ø
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@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> 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@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> wrote:
> you'll have to evaluate all relevant conditions individually and keep track of the positives
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]
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> wrote:
> 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/ht
> ml/ch05.html#d0e3962 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-tp4021928p4
> 021931.html Sent from the Drools: User forum mailing list archive at
> Nabble.com.
> _______________________________________________
> rules-users mailing list
> https://lists.jboss.org/mailman/listinfo/rules-users
>
_______________________________________________
rules-users mailing list
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
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
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
https://lists.jboss.org/mailman/listinfo/rules-users