Разработка / [Из песочницы] Hello world на ESB Toolkit

Что такое ESB Toolkit и чем он интересен

ESB Toolkit — это набор инструментов для BizTalk сервера, который позволяет упростить разработку интеграционных приложений.
Несмотря на то, что это мощный инструмент, позволяющий создавать серьезные продукты, первое, чем он подкупает – низкий «порог вхождения» в тему разработки для BizTalk. Многие задачи, сложно решаемые оркестровками, легко решаются с помощью ESB Toolkit.
Майкрософт создала прекрасную документацию, где приведены примеры решения множества типичных задач. Но на своем примере я понял, что эта документация становится полезной, когда появилось общее представление о работе с этим инструментом. Видимо, срабатывает условный рефлекс ленивого программиста – не читать документацию, пока не получилось хоть что-то работающее, или не была потрачена впустую куча времени.
Собственно основная цель данного поста – создать простое приложение, чтобы можно было «пощупать» ESB Toolkit. Знакомые с BizTalk, наверняка, читали пример с переносом файлов из одной папки в другую с использованием фильтра на SendPort. В этом посте пример повторен с использованием статического роутинга в ESB Toolkit.
Предусловия

Для разработки будет использоваться BizTalk Server 2010 и Visual Studio 2010.
Перед разработкой необходимо установить ESB Toolkit и его компоненты для Visual Studio. Установка описана на сайте Microsoft, ссылка приведена в конце поста.
Подготовка

Сначала подготовим новое приложение, в которое мы будем использовать при разработке.
Назовем приложение EsbToolkitTest.
В References необходимо добавить ссылку на приложение Microsoft.Practices.ESB.
В созданном приложении создаем Receive Port и добавляем в него Receive Location.
Настраиваем Receive Location на забор файлов из папки. Например, C:ESBinput.Нужно не забыть, что у пользователя BizTalk должны быть права на чтение и запись в эту папку. Или настроить доступ от имени другого пользователя во вкладке Authentication.
Так же необходимо создать динамический SendPort.
В фильтре Send Port зададим следующие параметры:
Эти параметры позволят нашему порту получить сообщение из Itinerary. Обратите внимание, что ServiceName здесь задается произвольно.
Все, подготовка закончена, можно создавать Itinerary.
Создание Itinerary

