BizTalk Server 2006运行时改进(4)

已失败消息路由

在默认条件下，当消息在接收管道中遭遇失败（验证、转换、路由失败等）时，该消息被自动地作为被挂起消息放入消息箱。可以使用 HAT 查看被挂起的消息，并且可以使用  MOM (Microsoft Operations Manager) 发送冲突消息的通知。在默认条件下，已失败消息不能被编排或发送端口等端点订阅。在 BizTalk Server 2004 中，这是已失败消息的默认操作。

BizTalk Server 2006 引入了新的功能，为处理已失败消息提供了附加的灵活性。当新的接收端口被创建时，有一个属性可以被设置为 “Generate error report for failed message”（见图 3）。

图 3：接收端口设定

当这一属性被选定时，已失败消息不会被挂起，而是被发送到消息箱并设定下列附加属性。

◆错误类型 (ErrorType)
◆失败代码 (FailureCode)
◆描述 (Description)
◆消息类型 (MessageType)
◆接收端口名称 (ReceivePortName)
◆发送端口名称 (SendPortName)
◆入站传输位置 (InboundTransportLocation)
◆出站传输位置 (OutboundTransportLocation)
◆路由失败报告 ID (RoutingFailureReportID)

除“描述”和“路由失败报告 ID”之外，将提示以上所有的属性。通过利用这些附加的上下文属性，您现在可以在编排或发送端口上创建端点过滤器以订阅这些已失败消息。在使用得当时，已失败消息路由可被用于给用户发送消息失败的通知或者建立丰富的错误处理或消息修复功能。参见图 4 中基于错误类别、错误代码和接收端口名称对消息进行过滤的编排范例。

图 4：错误处理编排范例

注意：这不会对仅仅订阅 BTS.MessageType 属性的现有应用程序构成影响，因为该属性只有在消息成功通过管道时才被提示。在消息失败时，则提示 ErrorReport.MessageType。

消息续传

在 BizTalk Server 2004 中，消息续传功能非常简单。对于发送方而言，可以选择单个消息用 HAT 进行续传。对于接收方而言，则不能对消息进行续传。在使用 BizTalk Server 2006 时，事情发生了改变。几乎所有的接收方消息都可以被续传。在需要依次传递的消息场合中（即 MSMQ 和 MQSeries 等），由于需要保持次序的完整性而不可能进行消息续传。依次消息传递在下一节中进行讨论。

此外，用于续传消息的工具发生了改变。消息监视不再是 HAT 的功能，但消息跟踪功能仍处于 HAT 中。相替代的是，BizTalk 管理控制台包含全新的“枢纽”页面，赋予管理员查看 BizTalk 中活动消息的功能。

图 5：使用 管理控制台续传接收方消息

从图 5 中可以看出，可以根据错误代码选择单个消息进行续传或中止或者执行批式续传或中止。