BizTalk Server 2009

Здравствуйте уважаемые хабропользователи. В данном посте я хочу рассказать вам о продукте для автоматизации и управления бизнес процессами BizTalk Server 2009.

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

Введение

Уже давно системы управления средними и крупными компаниями включают в себя множество программных комплексов, вводимых по мере роста и развития предприятия. Также эти системы требуют связи с программами и сервисами вне предприятия. Выглядит это приблизительно так:



Для понимания проблемной области приведу пример простейшего бизнес процесса:

1. Пользователь создает документ «Заказ товара» через web портал
2. Заказ должен быть передан во все остальные системы предприятия (бухгалтерам чтобы оплатить счет, в логистическую систему для учета и доставки товара, в Datawarehouse для составления исторических данных и подсчета kpi и т.д.)

Имеем проблему: как заставить все компоненты работать друг с другом?

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



Для решения таких проблем и был создан BizTalk Server (BTS). Он вводит новый уровень, с которым взаимодействуют системы, и берет на себя обязанности по доставке сообщений подписчикам. Теперь в нашем примере не нужно слать документ с web портала во все остальные системы. Достаточно передать его в BizTalk, после чего быть уверенным в доставке сообщения в каждую из требующих этого систем. Очевидно, что количество связей при таком подходе значительно уменьшится. Это позволит снизить затраты на управление системами в целом (ведь мы сняли с них обязанности общения с другими системами), а также позволит с легкостью добавлять новые.

Архитектура BTS

Вот простейший сервис достаточный для описания архитектуры работы BTS:

1. На входящем порту получаем сообщение инициирующее бизнес процесс;
2. Обрабатываем сообщение;
3. Отправляем сообщение на один или несколько исходящих портов;

А вот так этот процесс протекает на уровне сервера:


Для начала немного определений из того что видно на картинке:

Receive Adapter – входной порт. Необходим для приема сообщения из внешнего мира. Поддерживает различные протоколы и способы доступа к приложениям.
Orchestration – исполняющая часть бизнес процесса. Здесь можно писать код на C#, трансформировать сообщения, выбрасывать и ловить эксепшены, вызывать компенсацию для успешно отработавших сегментов и т.д. Но главный функционал, который предоставляет оркестрейшен — это паттерны обработки сообщений. Один из них я приведу в разделе с примером.
Send Adapter – тоже что и Receive Adapter только предназначен для отправки сообщений.

Ну а теперь процесс работы сервиса более детально:

1. Receive Adapter получает сообщение по одному из множества доступных протоколов из внешнего мира;
2. Сообщение пропускается через Receive Pipeline (с возможностями трансформации и валидиции);
3. Сообщение попадает в Message Box (MB) – хранилище сообщений внутри базы на основе MS SQL Server;
4. Постоянно работающий агент фиксирует наличие не обработанного сообщения и получателя в виде оркестрейшена;
5. Агент вызывает оркестерейшен с передачей ему на вход сообщения;
6. Оркестерейшен выполняет всю необходимую работу и генерирует новое сообщение которое попадает обратно в Message Box (чаще всего структура нового сообщения отличается от оригинального);
7. Агент снова фиксирует появление сообщения в MB и ищет получателя. На это раз им является Send Adapter;
8. Сообщение передается на Send Adapter который в связке с Send Pipeline по необходимости валидирует, трансформирует и отправляет сообщение во внешний мир по любому из доступных протоколов;

Теперь, когда базовый пример понятен я постараюсь на его основе описать некоторые полезные и даже уникальные возможности которые предоставляет BTS:

