1

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

我们的愿望：当我们将进度记录到 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，并继续将该值传递给所有架构和以后的编排。这似乎需要做很多工作，并且需要我们修改所有模式——这似乎是错误的。

我们甚至应该想要拥有这样的身份证吗？还有其他想到的解决方案吗？

4

5 回答 5

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/

于 2011-10-05T16:04:41.100 回答
1

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

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

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

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

于 2011-10-05T16:14:36.920 回答
1

看看 BAM。它旨在完全按照您的描述进行：使用业务活动监控

这本书有一个关于 BAM 的非常好的章节，而且本书的作者之一使用的这个工具可以帮助你开发你的 BAM 解决方案。最后，一张漂亮的BAM 海报。

不要被最初的复杂性所推迟。当您了解它时，BAM 就是 BizTalk 最酷的功能之一。

希望这可以帮助。祝你好运。

于 2011-10-05T20:17:22.460 回答
1

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

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

于 2011-10-06T14:13:28.607 回答
1

Biztalk assigns various values in the message context that usually persist for the life of the processing of that message. Such as the initial MessageId. Will that work for you?

In our application we have to use an externally provided ID (from the customer). We have a multi-part message with this id in part of it. You might consider that as well

于 2011-10-06T18:41:11.640 回答