Корреляция на портах с прямой связью MessageBox

Question

У меня есть оркестровка под названием MyUsefulOrch, размещенная в приложении MySharedApp.

MyUsefulOrch имеет въездной MessageBox-прямой переплете порт для приема запросов, и после того, как делать некоторые полезные работы, исходящее MessageBox-прямым переплете порта отправить сообщение абоненту.

Теперь у меня есть другая оркестровка называется MyCallerOrch который хочет извлечь выгоду из полезной обработки предоставленной MyUsefulOrch. Однако MyCallerOrch размещен в другом приложении, MyCallingApp.

Я не хочу иметь никаких ссылок на сборку, которая содержит MyUsefulOrch из MyCallerOrch.

Моя проблема теперь убедившись, что я могу послать сообщение MyUsefulOrch от MyCallerOrch и получить ответ от него.

Аах! Корреляция должна делать трюк! Но как мне добиться корреляции с работой в этом сценарии?

Например:

• бы я поставил корреляционный идентификатор в схеме собственности и запихнуть Guid в контексте сообщения по этой собственности от MyCallerOrch как раз перед его отправкой в ​​MessageBox?
• Как убедиться, что MyCallerOrch получает только ответы, которые он должен получать от MyUsefulOrch?
• Должен ли я помещать значение идентификатора корреляции в тело сообщения сообщений, которые отправляются между двумя оркестрами?

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

Большое спасибо заранее.

Answer 1

Я думаю, что вы очень много на правильном пути

Поскольку приложения 2 собираются отправлять сообщения друг друга, если вы используете строго типизированные схемы, оба приложения должны знать о схемах. В этом случае рекомендуется отделить общие схемы от отдельной сборки и ссылаться на это из обоих приложений оркестровки. (Схемы, зарегистрированные на сервере, должны иметь уникальные URL-адреса XMLNS # даже в нескольких приложениях)

Однако, если вы действительно не можете стоять даже с ссылкой на сборку общей схемы, вам может потребоваться обращение к нетипизированным сообщениям.

Ричард Seroter есть пример here

Его статья также объясняет методику автоматического штамповочного корреляции GUID на свойства контекста.

Редактировать: Хорошая точка. Можно создавать пользовательские свойства контекста в сообщении без конвейера - см. Трюки here и here - этого было бы достаточно, чтобы отправить свойство контекста в MyUsefulOrch, и аналогичным образом пользовательский контекст мог бы продвигаться по возвращенному сообщению из MyUsefulOrch (так как MyUsefulOrch не нуждается в корреляции). Однако я не могу представить, как при возврате в MyCallingOrch свойство пользовательского контекста можно использовать для продолжения «следующей корреляции», если вы не добавите новое новое свойство корреляции в сообщение возврата.

Answer 2

Если вы используете двусторонний порт отправки запроса/ответа в оркестровке звонящего, чтобы отправлять сообщения в полезную оркестровку, вы можете использовать корреляцию, чтобы перенаправить соответствующие сообщения обратно в пользовательский орк от вызывающего.

Фокус в том, что вам нужно будет изменить полезную орху (чтобы сделать ее более полезной, конечно).

Если вы не можете/не можете контролировать, будут ли вызывающие абоненты в удобном orch ожидать ответ, тогда вам нужно будет сделать входящий (запрос) порт односторонним. Затем оркестровка завершится отправкой в ​​односторонний исходящий (ответный) порт.

Чтобы гарантировать, что сообщения, полученные от абонентов двусторонней связи/запроса-ответа, будут правильно перенаправлены, форма конструкции исходящего сообщения внутри вашего полезного орха должна будет установить следующие свойства сообщения в значение true с использованием формы назначения сообщения:

• BTS.RouteDirectToTP
• BTS.IsRequestResponse

Перед установкой этих двух свойств, однако, также не забудьте сделать что-то вроде msgOut(*) f= msgIn(*); в т он имеет ту же форму назначения сообщения, чтобы обеспечить копирование других свойств. Если входящие и исходящие сообщения не совпадают, вы должны вручную установить каждое из необходимых свойств по одному за раз.

Эти свойства, конечно, в дополнение к двум приведенным выше, помогают гарантировать, что результат полезного орха правильно направляется вызывающему. Они должны быть внутри набора корреляции и являются:

• BTS.CorrelationToken
• BTS.EpmRRCorrelationToken
• BTS.IsRequestResponse
• BTS.ReqRespTransmitPipelineID
• BTS.RouteDirectToTP

Я получаю немного впереди себя, однако , поскольку вы назначаете корреляцию, установленную для исходящих s конец форма только если BTS.EpmRRCorrelationToken exists msgIn. Это важно. Я использовал форму решения в orchcestration, с решением, основанным на этой точной фразе. Если результат верен, отправьте ранее сконфигурированное сообщение и назначьте корреляцию, установленную сверху, как набор корреляции инициализации.Это приведет к тому, что BizTalk направит сообщение обратно вызывающему абоненту в качестве ожидаемого ответа.

Если результат решения был ложным, то вызывающий элемент полезной оркестровки был односторонним. Вы все равно захотите отправить результат (и просто попросите кого-нибудь подписаться на него). Вы даже можете использовать тот же порт отправки, что и для двусторонних ответов, просто выполните команду , а не.

Вы, конечно, захотите тщательно протестировать это. Это работает для меня в одном сценарии, в котором я его использовал, но это не освобождает других от должной осмотрительности.