Re: [rules-users] Anyway to get Failed Reason for Failed Rule?

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: