|
该版本仍在开发中,尚未被视为稳定。对于最新的稳定版本,请使用 Spring Integration 7.0.0! |
理赔核查
在前面的部分中,我们介绍了几个内容丰富要素,可以帮助你应对消息中缺少某一部分数据的情况。 我们还讨论了内容过滤,可以让你从消息中删除数据项。 然而,有时我们希望暂时隐藏数据。 例如,在分布式系统中,我们可能会收到一个负载非常大的消息。 某些间歇性消息处理步骤可能不需要访问该有效载荷,有些则只需访问特定头部,因此携带大消息载荷通过每个处理步骤可能导致性能下降,可能带来安全风险,并使调试更困难。
存储在库中(或称声明检查)模式描述了一种机制,允许你将数据存储在已知位置,同时只保留指向数据所在位置的指针(声明检查)。 你可以把这个指针作为新消息的有效载荷传递,这样消息流中的任何组件都能在需要时尽快获取实际数据。 这种方式与挂号信流程非常相似,你会收到一张理赔支票,然后再去邮局领取你的包裹。 这也和航班后或酒店行李提取的概念相同。
Spring Integration提供两种类型的理赔检查转换器:
-
来电理赔检查转换器
-
出厂理赔检查转换器
有方便的基于命名空间的机制用于配置它们。
来电理赔检查转换器
入站的理对检查转换器通过将消息存储在由其标识的消息存储中来转换信息消息存储属性。
以下示例定义了进入索赔检查转换器:
<int:claim-check-in id="checkin"
input-channel="checkinChannel"
message-store="testMessageStore"
output-channel="output"/>
在上述配置中,接收到的消息输入通道被持久化到标识为消息存储属性,并用生成的ID进行索引。
那个ID就是该消息的理赔支票。
声明检查也成为发送给输出通道.
现在,假设你在某个时刻确实需要访问实际的信息。 你可以手动访问消息存储器获取消息内容,或者用同样的方法(创建一个变换器),只是现在你用一个发出的声明检查变换器将申报检查转换成实际消息。
以下列表概述了所有可用参数的进件理赔检查转换器:
<int:claim-check-in auto-startup="true" (1)
id="" (2)
input-channel="" (3)
message-store="messageStore" (4)
order="" (5)
output-channel="" (6)
send-timeout=""> (7)
<int:poller></int:poller> (8)
</int:claim-check-in>
| 1 | 生命周期属性,指示该组件是否应在应用上下文启动时启动。
它默认为true.
该属性在链元素。
自选。 |
| 2 | 识别识别,识别底层豆子定义(消息变换处理程序).
该属性在链元素。
自选。 |
| 3 | 该端点的接收消息信道。
该属性在链元素。
自选。 |
| 4 | 对消息商店用于该理赔检查转换器。
如果未指定,默认引用的豆子是名为messageStore.
自选。 |
| 5 | 指定当该端点作为信道的订阅者连接时的调用顺序。
当该通道使用备援切换派遣策略。
当该端点本身是带队列的信道的轮询消费者时,这无效。
该属性在链元素。
自选。 |
| 6 | 识别消息通道,在该端点处理后,消息被发送。
该属性在链元素。
自选。 |
| 7 | 指定向输出信道发送回复消息时等待的最大时间(以毫秒为单位)。
默认30秒。
该属性在链元素。
自选。 |
| 8 | 定义了轮询器。
该元素在链元素。
自选。 |
出厂理赔检查转换器
一个发出的理权检查变换器可以让你将带有理权检查有效载荷的消息转换为以原始内容为有效载荷的消息。
<int:claim-check-out id="checkout"
input-channel="checkoutChannel"
message-store="testMessageStore"
output-channel="output"/>
在之前的配置中,收到的消息在输入通道应该有个索赔支票作为有效载荷。
发出的权利验证变换器通过查询消息存储器识别的消息,将该消息转换为带有原始有效载荷的消息。
然后它会将新借出的消息发送给输出通道.
以下列表概述了所有可用的出厂理赔核对转换器参数:
<int:claim-check-out auto-startup="true" (1)
id="" (2)
input-channel="" (3)
message-store="messageStore" (4)
order="" (5)
output-channel="" (6)
remove-message="false" (7)
send-timeout=""> (8)
<int:poller></int:poller> (9)
</int:claim-check-out>
| 1 | 生命周期属性,指示该组件是否应在应用上下文启动时启动。
它默认为true.
该属性在链元素。
自选。 |
| 2 | 识别识别,识别底层豆子定义(消息变换处理程序).
该属性在链元素。
自选。 |
| 3 | 该端点的接收消息信道。
该属性在链元素。
自选。 |
| 4 | 对消息商店用于该理赔检查转换器。
如果未指定,默认引用的豆子是名为messageStore.
自选。 |
| 5 | 指定当该端点作为信道的订阅者连接时的调用顺序。
当该通道使用一个备援切换派遣策略。
当该端点本身是带队列的信道的轮询消费者时,这无效。
该属性在链元素。
自选。 |
| 6 | 识别消息通道,在该端点处理后,消息被发送。
该属性在链元素。
自选。 |
| 7 | 如果设置为true,消息从消息商店靠这个转换器。
当消息只能被“认领”一次时,这个设置非常有用。
它默认为false.
自选。 |
| 8 | 指定向输出信道发送回复消息时等待的最大时间(以毫秒为单位)。
它默认为30秒。
该属性在链元素。
自选。 |
| 9 | 定义了轮询器。
该元素在链元素。
自选。 |
宣称一次
有时,某条消息只能申领一次。
打个比方,考虑飞机行李的处理过程。
你是在出发时托运行李,抵达时申领。
行李一旦被领取,必须先托运,否则不得再次领取。
为适应此类情况,我们引入了删除消息布尔属性领取结算转换器。
该属性被设置为false默认。
然而,如果设置为true,声称的消息从中移除消息商店这样就不能再被认领。
这一特性在存储空间方面有影响,尤其是在内存中地图-基于简易消息商店,其中未能移除消息最终可能导致内存异常.
因此,如果您不预期会有多项索赔,我们建议您设置删除消息属性的值为true.
以下示例展示了如何使用删除消息属性:
<int:claim-check-out id="checkout"
input-channel="checkoutChannel"
message-store="testMessageStore"
output-channel="output"
remove-message="true"/>
关于消息存储的一句话
虽然我们很少关心理赔检查的细节(只要它们能正常工作),但你应该知道,Spring Integration中实际理权验证(指针)的实现使用UUID以确保唯一性。
org.springframework.integration.store.MessageStore是一个用于存储和检索消息的策略接口。
Spring Integration 提供了两种便捷的实现方式:
-
简易消息商店:记忆中的,地图基于 的实现(默认,适合测试) -
Jdbc消息存储:一种基于JDBC的关系数据库实现