Exception Handling Strategy

[jpount]

Apologies for the fairly high-level topic but I was wondering if anyone had any thoughts or guidance on exception handling strategies.

I am working on a proof of concept using JBossESB to connect several JEE applications. The integration points are fairly simple at this stage ie one system puts a message on the bus and that message is delivered to a queue for pick up and processing by other systems.

Whilst I try to ensure that data in the message is valid, the consuming system may not be able to process it due to a business/application style error (data inconsistent/invalid) or a system level error ie the consuming system's database is offline etc. In these examples, the first error is probably not worth re-trying as the data will still be invalid, but the second is because the database may have been re-started.

I am wondering how I should approach exception handling in general ie should I implement it on each of my ESB deployments using the mechanisms provided by JBossESB or try to come up with some sort of generic, centralised service along the lines of this post ...

http://www.infoq.com/articles/lublinsky-soa-exception

I want to keep things simple, but at the same time, make them maintainable as we move forward.

Any suggestions would be greatly appreciated.

Thanks,
JP

[massios]

Hello JP,

We have implemented a strategy similar to the one in the link you provided. We have built an exception class hierarchy that distinguises between business and system errors as well as between errors caused by ESB code and code in other systems.

On top of that we have implemented an error handling ESB service. To call the error handling service we are using the process exception methods of the action pipeline.

So far we have not implemented retries and the plan is to let the ESB client depending on the error we return decide on the necessity of the retry.

[camunda]

Hey guys. Thanks for your thoughts on this so far and the provided link.

But I still wonder, in the case of business faults, often the consumer (best example: a business process), has to decide what to do based on the fault. So you have to transport the business fault to the consumer, how did you realize that with the central error handling service? How do you differentiate between handled and not handled faults by the service consumer?

Thanks a lot

Bernd

[massios]

