BizTalk中的僵尸

Question

我有一个完美运行的BizTalk 2006 R2应用程序。 它接收消息，处理消息并发送正确的响应。

但是虽然一切都是正确的（业务流程成功获取消息并且响应发送没有错误），BizTalk仍会生成与响应消息相关的“消息未消耗”错误...

我已经调试了应用程序的每一位，没有错误，没有重复的消息，没有留下任何消息，没有...我搜索了错误，我在这个主题上发现的绝大多数链接都是与僵尸清理脚本有关。这让我想知道这不是BizTalk中的常见问题......

有没有人知道可能导致此错误的原因？

Answer 1

是的......这是一个常见问题，大多数时候可以通过稍微改变解决方案的方式来克服这个问题。

僵尸通常在使用相关和超时时发生，但不是唯一的时间。 业务流程脱水等待对相关集的响应或超时，如果发生超时，则编排继续处理通过等待相关响应的接收位置。现在消息框获得响应，但不再有任何东西等待响应。因此你的错误。

我在调用Web服务并等待响应时也看到过这种行为;但这与我处理错误的方式有关。对我的流程进行了一些小改动，解决了这个问题。

最小化此问题发生的方法是缩短编排在超时后所做的工作量。让僵尸的窗口尽可能小。

有时候不可能避免这种非确定性的终止问题，所以我发现自己构建了一个“ZombieHandler”进程，它接收这些消息并自行清理。

如果您可以发布有关您的流程的更多信息，我们可以尝试提供更多帮助。

Answer 2

这听起来像一个僵尸。您的业​​务流程是否使用相关性和等待时间？如果是这样，你就在Zombie Land。问题是你有一个等待和seocndary读取等待先查看哪个触发器。如果等待首先触发，然后关于相关性的新消息进入...... Zombie。

让我们更多地了解您的编排，我们可以进一步讨论解决方案。

Answer 3

错误发生在BizTalk组面板中，而不是在事件日志中，并且“实例已完成而未消耗所有消息。实例及其未使用的消息已被暂停。”基本上，我有一个主编排通过双向端口接收消息，在初始化相关时将其发送到消息框。此业务流程中的下一个形状等待消息（没有任何超时逻辑）并遵循在先前发送形状中创建的相关性。收到响应后，它将被转发回原始请求者。

这是一个非常简单的编排（截图：http://img139.imageshack.us/img139/2307/orchestration.jpg），几乎没有逻辑。关键是我总是得到正确的答案，所以我无法弄清楚触发“消息未消耗”错误的原因。顺便说一下，标记为未消费的消息是响应消息。

还有其他想法吗？

聚苯乙烯。 ryancrawcour，你能详细说明你的ZombieHandler吗？您将哪些属性绑定到这样的业务流程？

Answer 4

为什么使用相关集？您有相关集的初始化接收，以下是接收？

你能退后一步，解释相关的要求是什么？你试图把这些东西绑在这里的消息是什么？我猜你是否从这个业务流程中删除相关性，它将完美地工作。

如果你想看一下，这是一个link相关教程。

Answer 5

@ChrisLoris：

业务流程的屏幕截图：http://img139.imageshack.us/img139/2307/orchestration.jpg

在上面的屏幕截图中，您可以看到我有一个链接到发送/接收端口的业务流程。基本上我正在处理消息，更新它上面的一些属性并将其发送到消息框，同时根据特定属性初始化相关（让我们称之为MsgIdentifier）。其他业务流程将接收此消息并进行实际处理。当响应被放入具有相同MsgIdentifier（自定义属性）的消息框中时，此业务流程会将其选中并将其发送回原始请求者。

在发送形状中初始化相关性，将发送请求发送到消息框，并且后续接收形状等待遵循相同相关性的响应，即在MsgIdentifier属性中具有相同值的响应。

将此业务流程视为代理，外部系统与BizTalk应用程序内部工作之间的中介。

同样，一切正常，正确的消息正在被接收而没有任何问题，这是我正在尝试分析的确切奇怪的行为。它不应该将响应标记为未被消耗的消息，因为它被检测，消费和返回。

Answer 6

多个业务流程是否有可能处理原始邮件？在这种情况下，可能会有两条消息放回到消息框中，以响应我们正在讨论的业务流程。在这种情况下，第一条消息将由corrleation集合拾取。因为在接下来的接收中没有循环结构，第二条消息将无处可去 - Zombie。