Human Tasks

Most processes depict real-life, practical business or scientific scenarios which need the interactions of a human at least once in its workflow design. Typically, these interactions are initiated by the process itself, and requests a user input to proceed. For example, consider a "bank loan request" process which often requires the final decision to be taken by a human.

These human interactions are referred to as human tasks. Human Tasks enable human interactions to be initiated from a process, so that the process issues tasks that can be completed by humans. Within a BPEL processes, such tasks are modeled as outgoing service calls, but those service calls are intended for and processed by a human. For example, a loan issuing process may include a human task step in its workflow to let a bank manager/executive review and approve a loan. Such a task can typically trigger an email/alert to the manager, allowing him to click on a link, review the loan, and approve it. While the approval is pending, the calling processes wait, and the approval or rejection triggers a message in the process which takes the process to the next step of execution in its workflow.

In SOA, human tasks management is generally facilitated by a Web service. For example, the human tasks server, which manages all human task related operations, is defined as a web service by the Human Tasks specification. Human tasks are realized using two technical specifications: Web Services for Human Task (WS-HumanTask: http://docs.oasis-open.org/bpel4people/bpel4people-1.1-spec-cd-09.pdf) Specification and WS-BPEL Extension for People (BPEL4People: http://docs.oasis-open.org/bpel4people/ws-humantask-1.1-spec-cd-10.pdf) specification. WS-HumanTask defines interfaces for a task server that enable the workflow engine to create tasks, enabling the organizations to map the tasks to humans and manage them. Support for users to interact with the tasks. On the other hand, BPEL4people specification extends workflow process definitions to include human tasks definitions.

WSO2 Business Process Server implements the WS-Human Task specification. It has WS-Human Task API and UI which expose the functionality in Task Management API. It enables users to bundle a human tasks definition as a zip file and upload it, where the tasks definition includes input and output message formats for the human task. The human task management functionality is provided by the following feature in the WSO2 feature repository.

Name : WSO2 Carbon - HumanTask Application Deployer Feature
Identifier: org.wso2.carbon.application.deployer.humantask.feature.group

If human task management capability is not included in your product by default, you can add it by installing the above feature using the instructions given in section, Feature Management. Follow the instructions below to add a human task.

1. Log on to the product's management console and select "Human Tasks-> Add" under the "Main" menu.

2. The "New HumanTask Package" window opens. Provide the file and click "Upload."

3. The "Deployed Task Configurations" window opens with the newly-added human task listed. For example,

• Package Name: The name of the package.
• Task Definition: The task definition
  
• Type: Whether this definition is a Task or a Notification
  
• Status: The package status.
  

4. Click on a selected "Task Definition".

Writing a human task artifact

Human tasks

Business processes cannot always proceed in a fully automated manner. They need human interaction as a means of decision making, error handling and exception cases. For example, canceling a flight due to a strike or bankruptcy, deciding whether to accept the claim based on the requested amount etc. Human tasks provide the specification to define tasks performed by human beings.

Sample Scenario

When a user requests a claim to be approved by the system, the system automatically approves claims under an amount of 1000 .This is a simple BPEL process. If the claim exceeds 1000, it will be handed over to the regional clerk who checks the claim amount along with the user information, decides whether or not to approve it, and the final decision is sent to the user. So when the claim is higher than 1000, it will be processed as a human task. The sample process is shown below.

Writing human tasks

The basic process is designed as a normal BPEL process with an IF component. For human tasks, we use the BPEL4PEOPLE activity remote task. It will get the input from the claim approval request such as the name and amount, and the output is sent via a claim approval callback service as true or false. The user can then see the final decision. This process needs some presentation elements. Human tasks are implemented as jsp pages.

The BPEL process is implemented using the BPEL4PEOPLE activities and deployed into the server. Human tasks have to be deployed as a separate process. Since there is no tool to create a human task workflow, all the steps have to be done manually. However, there is a predefined package structure which makes the work easier. As an initial step, you should create a package structure in your local directory.

 Package structure of an HT artifact

There are four components in the HT package.

1. .ht file
2. htconfig.xml file
3. taskService.wsdl
4. web folder

1) .ht file

