编排无法捕获发送到直接绑定端口的路由失败错误 [英] Orchestration Unable to Catch Routing Failure Error on Send to Direct Bound Port

问题描述

我有一个在直接绑定端口上发送消息的业务流程。它使用Correlation来确保等待业务流程接收消息。

I have an orchestration that sends a message on a direct bound port. It uses Correlation to ensure that a waiting orchestration receives the message.

但是，如果没有等待编排（例如，它超时），则BizTalk会生成"路由故障报告"。消息（在Suspended消息下列出），但Orchestration只是处于Active状态。

However, if there is no waiting orchestration (e.g. it timed out), then BizTalk generates a "Routing Failure Report" message (listed under Suspended messages), but the Orchestration just sits there in an Active state.

没有错误写入Windows事件日志！

No error gets written to the Windows Event Log!

如果我尝试将BizTalk调试器附加到Active业务流程，BizTalk会抱怨它没有此实例的任何跟踪数据，无论我等待多长时间。

If I try an attach the BizTalk debugger to the Active orchestration, BizTalk complains that it does not have any Tracking data for this instance, no matter how long I wait.

SEND形状是在具有System.Exception处理程序的SCOPE内部，但是异常处理程序永远不会被调用，可能这不被视为异常。

The SEND shape is inside a SCOPE which has a System.Exception handler, but the Exception handler never gets called, presumably this isn't considered an exception.

问题是如何处理这种情况。 Orchestration无法判断是否存在等待相关接收等待，因此它必须盲目地发送消息。但是如果没有等待编排，那么BizTalk会失败发送，不会写出
错误（所以没有任何通知任何人有问题）并且Orchestration只是坐在那里&没人知道它在等什么！

The problem is how to deal with this scenario. The Orchestration can't tell if there is a wait Correlated Receive pending, so it has to just blindly send the message. But if there is no waiting orchestration, then BizTalk fails the send, does not write an error (so nothing to notify anyone there is a problem) and the Orchestration just sits there & nobody can tell what it is waiting for!

我现在唯一可以想到的是发送编排立即回读消息所以总有一个接收器，但仍然意味着我们不知道是否没有听众。我会尝试这个，让你知道这是否有效。

The only thing I can think of for now is for the sending orchestration to read the message back immediately so there is always one receiver, but still means we don't know if there is no listener. I'll try this and let you know if this works.

推荐答案

好吧，

添加以下相关接收克服了路由错误，因为现在总是会有业务流程本身处理消息（效率不高，但它有效）。这是一个解决方法，但我想知道是否有更好的方法来处理无与伦比的
相关消息。

adding a Following Correlated Receive overcame the Routing error since now there will always the orchestration itself processing the message (not efficient, but it works). Its a work around but I would like to know if there is a better way for handling unmatched correlated messages.

这篇关于编排无法捕获发送到直接绑定端口的路由失败错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！