BizTalk TPE继续和未完成的活动

在我的BizTalk 2010解决方案中，我有以下业务流程，该业务流程是在收到courier更新消息后启动的。它通过两个请求响应端口（一个查找请求和一个更新请求）对AX的WCF AIF进行两次调用

对于这个应用程序，我们通过使用跟踪数据库来存储消息体来满足审计要求。当我们使用TPE时，我们能够从BAM中提供的参考链接到这一点。对客户来说，结果很好，他们获得了一个门户网站，可以从中查看消息计时等BAM数据。但他们也可以单击链接从跟踪数据库中调出消息有效负载的副本。尽管这很好地工作，并且在有效负载存储中使用了开箱即用的功能，但它为跟踪数据库的归档带来了相对复杂的工作（但这是另一回事！）

我的问题与继续有关。我已创建以下跟踪配置文件：

我已根据交换Id将业务流程的两个请求响应端口中的第一个与延续RcvToOdx关联，并且这起作用，我将以下单个记录写入已完成的活动表：

因此，在这种情况下，我们可以假设一个条目是在收到入站消息时首先写入的，TimeReceivedIntoBts列由物理文件接收端口填充。FindRequestToAx列随后由物理WCF发送端口填充。因为它绑定到RcvToOdx延续Id，并使用相同的交换Id和前面提到的文件接收消息，所以对相同的活动进行了更新。结果响应的通知也被更新到相同的活动记录中，即FindResponseFromAx列中

我的问题是，我还希望BAM为后续的UpdateRequestToAx记录一个时间戳。由于此请求将与以前的消息具有相同的交换Id，因此我希望能够通过简单地将AxUpdate发送端口（发送和接收部分）绑定到相同的延续Id来解决此问题，如以下屏幕抓图所示：

1. Date for the update send port was inserted into a new activity record 
2. The record was never completed

我还将UpdateRequestToAx里程碑映射到物理Ax_Track和TraceUpdate_发送端口（Send），并将OrchestrationCompleted里程碑映射到Ax_Track和TraceUpdate_发送端口（Receive）

不幸的是，当我尝试此方法时，我得到以下结果：

从上面的db屏幕抓取可以看出两个问题：

1. Date for the update send port was inserted into a new activity record 
2. The record was never completed

我对此感到惊讶，因为我认为既然他们的更新端口被登记为使用相同的延续，并且所有端口都使用单一的InterchangeId作为延续Id，那么所有的数据里程碑都将应用于单个活动

在寻找此问题的解决方案时，我遇到了以下关于堆栈溢出的帖子，建议必须从BAM API关闭延续：。因此，我尝试从编排中的表达式形状调用以下方法：

公共静态void EndBAMContinuation（字符串continuationId） { OrchestrationEventStream.EndActivity（承运商\订单\活动\名称，continuationId）； }

我可以确定该方法被调用为ok，因为我使用CAT框架中的日志条目包装了调用，我可以在调试视图中看到：

我检查了RcvToOdx{867…延续Id与非关闭活动，并确认它们匹配：

这意味着结束继续的请求可能在从UpdateAx调用接收到的消息的里程碑之前被处理

查询Relationsips表时，我得到以下结果：

有人能告诉我为什么UpdateToAx活动没有完成吗

---

我意识到我可能只使用BAM API就可以解决这个问题，但我真的想先排除TPE适合用途的可能性，因为TPE在组织的其他BizTalk解决方案中被广泛使用。

为了解决这个问题，我在TPE中创建了第二个延续

查找的“RcvToOdx”延续和更新的“ODXToopDate”延续-源在初始接收端口-UPS_TrackAndTrace上互换Id（与其他“RcvToOdx”延续相同），dest Id是映射到更新发送端口的互换Id