使用 XPath 路由 XML 消息
与基于 SpEL 的路由器类似,Spring Integration 提供了对基于 XPath 表达式路由消息的支持,这使您可以创建一个具有输入通道但没有输出通道的消息端点。相反,一个或多个输出通道是动态确定的。以下示例展示了如何创建这样的路由器
<int-xml:xpath-router id="orderTypeRouter" input-channel="orderChannel">
<int-xml:xpath-expression expression="/order/type"/>
</int-xml:xpath-router>
有关路由器之间共有的属性概述,请参阅 通用路由器参数。 |
在内部,XPath 表达式被评估为类型 NODESET
并转换为表示通道名称的 List<String>
。通常,这样的列表包含一个通道名称。但是,根据 XPath 表达式的结果,如果 XPath 表达式返回多个值,XPath 路由器也可以具有接收者列表路由器的特征。在这种情况下,List<String>
包含多个通道名称。因此,消息将发送到列表中的所有通道。
因此,假设传递到以下路由器配置的 XML 文件包含许多表示通道名称的 responder
子元素,则消息将发送到所有这些通道
<!-- route the order to all responders-->
<int-xml:xpath-router id="responderRouter" input-channel="orderChannel">
<int-xml:xpath-expression expression="/request/responders"/>
</int-xml:xpath-router>
如果返回的值不直接代表通道名称,您可以指定额外的映射参数将这些返回值映射到实际的通道名称。例如,如果/request/responders
表达式导致两个值(responderA
和responderB
),但您不想将响应器名称与通道名称耦合,您可以提供额外的映射配置,例如以下内容
<!-- route the order to all responders-->
<int-xml:xpath-router id="responderRouter" input-channel="orderChannel">
<int-xml:xpath-expression expression="/request/responders"/>
<int-xml:mapping value="responderA" channel="channelA"/>
<int-xml:mapping value="responderB" channel="channelB"/>
</int-xml:xpath-router>
如前所述,XPath 表达式的默认评估类型为NODESET
,它被转换为List<String>
的通道名称列表,这既可以处理单通道场景,也可以处理多通道场景。
尽管如此,某些 XPath 表达式可能从一开始就作为String
类型进行评估。例如,考虑以下 XPath 表达式
name(./node())
此表达式返回根节点的名称。如果使用默认评估类型NODESET
,则会导致异常。
对于这些场景,您可以使用evaluate-as-string
属性,它允许您管理评估类型。默认情况下,它是FALSE
。但是,如果将其设置为TRUE
,则使用String
评估类型。
XPath 1.0 指定了 4 种数据类型
当 XPath 路由器使用可选的 有关更多信息,请参见 |
例如,如果我们想根据根节点的名称进行路由,我们可以使用以下配置
<int-xml:xpath-router id="xpathRouterAsString"
input-channel="xpathStringChannel"
evaluate-as-string="true">
<int-xml:xpath-expression expression="name(./node())"/>
</int-xml:xpath-router>
XML 负载转换器
对于 XPath 路由器,您还可以指定在 XPath 评估之前转换负载时要使用的转换器。因此,XPath 路由器支持XmlPayloadConverter
策略的自定义实现,并且在 XML 中配置xpath-router
元素时,可以通过converter
属性提供对这种实现的引用。
如果未明确提供此引用,则使用DefaultXmlPayloadConverter
。在大多数情况下,它应该足够了,因为它可以从 Node、Document、Source、File 和 String 类型的负载进行转换。如果您需要扩展默认实现的功能,那么在大多数情况下,使用上游转换器通常是一个更好的选择,而不是在此处提供对该策略的自定义实现的引用。