Exception Handling with Integration Server By Igor Androsov

---

Introduction

This article discusses error handling within the Integration Server development.

Although Integration server provides many ways to catch and handle errors, I thought it would be useful to have a discussion on this subject. This article will present some real-world, production-tested error handling techniques.

---

Classifying error types

Let's start by classifying the different types of errors that a webMethods developer may encounter. There are three main types:

1. Application Error -- The result of business process or application failure, or a designation assigned by a developer.
2. Expected System Error -- The predictable result of a known invalid action. These errors are thrown by the server or its components (adapters) and are manifested as Java exceptions.
3. Unexpected System Error -- The unexpected result of a system failure, use of incompatible software, or starvation of resources, memory, disk space, or any other event.

---

Classifying error types

Most webMethods Integration Server development is in one of two languages -- Flow and Java (Note: DSP web development is out of scope for this article.).

For Java development, standard exception handling is available using Try-Catch blocks. This logic is well-known and heavily documented. When throwing errors inside of webMethods Java services, though, discretion should be used. It is a clean API practice to handle as much exception logic as possible from within the throwing service. Using defensive programming will help to avoid unwanted failures. Only when the failure is beyond the developer's control should the Inetgration Server be notified via a Service Exception.

For Flow development, webMethods makes available several exception handling techniques.

The BRANCH operator is handy for managing logic and application errors. By creating BRANCH logic with "case" or "if-else" structure, a developer can determine the exact error condition and then take the appropriate action.

The EXIT operator can be used to exit from an entire Flow or just a section of Flow. The developer can designate that the exit is an exception by signaling "FAILURE" or that the error has been caught by signaling "SUCCESS". webMethods provides a service -- pub.error:getLastError -- which simulates the familiar Java or C++ catch block.

The webMethods Integration Server also ships with Event Manager. Event Manager is very useful as an umbrella for error notification because it catches exception events for the entire server. Its broad scope, however, can work against you as your system can quickly flood with unwanted notifications. Because of this, Event Manager must be configured for filtering so that it only catches errors that are required by the developers.

---

Handling error notifications

How error notifications are handled once caught is required business logic for any integration and must be addressed during the Requirements Gathering phase of a project.

The most common error reporting method is email notification but many companies use a hybrid system in which Remedy, Peregrine, or other sophisticated issue tracking tools are deployed as well. An error should be classified and reported to any relevant applications as well as delivered via email to developers. This approach helps to deal with critical issues quickly.

A generic Error Handling service can be written to manage these tasks. It should reside in a utility-level package from which the entire corporate implementation will benefit. Then, a customized Error Handling service should be written to add an additional abstraction layer. This step provides freedom to change the error notification logic without changing the underlying business integration logic or performing additional regression tests.

Developing an Error Handling service is a simple process.

1. Install the downloadable package supporting this article.
2. Using the Event Manager, assign ErrorHandler.event:exceptionHandler to Exception Event.
3. Set the appropriate filters for Exception Events. Remember that the Exception Event will not fire if the exception-throwing service is not included in the Filter field.

Once assigned, the service will be invoked with every exception satisfying the filter. The default service behavior of ErrorHandler.event:exceptionHandler sends email to an intended recipient. This service can be modified to accomodate issue tracking software.

---

Throwing errors

In order to use Exception Handling services, we must write code that throws an error to be caught.

The following code sample exemplifies an error message thrown using Java:

try {
  // logic goes here
}
catch (Exception e) {
  throw new ServiceException(e.getMessage());
}

Using Flow, though, a developer must process the error differently. Using Flow, a developer will call the EXIT operator and provide a detailed message for the failed action. Following a standard naming convention is good practice for using EXIT because it helps to parse and then route the error message to the proper recipient or target tracking system.

Error Code: 1111
Reason Code: 9999
Message: Description of business process error

---

[1]  2  Next>>

Go Deeper on the Subject: The wMUsers Discussion Forums