我有一个运行良好的 BizTalk 2006 R2 应用程序。它接收消息、处理它们并发送正确的响应。
但是，尽管一切都正确（消息被编排成功拾取并且响应发送没有错误），BizTalk 仍然会生成与响应消息相关的“消息未消费”错误......
我已经调试了应用程序的每一部分，没有错误，没有重复的消息，没有留下任何消息，什么都没有……我用谷歌搜索了这个错误，我在这个主题上找到的少数链接中的绝大多数都与僵尸有关清理脚本。这让我想知道这是否不是 BizTalk 中的常见问题......
有人知道可能导致此错误的原因吗？
是的……这是一个常见问题，大多数情况下，只要稍微改变一下解决方案的组合方式，就可以解决这个问题。
僵尸通常在使用关联和超时时发生，但不是唯一的时间。编排脱水等待对相关集的响应或超时，如果发生超时，编排继续处理通常经过等待相关响应的接收位置。现在消息框得到了响应，但不再有任何东西在等待该响应。因此你的错误。
在调用 Web 服务并等待响应时，我也看到过这种行为；但这与我处理错误的方式有关。我的流程的一个小改动解决了这个问题。
尽量减少此问题发生的方法是缩短编排在超时后所做的工作量。使僵尸出现的窗口尽可能小。
有时无法避免这种不确定的终止问题，所以我发现自己构建了一个“ZombieHandler”进程，它接收这些消息并自行清理。
如果您可以发布有关您的流程的更多信息，我们可以尝试提供更多帮助。
这听起来像僵尸。您的编排是否使用相关性和等待时间？如果是这样，你就在僵尸之地。问题是您有一个等待和一个次要读取等待查看哪个触发器首先触发。如果等待首先触发，然后有关相关性的新消息进来......僵尸。
让我们更多地了解您的编排，我们可以进一步讨论解决方案。
错误出现在 BizTalk 组面板中，而不是在事件日志中，并且是“实例已完成但未使用其所有消息。该实例及其未使用的消息已暂停。”。基本上，我有一个主编排，它通过双向端口接收消息，在初始化关联时将其发送到消息框。此编排中的下一个形状等待消息（没有任何超时逻辑）并遵循在前一个发送形状中创建的相关性。收到响应后，会将其转发回原始请求者。
这是一个非常简单的编排（截图：http: //img139.imageshack.us/img139/2307/orchestration.jpg），几乎没有逻辑。关键是我总是得到正确的响应，所以我无法弄清楚是什么触发了“消息未消耗”错误。顺便说一句，标记为未消费的消息是响应消息。
还有什么想法吗？
附言。ryancrawcour，你能详细说明你的 ZombieHandler 吗？您将此类编排绑定到哪些属性？
原始消息是否有可能被多个业务流程处理？在这种情况下，可能会在消息框中放回两条消息，以响应我们正在讨论的编排。在这种情况下，第一条消息将被关联集拾取。因为在接下来的接收中没有循环构造，所以第二条消息将无处可去——僵尸。
为什么要使用相关集？你有一个相关集的初始化接收，下面的接收在哪里？
你能退后一步解释一下相关性的要求是什么？你想在这里把什么信息联系在一起？我猜如果你从这个编排中删除相关性，它会完美地工作。
如果您想看一下，这里是相关教程的链接。
@克里斯洛里斯：
编排截图：http: //img139.imageshack.us/img139/2307/orchestration.jpg
在上面的屏幕截图中，您可以看到我有一个链接到发送/接收端口的编排。基本上，我收到一条要处理的消息，更新其上的一些属性并将其发送到消息框，同时基于特定属性初始化相关性（我们称之为 MsgIdentifier）。其他编排将获取此消息并进行真正的处理。当响应被放入具有相同 MsgIdentifier（自定义属性）的消息框时，此编排将拾取它并将其发送回原始请求者。
相关性在将请求发送到消息框的发送形状中初始化，随后的接收形状等待遵循相同相关性的响应，即在 MsgIdentifier 属性中具有相同值。
将此编排视为代理，是外部系统与 BizTalk 应用程序内部工作之间的中介。
同样，一切正常，正确的消息被毫无问题地拾取，这正是我试图分析的奇怪行为。它不应该将响应标记为未使用的消息，因为它正在被检测、使用和返回。
