Re: [rules-users] Audit Logs: Business Case? Any pearls of wisdom?
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" À: "Rules Users List" 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.wo...@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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
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 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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] Audit Logs: Business Case? Any pearls of wisdom?
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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
