IBM Support

Exception handling and recovery for WebSphere Process Server (WPS) using synchronous or asynchronous service invocation

Question & Answer


Question

How do you handle exceptions during synchronous and asynchronous outbound processing? What are the differences and recommendations for both invocation styles?

Answer

Exception handling and recovery are important disciplines for application developers. This FAQ document guides you through the necessary basics and recommendations for handling runtime exceptions and building a stable recovery scenario. In addition, this FAQ includes information on making a decision between using a synchronous or asynchronous invocation style - the advantages and disadvantages.





Overview of invocation patterns and exception types

Before starting with the guide, read the following notes on synchronous and asynchronous invocation styles and their differences:
  • The synchronous invocation pattern makes a request to the target and receives the response in the same thread.

  • The asynchronous invocation pattern sends the request and receives the response in different threads. A response is optional (one-way operation) or can be received explicitly by the client certificate authority (CA) (deferred response) or implicitly sent by the server (callback).

Exception handling in WebSphere Process Server and WebSphere Enterprise Service Bus are divided into two categories:
  • The business exceptions are declared in a methods signature (for example, in faults or in a Java™ throw declaration) and are anticipated by the application. These exceptions are passed back to the client and are wrapped by a ServiceBusinessException exception.

  • More important for further discussion are system exceptions (also called runtime exceptions). There are some subclasses that are derived from the ServiceRuntimeException and are returned to the client for further interrogation. The following exception types are available:
    • ServiceExpirationRuntimeException marks an asynchronous call as expired. This scenario can occur for request and response messages.
    • ServiceTimeoutRuntimeException is thrown when an expected response does not arrive within a specified time limit using a deferred response invocation style.
    • ServiceUnavailableException is thrown when an asynchronous outbound call (using an import) fails to reach the target service.
    • ServiceUnwiredReferenceRuntimeException indicates that the service reference on the component is not wired correctly.

      • Back to top


Handling exceptions for synchronous invocations
    During a synchronous invocation, both the client and server run in the same thread; the target service returns a message, an exception, or nothing in the case of a one-way operation. The exception can be a business or system exception. When you invoke a service synchronously, include an exception handler, for example:

    try {
      someService.someOperation(...);
    }
    catch(ServiceRuntimeException e) {
      // handle runtime exception
    }

    This catch handler captures the exception (here a runtime exception) and allows you to handle it accordingly. If you want a more specific runtime exception than ServiceRuntimeException, use the following code snippet, which shows how to handle a specific runtime exception:

    try {
      someService.someOperation(...);
    }
    catch(ServiceUnavailableException e) {
      // service was unavailable
    }

    Calling any service and capturing an exception at run time should include mechanisms to retry the call (after a specific interval or waiting period) or to generate a fault and handle the exception in a Business Process Execution Language (BPEL) process. This depends on the placement of the Java code. If it is used in a plain old Java object (POJO), you can write additional code to retry the outbound call. In a snippet, you can easily generate a fault and then use a fault handler and compensation. Use the following code snippet to generate a fault; you can use generic or custom exception identifiers:

    raiseFault(new QName(
      "http://anyNamespace","SomeExceptionIdentifier"));

    For details on faults and exception handling, visit the Business Process Management Samples Gallery. Note that exception handling strongly depends on the context and can be fulfilled by different techniques:

  • Handle the exception in place (where the invocation is executed).
  • Generate a BPEL fault and use a fault handler in a BPEL process.
  • If the current process or POJO is called by another component, determine if the exception handling can be handled better by these components, then send a fault back to them using a response message.
  • Change the invocation style to asynchronous and use the failed event manager (read next section for details).

    • Back to top


Handling exceptions for asynchronous invocations


This section details the traps and pitfalls of exception handling and lists the advantages of using the failed event manager.

The client and service provider (server) run in different threads. On both threads, exceptions can be raised. For example, the client might lose the network connection, or the service provider might fail in case of another runtime exception. In the Service Component Architecture (SCA) programming model, the client does not receive the server side exceptions because they are not propagated, with one important exception: The client is a business process component, and the target service returns a system exception. This exception to the rule is necessary to allow the process designer to handle system exceptions and to model recovery mechanisms.

Automatic retry mechanism
SCA uses the service integration bus (SIBus) to transport messages between components. As soon as a module is deployed, a background task creates a queue on the SIBus for each import artifact component (outbound processing and service invocation). If the service invocation fails (by a system exception), the SIBus tries to resend the message at least five times. The following article describes how to change the default retry threshold:

Recovering from failed asynchronous SCA service invocations on WebSphere Process Server

