在 Biztalk 中处理消息的整个过程中创建/使用 ID 的最佳方式是什么？

Question

到目前为止我们的计划：我们有一个涉及多个模式、编排和发送/接收的消息的过程。

我们的愿望：当我们将进度记录到 SQL 服务器表中时，拥有一个将整个过程链接在一起的 ID。

到目前为止，我们有一个记录我们进度的表格，但是当有多个消息时，很难阅读，因为 Biztalk 有时会无序地处理某些消息。

例如，我们可以：

1 客户1的开始流程 2 客户 1 的第二项 3 客户 1 的第三项 4 客户 1 的最终项目

如果一次只更新一个客户端，则很容易跟进。另一方面，这更有可能：

1 客户1的开始流程 2 客户端2的开始过程 3 客户 2 的第二项 4 客户 2 的第三项 5 客户 1 的第二项 6 客户 1 的第三项 7 客户 1 的最终项目 8 客户2的最终项目

最好在整个过程中都有一个 ID，以便最后一个列表可以按此 ID 字段排序。

最好和/或最快的方法是什么？我们曾考虑从第一个编排触发的初始时刻添加一个我们将创建的 ID，并继续将该值传递给所有架构和以后的编排。这似乎需要做很多工作，并且需要我们修改所有模式 - 这似乎是错误的。

我们甚至应该想要拥有这样一个 ID 吗？想到其他解决方案了吗？

Answer 1

这可能不是最简单的方法，但你看过这个：

http://blogs.msdn.com/b/appfabriccat/archive/2010/08/30/biztalk-application-tracing-made-easy-with-biztalk-cat-instrumentation-framework-controller.aspx

基本上，它是一个检测框架，允许您从管道、地图、管弦等中进行事件处理。

当您写出事件跟踪时，您可以使用“业务密钥”，它将多个事件绑定在一个链中，类似于您所说的。

这里有 http://btscatifcontroller.codeplex.com/

Answer 2

我不确定我是否完全了解您的特定设置的所有细节，但这里是：

如果您可以将来自同一客户端的消息关联到“长时间运行”的编排（等待来自同一客户端的后续消息），那么编排将具有自动分配的 ServiceId Guid，该 Guid 将在整个编排过程中保留.

正如您所说，出于关联目的，您通常会尝试使用现有传入消息架构中的自然键来将后续消息关联回正在运行的编排 - 这样您就不需要更改架构。在您的示例中，ClientId 可能是一个很好的相关性，前提是同一个客户端不能同时发送多个消息“集”。 （最坏的情况是，如果您确实向模式添加了新的关联键，则需要更改编排中涉及的所有系统以“记住”该键并将其返回给您。）再次假设 ClientId 作为关联键，在您的示例中，将同时运行 2 个编排 - 一个用于客户端 1，一个用于客户端 2

但是，出于可扩展性和版本控制的原因，通常应避免（非常）长时间运行的编排，除非它们是绝对必要的（例如，除非您只能在收到所有 4 条客户端消息后触发进程）。如果您决定将每条消息作为单独的编排或仅在端口上映射和过滤，则“跟踪”集合的另一种方法是使用 BAM - 您可以使用延续将所有客户端消息重新绑定在一起，例如用于报告等目的。

Answer 3

看看 BAM。它旨在完全按照您的描述进行：Using Business Activity Monitoring

This book 有一个很好的关于 BAM 的章节，而本书的作者之一 this tool 可以帮助您开发 BAM 解决方案。最后，一个不错的BAM Poster。

不要因最初的复杂性而退缩。当您了解它时，BAM 就是 BizTalk 最酷的功能之一。

希望这会有所帮助。祝你好运。

Answer 4

Biztalk 在消息上下文中分配各种值，这些值通常会在消息处理的整个生命周期内持续存在。比如初始的MessageId。这对你有用吗？

在我们的应用程序中，我们必须使用外部提供的 ID（来自客户）。我们有一个包含这个 id 的多部分消息。你也可以考虑一下

Answer 5

您可以创建一个 UniqueId 和 StepId 并在消息上下文中传递它们。当客户端的新进程启动时，将 UniqueId 设置为 Guid，将 StepId 设置为 1。当它传递到下一个进程时，递增 StepId。

这将允许您查询事件，按客户端 ID 和事件发生的顺序 (stepId) 分组。