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.

CodePudding user response：

It is not fully clear what you are asking, but it feels like you'd like to return some custom payload from the httpError sub-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 the httpError sub-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 replyChannel won't help you from the httpError sub-flow. Just because a <si:gateway> creates its own replyChannel within 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 explicit reply-channel configuration for that HTTP Inbound Gateway won't help here. It's consuming logic in the end relies on a replyChannel header anyway. Which in our case is a replyChannel for that <si:gateway> in the middle.

So, if you want to have a custom httpError and bring its result back to the HTTP Inbound Gateway immediately and don't want to have a router just after that httpCall, then look into throwing some custom exception which you would handle respectively in the top-level general-errors for 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.