Chapter 6. Adding in Human Workflow

Many business processes require an element of human activity. Common tasks include approving an expense item or purchase order. But even fully automated processes can require human involvement, especially when things go wrong.

In this chapter, we will introduce you to the various parts of the human workflow component of the Oracle SOA Suite and take you through a practical example to create and run your first "simple" workflow. Once we've done that, we will examine how to carry out other basic workflow activities such as how to:

• Dynamically assign a task to a user or group based on the content of the task
• Cancel or change a workflow task while it's still in process
• Enable the workflow user to request additional details about a task
• Reassign, delegate, or escalate a task, either manually or through the use of user-defined business rules

Workflow overview

The following diagram illustrates the three, typical participants in any workflow:

On the left-hand side we have the BPEL process, which creates the task and submits it to the human workflow service. Once it has initiated the task, the process itself will pause until the completed task is returned.

On the right-hand side we have the user who carries out the task. Tasks can either be directly assigned to a user or to a group to which the user belongs; in this case they need to claim the task before they can work on it. When working on a task, a user typically does this via the BPM Worklist Application, which is a web-based application included as part of the SOA Suite.

Sitting between the BPEL process and the worklist application is the human workflow service. It is responsible for routing the task to the appropriate user or group, managing the lifecycle of a task until it completes, and returning the result to the initiator (that is, the BPEL process in the preceding diagram).

Note

The human workflow services have a full set of WSDL and Java APIs that allow us to build our own custom equivalent of the BPM worklist application. This is an area we examine in Chapter 17, Workflow Patterns.

The human workflow service utilizes an external identity store for details of users, their privileges, and which groups they belong to. In a production deployment, you would typically configure the identity store to be an LDAP repository such as Oracle Internet Directory or Active Directory .

Note

For the sake of simplicity, the workflow examples within this book make use of the sample user community provided by Oracle. To install this community, go to http://www.oracle.com/technology/sample_code/products/hwf/index.html and download the file workflow-001-DemoCommunitySeedApp. Unzip this file and follow the instructions in README.txt.

Leave approval workflow

For our first workflow, we will create a very simple BPEL process that takes a leave request and creates a simple approval task for the individual's manager, who can then either approve or reject the request.

The first step is to create a composite containing a simple asynchronous leave approval BPEL process. The input and output schema elements for the process are defined in LeaveRequest.xsd, as shown in the following code snippet (note that the schema is also provided in the samples folder for Chapter 6):

<?xml version="1.0" encoding="windows-1252"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
           xmlns="http://schemas.packtpub.com/LeaveRequest"
           targetNamespace="http://schemas.packtpub.com/LeaveRequest"
           elementFormDefault="qualified" >
  <xsd:element name="leaveRequest" type="tLeaveRequest"/>
  <xsd:complexType name="tLeaveRequest">
    <xsd:sequence>
      <xsd:element name="employeeId" type="xsd:string"/>
      <xsd:element name="fullName" type="xsd:string" />
      <xsd:element name="startDate" type="xsd:date" />      
      <xsd:element name="endDate" type="xsd:date" />
      <xsd:element name="leaveType" type="xsd:string" />  
      <xsd:element name="leaveReason" type="xsd:string"/>
      <xsd:element name="requestStatus" type="xsd:string"/>
    </xsd:sequence>
  </xsd:complexType>
</xsd:schema>

Make sure you import this file as part of the process of creating the BPEL process and set the input and output schema elements to LeaveRequest.

Defining the human task

Once you've created your composite, drag a Human Task Component from the SOA Component Palette onto it. This will pop up the following screen:

Give the task a meaningful name (for example, LeaveRequest) and click OK. This will add a Human Task with the corresponding name to our composite, as shown in the following screenshot:

Double-click on the LeaveRequest task tab. This will open up the task definition form as a new tab within JDeveloper (as shown in the following screenshot) where we can configure our task:

By default, JDeveloper displays the General subtab where we define the basic details about the task.

Note

For readers familiar with Oracle SOA Suite 10gR3, you will notice the task definition form looks a lot simpler. This is because it's been restructured to organize the task configuration parameters into categories, each accessed by a corresponding tab (rather than display them all on the same form as was previously the case).

The key things we need to define for the task are its Title, what the possible Outcomes are (that is, leave request approved or rejected), the Parameters (or payload) of the task, and who to route or assign it to.

On the General tab, give the task a Title, such as Approval Required for Leave Request. Note that this is what a user will see in their work queue if they are allocated the task. For the time being we can leave the other values (Description, Outcomes, Priority, Category, and Owner) with their default values.

Specifying task parameters

Next, we need to define the task data, that is, the content of the task that we want the approver to base their decision upon. For this, we can specify one or more parameters; each parameter can be a standard XML type such as string, integer, or boolean. In addition, we can use any type or element defined in one of our imported XML schemas.

For our purposes, we simply want to pass in the leave request received by the BPEL process. To do this, select the Data tab, click on the plus symbol (circled in the following screenshot), and select Add other payload:

This will launch the Add Task Parameter window:

Ensure that Element is selected as the parameter type and then click on the corresponding search icon to bring up the standard type chooser. From here, just browse the LeaveRequest schema file that we imported at the start, and select the LeaveRequest element.

If we check Editable via worklist, anyone who has write access to the task payload will be able to update the content of this parameter. In our case, we will leave it unchecked.

Click OK. We should now have a LeaveRequest parameter defined for our task.

Specifying task assignment and routing policy

Finally, we need to specify who is going to approve the task. We do this by creating an Assignment and Routing Policy. An assignment and routing policy consists of one or more stages that can be executed sequentially or in parallel (or any combination thereof), with each stage consisting of one or more participant types that in turn can also be sequential or in parallel (or any combination thereof). A participant type can be:

• Single: Used to specify a single user or group to assign the task to
• Serial: Used when a set of users must work in sequence, for example, when a task has to proceed through several layers of a management chain
• Parallel: Used when a set of users must work in parallel, a common usage for this is when a group of participants need to vote on an outcome
• FYI: Used to send a notification to a user or group

For our purposes we need a single stage containing one participant of type Single approver (we will examine the other types in more detail in Chapter 17, Workflow Patterns). Select the Assignment tab. You will see that, by default, our task consists of a single stage named Stage1, as shown in the following screenshot:

First, we will give our stage a more meaningful name. To do this, select the stage by clicking on its name. The stage will turn gray to indicate that it has been selected, as shown in the preceding screenshot. Then select Edit (circled in the preceding screenshot). This will bring up the Edit window. Give it an appropriate name, and click OK.

Next, we need to add a participant of type Single to our Approval stage. First, select the <Edit Participant> section of our stage by clicking on it. It will turn gray to indicate that it has been selected, as shown in the following screenshot:

Select Edit (circled in the preceding screenshot). This will launch the Add Participant Type window.

Note

You will notice that the menu icons in the Assignment tab are context-sensitive, based on whether you have selected one or more stages or participants.

By default, a participant type of Single approver is selected, which is fine for our purpose. Labels are used to provide a meaningful description of the routing rules and are also useful if we specify multiple participants for a stage. So for our purpose, just enter a meaningful value (for example, Manager Approval).

We now need to specify the list of participants that the task is going to be assigned to. Each participant can either be a specific user, group, or application role (and we can have any combination of these in our list).

For our purpose, we are going to assume that the CEO of the company is required to approve every holiday, so we will always assign it to cdickens. This is probably not ideal! But we will revisit this later in the chapter to look at how we can make it more realistic.

Click on the plus symbol, and select Add User, as shown in the preceding screenshot. This will add a participant of type User to our participant list, as shown in the following screenshot. We can either directly enter the name of a user into the Value field or click the browse icon (…) to bring up the identity lookup dialog. This allows you to search and browse the users and groups defined in the identity service.

Once you've specified the participant details, click OK; this will take us back to the task definition window, which will have been updated with our routing policy. Select Save on JDeveloper to make sure you save the task definition.

Invoking our human task from BPEL

So far, we have defined our human task. The next step is to incorporate it into our LeaveApproval BPEL process. To do this, drag a Human Task activity from the BPEL component palette onto our process, as shown in the following screenshot:

JDeveloper will prompt us to specify the Task Definition to use for this activity; from the drop-down list, select LeaveRequest. This will present us with the Human Task activity window from where we can configure the task within the context of our BPEL process:

The first value we need to specify is the Task Title. This is optional, since if we don't specify a value, it will use the task title we specified earlier as part of the task definition. We want to make the task title a bit friendlier, so first type in (without the quotes):

Leave Request for

Then click on the calculator icon to the right of the Task Title field. This will launch the now familiar Expression Builder. Here, from the inputVariable, just select the element:

ns1:LeaveRequest/ns1:fullName

This expression will be appended to the end of our title text embedded between <% %> to give the following:

Leave Request for <%bpws:getVariableData('inputVariable', 'payload', '/ns1:LeaveRequest/ns1:fullName')%>

At runtime, the BPEL process will evaluate the expression between <% %> and substitute the result. For now, we won't specify a task initiator as this is optional, and we will leave the Priority set to 3.

The final thing to specify is the value of each of the Task Parameters defined to the task. Click on the browse icon (…) for the LeaveRequest parameter, and this will bring up the Task Parameters window, which allows you to browse the variables defined to the BPEL process. Select the LeaveRequest element passed in as part of the inputVariable for the BPEL process.

This completes the configuration of the task, so click OK. This will return us to the BPEL process, which will now contain our human task activity, followed by an additional switch. If you expand the switch, you will see it contains a Case for each of our task outcomes (APPROVE or REJECT), where we can specify the appropriate next step in our process. For the purpose of this example, we don't need to do anything. However, in a real system we might update the HR system with details of the leave, if it was approved.

Your composite is now complete, so deploy it to the server in the normal way.

Creating the user interface to process the task

So far, we have defined the task that needs to be carried out and plugged it into a simple BPEL process. What we need to do next is implement the part of the user interface that allows someone to view the details of our specific task and then either approve or reject the leave request.

Out-of-the-box, SOA Suite provides the worklist application with all the main workflow user interface screens and a framework in which to plug your task-specific interface component. This can be developed from scratch if you want, using ADF, but the simplest way is to get JDeveloper to generate an ADF form based on the task definition.

To do this, go back to the task definition form, click on Create Form, and select Auto-Generate Task Form, as shown in the following screenshot:

This will launch the Create Project window, prompting us to specify the name of the project in which to create our form. Specify an appropriate name, such as LeaveRequestForm, and click OK.

This will generate an ADF form plus all the supporting components; JDeveloper will automatically open the form, which can then be customized as required.

To deploy the form, click on the Application menu (circled in the preceding screenshot) and select Deploy | LeaveRequestForm. This will launch the Deployment dialog. Select Deploy to Application Server, and click on Next. On the Select Server page, uncheck the option Deploy to all server instances in the domain and click on Next. On the Server Instances page, select the SOA server instance, click on Next, and then click Finish.

Running the workflow process

Log into the SOA console and launch the composite, ensuring that you specify a valid employee ID (such as jcooper). This will invoke the BPEL process, which in turn will create the LeaveRequest task.

If you browse the audit trail for the composite, you will see it paused at the LeaveRequest activity, as shown in the following screenshot:

Click on the LeaveRequest activity, and this will bring up the Activity Audit Trail for the workflow task, showing that it is assigned to cdickens, as shown in the following screenshot:

At the moment, the composite will wait forever, until the task is either approved or rejected. To do that, we need to log into the BPM worklist application to process the task.

Defining the human task

Once you've created your composite, drag a Human Task Component from the SOA Component Palette onto it. This will pop up the following screen:

Give the task a meaningful name (for example, LeaveRequest) and click OK. This will add a Human Task with the corresponding name to our composite, as shown in the following screenshot:

Double-click on the LeaveRequest task tab. This will open up the task definition form as a new tab within JDeveloper (as shown in the following screenshot) where we can configure our task:

By default, JDeveloper displays the General subtab where we define the basic details about the task.

Note

For readers familiar with Oracle SOA Suite 10gR3, you will notice the task definition form looks a lot simpler. This is because it's been restructured to organize the task configuration parameters into categories, each accessed by a corresponding tab (rather than display them all on the same form as was previously the case).

The key things we need to define for the task are its Title, what the possible Outcomes are (that is, leave request approved or rejected), the Parameters (or payload) of the task, and who to route or assign it to.

