Создание собственного 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 я публикую снимки экрана с фильтрами маршрутов, контекста и портов.

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

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

Источник

2 ответа

Решение

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

Источник

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

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

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

Источник
Другие вопросы по тегам