|
该版本仍在开发中，尚未被视为稳定。对于最新的稳定版本，请使用 Spring Integration 7.0.0！ |
分配器
分路器是一个组件，其职责是将消息划分为多个部分，并将生成的消息独立发送给处理。 他们往往是包含聚合商的管道中的上游生产者。
编程模型
用于执行拆分的 API 由一个基类组成，摘要消息分流器.
它是消息处理器实现了包含分流器常见特性的实现，例如填充相应的消息头部（CORRELATION_ID,SEQUENCE_SIZE和SEQUENCE_NUMBER）在所产生的消息上。
这种填充可以追踪消息及其处理结果（在典型场景中，这些头部会被复制到各个转换端点产生的消息中）。
这些值随后可以被组合消息处理器使用。
以下示例展示了以下摘录摘要消息分流器:
public abstract class AbstractMessageSplitter
extends AbstractReplyProducingMessageConsumer {
...
protected abstract Object splitMessage(Message<?> message);
}要在应用中实现特定的分配器，可以扩展摘要消息分流器并实现分裂消息方法，包含用于拆分消息的逻辑。
返回值可以是以下之一：
-
一个
收集或消息数组，或可迭代（或迭 代）对信息进行迭代。 在这种情况下，消息作为消息发送（在CORRELATION_ID,SEQUENCE_SIZE和SEQUENCE_NUMBER是有人居住的）。 采用这种方法可以让你有更多控制权——例如，在拆分过程中填充自定义消息头。 -
一个
收集或非消息对象数组，或可迭代（或迭 代）对非消息对象进行迭代。 它的工作原理与前述类似，只是每个集合元素都用作消息负载。 采用这种方法可以让你专注于域对象，而无需考虑消息系统，并且生成的代码更易于测试。 -
一个
消息或非消息对象（但不是集合或数组）。 它的运作方式与之前的情况类似，只是发送一条消息。
在 Spring Integration 中，任何 POJO 都可以实现拆分算法，只要它定义了一个接受单一参数且有返回值的方法。
在这种情况下，方法的返回值如前所述解释。
输入参数可能是消息或者简单的POJO。
在后一种情况下，分流器接收到来消息的有效载荷。
我们推荐这种方法，因为它将代码与 Spring 集成 API 解耦，通常更容易测试。
迭代器
从4.1版本开始，摘要消息分流器支持迭 代类型值分开。
注意，在迭 代（或可迭代），我们无法访问底层项目的数量，且SEQUENCE_SIZE首部设置为0.
这意味着默认情况下序列大小释放策略一<聚合器>这行不通，而这个小组的CORRELATION_ID来自分配器不会发布;它将保持为不完全的.
在这种情况下，你应该使用合适的自定义发布策略或者依赖发送部分结果于到期时䋰小组暂停或者MessageGroupStoreReaper.
从5.0版本开始，摘要消息分流器提供受保护的获得尺寸如果可能（）能够确定可迭代和迭 代如果可能的话，物体。
例如XPathMessageSplitter可以确定标的资产的大小节点列表对象。
从5.0.9版本开始，该方法也会正确返回com.fasterxml.jackson.core.TreeNode.
一迭 代Object 有助于避免在拆分前在内存中构建整个集合。
例如，当底层项目从某个外部系统（例如数据库或FTP）填充时MGET）通过迭代或流。
使用Java、Groovy和Kotlin DSL配置分配器
基于消息以及其可迭代的DSL配置有效载荷：
-
Java DSL
-
Kotlin DSL
-
Groovy DSL
@Bean
public IntegrationFlow someFlow() {
return f -> f.split(Message.class, Message::getPayload);
}@Bean
fun someFlow() =
integrationFlow {
split<Message<*>> { it.payload }
}@Bean
someFlow() {
integrationFlow {
splitWith {
expectedType Message<?>
function { it.payload }
}
}
}有关DSL的更多信息，请参阅相关章节：
用XML配置分路器
分线器可以通过XML配置如下：
<int:channel id="inputChannel"/>
<int:splitter id="splitter" (1)
ref="splitterBean" (2)
method="split" (3)
input-channel="inputChannel" (4)
output-channel="outputChannel" (5)
discard-channel="discardChannel" /> (6)
<int:channel id="outputChannel"/>
<beans:bean id="splitterBean" class="sample.PojoSplitter"/>| 1 | 分线器的ID是可选的。 |
| 2 | 在应用上下文中定义的豆子的引用。
豆子必须实现前文所述的拆分逻辑。
自选。
如果没有提供对豆子的引用，则假设到达消息的有效载荷是输入通道是 的实现java.util.Collection默认的拆分逻辑应用于集合，将每个单独元素整合进消息并发送给输出通道. |
| 3 | 实现拆分逻辑的方法（定义在豆子上）。 自选。 |
| 4 | 分线器的输入通道。 必填。 |
| 5 | 分路器将分拆消息结果发送到的信道。 可选（因为收到的消息可以自己指定回复通道）。 |
| 6 | 在分配为空时，请求消息发送到的信道。
可选（他们会停止，如同零结果）。 |
我们建议使用裁判如果自定义分路器实现可以被引用到其他<分线器>定义。
然而，如果自定义分流器处理器的实现应将作用域限定为<分线器>你可以配置一个内层豆定义，如下示例：
<int:splitter id="testSplitter" input-channel="inChannel" method="split"
output-channel="outChannel">
<beans:bean class="org.foo.TestSplitter"/>
</int:splitter>同时使用裁判属性和内部处理程序定义在同一个<智力：分裂器>不允许配置，因为这会造成歧义并导致异常抛出。 |
如果裁判属性指代扩展的豆子摘要消息制作处理程序（例如框架本身提供的分路器），通过直接将输出通道注入处理程序来优化配置。
在这种情况下，每一个裁判必须是一个独立的豆子实例（或原型-有瞄准镜的豆子）或使用内层<豆/>配置类型。
然而，这种优化仅适用于在分配器XML定义中未提供任何分流器特定的属性。
如果你无意中引用了多个 Beans 中的同一个消息处理程序，就会出现配置异常。 |