views:

188

answers:

7

Hi,

Something here doesn't feel right to me here, and so I would like the community's input - perhaps I am approaching this in the wrong way....

Q: Is is appropriate to use traditional infrastructure logging frameworks (like log4net) to log business events?

When I say business events, I mean I want a global log like this:

xx:xx Customer A purchased widget B.
xx:xx Widget B was dispatched from warehouse.
xx:xx Customer B payment declined.

Most traditional infrastructure logging frameworks have event levels something like this:

FATAL
ERROR
WARN
INFO
DEBUG

An of course these messages don't fit well into that. Best description would be INFO, but of course these are important events, and INFO is of very low importance.

I would still like this as a 'log' (e.g. I don't want to have to extract this from my business objects each time I want to see it)

Seems to me I have two options:

1) Use a framework like log4net and just define a special logger for this (and live with the fact that it doesn't feel right).

2) Provide a service for performing this that doesn't rely on a traditional logging services.

I'm leaning towards 2. What has anyone else done in a similar situations?

Thanks!

+1  A: 

These sound like the sorts of things that your customers might potentially want to query or report on from within your application - the obvious choice would be the database.

In particualr, in this case I'd feel like traditional logging frameworks wouldnt be suitable because when it comes to data that you might later want to access within your application logging frameworks allow you to do things that dont really make sense, for example you might be able to change where the logging is sent to based on the app.config file (which is unhelful if you try and read it from a different location).

That said, if a logging framework allows you to do exactly what you want already then there isnt any shame in just using the logging framework as your implementation and saving yourself the effort:

class TransactionLogger
{
    public void Log (Message message)
    {
        MyLoggingFramework.Log(message.string, etc...);
    }
}
Kragen
+1  A: 

Leave the logger for things having to do with the program, not the business. It is just a tool to help the developers.

Write your own system to log business events. If it is a business requirement to have a record, you will want something you have control over and you will need to use the logger above to keep track of how it works.

Basically, #2 in your question.

Eric Normand
+4  A: 

What you're wanting sounds like an auditing service, not a logging service. If I'm right, your goals are to keep track of these business events for historical and maybe even reporting purposes. You can use the details in the audit to, for lack of a better phrase, place blame for events that happen in the system.

I probably wouldn't use a logging system, like log4j, for this purpose. In our system, auditing is a first class citizen as a full service.

-- HTH, Dusty

dustyburwell
+1  A: 

To me the idea of a Business Event is that it plays a role in some future business processing, anything from actually triggering Business Actions to simply available for analytics.

Hence, completely different QOS requirements. needs its own API.

Conceviably initially that maps down to logging, but in future could go to reliable messaging or DB.

djna
A: 

In my experience business events comprise large or huge number of technical operations behind the scenes, with only certain business events being important to the business.

This creates problems when trying to use a generic logging methodology, so in general, in the systems I've worked on, both are used.
Logging for the technical aspects, and business event logging for the business events.

The business event logging, doesn't use the same technology as the technical logging, and instead logs to a custom designed history/audit table (Sometimes these are split, depending on the required detail), which is designed specifically for each application. (This keeps the auditors and users nice and happy.)

This allows easy reporting, and management of the information, while obviously expanding the scope of each specification slightly.

Bravax
A: 

you could use it but you need is business activity monitoring and event processing software. Off the top of my head, IBM WebSphere Business Monitor provides this capability. It processes Common Base Event (an IBM implementation of the Web Services Distributed Management Web Event Format standard) and then takes that data and create business activity dashboards.

Albert T. Wong
A: 

Check out DiALog: A Distributed Model for Capturing Provenance and Auditing Information, apart from the disbtributed aspect, you can use the subject-predicate-object principle to record the business events. And after wards reconstruct certain trails.

Holtkamp