Exception Handling with Integration Server

When dealing with special binary objects such as JDBC Connection objects or JMS session objects, though, you must take special precautions. Even though invoking pub.flow:getLastError restores the pipeline as it was when the exception was thrown, binary objects are unrecoverable.

To prevent the trashing of a connection and session object, create it before the Try block, if possible. This is an example using JDBC database connectivity.

Saving Data on the IS Session

Another way of preserving a special binary object is to do it in the user's session with the Integration Server.

When saving an object in the user's IS session, the object will remain valid until the session destroyed. To accomplish this task, use the Java service ErrorHandler.util:put_object_in_session in this article's accompanying package. ErrorHandler.util:ErrorHandler.util:put_object_in_session saves the binary object to an IS session from which it can be later retrieved. The service source code is below:

import com.wm.app.b2b.server.Session;
import com.wm.app.b2b.server.ServerAPI;

Object obj = in.get("object");
String strObjectName = in.getString("objectName");
Session session = Service.getSession();

// Data type
Object tobj = session.get(strObjectName);
if (tobj != null)
    session.remove(strObjectName);

session.put(strObjectName, obj);

To retrieve the object from the user IS session, use the Java service ErrorHandler.util:get_object_from_session, also included in the package. The service source code is below:

  String strObjectName = in.getString("objectName");
  Session session = Service.getSession();
  out.put("object", session.get(strObjectName));

Now, let's put it all together. Here is an example Flow structure to implement putObjectInSession and getObjectFromSession:

Retrofitting for Exception Handling

The most useful piece of data in an error is the name of the service from which the error was thrown.

If you are including building a new integration that uses Error Handling, pub.flow:getLastError is a reliable service for finding the exception-throwing service -- just look at the output field error/service. But, when implementing Error Handling procedures on production code, making edits to working Flow may not be an option. There is a workaround for this situation.

For retrofitting production code, make use of the accompanying package's service ErrorHandler.util:get_service_name. This service examines the complete call stack thrown by the exception event and identifies which service was called immediately before the Error Handling service. It is not a perfect solution, but it is minimally intrusive to production environments (and it works!).

The source code for ErrorHandler.util:get_service_name is below:

IDataHashCursor curs = pipeline.getHashCursor();
String caller = "SVC - ";
try
{
  Thread t = Thread.currentThread();
  com.wm.app.b2b.server.ServerThread st =
        (com.wm.app.b2b.server.ServerThread)t;
  java.util.Stack stack =
        st.getState().getCallStack();
  for (int i = 0; i < stack.size(); i++)
  {
    if (i < stack.size() - 1)
    {
      caller += stack.elementAt(i).toString();
      caller += " ";
    }
  }
}
catch (Exception e)
{
  caller = new String("non-determinable");
}
curs.last();
curs.insertAfter("serviceName", caller);

Conclusion

Strong error handling plays an important part in developing robust, failure-resistant systems. I hope that this article adds clarity to webMethods Integration Server exception handling logic.

<<Prev  1  [2]  

Go Deeper on the Subject: The wMUsers Discussion Forums