.net BizTalk业务流程水合/再水合问题

我有一个自定义的接收管道，它将一个大文件分解为单个文件，并将它们发送到消息框中，编排将订阅并处理这些消息。在我的编排中，有几个表达式形状可以执行.net dll中的方法。我还在每一步都添加了日志记录。在任何给定的时间，消息框都可能充斥着数百条消息。我注意到有些消息被多次执行。我加倍检查以确保我没有生成多条相同的消息。这让我相信也许它与水合作用有关。根据我的研究，当一个编排被水合时，它将保持它原来的形状以及dll的状态。当它恢复时，它将以其保持的形状恢复，而不是从头开始

有人见过这个问题吗？我可以做哪些测试/配置来验证/纠正此问题

非常感谢

安吉（有趣的问题：）

水合作用和再水合作用发生在编排空闲等待某件事情时。因此，不应该发生在文件处理的中间。

• 为了确保这不是数据质量问题，请检查输入文件中是否没有重复数据
• 您可以使用限制功能来确保一次只处理一个文件。这将删除一个潜在的错误源
• 您可以做的另一件事是检查您的错误处理，当第一次调用失败时，您是否有重试逻辑？如果Biztalk也在进行重试，这可以解释复制的原因

---

我想你把水合作用和坚持点混淆了。字母加上一些try\catch逻辑可以使编排从最新的持久性点重新启动。您没有发布您的编排的完整图片，但我看到有一个范围。你有任何异常处理吗

---

无论如何，如果没有明确的发送形状，编排无法将任何消息发布到消息框。还要查看是否安装了最新的SP和累积更新。

在这种情况下，我建议在管道阶段为您生成的每个新邮件升级两个新的自定义属性-

1） 邮件总数 2） 当前消息号码

---

通过这种方式，您可以在编排开始时或您决定的任何其他阶段跟踪、打印或保存每个消息编号，从而使工作更轻松。

您是否尝试使用“原子”作用域？请发布反汇编程序编排的屏幕截图，以及您正在调用的.net库中的代码示例。是的，水合作用只允许BizTalk序列化“空闲”业务流程的当前状态（例如，等待相关消息、等待计时器等），以便将资源重新分配给更紧急的任务。您是否使用直接绑定到messagebox？可能在某个地方有一个反馈循环？不，是的，我正在使用messagebox的直接绑定，该绑定基于我在自定义接收管道中提升的消息类型属性。我将尝试一个虚拟编排来接收消息并写出它，看看消息是否重复..Evgeny。。我试过原子和长时间运行范围，结果仍然一样。我认为问题不在于水合作用/再水合作用。问题可能在messagebox的直接绑定中。出于某种原因，编排将消息回溯到messagebox，并从一开始就再次执行。我试图创建一条新消息，并更改新消息的升级属性，但问题仍然存在。我不确定编排是否出于某种原因将消息回退到MessageBox，它将回退哪条消息？原始的还是新的？当消息以某种方式被踢回消息框时，它是否具有相同的消息编号？如果它是消息的相同实例，则是。即使没有，当您尝试在编排中打印消息编号时，您会看到它没有消息编号，然后这意味着它是克隆，并且肯定不是来自管道，这也可能有助于您进行调查。我还建议使用性能计数器，以确保您的系统没有进入节流状态，如果进入节流状态，请检查您可以做些什么，以允许系统在具有足够资源的情况下运行并避免该状态。