通过

使用失败的消息路由

错误处理工具允许设计器将消息传递失败的自动处理指定为将失败消息置于挂起队列的传统（现在默认）行为的替代方法。 此自动处理会将错误消息路由到任何订阅路由目标，例如发送端口或业务流程。 错误消息是原始消息的一个克隆，其中所有以前被提升的属性现已被降级，而与特定消息失败相关的某些属性则被选择并提升到消息上下文中。

警告

失败的消息包含原始消息的副本。 如果原始消息包含敏感信息，请设计手动和自动失败的消息进程，以免意外泄露。

失败的消息路由包括哪些内容？

启用失败的消息路由后，BizTalk Server 不会挂起消息，而是将其路由。 可以在接收和发送端口上启用失败的消息路由，结果如下：

  • 如果在接收端口上启用了失败的消息路由，并且消息在接收管道或路由中失败，则会生成失败的消息。 如果在反汇编阶段或之前发生错误，则错误消息与原始交换信息相同。

  • 如果在发送端口上启用了失败的消息路由，并且消息在发送管道中失败，则会生成失败的消息。

    生成失败的消息时，BizTalk Server 会提升与错误报告相关的消息上下文属性，并在发布失败的消息之前降级常规消息上下文属性。 如果未启用失败的消息路由，则将此与默认行为进行比较：挂起失败的消息。

哪些类型的消息传送失败会触发错误消息？

如果启用了失败的消息路由，适配器处理、管道处理、映射或消息路由中发生的任何失败都会导致错误消息。 当业务流程从接收端口或发送到发送端口时发生消息错误时，生成的错误消息与业务流程绑定到的消息端口相关联。

订阅错误消息

错误消息将传送到业务流程或发送已订阅接收它们的端口。 订阅通常根据发生消息传送错误的端口的名称（发送或接收端口）选择错误消息。 订阅还可以基于在错误消息上下文中被提升的其他属性进行筛选（例如 InboundTransportLocation 或 FailureCode）。

错误消息规范

错误消息是原始失败消息的克隆，其中所有以前升级的属性已降级，并升级为消息上下文的一组特定于错误的属性。 以前被提升的特性已被降级，以避免意外传递给未指定接收错误消息的订阅用户。 发布错误消息以分发给订阅服务器（业务流程、发送端口和发送端口组）。

提升为错误消息上下文的属性都位于 BizTalk Server 中的 ErrorReport 命名空间下。 如下所示：

属性名称 数据类型 促进 DESCRIPTION
故障代码 xs：string 是的 错误代码。 BizTalk Server 管理控制台中报告的十六进制值。
故障类别 xs：int 是的 不使用此属性。 其值未定义。
DESCRIPTION xs：string 否 错误说明。 与写入应用程序事件日志中有关此消息传送失败的诊断文本相同。
消息类型 xs：string 是的 失败消息的消息类型;如果消息类型不确定，则为空。

BizTalk Server 使用消息类型将消息与其 XML 架构相关联。 消息类型通过连接架构命名空间与架构根节点形成： http://mynamespace#rootnode. 注意： 确定消息类型之前失败的消息未设置此属性。
接收端口名称 xs：string 如果故障发生在接收端口的入站处理期间，则状态会被提升

如果故障发生在发送端口，则不会被提升。		 发生故障的接收端口的名称。
InboundTransportLocation xs：string 升级 如果在入站处理（在接收端口中）期间发生故障

在发送端口中发生故障时，不会被提升。		 发生故障的接收位置的 URI。
SendPortName xs：string 升级 如果在出站处理期间发生故障（在发送端口中）

如果失败发生在接收端口中，则不会升级。		 发生故障的发送端口的名称。
出站运输地点 xs：string 在出站处理期间发生故障（在发送端口中）时，故障将被提升处理

