BizTalk 编排水化/再水化问题答案

【问题标题】：BizTalk orchestration hydration / rehydration issueBizTalk 编排水化/再水化问题
【发布时间】：2011-12-25 01:29:18
【问题描述】：

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

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

非常感谢！

安吉

【问题讨论】：

您是否尝试使用“原子”作用域？
请发布反汇编程序的屏幕截图，以及您正在调用的 .net 库中的代码示例。
是的，水合只允许 BizTalk 序列化“空闲”编排的当前状态（例如等待相关消息、等待计时器等），以便可以将资源重新分配给更紧急的任务。您是否使用直接绑定到消息框？可能某处存在反馈循环？
nonnb，是的，我正在使用消息框中的直接绑定，基于我在自定义接收管道中提升的消息类型属性。我将尝试一个虚拟编排，只是为了接收消息并将其写出来以查看消息是否重复..
Evgeniy.. 我已经尝试了原子和长期运行范围，仍然是相同的结果。

标签： .net biztalk orchestration

【解决方案1】：

在这种情况下，我建议在管道阶段为您生成的每条新消息推广 2 个新的自定义属性 -

1) 消息总数 2) 当前消息号

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

【讨论】：

当消息以某种方式被踢回消息框时，它的消息号是否相同？
如果是同一个消息实例，那么是的。即使没有，当您尝试在编排中打印消息编号时，您会看到它没有消息编号，这意味着它是一个克隆并且肯定不是来自管道，它也可能对您有所帮助随着调查。我还建议使用性能计数器，以确保您的系统没有进入限制状态，如果是，请检查您可以做些什么来让系统以足够的资源运行并避免该状态。

【解决方案2】：

我认为您将水合作用与持久性点混淆了。字母结合一些 try\catch 逻辑可以使编排从最新的持久性点重新开始。您没有发布您的编排的完整图片，但我看到了一个范围。你那里有任何异常处理吗？

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

【讨论】：

【解决方案3】：

有趣的问题:)

当编排空闲等待某事时，就会发生水合和再水合。因此，它不应该发生在处理文件的过程中。

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

【讨论】：

我认为问题不在于补水/补液。问题可能出在消息框的直接绑定中。由于某种原因，编排将消息踢回消息框并再次从头执行。我尝试创建一条新消息并更改新消息的promoted 属性，但问题仍然存在。我不确定编排是否出于某种原因将消息退回到 MessageBox，它将退回哪条消息？原来的还是新的？