我们的程序到目前为止：我们的流程涉及多个架构，编排和发送/接收的消息。
我们的愿望：当我们将进度记录到SQL服务器表中时，要有一个将整个过程链接在一起的ID。
到目前为止，我们有一个记录我们进度的表，但是当有多个消息时，很难阅读，因为Biztalk有时会处理某些不按顺序的消息。
例如，我们可以：
1 Beginning process for client1 2 Second item for client1 3 Third item for client1 4 Final item for client1
如果一次只更新一个客户端，则轻松跟踪。另一方面，这将更有可能：
1 Beginning process for client1 2 Beginning process for client2 3 Second item for client2 4 Third item for client2 5 Second item for client1 6 Third item for client1 7 Final item for client1 8 Final item for client2
在整个事情中拥有一个ID会很好，以便最后一个列表可以通过此ID字段排序。
最好和/或最快的方法是什么？我们曾想过从第一个业务流程触发的最初时刻开始添加一个ID，并将该值传递给所有架构和后来的编排。这似乎是很多工作，需要我们修改所有的架构 - 这似乎是错误的。
我们是否应该想要这样的身份证？想到的任何其他解决方案？
答案 0 :(得分：1)
这可能不是最简单的方法，但你看过这个：
基本上它是一个仪器框架，允许您从管道，地图，orch等事件中出来。
当您写出事件跟踪时，您可以使用“业务密钥”，它将多个事件绑定在一个链中，类似于您所说的。
答案 1 :(得分：1)
我不确定我是否完全了解您具体设置的所有细节，但请注意：
如果您可以将来自同一客户端的消息关联到“长时间运行”业务流程（等待来自同一客户端的后续消息），则业务流程将具有自动分配的ServiceId Guid，该指南将保留在整个业务流程中
正如您所说，出于关联目的，您通常会尝试在现有传入消息模式中使用自然键将后续消息关联回正在运行的业务流程 - 这样您就不需要更改模式。在您的示例中，如果同一客户端无法同时发送多个消息“集合”，则ClientId可能是良好的关联。 （最糟糕的情况是，如果您确实向模式添加了新的关联密钥，则需要将业务流程中涉及的所有系统更改为“记住”此密钥并将其返回给您。）同样，假设ClientId为关联密钥，在您的示例中，2个业务流程将同时运行 - 一个用于客户端1，另一个用于客户端2
但是，出于可伸缩性和版本控制的原因，通常要避免（非常）长时间运行的编排，除非它们是绝对必要的（例如，除非您只能在收到所有4个客户端消息后才触发进程）。如果您决定将每条消息作为单独的业务流程保留，或者只是在端口上进行映射和过滤，那么另一种“跟踪”集合的方法是使用BAM - 您可以使用延续将所有客户端消息重新绑定在一起，例如：为了报告等目的。
答案 2 :(得分：1)
看看BAM。它的设计完全符合您的描述：Using Business Activity Monitoring
This book有一个关于BAM的非常好的章节，本书的作者之一this tool可以帮助您开发BAM解决方案。最后，一个不错的BAM Poster。
不要被最初的复杂性推迟。当你了解它时，BAM它是BizTalk最酷的功能之一。
希望这会有所帮助。祝你好运。
答案 3 :(得分：1)
您可以创建一个UniqueId和StepId，并在消息上下文中传递它们。当客户端的新进程开始时，将UniqueId设置为Guid，将StepId设置为1.当它传递给下一个进程时，将StepId递增。
这将允许您查询事件，按客户端ID和事件发生的顺序（stepId）分组。
答案 4 :(得分：1)
Biztalk在消息上下文中分配各种值，这些值通常在处理该消息的过程中持续存在。比如最初的MessageId。这对你有用吗？
在我们的应用程序中，我们必须使用外部提供的ID（来自客户）。我们有一个多部分消息，其中包含此ID。您也可以考虑这一点