[rules-users] Drools Flow BAM

Kris Verlaenen Kris.Verlaenen at cs.kuleuven.be
Mon Oct 25 22:21:51 EDT 2010


Prafull,

It all depends on how you want to store the data that you need to do
BAM.  You could consider the audit logger as an example of how you could
do logging (although it might probably be better to not use XML logging
for BAM, but rather use a database or feed the events directly into
Drools Fusion for processing).

Quoting Prafull Kumar <to_prafull at yahoo.com>:

> 1. In the ProcessEventListener can we embed required data from the
> process, global variables?
The event listeners provide access to the process instance object, so
you can access all runtime information, including variable values, etc.
 You can then customize how to store that information.

> Its good, But I would like to log the variables as the workflow
> executes, so 
> that I can generate the meaningful reports. e.g. If the flow
> takes one path I 
> would like to log a variable of a object and for another maybe
> another part of 
> the object.
You should probably be looking at the history log (in the drools-bam
module) for this kind of features, which maintains a history of what
happens at runtime (including variable values) based on the events. 
Again, you could look at this as an example that you can tweak according
to your needs.  Depending on whether you use persistence or not, you
should be looking at the WorkingMemoryDbLogger or
JPAWorkingMemoryDbLogger respectively:
http://anonsvn.jboss.org/repos/labs/labs/jbossrules/trunk/drools-process/drools-bam/src/main/java/org/drools/process/audit/

> It will help me to create the kind of report I am looking for. Please
> advice.
> 
> 2. Any idea on the performance impact if we log these events in the
> database. 
> Does the process waits till the event is written in database or this
> happens 
> asynchronously as its a event? Please clarify.

How your event listener works is up to you.  If you use persistence, you
should make sure the events are created as part of the transaction the
events are generated in.  The two default implementations don't use
asynchronous handling of events, but this could be added if necessary by
updating the listener.  When using the JPA version, all updates to the
history log are already batched as part of one commit, so this should
improve performance.  You should also make sure that you only log the
data that you are planning to use (at the level of detail you'll be
using it) to avoid storing too much data and impacting performance.

Kris

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm



More information about the rules-users mailing list