如何在 BizTalk Orchestration 中从 Rest 服务捕获 http 400 状态答案

【问题标题】：How catch http 400 Status from Rest Service in BizTalk Orchestration如何在 BizTalk Orchestration 中从 Rest 服务捕获 http 400 状态
【发布时间】：2018-09-08 20:20:03
【问题描述】：

在 BizTalk 2013/R2 (CU6) 上，我在当前客户端中看到另一个应用程序/编排似乎正在执行此操作，但我的应用程序/编排不是。

我通过导出、编辑、然后导入、仅更改名称和操作/方法绑定来克隆他们的发送端口。它具有“检查失败消息的启用路由”。

看起来我正在使用 System.Exception 在编排中捕获它，但我仍然看到 SendPort 暂停（可恢复）和路由错误（不可恢复）。

我正在捕获的示例错误（我故意强制错误以测试错误处理）。

System.Net.WebException：远程服务器返回了意外响应：(400) 错误请求。 {"httpStatusCode":400,"httpMessage":"错误 Request","errorMessage":"无法处理货件 request","errors":[{"severity":"ERROR","message":"没有凭据为该供应商找到。你把它们加到ABC了吗仪表板？","source":"SYSTEM"}],"supportReferenceId":"31eee61a-8770-4524-bada-2d906a53ab48"}

我看过其他一些博客和问题表明没有返回500错误，并且没有设置http状态。但我还没有看到任何关于暂停发送端口的信息。似乎今天早些时候，我的 System.Exception 没有捕捉到它，但我不能及时回去确定。

我已将 SendPort 上的重试次数设为 0。

另外，究竟是什么决定了哪些 http 状态可以返回编排？我同事的代码也检查了 400、401 和 403。

相关问题：BizTalk Catch Http Response Code

更新：我的同事在另一个团队，但我收到了她的回复。她有另一个编排，只是“吃掉”错误消息以避免错误。

【问题讨论】：

标签： rest wcf biztalk

【解决方案1】：

Http 错误与任何其他硬故障相比应该没有什么特别之处。他们同样被提回到编排中。

这是一篇关于使用一些有用的技术处理编排中的错误的文章。

BizTalk Server: Suspend and Resume an Orchestration on Two Way Port Error

【讨论】：

但如果他们不这样做呢？我试图在编排中捕获 HTTP 4xx 状态，但似乎它们没有被 System.Exception 或 System.Net.WebException 处理程序捕获

【解决方案2】：

是的，即使您在编排中将其作为System.Exception 捕获，该消息仍将在发送端口中挂起。您可以通过执行以下操作来解决此问题。

为发送端口上的失败消息打开路由
拥有另一个带有自定义 NULL adapter 的发送端口，或者根据您的注释和 Johns 链接到的博客，一个订阅来自发送端口的所有错误消息的编排，例如ErrorReport.SendPortName == SendPortName。
如果您有另一个发送端口（如 ESB ALL.Exception 端口订阅失败），那么您需要更新规则以排除该端口 ErrorReport.SendPortName != SendPortName

Null Adapter 顾名思义，它只是将消息丢弃。你可以在 GitHub 上找到一个 NULL 适配器。如果无法安装，只需将其写入 FILE 位置并让清理作业将其删除。

【讨论】：

酷，我可能需要尽快在我正在编写的教程中再试一次。