Strategy for passing same payload between messages when optional outbound gateways fail

Question

I have a workflow whose message payload (MasterObj) is being enriched several times. During the 2nd enrichment () an UnknownHostException was thrown by an outbound gateway. My error channel on the enricher is called but the message the error-channel receives is an exception, and the failed msg in that exception is no longer my MasterObj (original payload) but it is now the object gotten from request-payload-expression on the enricher.

The enricher calls an outbound-gateway and business-wise this is optional. I just want to continue my workflow with the payload that I've been enriching. The docs say that the error-channel on the enricher can be used to provide an alternate object (to what the enricher's request-channel would return) but even when I return an object from the enricher's error-channel, it still takes me to the workflow's overall error channel.

How do I trap errors from enricher's + outbound-gateways, and continue processing my workflow with the same payload I've been working on?

Is trying to maintain a single payload object for the entire workflow the right strategy? I need to be able to access it whenever I need.

I was thinking of using a bean scoped to the session where I store the payload but that seems to defeat the purpose of SI, no?

Thanks.

Answer 1

Well, if you worry about your MasterObj in the error-channel flow, don't use that request-payload-expression and let the original payload go to the enricher's sub-flow.

You always can use in that flow a simple <transformer expression="">.

On the other hand, you're right: it isn't good strategy to support single object through the flow. You carry messages via channel and it isn't good to be tied on each step. The Spring Integration purpose is to be able to switch from different MessageChannel types at any time with small effort for their producers and consumers. Also you can switch to the distributed mode when consumers and producers are on different machines.

If you still need to enrich the same object several times, consider to write some custom Java code. You can use a @MessagingGateway on the matter to still have a Spring Integration gain.

And right, scope is not good for integration flow, because you can simply switch there to a different channel type and lose a ThreadLocal context.