Маршруты (Itinerary) – это основной компонент ESB Toolkit. С их помощью мы определяем, что будет твориться с нашим сообщением. После установки компонентов создавать маршруты можно во многих типа проектов. В этом примере мы создадим маршрут в Itinerary проекте.
Итак, в Visual Studio создаем новый проект. На вкладке BizTalk Projects нам должен быть доступен проект BizTalk ESB Itinerary Designer. Назовем наш маршрут TestItinerary.Если у вас нет такого шаблона проекта, его нужно установить из папки с ESB Toolkit. У меня шаблон расположен в папке C:Program FilesMicrosoft BizTalk ESB Toolkit 2.1ToolsItinerary Designer. Шаблон устанавливается запуском файла Microsoft.Practices.Services.Itinerary.DslPackage.vsix, после этого он появляется в Visual Studio.
В созданном проекте должен быть уже добавлен маршрут TestItinerary.ititnerary. Двойным щелчком открываем Itinerary Designer. Естественно, компонентов там сейчас никаких нет, и он радует нас пустым градиентом.
В тулбоксе слева нам представлен список доступных компонентов.
В данном примере нам пригодятся OnRamp, OffRamp, Itinerary Service и, конечно, Connector.
On-Ramp – это наш источник данных и контейнер для сервисов.
Itinerary Service – здесь будет наша логика роутинга.
Off-Ramp – это наш передающий компонент. Его нужно будет привязать к Send Port. Обратить внимание – порт должен быть динамическим, т.к. реальный адрес разрешается внутри маршрута.
Итак, переносим в область Itinerary Designer один On-Ramp, два Itinerary Service, один Off-Ramp и соединяем их коннекторами как показано на рисунке.Чтобы соединить два компонента коннектором, нужно сначала кликнуть на коннектор в Toolbox, потом кликнуть на первый компонент, потом кликнуть на второй. У активных пользователей графических редакторов здесь иногда бывает заминка, т.к. они пытаются «тянуть» коннектор от первого компонента ко второму. Мелочь, но может доставить пару неприятных минут.
Теперь нам нужно настроить каждый из компонентов и саму itinerary. Выбираем компонент OnRamp1 и прописываем ему следующие свойства:
Т.е. мы указываем, из какого Receive Port какого приложения нужно получать данные, переименовываем компонент в TestOnRamp и указываем Extender. Зачем каждый раз выбирать Extender для On-Ramp, если для него доступен один единственный «On-Ramp ESB Extender» -непонятно. Видимо, в некоторых ситуация там могут быть еще какие-то варианты, но я с этим не сталкивался.Обратите внимание, что пока вы не выберите Extender, некоторые свойства не появятся.
Совет по заданию свойств компонентов — указывайте те свойства, которые видите в данный момент, и не обращайте внимание на то, что некоторых пока нет – они появятся в процессе заполнения. Это связано с тем, что в свойствах вам часто приходится указывать тип компонента, а разные типы имеют разные наборы свойств.
После On-Ramp переходим к ItineraryService1. Задаем ему следующие свойства:
Т.е. контейнером для этого сервиса будет наш он-рамп, Extender’ом будет Messaging Extender. В Service Name указываем Microsoft.Practices.ESB.Services.Routing – этот сервис будет отвечать за роутинг. И переименовываем компонент в «Routing».
Помимо определения свойств нам нужно добавить в сервис роутинга резолвер. В нашем случае он будет разрешать адрес. Resolver у нас будет статический – его свойства будут жестко прописаны и не будут динамически изменяться.
Итак, кликаем правой кнопкой мыши по нашему Routing сервису и выбираем пункт Add-> Resolver
Если вызвать контекстное меню не всего компонента, а конкретного его резолвера, то появится такое меню:
Выделенный пункт здесь аналогичен предыдущему и никакой разницы между ними нет.
Назовем наш резолвер «staticResolver» и зададим ему следующие свойства:
Напоминаю, что у пользователя BizTalk должны быть права на запись в указанную в Transport Location папку. Статический резолвер позволяет довольно подробно задавать свойства SendPort, но для примера нам достаточно типа транспорта и адреса назначения.
Все, свойства сервиса маршрутизации мы определили. Переходим к компоненту Off-Ramp. Компонент ItineraryService2 пока пропускаем.
Для Off-Ramp компонента задаем следующие свойства:
Т.е. мы привязали наш Off-Ramp к ранее созданному Send порту. Off-Ramp’у мы так же дали более благозвучное имя: «TestOffRamp».
Теперь переходим к компоненту ItineraryService2. Этот компонент будет играть роль Off-Ramp сервиса. Задаем ему следующие свойства:
Т.е. мы указали, что это Off-Ramp сервис для TestOffRamp, и переименовали его.
Всё, все компоненты мы настроили, и наш Itinirary Designer должен иметь следующий вид:
Осталось задать свойства самой Itinerary. Для этого кликаем на свободном от компонентов месте и жмем F4. Задаем следующие свойства:
Разберем подробнее свойства, которые мы изменили:
1. Model Exporter – мы указали Database Itinerary Exporter, т.е. наш маршрут будет экспортирован не в XML, а сразу в БД, откуда его BizTalk и будет брать.
2. Require Encryption Certificate – False, т.к. он нам сейчас не нужен.
3. Itinerary Status – Deployed. Если оставить маршрут Published, то он будет в БД, но не будет доступен. Т.е. BizTalk его вызвать не сможет.
Еще нужно обратить внимание на свойство Name – это имя нашего маршрута, по которому его следует искать. Скопируйте его в буфер обмена – он нам сейчас пригодится.
Сохраните созданный маршрут, затем кликните правой кнопкой мышки на свободном от компонентов месте и выберите пункт «Export model». Теперь наш маршрут экспортирован в БД и доступен для вызова из BizTalk.
Настройка Receive порта

Еще раз зайдите в BizTalk Server Administration Console и откройте свойства созданного нами Receive Location. Мы не меняли pipeline и он остался PassThruReceive. Пришло время изменить его и настроить выбор нашей Itinerary.
Выберите pipeline ItinerarySelectReceivePassthrough и откройте его свойства.
В разделе Stage 1: Decode – Component: ESB Itinerary Selector необходимо указать свойства для выбора Itinerary.
В ItineraryFactKey укажите Resolver.Itinerary, а в ResolverConnectionString — ITINERARY:\name=TestItinerary;
В параметре Name задается имя нашего маршрута. Сейчас мы использовали статический выбор маршрута, однако можно так же использовать динамический, например, на основании бизнес-правил.
Старт, финиш и выводы

Запускаем приложение в BizTalk Server Administration Console.
В папке C:ESB создаем тестовый документ. Например, такой:
Hello world
Копируем документ в папку C:ESBinput и смотрим, как он появляется в папке C:ESBoutput.
Все, наше приложение отработало, можно радоваться.
Первый вывод, который напрашивается из этого примера – ESB Toolkit — это что-то громоздкое и того же результата можно добиться гораздо проще. Но нужно учесть — все, что мы задавали здесь статически, может определяться динамически. Т.е. лишь чуть-чуть усложнив задачу, мы получаем динамическую content-based маршрутизацию и трансформацию. И даже сам выбор маршрута может быть динамическим. Если данная тема будет интересна, то в следующем посту я приведу пример именно динамического решения на основании бизнес-правил.
Самая главная ссылка

Хотел назвать «Полезные ссылки», но понял, что полезной будет только одна:ESB Toolkit на сайте Microsoft
Здесь размещено все самое важное по ESB Toolkit, написано, что это такое, даны ссылки на документацию и на скачивание самого тулкита. Кстати, рекомендую скачать постер – очень полезная и наглядная вещь. Ресурс на английском. К сожалению, найти русский аналог мне не удалось.