Browse Prior Art Database

Business Process Intelligent enablement to handle failed events during Enterprise Applications

IP.com Disclosure Number: IPCOM000131690D
Original Publication Date: 2005-Nov-15
Included in the Prior Art Database: 2005-Nov-15
Document File: 6 page(s) / 86K

Publishing Venue

IBM

Abstract

Disclosed is a mechanism that provides failed event management inside business process in enterprise applications. Failed event is normally generated after flow is processing unsuccessfully, and delivered event is treated as a whole record. This does not meet customer's needs that require automatically handling failed event when flow is running. A typical example is to save only failed flows in batch event, and continue the process without causing the whole flow to fail. This invention enables building event management into their customer's business logic to save, query, delete or resubmit failed events during the runtime of business process. With the enablement, Customer can choose to generate new events in batch process in case of failure and resubmit them later, or even delete failed events belonging to another process. The build-in event management logic can make business process much more flexible.

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

Page 1 of 6

Business Process Intelligent enablement to handle failed events during Enterprise Applications

Intelligent business process requires automatically handling failed events according to pre-defined business logic in enterprise applications. When business flow fails during execution, this event is logged into persistent storage for further management. In some cases, failed events need to be handled at flow runtime without manual participation. A typical scenario is a batch process in which a flow contains thousands of sub flows. Failure of a few sub flows should not cause the whole flow to fail. Instead, they can be saved off individually while the whole business process will continue. Another example, if there are too many failed events which are difficult to deal manually, it's convenient to define a management process to smartly handle these failed events.

To achieve this, we provide a mechanism to allow handling failed events intelligently in business process integration. Figure 1 shows an example of a structure of business integration. Different applications are joined together with adaptors (Controller and Agent). An event is delivered from one application through Agent and passed into collaboration to process. If there are errors during the process, the event is stored as a failed record. In order to automatically handle failed events at collaboration runtime, failed event management is enabled inside business process. When process encounters errors, defined logic will tell event manager (the component that handles all requests to manage failed events) whether to save, delete or resubmit the failed event. Event management is not limited to delivered event itself, but enabled inside collaborations. A running business process can generate new failed events, and even delete/resubmit other failed events that are saved in a different collaboration.

Figure 1 Business Process Intelligent Enablement Infrastructure

The advantage of this mechanism is that it provides built-in event management logic in the business process and enables intelligent handling for failed events in enterprise applications.

This invention provides a mechanism to enable event management logic inside business process. Events normally are saved to database at the side of the event subscriber or consumer. During the business process, the event cannot be accessed, and its status is changed until the event finishes the whole process. Following is the event lifecycle of an event in a normal situation.

Event is delivered from subscriber. The business object is of application format.

The event is saved to persistent storage in advance (step 1 in Figure 2).

Business object is mapped to generic format if necessary.

After the business process is finished, business object is mapped to application format to event consumer.

Update the status of event (step 2) according to the result. If there are no errors, the event may be removed

from storage since a successful event need no...