Динамическое определение конечной точки в BizTalk Send Port с использованием адаптера MQSeries

Question

Введение

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

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

Все эти приложения функционально равны, что означает, что мы проверяем входящие сообщения и пересылаем действительные сообщения в определенную очередь MQSeries. Каждое недопустимое сообщение направляется в очередь ответов. Каждое приложение имеет собственные «правильные» и «недопустимые» очереди сообщений.

План

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

До сих пор ...

я могу получить несколько сообщений о том же BizTalk получить порт (MessageType XmlDocument) и я в состоянии проверить эти сообщения динамически в оркестровке, вызвав пользовательские получить трубопровод (XML Disassembler + XML Validator). Исключения, а также действительные сообщения обрабатываются в соответствии с предписаниями. Между схемами и общим приложением нет ссылок, поэтому схемы могут быть развернуты без необходимости прекращать выполнение процессов. Все идет нормально.

Оркестрация имеет 1 форму получения и 2 посылает фигуры (действительные, недействительные).

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

Проблема

Ранее я занимался с динамическим FTP, FILE, WCF и SMTP портами, которые все работали безотказно после поставки адаптера с правильным Свойством контекста. Даже MSMQ, похоже, имеет довольно простой подход к динамической настройке транспортных свойств.

Однако я не могу найти MQSeries MQMT ContextProperties для динамического определения очереди.

Корпорация Майкрософт не предоставляет много информации о this, а обширные поисковые запросы в Интернете не предоставили мне ничего полезного (примеры).

Я пробовал сопоставить IBM's docs с Microsoft, но в целом я застрял.

Answer 1

Я бы предложил использовать адаптер MQSC для интеграции IBM MQ. Он входит в состав Host Integration Server MSI. Для этого требуется только, чтобы клиент MQ был установлен на сервере Vs MQ Server для установки Windows, требуемом адаптером MQSeries.

Установить свойство OutboundTransportLocation в следующем формате MQSC: // {ChannelName}/TCP/{Сервер {({порт})/{queuemanager}/{} ИмяОчереди

TransportType = MQSC

Контекст Свойства - Схему можно найти в сборке MQSeriesEx.MQSPropertySchemaEx с пространством имен (http://schemas.microsoft.com/BizTalk/2003/mqs-properties).

Существует только несколько свойств контекста, которые необходимо установить, если это вообще необходимо.

• Channel_HeartBeat
• Channel_MaxMessageLength
• Channel_UserId
• Channel_Password
• ConnectionTimeout

Если дополнительные свойства необходимы, чем использовать MQSeries.MQSPropertySchema свойства контекста.

Answer 2

спасибо Vikas за ваше предложение. Я следовал вашим указаниям и нашел, что это работает!

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

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

SendPort(Microsoft.XLANGs.BaseTypes.Address)="MQS://SERVER/QMANAGER/QUEUENAME";