On the General tab, give the task a Title, such as Approval Required for Leave Request. Note that this is what a user will see in their work queue if they are allocated the task. For the time being we can leave the other values (Description, Outcomes, Priority, Category, and Owner) with their default values.

Specifying task parameters

Next, we need to define the task data, that is, the content of the task that we want the approver to base their decision upon. For this, we can specify one or more parameters; each parameter can be a standard XML type such as string, integer, or boolean. In addition, we can use any type or element defined in one of our imported XML schemas.

For our purposes, we simply want to pass in the leave request received by the BPEL process. To do this, select the Data tab, click on the plus symbol (circled in the following screenshot), and select Add other payload:

This will launch the Add Task Parameter window:

Ensure that Element is selected as the parameter type and then click on the corresponding search icon to bring up the standard type chooser. From here, just browse the LeaveRequest schema file that we imported at the start, and select the LeaveRequest element.

If we check Editable via worklist, anyone who has write access to the task payload will be able to update the content of this parameter. In our case, we will leave it unchecked.

Click OK. We should now have a LeaveRequest parameter defined for our task.

Specifying task assignment and routing policy

Finally, we need to specify who is going to approve the task. We do this by creating an Assignment and Routing Policy. An assignment and routing policy consists of one or more stages that can be executed sequentially or in parallel (or any combination thereof), with each stage consisting of one or more participant types that in turn can also be sequential or in parallel (or any combination thereof). A participant type can be:

• Single: Used to specify a single user or group to assign the task to
• Serial: Used when a set of users must work in sequence, for example, when a task has to proceed through several layers of a management chain
• Parallel: Used when a set of users must work in parallel, a common usage for this is when a group of participants need to vote on an outcome
• FYI: Used to send a notification to a user or group

For our purposes we need a single stage containing one participant of type Single approver (we will examine the other types in more detail in Chapter 17, Workflow Patterns). Select the Assignment tab. You will see that, by default, our task consists of a single stage named Stage1, as shown in the following screenshot:

First, we will give our stage a more meaningful name. To do this, select the stage by clicking on its name. The stage will turn gray to indicate that it has been selected, as shown in the preceding screenshot. Then select Edit (circled in the preceding screenshot). This will bring up the Edit window. Give it an appropriate name, and click OK.

Next, we need to add a participant of type Single to our Approval stage. First, select the <Edit Participant> section of our stage by clicking on it. It will turn gray to indicate that it has been selected, as shown in the following screenshot:

Select Edit (circled in the preceding screenshot). This will launch the Add Participant Type window.

Note

You will notice that the menu icons in the Assignment tab are context-sensitive, based on whether you have selected one or more stages or participants.

By default, a participant type of Single approver is selected, which is fine for our purpose. Labels are used to provide a meaningful description of the routing rules and are also useful if we specify multiple participants for a stage. So for our purpose, just enter a meaningful value (for example, Manager Approval).

We now need to specify the list of participants that the task is going to be assigned to. Each participant can either be a specific user, group, or application role (and we can have any combination of these in our list).

For our purpose, we are going to assume that the CEO of the company is required to approve every holiday, so we will always assign it to cdickens. This is probably not ideal! But we will revisit this later in the chapter to look at how we can make it more realistic.

Click on the plus symbol, and select Add User, as shown in the preceding screenshot. This will add a participant of type User to our participant list, as shown in the following screenshot. We can either directly enter the name of a user into the Value field or click the browse icon (…) to bring up the identity lookup dialog. This allows you to search and browse the users and groups defined in the identity service.

Once you've specified the participant details, click OK; this will take us back to the task definition window, which will have been updated with our routing policy. Select Save on JDeveloper to make sure you save the task definition.

Invoking our human task from BPEL

So far, we have defined our human task. The next step is to incorporate it into our LeaveApproval BPEL process. To do this, drag a Human Task activity from the BPEL component palette onto our process, as shown in the following screenshot:

JDeveloper will prompt us to specify the Task Definition to use for this activity; from the drop-down list, select LeaveRequest. This will present us with the Human Task activity window from where we can configure the task within the context of our BPEL process:

The first value we need to specify is the Task Title. This is optional, since if we don't specify a value, it will use the task title we specified earlier as part of the task definition. We want to make the task title a bit friendlier, so first type in (without the quotes):

Leave Request for

Then click on the calculator icon to the right of the Task Title field. This will launch the now familiar Expression Builder. Here, from the inputVariable, just select the element:

ns1:LeaveRequest/ns1:fullName

This expression will be appended to the end of our title text embedded between <% %> to give the following:

Leave Request for <%bpws:getVariableData('inputVariable', 'payload', '/ns1:LeaveRequest/ns1:fullName')%>

At runtime, the BPEL process will evaluate the expression between <% %> and substitute the result. For now, we won't specify a task initiator as this is optional, and we will leave the Priority set to 3.

The final thing to specify is the value of each of the Task Parameters defined to the task. Click on the browse icon (…) for the LeaveRequest parameter, and this will bring up the Task Parameters window, which allows you to browse the variables defined to the BPEL process. Select the LeaveRequest element passed in as part of the inputVariable for the BPEL process.

This completes the configuration of the task, so click OK. This will return us to the BPEL process, which will now contain our human task activity, followed by an additional switch. If you expand the switch, you will see it contains a Case for each of our task outcomes (APPROVE or REJECT), where we can specify the appropriate next step in our process. For the purpose of this example, we don't need to do anything. However, in a real system we might update the HR system with details of the leave, if it was approved.

Your composite is now complete, so deploy it to the server in the normal way.

Creating the user interface to process the task

So far, we have defined the task that needs to be carried out and plugged it into a simple BPEL process. What we need to do next is implement the part of the user interface that allows someone to view the details of our specific task and then either approve or reject the leave request.

Out-of-the-box, SOA Suite provides the worklist application with all the main workflow user interface screens and a framework in which to plug your task-specific interface component. This can be developed from scratch if you want, using ADF, but the simplest way is to get JDeveloper to generate an ADF form based on the task definition.

To do this, go back to the task definition form, click on Create Form, and select Auto-Generate Task Form, as shown in the following screenshot:

This will launch the Create Project window, prompting us to specify the name of the project in which to create our form. Specify an appropriate name, such as LeaveRequestForm, and click OK.

This will generate an ADF form plus all the supporting components; JDeveloper will automatically open the form, which can then be customized as required.

To deploy the form, click on the Application menu (circled in the preceding screenshot) and select Deploy | LeaveRequestForm. This will launch the Deployment dialog. Select Deploy to Application Server, and click on Next. On the Select Server page, uncheck the option Deploy to all server instances in the domain and click on Next. On the Server Instances page, select the SOA server instance, click on Next, and then click Finish.

Running the workflow process

Log into the SOA console and launch the composite, ensuring that you specify a valid employee ID (such as jcooper). This will invoke the BPEL process, which in turn will create the LeaveRequest task.

If you browse the audit trail for the composite, you will see it paused at the LeaveRequest activity, as shown in the following screenshot:

Click on the LeaveRequest activity, and this will bring up the Activity Audit Trail for the workflow task, showing that it is assigned to cdickens, as shown in the following screenshot:

At the moment, the composite will wait forever, until the task is either approved or rejected. To do that, we need to log into the BPM worklist application to process the task.

Specifying task parameters

Next, we need to define the task data, that is, the content of the task that we want the approver to base their decision upon. For this, we can specify one or more parameters; each parameter can be a standard XML type such as string, integer, or boolean. In addition, we can use any type or element defined in one of our imported XML schemas.

For our purposes, we simply want to pass in the leave request received by the BPEL process. To do this, select the Data tab, click on the plus symbol (circled in the following screenshot), and select Add other payload:

This will launch the Add Task Parameter window:

Ensure that Element is selected as the parameter type and then click on the corresponding search icon to bring up the standard type chooser. From here, just browse the LeaveRequest schema file that we imported at the start, and select the LeaveRequest element.

If we check Editable via worklist, anyone who has write access to the task payload will be able to update the content of this parameter. In our case, we will leave it unchecked.

Click OK. We should now have a LeaveRequest parameter defined for our task.

Specifying task assignment and routing policy

Finally, we need to specify who is going to approve the task. We do this by creating an Assignment and Routing Policy. An assignment and routing policy consists of one or more stages that can be executed sequentially or in parallel (or any combination thereof), with each stage consisting of one or more participant types that in turn can also be sequential or in parallel (or any combination thereof). A participant type can be:

• Single: Used to specify a single user or group to assign the task to
• Serial: Used when a set of users must work in sequence, for example, when a task has to proceed through several layers of a management chain
• Parallel: Used when a set of users must work in parallel, a common usage for this is when a group of participants need to vote on an outcome
• FYI: Used to send a notification to a user or group

For our purposes we need a single stage containing one participant of type Single approver (we will examine the other types in more detail in Chapter 17, Workflow Patterns). Select the Assignment tab. You will see that, by default, our task consists of a single stage named Stage1, as shown in the following screenshot:

First, we will give our stage a more meaningful name. To do this, select the stage by clicking on its name. The stage will turn gray to indicate that it has been selected, as shown in the preceding screenshot. Then select Edit (circled in the preceding screenshot). This will bring up the Edit window. Give it an appropriate name, and click OK.

Next, we need to add a participant of type Single to our Approval stage. First, select the <Edit Participant> section of our stage by clicking on it. It will turn gray to indicate that it has been selected, as shown in the following screenshot:

Select Edit (circled in the preceding screenshot). This will launch the Add Participant Type window.

Note

You will notice that the menu icons in the Assignment tab are context-sensitive, based on whether you have selected one or more stages or participants.

By default, a participant type of Single approver is selected, which is fine for our purpose. Labels are used to provide a meaningful description of the routing rules and are also useful if we specify multiple participants for a stage. So for our purpose, just enter a meaningful value (for example, Manager Approval).

We now need to specify the list of participants that the task is going to be assigned to. Each participant can either be a specific user, group, or application role (and we can have any combination of these in our list).

For our purpose, we are going to assume that the CEO of the company is required to approve every holiday, so we will always assign it to cdickens. This is probably not ideal! But we will revisit this later in the chapter to look at how we can make it more realistic.

Click on the plus symbol, and select Add User, as shown in the preceding screenshot. This will add a participant of type User to our participant list, as shown in the following screenshot. We can either directly enter the name of a user into the Value field or click the browse icon (…) to bring up the identity lookup dialog. This allows you to search and browse the users and groups defined in the identity service.

Once you've specified the participant details, click OK; this will take us back to the task definition window, which will have been updated with our routing policy. Select Save on JDeveloper to make sure you save the task definition.

Invoking our human task from BPEL

So far, we have defined our human task. The next step is to incorporate it into our LeaveApproval BPEL process. To do this, drag a Human Task activity from the BPEL component palette onto our process, as shown in the following screenshot:

JDeveloper will prompt us to specify the Task Definition to use for this activity; from the drop-down list, select LeaveRequest. This will present us with the Human Task activity window from where we can configure the task within the context of our BPEL process:

The first value we need to specify is the Task Title. This is optional, since if we don't specify a value, it will use the task title we specified earlier as part of the task definition. We want to make the task title a bit friendlier, so first type in (without the quotes):

Leave Request for

Then click on the calculator icon to the right of the Task Title field. This will launch the now familiar Expression Builder. Here, from the inputVariable, just select the element:

ns1:LeaveRequest/ns1:fullName

This expression will be appended to the end of our title text embedded between <% %> to give the following:

Leave Request for <%bpws:getVariableData('inputVariable', 'payload', '/ns1:LeaveRequest/ns1:fullName')%>

At runtime, the BPEL process will evaluate the expression between <% %> and substitute the result. For now, we won't specify a task initiator as this is optional, and we will leave the Priority set to 3.

The final thing to specify is the value of each of the Task Parameters defined to the task. Click on the browse icon (…) for the LeaveRequest parameter, and this will bring up the Task Parameters window, which allows you to browse the variables defined to the BPEL process. Select the LeaveRequest element passed in as part of the inputVariable for the BPEL process.

This completes the configuration of the task, so click OK. This will return us to the BPEL process, which will now contain our human task activity, followed by an additional switch. If you expand the switch, you will see it contains a Case for each of our task outcomes (APPROVE or REJECT), where we can specify the appropriate next step in our process. For the purpose of this example, we don't need to do anything. However, in a real system we might update the HR system with details of the leave, if it was approved.

Your composite is now complete, so deploy it to the server in the normal way.

Creating the user interface to process the task