如果失败发生在接收端口中，则不会被提升。		 发生失败的发送位置的 URI。
错误类型 xs：string 是的 指示错误包含的消息类型。 此属性始终包含 FailedMessage 值，这意味着错误包含原始失败的消息。
路由失败报告ID xs：string 是的 此属性提供 BizTalk Server 在发生路由失败时生成的路由失败报告的 ID。 路由失败报告是由 BizTalk Server 生成并挂起的一种特殊消息。 此消息没有正文，但它具有失败消息的上下文。 使用此 ID，错误处理业务流程或发送端口可以查询 MessageBox 数据库并处理路由失败报告。 例如，业务流程可能需要在收到失败消息后终止路由失败报告。
故障时间 xs：dateTime 失败事件的日期时间
失败消息ID xs：string
故障实例ID xs：string
故障适配器 xs：string

处理错误消息

错误处理是由编排或发送端口订阅指定的，其筛选器与被推广到错误消息上下文的属性匹配。

安全隐患

与原始消息关联的身份——无论是初始身份还是通过接收管道的“解析方”阶段确定的最终身份——都会被分配给错误消息。

限制将消息传送到授权订阅端口和业务流程的安全机制也适用于错误消息。

订阅错误消息但未配置合适解密证书的发送端口，不会收到在接收管道的解密阶段或之前出现的，由消息传送失败引起的错误消息。这些错误消息是在原始消息通过接收管道进入 BizTalk Server 时产生的。 相反，失败的消息被放置在挂起队列中。

适配器消息传送失败

如果适配器挂起消息，则会发布错误消息。 若消息未被挂起，则不会生成错误消息。

事务接收管道

如果事务接收管道引发异常（指定应中止事务），则会中止事务并发布错误消息。

如果事务接收管道显式挂起消息（指定 MessageDestination = SuspendQueue），则允许当前事务继续（除非后续阶段指定中止该消息），并发布生成的错误消息。

Solicit-Response 发送端口

当请求消息从业务流程发送且传输失败或其响应处理失败时，不论失败的消息是否已被路由，业务流程都会收到异常。

如果请求响应发送端口连接到请求-响应接收端口，则接收端口将获取响应消息（如果传输成功）或 NACK（如果传输失败），而不考虑是否已路由失败的消息。

One-Way 发送端口

当通过配置为传递通知的发送端口从业务流程发送消息时，业务流程将接收传递通知，而不考虑是否已路由错误消息。 换句话说，即使端口在处理过程中遇到消息传送失败，发送端口也会为业务流程生成传递通知。 通知确认传送到端口，但无法解决通过端口成功处理的问题。

恢复被挂起的消息

大多数在入站处理过程中失败且未处理失败的信息（即，从接收适配器开始处理到但不包括发布到消息框的过程），将被暂停为可重试。 例外情况是，来自双向接收端口的请求消息被挂起为不可恢复。

消息通常以原始形式暂停（就像管道处理前一样），但有两个例外：

  • 消息被管道组件挂起。 BizTalk Server 以与提供给失败的管道组件相同的形式挂起这种类型的消息。 消息恢复后，将从同一管道的起点开始进行处理。 这意味着，在原始失败发生之前的管道阶段中，管道组件必须准备好以不同于初始处理方式的形式处理“相同”的消息。

  • 可恢复交换拆解过程中随后无法路由的消息。 BizTalk Server 以与发布时相同的形式挂起这种类型的消息。 这是消息在管道执行 后 采用的格式。 恢复消息后，它将跳过管道处理，并直接发布到 MessageBox 数据库。

导致挂起（不可重启）消息的情况

虽然消息通常会被暂停为可恢复的，但在某些情况下会导致消息不可恢复：

  • 在启用了继续失败选项的有序传递发送端口中，如果管道、映射或传输出现故障。

  • 在有序传递接收端口中，如果适配器配置为在发生不可恢复的故障时挂起消息。 例如，如果 MSMQ 适配器的设置“失败时”被设置为“挂起（不可恢复）”，或者 MQSeries 适配器启用了“挂起为不可恢复”，则失败的消息将被挂起为不可恢复。

  • 在双向接收端口中，如果响应消息在管道、映射或传输过程中失败。

  • 在双向接收端口中，如果接收消息在管道、映射或传输过程中失败。 单个适配器行为可能有所不同。 例如，HTTP 适配器在默认情况下不会挂起消息，但可以配置为这样做。

另请参阅

错误处理
使用致谢
邮件的有序传递