Microsoft BizTalk Server 2004 для интеграции приложений

Новая версия сервера интеграции Microsoft BizTalk Server 2004*, вышедшая в апреле 2004 г., основана на принципиально новой архитектуре и предлагает ряд полезных возможностей, таких, как улучшенная поддержка технологии Web-сервисов, средства разработки, интегрированные в среду Visual Studio .NET, и многое другое. Среди достоинств новой версии необходимо отметить значительное увеличение скорости работы BizTalk-приложений и упрощение процесса разработки, а также появление нескольких новых сценариев интеграции (пример - автоматизация управления потоками работ с помощью службы Human Workflow Services).

* См. также Александр Ложечкин "Microsoft BizTalk Server 2002 - второе пришествие", "BYTE/Россия" № 5'2002; Элдар Мусаев "Microsoft BizTalk Server 2004 - автоматизация документооборота и интеграция систем предприятия", "BYTE/Россия" № 6'2004.

На сегодняшний день Microsoft BizTalk Server 2004 используется для автоматизации бизнес-процессов организации в рамках двух основных сценариев:

• организация обмена информацией между несколькими системами, использующими несовместимые форматы данных и коммуникационные протоколы (EAI и B2B);
• построение систем электронного документооборота, ориентированных как на формализованные, так и на ad hoc-процессы.

Эффективные интеграционные решения основываются на ряде важных концепций - это асинхронная передача сообщений, сценарии бизнес-процессов, корреляция, длинные транзакции и ряд других. Шаблоны интеграции описывают, как подходить к решению проблем проектирования, основываясь на этих концепциях. Подобно шаблонам в других областях ИТ, шаблоны интеграции не зависят от используемых технологий конкретных производителей. В статье описываются сценарии автоматизации бизнес-процессов на основе стандартных шаблонов, а также рассматриваются службы и инструменты BizTalk Server 2004, помогающие в реализации.

Интеграция внутрикорпоративных приложений

Интеграция внутрикорпоративных приложений становится все более значимой с увеличением числа различных информационных систем в компании и роста зависимости бизнеса от хранимых в них данных. Такая ситуация типична для средних и крупных организаций, которые пытаются связать воедино разнообразные приложения, инсталлированные за последние 5-7 лет.

Для построения интеграционного решения, как правило, необходимы следующие предпосылки:

• прозрачный и быстрый обмен данными между различными системами (система должна получать доступ к любым требуемым данным, где бы они ни находились);
• корректность данных в информационных системах (в идеале во всем "информационном контуре" данные должны быть представлены в единственном экземпляре либо должен быть выстроен четкий механизм синхронизации);
• снижение объемов, а в идеале и полное исключение из бизнес-процессов переноса данных между системами вручную (ручное копирование и повторный ввод данных увеличивают риск привнесения ошибок и появления в системе противоречивой информации).

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

Рис. 1 иллюстрирует следующее интеграционное решение. Система "Заказы" принимает новый заказ, на основании которого необходимо сформировать указания для систем "Склад" (отгрузка товара) и "Биллинг" (выставление счета). Сообщение, генерируемое системой "Заказы", содержит общие данные, которые требуется передать как в систему "Склад", так и в систему "Биллинг", а также данные, специфичные для этих систем.

Рис. 1. Интеграция внутрикорпоративных приложений.

Исходное сообщение, поступающее из системы "Заказы", необходимо разделить, создав два новых типа сообщений - для систем "Склад" и "Биллинг". Эту задачу решает "Преобразователь сообщений". На его вход поступает одно сообщение типа "Заказ", на выходе образуется два новых сообщения, содержащих данные для систем "Склад" и "Биллинг". На этом шаге необходимо перевести данные из формата сообщения типа "Заказ" в формат, понятный системам "Склад" и "Биллинг".

Преобразование сообщений - наиболее общая функция в интеграционных решениях, поскольку связываемые приложения, как правило, используют несовместимые между собой форматы данных. "Преобразователь сообщений" конвертирует сообщения из одного формата в другой, используя XSLT-преобразование. В Microsoft BizTalk Server 2004 карта преобразования представляет собой отображаемую графически корреляцию между двумя XML-схемами, определяющую взаимосвязь их элементов. Схема преобразования разрабатывается с помощью графического инструмента BizTalk Mapper, интегрированного в среду разработки Microsoft Visual Studio.

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

Транспортные службы обеспечивают взаимодействие бизнес-приложений с промежуточным интеграционным слоем. В BizTalk Server 2004 транспортные службы представлены инфраструктурой транспортных адаптеров и службы выполнения. Адаптеры можно разделить на две категории: технологические, которые обеспечивают взаимодействие с конкретным транспортным уровнем, и адаптеры приложений, реализующие взаимодействие с конкретным бизнес-приложением.

