Очередь подписок Biztalk - PullRequest
1 голос
/ 12 июля 2011

У нас есть система, отправляющая сообщения HL7 в BizTalk с использованием ускорителя MLLP HL7.Затем у нас есть несколько систем получателей, которым всем нужен собственный формат сообщения HL7, поэтому мы используем оркестровки для каждого получателя, каждая из которых включает в себя свое преобразование.Каждый оркестровщик использует фильтр для подписки на порт приема.Эта модель подписки работает довольно хорошо, но что, если нам нужно остановить или отменить развертывание одной из оркестровок.Недостаток модели подписки по сравнению с моделью push-уведомлений заключается в том, что в ней нет встроенной очереди, поэтому, если оркестровка удалена, сообщения, принятые портом получения, не помещаются в очередь для этой системы.Или это проблема?Как вы справляетесь с обновлениями оркестровки и т. Д. Есть ли лучший шаблон проектирования?

1 Ответ

4 голосов
/ 12 июля 2011

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

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

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

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