【问题标题】:BizTalk 2006 R2 schema validation specific error message with failed message routingBizTalk 2006 R2 架构验证特定错误消息,消息路由失败
【发布时间】:2011-04-20 18:58:55
【问题描述】:

我正在寻找一种方法来捕获 BizTalk 2006 R2 在接收端口无法解析接收到的消息时引发的实际异常。

例如,我有一个未正确创建的 csv 文件,说它缺少逗号,因此当 BizTalk 尝试确定消息类型时,它会出错。如果不使用失败的消息路由,应用程序事件日志中有 2 个条目。其中有一个非常通用的错误描述,类似于“消息引擎在处理一条或多条入站消息期间遇到错误”。第二个条目有我正在寻找的东西。它将包含缺少逗号所在位置的详细信息,类似于“查找时发现意外数据: ',' 当前正在解析的定义是 POSTrailer。发生错误的流偏移量为44443。发生错误的行号为244。发生错误的列是1。"

我尝试使用 BizTalk 2006 R2 的 ESB 工具包异常处理程序。使用失败的消息路由及其异常处理框架,它捕获的错误描述是第一个通用的错误描述。

我看不到任何获取第二个更详细的错误描述的方法。我假设在 biztalk 消息传递引擎的内部某个地方抛出了这个异常,在这个过程中被更高一点的东西捕获,它抛出了它自己的通用 biztalk 异常。我还假设更具体的错误描述包含在路由到 ESB 工具包的异常的内部异常中,但是当我可以掌握它时,据我所知,实际的异常对象已经被消息上下文所取代,它只不过是一堆名称/值对。错误描述现在是没有帮助的通用错误描述,任何类似于内部异常的东西都只是十六进制代码,对我的最终用户没有任何意义。

我发现的有关获取特定错误消息的所有内容都涉及从业务流程中抛出的异常。不过,我不是在处理编排,而是在处理接收端口。我能找到的最接近的是here。但即使我可以使用它创建一个自定义管道组件,这意味着我需要将该组件添加到每个现有的自定义管道中,或者创建一个新的来验证 XML 并使用它而不是 BizTalk 附带的 XMLRecieve 或 XMLSend 管道...这也意味着捕获由 EDI 产生的错误是不可能的。有谁知道如何从 BizTalk 生成的错误消息中获取更详细的错误描述?

【问题讨论】:

  • 为什么这会交给您的最终用户?我工作过的每个组织都将这个问题留给了 BizTalk 管理员(通常是系统管理员或 BizTalk 开发组)。您是否希望允许某些代码重新生成文件?
  • @AllenG - 最终目标将是一个网站,最终用户可以使用该网站来监控流程并解决任何错误。我所指的最终用户是业务流程所有者。他们不需要专门了解 BizTalk 管理,他们需要知道(例如)供应商发送的采购订单是否进入了分析数据库,如果没有,发生了什么。我目前是 biztalk 的开发人员和管理员,但我们现在已经推出了足够多的应用程序,我无法再处理所有的管理员职责了。

标签: exception-handling biztalk biztalk2006r2


【解决方案1】:

我不确定是否有一个工具可以完全满足您的需求,但我确实有几个选择。

1) 我很确定 SCOM 可以抓住这些错误并提醒需要提醒的人。不过,我过去遇到过一些问题,所以这可能不是你最好的选择。

2) 对于基本的故障处理,您可以编写代码以从 BizTalk 中抓取任何警告或错误的 EventLog 并将其传递下去(我当前的客户端就是这样做的——它不是很优雅,但效果很好)。

3) 我会鼓励 - 如果您不想要编排 - 设置自定义管道,除了您的正常操作之外,它只实现您的错误处理/监控。然后,对于非关键消息,您仍然可以使用标准管道(减少开销/延迟),对于关键消息,您可以使用“GuaranteedDeliveryPassThruPipeline”或“GuaranteedDeliveryXMLTransmitPipeline”等。

【讨论】:

  • 我已经在做你提到的 2 选项...我发现它真的不能很好地工作。我尝试将事件日志条目时间与消息框数据库中的异常时间相匹配。它通常会关闭几秒钟。然而,即使它看起来像我想要避免的,我认为你提到的第三个选项看起来是最好的。我将创建一个 POC 组件和一些管道,并让您知道它是如何工作的。感谢艾伦的帮助!
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2017-06-23
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2012-07-28
  • 2014-04-30
相关资源
最近更新 更多