此版本仍在开发中,尚不被认为是稳定的。对于最新的稳定版本,请使用 Spring Integration 6.5.1! |
Spring 集成示例
从 Spring Integration 2.0 开始,Spring Integration 发行版不再包含示例。 相反,我们已经切换到一种更简单的协作模式,这种模式应该促进更好的社区参与,理想情况下,更多的贡献。 示例现在有一个专用的 GitHub 存储库。 示例开发也有自己的生命周期,它不依赖于框架版本的生命周期,尽管出于兼容性原因,存储库仍与每个主要版本一起标记。
对社区来说,最大的好处是我们现在可以添加更多示例并立即提供给您,而无需等待下一个版本。 拥有自己的 GitHub 仓库,不绑定到实际框架,也是一个很大的好处。 现在,您有一个专门的地方来建议 Samples以及报告现有 Samples的问题。 您也可以将示例作为拉取请求提交给我们。 如果我们认为您的样本增加了价值,我们非常乐意将其添加到“样本”存储库中,并正确地注明您是作者。
从哪里获得 Samples
Spring Integration Samples 项目托管在 GitHub 上。 若要签出或克隆示例,必须在系统上安装 Git 客户端。 有几种基于 GUI 的产品可用于许多平台(例如用于 Eclipse IDE 的 EGit)。 简单的 Google 搜索可以帮助您找到它们。 您还可以使用 Git 的命令行界面。
如果您需要有关如何安装或使用 Git 的详细信息,请访问:https://git-scm.com/。 |
要使用 Git 命令行工具克隆(签出)Spring Integration 示例存储库,请发出以下命令:
$ git clone https://github.com/spring-projects/spring-integration-samples.git
上述命令将整个示例存储库克隆到名为spring-integration-samples
在您发出该git
命令。
由于示例存储库是实时存储库,因此可能需要执行定期拉取(更新)以获取新示例和现有示例的更新。
为此,请发出以下命令git pull
命令:
$ git pull
提交 Samples或 Samples请求
您可以提交新 Samples和 Samples请求。 我们非常感谢为改进样本所做的任何努力,包括分享好的想法。
我怎样才能贡献自己的样本?
GitHub 用于社交编码:如果您想将自己的代码示例提交到 Spring Integration Samples 项目,我们鼓励通过来自该存储库的分支的拉取请求进行贡献。 如果您想以这种方式贡献代码,请尽可能参考 GutHub 问题,其中提供了有关您的示例的一些详细信息。
签署参与者许可协议
非常重要:在我们接受您的 Spring Integration 示例之前,我们需要您签署 SpringSource 贡献者许可协议 (CLA)。 签署贡献者协议并不授予任何人对主存储库的提交权限,但这确实意味着我们可以接受您的贡献,如果我们这样做,您将获得作者信用。 要阅读并签署 CLA,请转到: 从 Project 下拉列表中,选择 Spring Integration。 项目负责人是 Artem Bilan。 |
代码贡献流程
有关实际的代码贡献过程,请阅读 Spring Integration 的贡献者指南。 他们也申请了 Samples项目。 您可以在以下位置找到它们 github.com/spring-projects/spring-integration/blob/main/CONTRIBUTING.adoc
此过程可确保每个提交都经过同行评审。 事实上,核心提交者遵循完全相同的规则。 我们非常期待您的 Spring Integration 示例!
示例请求
如前所述,Spring Integration Samples 项目使用 GitHub 问题作为错误跟踪系统。要提交新的示例请求,请访问 github.com/spring-projects/spring-integration-samples/issues。
样本结构
从 Spring Integration 2.0 开始,示例的结构发生了变化。随着更多示例的计划,我们意识到并非所有示例都有相同的目标。它们都有一个共同的目标,即向您展示如何应用和使用 Spring Integration 框架。但是,它们的不同之处在于,一些示例专注于技术用例,而另一些示例则专注于业务用例。此外,一些示例是关于展示可用于解决某些场景(技术和业务)的各种技术。新的示例分类使我们能够根据每个示例解决的问题更好地组织它们,同时为您提供一种更简单的方法来找到满足您需求的正确示例。
目前,有四个类别。在示例存储库中,每个类别都有自己的目录,该目录以类别名称命名:
- 基本 (
samples/basic
) -
这是一个很好的入门。这里的示例是出于技术动机,并演示了配置和代码方面的最低限度。这些应该通过向您介绍 Spring Integration 以及企业集成模式 (EIP) 的基本概念、API 和配置来帮助您快速入门。例如,如果您正在寻找有关如何实现服务激活器并将其连接到消息通道、如何使用消息传递网关作为消息交换的外观或如何开始使用 MAIL、TCP/UDP 或其他模块的答案,那么这里是找到一个好示例的正确位置。底线是
samples/basic
是一个很好的起点。 - 中级 (
samples/intermediate
) -
此类别针对已经熟悉 Spring Integration 框架(除了入门之外)但在解决切换到消息传递架构后可能遇到的更高级技术问题时需要更多指导的开发人员。例如,如果您正在寻找有关如何处理各种消息交换场景中的错误的答案,或者如何正确配置聚合器以应对某些消息永远不会到达聚合的情况,或者超出特定组件的基本实现和配置并暴露“还有什么”类型的问题的任何其他问题,这是查找这些类型示例的正确位置。
- 高级 (
samples/advanced
) -
此类别面向非常熟悉 Spring Integration 框架但希望通过使用 Spring Integration 的公共 API 对其进行扩展以满足特定自定义需求的开发人员。例如,如果您正在寻找展示如何实现自定义通道或消费者(基于事件或基于轮询)的示例,或者您正在尝试找出在 Spring Integration bean 解析器层次结构之上实现自定义 bean 解析器的最合适方法(也许在为自定义组件实现您自己的命名空间和模式时),这是正确的位置。在这里,您还可以找到有助于您进行适配器开发的示例。Spring Integration 附带了一个广泛的适配器库,可让您将远程系统与 Spring Integration 消息传递框架连接起来。但是,您可能需要与核心框架不提供适配器的系统集成。如果是这样,您可能会决定实现自己的(请考虑贡献它)。此类别将包括向您展示如何作的示例。
- 应用 (
samples/applications
) -
此类别针对的是对消息驱动架构和 EIP 有很好的理解,并且对 Spring 和 Spring Integration 有高于平均水平的理解的开发人员和架构师,他们正在寻找解决特定业务问题的示例。 换句话说,此类别中示例的重点是业务用例以及如何使用消息驱动的架构,特别是 Spring Integration 来解决它们。 例如,如果您想了解如何使用 Spring Integration 实现和自动化贷款经纪人或旅行社流程,那么这是查找这些类型示例的正确位置。
Spring Integration 是一个社区驱动的框架。 因此,社区参与很重要。 这包括样本。 如果您找不到您要找的东西,请告诉我们! |
Samples
目前,Spring Integration 附带了相当多的示例,您只能期待更多。
为了帮助您更好地浏览它们,每个示例都附带自己的readme.txt
文件,其中涵盖了有关示例的几个详细信息(例如,它解决了哪些 EIP 模式、它试图解决什么问题、如何运行示例以及其他详细信息)。
但是,某些示例需要更详细的、有时是图形化的解释。
在本节中,您可以找到我们认为需要特别注意的
Samples的详细信息。
贷款经纪人
本节介绍 Spring Integration 示例中包含的贷款经纪人示例应用程序。 此示例的灵感来自于 Gregor Hohpe 和 Bobby Woolf 的书《企业集成模式》中的一个示例。
下图显示了整个过程:

EIP 架构的核心是非常简单但强大的管道、过滤器,当然还有消息的概念。 端点(过滤器)通过通道(管道)相互连接。 生成端点将消息发送到通道,而使用端点检索消息。 此体系结构旨在定义各种机制,这些机制描述了终结点之间如何交换信息,而不知道这些终结点是什么或它们正在交换什么信息。 因此,它提供了一个非常松散耦合和灵活的协作模型,同时也将集成问题与业务问题解耦。 EIP 通过进一步定义以下内容扩展了该架构:
-
管道类型(点对点通道、发布-订阅通道、通道适配器等)
-
围绕筛选器如何与管道协作的核心筛选器和模式(消息路由器、拆分器和聚合器、各种消息转换模式等)
EIP 书的第 9 章很好地描述了这个用例的细节和变化,但这里是简要的总结:在购买最佳贷款报价时,消费者订阅了贷款经纪人的服务,该经纪人处理以下细节:
-
消费者预筛选(例如,获取和审查消费者的信用记录)
-
确定最合适的银行(例如,根据消费者的信用记录或评分)
-
向每个选定的银行发送贷款报价请求
-
收集各银行的回复
-
根据消费者的要求过滤回复并确定最佳报价。
-
将贷款报价转回给消费者。
获得贷款报价的真正过程通常要复杂一些。 但是,由于我们的目标是演示如何在 Spring Integration 中实现和实现企业集成模式,因此用例已被简化为仅专注于流程的集成方面。 这并不是试图为您提供有关消费财务的建议。
通过聘请贷款经纪人,消费者与贷款经纪人的运营细节隔离开来,每个贷款经纪人的运营可能会相互推迟以保持竞争优势,因此无论我们组装和实施什么,都必须是灵活的,以便可以快速、轻松地引入任何变化。
贷款经纪人样本实际上并没有与任何“想象的”银行或征信机构交谈。 这些服务被淘汰了。 |
我们的目标是组装、编排和测试整个流程的集成方面。 只有这样,我们才能开始考虑将此类流程连接到实际服务。 届时,无论与特定贷款经纪人进行交易的银行数量或用于与这些银行通信的通信介质(或协议)类型(JMS、WS、TCP 等)如何,组装的流程及其配置都不会改变。
设计
当您分析前面列出的六个要求时,您可以看到它们都是集成问题。 例如,在消费者预筛选步骤中,我们需要收集有关消费者和消费者愿望的额外信息,并使用额外的元信息丰富贷款请求。 然后,我们必须过滤此类信息以选择最合适的银行列表等。 丰富、过滤和选择都是 EIP 以模式形式定义解决方案的集成问题。 Spring Integration 提供了这些模式的实现。
下图显示了消息传递网关的表示形式:

