[rules-users] Tracking non-matches...

[Michael Rhoden]

Store all rules with a unique id (rule id) and keep dates of when rules 
were put in/out of production. Store your net matches in a database, 
after a run, and you can easily pull the delta to show what didn't 
"match" on a particular day. 

-Michael

-----Original Message-----
From: rules-users-bounces at lists.jboss.org 
[mailto:rules-users-bounces at lists.jboss.org] On Behalf Of jdepaul
Sent: Tuesday, April 17, 2007 1:57 PM
To: rules-users at lists.jboss.org
Subject: [rules-users] Tracking non-matches...


I was hoping for some opinions on the following:

Client will have many rules (about 1000) per RuleBase.  The primary goal 
is to assert Facts and find Matches in one or more rules.  The secondary 
goal may be to keep track of those Facts that did not produce Matches.  
I was wondering what the best solution may be in this case?!

The benefit in keeping track of the non-matches would be periodic 
analysis of the non-matches to discover patterns and perhaps provide 
some proactive
monitoring and notification.   An additional benefit may be to spot a 
trend
and setup additional rules to reduce the number of non-matches.  

So I would need to not only spot the no-match condition, I also need to 
persist the no-match event in the database for tracking and later 
reporting.

One way I can see is to assert a new Match fact the instance a single 
rule is matched and then test for the presence/absence of the Match() 
fact. 
Efficiency and speed are paramount in our case, so I'm wondering if 
there is an alternate approach that would work here.

Thanks,
James


--
View this message in context: 
http://www.nabble.com/Tracking-non-matches...-tf3596042.html#a10044235
Sent from the drools - user mailing list archive at Nabble.com.

_______________________________________________
rules-users mailing list
rules-users at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users