从架构的角度来看，通常情况下，有几种方法可以实现您想要的，并且解决方案的外观将根据您的具体场景而有很大差异。
在 BizTalk 中，跟踪由特定消息启动的流的最佳方式是交换 id。
交换 ID 是一种上下文属性，它随着传入消息的处理进行而流动，并在整个过程中从一条消息复制到另一条消息。从技术上讲，是接收到的消息的消息 id 开始了交换。
如果您需要一个 ID 将“所有内容”组合在一起，就是这样。
如果在您的场景中您可以选择将其返回给您的调用者，它将能够将它链接到您需要的任何东西（进出数据库）。
如果您不能，但调用者可以将它分配给此请求的 ID 传递给您，您可以使用交换 ID 更新数据库记录以链接两者。
随着流程的进展（成功与否），您始终可以返回并更新该记录，因为您始终可以访问 BizTalk 中的交换 ID。
真正考虑自己想要什么可能是一件好事。可能您希望发送客户/内部系统以某种方式跟踪他们的消息，但是状态是否必须由应用程序读取，还是某些用户需要消息的状态？
一种方法是，如上所述，给他们一个相关的交换 id（在响应消息中），但是然后呢？设置一个应用程序可以查询状态且易于维护的服务（关于流程更改）是非常困难的。我已经构建了一个，您可以获得有关消息传递的所有实例的信息，但这不会让您的客户“更聪明”，因为他们可能无法将您的编排或管道名称翻译成可以理解的东西。
另一种方法是使用 BAM 并创建一个网站，客户可以使用它来查找他们的消息状态，就像大多数快递公司一样，例如 DHL。它可能需要更多的努力，但我认为最好根据需要定制解决方案。
使用 BAM，您可以在完全不更改 BizTalk 项目的情况下提取数据。“只需”分析您的需求，找出要在 BAM-Excel 中提取或聚合的数据，将其导出到 BizTalk 数据库，激活并将其与跟踪配置文件编辑器连接。
然后，您可以在网站上向客户展示重要的里程碑。我知道这并不像我上面描述的那么容易，但它会很好:)
如果您向 BizTalk 发布消息，默认情况下它会返回给您 SubmissionHandle。这是您可以从接收端口获得的 Context 属性。然后可以在编排中捕获它，并用于将错误关联回原始提交。
或者，您可以使用两种方式接收 HTTP 端口并将您想要的任何内容发送回调用应用程序。您可以立即返回一条消息，也可以根据处理过程中发生的情况等待返回成功或失败。
祝你好运