使用Biztalk的异常处理解决交换过程中的出错问题
使用Biztalk的异常处理解决交换过程中的出错问题
摘要:
通过 BizTalk Server 2006 中的新增错误处理功能，设计者可以指定对消息传送失败进行自动处理，以此作为将失败消息放在挂起队列中的传统（现在是默认）行为的替换选择。此自动处理方式会将错误消息路由到任何订阅路由目标（例如发送端口或业务流程）。错误消息是原始消息的克隆，其中以前升级的所有属性将降级，与特定消息传送失败相关的所选属性将升级到消息上下文。
问题描述:
源端和目标端数据交换,一批数据进入Biztalk后,逐条拆分映射后,交换到目标库.流程中未使用异常处理.
源端对应的字段比目标端对应的字段长度大,但真正比目标大的记录条数不多,这几条记录导致流程挂起,该数据之后的数据全部未交换.
以前解决方案:
更新目标库对应字段长度后,未交换的数据全部再次交换.这种方法比较死板,而且效率不高.
利用出错处理:
在发送到目标库并返回,这部操作加上异常处理,捕获异常.则该激发异常的消息不交换,该消息之后的数据继续进行交换.
之后找到出错原因,更改目标库字段长度,重新交换未交换到目标的消息.
异常处理为系统日志中加入该出错信息:
激发异常的消息处理:
该消息不处理或者路由到指定位置.
消息不处理:
消息则为挂起(可恢复)状态,如果此时流程未完成,更改目标库后,可以恢复并交换到目标库;如果此时流程已经完成,只剩单个消息,即使更改好了目标库,恢复也不能成功.
路由到指定位置:
消息在出错后,直接由路由的发送端口发送到指定位置,通常为文件夹中的的xml文件.重新交换该消息时,可以从这些文件中获取未交换记录的信息.
路由时发送到目标的端口需要选择"为失败的消息启用路由功能":
路由该出错消息的发送端口设置过滤条件,确保只路由该端口产生的异常消息:
参考文档:
<<biztalk中的发送端口产生异常及处理(下）>> chnking
BTS06_CN.chm BizTalk2006帮助文档中文版:
通过 BizTalk Server 2006 中的新增错误处理功能，设计者可以指定对消息传送失败进行自动处理，以此作为将失败消息放在挂起队列中的传统（现在是默认）行为的替换选择。此自动处理方式会将错误消息路由到任何订阅路由目标（例如发送端口或业务流程）。错误消息是原始消息的克隆，其中以前升级的所有属性将降级，与特定消息传送失败相关的所选属性将升级到消息上下文。
| 警告 |
|---|
| 失败消息包含原始消息的副本。如果原始消息包含敏感信息，则应当设计手动和自动失败消息处理，以避免意外泄漏这些信息。
|
失败消息路由由哪些部分组成？
启用失败消息路由后，BizTalk Server 不会挂起消息，而是路由消息。可以在接收端口和发送端口上都启用失败消息路由，其结果如下：
- 如果在接收端口上启用失败消息路由，并且消息在接收管道或路由中失败，则会生成失败消息。在拆装阶段中或拆装阶段之前出现错误的情况下，错误消息是原始交换的克隆。
- 如果在发送端口上启用失败消息路由，并且消息在发送管道中失败，则会生成失败消息。
生成失败消息时，BizTalk Server 会在发布失败消息之前将与错误报告相关的消息上下文属性升级，并将常规消息上下文属性降级。将此行为与不启用失败消息路由时的默认行为进行比较：失败的消息将被挂起。
有哪些种类的消息失败会触发错误消息？
如果启用了对失败消息的路由，则在适配器处理、管道处理、映射或消息路由过程中所发生的任何故障都将导致错误消息。如果从接收端口接收或向发送端口发送业务流程时出现了消息传送错误，则生成的错误消息将与业务流程所绑定的消息端口关联。
订阅错误消息
错误消息将传送到已订阅接收它们的业务流程或发送端口。通常，订阅基于出现消息传送错误的端口（发送端口或接收端口）的名称来选择错误消息。订阅还可能对升级到错误的消息上下文的其他属性（例如，InboundTransportLocation 或 FailureCode）进行筛选。
错误消息规范
错误消息是原始失败消息的克隆，其中以前升级的所有属性将降级，一组特定于错误的属性将升级到消息上下文。以前升级的属性降级是为了避免非有意地将其传送给未指定接收错误消息的订户。发布错误消息以分发给订户（业务流程、发送端口和发送端口组）。
升级到错误消息上下文的属性全部在 ErrorReport 命名空间下。这些属性包括：
| 属性名称 | 数据类型 | 已升级 | 说明 | ||
|---|---|---|---|---|---|
|
FailureCode |
System.String |
是 |
错误代码。十六进制值，在 BizTalk Server 管理控制台中报告该值。 | ||
|
FailureCategory |
System.Int32 |
是 |
BizTalk Server 2006 中不使用此属性。其值未定义。 | ||
|
说明 |
System.String |
否 |
错误说明。与写入应用程序事件日志中的内容相同的诊断文本，提供有关此消息传送失败的信息。 | ||
|
MessageType |
System.String |
是 |
失败消息的消息类型，如果消息类型不确定则为空。 BizTalk Server 使用消息类型将消息与其 XML 架构相关联。消息类型通过连接架构命名空间和架构根节点形成：http://mynamespace#rootnode。
| ||
|
ReceivePortName |
System.String |
如果失败发生在入站处理期间（在接收端口中），则为“已升级”。 如果失败发生在发送端口中，则为“未升级”。 |
发生失败的接收端口的名称。 | ||
|
InboundTransportLocation |
System.String |
如果失败发生在入站处理期间（在接收端口中），则为“已升级”。 如果失败发生在发送端口中，则为“未升级”。 |
发生失败的接收位置的 URI。 | ||
|
SendPortName |
System.String |
如果失败发生在出站处理期间（在发送端口中），则为“已升级”。 如果失败发生在接收端口中，则为“未升级”。 |
发生失败的发送端口的名称。 | ||
|
OutboundTransportLocation |
System.String |
如果失败发生在出站处理期间（在发送端口中），则为“已升级”。 如果失败发生在接收端口中，则为“未升级”。 |
发生失败的发送位置的 URI。 | ||
|
ErrorType |
System.String |
是 |
指示错误包含的消息的类型。在 BizTalk Server 2006 中，此属性始终包含值 FailedMessage，表示错误包含原始失败消息。 | ||
|
RoutingFailureReportID |
System.String |
是 |
存在路由故障时，此属性提供 BizTalk Server 生成的路由故障报告的 ID。路由故障报告是由 BizTalk Server 生成和挂起的特殊消息。此消息没有正文，但它具有失败消息的上下文。使用此 ID，错误处理业务流程或发送端口可以查询 MessageBox 数据库并处理路由故障报告。例如，业务流程在获取失败消息之后可能要终止路由故障报告。 |
处理错误消息
错误处理由其筛选器与已升级到错误消息的消息上下文的属性匹配的业务流程或发送端口订阅指定。
安全含义
将与原始消息关联的标识（它的初始标识或它的最后标识，由接收管道的解析参与方阶段确定）分配给错误消息。
限制消息只能传送给授权的订阅端口和业务流程的安全机制也应用于错误消息。
对于订阅错误消息但未使用适当的解密证书进行配置的发送端口，不会收到在接收管道（原始消息通过其进入 BizTalk Server）解密阶段之内或之前基于消息传送失败产生的错误消息。而失败消息将放置在挂起队列中。
适配器消息传送失败
如果适配器挂起消息，则会发布错误消息。如果消息未挂起，则不会生成错误消息。
事务性接收管道
如果事务性接收管道引发异常（指定事务应被中止），则事务将中止，并发布错误消息。
如果事务性接收管道显式挂起消息（指定 MessageDestination = SuspendQueue），则允许当前事务继续（并且可能被提交，除非随后的阶段指定将其中止），并且发布所生成的错误消息。
要求响应发送端口
如果从业务流程发送请求消息，而请求消息传输失败或其响应在入站处理时失败，则不管是否已经路由失败消息，业务流程都将获得异常。
在将要求响应发送端口连接到请求响应接收端口的情况下，不管是否已经路由失败消息，接收端口都将获得响应消息（如果传输成功）或 NACK（如果传输失败）。
单向发送端口
如果从业务流程通过配置送达通知的发送端口发送消息，则不管是否已经路由了错误消息，业务流程都将收到送达通知。换句话说，即使端口在处理期间遇到消息传送失败，发送端口也将为业务流程生成送达通知。通知会确认到端口的送达，但不会确保通过端口成功进行处理。
恢复挂起消息
大多数入站处理（即从接收适配器（包括）到发布到 MessageBox（不包括）的处理）失败并且其失败未处理的消息将会作为可恢复消息挂起。例外情况是来自双向接收端口的请求消息将作为不可恢复消息挂起。
消息通常以其原始形式（管道处理之前的形式）挂起，但以下两种消息除外：
- 由管道组件挂起的消息。BizTalk Server 以将其提供给失败管道组件时的相同形式挂起此类消息。恢复消息时，从同一管道的开始位置执行管道处理。这意味着，对于在出现原始失败的阶段以前的管道阶段中的管道组件，它们必须准备以不同于原始形式（处理该消息的形式）的形式处理“相同”消息。
- 来自可恢复的交换拆装随后路由失败的消息。BizTalk Server 将以与消息发布时相同的形式挂起此类消息。这是在管道执行之后消息所具有的形式。消息恢复后，会跳过管道处理，直接发布到 MessageBox 数据库。
导致消息挂起（不可恢复）的情况
通常，挂起的消息是可恢复的，不过在某些情况下，也会导致不可恢复的消息：
- 在允许在发生故障后仍继续的“按序送达”发送端口中，如果管道、映射或传输发生故障的情况下。
- 在“按序送达”接收端口中，如果适配器配置为发生故障时以不可恢复的方式挂起消息的情况下。例如，如果 MSMQ 适配器的“失败时”设置设为“已挂起(不可恢复)”或者 MQSeries 适配器启用了“挂起且不可恢复”，则失败的消息将作为不可恢复的消息被挂起。
- 在双向接收端口中，如果管道、映射或传输中的响应消息失败的情况下。
- 在双向接收端口中，如果管道、映射或传输中的接收消息失败的情况下。不同的适配器可能有不同的行为。例如，默认情况下 HTTP 适配器不会将消息挂起，但可以配置为将消息挂起。
