Business processes express the way an organization works toward a well-defined business goal. Both humans and systems play important roles in reaching this goal. We need an understanding of interactions between people and an organization's business processes and how responsibilities are assigned and managed for different human interactions involved in those processes.
This chapter will focus on understanding the framework provided by the BPM discipline—and the jBPM6 framework—to handle human interactions. We will also introduce the Web Service Human Task (WS-HT) standard specification that has been created to standardize the information, life cycle, and interaction with software components specialized in managing human interactions.
In this chapter, you will learn the following topics:
- The role that human tasks play in the BPM discipline
- How jBPM6 handles human interactions at the code level
- User interfaces of KIE Workbench specialized in human interactions
Many studies have been made to improve human-to-system interactions in the software industry. We will see how the BPM discipline approaches these interactions in a way that distils decades of experience. Some changes will be introduced to how we think and design user interfaces, from thinking about standalone applications to integration components. First, we need to take a look at the context in which Human tasks take place inside business processes.
Modeling business processes using the BPMN 2.0 standard notation allows you to define many different types of activities. Two of the most frequently used activities are User tasks to handle human interactions and Service tasks to handle external system interactions. Our processes will be in charge of coordinating system-to-system and human-to-system interactions to guide an organization's day-to-day activities.
From a BPM discipline perspective, the distinction exists to guarantee a higher level of descriptive content in our process diagrams. At an interaction level, both human and system interactions are the same: something that happens outside the process scope.
When a User task is reached in one of our processes, a new User task will be created and handed to the correspondent business actors. At that point, we will create a new task in another system—the Human task component. This system is the main focus of this chapter and will have the responsibility of notifying the users and handling interactions with the newly created task along with its status changes.
User tasks contain information that is relevant in the context of a specific process' execution, which will allow the user to execute the task. Also, an actor will need to handle more than one task at a time, and the contextual information, including the type and/or name of the task, will differentiate each task from the rest.
Depending on the number of business processes in which the actor is involved, there will be different types of tasks that the user must be ready to execute. The ability of a user to perform a certain job will be determined easily through his/her user role. However, the processes themselves might be a component that the end user will not be interested in. In the same way as that of the process engine that sees the Human task as merely an external interaction, the Human task only sees the process engine as its origin and as a listener for the changes in its status.
At this point, we need to have a list of user interaction components to manage notifications, displaying, interaction, and completion of Human tasks. Both humans and the process engine itself will interact with those components at runtime.
Many different vendors have implemented these mechanisms in many different ways. Eventually, a standard specification appeared that formalized these mechanisms as well as the task's life cycle for all human interactions. The following section introduces this standard called the WS-HT standard specification. For further details, you can review the WS-HT specification definition in a PDF format at http://docs.oasis-open.org/bpel4people/ws-humantask-1.1.pdf.
OASIS Group is an international consortium that drives open source adoption of standards. It has defined the WS-HT specification to standardize human interactions, their structure and information, and make them interoperable between different vendors. The WS-HT specification serves as a guideline of the features that every human component should have; it is based on industrial best practices and on the most implemented end user features. Being compliant with this kind of specification will help you to replace components provided by one vendor with the components of another vendor without affecting other components, as long as both vendors apply the same standards.
Most BPM systems architectures provide a built-in component that is in charge of handling human interactions. This becomes a problem when trying to expose human interactions to other systems, besides the BPM system. It is because of this reason that even if jBPM6 provides a built-in Human task component, it can be created as a standalone component, accessible through external services. The overall structure for a jBPM6 BPM system core, considering only the main components relevant to our current scenario, looks like the following figure:
In the preceding figure, we can see that external components can interact with any of the components related to jBPM6, regardless of whether we're talking about processes, rules, or human interactions. The sort of information exposed through the listeners in the Human task engine is, however, closely related to the task's internal life cycle. We'll now provide an overview of it.
The WS-HT specification defines a detailed and complete set of states that every task can be in as well as operations allowed to change a task from one status to the next. These states are designed to cover almost every possible scenario related to Human tasks.
These statuses also cover what we call Group tasks, which are assigned to a group instead of a particular person. Business processes can create these tasks, and anyone who belongs to the defined groups can complete them. When tasks are created, every person in the group who wishes to complete them will have to claim each task in order to work on it. Claimed tasks are assigned to the claimer only, and no one else can claim that task. If the claimer of the task cannot work on it, he or she has the option to release it.
The following graph represents the possible states and transitions of a task according to the specification:
When you invoke a specific task operation on a particular task instance, you can change the internal status on said task. If you call an invalid operation for the current state of the task, the Human task component will throw an exception.
Usually, when our business process creates a User task, it will be set up at the Created state. If the task has no direct assignment (that is, the process or the task definition doesn't contain information about who is in charge of it), the task will be placed at the Ready state until someone can claim it.
A task in the Ready state still needs a potential owner of the task to claim it. Potential owners can both claim it into the Reserved state and release it back into the Ready state. At this point, the task will be ready and waiting for a user assignment.
A task in the Reserved state is only available for one user, so it is ready to be started by the claimer. The claimer, once ready to begin working on the task, can start it by moving it to the InProgress state. The task will usually remain in that state until the user in charge of that task completes it, moving it to the Completed state. Alternatively, we can suspend or stop the task, which means that we need to resume it or start it again.
In situations where a task cannot be successfully completed, we can use four other close strategies for the tasks. If it cannot be successfully completed, the Fault task operation moves the task to the Failed state. This is usually done when the user in charge of the task doesn't have all the information or the means that is required to finish the task. Error, Exit, and Obsolete are used when there is an error inside the task or the task is no longer needed.
Determining who is the right person to complete a specific task is the responsibility of the Human task service, and it will do it based on the input information received from the task creation process. Now that we understand the states that a task can be in, we can get into the API side to understand how these operations translate to code invocations and how this extra information is shared between processes and tasks. The following section introduces the Human task component provided in jBPM6 by showing us an example of how to create Human tasks.