So far, we have defined the task that needs to be carried out and plugged it into a simple BPEL process. What we need to do next is implement the part of the user interface that allows someone to view the details of our specific task and then either approve or reject the leave request.

Out-of-the-box, SOA Suite provides the worklist application with all the main workflow user interface screens and a framework in which to plug your task-specific interface component. This can be developed from scratch if you want, using ADF, but the simplest way is to get JDeveloper to generate an ADF form based on the task definition.

To do this, go back to the task definition form, click on Create Form, and select Auto-Generate Task Form, as shown in the following screenshot:

This will launch the Create Project window, prompting us to specify the name of the project in which to create our form. Specify an appropriate name, such as LeaveRequestForm, and click OK.

This will generate an ADF form plus all the supporting components; JDeveloper will automatically open the form, which can then be customized as required.

To deploy the form, click on the Application menu (circled in the preceding screenshot) and select Deploy | LeaveRequestForm. This will launch the Deployment dialog. Select Deploy to Application Server, and click on Next. On the Select Server page, uncheck the option Deploy to all server instances in the domain and click on Next. On the Server Instances page, select the SOA server instance, click on Next, and then click Finish.

Running the workflow process

Log into the SOA console and launch the composite, ensuring that you specify a valid employee ID (such as jcooper). This will invoke the BPEL process, which in turn will create the LeaveRequest task.

If you browse the audit trail for the composite, you will see it paused at the LeaveRequest activity, as shown in the following screenshot:

Click on the LeaveRequest activity, and this will bring up the Activity Audit Trail for the workflow task, showing that it is assigned to cdickens, as shown in the following screenshot:

At the moment, the composite will wait forever, until the task is either approved or rejected. To do that, we need to log into the BPM worklist application to process the task.

Specifying task assignment and routing policy

Finally, we need to specify who is going to approve the task. We do this by creating an Assignment and Routing Policy. An assignment and routing policy consists of one or more stages that can be executed sequentially or in parallel (or any combination thereof), with each stage consisting of one or more participant types that in turn can also be sequential or in parallel (or any combination thereof). A participant type can be:

• Single: Used to specify a single user or group to assign the task to
• Serial: Used when a set of users must work in sequence, for example, when a task has to proceed through several layers of a management chain
• Parallel: Used when a set of users must work in parallel, a common usage for this is when a group of participants need to vote on an outcome
• FYI: Used to send a notification to a user or group

For our purposes we need a single stage containing one participant of type Single approver (we will examine the other types in more detail in Chapter 17, Workflow Patterns). Select the Assignment tab. You will see that, by default, our task consists of a single stage named Stage1, as shown in the following screenshot:

First, we will give our stage a more meaningful name. To do this, select the stage by clicking on its name. The stage will turn gray to indicate that it has been selected, as shown in the preceding screenshot. Then select Edit (circled in the preceding screenshot). This will bring up the Edit window. Give it an appropriate name, and click OK.

Next, we need to add a participant of type Single to our Approval stage. First, select the <Edit Participant> section of our stage by clicking on it. It will turn gray to indicate that it has been selected, as shown in the following screenshot:

Select Edit (circled in the preceding screenshot). This will launch the Add Participant Type window.

Note

You will notice that the menu icons in the Assignment tab are context-sensitive, based on whether you have selected one or more stages or participants.

By default, a participant type of Single approver is selected, which is fine for our purpose. Labels are used to provide a meaningful description of the routing rules and are also useful if we specify multiple participants for a stage. So for our purpose, just enter a meaningful value (for example, Manager Approval).

We now need to specify the list of participants that the task is going to be assigned to. Each participant can either be a specific user, group, or application role (and we can have any combination of these in our list).

For our purpose, we are going to assume that the CEO of the company is required to approve every holiday, so we will always assign it to cdickens. This is probably not ideal! But we will revisit this later in the chapter to look at how we can make it more realistic.

Click on the plus symbol, and select Add User, as shown in the preceding screenshot. This will add a participant of type User to our participant list, as shown in the following screenshot. We can either directly enter the name of a user into the Value field or click the browse icon (…) to bring up the identity lookup dialog. This allows you to search and browse the users and groups defined in the identity service.

Once you've specified the participant details, click OK; this will take us back to the task definition window, which will have been updated with our routing policy. Select Save on JDeveloper to make sure you save the task definition.

Invoking our human task from BPEL

So far, we have defined our human task. The next step is to incorporate it into our LeaveApproval BPEL process. To do this, drag a Human Task activity from the BPEL component palette onto our process, as shown in the following screenshot:

JDeveloper will prompt us to specify the Task Definition to use for this activity; from the drop-down list, select LeaveRequest. This will present us with the Human Task activity window from where we can configure the task within the context of our BPEL process:

The first value we need to specify is the Task Title. This is optional, since if we don't specify a value, it will use the task title we specified earlier as part of the task definition. We want to make the task title a bit friendlier, so first type in (without the quotes):

Leave Request for

Then click on the calculator icon to the right of the Task Title field. This will launch the now familiar Expression Builder. Here, from the inputVariable, just select the element:

ns1:LeaveRequest/ns1:fullName

This expression will be appended to the end of our title text embedded between <% %> to give the following:

Leave Request for <%bpws:getVariableData('inputVariable', 'payload', '/ns1:LeaveRequest/ns1:fullName')%>

At runtime, the BPEL process will evaluate the expression between <% %> and substitute the result. For now, we won't specify a task initiator as this is optional, and we will leave the Priority set to 3.

The final thing to specify is the value of each of the Task Parameters defined to the task. Click on the browse icon (…) for the LeaveRequest parameter, and this will bring up the Task Parameters window, which allows you to browse the variables defined to the BPEL process. Select the LeaveRequest element passed in as part of the inputVariable for the BPEL process.

This completes the configuration of the task, so click OK. This will return us to the BPEL process, which will now contain our human task activity, followed by an additional switch. If you expand the switch, you will see it contains a Case for each of our task outcomes (APPROVE or REJECT), where we can specify the appropriate next step in our process. For the purpose of this example, we don't need to do anything. However, in a real system we might update the HR system with details of the leave, if it was approved.

Your composite is now complete, so deploy it to the server in the normal way.

Creating the user interface to process the task

So far, we have defined the task that needs to be carried out and plugged it into a simple BPEL process. What we need to do next is implement the part of the user interface that allows someone to view the details of our specific task and then either approve or reject the leave request.

Out-of-the-box, SOA Suite provides the worklist application with all the main workflow user interface screens and a framework in which to plug your task-specific interface component. This can be developed from scratch if you want, using ADF, but the simplest way is to get JDeveloper to generate an ADF form based on the task definition.

To do this, go back to the task definition form, click on Create Form, and select Auto-Generate Task Form, as shown in the following screenshot:

This will launch the Create Project window, prompting us to specify the name of the project in which to create our form. Specify an appropriate name, such as LeaveRequestForm, and click OK.

This will generate an ADF form plus all the supporting components; JDeveloper will automatically open the form, which can then be customized as required.

To deploy the form, click on the Application menu (circled in the preceding screenshot) and select Deploy | LeaveRequestForm. This will launch the Deployment dialog. Select Deploy to Application Server, and click on Next. On the Select Server page, uncheck the option Deploy to all server instances in the domain and click on Next. On the Server Instances page, select the SOA server instance, click on Next, and then click Finish.

Running the workflow process

Log into the SOA console and launch the composite, ensuring that you specify a valid employee ID (such as jcooper). This will invoke the BPEL process, which in turn will create the LeaveRequest task.

If you browse the audit trail for the composite, you will see it paused at the LeaveRequest activity, as shown in the following screenshot:

Click on the LeaveRequest activity, and this will bring up the Activity Audit Trail for the workflow task, showing that it is assigned to cdickens, as shown in the following screenshot:

At the moment, the composite will wait forever, until the task is either approved or rejected. To do that, we need to log into the BPM worklist application to process the task.

Invoking our human task from BPEL

So far, we have defined our human task. The next step is to incorporate it into our LeaveApproval BPEL process. To do this, drag a Human Task activity from the BPEL component palette onto our process, as shown in the following screenshot:

JDeveloper will prompt us to specify the Task Definition to use for this activity; from the drop-down list, select LeaveRequest. This will present us with the Human Task activity window from where we can configure the task within the context of our BPEL process:

The first value we need to specify is the Task Title. This is optional, since if we don't specify a value, it will use the task title we specified earlier as part of the task definition. We want to make the task title a bit friendlier, so first type in (without the quotes):

Leave Request for

Then click on the calculator icon to the right of the Task Title field. This will launch the now familiar Expression Builder. Here, from the inputVariable, just select the element:

ns1:LeaveRequest/ns1:fullName

This expression will be appended to the end of our title text embedded between <% %> to give the following:

Leave Request for <%bpws:getVariableData('inputVariable', 'payload', '/ns1:LeaveRequest/ns1:fullName')%>

At runtime, the BPEL process will evaluate the expression between <% %> and substitute the result. For now, we won't specify a task initiator as this is optional, and we will leave the Priority set to 3.

The final thing to specify is the value of each of the Task Parameters defined to the task. Click on the browse icon (…) for the LeaveRequest parameter, and this will bring up the Task Parameters window, which allows you to browse the variables defined to the BPEL process. Select the LeaveRequest element passed in as part of the inputVariable for the BPEL process.

This completes the configuration of the task, so click OK. This will return us to the BPEL process, which will now contain our human task activity, followed by an additional switch. If you expand the switch, you will see it contains a Case for each of our task outcomes (APPROVE or REJECT), where we can specify the appropriate next step in our process. For the purpose of this example, we don't need to do anything. However, in a real system we might update the HR system with details of the leave, if it was approved.

Your composite is now complete, so deploy it to the server in the normal way.

Creating the user interface to process the task

So far, we have defined the task that needs to be carried out and plugged it into a simple BPEL process. What we need to do next is implement the part of the user interface that allows someone to view the details of our specific task and then either approve or reject the leave request.

Out-of-the-box, SOA Suite provides the worklist application with all the main workflow user interface screens and a framework in which to plug your task-specific interface component. This can be developed from scratch if you want, using ADF, but the simplest way is to get JDeveloper to generate an ADF form based on the task definition.

To do this, go back to the task definition form, click on Create Form, and select Auto-Generate Task Form, as shown in the following screenshot:

This will launch the Create Project window, prompting us to specify the name of the project in which to create our form. Specify an appropriate name, such as LeaveRequestForm, and click OK.

This will generate an ADF form plus all the supporting components; JDeveloper will automatically open the form, which can then be customized as required.

To deploy the form, click on the Application menu (circled in the preceding screenshot) and select Deploy | LeaveRequestForm. This will launch the Deployment dialog. Select Deploy to Application Server, and click on Next. On the Select Server page, uncheck the option Deploy to all server instances in the domain and click on Next. On the Server Instances page, select the SOA server instance, click on Next, and then click Finish.

Running the workflow process

Log into the SOA console and launch the composite, ensuring that you specify a valid employee ID (such as jcooper). This will invoke the BPEL process, which in turn will create the LeaveRequest task.

If you browse the audit trail for the composite, you will see it paused at the LeaveRequest activity, as shown in the following screenshot:

Click on the LeaveRequest activity, and this will bring up the Activity Audit Trail for the workflow task, showing that it is assigned to cdickens, as shown in the following screenshot:

At the moment, the composite will wait forever, until the task is either approved or rejected. To do that, we need to log into the BPM worklist application to process the task.

Creating the user interface to process the task

So far, we have defined the task that needs to be carried out and plugged it into a simple BPEL process. What we need to do next is implement the part of the user interface that allows someone to view the details of our specific task and then either approve or reject the leave request.

Out-of-the-box, SOA Suite provides the worklist application with all the main workflow user interface screens and a framework in which to plug your task-specific interface component. This can be developed from scratch if you want, using ADF, but the simplest way is to get JDeveloper to generate an ADF form based on the task definition.

To do this, go back to the task definition form, click on Create Form, and select Auto-Generate Task Form, as shown in the following screenshot:

This will launch the Create Project window, prompting us to specify the name of the project in which to create our form. Specify an appropriate name, such as LeaveRequestForm, and click OK.

This will generate an ADF form plus all the supporting components; JDeveloper will automatically open the form, which can then be customized as required.

To deploy the form, click on the Application menu (circled in the preceding screenshot) and select Deploy | LeaveRequestForm. This will launch the Deployment dialog. Select Deploy to Application Server, and click on Next. On the Select Server page, uncheck the option Deploy to all server instances in the domain and click on Next. On the Server Instances page, select the SOA server instance, click on Next, and then click Finish.

