Spring 集成 DSL 过滤器与 RouteToRecipients 与单个 Recipient 和 DefaultOutputToParentFlow

Question

当给定的评估返回 false 时，我需要将消息从我的父流路由到一个新的流，但当该评估返回 true 时让它在父流中继续。目前，我已经能够使用 Spring Integration DSL .filter() 成功实现此功能。方法没有任何问题。但是，我感觉好像在使用 .filter()这种方式不属于这种方法的真正意图。是否有某种类型的路由器可以用来更好地满足同样的需求？有没有必要改从这个.filter()实现到基于路由器的实现？

以下面的集成流程配置为例......

@Bean
public IntegrationFlow flow() {
    return IntegrationFlows
            .from("inboundChannel")
            .filter(someService::someTrueFalseMethod, onFalseReturn -> onFalseReturn.discardChannel("otherFlowInboundChannel"))
            .handle(someService::someHandleMethod)
            .get();
}

@Bean
public IntegrationFlow otherFlow() {
    return IntegrationFlows
            .from("otherFlowInboundChannel")
            .handle(someOtherService::someOtherHandleMethod)
            .get();
}

到目前为止似乎 .routeToRecipents()可能是我需要使用的。在我的场景中，我需要评估消息的 header ，这就是 recipientMessageSelector 的原因。正在使用。

@Bean
public IntegrationFlow flow() {
    return IntegrationFlows
            .from("inboundChannel"
            .routeToRecipients(router -> router
                .recipientMessageSelector("otherFlowInboundChannel", someService::someTrueFalseMethod)
                .defaultOutputToParentFlow()
            )
            .handle(someService::someHandleMethod)
            .get();
}

@Bean
public IntegrationFlow otherFlow() {
    return IntegrationFlows
            .from("otherFlowInboundChannel")
            .handle(someOtherService::someOtherHandleMethod)
            .get();
}

即使有了这个 routeToRecipients似乎有效的解决方案，它与上面的过滤器实现之间真的有什么好处吗？

Answer 1

嗯，这真的不是关于 Java DSL 方法以及如何使用它们。它实际上是关于那些 IE 模式的理论。

我们比较一下Filter和 RecipientListRouter来自 EIP!

过滤器 - https://www.enterpriseintegrationpatterns.com/patterns/messaging/Filter.html :

If the message content matches the criteria specified by the Message Filter, the message is routed to the output channel. If the message content does not match the criteria, the message is discarded.

因此，从技术上讲 filter自 false 起与您的期望不符决议你有点丢弃消息。然而，对于那些被丢弃的消息的可能处理，Spring Integration 提供了 discardChannel启动丢弃子流的选项。所以，我们可以把它当作 if..else build ...

收件人列表 - https://www.enterpriseintegrationpatterns.com/patterns/messaging/RecipientList.html

Then use a Recipient List to inspect an incoming message, determine the list of desired recipients, and forward the message to all channels associated with the recipients in the list.

所以，这有点像你需要的，因为你评估了一条消息和它的收件人，然后发送到他们的 channel 。只有模拟 filter 的问题行为，因为您不会有两个以上具有互斥目的的 channel 。

当 filter方法感觉像是滥用流控制(让我想起 Java 中的类似逻辑依赖于流控制的异常处理)，它并没有要求我们始终保持规范的行为以在消息不适合时以错误告终健康)状况。
recipientList is for more complicated scenarios when a selector is used for any arbitrary evaluation, not just plain boolean and has an ability to distribute the same message into several output channels.所以，我不推荐这个简单的 true/false设想。

您可以考虑研究另一种类似的模式:

基于内容的路由器 - https://www.enterpriseintegrationpatterns.com/patterns/messaging/ContentBasedRouter.html

Use a Content-Based Router to route each message to the correct recipient based on message content.

这个感觉非常接近您所需要的 true/false并且它不会滥用流量控制的错误(丢弃)，也不会规定我们的收件人列表。而这个也有那个 defaultOutputToParentFlow()当您想依赖非映射结果时。

恕我直言，我会留在 filter() - 与其 true/false逻辑和 discardChannel它真的看起来像是基于内容的路由器的特定实现:-)。