1. Большое количество протоколов с которыми могут работать входящие (исходящие) порты (File, SMTP, HTTP, WCF, MSMQ, SOAP и другие). Кроме протоколов есть также поддержка различных приложений: Oracle, SQL Server, WebSphere MQ, SharePoint, Tibco, SAP, JMS, JD Edwards, Dynamics и другие. Если же вашей системы нет в списке, то есть SDK при помощи которой вы можете сами разработать адаптер;
2. Полученные на входе сообщения можно преобразовывать внутри Pipeline в наиболее удобный формат до того как они попадут в оркестрейшен. Из коробки есть поддержка для работы с Flat files и богатые возможности обработки EDIFACT. Все эти форматы BizTalk сам преобразует в XML с заранее заданной XSD схемой.
   И опять-таки если вы хотите на вход получать, например Excel файлы или Binary файлы то может сами написать процедуру преобразования в XML, а можете и прямо так кинуть в Message Box, и потом уже разобрать начинку сообщения внутри оркестрейшена.
   Хочется особенно отметить удобство обработки EDIFACT сообщений. Поддерживаются все имеющиеся форматы, но если один из ваших партнеров отклонился от стандарта, можно легко подправить формат под него. Кроме фреймворка обработки сообщений BizTalk предоставляет еще инфраструктуру для обмена документами. В ней можно вести учет уникальности сообщений, вводить специальные настройки для каждого из партнеров и автоматические отправлять подтверждения принятия EDI документа. Также все это может работать через AS2 протокол;
   
3. В описанном примере происходит асинхронная обработка сообщения, но в общем случае она может быть синхронной или смешанной. Например если на вход нам приходит HTTP запрос требующий ответа то мы можем ответить на него только после того как убедимся в успешной отправке сообщения на исходящий порт;
4. Паттерны разработки подразумевают повторное использование одних компонент без необходимости дублирования. Например, если вам понадобиться получать сообщение не через FileSystem а через FTP то это никак не коснется реализации – достаточно только изменить тип входящего порта и настроить его на правильный адрес;
5. Контекстный роутинг сообщений. Очень удобная функциональнсоть! Если у вас есть несколько компонент обрабатывающих один тип сообщения, то вы можете подписать их на получение по описанию XSD схемы. Таким образом, как только в Message Box падает XML удовлетворяющих заданной XSD структуре, тут же все заинтересованные подписчики получают себе его копию. Естественно добавление нового подписчика не влияет не на получателей не на отправителя. Если провести аналогию с JMS то это как если бы у вас был один топик с одним паблишером и множеством сабскрайберов. Но разница в том, что в случае контекстного роутинга вам не нужен топик, а нужен только контракт на получение сообщения в виде XSD схемы;
6. Немного про масштабирование. Как вы заметили, Окестрейшен получает сообщение напрямую из базы. Он не знает, откуда оно пришло и кому предназначено, его задача взять сообщение, обработать и положить обратно. Поэтому вы можете установить сколько угодно серверов, каждый из которых будет подписан на получение сообщений. И в тот момент, когда внезапно их окажется в базе 1000 штук — Load Balancer автоматически раздаст их поровну для каждого сервера в зависимости от его текущей загрузки;
7. Хранение сообщений в базе дает еще один положительный момент. Если при отправке сообщения на порт происходит ошибка (например — канал закрыт фаерволом), сообщение отбракуется и сохранится в базе с описанием ошибки. Когда администратор обнаружит проблему, он сможет при необходимости исправить проблему с сетью и повторно отправит сообщение на порт. Также можно реализовывать автоматические стратегии репроцессинга. Все это делается без какого либо участия девелопера через удобную и информативную консоль администрирования BTS;
8. Пару слов о самой консоли – это мощное средство управления и мониторинга состояния одного или нескольких BizTalk серверов. Тут можно наблюдать какие сервисы активны, управлять их запуском, настраивать шедулинг, проверять как происходит роутинг сообщений между компонентами, были ли в последнее время ошибки и многое другое;
9. BRE (Business Rule Engine) – механизм внедрения функциональности в сервис налету (Dependency injection). Для использования BRE девелопер вставляет в оркестрейшен элемент Bussines Rule и реализует процесс обработки в контексте этого правила. Затем сервис деплоится на сервер и начинает работать. Со временем бизнес модель может измениться, тогда Аналитик должен будет создать новое правило в специальном user friendly редакторе и задеплоить его в BRE репозиторий ассоциировав с требуемым сервисом. При этом ранее созданный процесс будет функционировать на основе изменившегося правила, без необходимости привлечения разработчика и перезапуска сервиса;
10. BAM (Business Activity Monitoring) – все элементы внутри оркестрейшена которые используются в процессе функционирования сервиса содержат набор параметров которые доступны для BAM сервера. Например, объект ремаппинга xml сообщения предоставляет доступ ко всем полям заданным XSD схемой. Имея эти данные бизнес пользователи, без участия девелопера, могут создавать выборки данных, чарты и диаграммы на основе данных проходящих в XML сообщении через сервис. Вся эта работа происходит независимо от процесса работы самого сервиса и может изменяться без необходимости остановки сервиса. Результаты могут выводиться в документы office или на специальный BAM портал.

