我有一个带有直接绑定逻辑端口的业务流程。我们称之为“O1” O1订阅消息类型“A”（在接收端口的filter属性中指定）
当O1收到类型为“A”的消息时，它会在完成之前等待一些用户输入。 （这里有一些相关性）
到目前为止一直很好......
我有第二个编排，“O2”构造并将“A”类型的消息推送到消息框。
当发生这种情况时，我会启动许多O1实例。 我能想到的只是，只要存在O1的实例，消息仍然可以在消息框上供订阅者使用。所以，我将不断创建业务流程的实例。
当Orchestration正在处理消息时，它是否会保留在消息框中直到完成？
非常感谢有人可以解释发生了什么以及我缺少什么！
答案 0 :(得分：6)
当Orchestration正在处理消息时，它是否会保留在消息框中直到完成？
没有。实际上，消息在消息框中，但它被标记为活动。所以没有其他过程会使用它。也许O1正在构造一个类型为A的消息，因此它会重新激活它。
请看这篇Tips And Tricks文章：
现在为有趣的部分。 Direct-Bound端口的常见缺陷，特别是Message Box变种，正在创建一个无限循环。想象一个简单的编排只包含两个形状，一个Activate = True Receive形状（当然是直接绑定）和一个只将消息转发到FILE端口的Send形状。当这个业务流程发送消息时，它会在哪里发生？一如既往，首先到消息框。每当消息到达消息框时，BizTalk都会搜索匹配的任何订阅。这条消息与首先激活业务流程的消息有何不同？它不会，所以BizTalk很乐意启动你的业务流程的另一个实例来处理它，等等，直到你的内存不足。