Ряд адаптеров (HTTP, FTP, FILE, SOAP, SQL, MSMQT, SMTP) поставляются вместе с продуктом. Часть адаптеров (MQ Series, SAP R/3) Microsoft предоставляет дополнительно. Инфраструктура транспортных адаптеров позволяет создавать дополнительные адаптеры.

Системный администратор следит за процессом обмена с помощью блока "Мониторинг". Этот блок позволяет отслеживать процесс обмена с двух точек зрения:

• системного администратора: объем переданных данных, число успешных/неуспешных операций, контроль транспортного уровня и т. д.;
• бизнес-аналитика: число заказов того или иного товара в единицу времени, общий размер заказов, количество отгруженных единиц товара и т. п.

Ядро BizTalk Server 2004 содержит два важных компонента, позволяющих серверу интеграции выступать в качестве связующего звена между приложениями: компонент обмена сообщениями (Messaging) и компонент для реализации логики процесса (Orchestration).

Компонент Messaging отвечает за прием и отправку данных во внешние системы. Обмен данными происходит в виде сообщений, которые фактически представляют собой документы, значимые с точки зрения бизнеса (например, форма заказа). Компонент Orchestration отвечает за исполнение логики бизнес-процесса, связанного с определенным типом документа (или сообщения, в терминах BizTalk Server). Бизнес-процесс описывается в виде последовательности операций, которая носит название "схема Orchestration". Формирование структуры сообщения, а также описание логики бизнес-процесса в виде схемы Orchestration выполняется с помощью графической среды разработки (в рамках VS.NET).

Для унификации процесса обработки сообщений внутри BizTalk Server используется XML. Фактически с реальными форматами систем приходится иметь дело только в двух случаях: предобработка сообщения в момент поступления его в BizTalk Server и постобработка - в момент отдачи сообщения во внешнюю систему. Все блоки внутри "контура BizTalk Server" обмениваются друг с другом только XML-сообщениями.

При реализации "Преобразователя сообщений" задействуется функциональность BizTalk Server, позволяющая управлять схемами преобразования одного документа в другой. Схема преобразования может задавать простую трансформацию, например, копирование содержимого элемента. При более сложных трансформациях используются функции-преобразователи (функтоиды). Функтоид - это фрагмент исполняемого кода, который может произвольно определять сложные взаимосвязи между XML-схемами. Для часто используемых трансформаций BizTalk Server 2004 предоставляет ряд встроенных функтоидов различных категорий: математические, логические, агрегатные, функтоиды для доступа к БД и т. п.

При построении интеграционной платформы, помимо мониторинга работы системы в целом, необходимо отслеживать выполнение конкретных бизнес-процессов и экземпляров этих процессов для конкретных данных. Для целей бизнес-мониторинга, в дополнение к средствам технического мониторинга, в BizTalk Server 2004 существуют службы Business Activity Monitoring (BAM). С помощью инструмента Tracking Profile Editor разработчик задает информацию, которая будет доступна для компонентов BAM при выполнении сценария Orchestration. Представления BAM доступны бизнес-пользователям, например, в виде таблиц Microsoft Excel. С помощью BAM можно исследовать различные "представления" бизнес-процесса, например, отражать графически тренды продаж, текущее состояние складских запасов или другие индикаторы бизнес-процесса.

Часто возникает ситуация, когда при обмене сообщениями исходная система должна пройти авторизацию в целевой системе. В идеале авторизация должна выполняться автоматически, без вмешательства оператора. Сервер BizTalk Server поддерживает механизм Single Sign-On (SSO), обеспечивающий автоматическую авторизацию. Правила авторизации, а также необходимые параметры доступа (credentials) указываются системным администратором однократно и хранятся в защищенном хранилище, в рабочей БД BizTalk Server. В процессе обмена сообщениями BizTalk Server автоматически находит и подставляет необходимые данные при обращении к системам.

Взаимодействие с внешними системами

Развитие предыдущего сценария - работа с удаленной системой (B2B) с помощью Web-сервисов. Отметим, что поддержка взаимодействия с Web-сервисами существовала и в предыдущих версиях BizTalk Server, однако в последней версии продукта она была значительно улучшена. На рис. 2 показана схема такого взаимодействия: система "Заказы" принимает новый заказ, на основании которого формирует управляющие сообщения для систем "Склад" и "ERP". Процедуры обработки и транспортировки собщений аналогичны предыдущему сценарию.

Рис. 2. Интеграция с внешними системами.

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

Сервер интеграции BizTalk Server 2004 поддерживает работу с Web-сервисами двумя способами:

• BizTalk Server может трассировать сообщения между обычными приложениями и теми, которые предоставляют свои интерфейсы через Web-сервисы; таким образом, появляется возможность включать в "информационный контур" любые внешние приложения либо приложения, работающие на разных платформах;
• схему Orchestration можно представить в виде Web-сервиса, доступного извне; это позволяет быстро и с минимальными затратами организовать внешний интерфейс к бизнес-процессу или к внутреннему приложению.

