I'm trying to figure out a general strategy for exception handling within Spring-Integration workflows.
I'm using an error-channel attribute on the int-http:inbound-gateway and that works fine for errors that I encounter in the workflow.
<int-http:inbound-gateway
...
error-channel = "general-errors"
...
/>
<int:channel id="general-errors" />
<int:chain input-channel = "general-errors" >
....
</int:chain>
In this case, when there is an exception, the steps in the general-errors chain create the return message.
But I also was looking at having some specific error handling for inner flows in the workflow, for instance for calls to external services.
<int:chain>
<si:gateway request-channel="transformForRequest" />
<si:gateway request-channel="httpCall" error-channel="httpError" />
<si:gateway request-channel="transformResponse" />
</int:chain>
<int:channel id="httpCall" />
<int-http:outbound-gateway request-channel="httpCall"
...
/>
<int:channel id="httpError" />
<int:chain request-channel="httpError" >
... do special error processing for http call ...
</int:chain>
I've tried this and I discovered that, upon an exception in the call to the int-http:outbound-gatewaywhich then calls to httpError chain, the workflow processing continues at transformResponse. What I would like to happen is to return the error payload and headers from the http:inbound-gateway at that point.
Is there an different approach that would allow me to apply specific exception processing within inner flows? Or perhaps I can force a return to the http:inbound-gateway via replyChannel header from within the httpError chain?
Thanks for any help/pointers.
It is not fully clear what you are asking, but it feels like you'd like to return some custom payload from the
httpErrorsub-flow, but return it immediately into an<int-http:inbound-gateway>in the beginning of the flow. If that is the case, then it is not possible. You return something from thehttpErrorsub-flow back to that<si:gateway request-channel="httpCall">. Since it is just plain return it is treated as a reply and therefore it send to whatever goes after. In your case<si:gateway request-channel="transformResponse" />. The payload is just out of the messaging system scope. You made your flow go on, so it will be independently of the payload.Of course your can interfere into the logic based on the returned payload via
<router>and already there decide to continue the flow downstream or come back to the inbound gateway in the beginning.No, the
replyChannelwon't help you from thehttpErrorsub-flow. Just because a<si:gateway>creates its ownreplyChannelwithin its context. Therefore coming back to this channel will just bring a reply payload back to the<si:gateway>, not an HTTP Inbound Gateway in the beginning. The bigger problem that even an explicitreply-channelconfiguration for that HTTP Inbound Gateway won't help here. It's consuming logic in the end relies on areplyChannelheader anyway. Which in our case is areplyChannelfor that<si:gateway>in the middle.So, if you want to have a custom
httpErrorand bring its result back to the HTTP Inbound Gateway immediately and don't want to have a router just after thathttpCall, then look into throwing some custom exception which you would handle respectively in the top-levelgeneral-errorsfor HTTP Inbound Gateway.Everything is OK with what you have so far - only the problem that your requirement cannot wonk just as is without some extra effort. This is something similar to what we could do with just plain Java when we call one function from another and would like to return immediately without going for the next function.