TheWebSphere Process Server Recovery
service monitors for failed operations between Service Component Architecture
(SCA) components. If an operation fails, the Recovery service captures data
about the event and the failure. You can then use the failed event manager
to view, modify, resubmit, or delete the failed event.
What is a failed event?
In the context of WebSphere® Process Server,
an event is a request that is received by a WebSphere Process Server application.
It can come from an external source (such as an inbound application adapter)
or an external invocation to a web service. The event is comprised of a reference
to the business logic it wants to operate and its data, stored in a Service
Data Object (a business object). When an event is received, it is processed
by the appropriate WebSphere Process Server application business logic.
A single thread of execution can branch off into multiple branches (or
threads); the individual branches are linked to the main invoking event by
the same session context.
If this business logic in one of these branches cannot execute completely
due to system failure, component failure, or component unavailability, the
event moves into the failed state. If multiple branches fail, a failed event
is created for each. The WebSphere Process Server Recovery service handles
the following types of failed events:
- Event failures that occur during an asynchronous invocation of a Service
Component Architecture (SCA) operation
- Event failures that are caused by a runtime exception (in other words,
any exception that is not declared in the methods used by the business logic)
The Recovery service does not handle failures from synchronous invocations.
Failed events typically have source and destination information associated
with them. The source and destination are based on the failure point (the
location where the invocation fails), regardless of the type of interaction.
Consider the following example, where Component A is asynchronously invoking
Component B. The request message is sent from A to B, and the response message
is sent from B to A.
- If the exception occurs during the initial request, Component A is the
source and Component B is the destination for the purposes of the failed event
manager.
- If the exception occurs during the response, Component B is the source
and Component A is the destination for the purposes of the failed event manager.
This is true for all asynchronous invocations.
How are failed events managed?
The Recovery service sends failed asynchronous interactions to failed event
destinations that have been created on the SCA system bus (SCA.SYSTEM.cell_name.Bus).
The data for failed events is stored in the failed event database (by default,
WPSCRDB) and is made available for administrative purposes through the failed
event manager interface.
An administrator uses the failed event manager to browse and manage all
WebSphere Process Server failed events. Common tasks for managing failed events
include:
- Browsing all failed events
- Searching for failed events by specific criteria
- Editing data for a failed event
- Resubmitting failed events
- Deleting failed events
To access the failed event manager, click Integration Applications >
Failed Event Manager.
Last updated: Tue 31 Oct 2006 09:53:28
(c) Copyright IBM Corporation 2005, 2006.
This information center is powered by Eclipse technology (http://www.eclipse.org)