Создание настраиваемого адаптера SOAP для BizTalk ESB Toolkit 2.0

Использование BizTalk ESB Toolkit 2.0

Мы работаем над проектом, в котором нам нужно вызвать прокси-сервер для веб-службы, которая представляет собой DLL. У нас нет проблем с этим через оркестровку, поскольку вы можете использовать статический порт и настроить его для использования адаптера SOAP с настройкой веб-службы, указывающей на сборку в интерфейсе администратора BizTalk. Хотя в маршруте нет очевидного способа сделать это, поскольку динамические порты не имеют возможности использовать адаптер SOAP.

Не волнуйтесь, есть веская причина, по которой мы хотим это сделать.

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

Мы последовали (старому) примеру, показанному здесь:

Пользовательский поставщик адаптера наследуется от BaseAdapterProvider и переопределяет метод SetEndPoint (Dictionary, IBaseMessageContext).

Метод извлекает имя сборки, имя типа и имя метода, которые передаются через словарь преобразователя, а затем записывает их в контекст конвейера:

pipelineContext.Write("TypeName", 
    "http://schemas.microsoft.com/BizTalk/2003/soap-properties", typeName);
pipelineContext.Write("MethodName", 
   "http://schemas.microsoft.com/BizTalk/2003/soap-properties", action);
pipelineContext.Write("AssemblyName", 
    "http://schemas.microsoft.com/BizTalk/2003/soap-properties", assembly);

и устанавливает тип транспорта мыло:

pipelineContext.Write("TransportType",
    "http://schemas.microsoft.biztalk.practices.esb.com/itinerary", "SOAP");

Во всех других отношениях поставщик адаптера почти идентичен примеру, показанному в приведенной выше ссылке, за исключением очевидного изменения с SMTP на SOAP.

Сборка поставщика адаптера подписывается, GACed и добавляется в esb.config.

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

Подсистеме обмена сообщениями не удалось обработать сообщение, отправленное адаптером: URL-адрес источника SOAP: /ESB.ItineraryServices.Response/ProcessItinerary.asmx. Подробности: опубликованное сообщение не может быть маршрутизировано, потому что не найдены подписчики. Эта ошибка возникает, если подписывающаяся оркестровка или порт отправки не были включены в список, или если некоторые свойства сообщения, необходимые для оценки подписки, не были повышены. Используйте консоль администрирования Biztalk для устранения этой ошибки.

Исследование приостановленных экземпляров службы в обзоре группы показывает две вещи: значения для имени сборки, имени типа и имени метода установлены правильно. Тело сообщения отсутствует. Мы пробовали настроить конвейеры отправки и получения на порту отправки как XMLTransmit / XMLReceive и ItinerarySendPassthrough / PassthroughReceive, и это не имеет никакого значения.

Есть ли что-то очевидное, что мы могли упустить? Вы должны явно передать тело сообщения? Если да, то как?

РЕДАКТИРОВАТЬ:

После запрос с форума BizTalk ESB Toolkit Я публикую снимки экрана с маршрутом, контекстом и фильтрами портов отправки.

Маршрут, Контекст, Фильтры портов.

Большое спасибо, Найджел.


biztalk esb esb-toolkit-2.0
person Nigel    schedule 24.07.2009    source источник
comment
Сначала я бы попытался войти в код вашего адаптера, чтобы увидеть, что на самом деле там происходит, и посмотреть, получаете ли вы данные сообщения в первую очередь.   -  person Bryan Corazza    schedule 25.07.2009

Ответы (2)


arrow_upward
1
arrow_downward

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

person Saravana Kumar    schedule 27.07.2009
comment
Спасибо за ответ; мы также пошли по пути вызова прокси из оркестровки, как вы предлагаете. Однако мы по-прежнему хотим придерживаться этого подхода. И да, согласен, это далеко не тривиально :). - person Nigel; 27.07.2009

arrow_upward
0
arrow_downward

Семантически я не понимаю, почему решение, включающее адаптер WCF-BasicHtpp, не будет работать в вашем сценарии. В любом случае я бы определенно попытался посмотреть, что происходит с адаптером WCF-BasicHttp, и как только у меня будет рабочее решение, я бы переключился на настраиваемый адаптер SOAP, если это действительно необходимо.

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

В противном случае сообщение фактически публикуется в окне сообщения и, очевидно, для него нет подписчиков, отсюда и возникает ошибка.

person Maxime Labelle    schedule 17.01.2011