Running the workflow process

Log into the SOA console and launch the composite, ensuring that you specify a valid employee ID (such as jcooper). This will invoke the BPEL process, which in turn will create the LeaveRequest task.

If you browse the audit trail for the composite, you will see it paused at the LeaveRequest activity, as shown in the following screenshot:

Click on the LeaveRequest activity, and this will bring up the Activity Audit Trail for the workflow task, showing that it is assigned to cdickens, as shown in the following screenshot:

At the moment, the composite will wait forever, until the task is either approved or rejected. To do that, we need to log into the BPM worklist application to process the task.

Running the workflow process

Log into the SOA console and launch the composite, ensuring that you specify a valid employee ID (such as jcooper). This will invoke the BPEL process, which in turn will create the LeaveRequest task.

If you browse the audit trail for the composite, you will see it paused at the LeaveRequest activity, as shown in the following screenshot:

Click on the LeaveRequest activity, and this will bring up the Activity Audit Trail for the workflow task, showing that it is assigned to cdickens, as shown in the following screenshot:

At the moment, the composite will wait forever, until the task is either approved or rejected. To do that, we need to log into the BPM worklist application to process the task.

Processing tasks with the worklist application

To launch the worklist application, open up a browser and enter the following URL:

http://<hostname>:<port>/integration/worklistapp

This will bring up the login screen for the BPM worklist application; log in as cdickens (password welcome1). This will bring you into the My Tasks tab, which provides access to our various tasks and work queues. By default, it displays our inbox, which lists all the tasks currently allocated to us (or any groups that we belong to). We can then filter this based on assignee and task status.

The application also provides a number of other views that enable us to quickly identify high priority tasks, tasks due soon or new tasks. In addition, we can also define our own views.

Here, you should see the LeaveRequest task created by our process. Click on the task and it will display details of the task in the bottom pane of the page, like the one shown in the following screenshot:

If we study this, we can see it is made up of the following five areas:

• Actions: Contains the actions that can be performed on a task. This is split into two parts. The first is a drop-down list that lists standard actions available for tasks such as Escalate and Suspend, which we will examine later. The second is a set of buttons that correspond to each of the outcomes defined in the task definition (that is, Approve or Reject).
• Details: Contains the standard header information about the task, a summary of which was displayed for each task in our work queue. In the preceding screenshot this is minimized. To expand it, click on the > sign (circled in the preceding screenshot).
• Contents: This contains the task specific payload, in our case, details of the leave request. This may be editable, depending on how we configure the task.
• History: Provides a history (in tabular and pictorial form) of when the task was created, who it's been assigned to, and so on. This is useful as it provides a complete audit trail of the task. Note this is also available in the SOA console.
• Comments, Attachments: Here we can add comments or attach documents to the task. This can be especially useful when a task is exchanged between multiple participants.

For our purpose, we just want to approve or reject the task, so just click the appropriate button. This will complete the task and remove it from our work queue.

However, change the search filter for the task list to show tasks with a completed status and you will see that the task is still there. If you select the task, it will display its details in the task pane, where you can view the content of the task but no longer perform any actions as it is now complete.

Go back to the SOA console and look at the audit trail for the process, you will see that it is completed.

Improving the workflow

At this point, we have a simple workflow up and running. However, we have the following issues with it:

• At the moment, all requests go to the CEO, but it would be better if requests went to the applicant's manager.
• Also, what happens if the requester makes a mistake with his/her request, or changes their mind? How do we let the original requester amend or cancel their request?
• What if the approver needs additional information about a task, is there a simple way to enable that?

Dynamic task assignment

There are two approaches here. One is to assign the task to a specific group, which may contain one or more individuals. A classic example would be to assign a support request to the customer support group.

The other is to dynamically specify the user to assign to a task at runtime, based on the value of some parameter, which is roughly what we want to do. Actually, we want to look up the manager of the employee requesting the task and assign it to them.

If we go back to the Human Task Definition form (refer to Defining the human task section), and double-click on the Manager Approval step in the routing policy we defined, this will reopen the Edit Participant Type form. For the Data Type, specify that you want to select the participant By Expression, and then click on the browse icon for the Value field (circled in the following screenshot):

This will open up the Expression Builder , which was introduced in Chapter 5, Using BPEL to Build Composite Services and Business Processess. However, the key thing to notice here is that we only have access to the content of the task we are working on (not the full content of the BPEL process).

We need to create an expression that evaluates to the user ID of the employee's manager. Fortunately, one of the services that come with workflow is the identity service, which provides us with a simple way of querying the underlying identity layer to find out details about a user. In our case, we can use the getManager function to get the ID of the manager.

So within the Expression Builder, select the Identity Service Functions, and from here, select the getManager function and insert it into the expression. We now need to pass it the employee ID of whoever is requesting the leave. Expand the task payload; you will find it contains the content of the leave request. Select the employeeId and insert that as the parameter, as shown in the following screenshot:

You can now save the task, redeploy it, and run the process. Assuming you specify that the request is for jcooper, you will need to log in as jstein to approve the task.

Assigning tasks to multiple users or groups

So far, we have only looked at scenarios where we assign a task to a single user. However, workflow enables you to either assign a task to multiple users, or to one or more groups (or a combination of the two).

In this case, every user who is a member of the group or has the task assigned to them will be able to see the task on their queue. However, before anyone can work on the task, they must first claim it. Once claimed, other users will still be able to see the task, but only the user who has claimed the task will be able to perform any operations on it.

Note

Although group assignments are more likely to be static, you can also specify them dynamically in the same way we have for the user.

Cancelling or modifying a task

Another common requirement is to cancel or modify a task before it has completed the workflow. If we take our example, suppose that having submitted the leave request we changed our mind. Ideally we would like to be able to withdraw the task or modify it before someone goes to the effort of approving it.

Withdrawing a task

You may remember that when we first added the task to the BPEL process we had a field where we could specify a task initiator that we previously left blank. Well, if you specify a task initiator they are effectively the creator of the task and have the ability to withdraw the task.

To specify the task initiator, go back to your BPEL process and double-click on the Human Task. This will reopen the Human Task Configuration window (see Initializing the Workflow Parameter section), click the icon to the right of the initiator field, and this will launch the Expression Builder. Use this to specify the employeeId as the task initiator.

Now save the process, redeploy it, and run the process. Again, specify that the request is for jcooper, then log into the worklist application as jstein. You should notice that the task creator is jcooper. Don't approve the task, rather log out and log back into the worklist application as jcooper.

This will take you into the My Tasks tab, which is probably empty, but if you click the Initiated Tasks tab, then this will list all the tasks that you have initiated. If you look at the task, you will see that you can perform a single action on the task, which is to withdraw it.

Modifying a task

When we defined the task parameters on the task definition form, we had the option to specify if the parameters are Editable via Worklist, and at the time we didn't select this option. If this option is selected, then anyone who the task is assigned to has the ability to modify the task payload, including the task owner and initiator.

Difference between task owner and initiator

Now you may have noticed while specifying the various task details that as well as being able to specify the task initiator, we can also specify the task owner. At this point, you may be asking what is the difference between these two roles?