Средства разработки приложений BizTalk, базирующиеся на Visual Studio .NET, теперь позволяют добавить в проект ссылку (URL) на Web-сервис либо идентифицировать Web-сервис на основе информации в каталоге UDDI. После того как информация о Web-сервисе добавлена в проект, разработчик получает возможность прямого обращения к методам данного Web-сервиса. Существует также возможность публикации схемы Orchestration в виде Web-сервиса в каталоге UDDI с помощью специального Мастера.

Построение электронного документооборота

Системы электронного документооборота предназначены для комплексной автоматизации и охватывают процессы взаимодействия не только между людьми, но и между системами. Движение электронного документа требует участия сотрудников, а также может "оставлять след" в информационных системах как результат обработки документа. Сервер интеграционной платформы обязан учитывать специфику работы систем электронного документооборота для облегчения процесса интеграции. Более того, интеграционное решение должно использовать возможности привычных приложений для работы с данными вручную, когда это необходимо.

Для выбора наиболее адекватной реализации того или иного сценария нужно ответить на следующие ключевые вопросы:

• Процессы документооборота жестко структурированы или формируются динамически, во время выполнения бизнес-процесса, путем задания ряда параметров?
• Какие пользовательские роли вовлечены в процесс на каждом шаге?
• Каким должен быть пользовательский интерфейс для взаимодействия с процессами и документами - портал, настольное приложение или оба варианта?
• Каким образом создается и модифицируется сценарий прохождения документа?

Ниже рассматриваются два основных подхода с использованием технологий и продуктов Microsoft.

BizTalk Orchestration и Microsoft InfoPath

BizTalk Server Orchestration - это средство графического описания бизнес-процессов, в которые входят шаги, связанные с получением и отправкой информации системам и людям.

Комбинация BizTalk Server с Microsoft InfoPath позволяет разработчикам проектировать структурированные и динамические маршруты движения документов, включая обработку электронных форм документов. BizTalk Server взаимодействует с Microsoft InfoPath, поддерживая динамическое заполнение форм или обработку запросов из форм через механизм Web-сервисов.

В комбинации с технологией организации совместной работы SharePoint и адаптером BizTalk для Windows SharePoint Services Libraries (свободно доступен для загрузки с сайта Microsoft) разработчики могут проектировать структурированные потоки документооборота для портальных сценариев взаимодействия. Документы (например, электронные формы Microsoft InfoPath) можно получить или записать в библиотеки документов SharePoint как часть бизнес-процесса.

Данный подход позволяет реализовать ряд типовых сценариев, в которых не требуется визуализация процесса вне Orchestration. Он будет развиваться в следующих версиях BizTalk Server.

Human Workflow Services

Службы Human Workflow Services (HWS) построены на основе функциональности BizTalk Orchestration путем добавления возможностей для построения динамических потоков документооборота во время выполнения. Для этого используются определенные заранее условия и ограничения, роли пользователей.

Службы HWS представляют собой интерфейс приложения (API), представленный в виде Web-сервиса и ориентированный исключительно на разработчика. Этот API достаточно сложен в изучении и освоении (по сравнению с предыдущим подходом). Службы HWS не предоставляют инструментов для графического описания процессов, подходящих для работы пользователей.

Microsoft InfoPath имеет встроенную панель задач, посредством которой пользователи могут видеть информацию, связанную с HWS-процессами, и управлять ею. С выходом Microsoft InfoPath SP1 появилась возможность реализовать уровень представления данных для решения, построенного на HWS.

Функциональность службы HWS должна рассматриваться для тактических реализаций со специфическими текущими требованиями к функциональности, описанными выше. Службы HWS будут поддерживаться без развития функциональности в следующей версии BizTalk Server. Программный интерфейс приложения будет поддерживаться в соответствии с политикой компании Microsoft в отношении серверных продуктов, однако нужно учитывать, что на смену HWS придут другие технологии. Эти технологии, концептуально развивающие HWS, будут реализованы в следующих серверных ОС Microsoft (Longhorn). Пути миграции от текущих решений на базе HWS на эти новые реализации еще не определены, и с высокой вероятностью они не будут простыми.

Заключение

Встроенные средства проектирования и разработки Microsoft BizTalk Server 2004 во многом облегчают работу как бизнес-аналитика, так и разработчика за счет удобной графической среды проектирования, наличия базовых механизмов интеграции и следования лучшей мировой практике автоматизации бизнес-процессов. Однако проекты автоматизации, по праву считающиеся одними из самых сложных в индустрии, требуют тщательно продуманного подхода и проектирования, а также владения специальными навыками и знаниями. Использование интеграционной платформы Microsoft BizTalk Server для автоматизации бизнес-процессов дает возможность формализовать подходы к автоматизации и выработать определенную долговременную стратегию объединения систем и людей в единый "информационный контур".

Дмитрий Шульгин,
специалист по продвижению бизнес-приложений, Microsoft