在我的BizTalk 2010解决方案中,我有以下业务流程,它是通过收到快递更新消息启动的。它们通过两个请求响应端口,一个查找请求和一个更新请求,对AX的WCF AIF进行了几次调用。
对于此应用程序,我们通过使用跟踪数据库来存储邮件正文来满足审计要求。当我们使用TPE时,我们能够从BAM中提供的参考链接到此链接。客户的结果很好,他们获得了一个门户网站,他们可以从中查看消息计时的BAM数据等,但他们也可以单击链接从跟踪数据库中提取消息有效负载的副本。尽管这种方法运行良好并且利用了开箱即用的功能来进行有效负载存储,但它导致了跟踪数据库存档的相对复杂的工作(但这是另一个故事!)。
我的问题与延续有关。我创建了以下跟踪配置文件:
我已将业务流程的两个请求响应端口中的第一个与基于交换ID的延续RcvToOdx相关联,这样可行,我将以下单个记录写入已完成活动表:
因此,在这种情况下,我们可以假设在入站消息中首次写入条目,并且物理文件接收端口填充了TimeReceivedIntoBts列。然后,物理WCF发送端口填充FindRequestToAx列。因为这绑定到RcvToOdx继续Id并使用相同的交换ID和前面提到的文件接收消息,所以更新是针对相同的活动进行的。结果响应的通知也更新到相同的活动记录 - 进入FindResponseFromAx列。
我的问题是我还希望BAM记录后续UpdateRequestToAx的时间戳。因为这个请求将具有与先前消息相同的交换ID,我希望能够通过简单地将AxUpdate发送端口(它的发送和接收部分)绑定到相同的延续id来解决此问题,如下所示屏幕抓取:
我还将UpdateRequestToAx里程碑映射到物理Ax_TrackAndTraceUpdate_SendPort(发送),并将OrchestrationCompleted里程碑映射到Ax_TrackAndTraceUpdate_SendPort(接收)
不幸的是,当我尝试这个时,我得到以下结果:
从上面的数据库屏幕抓取中可以看到两个问题:
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。所以,我通过从我的业务流程中的表达式形状调用以下方法来尝试这个:
public static void EndBAMContinuation(string continuationId) { OrchestrationEventStream.EndActivity(CARRIER_ORDER_ACTIVITY_NAME,continuationId); }
我可以肯定这个方法被称为ok,因为我用CAT框架中的日志条目包装了调用,我可以在调试视图中看到:
我检查了RcvToOdx {867 ...对非关闭活动的延续ID并确认它们匹配:
这表明结束延续的请求可能是在收到来自UpdateAx呼叫的消息的里程碑之前处理的?
当我查询Relationsips表时,我得到以下结果:
有人可以告知为什么UpdateToAx活动没有完成吗?
我意识到我可以仅使用BAM API解决问题,但我真的想用尽TPE适合目的的任何可能性,因为TPE广泛用于组织的其他BizTalk解决方案。 / p>
答案 0 :(得分:2)
为了解决这个问题,我在TPE中创建了第二个延续。
“RcvToOdx”继续更新的Find和“OdxToUpdate”延续 - 源是初始接收端口上的InterchangeId - UPS_TrackAndTrace(与其他“RcvToOdx”延续相同),dest Id是映射到更新发送端口的InterchangeId