消息传递网关模式提供了一种简单的机制来访问消息传递系统,包括我们的贷款经纪人。
在 Spring Integration 中,您可以将网关定义为普通的旧 Java 接口(您不需要提供实现),使用 XML 对其进行配置<gateway>
元素或带有 Java 中的注释,并像使用任何其他 Spring Bean 一样使用它。
Spring Integration通过生成消息(有效负载映射到方法的输入参数)并将其发送到指定通道来负责将方法调用委托和映射到消息传递基础设施。
以下示例演示如何使用 XML 定义此类网关:
<int:gateway id="loanBrokerGateway"
default-request-channel="loanBrokerPreProcessingChannel"
service-interface="org.springframework.integration.samples.loanbroker.LoanBrokerGateway">
<int:method name="getBestLoanQuote">
<int:header name="RESPONSE_TYPE" value="BEST"/>
</int:method>
</int:gateway>
我们当前的网关提供了两种可以调用的方法。
一个返回最佳单引号,另一个返回所有引号。
不知何故,在下游,我们需要知道呼叫者需要什么类型的回复。
在消息传递体系结构中实现这一点的最佳方法是使用一些描述您的意图的元数据来丰富消息的内容。
Content Enricher 是解决此问题的模式之一。
为了方便起见,Spring Integration 确实提供了一个单独的配置元素,以使用任意数据(稍后描述)丰富消息头
但是,由于gateway
元素负责构造初始消息,它包括使用任意消息头丰富新创建消息的能力。
在我们的示例中,我们添加一个RESPONSE_TYPE
标头,值为BEST
每当getBestQuote()
方法被调用。
对于其他方法,我们不添加任何标头。
现在我们可以检查下游是否存在此标头。
根据它的存在和价值,我们可以确定呼叫者想要什么类型的回复。
根据用例,我们还知道需要执行一些预筛选步骤,例如获取和评估消费者的信用评分,因为一些顶级银行只接受满足最低信用评分要求的消费者的报价请求。 因此,如果消息在转发给银行之前能够丰富此类信息,那就太好了。 如果当需要完成多个流程来提供此类元信息时,这些流程可以分组到一个单元中,那就太好了。 在我们的用例中,我们需要确定信用评分,并根据信用评分和一些规则,选择要向其发送报价请求的消息渠道(银行渠道)列表。
组合式消息处理器
组合消息处理器模式描述了有关构建终结点的规则,这些终结点保持对消息流的控制,该终结点由多个消息处理器组成。
在 Spring Integration 中,组合的消息处理器模式由<chain>
元素。
下图显示了链模式:

