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> wrote:
Gents,
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,
while others are simply "filters".. Wolfgang's mention of "near
misses" is potentially a hot topic, I have been experimenting with
"imperfect" rules which
are more robust in that sense and provide better traceability, but that is not yet
implemented in the core engine.
I would also point out that one thing is monitor constraints for "logging" or
"auditing" purposes, another is the ability to specify different behaviours
(i.e. consequences) according to the success vs failure of an evaluation.
To this end, and following on the "extending" rule thread, it has actually been
planned and partially implemented.. it's only an experimental feature
(@Mario, any update/clarification?), so it's probably not well documented. But I
would point you to these links:
http://blog.athico.com/2012/09/conditional-branches-with-sub-blocks.html
https://community.jboss.org/wiki/BranchCEs
with the warning that it's still experimental and, while adopting
"familiar" keywords (if, then, else, switch), their semantics is different from
the
usual imperative language one, and in fact could enable some of the "extend"
capabilities that have been invoked in the last couple of posts.
Best
Davide
On 01/30/2013 02:25 PM, Cotton, Ben wrote:
>
>
> Ø 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).
>
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users