BizTalk 中的僵尸
我有一个运行良好的 BizTalk 2006 R2 应用程序。 它接收消息、处理消息并发送正确的响应。
但是，尽管一切都是正确的（编排成功拾取消息并且发送响应没有错误），BizTalk 仍然生成与响应消息相关的“消息未使用”错误...
我已经调试了每一个位应用程序没有错误，没有重复的消息，没有留下任何消息，什么都没有...我用谷歌搜索了该错误，我发现的关于该主题的少数链接中的绝大多数都与僵尸清理脚本有关。 这让我想知道这是否不是 BizTalk 中的常见问题...
有人知道可能导致此错误的原因吗？
I have a BizTalk 2006 R2 application that works perfectly.
It receives the messages, processes them and sends correct responses.
But although the everything is correct (the messages are successfully picked up by the orchestrations and the response is sent without errors), BizTalk still generates a "Message not consumed" error related to the response message...
I've debugged every bit of the application and there is no error, no duplicated message, no message left behind, nothing... I googled the error and the vast majority of the few links that I find on the subject are related to zombie clean up scripts. This makes me wonder if this is not a common issue in BizTalk...
Does anybody have any idea on what may be causing this error?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
是的......这是一个常见问题，大多数时候可以通过稍微改变解决方案的组合方式来克服。
僵尸通常在使用相关性和超时时发生，但不是唯一一次。
编排等待对相关集的响应或超时，如果发生超时，编排通常会继续处理等待相关响应的接收位置。 现在消息框收到响应，但不再有任何内容等待该响应。 因此你的错误。
我在调用 Web 服务并等待响应时也看到过这种行为； 但这与我处理错误的方式有关。 对我的流程进行一个小小的改变就解决了这个问题。
最大限度地减少此问题发生的方法是缩短超时后编排的工作量。 使僵尸出现的窗口尽可能小。
有时无法避免这种不确定性终止问题，因此我发现自己构建了一个“ZombieHandler”进程，该进程接收这些消息并自行清理。
如果您可以发布有关您的流程的更多信息，我们可以尝试提供更多帮助。
Yeah ... this is a common issue which can most of the time be overcome by a slight change in the way your solution is put together.
Zombies usually occur when using correlations and time-outs, but not the only time.
The orchestration is dehydrated waiting for either a response to the correlation set or the time-out, if the time-out occurs the orchestration proceeds to process usuall past the receive location waiting for the correlated response. Now the message box gets the response but there is no longer anything waiting for that response. Hence your error.
I've also seen this behavior when calling a web service and waiting for a response; but this had to do with how I was handling errors. A small change to my process resolved that problem.
Ways to minimise the occurance of this problem is to shorten the amount of work the orchestration does after the time-out. Make the window for Zombies to occur as small as possible.
Sometimes it is not possible to avoid this non-deterministic termination issue so I've found myself building a "ZombieHandler" process which receives these messages and cleans up after itself.
If you could post more information about your process we could try assist some more.
这听起来像僵尸。 您的编排是否使用关联性和等待时间？ 如果是这样，那么你就在僵尸之地了。 问题是您需要等待和辅助读取，以查看哪个先触发。 如果首先触发等待，然后出现有关相关性的新消息……僵尸。
让我们更多地了解您的编排，我们可以进一步讨论解决方案。
This sounds like a zombie. Does your orchestration use correlation and a wait time? If so, you're in Zombie Land. The issue is that you have a wait and a seocndary read waiting to see which triggers first. If the wait triggers first and then a new message on the correlation comes in... Zombie.
Let us know more about your orchestration and we can further discuss a solution.
该错误位于 BizTalk 组面板中，而不是事件日志中，并且是“实例已完成，但未消耗其所有消息。该实例及其未消耗的消息已被挂起。”。 基本上，我有一个主要的编排，它通过双向端口接收消息，在初始化关联时将其发送到消息框。 此编排中的下一个形状等待消息（没有任何超时逻辑）并遵循前一个发送形状中创建的相关性。 收到响应后，会将其转发回原始请求者。
这是一个非常简单的编排（屏幕截图：http://img139.imageshack.us/img139 /2307/orchestration.jpg）几乎没有逻辑。 关键是我总是得到正确的响应，所以我无法弄清楚是什么触发了“消息未消耗”错误。 顺便说一句，标记为未消费的消息是响应消息。
还有其他想法吗？
诗。 ryancrawcour，您能详细说明一下您的 ZombieHandler 吗？ 您将此类编排绑定到哪些属性？
The error is in the BizTalk group panel and not in the event log and is "The instance completed without consuming all of its messages. The instance and its unconsumed messages have been suspended.". Basically, I have a main orchestration that receives a message through a two way port, sends it to the message box while initializing a correlation. The next shape in this orchestration waits for a message (without any timeout logic) and follows the correlation created in the previous send shape. When a response is received it is forwarded back to the original requester.
It is a very simple orchestration (screenshot: http://img139.imageshack.us/img139/2307/orchestration.jpg) with almost no logic. The point is that i'm getting correct responses always, so I cannot figure out what is triggering the "message not consumed" error. By the way, the message flagged as not consumed is the response message.
Any further ideas?
Ps. ryancrawcour, can you elaborate on your ZombieHandler? To which properties do you bind such orchestration?
为什么要使用相关集？ 您有一个相关集的初始化接收，以下接收在哪里？
您能否退后一步解释一下相关性的要求是什么？ 您想在这里将哪些信息联系在一起？ 我猜如果你从这个编排中删除相关性，它就会完美地工作。
如果您愿意，这里有链接到相关教程去看一看。
Why are you using a correlation set? You have an initializing receive for the correlation set, where is the following receive?
Can you take a step back and explain what is the requirement for correlation? What messages are you trying to tie togeather here? I am guessing if you remove correlation from this orchestration, it will work perfectly.
Here's a link to correlation Tutorial if you want to take a look.
@ChrisLoris：
编排的屏幕截图： http://img139.imageshack.us/img139/ 2307/orchestration.jpg
在上面的屏幕截图中，您可以看到我有一个链接到发送/接收端口的编排。 基本上，我正在获取一条要处理的消息，更新其上的一些属性并将其发送到消息框，同时根据特定属性初始化相关性（我们称之为 MsgIdentifier）。 其他编排将获取此消息并进行真正的处理。 当使用相同的 MsgIdentifier（自定义属性）将响应放入消息框中时，此编排会拾取该响应并将其发送回原始请求者。
相关性在将请求发送到消息框的发送形状中初始化，随后的接收形状等待遵循相同相关性的响应，即在 MsgIdentifier 属性中具有相同值的响应。
将此编排视为一个代理，一个外部系统与 BizTalk 应用程序内部运作之间的中介。
同样，一切都工作正常，并且正确的消息被毫无问题地接收，这正是我正在尝试分析的奇怪行为。 它不应该将响应标记为未使用的消息，因为它已被检测、使用和返回。
@ChrisLoris:
Screenshot of the orchestration: http://img139.imageshack.us/img139/2307/orchestration.jpg
In the screenshot above you can see that I have an orchestration linked to a send/receive port. Basically i'm getting a message to process, update a few attributes on it and send it to the message box while initializing a correlation based on a specific property (lets call it MsgIdentifier). Other orchestrations will pickup this message and do the real processing. When a response is dropped into the message box with the same MsgIdentifier (custom property) this orchestration picks it up and sends it back to the original requester.
The correlation is initialized in the send shape that sends the request to the message box and the following receive shape waits for a response that follows the same correlation, i.e. that has the same value in the MsgIdentifier property.
Think of this orchestration as a broker, an intermediary between the external system and the inner workings of the BizTalk application.
Again, all is working properly and the correct messages are being picked up without any problems and that is the exact strange behavior that I'm trying to analyse. It shouldn't mark the response as a message not being consumed, because its being detected, consumed and returned.
原始消息是否有可能由多个编排处理？ 在这种情况下，可能有两条消息被放回到消息框中，以响应我们正在讨论的编排。 在这种情况下，第一条消息将被关联集选取。 因为接下来的接收没有循环结构，所以第二条消息将无处可去——僵尸。
Are there any chances that the original message is being processed by multiple orchestrations? In this case, there may be two messages put back into the message box for a response to the orchestration we are discussing. In this case, the first message would be picked up by the corrleation set. because there is no looping construct on the following receive, the second message would have no where to go - Zombie.