Исключение в BizTalk с двухсторонним портом получения прямой привязки

Question

У меня та же проблема, что и описанная здесь :

Я использую две оркестровки.Первая оркестровка вызывает вторую, используя прямое связывание через двусторонний порт отправки.Второй оркестр имеет двусторонний порт приема для отправки результата обратно первому.Все работает как надо, но я получаю следующее исключение.

A response message for two-way receive port "Unknown " is being suspended as the messaging engine could not correlate the response to an existing request message. This usually happens when the host process has been recycled.

И предлагаемое решение также работает ( установите значение BTS.EpmRRCorrelationTokenк случайному значению, новый GUID в моем случае, в первой оркестрации перед отправкой в ​​порт прямой привязки, а затем в оркестровке secod я копирую значение из inputMessage в outputMessage, поэтому значение остается тем же.знает, как соотнести ответ обратно с абонентом ).Но я не могу понять, почему это работает, и если это хороший способ решить проблему.Поток BTS.EpmRRCorrelationToken выглядит следующим образом:

Когда я не изменяю свойство BTS.EpmRRCorrelationToken, оно одинаково во всех сообщениях, которые передаются в процессе, но почему на Земле это не такВместо этого BizTalk изменит его, если он не сможет правильно соотнести сообщения?

Answer 1

Изменение этого свойства, безусловно, нормально в вашем случае.

Проблема в прямой привязке.Когда вы используете его, вы на самом деле идете более «низкоуровневым» способом и должны иметь дело с тем, как работает механизм публикации-подписки BTS.

Порт отправки-получения подписывается на получение сообщения с определенным BTS.EpmRRCorrelationToken.Таким образом, когда вы снова публикуете сообщение о получении в окне сообщений (для второго сервера), порт получения также захватывает его и отписывается.Когда вы наконец попытаетесь отправить ответ - никто не ждет его.Поэтому вы должны изменять это свойство, пока не отправите ответ обратно в порт.