在我的 BizTalk 2010 解决方案中，我有以下编排，该编排由收到快递更新消息开始。他们通过两个请求响应端口、一个查找请求和一个更新请求对 AX 的 WCF AIF 进行了几次调用。
对于这个应用程序，我们通过使用跟踪数据库来存储消息正文来满足审计要求。当我们使用 TPE 时，我们可以从 BAM 中提供的参考资料中链接到此。客户的结果很好，他们获得了一个门户网站，他们可以从中查看消息时间等的 BAM 数据，但他们也可以单击链接从跟踪数据库中提取消息有效负载的副本。尽管这很有效，并且利用了开箱即用的功能来存储有效负载，但它导致了跟踪数据库归档的相对复杂的工作（但这是另一回事！）。
我的问题与延续有关。我创建了以下跟踪配置文件：
我已根据交换 Id 将编排的两个请求响应端口中的第一个与延续 RcvToOdx 相关联，并且此方法有效，我将以下单个记录写入已完成的活动表：
因此，在这种情况下，我们可以假设在入站消息中收到一个条目时首先写入一个条目，其中 TimeReceivedIntoBts 列由物理文件接收端口填充。FindRequestToAx 列随后由物理 WCF 发送端口填充。因为这已绑定到 RcvToOdx 延续 Id 并使用相同的交换 Id 和前面提到的文件接收消息，所以对相同的活动进行了更新。结果响应的通知也更新为相同的活动记录 - FindResponseFromAx 列。
我的问题是我还希望 BAM 为后续的 UpdateRequestToAx 记录时间戳。因为此请求将具有与先前消息相同的交换 ID，所以我希望能够通过简单地将 AxUpdate 发送端口（发送和接收部分）绑定到相同的延续 ID 来解决此问题，如下所示屏幕抓取：
我还将 UpdateRequestToAx 里程碑映射到物理 Ax_TrackAndTraceUpdate_SendPort（发送），并将 OrchestrationCompleted 里程碑映射到 Ax_TrackAndTraceUpdate_SendPort（接收）
不幸的是，当我尝试这个时，我得到以下结果：
从上面的db截屏可以看出两个问题：
1. Date for the update send port was inserted into a new activity record
2. The record was never completed
我对此感到惊讶，因为我认为既然他们更新端口被征用以使用相同的延续，并且所有端口都使用单个 InterchangeId 作为延续 Id，那么所有数据里程碑都将应用于单个活动。
在寻找解决此问题的方法时，我在 Stack Overflow 上看到以下帖子，建议必须从 BAM API 关闭继续：BAM Continuation issue with TPE。因此，我通过从编排中的表达式形状调用以下方法来尝试此操作：
公共静态无效EndBAMContinuation（字符串continuationId）{OrchestrationEventStream.EndActivity（CARRIER_ORDER_ACTIVITY_NAME，continuationId）；}
我可以确定该方法调用正常，因为我使用 CAT 框架中的日志条目包装了调用，我可以在调试视图中看到该日志条目：
我检查了 RcvToOdx{867... continuation Id 与非关闭活动并确认它们匹配：
这表明在从 UpdateAx 调用接收到的消息的里程碑之前，可能正在处理结束延续的请求？
当我查询 Relationsips 表时，我得到以下结果：
谁能告诉我为什么 UpdateToAx 活动没有完成？
我意识到我可以仅使用 BAM API 解决问题，但我真的想先排除 TPE 适合用途的任何可能性，因为 TPE 广泛用于组织的其他 BizTalk 解决方案。
