BizTalk TPE продолжения и незавершенные действия

Question

В моем решении BizTalk 2010 у меня есть следующая оркестровка, которая начинается с получения сообщения обновления курьера. Он делает пару звонков в AX WCF AIF через два порта запроса-ответа, запрос на поиск и запрос на обновление.

Для этого приложения мы выполняем требования аудита путем использования базы данных отслеживания для хранения тела сообщения. Мы можем ссылаться на это из ссылок, предоставленных в BAM, когда мы используем TPE. Результат для клиента хороший, он получает веб-портал, с которого он может просматривать данные BAM о времени сообщения и т. Д., Но он также может щелкнуть ссылку, чтобы получить копию полезных данных сообщения из базы данных отслеживания. Хотя это работает хорошо и использует готовые функциональные возможности для хранения полезной нагрузки, это привело к относительно сложным заданиям по архивированию отслеживающей базы данных (но это другая история!).

Моя проблема связана с продолжением. Я создал следующий профиль отслеживания:

Я связал первый из двух портов запроса ответа оркестровки с продолжением RcvToOdx на основе идентификатора обмена, и это работает, я получаю следующую единственную запись, записанную в таблицу завершенных действий:

Таким образом, в этом случае мы можем предположить, что запись была сначала записана при получении во входящем сообщении со столбцом TimeReceivedIntoBts, заполненным физическим портом приема файла. Столбец FindRequestToAx был затем заполнен физическим портом отправки WCF. Поскольку это было связано с идентификатором продолжения RcvToOdx и использовало тот же идентификатор обмена и ранее упомянутое сообщение о получении файла, было выполнено обновление для той же операции. Уведомление о полученном ответе также было обновлено до той же записи активности - в столбце FindResponseFromAx.

Моя проблема в том, что я также хотел бы, чтобы BAM записал временную метку для последующего UpdateRequestToAx. Поскольку этот запрос будет иметь тот же Id обмена, что и предыдущие сообщения, я ожидал, что смогу решить эту проблему, просто привязав порт отправки AxUpdate (его части отправки и получения) к одному и тому же идентификатору продолжения, как показано в следующем захват экрана:

Я также сопоставляю этап обновления 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 использовался всеми портами для идентификатора продолжения, тогда все этапы данных будут применены к одному действию.

В поисках решения этой проблемы я наткнулся на следующую статью о переполнении стека, в которой предлагалось закрыть продолжение из BAM API: проблема продолжения BAM с TPE. Итак, я попробовал это, вызвав следующий метод из формы выражения в моей оркестровке:

public static void EndBAMContinuation (string continueationId) { OrchestrationEventStream.EndActivity(CARRIER_ORDER_ACTIVITY_NAME, continueationId); }

Я могу быть уверен, что метод был вызван нормально, потому что я обернул вызов записью в журнале из среды CAT, которую я мог видеть в режиме отладки:

Я проверил RcvToOdx{867... Id продолжения против незамкнутой активности и подтвердил, что они совпадают:

Это может означать, что, возможно, запрос на завершение продолжения обрабатывается до вехи полученного сообщения от вызова UpdateAx?

Когда я запрашиваю таблицы Relationsips, я получаю следующие результаты:

Может ли кто-нибудь сообщить, почему действие UpdateToAx не завершается?

Я понимаю, что могу решить проблему, используя только API BAM, но я действительно хочу исчерпать любую возможность того, что TPE будет в первую очередь пригоден для этой цели, поскольку TPE широко используется в других решениях BizTalk организации.

Answer 1

Чтобы решить эту проблему, я создал 2-е продолжение в TPE.

Продолжение "RcvToOdx" для продолжения Find и "OdxToUpdate" для обновления - источником является InterchangeId на начальном порте приема - UPS_TrackAndTrace (то же, что и для другого продолжения "RcvToOdx"), dest Id - это InterchangeId, сопоставленный для обновления порта отправки.