Пример сервиса

Вот пример более искушенного сервиса, показывающий возможности оркестрейшена по управлению течением бизнес процесса (номера в списке соответствуют пунктам в дизайнере оркестрейшена на картинке):

1. Пользователь в своей системе создает заказ товара. На его запрос должен прийти положительный или отрицательный ответ в зависимости от разных факторов, определяющихся внешними, по отношению к пользователю системами. Заказ попадает на вход адаптеру BizTalk, далее в MessageBox, и затем выполнение передается в оркестрейшен;
2. Сервис отправляет полученный заказ менеджеру для проверки валидности (ведь пользователь мог заказать товар не касающийся работы фирмы);
3. Этот же заказ немедленно отправляется на склад для проверки возможности его выполнения (Товара может попросту не быть в наличие);
4. Далее в работу вступает ParallelActions Shape, реализующий Parallel Convoy Pattern. Этот элемент завершит выполнение только когда отработают все составляющие его элементы. А сработать должны 2 факта: сервис должен получить ответы от менеджера и со склада.
   В общем случае ожидание может длиться достаточно долго (например если Менеджер в отпуске). На этот случай в BizTalk есть возможность задать тип Orchestration: Long Running. Тогда во время ожидания ответа из обеих систем состояние выполнение оркестрейшена сериализуется и сохранится в базе (в терминах BTS этот процесс называется Дегидротацией приложения). А как только будут получены оба ответа — сервис снова загрузится в память и завершит выполнение ParallelActions Shape.
   Тут есть один тонкий момент. В реальной системе юзеров всегда много и приложению менеджера и на склад одновременно может приходить несколько сообщений, соответственно и отвечать они могут не в том порядке, в котором пришли запросы. Отсюда вопрос: как BizTalk знает какому из работающих инстансов сервиса предназначен ответ из внешней системы?
   Ответ прост, логичен и реализуется всего в пару кликов в оркестрейшен дизайнере. У каждого сообщения уходящего на Send Port должен быть выставлен Correlation_ID. В данном случае на его роль идеально подходит поле OrderNo. Его нужно указать прямо из контекста XML сообщения. Этот же Correlation_ID задается и для ответа на запрос. Таким образом, мы имеем множество сервисов ждущих ответа и множество ответов. Для их связи между собой Агент управления вызовами будет использовать поле OrderNo. То есть, если инстанс «А» отправил заказ номер «35», а инстанс «В» заказ «47», то ответ на заказ «47» вернется инстансу «В», а на заказ «35» — «А»;
   
5. После того как ответы получены останется проверить результаты от менеджера и со склада. Если все OK, пользователь получит уведомление об успешном выполнении его заказа, а сам заказ уйдет в систему поставщика товара. Иначе пользователь получит сообщение с описанием причины, почему его заказ не может быть удовлетворен. На этом сервис завершит работу;

В этом пример сервис работал с 4 портами. За каждым из них находится своя система (на пример это могут быть Oracle Retail, Dynamics, порты JMS и Web Sphere или еще что-нибудь), но сам сервис не должен беспокоиться какая именно. Детали доставки сообщения, авторизации, преобразования сообщения в нужный формат для каждой из систем происходят на уровне адаптера и ассоциированного Pipeline. Также проблемы транспорта и возможных ошибок доставки также решаются при помощи стандартных средств, и не требует реализации на уровне сервиса (хотя если понадобится, это можно сделать и внутри оркестрейшена).

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

Спасибо за внимание, надеюсь вам было интересно.

Литература:

• WROX: Professional BizTalk Server 2006
• APRESS: Pro BizTalk 2009
• PACKT: SOA Patterns with BizTalk Server 2009