AVIO Consulting

How Task Flow Registration for Human Tasks Works

Aug 17, 2012 | BPM


The most common and easiest way to implement user interfaces for your BPM Human Tasks is with ADF task flows.  It is possible to develop your user interfaces in other web frameworks such as Spring MVC, Grails, or .NET, but in order to use the provided BPM workspace you need to implement certain functionality to interact with the Human Workflow task services.  One of the items you need to implement is the registration of a task flow to a human task.  Even when using ADF task flows as the implementation, it is important and useful to understand how this registration happens.

Database Tables Used

The registration of human tasks and the associated user interface for each task flow is done within the two database tables listed below, WFTASKMETADATA and WFTASKDISPLAY.

WFTASKMETADATA – This table contains the metadata for all deployed human tasks.

Column Description

The ID of the human task in the format


URI Not populated
NAME Human Task Name
TITLE Human Task Title
DESCRIPTION Not populated
DOMAINID Not populated
PROCESSNAME Not populated
PROCESSID Not populated
NAMESPACE Human Task Namespace

WFTASKDISPLAY – This table contains the user interface that has been registered for each human task.  For a given human task the display information can be looked up using the namespace, composite version and partition name.

Column Description
NAMESPACE Human Task Namespace
URI URI to the User Interface for the Human Task, this does not include protocol, host or port
APPLICATIONNAME Application Name, BPM always uses worklist as the application name
HOSTNAME Hostname where URI is hosted
PARTITIONNAME Partition name

Registration Process

When a composite is deployed the following steps happen:

One record is inserted into the WFTASKMETADATA table for each human task.  

The WFTASKDISPLAY table is then checked for a row where the human task namespace and partition name match the human task being deployed and where the composite version = NULL.  This is the default entry for this human task and is not version specific.  If this row already exists, a new row is inserted with all of the same information (namespace, partition, human task name, URI, host, port) but with a composite version number (i.e. 1.0).  The composite version number is the current version of the composite being deployed.

This has used the default row that already had a URI populated, and made a version specific row for the new deployment using this information.


When an ADF task flow based on a human task is deployed the following happens

  1. The servlet, oracle.bpel.services.workflow.client.worklist.servlet.IntegrateTaskFlowWithTask, executes at startup to register the task flow for the human task.
  2. The hwtaskflow.xml is read from the /WEB-INF/classes folder within the ADF application.  This contains the mappings of which task flows are associated to which human tasks.
  3. The RuntimeConfigService from the Human Workflow services is used to register each task flow with its corresponding human task.  The setTaskDisplayInfo operation is used to do this registration.
  4. For each registration that is done one of the following is done by the RuntimeConfigService:
    1. If the human task has already been deployed:  The row in the WFTASKDISPLAY table which contains a NULL composite version is updated so the new URI becomes the default for the next deployed version of the composite.  The row for the currently active version of the composite is also updated so that the latest version of the human task now contains the new URI for the task flow.
    2. If the human task has not been deployed:  A single row is inserted into the WFTASKDISPLAY table which contains a NULL composite version.  This makes the provided URI the default URI for when the human task is deployed.
Versioned UI Deployments

Based on the series of events that occurs, the following should be taken into consideration:

  1. Each version of a composite can have its own associated version of the user interface if needed.  This can be done simply by adding the version number to the context root of the ADF application before it is deployed.
  2. When using versioned user interfaces the order of deployment for the composite and the ADF application must be considered as well.  If each version of the composite should be associated with its own specific version of the UI then the composite should always be deployed first.  This will result in the new version of the composite (2.0) first being associated with the old version of the UI (1.0).  Then when the UI is deployed 2nd it will updated the active version of the composite (2.0) to use the new UI (2.0) and also update the default URI to be 2.0 as well.

Usage Outside of ADF

This same pattern could be implemented using another web framework besides ADF, although there may be a significant amount of effort required.  You would need to replace all of the functionality provided by the IntegrateTaskFlowWithTask servlet including the following items.

  1. Determine a list of URI’s and which Human Tasks they are associated to.  This is the equivalent of the hwconfig.xml file
  2. At start up the registration of the URI’s to the Human Tasks needs to be performed using the RuntimeConfigService

This is also only one part of the effort needed to implement the human task interfaces in another web framework.  Inside the UI you would also need to interact with the TaskService to retrieve the payload, set the outcome and complete the task as well as provide the proper interaction with the workspace so that it will refresh the task list once the task is completed.


Whether you are implementing your user interfaces using ADF task flows or decide to implement them using another web framework but would still like to leverage the out of the box BPM workspace it is important to understand how your task flows are associated to your deployed human tasks.  This is also important to understand when using versioned user interfaces.