上图显示,我们有一个带有内部标头丰富器元素的链,该元素使用CREDIT_SCORE
标头和值(由对信用服务的调用确定——一个由 'creditBureau' 名称标识的简单 POJO Spring Bean)。
然后它委托给消息路由器。
下图显示了消息路由器模式:

Spring Integration提供了消息路由模式的多种实现。
在这种情况下,我们使用一个路由器,该路由器根据评估一个表达式(在 Spring Expression Language 中)来确定通道列表,该表达式查看信用评分(在上一步中确定)并从Map
带有id
之banks
其值为premier
或secondary
,基于信用评分的值。
选择通道列表后,消息将路由到这些通道。
现在,贷款经纪人需要从银行接收贷款报价的最后一件事,按消费者汇总它们(我们不想显示从一个消费者到另一个消费者的报价),根据消费者的选择标准(单个最佳报价或所有报价)组装响应,并将回复发送给消费者。
下图显示了消息聚合器模式:

聚合器模式描述将相关消息分组到单个消息中的终结点。 可以提供标准和规则来确定聚合和关联策略。 Spring Integration提供了聚合器模式的多种实现以及方便的基于命名空间的配置。
以下示例演示如何定义聚合器:
<int:aggregator id="quotesAggregator"
input-channel="quotesAggregationChannel"
method="aggregateQuotes">
<beans:bean class="org.springframework.integration.samples.loanbroker.LoanQuoteAggregator"/>
</int:aggregator>
我们的贷款经纪人定义了一个 'quotesAggregator' bean,其中包含<aggregator>
元素,它提供了默认的聚合和关联策略。
默认关联策略根据correlationId
标头(参见 EIP 书中的相关标识符模式)。
请注意,我们从未提供此标头的值。
它是路由器在为每个银行通道生成单独消息时自动设置的。
一旦消息关联起来,它们就会被释放到实际的聚合器实现中。
尽管 Spring Integration 提供了一个默认的聚合器,但它的策略(从所有消息中收集有效负载列表并构造一个新消息,并将此列表作为其有效负载)不能满足我们的要求。
在消息中包含所有结果是一个问题,因为我们的消费者可能需要一个最佳报价或所有报价。
为了传达消费者的意图,在流程的早期,我们将RESPONSE_TYPE
页眉。
现在我们必须评估这个标头并返回所有报价(默认聚合策略有效)或最佳报价(默认聚合策略不起作用,因为我们必须确定哪个贷款报价是最好的)。
在更现实的应用程序中,选择最佳报价可能基于可能影响聚合器实现和配置复杂性的复杂标准。
不过,现在,我们正在让它变得简单。
如果消费者想要最好的报价,我们选择利率最低的报价。
为了实现这一目标,LoanQuoteAggregator
class 按利率对所有报价进行排序并返回第一个报价。
这LoanQuote
类实现Comparable
以根据 rate 属性比较报价。
创建响应消息后,它将发送到启动该过程的消息传递网关的默认回复通道(从而发送到使用者)。
我们的消费者得到了贷款报价!
总之,基于 POJO(即现有或遗留)逻辑和轻量级、可嵌入的消息传递框架(Spring Integration)组装了一个相当复杂的过程,该框架具有松散耦合的编程模型,旨在简化异构系统的集成,而无需重量级的类似 ESB 的引擎或专有的开发和部署环境。 作为开发人员,您不应该仅仅因为有集成问题而将 Swing 或基于控制台的应用程序移植到类似 ESB 的服务器或实现专有接口。
此示例和本节中的其他示例构建在企业集成模式之上。 您可以将它们视为解决方案的“构建块”。 它们并不是一个完整的解决方案。 集成问题存在于所有类型的应用程序(无论是否基于服务器)中。 我们的目标是使集成应用程序不需要更改设计、测试和部署策略。
咖啡馆示例
本节介绍 Spring Integration 示例中包含的 café 示例应用程序。 该样本的灵感来自格雷戈尔·霍普 (Gregor Hohpe) 的《漫步》中的另一个样本。
该域是咖啡馆的域,下图描述了基本流程:

这Order
对象可能包含多个OrderItems
.
下订单后,拆分器会将复合订单消息分解为每种饮料的一条消息。
然后,其中每一个都由路由器处理,路由器确定饮料是热的还是冷的(通过检查OrderItem
对象的 'isIced' 属性)。
这Barista
准备每种饮料,但热饮和冷饮的准备通过两种不同的方法处理:“prepareHotDrink”和“prepareColdDrink”。
然后准备好的饮料被送到Waiter
其中它们被聚合到Delivery
对象。
以下列表显示了 XML 配置:
<?xml version="1.0" encoding="UTF-8"?>
<beans:beans xmlns:int="http://www.springframework.org/schema/integration"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:beans="http://www.springframework.org/schema/beans"
xmlns:int-stream="http://www.springframework.org/schema/integration/stream"
xsi:schemaLocation="http://www.springframework.org/schema/beans
https://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/integration
https://www.springframework.org/schema/integration/spring-integration.xsd
http://www.springframework.org/schema/integration/stream
https://www.springframework.org/schema/integration/stream/spring-integration-stream.xsd">
<int:gateway id="cafe" service-interface="o.s.i.samples.cafe.Cafe"/>
<int:channel id="orders"/>
<int:splitter input-channel="orders" ref="orderSplitter"
method="split" output-channel="drinks"/>
<int:channel id="drinks"/>
<int:router input-channel="drinks"
ref="drinkRouter" method="resolveOrderItemChannel"/>
<int:channel id="coldDrinks"><int:queue capacity="10"/></int:channel>
<int:service-activator input-channel="coldDrinks" ref="barista"
method="prepareColdDrink" output-channel="preparedDrinks"/>
<int:channel id="hotDrinks"><int:queue capacity="10"/></int:channel>
<int:service-activator input-channel="hotDrinks" ref="barista"
method="prepareHotDrink" output-channel="preparedDrinks"/>
<int:channel id="preparedDrinks"/>
<int:aggregator input-channel="preparedDrinks" ref="waiter"
method="prepareDelivery" output-channel="deliveries"/>
<int-stream:stdout-channel-adapter id="deliveries"/>
<beans:bean id="orderSplitter"
class="org.springframework.integration.samples.cafe.xml.OrderSplitter"/>
<beans:bean id="drinkRouter"
class="org.springframework.integration.samples.cafe.xml.DrinkRouter"/>
<beans:bean id="barista" class="o.s.i.samples.cafe.xml.Barista"/>
<beans:bean id="waiter" class="o.s.i.samples.cafe.xml.Waiter"/>
<int:poller id="poller" default="true" fixed-rate="1000"/>
</beans:beans>
每个消息终结点都连接到输入通道和/或输出通道。
每个端点都管理自己的生命周期(默认情况下,端点在初始化时自动启动,要防止这种情况,请添加auto-startup
属性,值为false
).
最重要的是,请注意,这些对象是具有强类型方法参数的简单 POJO。
以下示例显示了拆分器:
public class OrderSplitter {
public List<OrderItem> split(Order order) {
return order.getItems();
}
}
对于路由器,返回值不必是MessageChannel
实例(尽管,它可以)。
在此示例中,String
相反,返回保存通道名称的值,如以下列表所示。
public class DrinkRouter {
public String resolveOrderItemChannel(OrderItem orderItem) {
return (orderItem.isIced()) ? "coldDrinks" : "hotDrinks";
}
}
现在,回到 XML,您可以看到有两个<service-activator>
元素。
其中每一个都委托给相同的Barista
实例,但使用不同的方法 (prepareHotDrink
或prepareColdDrink
),每个通道对应于已路由订单项目的两个通道之一。
以下列表显示了 Barista 类(其中包含prepareHotDrink
和prepareColdDrink
方法)
public class Barista {
private long hotDrinkDelay = 5000;
private long coldDrinkDelay = 1000;
private AtomicInteger hotDrinkCounter = new AtomicInteger();
private AtomicInteger coldDrinkCounter = new AtomicInteger();
public void setHotDrinkDelay(long hotDrinkDelay) {
this.hotDrinkDelay = hotDrinkDelay;
}
public void setColdDrinkDelay(long coldDrinkDelay) {
this.coldDrinkDelay = coldDrinkDelay;
}
public Drink prepareHotDrink(OrderItem orderItem) {
try {
Thread.sleep(this.hotDrinkDelay);
System.out.println(Thread.currentThread().getName()
+ " prepared hot drink #" + hotDrinkCounter.incrementAndGet()
+ " for order #" + orderItem.getOrder().getNumber()
+ ": " + orderItem);
return new Drink(orderItem.getOrder().getNumber(), orderItem.getDrinkType(),
orderItem.isIced(), orderItem.getShots());
}
catch (InterruptedException e) {
Thread.currentThread().interrupt();
return null;
}
}
public Drink prepareColdDrink(OrderItem orderItem) {
try {
Thread.sleep(this.coldDrinkDelay);
System.out.println(Thread.currentThread().getName()
+ " prepared cold drink #" + coldDrinkCounter.incrementAndGet()
+ " for order #" + orderItem.getOrder().getNumber() + ": "
+ orderItem);
return new Drink(orderItem.getOrder().getNumber(), orderItem.getDrinkType(),
orderItem.isIced(), orderItem.getShots());
}
catch (InterruptedException e) {
Thread.currentThread().interrupt();
return null;
}
}
}
从前面的代码摘录中可以看出,该Barista
方法有不同的延迟(热饮的准备时间是原来的五倍)。
这模拟了以不同速率完成的工作。
当CafeDemo
'main' 方法运行,它循环 100 次,每次发送单杯热饮和单杯冷饮。
它实际上通过调用Cafe
接口。
在前面的 XML 配置中,你可以看到<gateway>
元素。
这将触发创建代理,该代理实现给定的服务接口并将其连接到通道。
通道名称在@Gateway
的注释Cafe
接口,如以下接口定义所示:
public interface Cafe {
@Gateway(requestChannel="orders")
void placeOrder(Order order);
}
最后,看看main()
方法CafeDemo
本身:
public static void main(String[] args) {
AbstractApplicationContext context = null;
if (args.length > 0) {
context = new FileSystemXmlApplicationContext(args);
}
else {
context = new ClassPathXmlApplicationContext("cafeDemo.xml", CafeDemo.class);
}
Cafe cafe = context.getBean("cafe", Cafe.class);
for (int i = 1; i <= 100; i++) {
Order order = new Order(i);
order.addItem(DrinkType.LATTE, 2, false);
order.addItem(DrinkType.MOCHA, 3, true);
cafe.placeOrder(order);
}
}
要运行此示例以及其他八个示例,请参阅README.txt 在samples 主发行版的目录(如本章开头所述)。 |
当你运行时cafeDemo
,可以看到冷饮的初熟速度比热饮快。
因为有一个聚合器,冷饮受到热饮制备速度的有效限制。
这是可以预料的,基于它们各自的 1000 和 5000 毫秒延迟。
但是,通过使用并发任务执行器配置轮询器,您可以显着更改结果。
例如,您可以为热饮咖啡师使用具有五个工作程序的线程池执行器,同时保持冷饮咖啡师的原样。
以下列表配置了这种安排:
<int:service-activator input-channel="hotDrinks"
ref="barista"
method="prepareHotDrink"
output-channel="preparedDrinks"/>
<int:service-activator input-channel="hotDrinks"
ref="barista"
method="prepareHotDrink"
output-channel="preparedDrinks">
<int:poller task-executor="pool" fixed-rate="1000"/>
</int:service-activator>
<task:executor id="pool" pool-size="5"/>
此外,请注意,每次调用都会显示工作线程名称。 可以看到热饮是由任务执行器线程准备的。 如果提供更短的轮询器间隔(例如 100 毫秒),则可以看到它偶尔会通过强制任务计划程序(调用方)调用作来限制输入。
除了试验轮询器的并发设置外,您还可以添加“事务性”子元素,然后引用任何PlatformTransactionManager 实例。 |
XML 消息传递示例
中的 XML 消息传递示例basic/xml
显示了如何使用处理 XML 有效负载的一些提供的组件。
该示例使用处理以 XML 表示的书籍订单的思想。
此示例显示命名空间前缀可以是您想要的任何内容。
虽然我们通常使用int-xml 对于集成 XML 组件,示例使用si-xml .
(int 是“集成”的缩写,并且si 是“Spring Integration”的缩写。 |
首先,订单被拆分为多个消息,每个消息代表来自 XPath 拆分器组件的单个订单项。 以下列表显示了拆分器的配置:
<si-xml:xpath-splitter id="orderItemSplitter" input-channel="ordersChannel"
output-channel="stockCheckerChannel" create-documents="true">
<si-xml:xpath-expression expression="/orderNs:order/orderNs:orderItem"
namespace-map="orderNamespaceMap" />
</si-xml:xpath-splitter>
然后,服务激活器将消息传递到库存检查器 POJO 中。
订单项目单据使用库存检查器中有关订单项目库存水平的信息进行扩充。
然后,此扩充的订单项消息用于路由消息。
如果订单物料有库存,则消息将传递到仓库。
以下列表配置了xpath-router
路由消息:
<si-xml:xpath-router id="inStockRouter" input-channel="orderRoutingChannel" resolution-required="true">
<si-xml:xpath-expression expression="/orderNs:orderItem/@in-stock" namespace-map="orderNamespaceMap" />
<si-xml:mapping value="true" channel="warehouseDispatchChannel"/>
<si-xml:mapping value="false" channel="outOfStockChannel"/>
</si-xml:xpath-router>
当订单项没有库存时,消息将使用 XSLT 转换为适合发送给提供商的格式。 以下列表配置了 XSLT 转换器:
<si-xml:xslt-transformer input-channel="outOfStockChannel"
output-channel="resupplyOrderChannel"
xsl-resource="classpath:org/springframework/integration/samples/xml/bigBooksSupplierTransformer.xsl"/>