The .ht file contains the information about the human task of the BPEL process. It is an xml based file consisting of a predefined set of human task description elements. The table below shows the basic elements and their descriptions with some examples from the ClaimsApprovalTask sample.

2) htconfig.xml file

This file consists of deployment details of the human task. Human tasks supports two task types called task and notification. A task can have a publish and a callback. Publish means providing a service and Callback means calling an external service to provide the output. Notification is also a task type. A notification task provides one operation for external parties to create notifications. 

Example from the claim task sample:

<hic:HTDeploymentConfig xmlns:hic="http://wso2.org/ht/schema/deployment/config"
	xmlns:claim="http://www.example.com/claims/"
	xmlns:claimtask="http://www.example.com">
	<hic:task name="claimtask:ApproveClaim">
		<hic:publish>
			<hic:service name="claim:ClaimService" port="ClaimPort" />
		</hic:publish>
		<hic:callback>
			<hic:service name="claim:ClaimServiceCB" port="ClaimPortCB" />
		</hic:callback>
	</hic:task>
	<hic:notification name="claimtask:ClaimApprovalReminder">
		<hic:publish>
			<hic:service name="claim:ClaimReminderService" port="ClaimReminderPort" />
		</hic:publish>
	</hic:notification>
</hic:HTDeploymentConfig>

Here, the htconfig.xml file consists of three services used by a human task; get data from the user, call back of either approve or not and the reminder web service.

3) <Service>.wsdl

You can have one or more WSDL files which have been used in the BPEL process. You can have a composite WSDL addressing many web services. Claim Approval task has one composite WSDL.

4) Web folder

There are four jsp files inside the web folder. Three jsp files end with:

1. <TaskName>-input.jsp 
2. <TaskName>-output.jsp
3. <TaskName>-response.jsp

<TaskName>-input.jsp

The input.jsp file uses (OMElement) request.getAttribute("taskInput") attribute to obtain the task Details OMElement. This is inserted into the JSP context from BPS. The input.jsp file is used to show the task information to the task user.

Example from the ApproveClaim-input.jsp:

OMElement requestElement = (OMElement) request.getAttribute("taskInput");
	String ns = "http://www.example.com/claims/schema";
	if (requestElement != null) {
	OMElement customerElement = requestElement.getFirstChildWithName(new QName(ns, "cust"));
	if (customerElement != null) {
OMElement id = customerElement.getFirstChildWithName(new QName(ns, "id"));
if (id != null) {
customerId = id.getText();
}

The input web will show the human task list of the regional clerk user.

<TaskName>-output.jsp

The output.jsp is used to provide the user with a task form. Task processing happens when this is completed and submmited by the user.

All output.jsp files should implement the javascript method

createTaskOutput = function() {
};

which should output the corresponding xml string expected by the task operation.

Example from the ApproveClaim-output.jsp:

createTaskOutput = function() {
	var outputVal = getCheckedRadio(); //get approve or not from radio button
 if(outputVal == 'approve') {return'<sch:ClaimApprovalResponse 	xmlns:sch="http://www.example.com/claims/schema"><sch:approved>true</sch:approved></sch:ClaimApprova	lResponse>';
	} else if (outputVal == 'disapprove') {return'<sch:ClaimApprovalResponse 	  
xmlns:sch= "http://www.example.com/claims/schema"> <sch:approved>false</sch:approved>
</sch:ClaimApprov	 alResponse>';
}
	};

Output JSP will be used by the regional clerk user to approve the claim.

<TaskName>-response.jsp

Response.jsp is used to display the output of the completed task. It also uses the OMElement responseElement = (OMElement) request.getAttribute("taskOutput"); to obtain the OMElement corresponding to the output.

Example from the ApproveClaim-response.jsp:

String approved = "No Value Assigned";
OMElement responseElement = (OMElement) request.getAttribute("taskOutput");
if (responseElement != null) {
approved = responseElement.getFirstElement().getText(); }

The response after approving the claim looks like this: