What do you mean by "failed rule"? It has several possible interpretations... just to hint to some: a rule that throws an exception during its execution, possibly through chaining? For that, you can attach custom error handlers. Or, more likely, are you interested in the reason why a rule didn't fire? That is trickier: if you take the LHS of a rule as a boolean condition, the reason why it does not fire is because there are not enough facts matching ALL the conditions at the same time. The negation here is a potentially very complicated disjunction of possible cases. I.e. same as putting a "not" in front of the whole LHS. I don't think it's possible to monitor the RETE nodes directly to the point where you can see partial matches, which would rule out (no pun intended) sub-parts of the LHS and help you explain a missed activation.. justification is currently supported only for positive activations, through the associated Tuple and its LogicalDependencies. The closest approximation you can get is to attach workingmemory and agenda event listeners, and see which facts are asserted/retracted and which activations created/cancelled. The latter, in particular, might help you understand which rules were good candidates to fire but got "preempted" before they could be executed. I hope I didn't confuse you too much, but it would be appreciated if you could specify your question better :) Thanks, Davide -- View this message in context: http://drools.46999.n3.nabble.com/Anyway-to-get-Failed-Reason-for-Failed-... Sent from the Drools: User forum mailing list archive at Nabble.com.

Hi, you have several option then You can use drools-verifier for a static analysis of your rule base. In a nutshell, it converts the rules into "descriptor" facts and inserts them in a drools sessions, where you can apply some meta-rules. Drools verifier comes with a few consistency check rules, but you can add your own. You can attach listeners to the working memory and to the agenda: they will process events (in the java sense) which the engine generates as it processes data. You can use the "declarative agenda": every time a rule activation is created, it is insert in the workingmemory, where you can use rules to process it. Notice that, unlike drools verifier which works on rules ("offline"), this works on rule activations ("online"). This said, the concept of "failed condition" is quite debatable. Coming to your second question: when Drools evaluates the premise of a rule, it alternates select-like and join-like operations (I recommend you take a look at the RETE algorithm and the drools documentation). A premise can be matched or not, but the individual conditions that make up the patterns might be 1) satisfied, 2) violated, 3) not evaluated at all because other conditions make their evaluation not necessary. Moreover, one might consider differently rules which MUST fail - e.g. Person( age < 10 && > 20 ) - from rules which MUST succeed - e.g. Object() - from "normal" rules which might or might not fail, but that will depend heavily on your facts. My gut feeling, without knowing your precise requirements, is as this: if you need to check the consistency of a rule base, try verifier. if you want to optimize a rule base (e.g. give priorities to rules which are used more often, remove unused ones etc), use the declarative agenda or the listeners and monitor the runtime execution. If you have critical conditions in your data that you must evaluate, use explicit positive and negative conditions: "when Person( age < 18 ) then A", "when Patient( age >= 18) then B" (or, with a slightly different semantics, "not Patient( age < 18 )" ) Davide -- View this message in context: http://drools.46999.n3.nabble.com/Anyway-to-get-Failed-Reason-for-Failed-... Sent from the Drools: User forum mailing list archive at Nabble.com.

For a simplified scenario, it is easily possible to determine which rules fire and which don't. This scenario assumes that you have - a set of rules - some static facts (which may be modified in the process or not) - one transactional fact and the simple sequence kSession.insert( transFact ); kSession.fireAllRules(); repeated for each fact. Set up an agenda event listener and register which rules fired - all the others did not. Analysing why some fact does not trigger a rule R is much more complex than rule R itself. Consider: rule R constrains n properties, and each of these values can be out of the "hot" range. Lets say we are investigating boxes with height, width, depth, colour, material, and weight. When your rule looks for h>10, w>20, d>5, colour == RED, material == WOOD, weight < 100 then you have 6 individual possibilities for this rule to fire. If you really need to have a detailed analysis you will have to redesign your rule base with individual rules checking individual properties, one rule each for width, height, depth, colour, material and weight. Each of these rules would add a property (WIDTH_OK, HEIGHT_OK,... WEIGHT_OK) to the investigated box. Then, at the end of the firings you look at the collected properties and can determine what is there and what isn't. If it is the full set, you have a matching box; otherwise the missing properties tell you what prohibited a full match. (Again, this assumes that you are investigating one transactional fact at a time.) Of course it will get even more complicated if you need to investigate combinations of facts, but I think it can be done, but it'll need some extensive work. -W On 09/08/2012, Rana <ven12344(a)yahoo.com&gt; wrote:

Hi there, Just a minor remark. If you prefer this way of working, do not add the log as a Fact. Add it as a global. Otherwise, it would clutter the rete tree and slow down the execution. Unless you want to use the RuleLog to control the further execution, that is. Regards, Frank jasonxzhong wrote -- View this message in context: http://drools.46999.n3.nabble.com/Anyway-to-get-Failed-Reason-for-Failed-... Sent from the Drools: User forum mailing list archive at Nabble.com.