Workflow Patterns

The following is a serialisation of Chapter 15 from the book Oracle SOA Suite Developer's Guide by Matt Wright and Antony Reynolds from Packt Publishing.

So far we've used workflow for simple task approval in conjunction with the worklist application. However, human workflows are often more complex, often involving multiple participants as well as requiring the task list to be integrated into the user's existing user interface rather than accessed through a standalone worklist application.

In this chapter, we look at these common requirements. First, we examine how to manage workflows involving complex chains of approval, including parallel approvers and the different options that are available. Next, we look at the Workflow Service API and how we can use that to completely transform the look and feel of the workflow service.

Managing multiple participants in a workflow

The process for validating items which have been flagged as suspicious is a classic workflow scenario that may potentially involve multiple participants.

The first step in the workflow requires an oBay administrator to check whether the item is suspect. Assuming the case is straightforward they can either approve or reject the item and complete the workflow.

This is pretty straightforward; however, for grey areas the oBay administrator needs to defer making a decision. In this scenario we have a second step in which the item is submitted to a panel who can vote on whether to approve or reject the item.

There are two approaches to model this workflow, one is to model each step as a separate Human Task, the other is to model it as a single Human Task containing multiple assignments and routing policies. Each approach has its own advantages and disadvantages, so we will look at each in turn to understand the differences.

Using multiple assignment and routing policies

For our checkSuspectItem process, we are first going to take the approach of combining the two workflow steps into a single Human Task. The first step in the workflow is the familiar single approval step, where we assign the task to the oBayAdministrator group.

The task takes a single un-editable parameter of type suspectItem, which contains the details of the item in question as well as why it has been flagged as suspect. The definition of this is shown as follows:

<xsd:element name="suspectItem"   type="act:tSuspectItem"/>
<xsd:complexType name="tSuspectItem">

    <xsd:sequence>
        <xsd:element name="item" type="act:ItemType"/>
        <xsd:element name="reasonCode" type="xsd:string" />
        <xsd:element name="reasonDesc" type="xsd:string"/>
    </xsd:sequence>
</xsd:complexType>

Determining the outcome by a group vote

For the second step in the workflow we are going to define a participant type of Group Vote; this participant type allows us to allocate the same task to multiple participants in parallel. The task definition form for a group vote is shown in the following figure:

Assigning participants

The first requirement is to allocate this task to all users in the voting panel. To enable this, we've defined the group SuspectItemPanel within our user repository. We don't want to allocate the task to the group, as this would only allow one user from the group to acquire and process the task. Rather we want to allocate it to all members of the group. To do that we can use the Identity Service XPath function ids:getUsersInGroup, as illustrated here:

ids:getUsersInGroup ('SuspectItemPanel', false())

Note the second parameter is a Boolean which, if set to true, will only return direct members of the group. Setting it to false causes it to return all members of the group.

Doing this will effectively create and assign a separate sub-task to every member of the group.

Skipping the second step

There is an issue with this approach so far, in that the second step will always be executed regardless of what happens in the first step. To prevent this we've specified the following skip rule:

/task:task/task:systemAttributes/task:outcome != 'DEFER'

The skip rule lets you specify an XPath expression which evaluates to a boolean value. If it evaluates to true then the corresponding participant will be skipped in the task.

In our case we are testing the outcome taken by the oBay administrator in the previous step. If they didn't defer it, that is they chose to either accept or reject the item, then this step is skipped.

Sharing attachments and comments

When panel members are considering their decision they may want to confer with one another. By default anyone assigned a task will be able to see comments and attachments made by participants in previous steps of the task (that is, the oBay administrator), however, they won't be able to see comments made by other panel members.

To enable the sharing of attachments and comments between panel members we've selected the Share comments and attachments checkbox.

Deciding on the outcome

The final part of the group vote is to specify what the outcome is in the event that not all members are in agreement. There are two parts to this; the first is to specify what the default outcome is if there isn't agreement, in our case we want to REJECT the item.

The second part is to specify what constitutes agreement, this can either be unanimous, that is, everyone must agree, or the default outcome is selected. Alternatively, you can specify that only a majority need to be in agreement and what the size of that majority should be.

The size of the majority can be a fixed amount (60% as in our case), or can be based on an XPath expression which could calculate this value dynamically at run time.

The final option you have is to specify whether all votes should be counted or if once we have sufficient votes on which to make a decision the outcome should be triggered. In this scenario, any outstanding sub-tasks will be withdrawn.

In our case the panel consists of three members, so as soon as two have approved the task, the required consensus will have been achieved and the third member will have their task withdrawn.