发送适配器批量管理
在发送端使用事务时，BizTalk Server 创建的同一个事务既用于发送到目标系统，又在消息成功发送后用于相应的删除操作。 如果有任何失败，则可以终止事务，此时，删除将中止，数据会保留在 BizTalk Server 中，而不是目标系统中。 这可以防止重复消息。 事务仅支持异步发送适配器。 不应将事务与同步发送适配器一起使用。
但适配器不能仅仅结束事务；它还必须正确处理所给消息的状态。 具体而言，适配器应根据重试计数以及备份传输是否可用，适当地调用 Resubmit、 MoveToNextTransport 和 MoveToSuspendQ 的方法。
重要的是要将 Delete 和 SubmitResponse 操作放在使用同一事务的批处理中。 通过结束事务来处理失败（以确保数据仅提交一次到外部系统）。 但是，你仍希望重新提交或调用 MoveToNextTransport 以获取 BizTalk Server 上的消息。 为此，请对这类操作使用单独的普通（非事务性）批处理流程。
下图显示了对响应消息使用单独的批处理。
按终结点对 Send-Side 事务批处理进行排序
BizTalk Server 发送到适配器的消息批处理可以跨越多个发送端口（或终结点）。 由于适配器通常想要将事务发送到单个终结点，因此适配器必须基于发送端口（SPName 或 OutboundTransportLocation）对消息进行排序。 通过执行此操作，适配器可以创建一个仅跨越特定发送端口的事务。
例如，当 FTP 发送适配器从 BizTalk Server 接收一批消息时，它会获取所有当前活动 FTP 发送端口的混合批消息。 发生这种情况是因为 API 是基于单例模式的，这意味着仅加载一个 FTP 适配器，而不是为每个发送端口加载一个。
适配器必须首先将 BizTalk Server 提供的消息批进行分类排序，按照每个终结点划分为单独的批。 然后，它可以依次处理每个终结点，并可能为每个终结点构造删除批处理。 SDK 示例代码中的 BaseAdapter 泛型可重用类的工作方式相同。
动态发送的排序
BizTalk Server 业务流程可以将消息发送到尚未配置的端口，只要它在消息标头和 URL 本身中提供了足够的配置详细信息。 BizTalk Server 必须识别 URL 的协议。
对消息进行排序时，应注意确定定义终结点的内容。 对于动态发送，这尤其如此。 如果仅 URI 定义终结点，则情况很简单。 但是，在 FTP 会话中，FTP 服务器可能会使用用户名登录详细信息来定义真正的终结点。 在这种情况下，如果适配器以其他帐户身份登录，则它可能连接到其他目录。
在某些情况下，要等到您运行 Enterprise Single Sign-On（SSO）命令 ValidateAndRedeemTicket 后，才知道真正的终结点。
对于 MQSeries，确定是否使用事务是可配置的。 鉴于体系结构和使用远程 COM+ 对象，最好将事务终结点视为不同于非事务终结点。
总之，将消息排序到其单个终结点批处理有时是一项非琐碎的任务，并可能涉及考虑上下文值甚至调用 SSO 的结果等额外步骤。
静态发送的排序
如果终结点是静态配置的终结点，则消息上下文中存在一个名为静态端口 ID（SPID）的唯一 GUID。 此值可用于对终结点进行排序。 以下代码可用于检索它：
string spid = (string)message.Context.Read("SPID", "http://schemas.microsoft.com/BizTalk/2003/system-properties");
当你考虑基于 XML 架构定义 （XSD） 的配置框架引入的问题时，这非常有用。 在此框架中，你有一个属性，该属性可能是存储在单个上下文属性中 XML 中的终结点密钥的一部分。 如果上下文中有 SPID，则可以将其用作对批处理进行排序的方法。 否则，需要执行动态发送，并且需要构造用于对批处理进行排序的备用键。
下图显示了按终结点进行消息排序。
请记住，消息的重试计数不反映批处理的成功或失败。 在发送端，由于批处理中的一些消息失败，一批消息可能会失败。 适配器必须确定它收到的每条消息。 在失败的批处理情况下，您可能会假设重新提交每条消息。 但是，如果重新提交失败批处理中的所有消息，即使成功消息的重试计数（由 BizTalk Server 引擎维护）也会错误地递增，因为它们恰好与失败的消息位于同一批中。 在这种情况下，适配器可以调整出站批处理，并再次发送已成功的消息到外部系统。