Applies To

Content

• Introduction
• How do Human Tasks Work?
• How does the system Interact with Humans?
• Anatomy of a Task Server?
• Usecase

Introduction

Real world IT usecases rarely contained within the word of bits. More often than not, humans are an integral part of those usecases where usecases often includes interactions with humans. Desktop or Internet applications are a common form of such applications, where a human starts the interaction and continue to interact with the application through a User Interface. In contrast to those Desktop applications, enterprise applications often tend to run completely or partially in the backend without humans watching over the user console. However, there are many cases where an enterprise system (a software program) actively seeks input from humans even when there is no human sitting in front of the monitor. One of the common usecase is loan processing where often it is required that final decision to be taken by a human. Unlike the former case, the interactions are initiated from the system itself, and the system requests user input when required. A skeptic may claim that with this model, humans are merely been a peripheral to a computer program. Regardless of how you look at the interactions, we are finding such scenarios increasingly often.

Human Tasks are a concept that enables such interactions initiated from a system. Here the idea is that the system can issue tasks that can be completed by humans. For example, within a BPEL processes, such tasks are modeled as outgoing service calls, but those service calls are intended for a human and processed by a human. As we discussed before, a loan issuing process may include a human task step to let the bank manager to review and approve a loan. In such a scenario, executing such a task may trigger an email to the manager that let him click on a link, review the loan, and approve it. While the approval is pending, the calling processes will wait, and the approval or rejection will trigger a message in the process that will take the process to the next step of execution.

In SOA world, Human tasks are realized using two technical specifications: Web Services for Human Task (WS-HumanTask) Specification and WS-BPEL Extension for People (BPEL4People) specification. WS-HumanTask defines interfaces for a task server that enable workflow engine to create tasks, enabling the organizations to map the tasks to humans and manage them, and support for users to interact with the tasks. On the other hand, BPEL4people specification extends workflow process definitions to include human tasks definitions.

How do Human Tasks work?

Following figure shows how Human tasks generally work. As shown by the figure, a workflow engine executes the workflow. When the Human task node of the workflow has reached, workflow server delegates the Human task to a Human task server. Then the workflow waits until the task is completed. The Human task server interacts with humans through emails, some form of alerts, or adding a task to a TODO list. When the task completes, Human tasks engine notifies the workflow engine, which continues the workflow.

How does the system Interact with Humans?

When a human task has been created in the human tasks server, it become available to be started. Sometime, the tasks server may have a scheduler that would assign the task for a specific person, and on which case the task server may communicate the task to the person by sending a email, SMS, showing a popup, or adding a task to the person’s TODO list. Otherwise, the task may be place in a task queue, and someone may chose to work on the task.

In either case, start working on a task typically starts a UI that enable user to interact with the task and complete it. For example, clicking the task link in the email may open a form, and filling it in and submitting the form may cause the task to be completed. Some human tasks may let the task developers define the User Interface shown to the user, and sometime, this UI may be custom developed without any help from the human task server. For example, in the loan-processing example, the task UI may be a custom UI that is specific to the bank, which collects the results and submit the results to the task server.

Anatomy of a Task Server

Human tasks server generally implemented as a Service. For example, in SOA world, Human tasks server is defined as a web service by the Human Tasks specification. For example, the following Figure 2 shows a typical Human tasks API.

First developers define human tasks and register them with the Human Tasks server. For example, upcoming human tasks support within WSO2 BPS will enable users to bundle a human tasks definition as a zip file and upload it to the human tasks server. The tasks definition includes inputs and output message formats for the Human Task.

Later, a user or a process initiate a task and create a task instance by invoking the createTask(..) method. Then user or an application may search for tasks and claim a task by invoking startWorkingOnATask(..). Finally, when the task has been completed or failed, the user can notify that through completeATask(…) or cancelATask(...) methods. For example, let us consider a bank application developed to enable the bank manager to review and approve/reject loans. The bank may retrieve task lists from the server, show an custom UI that enable the bank manager to review the loan application, comment on it, and finally submit results to the task server.

It is worth noting that task server enables human tasks to be integrated with any application that supports programmable extensions. For instance, one can write a task client as a Thunderbird extension, a Jira extension, or a Firefox plugin that enable users to see tasks, claim them, and complete them. Any of those extensions will interact with the task server through the Human Task server API similar to the above API.

Also, It is worth noting that although we generally talk about tasks within processes, tasks servers are independent of the processes. For example, someone can use a task server to manage human tasks without using processes at all.

Usecases

Let us look at few usecases where Human tasks might become useful.

1. Automation while still keeping human in the loop: One of the main challenges of automation is to keep human in the loop to avoid mistake in the critical decision. Human tasks enable us to include a human decision into processes.
2. Seamless scheduling of tasks: A Human tasks based system can act as a scheduling system. For example, Customer service system could model all help queries as human tasks and schedule the service to queries actively. This provides greater control over the workflow, more visibility into scheduling, and added features like escalation.
3. Escalation : Human tasks can seamlessly implementation escalation path in a process. For example, if a support query is not answered within the Service Level Agreement (SLA), the human tasks based process can escalate the problem in to the superiors, and escalation can keep happening to upper layers unless the query is resolved. A key advantage of such automation is it enforces the process rigidly and brings into attention any exceptional conditions.
4. Ensuring operability: If all processes in an organization are modeled as human tasks, then the system can monitor the operationability of the system. For example, if it is a bank, the system can make sure there are enough officers are available to carry out all key workflows in the bank before granting leaves.
5. Interactive computations and Handling exceptional scenarios: If a long running workflow has failed, the workflow engine can contract the user about the error using human tasks and give him an opportunity to fix the problem and continue the workflow. Furthermore, some workflows could enable an expert to make decisions by examining the results of first part of the workflow. For example, weather workflow might be best executed by visualizing the weather data and letting an expert select the area that need high resolution weather forecasts.
6. Making Human involved processes flexible: Most applications implement human involved processes as a UI wizard that guides the humans through a process. For example, creating an account process in a bank will take the bank officer through a series of screens. However, such processes are rigid and hard to change. Alternatively, Human tasks enable user to model such a process as a workflow composed of many human interactions, and unlike the UI wizard, it is easy to edit and change the process when needed.

Conclusion

Human Tasks enable systems to include human inputs into the IT infrastructure processes, and thus brings Computing systems and real world closer to each other. The human tasks are implemented through a Human task server. A Process or the activity that requires human intervention may initiate a human task through the human task server. Human task server communicates the task to users, helps them carry out the task, and when completed, the task server will notify the initiating process or the activity returning the control back to the workflow engine.

We discussed the typical human tasks architectural setup, and how human tasks and processes can work together. We also noted that although human tasks are generally discussed as part of business processes, the human task servers are designed as a standalone component and can therefore used to model other types of human interactions as well. For example, a service may create a human task to review any approved but failed transaction.

Finally we discussed different usecase where human tasks may be useful. Among some of the usecases are supporting human oversight in automated processes, doing better task scheduling and escalations for human activities, and getting human input for exceptional conditions.

Upcoming WSO2 Business Process Server releases will include first class support for human tasks as per BPEL4People and WS-Human Tasks specification. Stay tuned.

Author

Srinath Perera, Software Architect, WSO2 Inc.