|
此版本仍在开发中，尚未被视为稳定版本。对于最新的稳定版本，请使用 Spring Integration 6.4.0！ |
消息处理程序链
这MessageHandlerChain是MessageHandler这可以配置为单个消息端点，同时实际委托给其他处理程序链，例如过滤器、转换器、拆分器等。
当需要以固定的线性进度连接多个处理程序时，这可能会导致更简单的配置。
例如，在其他组件之前提供 transformer 是相当常见的。
同样，当您在链中的其他组件之前提供过滤器时，您实际上是创建了一个选择性使用者。
无论哪种情况，链都只需要一个input-channel和一个output-channel，无需为每个单独的组件定义通道。
这MessageHandlerChain主要是为 XML 配置设计的。
对于 Java DSL，一个IntegrationFlowdefinition 可以被视为一个链组件，但它与下面本章中描述的概念和原则无关。
有关更多信息，请参阅 Java DSL。 |
Spring 集成的Filter提供 boolean 属性：throwExceptionOnRejection.
当你在同一个点对点通道上为多个选择性使用者提供具有不同接受条件时，你应该将这个值设置为'true'（默认值是false），以便调度程序知道消息已被拒绝，并因此尝试将消息传递给其他订阅者。
如果未引发异常，则调度程序会认为消息已成功传递，即使筛选器已删除消息以防止进一步处理。
如果您确实想要 “drop” 消息，过滤器的 'discard-channel' 可能很有用，因为它确实让您有机会对丢弃的消息执行某些作（例如将其发送到 JMS 队列或将其写入日志）。 |
处理程序链简化了配置，同时在内部保持组件之间相同程度的松散耦合，如果在某些时候需要非线性排列，修改配置是很简单的。
在内部，该链被扩展为列出的端点的线性设置，由匿名通道分隔。
在链中不考虑 reply channel headers。
只有在调用最后一个处理程序后，生成的消息才会转发到回复通道或链的输出通道。
由于这种设置，除最后一个处理程序之外的所有处理程序都必须实现MessageProducer接口（提供 'setOutputChannel（）' 方法）。
如果outputChannel在MessageHandlerChain设置后，最后一个处理程序只需要一个 output channel。
与其他终端节点一样，output-channel是可选的。
如果链的末尾有回复消息，则 output-channel 优先。
但是，如果它不可用，则链处理程序将检查入站消息上的回复通道头作为回退。 |
在大多数情况下，您无需实施MessageHandler你自己。
下一节重点介绍 chain 元素的命名空间支持。
大多数 Spring 集成端点，例如服务激活器和转换器，都适合在MessageHandlerChain.
配置链
这<chain>元素提供了一个input-channel属性。
如果链中的最后一个元素能够生成回复消息（可选），它还支持output-channel属性。
然后，子元素是 filters、transformers、splitter 和 service-activator。
最后一个元素也可以是 router 或 outbound channel adapter。
以下示例显示了链定义：
<int:chain input-channel="input" output-channel="output">
<int:filter ref="someSelector" throw-exception-on-rejection="true"/>
<int:header-enricher>
<int:header name="thing1" value="thing2"/>
</int:header-enricher>
<int:service-activator ref="someService" method="someMethod"/>
</int:chain>这<header-enricher>元素设置一个名为thing1的值为thing2在消息上。
标头扩充器是Transformer仅触及 Headers 值。
您可以通过实现MessageHandler这完成了 Headers 修改并将其作为 bean 进行连接，但是 Header-Enricher 是一个更简单的选项。
这<chain>可以配置为消息流的最后一个 “closed-box” 使用者。
对于此解决方案，您可以将其放在 <链的末尾>一些 <outbound-channel-adapter>，如下例所示：
<int:chain input-channel="input">
<int-xml:marshalling-transformer marshaller="marshaller" result-type="StringResult" />
<int:service-activator ref="someService" method="someMethod"/>
<int:header-enricher>
<int:header name="thing1" value="thing2"/>
</int:header-enricher>
<int:logging-channel-adapter level="INFO" log-full-message="true"/>
</int:chain>|
不允许的属性和元素
某些属性（例如 对于 Spring 集成核心组件，XML 模式本身会强制执行其中一些约束。 但是，对于非核心组件或您自己的自定义组件，这些约束由 XML 名称空间解析器（而不是 XML 架构）强制执行。 这些 XML 名称空间解析器约束是在 Spring Integration 2.2 中添加的。
如果您尝试使用不允许的属性和元素，XML 名称空间解析器会抛出一个 |
使用 'id' 属性
从 Spring Integration 3.0 开始，如果为 chain 元素赋予id属性，则元素的 Bean 名称是链的id和id元素本身。
没有 Elementid属性未注册为 bean，但每个属性都被赋予了一个componentName这包括链条id.
请考虑以下示例：
<int:chain id="somethingChain" input-channel="input">
<int:service-activator id="somethingService" ref="someService" method="someMethod"/>
<int:object-to-json-transformer/>
</int:chain>在前面的示例中：
-
这
<chain>根元素具有id的 'somethingChain' 中。 因此，AbstractEndpointimplementation （PollingConsumer或EventDrivenConsumer，具体取决于input-channeltype） bean 将此值作为其 bean 名称。 -
这
MessageHandlerChainbean 获取一个 bean 别名（'somethingChain.handler'），它允许从BeanFactory. -
这
<service-activator>不是一个成熟的消息收发终端节点（它不是PollingConsumer或EventDrivenConsumer). 它是一个MessageHandler在<chain>. 在这种情况下，使用BeanFactory是 'somethingChain$child.somethingService.handler'。 -
这
componentName的ServiceActivatingHandler采用相同的值，但没有 '.handler' 后缀。 它变为 'somethingChain$child.somethingService'。 -
最后
<chain>子组件 /<object-to-json-transformer>中没有id属性。 其componentName基于它在<chain>. 在本例中，它是 'somethingChain$child#1'。 （名称的最后一个元素是链中的顺序，以 '#0' 开头）。 请注意，此转换器未在应用程序上下文中注册为 bean，因此它不会获得beanName. 但是，其componentName具有一个可用于日志记录和其他目的的值。
提供显式的id属性<chain>元素来简化日志中子组件的标识，并提供从BeanFactory等。 |
从 Chain 中调用 Chain
有时，您需要从链中对另一个链进行嵌套调用，然后返回并继续在原始链中执行。 为此，您可以通过包含 <gateway> 元素来使用消息传送网关，如下例所示：
<int:chain id="main-chain" input-channel="in" output-channel="out">
<int:header-enricher>
<int:header name="name" value="Many" />
</int:header-enricher>
<int:service-activator>
<bean class="org.foo.SampleService" />
</int:service-activator>
<int:gateway request-channel="inputA"/>
</int:chain>
<int:chain id="nested-chain-a" input-channel="inputA">
<int:header-enricher>
<int:header name="name" value="Moe" />
</int:header-enricher>
<int:gateway request-channel="inputB"/>
<int:service-activator>
<bean class="org.foo.SampleService" />
</int:service-activator>
</int:chain>
<int:chain id="nested-chain-b" input-channel="inputB">
<int:header-enricher>
<int:header name="name" value="Jack" />
</int:header-enricher>
<int:service-activator>
<bean class="org.foo.SampleService" />
</int:service-activator>
</int:chain>在前面的示例中，nested-chain-a在 的末尾调用main-chain通过此处配置的 'gateway' 元素进行处理。
在nested-chain-a，则调用nested-chain-b是在标头扩充之后进行的。
然后，流返回以完成nested-chain-b.
最后，流返回到main-chain.
当<gateway>元素定义在链中，则不需要service-interface属性。
相反，它会获取当前状态的消息，并将其放置在request-channel属性。
当该网关启动的下游流完成时，一个Message返回到网关并继续在当前链中的旅程。