Интеграция и автоматизация: BPEL в действии

--> Дата: Фев 18, 2008 169

BPEL — это универсальный язык для описания алгоритма выполнения бизнес-процессов. Язык часто рассматривается как ключевая составляющая сервис-ориентированной архитектуры приложений (SOA). Действительно, BPEL позволяет эффективно управлять вызовами сервисов; в особенности он удобен при работе с Web-сервисами*.

* Краткий обзор языка BPEL приведен в статье “Автоматизация бизнес-процессов с помощью BPEL” («BYTE/Россия» №2’2005). – Прим. ред.

Язык BPEL — это средство автоматизации процессов, но его базовых возможностей недостаточно для управления потоком работ (workflow). Только после того как процесс сможет оперировать понятиями «документ» и «задача», на основе BPEL можно создать систему workflow.

Российская компания Naumen (http://www.naumen.ru) представила систему электронного документооборота Naumen DMS, построенную на принципах SOA. Система документооборота предоставляет свою функциональность в виде Web-сервисов, управление сервисами организовано с помощью BPEL-процессов. Средой исполнения процессов служит продукт Active Endpoints ActiveBPEL.

Система электронного документооборота позволяет автоматизировать бизнес-процессы с участием документов. Для того чтобы процессы могли взаимодействовать с пользователями посредством назначения задач, вводится компонент «Диспетчер задач». Используя интерфейс Web-сервисов, любое уполномоченное приложение (в том числе и BPEL-процесс) может обратиться к компоненту, назначить задачи пользователям, получить список назначенных задач и т. д. Таким образом, BPEL выступает как средство автоматизации потоков работ.

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

Автоматизируем бизнес-процесс

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

среда исполнения BPEL (ActiveBPEL);
система электронного документооборота Naumen DMS;
диспетчер задач;
средство потокового ввода Microsoft InfoPath, входящее в пакет Microsoft Office 2003.

Участие в нашем примере такого продукта, как InfoPath, может показаться неожиданным. Действительно, каким образом настольное приложение можно интегрировать с системой масштаба предприятия без дополнительных работ по их сопряжению? Ответ очевиден: продукты Microsoft Office, как и множество других приложений, поддерживают технологию Web-сервисов, что позволяет легко интегрировать их в сквозные бизнес-процессы.

Итак, представим себе следующий сценарий.

Оператор заполняет форму с данными заявки клиента в приложении Microsoft InfoPath.
Оператор нажимает на кнопку «Сохранить». В результате InfoPath отправляет введенные данные на сервер исполнения BPEL-процессов (который виден извне как набор Web-сервисов), тем самым порождая новый экземпляр процесса «Рассмотрение заявки».
BPEL-процесс создает документ с текстом заявки в системе электронного документооборота Naumen DMS.
После того как документ создан, BPEL-процесс направляет ответственному лицу задачу на рассмотрение заявки.

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

Разработка процесса

Создадим описание BPEL-процесса. Мы не станем писать BPEL-код вручную, а воспользуемся визуальным редактором ActiveBPEL Designer. Редактор распространяется бесплатно и представляет собой модуль расширения для популярной среды разработки Eclipse.

Шаг 1. Начинаем проект

Добавим в среду разработки новый проект InquiryProcess и пустой процесс в файле inquiryProcess.bpel (рис. 1).

Рис. 1. Начало BPEL-проекта.

Шаг 2. Описание программного интерфейса

BPEL-процесс предоставляет свои интерфейсы во внешний мир в виде набора Web-сервисов. Интерфейсы Web-сервисов описываются с помощью WSDL-документов и содержат перечень предоставляемых функций, описание их параметров и определение используемых типов данных. Итак, создадим WSDL-файл inquiryProcess.wsdl.

Вместо того чтобы редактировать WSDL-файл вручную, воспользуемся модулем расширения Eclipse Web Tools. EWT представляет собой удобное средство визуального редактирования XML и WSDL-файлов, а также содержит инструменты тестирования Web-сервисов. На рис. 2 представлена графическая схема WSDL-файла для нашего процесса.

Рис. 2. Схема проектируемого процесса.

Из рис. 2 мы видим, что WSDL-описание процесса содержит один интерфейс (Port Type) с названием inquiryProcess, в котором содержится единственная функция inquiry. В качестве входного параметра функция принимает сообщение inquiryRequest. Это сообщение, в свою очередь, содержит элемент IssueInfo, который несет в себе следующие данные о новой заявке:

referenceNumber — регистрационный номер заявки (строка);
summary — краткое описание сути вопроса (строка);
text — полный текст заявки (строка);
resolveBefore — дата, до наступления которой требуется разрешить запрос (дата/время).

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

Шаг 3. Импорт WSDL-описаний сервисов

Для того чтобы BPEL-процесс смог обращаться к внешним сервисам, необходимо импортировать в проект WSDL-файлы всех используемых сервисов. Таких сервисов в нашем случае будет всего два: сервис работы с документами в системе документооборота Naumen DMS (DMSDocuments) и сервис взаимодействия с диспетчером задач (WorkListManager).

Поскольку BPEL-процесс сам представляет собой Web-сервис, для того чтобы он мог принимать запросы извне, необходимо импортировать WSDL-описание его программного интерфейса. Поэтому мы импортируем файл inquiryProcess.wsdl, созданный на предыдущем этапе.

На рис. 3 показана вкладка Web References редактора ActiveBPEL Designer с перечнем импортированных WSDL-документов. Описания сервисов можно добавлять как в виде локального WSDL-файла, так и указывая URL внешнего источника в сети.

Рис. 3. Перечень импортированных WSDL-документов.

Шаг 4. Первое действие

Теперь мы можем приступить к созданию алгоритма процесса.

Создадим первое действие, состоящее из элемента Receive. С этого действия начинается наш процесс, оно ожидает запроса со стороны клиента. Мы можем создать действие вручную и указать все его параметры, но предпочтем, чтобы BPEL-редактор выполнил за нас всю рутинную работу. Для этого на вкладке Web References раскроем ссылку на WSDL-документ inquiryProcess.wsdl (мы создали его на этапе 2). На рис. 4,а мы видим структуру документа, в том числе интерфейс inquiryProcess и его единственную операцию inquiry. Мышкой перенесем название операции в область описания алгоритма процесса.

Редактор задаст нам вопросы о названии нового типа партнерского взаимоотношения (Partner Link Type), в которое необходимо включить выбранную операцию. Необходимо также указать название роли, которую будет выполнять процесс в данном взаимоотношении. Мы указали соответственно значение Inquiry в качестве Partner Link Type и processor в поле Role (рис 4,б). В качестве значений этих параметров можно указать любые подходящие по смыслу названия.

После этого редактор уточнит (рис. 4,в), какого рода действие мы хотим создать на основе указанной операции. Пока что ему неизвестно, хотим ли мы вызвать операцию в удаленном сервисе (добавить действие Invoke) либо намерены добавить действие Receive, ожидающее вызова к процессу.

Мы выбрали Receive, после чего в нашем процессе появилось первое действие (рис. 4,г), все параметры которого были установлены автоматически. Нам осталось лишь переключить значение свойства createInstance в положение true, после чего вызов данного действия будет приводить к созданию нового экземпляра процесса.

Создание действия Receive привело к тому, что теперь процесс предоставляет во внешний мир Web-сервис Inquiry, с помощью которого мы можем отправлять ему новые заявки. ActiveBPEL автоматически публикует WSDL-описание сервиса по адресу http://<имя_сервера>/active-bpel/services/InquiryService?wsdl.

Рис. 4. Создание действия, состоящего из элемента Receive.

Шаг 5. Добавление вызовов внешних сервисов

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

Для создания нового документа мы используем операцию addDocument сервиса DMSDocuments, а для назначения задачи воспользуемся операцией addWorkItem сервиса WorkListManager. Каждый раз мы должны выбрать другое имя для значения параметра Partner Link Type. В случае с сервисом создания документа мы используем название DocumentManagement, а для диспетчера задач — значение WorkList. В результате процесс содержит три типа партнерских взаимоотношений: WorkList, Inquiry и DocumentManagement.

Следует обратить внимание на то, что теперь мы создаем действия типа Invoke, поскольку намерены сами вызывать удаленные сервисы, а не ожидать запросов от клиентских приложений. Сейчас наш процесс состоит из одного действия Receive и двух действий Invoke. Перед каждым вызовом удаленного сервиса (Invoke) добавим по элементу Assign, которые будут инициализировать переменные с входными данными для каждой вызываемой операции. Присвоим каждому действию «дружественное» название и заключим их в элемент Sequence. Все помещенные в элемент Sequence действия выполняются последовательно, один за другим. Получившаяся диаграмма процесса показана на рис. 5.

Рис. 5. Диаграмма последовательного процесса.

Шаг 6. Подготовка данных

Наш процесс почти готов. Осталось настроить элементы Assign с именами ПодготовитьДокумент и ПодготовитьЗадачу. Каждый элемент Assign состоит из набора операций копирования. Например, можно скопировать содержимое (или часть) одной XML-переменной в другую либо присвоить переменной результат XPath-выражения.

Подготовим содержимое переменной addDocumentRequest, значение которой передается сервису создания документа в системе документооборота Naumen DMS. Например, сделаем так, чтобы регистрационный номер заявки стал заголовком нового документа. Для этого скопируем элемент referenceNumber переменной inquiryRequest в элемент title переменной addDocumentRequest. Редактор ActiveBPEL Designer предоставляет графический интерфейс конструирования подобных выражений.

Аналогично копируем текст заявки (text) в текст документа. Краткое описание (summary) копируем в свойство description переменной addDocumentRequest.

Чтобы система Naumen DMS могла создать документ, необходимо указать его категорию, автора и родительский объект (папку). В нашем примере это константы.

Далее настраиваем параметры новой задачи, инициализируя переменную addWorkItemRequest. После того как документ в системе документооборота создан, его идентификатор помещается в переменную addDocumentResponse. Добавим значение идентификатора в элемент references задачи, тем самым привязав задачу к документу. Затем свойство заявки resolveBefore скопируем в элемент estimatedCompletionDate переменной addWorkItemRequest. Параметр estimatedCompletionDate определяет планируемый срок завершения задачи.

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

Следует отметить, что конструирование выражений с помощью языка XPath может оказаться крайне непростой задачей. Язык XPath создавался с одной целью — манипулирование XML-данными. Если потребности разработчика выходят за рамки поиска и копирования информации из одной XML-переменной в другую, то возможности языка могут поставить его в тупик. Например, даже операция добавления нового элемента в массив порой вызывает затруднения. К счастью, стандарт BPEL не накладывает ограничений на используемый язык выражений.

Кроме языков XPath и XQuery среда ActiveBPEL позволяет применять в выражениях BPEL-процессов большинство современных интерпретируемых языков программирования, таких, как JavaScript, Python, Ruby, Groovy. Эта возможность реализована за счет интеграции с проектом Apache Bean Scripting Framework.

Интеграция с InfoPath

Мы закончили описание процесса, и сейчас настало время создать клиентскую часть — форму заполнения заявки в Microsoft InfoPath. Откроем конструктор форм InfoPath и создадим простую форму с полями, соответствующими параметрам заявки, как показано на рис. 6.

Рис. 6. Форма создания заявки в конструкторе форм InfoPath.

После того как форма готова, остается настроить способ передачи введенных оператором данных на сервер. Воспользуемся функцией «Отправка форм» в сервисном меню InfoPath. В появившемся диалоговом окне укажем, что требуется отправлять данные формы с помощью Web-сервиса, и сообщим адрес его WSDL-описания. В нашем случае это http://<имя_сервера>/active-bpel/services/InquiryService?wsdl.

Запуск процесса

Нам осталось лишь протестировать полученное решение. Итак, оператор заполняет форму заявки в приложении Microsoft InfoPath (рис. 7).

Рис. 7. Заполнение формы заявки в Microsoft InfoPath.

Как только оператор нажимает на кнопку «Сохранить», данные заявки передаются серверу ActiveBPEL. Создается новый экземпляр процесса «Рассмотрение заявки». В папке «Заявки» системы документооборота Naumen DMS создается документ, содержащий текст заявки (рис. 8).

Рис. 8. Документ с текстом заявки в системе Naumen DMS.

Теперь зайдем в систему Naumen DMS от имени пользователя, ответственного за рассмотрение заявок. В персональном списке задач пользователя появилась новая задача (рис. 9). Видно также, что к ней прикреплена ссылка на документ с текстом заявки.

Рис. 9. В списке задач появилась новая позиция.

Итак, нам удалось автоматизировать процесс с участием нескольких информационных систем: системы электронного документооборота Naumen DMS, диспетчера задач и Microsoft InfoPath.

Конечно, мы рассмотрели не все детали создания процесса; в действительности технологу необходимо потратить время на создание Xpath-выражений инициализации переменных, установить процесс на сервер исполнения и т. д. Тем не менее, хотя автоматизация процессов в сервис-ориентированной среде и требует глубокого понимания Web-технологий, взамен мы получаем широкие интеграционные возможности и универсальность решения.