We have a single entry point service to the ESB so far. The entry point service (the only one with a gateway) is accepting messages in a very general format. The format we use for messages is IFX (http://www.ifxforum.org/home/) but this is not important.

This entry point service is only responsible for routing the messages to different handling services. Basically based on the message type we call different types of systems. So we have services for handling that. If one of the "handler" services gets an error either business or system or if the ESB itself gets into validation (business errors) or throws an exception (system errors) we are translating those errors to a custom exception class hierarchy so that the errors are classified.

These exceptions are propagated backwards through the handler services. Basically you might want to do rollbacks, logging etc in each handler service. Then the exception finally arrives to the initial entry point service. Before the entry point service replies to the ESB client that an error has occurred it calls an "exception handling service" that for the time being is general in our system. This service can be using BPM if you wish so or the entry point service can use BPM if you wish so. But we don't at least yet. This service is responsible for creating a valid reply. You could program this exception handling service based on the type of exception to retry the call for which the error has happened if this makes sense.

Anyway in a nutshell we use an exception hierarchy to wrap errors into something that is easy for the system to understand if it needs retrying and we use a specific service for handling errors that for the time being is simple but which can in turn be turned into something more complicated that decides upon retries.

We also use attachments to pass additional information on in the original message.

Nikos.

[rburton]

    My current client is using the JBoss SOA Platform and I am researching how exception handling should be handled as well, but at a much lower level. Naturally, leveraging ActionPipelineProcessor#processException(Message, Throwable) seem like the proper way to handle exceptions and then route the message to an exception service; but there's also the FaultTo EPR on the Message to handle exceptions, but I don't find any information on the recommended way of handling exceptions at that level.

    I'd like to hear how others are handling exceptions throughout the ESB engine and routed those exceptions to an exception service for processing.

    The design of JBoss ESB isn't as strict as I would like it to be with regards to the EIP (Enterprise Integration Patterns). There's really no distinction between a Router, Transformer, etc. besides their logical responsibility. This makes the ESB easier to use, but also allows for bad practices and encourages merging responsibility. In Mule, Ross makes a clear distinction between Transformers, Routers, etc.. which encourages developers to isolate responsibility between the different layers.

    If anyone is interesting in learning more the following or about how I'm handling various things using JBoss ESB, let me know and I'll publish a blog about them. I'd love to share my experiences and at the same time, learn more about yours.

1. How to build ESB Services using Maven

2. Deploying ESB services to JBoss ESB using Maven

3. How to import an ESB project built with Maven into JBoss Studio

Cheers,

Richard L. Burton III

http://www.SmartCodeLLC.com

[jpount]

All,

Thanks for the various replies - I have been avoiding error handling for a while as I am busy trying out other bits of functionality that we need.

@Nikos, nice to hear you are building something along the lines of the post I provided. The concept sounds good to me but I was wondering how easy it would be to implement and how far to take it - I'd hate to build a complicated error handling beast when it might be quicker and easier to use the ESB provided mechanisms. It sounds like you have got a simple implementation in place which works for your scenario and enables you to build on it later.

Like Bernd, if I were to adopt the ESB provided mechanisms I would love to know if there are any best practices or gotchas that people have encountered. Error handling is obviously important so surely there are loads of people who could share their ideas. I might take a quick look at Mule, ServiceMix etc and see what they have done and what they suggest to get some more ideas. That said, it would be great to hear the thoughts of some of the JBossESB developers.

Cheers,

JP

[henrique.malheiro]

Hi all,

Like Nikos Massios, we are developing an error handling strategy based on Exception Type Hierarchy and generic error handler.

The Error Handler Action is placed on the beginning of the processing pipeline and whenever an exception is thrown and propagated backwards, it eventually reaches the Error Handler Action which processes the error in the processException annotated method. For now, it is only logging the error and routing the message to a Exception Handling Service which properly deals with the error.

Being generic, the exception handler service needs context information about the error to better deal with it, besides the type of exception raised. Namely, it is important to know the service name and category where the exception occurred, as well as the action name.

We would like to know if it is possible to get the action name where the exception occurred as this is crucial information to handle with exceptions. We also noticed that the service name and category can ben inferred by a property that is set on the message and as the following format: 'jboss.esb:category=MessageCounter,deployment=Project Examples.esb,service-category=Exemplos,service-name=Exemplo15PipelineWithErrorTime'. Is there a better way to achieve this?

This question is particularly relevant when using JBoss ESB Actions, as in this cases we have no control about the inner workings of those actions.

Thanks in advance,

Henrique Malheiro

[iboyle]

I have just build a simple exception handling framework for a small pilot I was working on, so I thought it worh sharing the experience with others.

My first attempt was to modify the FaultToEpr in the message header from the first action in the first pipeline called by the client, but this gave me three problems.

1. In an SOA environment, it is the client of the service which should determine where fault messages are delivered, not the target service itself. Image you are a client invoking a service and you expect a reply. If that reply either doesn't come back to you or arrives from somebody other than the service you sent it to, you would be concerned (or should be). If the target service sets the FaultToEpr itself, then the client loses control or the error handling.
2. JBoss SOA-P enforces the requirement that clients must set the FaultToEpr themselves. Hence, if the first target service sets the FaultToEpr in the action pipeline, it will be ignored until that service finishes and routes to another service, thereby making the first service the client and the second service the target. Having to insert a static route just to make the FaultToEpr work is an extra step I don't really want to have.
3. When you end up at the FaultToEpr, unless you have an audit trail recorded in the message body, you have no idea how you ended up in the Fault service. This makes it more difficult to handle any problems.

For me, a better pattern for using the FaultToEpr is for a service client to specify the To and FaultTo services before the call is made. The FaultTo service is then dedicated to handling any errors which occur solely in the To service. This makes the FaultToEpr a specific error handling system for specific services.

From my point of view a much better pattern for generalise use is to use the technique suggested by Nikos and Henrique.

At the start of every action pipeline I insert a custom action. Here is the pseudo-code for the action :-

public PipelineExceptionHandlerAction(ConfigTree config) throws ConfigurationException {

        // Pass the name category:name of exception service as parameters and record category:name of current service

        exceptionServiceCategory = config.getAttribute("exceptionServiceCategory");

        exceptionServiceName = config.getAttribute("exceptionServiceName");

        parentServiceCategory = config.getParent().getAttribute(ListenerTagNames.SERVICE_CATEGORY_NAME_TAG);

        parentServiceName = config.getParent().getAttribute(ListenerTagNames.SERVICE_NAME_TAG);

    }

public Message process(Message message) {

         // Do nothing on 1st pass of pipeline

         return message;

}

public void exceptionHandler(Message message, Throwable t) {

         // On 2nd pass of pipleline, if there is an exception, add category:name of offending service to the message and route to exception service

        message.getBody().add("exceptionTrace", t);

         message.getBody().add("sourceServiceName", parentServiceName);

         message.getBody().add("sourceServiceCategory", parentServiceCategory);

         invoker.deliverAsync(message);

}

This type of code will only work if the original inbound message is set to be mep=OneWay, since if an exception occurs, there is now no ability to reply back to the client.

Message was edited by: Iain Boyle Take a look at https://community.jboss.org/message/622789#622789 for an example implementation.

[kishor_pawar89]

Hi Guys,

I am also working on the similar approach for Exception handling.

https://community.jboss.org/message/750997#750997 Can you guys help me out?

[joe_boy12]

FaultToEPR can be used if its set on Message - if you are listening on a gateway channel - u cant do that - you have to override the composer to inject that before it hits the pipeline where fault is generated. Also I believe only Fault details are sent to FaultToEPR and not along with the original message. We had a scenario where we had to extend the StaticRouter to inject FaultToEPR for each Service as each service had different fault to epr. but it became too complicated to maintain so we went with JCA DLQ mechanism.