Browse Prior Art Database

Advanced Posting of Events in Workflow Management Systems

IP.com Disclosure Number: IPCOM000014507D
Original Publication Date: 2000-Jul-01
Included in the Prior Art Database: 2003-Jun-19
Document File: 3 page(s) / 97K

Publishing Venue

IBM

Abstract

1 Introduction Workflow management systems [1] manage the execution of business processes. Events as described in [2] 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 3

Advanced Posting of Events in Workflow Management Systems

1 Introduction

    Workflow management systems [1] manage the execution of business processes. Events as described in [2] 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.

    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. However, it is easy to construct a set of scenarios where this does not work. Particularly interesting are those scenarios where the posting has no effect as the appropriate event has already been processed or will never be processed. In these cases the posting user is not aware that the post has no effect. Whereas this may not be a problem in general, there are certainly situations where it would be extremely helpful to know whether a posting was consumed or not; just in case this was an error.

    A previous technical disclosure [3] proposed to assist in informing the posting user by keeping the obsolete waited events for a certain period of time. When the post occurs and the event has been appropriately marked, the post is returned with an appropriate error code. However, this approach does not help, if the event activity is never activated; in this case the posting for the event is just kept in the posted event table.

3 Proposal

Informing the posting system/user about the failure of the

1

Page 2 of 3

posting can be furt...