Browse Prior Art Database

Halted State Support in Workflow Management Systems

IP.com Disclosure Number: IPCOM000015205D
Original Publication Date: 2001-Sep-14
Included in the Prior Art Database: 2003-Jun-20
Document File: 4 page(s) / 144K

Publishing Venue

IBM

Abstract

1. Introduction

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 4

Halted State Support in Workflow Management Systems

1.Introduction

    Workflow management systems [1] support the definition and execution of business processes. The major constructs in drawing processes are activities and control connectors. The activities describe the tasks to be performed, and the control connectors describe the potential sequence in which the activities are to be carried out. Figure 1 shows schematically the structure of such a process graph.

Figure 1 Process Model

    Activities are represented as named circles; the name typically describes the purpose of the activity. Activities come in various flavors to address the different tasks that may need to be performed. They may have different activity implementations to meet these diverse needs. Program activities are performed by an assigned program, process activities are performed by another process, and blocks implement a macro with a built-in do-until loop.

    Control connectors are represented as arrows; the head of the arrow describes the direction in which the flow of control is moving through the process. The activity where the control connector starts is called the source activity; where it ends is called the target activity.

    Dependent on the implementation of an activity, several activity types are differentiated: process activities are implemented via a sub-process, or program activities via executables, such as programs or DLLs. Information activities have no implementation at all; they are just used to convey some information.

2. State of the Art

1

[This page contains 1 picture or other non-text object]

Page 2 of 4

    Processes have a set of states associated with them. State changes are caused either by some external request or by the WFMS when navigating through the process model. Figure 2 shows a subset of the states that MQSeries Workflow [2] supports.

Figure 2 Process State Machine

    The same is true for activity; they also have a state engine associated with them. Figure 3 shows the appropriate MQSeries Workflow state engine for activities. The state Executing/Waiting is of particular interest. When a program activity is being carried, the state of the activity is Executing; when an event activity is being carried out, the state of the activity is called Waiting to indicating that the event activity waits for some external signal to arrive.

2

[This page contains 1 picture or other non-text object]

Page 3 of 4

Figure 3 Activity State Machine

3. Problem Statement

    The process states and the activity are typically completely decoupled. Thus it is not possible to determine that navigation of a process can not continue, because some of the activities are in the InError State or are waiting.

There are several options how one could cope with the situation:

The workflow management provides an API to query the status of acivities. Based on that information and knowledge about the structure of the process model, on can write an application progranm that can deduce whet...