Корреляция в MessageBox с прямыми связанными портами

Question

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

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

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

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

Теперь моя проблема заключается в том, чтобы я мог отправить сообщение MyUsefulOrch с MyCallerOrch и получить от него ответ.

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

Например:

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

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

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

Answer 1

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

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

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

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

• BTS.RouteDirectToTP
• BTS.IsRequestResponse

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

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

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

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

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

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

Answer 2

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

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

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

У Ричарда Серотера есть пример здесь

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

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