通过

Microsoft BizTalk Accelerator for RosettaNet (BTARN) 的已知问题

  • 项目

本部分包含有助于避免 Microsoft® BizTalk Accelerator for RosettaNet (BTARN) 错误的有用信息。 已知问题归为以下几个方面：

  • 0A1 失败通知

  • 业务活动监视 (BAM)

  • 安装和配置

  • 杂项

0A1 失败通知

BTARN 不对 CIDX 流程配置属性和 0A1 协议属性执行跨字段验证

将使用该配置文件的协议的“0A1 协议”属性设置为“0A1”后，BTARN 不会阻止将进程配置文件的“标准”属性设置为“CIDX”，即使 CIDX 不支持 0A1 协议也是如此。

业务活动监视

业务活动监视报表中出现重复的列数据

BAM 活动 Web 报表中的 ActivityID 和 PIPInstanceID 列包含相同的内容。 此数据精确地反映了合作伙伴接口流程 (PIP) 实例标识符。 ActivityID 将这个值用于内部关联。 可以忽略此消息。

业务活动监视 Web 报表中出现空的数据列

业务活动监视 (BAM) Web 报表不包含任何有关 0A1 消息流程的数据。 Web 报表中的 0A1 消息列是用“Initiated 0A1”硬编码而成的。

安装和配置

BizTalk Application Users 组和 BizTalk Server Administrators 组中的组和用户必须在同一个域中

BTARN 支持将组添加到 BizTalk 应用程序用户组或BizTalk Server管理员组。 但是，属于 BizTalk Application Users 组或 BizTalk Server Administrators 组的各个用户帐户和组必须在同一个域中。

如果先删除 BizTalk Server，BTARN 的卸载将失败

如果在删除 BTARN 之前删除BizTalk Server，则 BTARN 删除过程将失败且不会出错。 若要解决此问题，请重新安装并重新配置BizTalk Server，然后删除 BTARN。

分布式部署需要域控制器

在多服务器环境中部署 BTARN 需要域控制器，例如，在一台服务器上安装了 BTARN，在另一台服务器上SQL Server用于配置的数据库。

不支持自定义 PIP 配置

当前版本的 BTARN 不支持使用自定义元素或其他非 RosettaNet 标准信息配置 PIP。

BTARN 自动启动单一登录服务

