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

[stnor]

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!

Stefan

[Gary Russell]

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

...splitter->sagateway->service------------------->aggregator->transformTo2Lists->splitter->...
               |                                 |
               |->errorChannel->transformErrors->|

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" />

[stnor]

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,
Stefan

[Gary Russell]

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,

[stnor]

Thanks Gary! That makes perfect sense!
Much appreciated!

All the best,
Stefan

[imro]

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?

Thanks.