Building custom audit trails for human workflow monitoring
By Roxana Petculet on Mar 09, 2014
Business Process Management applications usually have a lot of human interaction steps. Whenever somebody does something most probably out there is another person who will need to be informed about this. As a result, the need of delivering customized and comprehensive control tools would always be an important requirement for somebody using BPM.
This article will explain in a few simple steps how you can create you own audit trail which delivers data about all the human interactions inside your BPM process. The main mechanism used is the business events callbacks made available by the human workflow component inside the SOA infrastructure.
Why would somebody need to build another audit trail when you already have similar features inside Oracle Enterprise Manager or Oracle BPM Workspace?
Here are some situations:
- you want to build your own workspace
- you need to create a more specific audit trail which targets business users such as team leaders, LOB managers, head of department etc
- you want to have custom trails for specific applications inside your infrastructure
- you want to create a simple mechanism for managing the data sent to your trails so administrators would be able to handle this in a more efficient way
The solution delivered along with this article will provide you a plug-and-play application which is able to listen to any workflow events and insert data into a database table. This table can be further used a source for any web page inside your workspace.
Let’s start with the beginning. We have a simple BPM process as shown below.
We want to design a trail which holds details about assignments, updates and submissions of all the tasks in the process. Also, we need to get the name of the project, the system date, the author of the action, the current payload of the task and the ID of the composite.
Firstly, we need to make sure that our Human Tasks are configured to trigger events.
That would be everything you need to change in your BPM application. Here are some details regarding the state types used for this example:
· OnAssigned - Select if the callback class must be called on any assignment change, including standard routing, reassignment, delegation, escalation, and so on. If a callback is required when a task has an outcome update (that is, one of the approvers in a chain approves or rejects the task), this option must be selected.
· OnUpdated - Select if the callback class must be called on any update (including payload, comments, attachments, priority, and so on).
· OnCompleted - Select if the callback class must finally be called when the task is completed and control is about to be passed to the initiator (such as the BPEL process initiating the task).
Now, let’s create a different project for actually getting the data and building the trail. Here are the steps:
- Add a SOA-MDS connection to your project.
- Add a new mediator component using the events subscription template.
- Choose the HumanTaskEvents.edl from your SOA-MDS connection.
- Choose the 3 needed events: OnTaskAssigned, OnTaskCompleted and OnTaskUpdated.
- You can click OK now.
- Here is how your mediator should look like.
- Create a Database Adapter which will insert data inside a table with a structure as below.
- Now let’s wire this mediator to the Database Adapter.
- Add a static routing rule for each event which will invoke the database adapter and create a transformation for mapping data. Below you can see an example of mapping. The rest can be found in the archived application.
- Once done, you can deploy your project and run a few instances through the process. By checking the instance trace in Oracle Enterprise Manager you will see how the workflow events triggered the insert in your database table.
- Here is how the transformation result looks like in Oracle Enterprise Manager.
- It’s time to check also the database. You should see data as below.
The nice thing about this mechanism is the simple way in which you can juggle with the data sent to your audit trail by changing the transformation used inside the mediator. You can add data like: outcomes, types of actions, full payload, users and roles, task Id and name, user comments, attachment details or any other data which is present in your task payload.
Additionally, by adding filters to your mediator component you can invoke different services for different types of payload you receive (e.g. composite name, activity name etc.). This way, you will be able to turn on/off trailing for different components inside your infrastructure.
Enjoy logging workflow events!