Александр Ложечкин
alozhechkin@hotmail.com

Каково сейчас положение дел с интеграцией приложений? Наиболее типичная ситуация - совместная деятельность двух организаций (например, производителя или дистрибьютора и покупателя - дилера). При этом к мысли о необходимости интеграции появляются в организациях, когда у них уже сформировались информационные системы, включающие в себя и базы данных, и системы управления бизнес-процессом (так называемые Line-of-Business приложения), и ERP-системы. Когда возникает потребность объединить происходящие у партнеров по бизнесу процессы, то, как правило, интеграция приложений происходит постепенно.

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

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

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

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

Затем у партнеров возникает желание связать между собой и кассы, выдающие чек на оплату. И здесь решение возникает достаточно быстро (например, через 2 месяца) - создается новое приложение, автоматизирующее и этот процесс.

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

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

Именно эту роль готов взять на себя Microsoft BizTalk Server 2000. Каким же образом осуществляется в нем интеграция приложений и бизнес-процессов? Архитектурно сервер интеграции состоит из двух основных подсистем: системы связи приложений BizTalk Messaging и системы управления бизнес-процессами BizTalk Orchestration. Рассмотрим подробно каждую из них.

BizTalk Messaging

Подсистема BizTalk Messaging решает следующую задачу: получение документа по одному транспортному протоколу в одном формате представления, преобразование его в другой формат и отправка документа в новом формате по другому транспортному протоколу. Одновременно со своей основной задачей BizTalk Messaging позволяет задействовать средства обеспечения безопасности - проверку цифровой подписи и расшифровку пришедшего документа, а также шифрование и подпись отправляемого, ведение журнала прошедших документов (целиком или только выделенных полей).

Что требуется для создания связи между двумя приложениями при помощи BizTalk Messaging? Прежде всего необходимо описать формат документов, получаемых на выходе одного приложения и подаваемых на вход другому. Для решения этой задачи в состав BizTalk Server входит приложение BizTalk Editor (рис. 1), позволяющее создать схему документа, во многом похожую на XDR-схему, которая используется для описания XML-документов. Но схемы BizTalk позволяют описать и формат хранения документа - например, плоский файл (позиционированный или с разделителями), EDIFACT или EDI/X12 и, естественно, XML. Если же приложение сохраняет файл в каком-то не поддающемся описанию двоичном формате, существует возможность написать собственный синтаксический анализатор, преобразующий документ в XML и обратно.

Fig.1
Рис. 1. Окно редактора схем документов BizTalk Editor.

Описав формат документов, попадающих на вход и выход BizTalk Server, затем необходимо описать их преобразование из одного формата в другой. Для этой цели служит приложение BizTalk Mapper (рис. 2), позволяющее описать преобразование при помощи стандарта XSL transformation (XSLT). При этом можно использовать функции, называемые в BizTalk Mapper Functoid, которые не только выполняют простые математические и строковые операции над данными, но и позволяют в процессе преобразования обращаться в базу данных, производить операции над множеством значений (агрегатные функции) и т.д. Если необходимо реализовать нестандартную операцию, можно реализовать собственные функции Functoid на языке VBScript.

Fig.2
Рис. 2. Окно редактора схемы преобразования документов BizTalk Mapper.

После описания документов и преобразования необходимо сконфигурировать подсистему BizTalk Messaging, сообщив ей способ получения документов у приложения-источника и способ отправки преобразованных документов приложению-приемнику. BizTalk Server поддерживает широкий набор транспортных протоколов, по которым можно получать и отправлять документы. Среди них: ·

  • транспортные протоколы Интернета - HTTP и SMTP; ·
  • файловый транспортный сервис (BizTalk Server может забирать документы из определенной папки файловой системы и сохранять обработанный документ в определенной папке); ·
  • транспортный сервис MSMQ, позволяющий забирать и отправлять сообщения в очередь (а если использовать средства трансляции сообщений MSMQ-MQSeries, появляется возможность интеграции с наследованными системами и мэйнфреймами).

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

Для управления конфигурацией BizTalk Messaging служит приложение BizTalk Messaging Manager (рис. 3). При создании схемы взаимодействия приложений используются следующие понятия.

Document definition (описание документа), содержащее описание документа, ссылку на схему документа и указание, какие поля документа подлежат сохранению в журнале;

Envelope (конверт), позволяющий транспортировать документы нестандартного формата, а также вкладывать в посылку маршрутизирующую информацию, если сам документ ее не содержит;

Organization и Application (организация и приложение) - описывают источники и приемники сообщений, содержат идентификаторы, позволяющие адресовать документы;

Channel (канал), в который попадают входящие документы. В канале выполняется обработка входящего документа и, при необходимости, преобразование его в другой формат, описанный в схеме преобразования;

Port и Distribution List (порт и список рассылки) - каждый канал заканчивается портом или списком рассылки, позволяющим описать транспорт и получателя документа (организацию или приложение).

Fig.3
Рис. 3. Окно приложения BizTalk Messaging Manager и окно свойств одного из объектов схемы - порта.

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

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

BizTalk Orchestration

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