当 BTARN 需要单 Sign-On (SSO 服务未运行时，BTARN 会自动启动单 Sign-On (SSO) 。

如果没有为默认网站配置 WebApps，则配置程序将不会删除排除路径列表中的 BTARN 虚拟目录。

如果取消配置 BTARN 安装，其中 Web 应用程序虚拟文件夹配置为 SharePoint Server，而不是默认网站，则取消配置后，必须手动从 SharePoint 管理中心网站的“排除路径”列表中删除 btarnapp 和 btarnhttpreceive 虚拟目录。 这是因为当将 Web 应用程序虚拟文件夹配置为 SharePoint Server 时，必须将 btarnapp 和 btarnhttpreceive 手动添加到“排除路径”列表中。 配置程序将无法自动从“排除路径”列表中删除它们。

杂项

BTARN 将接收用下列任一种加密算法加密的消息

即使用于加密消息的协议与此字段中的编码设置不匹配，BTARN 接收管道也会接收和解密消息。 因此，BTARN 接收在 RC2-40 或 3DES 中加密的消息。

在单一操作同步方案中 BTARN 需要信号

在单操作同步方案中，BTARN 始终预期并生成信号。 此行为与 RosettaNet 规范允许的行为（在单一操作同步方案中信号可有可无）有所不同。 如果 BTARN 是响应方，它将始终生成信号以响应来自发起方的消息。 如果 BTARN 是发起方，则它始终需要响应方返回的信号。 如果 BTARN 未收到信号，则会在进程配置设置中的 Time To Perform 属性中指定的间隔后超时，并生成 0A1 消息。

BTARN 支持接收的消息中使用 UTF-16

BTARN 接收和处理字符集为 UTF-16 的消息。 BTARN 发送具有 UTF-8 字符集的消息。

从请求消息映射的响应消息中必须去掉命名空间

如果在双操作方案的专用流程中使用 BizTalk 映射器，则 BizTalk 映射器将向从请求消息映射的响应消息实例中的一些元素标记添加命名空间。 这些命名空间会导致在发送管道中发生故障。 必须删除这些命名空间。 使用 HeaderHelper 示例可实现这一目的。 有关详细信息，请参阅 双重操作 PIPAutomation Orchestration [RN3] 和 步骤 4：创建 HeaderHelper 项目 [RN3]。

更改 URI 设置需要 IISRESET

运行安装程序时，需要设置接收和发送 .aspx 页使用的 URI 设置以及接收和发送适配器使用的 URI 设置。 如果你更改了安装了 .aspx 页或适配器的计算机的名称，则必须更改这些设置。 可以通过重新运行配置进程更改这些设置，但这需要重置所有配置设置。 可以通过更改关联的注册表项 (AsyncReceivePortURI、 RNIFSenderURI和 SyncReceivePortURI) 来单独更改 URI 设置。 更改这些注册表设置中的任一项后，必须运行 IISRESET 才能使更改生效。 这是因为 BTARN 缓存设置以供其使用。 运行 IISRESET 后，还必须重新启动 BizTalk 服务。

BTARN 不对 RNIF v1.1 枚举进行限制

RosettaNet 实现框架 (RNIF) 规范 v1.1 指定了对某些 RNIF 架构枚举的限制。 BTARN 不会强制实施这些限制，也不会针对这些限制进行验证。 这些限制不适用于 RNIF v2.01。

这适用于下列服务头元素：

  • GlobalBusinessActionCode

  • GlobalPartnerClassificationCode

  • GlobalBusinessServiceCode

  • GlobalProcessCode

  • GlobalProcessIndicatorCode

  • VersionIdentifier

PerformanceControlRequest 参数不覆盖默认的流程配置设置

传入消息可以在 PerformanceControlRequest 服务标头中包含参数。 这些参数包括时间延迟参数“确认 (收据) ”和“执行时间”的值，如在 BTARN 管理控制台中所做的进程配置设置中设置的那样。 BTARN 不会根据传入消息中的 PerformanceControlRequest 参数动态设置时间延迟。 BTARN 始终采用进程配置设置中设置的默认 PIP 值的时间延迟。 这符合 RosettaNet 实现框架 (RNIF) 规范 v1.1。

双操作消息的 PIP 名称和 PIP 版本区分大小写

如果响应消息的 PIP 名称和 PIP 版本与原始双重操作请求消息的相应值不同，则发起方 BTARN 将拒绝响应消息，因为该消息无效，并将异常返回给响应方。

BTARN 不支持在流程处于活动状态时更改协议设置

单击“ 应用 ”或“ 确定 ”接受更改后，将立即应用对协议属性所做的更改。 更改协议后，已在运行的流程以及涉及该协议的任何新流程中的任何新活动都将使用更改的协议属性。 如果更改协议时有正在运行的流程，则该流程可能已经为消息使用了以前的协议属性。 该流程的新消息将使用新的协议设置，这会产生不可预测的结果。 建议你在所有流程都处于关闭状态时更改协议设置。

在对流程配置的配置文件进行更改后，BTARN 不执行跨字段验证

创建进程配置文件并创建协议时，BTARN 会执行跨字段验证，以确保协议的属性与配置文件兼容。 例如，它会对“标准”属性设为“CIDX”的配置文件进行检查，将协议的 0A1 协议属性设为“非 0A1”。 但是，如果在创建协议后更改进程配置文件，BTARN 不会执行跨字段验证。 如果将 Standard 属性从“RosettaNet”更改为“CIDX”，BTARN 不会验证协议的 0A1 协议属性是否设置为“No 0A1”。

如果所有业务流程均未启动，将出现错误

BTARN 安装程序安装九个业务流程。 要使 BTARN 成功处理消息，必须在开始处理之前绑定、登记和启动所有 9 个业务流程。 有关详细信息，请参阅“BizTalk 资源管理器中的业务流程管理”或BizTalk Server帮助中的“管理业务流程”主题。

RNIFReceive.aspx 不删除消息中的 MIME 下边界

RNIFReceive.aspx 页收到来自合作伙伴的 RNIFSend.aspx 页的消息时，该消息包含了 MIME 头以及 MIME 上边界和下边界（用 Base64 数字表示）。 RNIFSend.aspx 将头和边界添加到消息中以便进行 RNIF 传输。 将消息提交到公用流程之前，RNIFReceive.aspx 应将 MIME 头和边界从消息中删除。 RNIFReceive.aspx 删除 MIME 头和上边界，但不删除下边界。 下边界的存在不会影响公用流程中消息的处理。

BTARN 不支持 SQL Server 数据库的区分大小写的配置

如果使 BTARNSQL 服务器数据库和数据库对象区分大小写，BTARN 管理控制台将无法找到数据库资源并引发异常。 BTARNSQL 服务器数据库和数据库对象必须不区分大小写。

数据库维护脚本中的所有查询都应使用 UTC 时间

BTARN SQL Server数据库使用 UTC (世界时坐标) 时间，因此为维护其中一个数据库而创建的任何查询都必须在 UTC 时间写入。 例如，如果维护脚本要使用 GetDate() 命令，则应将其更改为 GetUTCDate()。

PublicResponder 业务流程将拒绝重复的请求操作消息

PublicResponder当业务流程 (PublicResponderV11.odx) 收到重复的请求操作消息时，它将在事件日志中记录警告，然后拒绝该消息。 如果在响应方业务流程完成后收到重复的消息，则 BizTalk Server 将终止该消息，因为不存在针对它的订阅。

如果公用流程被终止，BAM 不显示传输错误

如果公用流程业务流程在处理其最终消息时出现传输错误，事件日志和 HAT 将显示该错误，但 BAM 不显示该错误。 BAM 之所以不能显示该消息，是因为业务流程已停止。

pipeline.exe 工具不能用于调试 BTARN 接收管道

如果要调试接收管道，必须创建承载该管道的端口。 无法使用BizTalk Server提供的 pipeline.exe 工具对其进行调试。

在业务流程完成后，如果重试已经成功处理过的消息，则可能会产生错误

BTARN 使用业务流程来表示进程流。 在重试一些已经重试过的消息时，业务流程可能在重试消息到达 BizTalk MessageBox 之前已成功完成。 发生此行为时，BizTalk Server会生成相应的“已完成但已放弃”错误消息。 此时应查看业务线 (LOB) 应用程序，确定该流程是否已完成。 如果 LOB 应用程序指出已成功完成，则可以忽略“已完成但被删除”消息。

从 tracking.xls 导出的 XML 文件可能包含错误的字段

在跟踪 XLS 文件中定义新的跟踪视图并从该跟踪 XLS 文件导出 XML 文件时，某些字段名可能会被稍做改动。 若要更正此问题，请根据 BTARN 安装程序安装的标准 tracking.xml 字段验证自定义跟踪 XML 文件中的字段。

信号和响应的 RNIF 1.1 服务头架构可能需要修改

BTARN 提供了所有现成的 RosettaNet 标头架构。 一些实现与其他实现相比，使用“信号控制”和“操作控制”节点的方式不同，请见下述。

BTARN 现成附带的信号控制元素，如下所示。 请注意，“操作控制”元素也是即时可用的。

<!ELEMENT SignalControl (  
          InstanceIdentifier,  
          PartnerRoute,  
          SignalIdentity,  
          inResponseTo)>

如果你的解决方案需要此序列，则你无需执行任何操作。

而另一方面，其他一些实现使用以下代码：

<!ELEMENT SignalControl (  
          inResponseTo,  
          InstanceIdentifier,  
          PartnerRoute,  
          SignalIdentity)>

如果您的解决方案需要此序列，请参阅 KB 889523。 此软件更新程序将更改相应的 XML 架构。 请注意，此更新程序仅影响 RNIF 1.1 流程。

PipAutomationGetAction SQL 存储过程需要更新

需要更新 PipAutomationGetAction SQL 存储过程才能锁定各条记录。 删除以下行：

IF @@ERROR <> 0  
    UPDATE MessagesToLOB SET Delivered = -1 WHERE MessageID = @tempGUID

正确的 PipAutomationGetAction 存储过程如下所示：

CREATE PROCEDURE PipAutomationGetAction  
AS  
 SET TRANSACTION ISOLATION LEVEL READ COMMITTED  
BEGIN TRANSACTION  
DECLARE @tempGUID nvarchar(36)  
SELECT TOP 1 @tempGUID = MessageID FROM MessagesToLOB WITH (READPAST,UPDLOCK,ROWLOCK)  
   WHERE Delivered = 0 AND MessageCategory = 10  
  ORDER BY TimeCreated  
  SELECT PIPInstanceID,DestinationPartyName,SourcePartyName,PIPCode,PIPVersion, ServiceContent FROM MessagesToLOB  
   WHERE MessageID = @tempGUID  
For xml auto  
UPDATE MessagesToLOB SET Delivered = 1 WHERE MessageID = @tempGUID  
 COMMIT TRANSACTION  
GO

可自定义 aspx 代码，以返回错误说明

如果需要记录或发送错误说明，可自定义 aspx 代码，在响应中返回实际的文本。 为此，请使用 HttpResponse.Status (这是内部 asp 请求的响应对象) 或 HttpWebResponse.StatusDescription (由 httpWebRequest 对象的 GetResponse 方法) 返回。 若要从适用的响应对象之一返回值，请设置 Response.Status 值，类似于在 BTARN 随附的 aspx 代码中设置 Response.StatusCode 的方式。

如果编码方法设置为 Base64，则无法以纯文本形式从不可否认性表中读取 RNIF 1.1 消息

只有编码方法设置为 Base64 时才会出现这种情况。 如果编码方法设置为“quoted-printable”或“8 bit”，则可以明文形式从不可否认性表中读取消息。 需要以 *.eml 扩展名保存消息文件，然后使用 Outlook Express 打开才能读取消息内容，因为 Outlook Express 可以对消息进行解码。 还可使用以下代码从不可否认性表中读取用 Base64 编码的消息。

byte[] textBytes = Convert.FromBase64String(txtEncodedText.Text);  
string plainText = Encoding.UTF8.GetString(textBytes);  
txtOutput.Text = plainText;

另请参阅

故障排除和已知问题