The gateway() operator in an IntegrationFlow definition is a special service activator implementation, to call some other endpoint or integration flow via its input channel and wait for reply. Technically it plays the same role as a nested <gateway> component in a <chain> definition (see Calling a Chain from within a Chain) and allows a flow to be cleaner and more straightforward. Logically, and from business perspective, it is a messaging gateway to allow the distribution and reuse of functionality between different parts of the target integration solution (see Messaging Gateways). This operator has several overloads for different goals:spring-doc.cn

  • gateway(String requestChannel) to send a message to some endpoint’s input channel by its name;spring-doc.cn

  • gateway(MessageChannel requestChannel) to send a message to some endpoint’s input channel by its direct injection;spring-doc.cn

  • gateway(IntegrationFlow flow) to send a message to the input channel of the provided IntegrationFlow.spring-doc.cn

All of these have a variant with the second Consumer<GatewayEndpointSpec> argument to configure the target GatewayMessageHandler and respective AbstractEndpoint. Also, the IntegrationFlow-based methods allows calling existing IntegrationFlow bean or declare the flow as a sub-flow via an in-place lambda for an IntegrationFlow functional interface or have it extracted in a private method cleaner code style:spring-doc.cn

@Bean
IntegrationFlow someFlow() {
        return IntegrationFlow
                .from(...)
                .gateway(subFlow())
                .handle(...)
                .get();
}

private static IntegrationFlow subFlow() {
        return f -> f
                .scatterGather(s -> s.recipientFlow(...),
                        g -> g.outputProcessor(MessageGroup::getOne))
}
If the downstream flow does not always return a reply, you should set the requestTimeout to 0 to prevent hanging the calling thread indefinitely. In that case, the flow will end at that point and the thread released for further work.
If the downstream flow does not always return a reply, you should set the requestTimeout to 0 to prevent hanging the calling thread indefinitely. In that case, the flow will end at that point and the thread released for further work.