BizTalk 编排水化/再水化问题
我有一个自定义的接收管道，它将一个大文件分解为单个文件并将它们发送到消息框，并且编排将订阅这些消息并处理它们。在我的编排中，我有几个执行 .net dll 中的方法的表达式形状。我还在每一步添加了日志记录。在任何给定时间，消息框都可能充满数百条消息。我注意到有些消息会执行多次。我仔细检查以确保我没有生成多条相同的消息。这让我相信这可能与水分有关。根据我的研究，当编排被水化时，它将保持其原来的形状以及 dll 的状态。当它恢复时，它将恢复其持久的形状，而不是从头开始。
有人见过这个问题吗？我可以做哪些测试/配置来验证/纠正这个问题？！
非常感谢！
安吉
I have a custom received pipeline that breaks down a large file into individual file and send them to the message box and an orchestration would subscribe to these messages and process them. In my orchestration i have several expression shapes that executes the methods in a .net dll. I also added logging at every step. At any given time, the message box might be flood with hundreds of messages. What I have noticed is that some messages are execute multiple times. I doubled checked to make sure I wasn't generating multiple message of the same. This leads me believe that maybe it has something to do with hydration. From what I researched, when an orchestration is hydrated, it will persist on the shape it was on and also the state of the dll. When it resumes, it will resume at it's persisted shape and not starting from the beginning.
Have anyone seen this problem? What test / configurations I can do to validate / correct this issue?!
Many thanks!
Angie
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为您将水分与持久点混淆了。字母结合一些try\catch逻辑可以使编排从最新的持久化点重新启动。您没有发布编排的完整图片，但我看到了一个范围。你们那里有任何异常处理吗？
无论如何，如果没有明确的发送形状，编排无法将任何消息发布到消息框。另请查看您是否安装了最新的 SP 和累积更新。
I think you confuse hydration with persistance points. Letters combined with some try\catch logic can make an orchestration to restart from the latest persistance point. You didn't post a full picture of your orchestrations, but I see there a scope. Do you have any exception handling there?
Anyway orchestration can't post any messages to message box without explicit send shape. Also look if you have latest SPs and cumulative updates installed.
有趣的问题:)
当编排空闲等待某些事情时，就会发生水化和再水化。因此，它不应该发生在处理文件的过程中。
Interesting problem :)
The hydration and rehydration occurs when the orchestration is idle waiting for something. Therefore, it should not happen in the middle of processing a file.
在这种情况下，我建议在管道阶段为您生成的每条新消息提升 2 个新的自定义属性 -
1) 消息总数
2) 当前消息编号
通过这种方式，您可以在编排开始时或您决定的任何其他阶段跟踪、打印或保存每个消息编号，这可以使工作变得更轻松。
I would suggest in such case the promotion of 2 new custom properties at the pipeline stage for each new message you generate -
1) Total number of messages
2) Current message number
This way you can keep track, print or save every single message number at the beginning of the orchestration or at any other stage you decide and it can make the work easier.