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

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

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

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 в моем случае, в первой оркестровке перед отправкой в ​​порт прямого связывания, а затем во второй оркестровке я копирую значение из inputMessage в outputMessage, поэтому значение остается прежним. С помощью этого метода BizTalk знает, как соотнести ответ с вызывающим). Но я не могу понять, почему это работает и хороший ли способ решить проблему. BTS.EpmRRCorrelationToken поток выглядит следующим образом: UML

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


biztalk correlation
person javros    schedule 26.10.2011    source источник
comment
Я проверил решение еще раз и обнаружил, что мне даже не нужно копировать BTS.EpmRRCorrelationToken во второй оркестровке! Мне нужно только заполнить BTS.EpmRRCorrelationToken в 1-й оркестровке только что сгенерированным Guid. Но почему?   -  person javros    schedule 26.10.2011
comment
Не уверен, что вы читали это: bveldhoen. wordpress.com/2010/09/05/. Ради интереса, почему бы не вызвать вторую оркестровку с выходным сообщением (нормально, хотя и связанное) или просто использовать отдельные порты отправки и получения (и вашу собственную корреляцию)?   -  person StuartLC    schedule 26.10.2011
comment
Прочитал статью, спасибо. Я не хочу делать лишнюю работу по настройке корреляций. Я просто хочу, чтобы опубликованное сообщение было подобрано с оркестровкой, разработанной для типа сообщения \ контекста. Например, когда я публикую сообщение со статусом NEW, я хочу, чтобы это сообщение было получено и обработано NewMessageOrchestration, а не ProcessedMessageOrchestration или каким-либо другим.   -  person javros    schedule 26.10.2011

Ответы (1)


arrow_upward
1
arrow_downward

В вашем случае изменение этого свойства определенно нормально.

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

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

person Dmitry Golubets    schedule 16.11.2011