Implementing human activities in Windows workflow

Although Windows Workflow is an excellent framework for implementing business process processing, it lacks direct support for human activities. Although Microsoft has released several methods to solve the problem, these methods are not universal. This article will define a completely generic approach to support human activities in WF.

The complexity of supporting human interaction poses numerous challenges, as shown in the following list:

The user's response time (the execution time of the user's activity) is unpredictable.

When the request occurs, the user can not connect to the system, so the request needs to be stored and submitted to the user when the user logs on to the system.

There can be multiple workflows running simultaneously on different machines. But users typically need a unified view of all tasks.

The industry has recognized these problems and has developed two major specifications to address them. We will build the implementation of human activities based on the following ideas, rather than on paper specifications.

Component view for a solution

The main components of the overall solution are shown in Figure 1.

Figure 1 Solution Components

At the heart of the solution is a Task Force column manager. This is a centralized service that tracks all the tasks for all users of the system. Any workflow that requires human interaction (or the workflow that the service/application contains), to invoke a custom workflow activity to submit the request to the Work Queue Manager and to persist it, while allowing other components of the system to collaborate with those requests. In this way, the Work Queue Manager becomes the decoupling layer between the workflow engine and the execution of the human activity. This approach also provides support during workflow execution if the user does not exist in the system. At the same time, the Work Queue manager, by forming a centralized service, can combine all tasks with the specified user, regardless of where the process is initialized. Because different user tasks can require different input information and produce different outputs, the communication between workflow and human activity takes the input and output of XML so that any possible requests and responses can be processed. Although using XML seems to increase the complexity of implementation,. NET supports XML serialization, making mapping between XML and objects a breeze. The Work Queue Viewer is a GUI application that allows the user to visually view all the tasks that are already ready for the input. The application is generic, showing only the basic elements of the task, including name, type, priority, creator, and so on. Depending on the information in the queue, the user can decide to perform a specific task. The actual process of a task is accomplished through a task application that supports a given task on a functional. A workflow queue management application provides a user interface to support the management of the Work Queue Manager. It can view and modify existing human tasks, view their history, and so on. Finally, a human activity is a custom activity (see sidebar "Windows Workflow Foundation Component Model", which implements communication with the task Queue Manager and presents a very simple programming model for workflow developers to perform on human tasks.) From the point of view of human interaction, this is not the same as regular service invocation.

Windows Workflow Foundation Component model

As described in [11], the implementation of Windows Workflow Foundation (WWF) differs from the Executable workflow language (domain language) implemented by the current mainstream workflow. In the WWF, the activity in the process diagram is associated with a component that implements the run-time behavior of the activity, and the component is implemented by a general-purpose programming language. Each activity in a process language corresponds to an implementation component. For example, a Web service invoke activity, a human task activity, or an e-mail activity corresponds to an implementation component.

Therefore, we can easily extend the WWF by introducing new activity types to implement run-time behavior in specific situations (in our case, the human task), making it easy to build or extend existing process languages by implementing new activities.

The overall interaction between components is shown in the sequence diagram (Figure 2)

Figure 2 Sequence diagram

As we can see, the overall solution above contains two types of components:

Generic, including human activities, Work Queue Manager, and Work Queue Viewer. These components run on top of the "standard" attribute of a human task (attributes) and treat the input and output of a task as generic XML.

Special, including the workflow itself and applications that process business processes, implement XML serialization/deserialization of specific business objects and use these objects to implement their functionality.

This article only discusses solutions for common components.

Work Queue Manager Service Interfaces and features

As we defined earlier, the Work Queue Manager is a centralized service. Its functionality is based on the data contract, as shown in Figure 3.

Figure 3 Work Queue Manager data contract