I am pretty sure I read on this forum (or was it in JIRA?) that full audit trial capability is planned for a future release. I think many of us are anxiously awaiting it.
Depending on what you want to audit, you could e.g. use AOP and intercept all calls to the database as your audit trial. Might not be that easy to do, but very complete.
What I have done in the past, is configure a <history-sessions> in the jbpm.cfg.xml file, a Java class that implements HistorySession. This way you can intercept anything that will result in a history record update. Admittedly, you still have to do a bit of coding (notably for checking the type of HistoryEvent and then acting accordingly), but it covers quite a bit in just one listener. Sadly this is not in the API docs, so you need to do a bit of digging in the code. There are 16 classes in the package org.jbpm.pvm.internal.history.events that each represents something you can capture.
I'm trying to construct an audit mechanism for my JBPM processes. When I first saw the event section in the user guide, I thought it would be perfect, but, after looking at the example, it seems that events are almost completely worthless. The reason for this is that you a) have to explicitly scatter events in your processes (a real nightmare if you have a lot of them) and b) have to explicitly tell it which class is a listener. I thought the whole point of events was that you didn't need to know what or how many listeners were listening. You could just generate an event and every listener who had registered would know about it. Am I missing something here?
In the observer pattern, it is the event source or observable subject the one who is unaware of the observers. However, observers still have to register themselves, otherwise the source cannot possibly know about them! In this case jBPM will notify as many listeners as you want to put in place, but you still have to declare them.
In any case, here's what I would like to do. I would like have an audit class which is notified on every step of a process. The audit class may choose to record these steps and some of the variables which would allow reconstruction of the "flow" of a specific execution of a process. I welcome any ideas about how to best implement this since it doesn't seem to be provided by default.
If notified on every step means each time an activity ends then you can leverage event propagation and, with a single event tag, receive a notification each time an activity ends.
<process name='Insurance claim' key='ICL'> <on event='end'> <event-listener propagation='enabled' class='org.example.EventListener' /> </on> <start> <transition to='a' /> </start> <state name='a'> <transition to='b' /> </state> <end name='b' /> </process>
Ahhh, now that makes more sense. I think this will work. Thanks Alex!
You still need to implement the HistorySession as I explained earlier to fully reconstruct your workflow, otherwise you cannot reconstruct when (and by whom) a task was taken/released etc.
Thanks for the info Jimmy. I've gotten my basic auditor working and will be adding the HistorySession peice today.