InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Transactional Behavior modified in case of Retry

IP.com Disclosure Number: IPCOM000019919D
Original Publication Date: 2003-Oct-10
Included in the Prior Art Database: 2003-Oct-10
Document File: 3 page(s) / 28K

Publishing Venue



Disclosed is a method that allows to identify a failing activity in a group of activities that are executed together in one transaction for performance reasons. If the transaction aborts it is not obvious which activity caused the failure. However, the activity needs to be uniquely identified to allow specific repair actions.

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 3

Transactional Behavior modified in case of Retry

1. Introduction

Workflow management systems [1] support the definition and execution of business processes or flows. The major constructs in drawing flows 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. The activity where the control connector starts is called the source activity; where it ends is called the target 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. One example for an activity type are Service activities or Elemental Activities. Each of these activities is performed by an associated service. Examples for services are methods of Enterprise JavaBeans beans, stored procedures, CICS transactions or Web Services. Activities are connected via control connectors.

    The navigation of a long-running business process is performed as a series of transactions where the control connectors represent possible transaction boundaries. Once an activity's implementation is executed, the activity is set to state Finished and a continue control connector message is put onto a persistent queue for each control connector leaving the activity and the transaction is committed. Each of these messages is then retrieved from the queue in another transaction, possibly triggering the execution of the control connector's target activity implementation. If the transaction aborts for any reason, the message is left on the persistent queue and the delivery counter is increment. The message is then retrieved another time from the queue but this time the target activity implementation is not executed but the activity is set to state Stopped to allow specific manual repair actions.

2. Problem Statement

    As outlined below, each activity implementation is executed in a separate transaction. However, depending on the activity type and the associated service this may not always be required. I.e., for performance reasons it may be useful to execute a group of activities in one transaction. To allow the process engine to decide during the navigation of the business process whether two activities may be executed in the same transaction the control connector carries a property with the possible values persistent and transient. If the property has the value persistent a continue control link message is put on the external queue as outlined above. If the property has the value transient, the process navigation continues with the target activity of the control connector in the current transaction. While this allows to form a group of activities to be executed together in one transaction it is no longer obvious which activity implementation caused the failure if the tra...