BizTalk适配器及适配器上的事务

 通常，BizTalk Server 中的适配器即是通过 BizTalk Server 接收和发送的消息的第一个组件也是最后一个组件。BizTalk 提供 File、SQL、HTTP、SOAP、SMTP、Message Queuing 和 Base EDI 等现成的适配器。  

    事务保证只投入一次成本。对于非事务性适配器，在单个 MessageBox 数据库的情况下，消息传递引擎使用 SQL 事务（而非 MSDTC）来创建 COM+ 事务。然而，在这些情况下，如果在处理时出现任何系统故障，则系统会两次接收或发送相同的消息。对于事务性适配器 (SQL/mySAP/MQ Series/MSMQ)，引擎将始终使用 COM+ DTC 事务，这是因为事务跨多个系统 — 消息框（一个或多个）和消息的源或目的地。适配器始终拥有事务，并负责事务的提交或回滚；引擎只是进行表决。

    在高吞吐量的情况下，可能需要扩展 BizTalk 使用的 MessageBox 数据库层。在多消息框的拓扑中，代理/引擎自动使用 DTC，通过添加第二个消息框所实现的性能提升都会被分布式事务所抵销。只有当添加第三个消息框时，才能真正提高性能。因此，一般建议将单个消息框的拓扑直接升级为三个消息框（而不是两个）。

    也有特殊情况，即消息传递引擎自动使用 DTC。在引擎正在处理大文件或大的批处理文件（包含多个消息的批处理文件，这些消息的数据总量大于配置门限）时，出现这一情况。配置门限默认为 100K。

BizTalk 本地适配器

BizTalk Server 有几个本地适配器。包括：

• 文件适配器

• SQL 适配器

• 消息队列适配器

• FTP 适配器

• HTTP 适配器

文件适配器

    文件接收适配器用于阅读来自文件系统（本地或网络）的消息并提交给 BizTalk Server。如果网络位置不可用，则适配器会根据接收位置中的设置重试操作（这不适用于本地共享）。成功接受消息之后，适配器会删除文件。如果阅读消息成功但在管线中失败，则适配器会将消息放在 Suspended Queue 中并删除文件。如果适配器不能向 MessageBox 数据库提交或挂起消息，则它不删除原始文件。

    接收适配器将消息成批提交给 MessageBox 数据库。批大小默认为 20，可在接收位置属性中配置。如果适配器可成功阅读消息并将其成批提交给 MessageBox 数据库，则会从接收位置删除相应的文件。如果批中有些消息处理失败，则该消息会挂起并从接收位置删除相应的文件。如果有任何消息在存储到 MessageBox 数据库时失败，则整个批都会回滚并在接收位置保留相应的文件不变。批只有在回发到 MessageBox 数据库不成功（不管是在挂起队列中还是在处理队列中）时才回滚，这一点非常重要。

    文件发送适配器的工作方式与之相反，它将消息写到一个文件中，如果成功，则从 MessageBox 数据库删除消息。批操作也可应用于发送适配器；但是，批大小不可配置且预设为 10。如果由于某种原因导致服务器不能将消息成批写到文件中，则这些消息会回滚到 MessageBox 数据库以便重试处理。只有当写入失败的消息经重试后，批中成功的消息才会从 MessageBox 数据库中删除，这一点非常重要。

文件适配器是非事务性适配器，可能释放文件或接收重复文件。

SQL 适配器

    SQL 适配器被归类为事务性 BizTalk Server 适配器。SQL 接收适配器是一个轮询服务，它周期性地轮询 Microsoft SQL Server 是否有结果集。该接收适配器支持返回单个结果集的 SELECT 语句和存储过程。如果消息在 BizTalk Server 2004 中验证或路由失败，则适配器提交事务并将失败的消息放在挂起队列中。该适配器使用 MSDTC 管理事务。

SQL 发送适配器可配置为发送 UpdateGrams 或运行存储过程。所有 UpdateGrams 都包含相同的基本结构：

<UpdateGramRootElement>
<sync>
<before>
<TableName col1='somevalue' col2='somevalue' />
</before>
<after>
<TableName col1='somevalue' col2='somevalue' />
</after>
</sync>
</UpdateGramRootElement>

以下定义描述每个块的作用：

<before>

标识记录实例的现有状态（也称为“前期状态”），与 SQL 语句中的 WHERE 子句作用相同。

<after>

标识数据将更改到的新状态。

<sync>