The simple answer is the task owner has more administrative privileges when it comes to a task. The task initiator is the person who creates a particular instance of a task. Say, in our example, jcooper and jstein both request leave. In this case, they are both initiators and can each withdraw the task they requested (but not each other's).

On the other hand, the task owner may be the holiday administrator. They are responsible for administering all leave requests. This enables them to perform operations on behalf of any of the assigned task participants; additionally they can also reassign or escalate tasks.

The task owner can either be specified as part of the task definition, or on the Advanced tab of the BPEL Human Task Configuration window.

Note

If no task owner is specified, it defaults to the system administrator.

When the task owner logs into the worklist application they will see an additional tab, Administration Tasks, which will list all the tasks for which they are the task owner.

Requesting additional information about a task

Once assigned a task, sometimes you need additional information about it, before you can complete it. In our example, the manager may need more information about the reason for the leave request.

If a task initiator has been specified, then on the Task details form we have the option of selecting Request Information. If we select this option we are presented with the Request More Information form, where we can select who we want more information from, and enter details of the information required (which will be added as a comment to the task).

This will then assign the task to the initiator. The task will then appear on the task creators work queue, with a state of Info Requested. The task creator can either update the details of the task (if allowed) or add their own comment to provide the additional information. Once done, they can choose the action Submit Information, and the task will be reassigned back to whoever requested the additional information.

This feature is automatically enabled when the task is opened. You can disable this feature if you want by overriding the default access settings for Actions in the Access tab of the task configuration form.

Note

We can request additional information, not just from the person who created the task, but anyone else who has already worked on the task or anyone else that we need further information from.

Dynamic task assignment

There are two approaches here. One is to assign the task to a specific group, which may contain one or more individuals. A classic example would be to assign a support request to the customer support group.

The other is to dynamically specify the user to assign to a task at runtime, based on the value of some parameter, which is roughly what we want to do. Actually, we want to look up the manager of the employee requesting the task and assign it to them.

If we go back to the Human Task Definition form (refer to Defining the human task section), and double-click on the Manager Approval step in the routing policy we defined, this will reopen the Edit Participant Type form. For the Data Type, specify that you want to select the participant By Expression, and then click on the browse icon for the Value field (circled in the following screenshot):

This will open up the Expression Builder , which was introduced in Chapter 5, Using BPEL to Build Composite Services and Business Processess. However, the key thing to notice here is that we only have access to the content of the task we are working on (not the full content of the BPEL process).

We need to create an expression that evaluates to the user ID of the employee's manager. Fortunately, one of the services that come with workflow is the identity service, which provides us with a simple way of querying the underlying identity layer to find out details about a user. In our case, we can use the getManager function to get the ID of the manager.

So within the Expression Builder, select the Identity Service Functions, and from here, select the getManager function and insert it into the expression. We now need to pass it the employee ID of whoever is requesting the leave. Expand the task payload; you will find it contains the content of the leave request. Select the employeeId and insert that as the parameter, as shown in the following screenshot:

You can now save the task, redeploy it, and run the process. Assuming you specify that the request is for jcooper, you will need to log in as jstein to approve the task.

Assigning tasks to multiple users or groups

So far, we have only looked at scenarios where we assign a task to a single user. However, workflow enables you to either assign a task to multiple users, or to one or more groups (or a combination of the two).

In this case, every user who is a member of the group or has the task assigned to them will be able to see the task on their queue. However, before anyone can work on the task, they must first claim it. Once claimed, other users will still be able to see the task, but only the user who has claimed the task will be able to perform any operations on it.

Note

Although group assignments are more likely to be static, you can also specify them dynamically in the same way we have for the user.

Cancelling or modifying a task

Another common requirement is to cancel or modify a task before it has completed the workflow. If we take our example, suppose that having submitted the leave request we changed our mind. Ideally we would like to be able to withdraw the task or modify it before someone goes to the effort of approving it.

Withdrawing a task

You may remember that when we first added the task to the BPEL process we had a field where we could specify a task initiator that we previously left blank. Well, if you specify a task initiator they are effectively the creator of the task and have the ability to withdraw the task.

To specify the task initiator, go back to your BPEL process and double-click on the Human Task. This will reopen the Human Task Configuration window (see Initializing the Workflow Parameter section), click the icon to the right of the initiator field, and this will launch the Expression Builder. Use this to specify the employeeId as the task initiator.

Now save the process, redeploy it, and run the process. Again, specify that the request is for jcooper, then log into the worklist application as jstein. You should notice that the task creator is jcooper. Don't approve the task, rather log out and log back into the worklist application as jcooper.

This will take you into the My Tasks tab, which is probably empty, but if you click the Initiated Tasks tab, then this will list all the tasks that you have initiated. If you look at the task, you will see that you can perform a single action on the task, which is to withdraw it.

Modifying a task

When we defined the task parameters on the task definition form, we had the option to specify if the parameters are Editable via Worklist, and at the time we didn't select this option. If this option is selected, then anyone who the task is assigned to has the ability to modify the task payload, including the task owner and initiator.

Difference between task owner and initiator

Now you may have noticed while specifying the various task details that as well as being able to specify the task initiator, we can also specify the task owner. At this point, you may be asking what is the difference between these two roles?

The simple answer is the task owner has more administrative privileges when it comes to a task. The task initiator is the person who creates a particular instance of a task. Say, in our example, jcooper and jstein both request leave. In this case, they are both initiators and can each withdraw the task they requested (but not each other's).

On the other hand, the task owner may be the holiday administrator. They are responsible for administering all leave requests. This enables them to perform operations on behalf of any of the assigned task participants; additionally they can also reassign or escalate tasks.

The task owner can either be specified as part of the task definition, or on the Advanced tab of the BPEL Human Task Configuration window.

Note

If no task owner is specified, it defaults to the system administrator.

When the task owner logs into the worklist application they will see an additional tab, Administration Tasks, which will list all the tasks for which they are the task owner.

Requesting additional information about a task

Once assigned a task, sometimes you need additional information about it, before you can complete it. In our example, the manager may need more information about the reason for the leave request.

If a task initiator has been specified, then on the Task details form we have the option of selecting Request Information. If we select this option we are presented with the Request More Information form, where we can select who we want more information from, and enter details of the information required (which will be added as a comment to the task).

This will then assign the task to the initiator. The task will then appear on the task creators work queue, with a state of Info Requested. The task creator can either update the details of the task (if allowed) or add their own comment to provide the additional information. Once done, they can choose the action Submit Information, and the task will be reassigned back to whoever requested the additional information.

This feature is automatically enabled when the task is opened. You can disable this feature if you want by overriding the default access settings for Actions in the Access tab of the task configuration form.

Note

We can request additional information, not just from the person who created the task, but anyone else who has already worked on the task or anyone else that we need further information from.

Assigning tasks to multiple users or groups

So far, we have only looked at scenarios where we assign a task to a single user. However, workflow enables you to either assign a task to multiple users, or to one or more groups (or a combination of the two).

In this case, every user who is a member of the group or has the task assigned to them will be able to see the task on their queue. However, before anyone can work on the task, they must first claim it. Once claimed, other users will still be able to see the task, but only the user who has claimed the task will be able to perform any operations on it.

Note

Although group assignments are more likely to be static, you can also specify them dynamically in the same way we have for the user.

Cancelling or modifying a task

Another common requirement is to cancel or modify a task before it has completed the workflow. If we take our example, suppose that having submitted the leave request we changed our mind. Ideally we would like to be able to withdraw the task or modify it before someone goes to the effort of approving it.

Withdrawing a task

You may remember that when we first added the task to the BPEL process we had a field where we could specify a task initiator that we previously left blank. Well, if you specify a task initiator they are effectively the creator of the task and have the ability to withdraw the task.

To specify the task initiator, go back to your BPEL process and double-click on the Human Task. This will reopen the Human Task Configuration window (see Initializing the Workflow Parameter section), click the icon to the right of the initiator field, and this will launch the Expression Builder. Use this to specify the employeeId as the task initiator.

Now save the process, redeploy it, and run the process. Again, specify that the request is for jcooper, then log into the worklist application as jstein. You should notice that the task creator is jcooper. Don't approve the task, rather log out and log back into the worklist application as jcooper.

This will take you into the My Tasks tab, which is probably empty, but if you click the Initiated Tasks tab, then this will list all the tasks that you have initiated. If you look at the task, you will see that you can perform a single action on the task, which is to withdraw it.

Modifying a task

When we defined the task parameters on the task definition form, we had the option to specify if the parameters are Editable via Worklist, and at the time we didn't select this option. If this option is selected, then anyone who the task is assigned to has the ability to modify the task payload, including the task owner and initiator.

Difference between task owner and initiator

Now you may have noticed while specifying the various task details that as well as being able to specify the task initiator, we can also specify the task owner. At this point, you may be asking what is the difference between these two roles?

The simple answer is the task owner has more administrative privileges when it comes to a task. The task initiator is the person who creates a particular instance of a task. Say, in our example, jcooper and jstein both request leave. In this case, they are both initiators and can each withdraw the task they requested (but not each other's).

On the other hand, the task owner may be the holiday administrator. They are responsible for administering all leave requests. This enables them to perform operations on behalf of any of the assigned task participants; additionally they can also reassign or escalate tasks.

The task owner can either be specified as part of the task definition, or on the Advanced tab of the BPEL Human Task Configuration window.

Note

If no task owner is specified, it defaults to the system administrator.

When the task owner logs into the worklist application they will see an additional tab, Administration Tasks, which will list all the tasks for which they are the task owner.

Requesting additional information about a task

Once assigned a task, sometimes you need additional information about it, before you can complete it. In our example, the manager may need more information about the reason for the leave request.

If a task initiator has been specified, then on the Task details form we have the option of selecting Request Information. If we select this option we are presented with the Request More Information form, where we can select who we want more information from, and enter details of the information required (which will be added as a comment to the task).

This will then assign the task to the initiator. The task will then appear on the task creators work queue, with a state of Info Requested. The task creator can either update the details of the task (if allowed) or add their own comment to provide the additional information. Once done, they can choose the action Submit Information, and the task will be reassigned back to whoever requested the additional information.

This feature is automatically enabled when the task is opened. You can disable this feature if you want by overriding the default access settings for Actions in the Access tab of the task configuration form.

Note

We can request additional information, not just from the person who created the task, but anyone else who has already worked on the task or anyone else that we need further information from.

Cancelling or modifying a task

Another common requirement is to cancel or modify a task before it has completed the workflow. If we take our example, suppose that having submitted the leave request we changed our mind. Ideally we would like to be able to withdraw the task or modify it before someone goes to the effort of approving it.

Withdrawing a task

You may remember that when we first added the task to the BPEL process we had a field where we could specify a task initiator that we previously left blank. Well, if you specify a task initiator they are effectively the creator of the task and have the ability to withdraw the task.

To specify the task initiator, go back to your BPEL process and double-click on the Human Task. This will reopen the Human Task Configuration window (see Initializing the Workflow Parameter section), click the icon to the right of the initiator field, and this will launch the Expression Builder. Use this to specify the employeeId as the task initiator.

Now save the process, redeploy it, and run the process. Again, specify that the request is for jcooper, then log into the worklist application as jstein. You should notice that the task creator is jcooper. Don't approve the task, rather log out and log back into the worklist application as jcooper.

This will take you into the My Tasks tab, which is probably empty, but if you click the Initiated Tasks tab, then this will list all the tasks that you have initiated. If you look at the task, you will see that you can perform a single action on the task, which is to withdraw it.

Modifying a task

When we defined the task parameters on the task definition form, we had the option to specify if the parameters are Editable via Worklist, and at the time we didn't select this option. If this option is selected, then anyone who the task is assigned to has the ability to modify the task payload, including the task owner and initiator.

Difference between task owner and initiator

Now you may have noticed while specifying the various task details that as well as being able to specify the task initiator, we can also specify the task owner. At this point, you may be asking what is the difference between these two roles?

The simple answer is the task owner has more administrative privileges when it comes to a task. The task initiator is the person who creates a particular instance of a task. Say, in our example, jcooper and jstein both request leave. In this case, they are both initiators and can each withdraw the task they requested (but not each other's).

On the other hand, the task owner may be the holiday administrator. They are responsible for administering all leave requests. This enables them to perform operations on behalf of any of the assigned task participants; additionally they can also reassign or escalate tasks.

The task owner can either be specified as part of the task definition, or on the Advanced tab of the BPEL Human Task Configuration window.

Note

If no task owner is specified, it defaults to the system administrator.

When the task owner logs into the worklist application they will see an additional tab, Administration Tasks, which will list all the tasks for which they are the task owner.

Requesting additional information about a task

Once assigned a task, sometimes you need additional information about it, before you can complete it. In our example, the manager may need more information about the reason for the leave request.

If a task initiator has been specified, then on the Task details form we have the option of selecting Request Information. If we select this option we are presented with the Request More Information form, where we can select who we want more information from, and enter details of the information required (which will be added as a comment to the task).

This will then assign the task to the initiator. The task will then appear on the task creators work queue, with a state of Info Requested. The task creator can either update the details of the task (if allowed) or add their own comment to provide the additional information. Once done, they can choose the action Submit Information, and the task will be reassigned back to whoever requested the additional information.

This feature is automatically enabled when the task is opened. You can disable this feature if you want by overriding the default access settings for Actions in the Access tab of the task configuration form.

Note

We can request additional information, not just from the person who created the task, but anyone else who has already worked on the task or anyone else that we need further information from.

Withdrawing a task

You may remember that when we first added the task to the BPEL process we had a field where we could specify a task initiator that we previously left blank. Well, if you specify a task initiator they are effectively the creator of the task and have the ability to withdraw the task.

To specify the task initiator, go back to your BPEL process and double-click on the Human Task. This will reopen the Human Task Configuration window (see Initializing the Workflow Parameter section), click the icon to the right of the initiator field, and this will launch the Expression Builder. Use this to specify the employeeId as the task initiator.

Now save the process, redeploy it, and run the process. Again, specify that the request is for jcooper, then log into the worklist application as jstein. You should notice that the task creator is jcooper. Don't approve the task, rather log out and log back into the worklist application as jcooper.

This will take you into the My Tasks tab, which is probably empty, but if you click the Initiated Tasks tab, then this will list all the tasks that you have initiated. If you look at the task, you will see that you can perform a single action on the task, which is to withdraw it.

Modifying a task

When we defined the task parameters on the task definition form, we had the option to specify if the parameters are Editable via Worklist, and at the time we didn't select this option. If this option is selected, then anyone who the task is assigned to has the ability to modify the task payload, including the task owner and initiator.

Difference between task owner and initiator

Now you may have noticed while specifying the various task details that as well as being able to specify the task initiator, we can also specify the task owner. At this point, you may be asking what is the difference between these two roles?

The simple answer is the task owner has more administrative privileges when it comes to a task. The task initiator is the person who creates a particular instance of a task. Say, in our example, jcooper and jstein both request leave. In this case, they are both initiators and can each withdraw the task they requested (but not each other's).

On the other hand, the task owner may be the holiday administrator. They are responsible for administering all leave requests. This enables them to perform operations on behalf of any of the assigned task participants; additionally they can also reassign or escalate tasks.

The task owner can either be specified as part of the task definition, or on the Advanced tab of the BPEL Human Task Configuration window.

Note

If no task owner is specified, it defaults to the system administrator.

When the task owner logs into the worklist application they will see an additional tab, Administration Tasks, which will list all the tasks for which they are the task owner.

Requesting additional information about a task

Once assigned a task, sometimes you need additional information about it, before you can complete it. In our example, the manager may need more information about the reason for the leave request.

If a task initiator has been specified, then on the Task details form we have the option of selecting Request Information. If we select this option we are presented with the Request More Information form, where we can select who we want more information from, and enter details of the information required (which will be added as a comment to the task).

This will then assign the task to the initiator. The task will then appear on the task creators work queue, with a state of Info Requested. The task creator can either update the details of the task (if allowed) or add their own comment to provide the additional information. Once done, they can choose the action Submit Information, and the task will be reassigned back to whoever requested the additional information.

This feature is automatically enabled when the task is opened. You can disable this feature if you want by overriding the default access settings for Actions in the Access tab of the task configuration form.

Note

We can request additional information, not just from the person who created the task, but anyone else who has already worked on the task or anyone else that we need further information from.

Modifying a task

When we defined the task parameters on the task definition form, we had the option to specify if the parameters are Editable via Worklist, and at the time we didn't select this option. If this option is selected, then anyone who the task is assigned to has the ability to modify the task payload, including the task owner and initiator.

Difference between task owner and initiator

Now you may have noticed while specifying the various task details that as well as being able to specify the task initiator, we can also specify the task owner. At this point, you may be asking what is the difference between these two roles?

The simple answer is the task owner has more administrative privileges when it comes to a task. The task initiator is the person who creates a particular instance of a task. Say, in our example, jcooper and jstein both request leave. In this case, they are both initiators and can each withdraw the task they requested (but not each other's).

On the other hand, the task owner may be the holiday administrator. They are responsible for administering all leave requests. This enables them to perform operations on behalf of any of the assigned task participants; additionally they can also reassign or escalate tasks.

The task owner can either be specified as part of the task definition, or on the Advanced tab of the BPEL Human Task Configuration window.

Note

If no task owner is specified, it defaults to the system administrator.

When the task owner logs into the worklist application they will see an additional tab, Administration Tasks, which will list all the tasks for which they are the task owner.

Requesting additional information about a task

Once assigned a task, sometimes you need additional information about it, before you can complete it. In our example, the manager may need more information about the reason for the leave request.

If a task initiator has been specified, then on the Task details form we have the option of selecting Request Information. If we select this option we are presented with the Request More Information form, where we can select who we want more information from, and enter details of the information required (which will be added as a comment to the task).

This will then assign the task to the initiator. The task will then appear on the task creators work queue, with a state of Info Requested. The task creator can either update the details of the task (if allowed) or add their own comment to provide the additional information. Once done, they can choose the action Submit Information, and the task will be reassigned back to whoever requested the additional information.

This feature is automatically enabled when the task is opened. You can disable this feature if you want by overriding the default access settings for Actions in the Access tab of the task configuration form.

Note

We can request additional information, not just from the person who created the task, but anyone else who has already worked on the task or anyone else that we need further information from.

Difference between task owner and initiator

Now you may have noticed while specifying the various task details that as well as being able to specify the task initiator, we can also specify the task owner. At this point, you may be asking what is the difference between these two roles?

The simple answer is the task owner has more administrative privileges when it comes to a task. The task initiator is the person who creates a particular instance of a task. Say, in our example, jcooper and jstein both request leave. In this case, they are both initiators and can each withdraw the task they requested (but not each other's).

On the other hand, the task owner may be the holiday administrator. They are responsible for administering all leave requests. This enables them to perform operations on behalf of any of the assigned task participants; additionally they can also reassign or escalate tasks.

The task owner can either be specified as part of the task definition, or on the Advanced tab of the BPEL Human Task Configuration window.

Note

If no task owner is specified, it defaults to the system administrator.

When the task owner logs into the worklist application they will see an additional tab, Administration Tasks, which will list all the tasks for which they are the task owner.

Requesting additional information about a task

Once assigned a task, sometimes you need additional information about it, before you can complete it. In our example, the manager may need more information about the reason for the leave request.

If a task initiator has been specified, then on the Task details form we have the option of selecting Request Information. If we select this option we are presented with the Request More Information form, where we can select who we want more information from, and enter details of the information required (which will be added as a comment to the task).

This will then assign the task to the initiator. The task will then appear on the task creators work queue, with a state of Info Requested. The task creator can either update the details of the task (if allowed) or add their own comment to provide the additional information. Once done, they can choose the action Submit Information, and the task will be reassigned back to whoever requested the additional information.

This feature is automatically enabled when the task is opened. You can disable this feature if you want by overriding the default access settings for Actions in the Access tab of the task configuration form.

Note

We can request additional information, not just from the person who created the task, but anyone else who has already worked on the task or anyone else that we need further information from.

Requesting additional information about a task

Once assigned a task, sometimes you need additional information about it, before you can complete it. In our example, the manager may need more information about the reason for the leave request.

If a task initiator has been specified, then on the Task details form we have the option of selecting Request Information. If we select this option we are presented with the Request More Information form, where we can select who we want more information from, and enter details of the information required (which will be added as a comment to the task).

This will then assign the task to the initiator. The task will then appear on the task creators work queue, with a state of Info Requested. The task creator can either update the details of the task (if allowed) or add their own comment to provide the additional information. Once done, they can choose the action Submit Information, and the task will be reassigned back to whoever requested the additional information.

This feature is automatically enabled when the task is opened. You can disable this feature if you want by overriding the default access settings for Actions in the Access tab of the task configuration form.

Note

We can request additional information, not just from the person who created the task, but anyone else who has already worked on the task or anyone else that we need further information from.

Managing the assignment of tasks

There is often a requirement to reassign tasks; maybe the task approver is about to go on leave themselves. Before they go, they may want to reassign all uncompleted tasks so they can be dealt with by someone else while they are away.

Alternatively, the individual may have already gone on leave (or be indisposed for some other reason) with a series of tasks already on their queue, which their manager may need to reassign to someone else.

Depending on a user's privileges and whether they are a manager, the worklist application provides a number of methods for either reassigning, delegating, or escalating tasks. We will examine these in detail below.

Reassigning reportee tasks

If a user has any direct reports, then the worklist application will treat them as a manager. This will give them additional privileges to work on tasks that are either assigned to any of their direct reports or groups that they own.

Within the work list application, managers have the additional tab, My Staff Tasks. If they select this, it will list all tasks currently assigned to any of their reports.

The list can be further filtered by selecting Advanced Search and specifying an appropriate query. For example, you could just show tasks assigned to a particular user or high priority tasks about to expire.

The manager has two basic options when it comes to staff tasks, they can either work on the task directly themselves, where they can carry out the same sets of actions as the assignee. Alternatively, they can choose to reassign the task to another of their direct reports or to any of the groups that they own.

To see how we do this, log in as wfaulk (jstein's manager), and click on My Staff Tasks. Select the task(s) you want to reassign; then from the Actions drop-down list, select Reassign. This will open the Reassign Task window, as shown in the following screenshot:

Here we have the option to either Reassign or Delegate the task. Stick with the Reassign option for the time being, as we will look at delegation shortly.

The remainder of the screen allows us to search for the users and or groups that we want to reassign the task to. You can choose to search just Users or Groups. In addition, you can further filter the list on the ID of the user or group, as well as the first name or last name of the user.

When specifying the search criteria, you can use a * to match any character. For example, the pattern st* will bring back the list of users whose user ID, first, or last name begin with st.

You will also notice that if you select a user, the Details panel will display basic information about the user, including their Manager, Reportees, and any Roles they have.

Use the arrows to move users/groups that you wish to reassign the task to from the search results box to the Selected box, and then click OK.

Reassigning your own task

In addition to reassigning staff tasks, any user can reassign their own tasks. To do this, they simply open the task from their task list as normal and select the Reassign option from the Action drop-down list. This will bring up the Reassign Task form that we just looked at.

An important point here is that the same restrictions on who a user can assign a task to apply regardless of whether it's the user's own task or a task belonging to one of their reportees.

Thus, users who have no direct reports will not be able to reassign their task to any other user. However, if they are a group owner, they will still have the ability to reassign the task to the group.

Note

If a user has the role "BPMWorkflowReassign", then they are allowed to reassign a task to anyone.

Delegating tasks

The other option we have when reassigning a task is to delegate it. This is very similar to reassigning a task, but with a number of key differences as follows:

• You can only delegate a task to a single user
• You cannot delegate a task to a group
• You can delegate a task to anyone regardless of where they are in the organizational hierarchy

When you delegate a task it is assigned to a new user, but it also remains on your work queue so that either you or the delegated user can work on the task.

Escalating tasks

There will often be cases where a user needs to escalate the task. To do this, they simply select the task from their task list as normal and choose Escalate from the Action drop-down list. This will reassign the task to the user's manager.

Note

Tasks can also be automatically escalated, usually if not handled within a specified period of time. This is specified in Expiration and Escalation Policy, which forms part of the task definition.

Using rules to automatically manage tasks

Even though it's possible to manually reassign tasks, this can be inefficient and time-consuming. An alternative approach is to automate this using workflow rules.

You can either define a rule to be applied to a particular task type (for example our leave request) or to all tasks. In addition, you can also specify when a rule is active, which can be during vacation periods, for a specified time period, or active all the time (which is the default).

You can specify various filter criteria that are applied to the task attributes (for example, priority, initiator, acquired by) to further restrict which tasks the rule applies to.

Once you've specified the matching criteria for a rule, you can then specify whether you want to reassign or delegate the task. Essentially, the same criteria applies to whomever you are allowed to reassign a task to (if you were to do it manually, as covered in the previous section, with the added caveat that you can only reassign a task to a single user or group).

For rules defined for a particular task type, we have the option of being able to automatically set the task outcome. In the case of our leave request task, we can write a rule to automatically approve all leave requests that are one day in duration.

The final option is to take no action, which may seem a bit strange. However, this serves a couple of useful purposes. Often you only want a rule to be active at certain periods of time. One way to do this is to just specify a date range. An alternative is to use this to turn the rule on and off, as required over time.

The other use comes in when you define multiple rules. Rules are evaluated in order against a task until a rule is found that matches a particular task.

For example, to create a rule that reassigned all tasks, except say an expense approval task, you would do the following. Define two rules, a generic rule to reassign any task and a specific rule that matched the expense approval task that did nothing. We would then order the rules so that the expense approval rule triggered first. This way, the generic rule to reassign a task would be triggered for all tasks except the expense approval task.

Setting up a sample rule

For example, let's say Robert Stevenson (user ID rsteven) is John Steinbeck's deputy, and we want to create a rule that reassigns all leave requests assigned to jstein to rsteven except for any leave request made by rsteven.

To do this, you log onto the worklist application as jstein, and click on the Preferences link on the top-right-hand corner of the worklist title bar. This will bring you into the My Rules tab, where a user can configure various rules for managing the assignment of tasks. By default it displays the users currently defined Vacation Period (which in this case is disabled).

Select the My Rules folder (below Vacation Period (Disabled)), and click on the plus icon (circled in the preceding screenshot). This will display the template for defining a new rule.

Enter a suitable name for the rule, but leave the checkbox Use as vacation rule unchecked. If we were to check this, then the rule would only be active during the user's vacation period.

Next we want to specify which tasks the rule should apply to. Click on the search icon to the right and this will pop up the Task Type Browser, where we can search for the required task type. Select the LeaveRequest task for the process default/LeaveApproval/1.0.

We will not specify a time period for the rule, as we want it to be active all the time. We now need to specify the conditions that apply to the rule and the appropriate action to take. First let's add the condition to prevent the rule reassigning leave requests made by rsteven.

From the Add Condition drop-down list, select the task attribute to which we want to apply the rule, which is, in our case, the Creator (that is, the task initiator), and then click the plus icon (circled in the following screenshot):

This will insert a condition line for testing the Creator attribute into our rule, as shown in the following screenshot:

In the drop-down list, select the test to be applied to the attribute. So in our case, we select isn't and finally specify the user (rsteven). You can either directly enter the user ID or click the magnifying glass icon to search for the user with the user search facility we introduced earlier.

Finally, specify the task action, which is to reassign the task to rsteven. Your rule description should now look like the one shown in the following screenshot:

Finally, click on Save to create the rule. Once you have created the rule, try creating two leave requests, one for jcooper and another for rsteven. You should see that only the request created for jcooper is reassigned to rsteven.

Log in as rsteven, and select the leave request that has been reassigned to that user. If you examine the full task history, you will see that it shows which rule was triggered to cause the task to be reassigned.

Note

A user can also specify rule conditions against the content of the task payload through the use of flex fields, as well as define rules for any groups that they own. We will examine flex fields in Chapter 17, Workflow Patterns.

Reassigning reportee tasks

If a user has any direct reports, then the worklist application will treat them as a manager. This will give them additional privileges to work on tasks that are either assigned to any of their direct reports or groups that they own.

Within the work list application, managers have the additional tab, My Staff Tasks. If they select this, it will list all tasks currently assigned to any of their reports.

The list can be further filtered by selecting Advanced Search and specifying an appropriate query. For example, you could just show tasks assigned to a particular user or high priority tasks about to expire.

The manager has two basic options when it comes to staff tasks, they can either work on the task directly themselves, where they can carry out the same sets of actions as the assignee. Alternatively, they can choose to reassign the task to another of their direct reports or to any of the groups that they own.

To see how we do this, log in as wfaulk (jstein's manager), and click on My Staff Tasks. Select the task(s) you want to reassign; then from the Actions drop-down list, select Reassign. This will open the Reassign Task window, as shown in the following screenshot:

Here we have the option to either Reassign or Delegate the task. Stick with the Reassign option for the time being, as we will look at delegation shortly.

The remainder of the screen allows us to search for the users and or groups that we want to reassign the task to. You can choose to search just Users or Groups. In addition, you can further filter the list on the ID of the user or group, as well as the first name or last name of the user.

When specifying the search criteria, you can use a * to match any character. For example, the pattern st* will bring back the list of users whose user ID, first, or last name begin with st.

You will also notice that if you select a user, the Details panel will display basic information about the user, including their Manager, Reportees, and any Roles they have.

Use the arrows to move users/groups that you wish to reassign the task to from the search results box to the Selected box, and then click OK.

Reassigning your own task

In addition to reassigning staff tasks, any user can reassign their own tasks. To do this, they simply open the task from their task list as normal and select the Reassign option from the Action drop-down list. This will bring up the Reassign Task form that we just looked at.

An important point here is that the same restrictions on who a user can assign a task to apply regardless of whether it's the user's own task or a task belonging to one of their reportees.

Thus, users who have no direct reports will not be able to reassign their task to any other user. However, if they are a group owner, they will still have the ability to reassign the task to the group.

Note

If a user has the role "BPMWorkflowReassign", then they are allowed to reassign a task to anyone.

Delegating tasks

The other option we have when reassigning a task is to delegate it. This is very similar to reassigning a task, but with a number of key differences as follows:

• You can only delegate a task to a single user
• You cannot delegate a task to a group
• You can delegate a task to anyone regardless of where they are in the organizational hierarchy

When you delegate a task it is assigned to a new user, but it also remains on your work queue so that either you or the delegated user can work on the task.

Escalating tasks

There will often be cases where a user needs to escalate the task. To do this, they simply select the task from their task list as normal and choose Escalate from the Action drop-down list. This will reassign the task to the user's manager.

Note

Tasks can also be automatically escalated, usually if not handled within a specified period of time. This is specified in Expiration and Escalation Policy, which forms part of the task definition.

Using rules to automatically manage tasks

Even though it's possible to manually reassign tasks, this can be inefficient and time-consuming. An alternative approach is to automate this using workflow rules.

You can either define a rule to be applied to a particular task type (for example our leave request) or to all tasks. In addition, you can also specify when a rule is active, which can be during vacation periods, for a specified time period, or active all the time (which is the default).

You can specify various filter criteria that are applied to the task attributes (for example, priority, initiator, acquired by) to further restrict which tasks the rule applies to.

Once you've specified the matching criteria for a rule, you can then specify whether you want to reassign or delegate the task. Essentially, the same criteria applies to whomever you are allowed to reassign a task to (if you were to do it manually, as covered in the previous section, with the added caveat that you can only reassign a task to a single user or group).

For rules defined for a particular task type, we have the option of being able to automatically set the task outcome. In the case of our leave request task, we can write a rule to automatically approve all leave requests that are one day in duration.

The final option is to take no action, which may seem a bit strange. However, this serves a couple of useful purposes. Often you only want a rule to be active at certain periods of time. One way to do this is to just specify a date range. An alternative is to use this to turn the rule on and off, as required over time.

The other use comes in when you define multiple rules. Rules are evaluated in order against a task until a rule is found that matches a particular task.

For example, to create a rule that reassigned all tasks, except say an expense approval task, you would do the following. Define two rules, a generic rule to reassign any task and a specific rule that matched the expense approval task that did nothing. We would then order the rules so that the expense approval rule triggered first. This way, the generic rule to reassign a task would be triggered for all tasks except the expense approval task.

Setting up a sample rule

For example, let's say Robert Stevenson (user ID rsteven) is John Steinbeck's deputy, and we want to create a rule that reassigns all leave requests assigned to jstein to rsteven except for any leave request made by rsteven.

To do this, you log onto the worklist application as jstein, and click on the Preferences link on the top-right-hand corner of the worklist title bar. This will bring you into the My Rules tab, where a user can configure various rules for managing the assignment of tasks. By default it displays the users currently defined Vacation Period (which in this case is disabled).

Select the My Rules folder (below Vacation Period (Disabled)), and click on the plus icon (circled in the preceding screenshot). This will display the template for defining a new rule.

Enter a suitable name for the rule, but leave the checkbox Use as vacation rule unchecked. If we were to check this, then the rule would only be active during the user's vacation period.

Next we want to specify which tasks the rule should apply to. Click on the search icon to the right and this will pop up the Task Type Browser, where we can search for the required task type. Select the LeaveRequest task for the process default/LeaveApproval/1.0.

We will not specify a time period for the rule, as we want it to be active all the time. We now need to specify the conditions that apply to the rule and the appropriate action to take. First let's add the condition to prevent the rule reassigning leave requests made by rsteven.

From the Add Condition drop-down list, select the task attribute to which we want to apply the rule, which is, in our case, the Creator (that is, the task initiator), and then click the plus icon (circled in the following screenshot):

This will insert a condition line for testing the Creator attribute into our rule, as shown in the following screenshot:

In the drop-down list, select the test to be applied to the attribute. So in our case, we select isn't and finally specify the user (rsteven). You can either directly enter the user ID or click the magnifying glass icon to search for the user with the user search facility we introduced earlier.

Finally, specify the task action, which is to reassign the task to rsteven. Your rule description should now look like the one shown in the following screenshot:

Finally, click on Save to create the rule. Once you have created the rule, try creating two leave requests, one for jcooper and another for rsteven. You should see that only the request created for jcooper is reassigned to rsteven.

Log in as rsteven, and select the leave request that has been reassigned to that user. If you examine the full task history, you will see that it shows which rule was triggered to cause the task to be reassigned.

Note

A user can also specify rule conditions against the content of the task payload through the use of flex fields, as well as define rules for any groups that they own. We will examine flex fields in Chapter 17, Workflow Patterns.

Reassigning your own task

In addition to reassigning staff tasks, any user can reassign their own tasks. To do this, they simply open the task from their task list as normal and select the Reassign option from the Action drop-down list. This will bring up the Reassign Task form that we just looked at.

An important point here is that the same restrictions on who a user can assign a task to apply regardless of whether it's the user's own task or a task belonging to one of their reportees.

Thus, users who have no direct reports will not be able to reassign their task to any other user. However, if they are a group owner, they will still have the ability to reassign the task to the group.

Note

If a user has the role "BPMWorkflowReassign", then they are allowed to reassign a task to anyone.

Delegating tasks

The other option we have when reassigning a task is to delegate it. This is very similar to reassigning a task, but with a number of key differences as follows:

• You can only delegate a task to a single user
• You cannot delegate a task to a group
• You can delegate a task to anyone regardless of where they are in the organizational hierarchy

When you delegate a task it is assigned to a new user, but it also remains on your work queue so that either you or the delegated user can work on the task.

Escalating tasks

There will often be cases where a user needs to escalate the task. To do this, they simply select the task from their task list as normal and choose Escalate from the Action drop-down list. This will reassign the task to the user's manager.

Note

Tasks can also be automatically escalated, usually if not handled within a specified period of time. This is specified in Expiration and Escalation Policy, which forms part of the task definition.

Using rules to automatically manage tasks

Even though it's possible to manually reassign tasks, this can be inefficient and time-consuming. An alternative approach is to automate this using workflow rules.

You can either define a rule to be applied to a particular task type (for example our leave request) or to all tasks. In addition, you can also specify when a rule is active, which can be during vacation periods, for a specified time period, or active all the time (which is the default).

You can specify various filter criteria that are applied to the task attributes (for example, priority, initiator, acquired by) to further restrict which tasks the rule applies to.

Once you've specified the matching criteria for a rule, you can then specify whether you want to reassign or delegate the task. Essentially, the same criteria applies to whomever you are allowed to reassign a task to (if you were to do it manually, as covered in the previous section, with the added caveat that you can only reassign a task to a single user or group).

For rules defined for a particular task type, we have the option of being able to automatically set the task outcome. In the case of our leave request task, we can write a rule to automatically approve all leave requests that are one day in duration.

The final option is to take no action, which may seem a bit strange. However, this serves a couple of useful purposes. Often you only want a rule to be active at certain periods of time. One way to do this is to just specify a date range. An alternative is to use this to turn the rule on and off, as required over time.

The other use comes in when you define multiple rules. Rules are evaluated in order against a task until a rule is found that matches a particular task.

For example, to create a rule that reassigned all tasks, except say an expense approval task, you would do the following. Define two rules, a generic rule to reassign any task and a specific rule that matched the expense approval task that did nothing. We would then order the rules so that the expense approval rule triggered first. This way, the generic rule to reassign a task would be triggered for all tasks except the expense approval task.

Setting up a sample rule

For example, let's say Robert Stevenson (user ID rsteven) is John Steinbeck's deputy, and we want to create a rule that reassigns all leave requests assigned to jstein to rsteven except for any leave request made by rsteven.

To do this, you log onto the worklist application as jstein, and click on the Preferences link on the top-right-hand corner of the worklist title bar. This will bring you into the My Rules tab, where a user can configure various rules for managing the assignment of tasks. By default it displays the users currently defined Vacation Period (which in this case is disabled).

Select the My Rules folder (below Vacation Period (Disabled)), and click on the plus icon (circled in the preceding screenshot). This will display the template for defining a new rule.

Enter a suitable name for the rule, but leave the checkbox Use as vacation rule unchecked. If we were to check this, then the rule would only be active during the user's vacation period.

Next we want to specify which tasks the rule should apply to. Click on the search icon to the right and this will pop up the Task Type Browser, where we can search for the required task type. Select the LeaveRequest task for the process default/LeaveApproval/1.0.

We will not specify a time period for the rule, as we want it to be active all the time. We now need to specify the conditions that apply to the rule and the appropriate action to take. First let's add the condition to prevent the rule reassigning leave requests made by rsteven.

From the Add Condition drop-down list, select the task attribute to which we want to apply the rule, which is, in our case, the Creator (that is, the task initiator), and then click the plus icon (circled in the following screenshot):

This will insert a condition line for testing the Creator attribute into our rule, as shown in the following screenshot:

In the drop-down list, select the test to be applied to the attribute. So in our case, we select isn't and finally specify the user (rsteven). You can either directly enter the user ID or click the magnifying glass icon to search for the user with the user search facility we introduced earlier.

Finally, specify the task action, which is to reassign the task to rsteven. Your rule description should now look like the one shown in the following screenshot:

Finally, click on Save to create the rule. Once you have created the rule, try creating two leave requests, one for jcooper and another for rsteven. You should see that only the request created for jcooper is reassigned to rsteven.

Log in as rsteven, and select the leave request that has been reassigned to that user. If you examine the full task history, you will see that it shows which rule was triggered to cause the task to be reassigned.

Note

A user can also specify rule conditions against the content of the task payload through the use of flex fields, as well as define rules for any groups that they own. We will examine flex fields in Chapter 17, Workflow Patterns.

Delegating tasks

The other option we have when reassigning a task is to delegate it. This is very similar to reassigning a task, but with a number of key differences as follows:

• You can only delegate a task to a single user
• You cannot delegate a task to a group
• You can delegate a task to anyone regardless of where they are in the organizational hierarchy

When you delegate a task it is assigned to a new user, but it also remains on your work queue so that either you or the delegated user can work on the task.

Escalating tasks

There will often be cases where a user needs to escalate the task. To do this, they simply select the task from their task list as normal and choose Escalate from the Action drop-down list. This will reassign the task to the user's manager.

Note

Tasks can also be automatically escalated, usually if not handled within a specified period of time. This is specified in Expiration and Escalation Policy, which forms part of the task definition.

Using rules to automatically manage tasks

Even though it's possible to manually reassign tasks, this can be inefficient and time-consuming. An alternative approach is to automate this using workflow rules.

You can either define a rule to be applied to a particular task type (for example our leave request) or to all tasks. In addition, you can also specify when a rule is active, which can be during vacation periods, for a specified time period, or active all the time (which is the default).

You can specify various filter criteria that are applied to the task attributes (for example, priority, initiator, acquired by) to further restrict which tasks the rule applies to.

Once you've specified the matching criteria for a rule, you can then specify whether you want to reassign or delegate the task. Essentially, the same criteria applies to whomever you are allowed to reassign a task to (if you were to do it manually, as covered in the previous section, with the added caveat that you can only reassign a task to a single user or group).

For rules defined for a particular task type, we have the option of being able to automatically set the task outcome. In the case of our leave request task, we can write a rule to automatically approve all leave requests that are one day in duration.

The final option is to take no action, which may seem a bit strange. However, this serves a couple of useful purposes. Often you only want a rule to be active at certain periods of time. One way to do this is to just specify a date range. An alternative is to use this to turn the rule on and off, as required over time.

The other use comes in when you define multiple rules. Rules are evaluated in order against a task until a rule is found that matches a particular task.

For example, to create a rule that reassigned all tasks, except say an expense approval task, you would do the following. Define two rules, a generic rule to reassign any task and a specific rule that matched the expense approval task that did nothing. We would then order the rules so that the expense approval rule triggered first. This way, the generic rule to reassign a task would be triggered for all tasks except the expense approval task.

Setting up a sample rule

For example, let's say Robert Stevenson (user ID rsteven) is John Steinbeck's deputy, and we want to create a rule that reassigns all leave requests assigned to jstein to rsteven except for any leave request made by rsteven.

To do this, you log onto the worklist application as jstein, and click on the Preferences link on the top-right-hand corner of the worklist title bar. This will bring you into the My Rules tab, where a user can configure various rules for managing the assignment of tasks. By default it displays the users currently defined Vacation Period (which in this case is disabled).

Select the My Rules folder (below Vacation Period (Disabled)), and click on the plus icon (circled in the preceding screenshot). This will display the template for defining a new rule.

Enter a suitable name for the rule, but leave the checkbox Use as vacation rule unchecked. If we were to check this, then the rule would only be active during the user's vacation period.

Next we want to specify which tasks the rule should apply to. Click on the search icon to the right and this will pop up the Task Type Browser, where we can search for the required task type. Select the LeaveRequest task for the process default/LeaveApproval/1.0.

We will not specify a time period for the rule, as we want it to be active all the time. We now need to specify the conditions that apply to the rule and the appropriate action to take. First let's add the condition to prevent the rule reassigning leave requests made by rsteven.

From the Add Condition drop-down list, select the task attribute to which we want to apply the rule, which is, in our case, the Creator (that is, the task initiator), and then click the plus icon (circled in the following screenshot):

This will insert a condition line for testing the Creator attribute into our rule, as shown in the following screenshot:

In the drop-down list, select the test to be applied to the attribute. So in our case, we select isn't and finally specify the user (rsteven). You can either directly enter the user ID or click the magnifying glass icon to search for the user with the user search facility we introduced earlier.

Finally, specify the task action, which is to reassign the task to rsteven. Your rule description should now look like the one shown in the following screenshot:

Finally, click on Save to create the rule. Once you have created the rule, try creating two leave requests, one for jcooper and another for rsteven. You should see that only the request created for jcooper is reassigned to rsteven.

Log in as rsteven, and select the leave request that has been reassigned to that user. If you examine the full task history, you will see that it shows which rule was triggered to cause the task to be reassigned.

Note

A user can also specify rule conditions against the content of the task payload through the use of flex fields, as well as define rules for any groups that they own. We will examine flex fields in Chapter 17, Workflow Patterns.

Escalating tasks

There will often be cases where a user needs to escalate the task. To do this, they simply select the task from their task list as normal and choose Escalate from the Action drop-down list. This will reassign the task to the user's manager.

Note

Tasks can also be automatically escalated, usually if not handled within a specified period of time. This is specified in Expiration and Escalation Policy, which forms part of the task definition.

Using rules to automatically manage tasks

Even though it's possible to manually reassign tasks, this can be inefficient and time-consuming. An alternative approach is to automate this using workflow rules.

You can either define a rule to be applied to a particular task type (for example our leave request) or to all tasks. In addition, you can also specify when a rule is active, which can be during vacation periods, for a specified time period, or active all the time (which is the default).

You can specify various filter criteria that are applied to the task attributes (for example, priority, initiator, acquired by) to further restrict which tasks the rule applies to.

Once you've specified the matching criteria for a rule, you can then specify whether you want to reassign or delegate the task. Essentially, the same criteria applies to whomever you are allowed to reassign a task to (if you were to do it manually, as covered in the previous section, with the added caveat that you can only reassign a task to a single user or group).

For rules defined for a particular task type, we have the option of being able to automatically set the task outcome. In the case of our leave request task, we can write a rule to automatically approve all leave requests that are one day in duration.

The final option is to take no action, which may seem a bit strange. However, this serves a couple of useful purposes. Often you only want a rule to be active at certain periods of time. One way to do this is to just specify a date range. An alternative is to use this to turn the rule on and off, as required over time.

The other use comes in when you define multiple rules. Rules are evaluated in order against a task until a rule is found that matches a particular task.

For example, to create a rule that reassigned all tasks, except say an expense approval task, you would do the following. Define two rules, a generic rule to reassign any task and a specific rule that matched the expense approval task that did nothing. We would then order the rules so that the expense approval rule triggered first. This way, the generic rule to reassign a task would be triggered for all tasks except the expense approval task.

Setting up a sample rule

For example, let's say Robert Stevenson (user ID rsteven) is John Steinbeck's deputy, and we want to create a rule that reassigns all leave requests assigned to jstein to rsteven except for any leave request made by rsteven.

To do this, you log onto the worklist application as jstein, and click on the Preferences link on the top-right-hand corner of the worklist title bar. This will bring you into the My Rules tab, where a user can configure various rules for managing the assignment of tasks. By default it displays the users currently defined Vacation Period (which in this case is disabled).

Select the My Rules folder (below Vacation Period (Disabled)), and click on the plus icon (circled in the preceding screenshot). This will display the template for defining a new rule.

Enter a suitable name for the rule, but leave the checkbox Use as vacation rule unchecked. If we were to check this, then the rule would only be active during the user's vacation period.

Next we want to specify which tasks the rule should apply to. Click on the search icon to the right and this will pop up the Task Type Browser, where we can search for the required task type. Select the LeaveRequest task for the process default/LeaveApproval/1.0.

We will not specify a time period for the rule, as we want it to be active all the time. We now need to specify the conditions that apply to the rule and the appropriate action to take. First let's add the condition to prevent the rule reassigning leave requests made by rsteven.

From the Add Condition drop-down list, select the task attribute to which we want to apply the rule, which is, in our case, the Creator (that is, the task initiator), and then click the plus icon (circled in the following screenshot):

This will insert a condition line for testing the Creator attribute into our rule, as shown in the following screenshot:

In the drop-down list, select the test to be applied to the attribute. So in our case, we select isn't and finally specify the user (rsteven). You can either directly enter the user ID or click the magnifying glass icon to search for the user with the user search facility we introduced earlier.

Finally, specify the task action, which is to reassign the task to rsteven. Your rule description should now look like the one shown in the following screenshot:

Finally, click on Save to create the rule. Once you have created the rule, try creating two leave requests, one for jcooper and another for rsteven. You should see that only the request created for jcooper is reassigned to rsteven.

Log in as rsteven, and select the leave request that has been reassigned to that user. If you examine the full task history, you will see that it shows which rule was triggered to cause the task to be reassigned.

Note

A user can also specify rule conditions against the content of the task payload through the use of flex fields, as well as define rules for any groups that they own. We will examine flex fields in Chapter 17, Workflow Patterns.

Using rules to automatically manage tasks

Even though it's possible to manually reassign tasks, this can be inefficient and time-consuming. An alternative approach is to automate this using workflow rules.

You can either define a rule to be applied to a particular task type (for example our leave request) or to all tasks. In addition, you can also specify when a rule is active, which can be during vacation periods, for a specified time period, or active all the time (which is the default).

You can specify various filter criteria that are applied to the task attributes (for example, priority, initiator, acquired by) to further restrict which tasks the rule applies to.

Once you've specified the matching criteria for a rule, you can then specify whether you want to reassign or delegate the task. Essentially, the same criteria applies to whomever you are allowed to reassign a task to (if you were to do it manually, as covered in the previous section, with the added caveat that you can only reassign a task to a single user or group).

For rules defined for a particular task type, we have the option of being able to automatically set the task outcome. In the case of our leave request task, we can write a rule to automatically approve all leave requests that are one day in duration.

The final option is to take no action, which may seem a bit strange. However, this serves a couple of useful purposes. Often you only want a rule to be active at certain periods of time. One way to do this is to just specify a date range. An alternative is to use this to turn the rule on and off, as required over time.

The other use comes in when you define multiple rules. Rules are evaluated in order against a task until a rule is found that matches a particular task.

For example, to create a rule that reassigned all tasks, except say an expense approval task, you would do the following. Define two rules, a generic rule to reassign any task and a specific rule that matched the expense approval task that did nothing. We would then order the rules so that the expense approval rule triggered first. This way, the generic rule to reassign a task would be triggered for all tasks except the expense approval task.

Setting up a sample rule

For example, let's say Robert Stevenson (user ID rsteven) is John Steinbeck's deputy, and we want to create a rule that reassigns all leave requests assigned to jstein to rsteven except for any leave request made by rsteven.

To do this, you log onto the worklist application as jstein, and click on the Preferences link on the top-right-hand corner of the worklist title bar. This will bring you into the My Rules tab, where a user can configure various rules for managing the assignment of tasks. By default it displays the users currently defined Vacation Period (which in this case is disabled).

Select the My Rules folder (below Vacation Period (Disabled)), and click on the plus icon (circled in the preceding screenshot). This will display the template for defining a new rule.

Enter a suitable name for the rule, but leave the checkbox Use as vacation rule unchecked. If we were to check this, then the rule would only be active during the user's vacation period.

Next we want to specify which tasks the rule should apply to. Click on the search icon to the right and this will pop up the Task Type Browser, where we can search for the required task type. Select the LeaveRequest task for the process default/LeaveApproval/1.0.

We will not specify a time period for the rule, as we want it to be active all the time. We now need to specify the conditions that apply to the rule and the appropriate action to take. First let's add the condition to prevent the rule reassigning leave requests made by rsteven.

From the Add Condition drop-down list, select the task attribute to which we want to apply the rule, which is, in our case, the Creator (that is, the task initiator), and then click the plus icon (circled in the following screenshot):

This will insert a condition line for testing the Creator attribute into our rule, as shown in the following screenshot:

In the drop-down list, select the test to be applied to the attribute. So in our case, we select isn't and finally specify the user (rsteven). You can either directly enter the user ID or click the magnifying glass icon to search for the user with the user search facility we introduced earlier.

Finally, specify the task action, which is to reassign the task to rsteven. Your rule description should now look like the one shown in the following screenshot:

Finally, click on Save to create the rule. Once you have created the rule, try creating two leave requests, one for jcooper and another for rsteven. You should see that only the request created for jcooper is reassigned to rsteven.

Log in as rsteven, and select the leave request that has been reassigned to that user. If you examine the full task history, you will see that it shows which rule was triggered to cause the task to be reassigned.

Note

A user can also specify rule conditions against the content of the task payload through the use of flex fields, as well as define rules for any groups that they own. We will examine flex fields in Chapter 17, Workflow Patterns.

Setting up a sample rule

For example, let's say Robert Stevenson (user ID rsteven) is John Steinbeck's deputy, and we want to create a rule that reassigns all leave requests assigned to jstein to rsteven except for any leave request made by rsteven.

To do this, you log onto the worklist application as jstein, and click on the Preferences link on the top-right-hand corner of the worklist title bar. This will bring you into the My Rules tab, where a user can configure various rules for managing the assignment of tasks. By default it displays the users currently defined Vacation Period (which in this case is disabled).

Select the My Rules folder (below Vacation Period (Disabled)), and click on the plus icon (circled in the preceding screenshot). This will display the template for defining a new rule.

Enter a suitable name for the rule, but leave the checkbox Use as vacation rule unchecked. If we were to check this, then the rule would only be active during the user's vacation period.

Next we want to specify which tasks the rule should apply to. Click on the search icon to the right and this will pop up the Task Type Browser, where we can search for the required task type. Select the LeaveRequest task for the process default/LeaveApproval/1.0.

We will not specify a time period for the rule, as we want it to be active all the time. We now need to specify the conditions that apply to the rule and the appropriate action to take. First let's add the condition to prevent the rule reassigning leave requests made by rsteven.

From the Add Condition drop-down list, select the task attribute to which we want to apply the rule, which is, in our case, the Creator (that is, the task initiator), and then click the plus icon (circled in the following screenshot):

This will insert a condition line for testing the Creator attribute into our rule, as shown in the following screenshot:

In the drop-down list, select the test to be applied to the attribute. So in our case, we select isn't and finally specify the user (rsteven). You can either directly enter the user ID or click the magnifying glass icon to search for the user with the user search facility we introduced earlier.

Finally, specify the task action, which is to reassign the task to rsteven. Your rule description should now look like the one shown in the following screenshot:

Finally, click on Save to create the rule. Once you have created the rule, try creating two leave requests, one for jcooper and another for rsteven. You should see that only the request created for jcooper is reassigned to rsteven.

Log in as rsteven, and select the leave request that has been reassigned to that user. If you examine the full task history, you will see that it shows which rule was triggered to cause the task to be reassigned.

Note

A user can also specify rule conditions against the content of the task payload through the use of flex fields, as well as define rules for any groups that they own. We will examine flex fields in Chapter 17, Workflow Patterns.

Summary

Human workflow is a key requirement for many projects. In this chapter, we saw how easy it is to insert a human task into a BPEL process, as well as implement the corresponding user interface to process the task.

We also looked at how business users can use the BPM worklist application to process their tasks as well as manage routing them, including reassigning, delegating, and escalating tasks. We also looked at how business users could automate most of the task management by defining business rules to automatically delegate, reassign, or complete a task.