WebSphere Enterprise Service Bus for z/OS, Version 6.2.0 Operating Systems: z/OS


Managing failed events

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:
  1. JMSExport receives the request message.
  2. JMSExport invokes the SCA component.
  3. The SCA component returns a response to JMSExport.
  4. 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 Integration Applications > Failed Event Manager.


concept Concept topic

Terms of use | Feedback


Timestamp icon Last updated: 21 June 2010


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic//com.ibm.websphere.wesb620.zseries.doc/doc/recovery/cadm_failedoverview.html
Copyright IBM Corporation 2005, 2010. All Rights Reserved.
This information center is powered by Eclipse technology (http://www.eclipse.org).