Announcement Announcement Module
No announcement yet.
Error handling (async) with splitter -> service activator -> aggregator Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Error handling (async) with splitter -> service activator -> aggregator

    I'm looking for the correct way/pattern how to deal with errors in a service activator after a splitter.

    I need to split up an XML-file for parallel processing by a task executor pool.
    The successfully processed messages (they are sent to a remote system using rmi) need to be aggregated to an output file and I'd like to output errors (the ones rejected by the remote system) to a different file.

    What is the preferred way to model this with Spring Integration?

    Specifically, how do I deal with aggregation of the successes and the errors/exceptions?

    I've looked in the reference manual and in the Apress book, but I can't seem to find a suggestion on how to deal with this use-case.

    Thanks in advance!

    Last edited by stnor; Mar 7th, 2012, 10:05 AM.

  • #2
    There are a number of ways to do it; one would be something like...

                   |                                 |
    The sagateway would be a <service-activator/> that references a <gateway/> allowing you to insert error handling mid-flow.

    <service-activator ... ref="gw" />
    <gateway id="gw" service-interface="foo.GW" default-request-channel="toService" errorChannel="myErrors" />


    • #3
      Hi Gary,
      Thanks for the quick reply.

      I think I get it. I assume the aggregator will have to work on SI's GenericMessage and ErrorMessage in order to distinguish good from bad apples?

      Best regards,
      Last edited by stnor; Mar 8th, 2012, 03:32 AM.


      • #4
        No; the aggregator doesn't care about the types (in this scenario - like I said there are many ways to do this - I just feel the above is one of the simplest).

        The main flow produces objects of type GoodGuy and the error flow objects of type BadGuy; the aggregator will simply create a list of objects (mixed). Then, a custom transformer produces two lists...

        Notice in the error flow I included a transformer - transform the ErrorMessage into a BadGuy object.

        public List<List<Object>> transform(List<Object> list) {...}
        ...which you can then split into two messages (with a standard <splitter/>) and route each to a different channel based on the type of the objects in the list.

        In fact, if you make the transformer above create lists that are wrapped in a type, it might make it even easier...

        public abstract class GuyList { ... } // simple wrapper for a list object.
        public class BadGuys extends GuyList {}
        public class GoodGuys extends GuyList {}
        public class SortGoodFromBadTransformer {
            public List<GuyList> transform(List<Object> list) {...}
        Then, downstream of the splitter you can use a payload type router to route BadGuys to one adapter and GoodGuys to another,
        Last edited by Gary Russell; Mar 8th, 2012, 07:38 AM.


        • #5
          Thanks Gary! That makes perfect sense!
          Much appreciated!

          All the best,


          • #6
            This is (more or less) the use case I'm looking for. In order to process messages in parallel (i.e. in different threads) I tried to use dispatcher task-executor="executor" on the splitter's outgoing channel but it doesn't seem to work (e.g. "Dispatcher has no subscribers").

            Can you please post your xml configuration?