<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>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.</div><div><br></div><div>A tracking working memory event listener:</div><div><a href="https://github.com/gratiartis/sctrcd-fx-web/blob/master/src/main/java/uk/co/scattercode/drools/util/TrackingWorkingMemoryEventListener.java">https://github.com/gratiartis/sctrcd-fx-web/blob/master/src/main/java/uk/co/scattercode/drools/util/TrackingWorkingMemoryEventListener.java</a></div><div>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.</div><div><br></div><div>A tracking agenda event listener:</div><div><a href="https://github.com/gratiartis/sctrcd-fx-web/blob/master/src/main/java/uk/co/scattercode/drools/util/TrackingAgendaEventListener.java">https://github.com/gratiartis/sctrcd-fx-web/blob/master/src/main/java/uk/co/scattercode/drools/util/TrackingAgendaEventListener.java</a></div><div>Keeps track of and logs every rule which fires.</div><div><br></div><div>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.</div><div><a href="https://github.com/gratiartis/sctrcd-fx-web/blob/master/src/main/java/uk/co/scattercode/drools/util/DroolsTestUtil.java">https://github.com/gratiartis/sctrcd-fx-web/blob/master/src/main/java/uk/co/scattercode/drools/util/DroolsTestUtil.java</a></div><div><br></div><div><br></div><div>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.</div><div><br></div><div>Steve</div><div><br></div><div><br></div><br><div><div>On 31 Jan 2013, at 00:53, Davide Sottara <<a href="mailto:dsotty@gmail.com">dsotty@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
<div bgcolor="#ffffff" text="#000000">
Gents, <br>
this is a really interesting discussion and I wish I had more time
to participate.. I agree with Stephen that some constraints are
really worthy monitoring, <br>
while others are simply "filters".. Wolfgang's mention of "near
misses" is potentially a hot topic, I have been experimenting with
"imperfect" rules which<br>
are more robust in that sense and provide better traceability, but
that is not yet implemented in the core engine. <br>
I would also point out that one thing is monitor constraints for
"logging" or "auditing" purposes, another is the ability to specify
different behaviours<br>
(i.e. consequences) according to the success vs failure of an
evaluation. <br>
To this end, and following on the "extending" rule thread, it has
actually been planned and partially implemented.. it's only an
experimental feature<br>
(@Mario, any update/clarification?), so it's probably not well
documented. But I would point you to these links:<br>
<br>
<a href="http://blog.athico.com/2012/09/conditional-branches-with-sub-blocks.html">http://blog.athico.com/2012/09/conditional-branches-with-sub-blocks.html</a><br>
<br>
<a class="moz-txt-link-freetext" href="https://community.jboss.org/wiki/BranchCEs">https://community.jboss.org/wiki/BranchCEs</a><br>
<br>
with the warning that it's still experimental and, while adopting
"familiar" keywords (if, then, else, switch), their semantics is
different from the <br>
usual imperative language one, and in fact could enable some of the
"extend" capabilities that have been invoked in the last couple of
posts.<br>
<br>
Best<br>
Davide<br>
<br>
<br>
On 01/30/2013 02:25 PM, Cotton, Ben wrote:
<blockquote cite="mid:0B95B3331313694FB86A196AA780A93DA9D23E@RRWEX2014N2.msad.ms.com" type="cite">
<!-- Template generated by Exclaimer Template Editor on 04:25:40 Wednesday, 30 January 2013 -->
<style type="text/css">P.2ee1cc27-72fd-41ad-a721-72d082ea8444 {
MARGIN: 0cm 0cm 0pt
}
LI.2ee1cc27-72fd-41ad-a721-72d082ea8444 {
MARGIN: 0cm 0cm 0pt
}
DIV.2ee1cc27-72fd-41ad-a721-72d082ea8444 {
MARGIN: 0cm 0cm 0pt
}
TABLE.2ee1cc27-72fd-41ad-a721-72d082ea8444Table {
MARGIN: 0cm 0cm 0pt
}
DIV.Section1 {
page: Section1
}
</style>
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<meta name="Generator" content="Microsoft Word 12 (filtered
medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]-->
<style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"Lucida Console";
panose-1:2 11 6 9 4 5 4 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1447770610;
mso-list-type:hybrid;
mso-list-template-ids:1210846478 1670531890 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:16;
mso-level-number-format:bullet;
mso-level-text:\F0D8;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;
mso-fareast-font-family:Calibri;
mso-bidi-font-family:"Times New Roman";}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--><div>
<br class="webkit-block-placeholder"></div>
<div class="WordSection1"><p class="MsoListParagraph" style="text-indent: -0.25in;"><!--[if !supportLists]--><span style="font-size: 14pt; font-family: Wingdings; color:
rgb(31, 73, 125);"><span style="">Ø<span style="font: 7pt
"Times New Roman";">
</span></span></span><!--[endif]--><span style="font-family: "Lucida Console";">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</span><span style="font-size:
14pt; font-family: "Lucida Console"; color:
rgb(31, 73, 125);"><o:p></o:p></span></p><p class="MsoNormal"><span style="font-size: 14pt; font-family:
"Calibri","sans-serif"; color: rgb(31,
73, 125);"><br>
</span></p><p class="MsoNormal"><span style="font-size: 14pt; font-family:
"Calibri","sans-serif"; color: rgb(31,
73, 125);">This is *<b>exactly</b>* the ambition we are
hoping that some Drools .DRL enrichment tool (or other
Drools capability) can provide.
<o:p></o:p></span></p><p class="MsoNormal"><span style="font-size: 14pt; font-family:
"Calibri","sans-serif"; color: rgb(31,
73, 125);"> </span></p><p class="MsoNormal"><span style="font-size: 14pt; font-family:
"Calibri","sans-serif"; color: rgb(31,
73, 125);">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).<o:p></o:p></span></p><p class="MsoNormal"><span style="font-size: 14pt;"> </span></p>
<span style="font-size: 14pt;"></span><o:p></o:p>
<div>
<div>
<div>
<div><div style=""> <br class="webkit-block-placeholder"></div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
_______________________________________________<br>rules-users mailing list<br><a href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/rules-users<br></blockquote></div><br></body></html>