使用保护方案

每当必须关联多个单个消息才能获得所需结果时，就存在 一个车队 。 有两种main类型的车队：顺序和并行。

在某些情况下，业务流程实例可能会同时收到一组相关消息。 这时就会产生争用条件，必须从该组中选出一条消息，令其在该业务流程实例中初始化一个相关集，然后其他消息再关联到该业务流程实例。

为了确保所有相关消息都由同一个业务流程实例接收，BizTalk Server 会检测出现争用条件的可能性，并将这些消息视为一个保护。 登记时，运行时会创建一个常规订阅，并将其标识为保护的组成部分。 填写完此订阅后，消息引擎会根据预定义相关属性的值，创建一个临时订阅。 此临时订阅称为 车队集。 一个保护集就是一组在保护中使用的相关集。 系统会依据保护集，对所有匹配常规订阅的后续消息进行评价，匹配的消息被路由到一个现有端口。

在业务流程中使用保护

在业务流程中使用保护处理时，请注意以下事项：

• 关联集是一个属性列表，其中包含用于将消息路由到特定业务流程的特定值。 用于接收形状的相关性集不能包含三个以上的用于关联的属性。 这是因为这些值在数据库级别上进行标识和存储，而这种方式最多只支持三个参数。

• 并行保护和顺序保护可并存于同一个业务流程中，但相互之间不能共享任何相关集。 这是因为每个相关集只能属于一个保护。

• 使用“启动业务流程”形状将已初始化的关联集传递到新业务流程时，BizTalk Server不支持车队处理。 这是因为保护集是在数据库级别处理的，独立于已在运行的业务流程实例。

• 不能使用单个 接收 形状来初始化将在单独的车队中使用的两个或多个相关集。 例如，假设接收 r1 为第一个保护初始化相关集 c1 和 c2，接收 r2 为第二个保护初始化 c1，接收 r3 为第三个保护初始化 c2。 设想中，第二个保护的保护集为 (c1, r2)，第三个保护的保护集为 (c2, r3)，它们都由 r1 初始化。 在这种情况下，业务流程引擎不会将它们视为保护。 在这个例子中，如果 r2 和 r3 均初始化 c1 (c1, r2, r3) 和 c2 (c2, r2, r3)，均仅初始化 c1 (c1, r2, r3) 或均仅初始化 c2 (c2, r2, r3)，则该保护方案将是有效的。

僵停

使用保护可能会引发称为僵停的“丢失”消息。 如果正在运行的业务流程中的非激活接收订阅与 MessageBox 数据库中的消息相匹配，则 MessageBox 会将该消息传递给业务流程。 由于 MessageBox 不了解业务流程内的业务逻辑，所以它只是简单地将所有匹配订阅的消息都传递给业务流程。 如果在该业务流程的执行流已经传递了可处理消息的接收订阅后，又传送了匹配消息，则这些消息将会僵停。

产生僵停的一个例子是：在一个循环中，一个接收循环 17 次，却有 18 个与该循环中的接收订阅匹配的消息被传出。 (MessageBox 不知道业务流程逻辑仅处理 17 条消息。) 业务流程不使用传递的第 18 条消息，因为执行流已退出循环。 该业务流程完成时，有丢弃的消息（僵停），这是不可恢复的，因为该业务流程实例已经完成了。

使用 Windows 管理规范 (WMI) 脚本来查询处于“已挂起-不可恢复”状态的实例，可以对僵停进行管理。 此外，消息引擎还会向事件日志写入一条错误消息：“已完成，有消息被放弃”。

而且，如果顺序保护具有长期事务作用域，且该作用域有超时设置，则某些业务流程实例也将以“已挂起-不可恢复”状态结束。 您也许已经注意到了输出消息数与“已挂起-不可恢复”实例数之和小于输入消息数。 此行为是设计使然。 发生超时异常时，代码将会转向异常处理程序。 BizTalk Server 调用异常处理程序来处理该异常，其中包括处理僵停。 您可以使用异常处理程序中的发送端口，将僵停发送到一个目标，以进一步查看和处理。

除保护外，其他方案也会产生僵停。 例如，假设一个业务流程实例在等待来自业务处理流程的响应消息，由于某种原因，它接收到了两个匹配订阅的响应消息。 在这种情况下，第二个响应消息成为僵停消息。 另一个示例是，在一个分支上具有“接收”形状，另一个分支处有“延迟”形状的“侦听”形状。 如果消息到达的同时发生超时，则该消息成为僵停消息。

有关如何管理僵尸的详细信息，请参阅 UI 指南和开发人员 API 命名空间参考中的删除挂起的服务实例。

后续步骤

顺序保护

并行保护

另请参阅

在业务流程中使用关联