我正在寻找一种方法来捕获BizTalk 2006 R2抛出的实际异常，当接收端口无法解析它拾取的消息时。
例如，我有一个未正确创建的csv文件，说它缺少一个逗号，所以当BizTalk尝试确定消息类型时，它会出错。如果不使用失败的消息路由，则应用程序事件日志中有2个条目。一个有一个非常通用的错误描述，类似于“消息传递引擎在处理一个或多个入站消息时遇到错误”。第二个条目有我正在寻找的东西。它将包含缺少逗号的位置的详细信息，类似于“在查找时发现的意外数据： '' 正在解析的当前定义是POSTrailer。发生错误的流偏移量为44443.发生错误的行号为244.发生错误的列为1.“
我尝试过使用BizTalk 2006 R2的ESB工具包异常处理程序。使用失败的消息路由及其异常处理框架，它捕获的错误描述是第一个通用的错误描述。
我认为没有办法获得第二个更详细的错误说明。我假设在biztalk消息传递引擎的某个地方，这个异常被抛出，这个过程会被更高的东西捕获，这会引发它自己的通用biztalk异常。我还假设更具体的错误描述被包含作为路由到ESB工具包的异常的内部异常，但是当我能够掌握它时，据我所知，实际的异常对象已经被消息上下文取代，消息上下文只不过是一堆名称/值对。错误描述现在是通用的，没有帮助，任何类似于内部异常的东西只是一个十字形代码，这对我的最终用户来说没有任何意义。
我发现的有关获取特定错误消息的所有内容都涉及从业务流程中抛出的异常。我不是在处理编排，但是，我正在处理一个接收端口。我能找到的最接近的是here。但即使我可以使用它创建自定义管道组件，这意味着我需要将该组件添加到每个现有的自定义pipline中，或者创建一个新组件来验证XML并使用它而不是BizTalk附带的XMLRecieve或XMLSend管道......这也意味着从EDI产生的陷阱错误是不可能的。有没有人知道如何从BizTalk生成的错误消息中获取更详细的错误描述？
答案 0 :(得分：0)
我不确定哪种工具可以完全满足您的需求，但我确实有两种选择。
1）我很确定SCOM可以抓住这些错误并提醒任何需要提醒的人。我在过去遇到过一些问题，所以这可能不是你最好的选择。
2）对于基本的故障处理，您可以编写代码来从事务日志中搜索任何来自BizTalk的警告或错误并将其传递给我（我当前的客户端执行此操作 - 它不是超级优雅，但它运行良好）。 / p>
3）如果您不想要编排，我会鼓励设置自定义管道，除了正常操作外，还可以简单地实现错误处理/监控。然后，对于非关键消息，您仍然可以使用标准管道（减少开销/延迟），对于关键消息，您可以使用“GuaranteedDeliveryPassThruPipeline”或“GuaranteedDeliveryXMLTransmitPipeline”或其他任何内容。