Browse Prior Art Database

Improved Posting of Events in Workflow Management Systems

IP.com Disclosure Number: IPCOM000013070D
Original Publication Date: 2000-May-01
Included in the Prior Art Database: 2003-Jun-12
Document File: 2 page(s) / 77K

Publishing Venue

IBM

Abstract

1 Introduction Workflow management systems manage the execution of business processes. Events as described in provide the capability to wait for some external action to take place. A typical example of an event is to wait for a customer letter that has been requested. 2 State of the Art Events are typically implemented as described in [1] and [2] . Two tables, the posted event table and the awaited event table hold the appropriate information for the events. The awaited events table holds a entry for all events for which the waited for action has not yet occurred; the posted event table contains all entries for which the external action has already occurred, however the event has not yet been reached in the processing of the process instance.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 53% of the total text.

Page 1 of 2

Improved Posting of Events in Workflow Management Systems

1 Introduction

      Workflow management systems manage the execution of business processes. Events as described in provide the capability to wait for some external action to take place. A typical example of an event is to wait for a customer letter that has been requested.

2 State of the Art

    Events are typically implemented as described in [1] and [2] . Two tables, the posted event table and the awaited event table hold the appropriate information for the events. The awaited events table holds a entry for all events for which the waited for action has not yet occurred; the posted event table contains all entries for which the external action has already occurred, however the event has not yet been reached in the processing of the process instance.

3 Problem Statement

In the perfect scenario, all awaited events are eventually posted, and all posted events are eventually consumed when navigation reaches the event activity for which the event was posted. Thus, there are no residues, that means leftover entries, in the two tables.

  However, it is easy to construct a set of scenarios where this does not work. One of them is the case where the process is terminated, for example, through an administrator, or when the event activity has expired and the process completed. In this case, residues will remain in either the awaited event table or the posted event table.

4 Proposal

Two options are available to handle the situation :
1. The first option is to delete the entry in the awaited event table. The problem with this approach is that somebody tries to post the event and does not know that...