包含 <before> 和 <after> 块。一个 <sync> 块可包含多组 <before> 和 <after> 块。如果存在多组 <before> 和 <after> 块，则需要将它们指定为对（即使它们为空）。可以有多个 <sync> 块，每个 <sync> 块都作为一个事务单元。如果在 UpdateGram 中指定多个 <sync> 块，则一个 <sync> 块失败不会影响其他 <sync> 块。

适配器的事务性功能默认为开启；该功能无法关闭。由于事务跨越整个应用程序数据库，因此应用程序数据库的设计和事务会影响应用程序的整体并发和性能。

消息队列适配器

    消息队列适配器（即通常所说的 MSMQ/T）与Microsoft Message Queuing 采用相同的网络协议，但保存位置是 BizTalk MessageBox 数据库。MSMQ/T 接收适配器与接收位置（而非队列）连接。

默认情况下，接收队列是事务性的。可以通过设置接收位置中的 Non-Transactional 属性，将队列指定为非事务性的。当使用 MSMQ 协议来向 MSMQT 发送消息时，客户端上事务的作用域仅确保消息已成功写入本地客户端的队列存储；即使客户端计算机发生故障，也可安全地重新构造此消息并将其发送给接收方。另外，使用事务时，只有在提交事务后才能在队列中看到消息。

    目的地 Microsoft Message Queuing 或 BizTalk Message Queuing 服务负责向源 Microsoft Message Queuing 或 BizTalk Message Queuing 服务发送确认，指示最近接收的消息的序列号。如果源 Microsoft Message Queuing 或 BizTalk Message Queuing 服务未在一定的时间限制内收到适当顺序的确认，则它会重新发送消息。Microsoft Message Queuing 或 BizTalk Message Queuing 服务会丢弃目的地未按顺序接收的消息，这是因为源 Microsoft Message Queuing 或 BizTalk Message Queuing 服务将重发这些消息。

MSMQ/T 始终按顺序传递，这使性能变差。

FTP 适配器

    FTP 适配器允许数据在 FTP 服务器和 BizTalk Server 之间来回移动。利用在以下平台上可用的默认 FTP 服务器，FTP 适配器提供对 FTP 传输的支持：Solaris 9.0、HP-UX、LINUX (Redhat 7.x)、运行 MVS 的 IBM O/S 390、AS400 OS/400 V5R1、Microsoft Windows® 2000 Server Service Pack 4、Microsoft Windows 2000 Advanced Server Service Pack 4 和 Microsoft Windows Server™ 2003。

FTP 接收适配器通过使用临时文件夹来确保从主机服务器一次性传递消息。Temporary 文件夹通过接收位置的属性设置进行设置。下面是一个示例方案：

Server A 是 BizTalk 试图连接的远程 FTP 服务器，Server B 是 FTP 适配器所在的 BizTalk Server。需要为接收位置设置以下值：

服务器：Server A

文件夹：远程 FTP 服务器上的 FTP 文件夹

Temporary 文件夹：C:\FTP\Temp

Server A 上应该存在具有正确权限的 FTP 文件夹。BizTalk Server 上需要存在具有正确权限的文件夹“C:\FTP\TEMP”。

FTP 发送适配器也使用 Temporary 文件夹来进行错误恢复和原子上载。错误恢复逻辑使用 Temporary 文件夹中的文件大小（以字节为单位）来确定（在前一次尝试中可能）已经传送的字节数。这仅支持在二进制模式下上载。

HTTP 适配器

    HTTP 适配器允许以 HTTP 协议的方式在 BizTalk Server 和应用程序之间交换信息。应用程序可以通过向指定的 URL 发送 HTTP POST 或 HTTP GET 请求来向服务器发送消息。HTTP 适配器接收 HTTP 请求并将它们提交给 BizTalk Server 进行处理。类似地，BizTalk Server 可以通过向指定的 HTTP URL 发送 HTTP POST 请求来向远程应用程序发送消息。

HTTP 接收适配器使用一个特定于 BizTalk 的 Internet Server API (ISAPI) 筛选器来为请求提供服务。该 HTTP 接收适配器将消息成批提交给服务器。如果批中有些消息在管线中处理失败，则 HTTP 接收适配器会向其消息处理失败的客户端返回服务器错误代码“500 - Internal Server Error”，并且不挂起失败的消息。如果一些消息或所有消息在存储到 MessageBox 数据库时失败，则系统回滚整个批操作并向批中发出请求的所有客户端发送服务器错误代码 500。HTTP 发送适配器不支持批操作。