Setting up the adapter for multiple ways of handling errors
As we all know error handling within the adapter can be configured at the workflow, channel or adapter level. Most of the time we just write the original file out to something that can’t fail (well, unlikely to fail in the context of things) like the file system.
What if you want to do more with it?
With the advent of the ProcessingExceptionHandler interface it’s been possible to insert arbitrary services into exception processing. Additionally with ExceptionReportService you can get additional information about the exception that occurred.
Of course; behaviour like this is not without associated cost. If the services that you applying as part of the ProcessingExceptionHandler fail, then there is no fall back, you don’t pass go and collect 200 dollars. You need to make sure that the first thing you do is to archive the file so that can be reprocessed.
Let’s see an example configuration that does stuff.
So what does message-error-handler do?
An error is encountered in the workflow, so the message-error-handler is triggered.
First of all we write the original message is written out to messages/errors in a MIME-encoded format (so it can be retried)
Next we have some steps to actually create a report from the document that errored.
Run the document through a transform
Generate a simple exception report (basically an e.printStackTrace() equivalent) which is nested inside an element called ErrorElement
Insert this element as a child element of Root
Write the document out to ./messages/error-reports
If we configure a workflow like this, we can see what happens quite easily.
Testing our config
Right then, we can start it up and copy a test message in to messages-adapter-in. For our purposes the document is a very simple XML document that looks like
After 20 seconds or so, we can see that eventually a couple of new directories are created messages/errors and messages/error-reports; which is exactly what we expected. message/errors just contains the original file, along with the stacktrace in a MIME encoded file, but messages/error-reports contains a nicely formatted XML document that contains both the original message and the stacktrace in the XML.
Of course this usage scenario is fairly redundant as both files as written have stacktraces in them; but if we were having to return information to a calling process via a JMSReplyTo destination, then having the stacktrace available in XML would be pretty useful; perhaps you want to email someone that there’s been an error. If you wanted specific behaviour from your exception report, then all you need to do is make your own concrete implementation of ExceptionReportGenerator and configure it.