[rules-users] Audit Logs: Business Case? Any pearls of wisdom?

[Vincent LEGENDRE]

I agree with Wolfgang on "it is common sense to have audit logs for a real application", and of course the way to do it with listeners. 

Most of time, for my experience, these logs (which rule has triggered, what are the changes made (insert, retract, update...) ...) are simply dumped in the main application log file, and follow the same life cycle (deleted after some fixed time). Except for some really critical application that needs a strong justification of their results (like something doing quotations, or computing salaries), I don't see the utility of keeping all audit for all transactions in a production evironnement. 
But for debug phase (and also users training phase), it is really useful. 

In your mail, I see two distincts questions : 
- Should you add in your system some audit functionnalities to log what happend somewhere : I would say yes 
- Should you keep all this stuff somewhere, and how to store and how to format these information : I would say that raw logging is enough for debugging, but not if you have other requirements (like giving access to this to non IT rules author, use the audit result in a automated alert system, do report on rules usage, being able to answer to claims for a long period of time ...). 


----- Mail original -----

De: "Wolfgang Laun" <wolfgang.laun at gmail.com> 
À: "Rules Users List" <rules-users at lists.jboss.org> 
Envoyé: Jeudi 9 Août 2012 20:31:29 
Objet: Re: [rules-users] Audit Logs: Business Case? Any pearls of wisdom? 

If you need to keep track of changes in your WM database, a property change 
listener is one solution. In addition with an AgendaEventListener listening to 
rules being fired you should be able to document what was done and by which 
rule. I'd say it is common sense to have this in a business application that 
uses rule to modify data. 

There are simpler scenarios such as validating or analyzing data where it 
might not be necessary (after testing). 

-W 


On 9 August 2012 20:14, BenjaminWolfe < benjamin.e.wolfe at gmail.com > wrote: 


Hello all, 

My company is just venturing into Drools, and I'd like to help make the 
endeavor as successful as possible. We'll be incorporating the rules engine 
into a broad range of use cases (depending on how successful the first few 
are, of course), with a wide range of business users, most of them using the 
Guvnor interface. 

It seems to me we'll want some sort of audit log in the form of a 
transaction-level table, simply to answer the question (in any given case, 
for any reason) of /what happened?/. On the other hand, a transaction-level 
table -- for a whole set of rules -- for a *lot* of facts (built up over 
time) -- could get pretty big. And our tech folks might not want to 
allocate resources to store and maintain the table. So I have a couple of 
questions for the more experienced Drools users: 

1. How might you build a solid business case for such logging? Do you have 
any specific examples of the problems an audit log would solve, or the 
benefits it would create? 
2. How common is it to keep audit logs? Do almost all of your projects 
include them, almost none, or somewhere in between? 
3. Maybe I'm missing some nuance. Do you include audit logs of some rules 
fired, in some applications, but not others? Any other nuggets of wisdom? 

Thanks everyone, 
Benjamin 



-- 
View this message in context: http://drools.46999.n3.nabble.com/Audit-Logs-Business-Case-Any-pearls-of-wisdom-tp4019073.html 
Sent from the Drools: User forum mailing list archive at Nabble.com. 
_______________________________________________ 
rules-users mailing list 
rules-users at lists.jboss.org 
https://lists.jboss.org/mailman/listinfo/rules-users 




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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20120810/91e7d10f/attachment.html