Browse Prior Art Database

Request Aliasing in Workflow Management Systems

IP.com Disclosure Number: IPCOM000013196D
Original Publication Date: 2001-Feb-01
Included in the Prior Art Database: 2003-Jun-17
Document File: 4 page(s) / 133K

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 48% of the total text.

Page 1 of 4

Request Aliasing in Workflow Management Systems

1. Introduction

    Workflow management systems [1] manage the 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. When more than one control connector leaves an activity, this indicates potentially parallel work.

    A process instance can assume various states when it is carried out by the workflow management system. Figure 2 illustrates those states exemplarily. It should be noted that this for

1

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

Page 2 of 4

illustration purpose only; workflow management systems typically differentiate between many more states.

Figure 2 Process States

    The first step a particular business process goes through is that it is created by taking the appropriate process template, possibly populating with supplied context data, and assigning it a unique process instance identification. This step is usually carried out as the result of requesting the workflow management system's CREATE function. As a result of function completion, the business process is put into the state created.

    When the business process is being carried out, that means the workflow management system navigates through the process graph and executes the individual activities, the business process is in the state running . The business process is typically put into this state by a client issuing a START request; other possibilities are that the business process is automatically started by the workflow management system at a time specified when the business process is created, or a combination of a CREATE and START request.

    When all activities of the business process have been carried out, the process goes into the state finished . No further activities are carried out with the business process; however all information about the business process is still available and can for example be queried. Some workflow management system still allow operations on a finished business proces...