One of the reasons to do Business Process Management is getting insight in what is going on during a process. From a process perspective, how long did an activity took, how many times was a process step executed, who executed the tasks and what was their effectiveness etc. In order to be able to answer all questions we need to monitor our processes and obtain data around the process steps. For a description of data available and used in processes see my previous blog on Capping IT off around Importance of data in processes. End-users do their part of the process work in the Human Task steps.
Within Oracle BPM these are modeled as an interactive process activity.
At run time the end-users see the Human Tasks as tasks in their inbox on which they can do a set of actions, change data related to the Human Task, Approve/Cancel, add notes, add documents, and a variety of actions such as Escalate and Reassign (the list of these actions is determined at design time).
Looking at all the activities an end-user can do there are a lot of things we would like to monitor. How many times was an activity escalated, who reassigned their task the most (did they want to clean up their task inbox?), how many documents were uploaded in every step etc. What possibilities do we have with Oracle BPM to measure all these things? Before diving into monitoring details, how does Oracle BPM deal with Human Tasks? The process engine is responsible for the execution of the process, handing over responsibilities to services to be called, handing over Human tasks to certain roles, data transfer, measurement of data or waiting for events to come in to name a few. A Human Task is implemented within Oracle BPM as a separate workflow engine. An important thing to understand is that whenever a process instance reaches a Human Task, the Workflow component is started and the process keeps waiting until an end-user presses the Approve/Cancel/etc button (or a timer exceeds). Whatever happens inside the Workflow components is outside the scope of the process. What options do we have to measure what’s happening inside a Human Task
- Use Business Events on Human Tasks Within the Human Tasks events can be created. Based upon configuration choices you made, events are created for instance with creation, escalation, when comments are added etc. These events can be picked up by Java Classes or be put on the Event Delivery Network and picked up by Mediator. This is detailed out below further
- Use BAM Data Controls to provide the process data A standard facility within BPM enables process run-time information to be handed over to BAM. This BAM information can then be exposed as a BAM Data Control within ADF. The provided BPM information towards BAM is way too meager. Only start/stop of the Human Task is available. Anything happening in the scope of the Workflow (like escalation) is NOT moved over to BAM
- Use the BPM Human Task Data Control For every created Human Task, a BPM Human Task Data Control is created. This Data Control only works for within the context of the Human Tasks. So in order to get an overview of the process status, this information will not suffice.
- Usage of PAPI’s (BPM Process API) Within BPM version 10 all Inbox functionality is exposed as PAPI’s, or Process API’s. Within the current version of 11G the PAPI’s are available. I did not have a chance to play with it. I guess it would just provide the same functionality as the worklist application. You can decide to start coding around the PAPI’s but it would just make your solution complex and code heavy?
- Querying the MDS Repository All design time and run time information of the defined processes is stored in the BPM MDS Repository data store in tables. In order to find out where to get what information, the BPM MDS repository needs to be reverse engineered. This is not a supported solution.
The first option, Using Business Events on Human Tasks, is obviously the most attractive, since this is out-of-the-box available functionality. Here I will describe what we need to do obtain the Workflow information and move it towards a File. Writing this information to a Database or BAM is the same way of working. In the process definition we’re able to set up the Human Task component. One of the things we can do is define what information should be made available when a certain event occurs. For instance when the Human Task (as executed by the Workflow engine) is finished, an onCompleted event is fired. In the following documentation a definition of the Event types can be found. Within the Human Task definition it’s just a matter of clicking which Workflow event information we’d like to receive.
These events can be picked up by the BPM process in two ways, in a Java class or (the preferred way), handing it over to the Event Delivery Network (EDN). From the EDN the information can be picked up by a Mediator.
Here the Human Tasks Event activity flow which describes what happens when a Human Task event occurs and how the data moves towards the File.
Now diving a bit deeper in on how this is done. Each Event has a separate Message Type, as can be found in the SOA-MDS resource connection
The Mediator component is listening to all Human Task Workflow Events.
Here an example of a Mediator component, which writes to a separate File via a File Adapter for every Event type.
Within the Mediator component mappings can be created in order to connect the Event input data to the File Adapter. The largest trick to find out what information is needed, because the payload of the Workflow Event messages is very large. Click on the below picture to see all information when a Task is Assigned to a person:
Once this is determined for one Human Task, the methodology can be replicated for all Human Tasks in the process.
during the handling of a Human Task within an Oracle BPM Process a lot of activities can take place. When we’d like to monitor these activities multiple methodologies exists, of which the Human Task Event based is the preferred one which provides the complete information set. Even though Oracle provides an elegant solution in order to catch every activity within a Human Task workflow component by means of Events, it would be much nicer when Human Task Workflow information can be directly written to BAM Dashboards or Process Spaces.