Recovery exception destination and database
In WebSphere Process Server and WebSphere Enterprise Service Bus, by default, one system exception destination for each server holds all failed events (events that reached the retry limit and are archived). The destination has the following default name structure:

_SYSTEM.Exception.Destination.<nodeName>.<serverName>-
SCA.SYSTEM.<cellName>.Bus

In WebSphere Process Server, all failed messages are routed to a recovery exception destination, which follows this naming convention:

WBI.FailedEvent.WPS.<serverName>

Failed event manager subsystem
For each failed message a "failed event" is generated and registered in a recovery database (a set of specific WebSphere Process Server and WebSphere Enterprise Service Bus common database tables). The failed event represents the basic system exception. In addition, the failed event manager application is the tool of choice to manage all failed events.

No runtime data is lost during the messaging and failed event process because the entire data flow is routed through the SCA and SIBus layer. This includes the request and response message handling as well as exception handling by the failed event manager application. Using this subsystem, it is unnecessary to implement specific recovery and exception handling mechanisms.

Enabling asynchronous invocation and failed event management
To enable a service for asynchronous invocation, adjust the component artifacts interface and reference:
  1. In WebSphere Integration Developer, in the assembly diagram, select the component.
  2. On the Properties tab, in the Details section, select the reference interface of the target service.
  3. On the Quality of Service (QOS) Qualifiers tab, apply the following settings to the QoS parameters:


The component that invokes the reference partner must also ensure that the service is invoked asynchronously. If the invocation is implemented by Java code in a BPEL snippet or POJO, the method invocation must be adjusted as well:

Service someService = (Service)
  ServiceManager.INSTANCE.locateService(
    "<interfacePartnerName");

someService.invokeAsync("<someOperation>", <payloadBO>);

Manage and resubmit failed events
All failed events that are registered in the recovery database are managed by the failed event manager application, which is part of the WebSphere Process Server and WebSphere Enterprise Service Bus products. Visit the information center for more information about the failed event manager:

Managing WebSphere Process Server failed events

Back to top

Choosing the right invocation



There is no simple guideline that allows you to choose the right invocation style for every situation. Invocation styles, exception handling, and recovery must be treated as a unit in a complex application architecture that allows for different approaches. However, the following sections can help you make a more informed choice.

Asynchronous invocation

Choose asynchronous invocation in the following situations:
  • You are calling a long-running BPEL process. In this situation, do not invoke an operation synchronously because you cannot predict when the target process will finish and send the response. Invoking an operation synchronously in this situation risks creating a service timeout exception.
  • You do not want to handle any system exceptions or use the failed event manager capability, which processes failed events for you.
  • You want to use a deferred response or callback mechanism to retrieve the response from the service provider.
  • You invoke message-related SCA import components in general (JMS, MQ, or SOAP-JMS binding).

Synchronous invocation

Choose synchronous invocation in the following situations:
  • You expect a response message in a short and specific time frame and cannot handle failed events that are generated.
  • You want to handle exceptions explicitly using your own code or BPEL process design that contains fault and compensation handlers.
  • You are using event sequencing on the service target. If an asynchronous invocation fails, the target service is stuck until the next messages arrives in order. If the message is held on the system exception destination queue, you must resubmit it using the failed event manager. Further processing of the target service depends on manual interaction.

Tips for recovery using the failed event manager
  • No failed events are generated for synchronous invocations or any two-way business process invocation.
  • You must manually resubmit failed events to finish the invocation.
  • You can adjust the retry threshold of the SIBus queue that is used for resending an event message. However, this often is not practical:
    • The retries are performed immediately one after another, in general within seconds. If there is a network outage for a long period, even a higher threshold does not solve the basic problem.
    • Using a very high threshold value (one hundred and more) generates a lot of traffic on the SIBus for a resend operation that might fail.

      • Back to top

Exception handling and recovery resources



The following resources on developerWorks provide additional information regarding invocation styles, exception handling, and automated recovery:

[{"Product":{"code":"SSQH9M","label":"WebSphere Process Server"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Component":"Service Component Architecture","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF010","label":"HP-UX"},{"code":"PF016","label":"Linux"},{"code":"PF027","label":"Solaris"},{"code":"PF033","label":"Windows"},{"code":"PF035","label":"z\/OS"}],"Version":"7.0;6.2;6.1.2;6.1","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}},{"Product":{"code":"SS7J6S","label":"WebSphere Enterprise Service Bus"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Component":" ","Platform":[{"code":"","label":""}],"Version":"","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]

Product Synonym

WPS

Document Information

Modified date:
15 June 2018

UID

swg21294883

Page Feedback