Databases Reference
In-Depth Information
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
, illustrated as follows:
ids:getUsersInGroup('SuspectItemPanel',true())
Doing this will effectively create and assign a separate subtask to every member of
the group.
Skipping the second step
There is an issue with this approach so far, in that the second step of the workflow
(that is, the Suspect Item Panel Vote) 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, but chose to either accept or reject the item,
then this step is skipped.
Using multiple human tasks
The other approach to this workflow is to model each step as a separate human task
in its own right, each with a single assignment and routing policy.
With this approach, you get a lot more control over how you want to handle each
step, since most of the runtime behavior of the human task is defined at the task
level, allowing you to specify different parameters, expiration policies, notification
settings, and task forms for each step in the workflow. In addition, on completion of
every step, control is returned to the BPEL process, allowing you to carry out some
additional processing before executing the next step in the workflow.
One of the drawbacks to this approach is that you need to specify a lot more
information (roughly n times as much, where n is the number of tasks that you
have), and often you may be replicating the same information across multiple task
definitions as well as having to specify the handling of outcomes for multiple tasks
within your BPEL process.
This not only requires more work upfront, but results in a larger, more complicated
BPEL process that is not so intuitive to understand and often harder to maintain.
