The WebSphere® Process Server Recovery
service captures data about failed events. You can then use the failed
event manager to view, modify, resubmit, or delete the failed event.
The WebSphere Process Server Recovery
service manages failed operations between Service Component Architecture
(SCA) components and failed JMS events.
Failed SCA events
In the context of SCA,
an event is a request or response that is received by a service 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 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 Recovery service handles the
following types of failed SCA events:
- Event failures that occur during an asynchronous invocation of
an 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 SCA 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 (callback) 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.
The Recovery
service sends failed SCA 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, WPCRSDB) and is made available for administrative purposes
through the failed event manager interface.
Failed JMS events
The
Java Message Service (JMS) binding type and configuration determine
whether a failed event is generated and sent to the failed event manager.
JMS
bindings
WebSphere Integration Developer provides a recovery
binding property that allows you to enable or disabled recovery for
each JMS binding, at authoring time. The
recoveryMode property
can be set to one of the following:
bindingManaged |
Allow binding to manage recovery for failed messages |
unmanaged |
Rely on transport-specific recovery for failed messages |
Recovery for JMS bindings
is enabled by default. When it is enabled, JMS failed events are created
in the following situations:
- The function selector fails
- The fault selector fails
- The fault selector returns the RuntimeException fault
type
- The fault handler fails
- The data binding or data handler fails after a single retry in
JMS
In addition, a Service Component Architecture (SCA) failed event
is created when the
ServiceRuntimeException exception
is thrown in a JMS binding target component after a single retry in
JMS.
These failures can occur during inbound
or outbound communication. During outbound communication, JMSImport
sends a request message and receives the response message; a failed
event is generated if the JMS import binding detects a problem while
processing the service response. During inbound communication, the
sequence of events is as follows:
- JMSExport receives the request message.
- JMSExport invokes the SCA component.
- The SCA component returns a response to JMSExport.
- JMSExport sends a response message.
A failed event is generated if the JMS export binding detects
a problem while processing the service request.
The Recovery
service captures the JMS message and stores it in a Recovery table
in the Common database. It also captures and stores the module name,
component name, operation name, failure time, exception detail, and
JMS properties of the failed event. You can use the failed event manager
to manage failed JMS events, or you can use a custom program.
To disable recovery, you must explicitly disable
it in WebSphere Integration Developer by setting the
recoveryMode property
to
unmanaged.
Note: If the recoveryMode property
is missing (for earlier versions of applications), the recovery capability
is regarded as enabled.
When recovery is disabled, a failed
message is rolled back to its original destination and retried. The
system does not create a failed event.
WebSphere
MQ JMS bindings and generic JMS bindings
WebSphere
MQ JMS bindings and generic JMS bindings handle failures in a different
way than JMS bindings. Problems during request and response handling
do not generate a failed JMS event. Instead, they generate a failed
SCA event if the following two conditions are met:
- The underlying messaging system is configured to automatically
redeliver a failed message.
- The failure occurs in the export binding's target SCA component,
not in the binding itself.
When both conditions are true, the Recovery system generates
a failed SCA event that you can manage with the failed event manager.
In all other situations, the failed message rolls
back to its original destination, where it is handled according to
the messaging system configuration. No failed event is created.
How are failed events managed?
An administrator
uses the failed event manager to browse and manage 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 .