Рассмотрим снова процесс взаимодействия дилера и дистрибьютора. Дилер занимается розничными продажами товара, предоставляемого дистрибьютором. У фирмы-дилера есть склад, на котором хранится минимально необходимое количество товара (минимальное потому, что склад небольшой, и потому, что цена на товар постоянно меняется). Покупатели постоянно уменьшают запасы товара на складе дилера, и когда его количество подходит к критической отметке, кладовщик посылает запрос в службу снабжения о том, что необходимо привезти еще партию товара от дистрибьютора. Этот запрос обрабатывается в службе снабжения, где принимается решение - заказывать товар или нет. Если нужно сделать заказ, письмо об этом отправляется дистрибьютору, где заказ и обрабатывается. Далее отправляется счет покупателю и одновременно с этим - информация о необходимости доставить товар на склад. Счет, попав к дилеру, оплачивается обрабатывающим сделку банком путем посылки платежного поручения, и товар благополучно доставляется на склад.

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

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

В состав BizTalk Server 2000 входит приложение BizTalk Orchestration Designer, предназначенное для описания модели бизнес-процесса и управления им. Процесс разбивается на последовательность действий (Actions), принятия решений (Decision), многократного повторения какого-либо действия (While), параллельного выполнения нескольких задач (Fork и Join) и (как же без этого!) транзакций (Transaction). В скобках мы привели не просто перевод терминов, а названия блоков Orchestration Designer, из которых строится бизнес-процесс.

Fig.4 Рис. 4. Логическая схема бизнес-процесса.

Описанный выше бизнес-процесс можно было бы представить так, как показано на рис. 4. И точно в таком же виде, с использованием тех же блоков, логическую схему процесса позволяет отобразить BizTalk Orchestration Designer. Но при этом каждый блок можно привязать к реализации: например, указать, что блок "Ждать счет" - это ожидание появления письма в определенном формате, а блок "Оплатить" - отправка сообщения в очередь MSMQ или вызов метода COM-объекта. Как может выглядеть тот же бизнес-процесс в Orchestration Designer, показано на рис. 5.

Fig.5
Рис. 5. Бизнес-процесс покупки партии товара в BizTalk Orchestration Designer.

Слева на рис. 5 мы видим ту же самую схему покупки партии товара, но описанный бизнес-процесс не "висит" в воздухе. Он привязан к своей реализации в виде компонентов бизнес-логики процесса, транспортных очередей и компонентов подсистемы BizTalk Messaging. Для реализации бизнес-процесса могут использоваться и такие блоки, как очередь MSMQ, компонент BizTalk Messaging, COM-компонент, а также COM-компонент, реализованный на языке исполнения сценариев (VBScript).

Между собой компоненты описания бизнес-процесса и компоненты реализации связываются через порты и сообщения (но это не те порты и сообщения, что используются в BizTalk Messaging, несмотря на одинаковые названия). Даже вызов COM-компонента представляется как отправка сообщения с входными параметрами и получение ответного сообщения с выходными параметрами метода.

Пользовательский интерфейс BizTalk Orchestration Designer (реализованный на базе Microsoft Visio 2000) состоит из страницы описания бизнес-процесса, разделенной на две части: слева - бизнес процесс из блоков действий и принятия решений, справа - его реализация, а посередине - привязка одного к другому. Вторая страница содержит описание используемых данных.

Созданная с помощью BizTalk Orchestration Designer бизнес-модель компилируется в язык XLANG (язык выполнения сценариев на базе XML), который впоследствии исполняется COM+-приложением XLANG Scheduler. За исполнением сценария можно проследить при помощи специального приложения-монитора, позволяющего контролировать все происходящие при этом процессы и определять его текущее состояние.

Во время исполнения бизнес-процесс может приостанавливаться на длительное время (например, если отслеживается процесс доставки товара до получения подтверждения). Для сохранения состояния процесса используется база данных на SQL Server. Для этого применяемые COM-компоненты должны поддерживать сохранение своего состояния (через стандартный интерфейс IPersist).

Таким образом, многие задачи, решаемые сейчас каждый раз заново при управлении бизнес-процессом внутри одной организации, а также при интеграции бизнес-партнеров, могут решаться существенно проще с использованием сервера интеграции приложений. Таким сервером может стать новый продукт Microsoft BizTalk Server. Его уже можно "потрогать руками" - сейчас доступны бета-версии, а выход окончательной версии продукта намечен на первый квартал 2001 г.

Дополнительная информация

Эта статья не претендует на полное описание BizTalk Server 2000, здесь дан только обзор его архитектуры и возможностей. Дополнительную информацию о BizTalk Server можно получить по следующим адресам Интернета.
http://www.microsoft.com/biztalk Узел на сайте корпорации Microsoft, посвященный технологии BizTalk
http://www.microsoft.com/biztalkserver Узел на сайте корпорации Microsoft, посвященный BizTalk Server
http://biztalk.org Сайт Интернет-сообщества biztalk.org. Здесь содержатся статьи о BizTalk и спецификации, форумы и группы новостей, а также обширная библиотека XML-схем документов, используемых в разных отраслях бизнеса
http://msdn.microsoft.com/msdnmag/
issues/0500/biztalk/biztalk.asp
Статья A. Skonnard и B. Laskey, BizTalk Server 2000: Architecture and Tools for Trading Partner Integration
news://msnews.microsoft.com/
microsoft.public.biztalk.*
;
news://msnews.microsoft.com/
microsoft.public.biztalkserver.*

Конференции, посвященные BizTalk Server и инициативе BizTalk