关联是指在多个单条消息需要组合起来以实现所需结果的时候出现的情况。 车队有两种主要类型：顺序和并行。
在某些情况下，协调实例可能会在同一时间收到一组相关消息。 在这种情况下，可能会发生竞争条件，其中一个消息必须在编排实例中初始化关联集，然后才能将其他消息与该编排实例相关联。
为了确保所有相关消息都由同一业务流程实例接收，BizTalk Server 会检测此类争用条件的可能性，并将这些消息视为车队。 在登记时，运行时将创建一个常规订阅，并将其标识为车队的一部分。 填写此订阅后，消息传送引擎会基于预定义相关属性中的值创建临时订阅。 此临时订阅称为 车队集。 车队集是车队中使用的一组相关集。 所有与一般订阅匹配的后续消息都将根据车队集进行评估，匹配的消息将被路由到现有的端口。
将 Convoys 与业务流程配合使用
将车队处理与业务流程配合使用时，请考虑以下事项：
关联集是一个属性列表，其中包含用于将消息路由到特定业务流程的特定值。 Receive形状上使用的相关集不能包含超过三个用于相关性的属性。 这是因为这些值在数据库级别进行标识和存储，支持最多三个参数。
并行和顺序车队可以共存在同一业务流程中，但它们不能彼此共享任何关联集。 这是因为每个关联集只能属于一个车队。
使用 “启动业务流程”形状将已初始化的关联集传递到新业务流程时，BizTalk Server 不支持汇聚处理。 这是因为车队集合在数据库级别进行处理，与已在运行的编排实例无关。
不能使用单个 接收 形状初始化将在单独的车队中使用的两个或多个关联集。 例如，假设接收方 r1 初始化第一个车队的相关性集 c1 和 c2，接收方 r2 遵循 c1 对应第二个车队，接收方 r3 遵循 c2 对应第三个车队。 第二个车队的预期护航集为 c1、r2 和第三个车队的预期护航集为 c2、r3，全部由 r1 初始化。 在这种情况下，编排引擎不会将这些视为批次处理。 如果 r2 和 r3 都遵循 c1 和 c2（c1、r2、r3 和 c2、r2、r3），则示例是有效的车队方案，两者都只关注 c1（c1、r2、r3），或者两者都只关注 c2（c2、r2、r3）。
僵尸
使用车队可能会导致称为僵尸的“丢失”消息。 当正在运行的业务流程中的非激活接收订阅与 MessageBox 数据库中的消息匹配时，MessageBox 会将消息传递到业务流程。 由于 MessageBox 不知道业务流程中的业务逻辑，因此它只传送到业务流程中与订阅匹配的所有消息。 如果在业务流程执行流已经经过了可以处理这些消息的接收订阅之后才传递这些消息中的任何一个，则此类消息将成为僵尸。
一种造成僵尸现象的情况是，在一个循环中迭代接收17次，但却收到18条匹配循环接收条件的消息。 （MessageBox 不知道业务流程逻辑仅处理 17 条消息。业务流程不使用传递的第 18 条消息，因为执行流已退出循环。 编排完成时带有被丢弃的消息（僵尸消息），这些消息无法恢复，因为编排实例已经完成。
可以使用 Windows Management Instrumentation （WMI） 脚本来查询具有“Suspended-NonResumable”状态的实例，从而管理僵尸。 此外，消息传送引擎还会将错误消息“处理完成，但消息已被丢弃”写入事件日志。
此外，如果你有一个具有长时间运行事务性范围的顺序队列，并且该范围具有超时设置，则某些编排实例最终可能处于“Suspended-NonResumable”状态。 您可能还会注意到，输出消息数加上“Suspended-NonResumable”实例数小于输入消息数。 此行为是设计造成的。 发生超时异常时，代码将进入异常处理程序。 BizTalk Server 调用异常处理程序以使其处理异常，包括处理僵尸。 可以使用异常处理程序中的发送端口将僵尸发送到目标，以便进一步查看和处理。
车队以外的场景也可以生成僵尸。 例如，假设一个编排实例正在期待来自某个业务流程的一个响应消息，但由于某种原因，它收到了两条匹配的订阅响应消息。 在这种情况下，第二个响应消息将成为僵尸。 另一个示例是，当您有一个分支上有接收形状的侦听形状，而另一个分支有延迟形状。 如果消息在发生超时时到达，则消息将成为僵尸。
有关如何管理僵尸的详细信息，请参阅 UI 指南和开发人员 API 命名空间参考中的“删除挂起的服务实例”。