Measuring the Human Task activity in Oracle BPM

Publish date:

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 […]

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.

Concluding,
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.

Related Posts

Digital Leadership

Architecture at Capgemini and The Power of One

David Rutter
Date icon May 15, 2018

An insight into architects and architecture at Capgemini and its relevance to our clients,...

Fusion Apps

Oracle Procurement Cloud Blog Part IX: Don’t push that red button!

Jeroen Sprangers
Date icon March 16, 2017

Being surrounded with all kinds of new technologies which you have to master can be a...

Business Analytics

Oracle Procurement Cloud Blog Part III: Why build a skyscraper if your need is a small apartment building?

Jeroen Sprangers
Date icon January 30, 2017

The good news is that in Oracle Procurement Cloud you can also model the giant skyscraper....

cookies.

By continuing to navigate on this website, you accept the use of cookies.

For more information and to change the setting of cookies on your computer, please read our Privacy Policy.

Close

Close cookie information