Стивен Уайт, архитектор IBM BPM, председатель специальной группы BPMI BPMN

Введение

Business Process Modeling Notation (BPMN) был разработан для того, чтобы дать возможность бизнес-пользователям разрабатывать легко понимаемые графические представления бизнес-процессов. BPMN также поддерживает свойства графических объектов, что делает возможным генерацию выполнимого BPEL. Таким образом, BPMN создает стандартизованный мост между дизайном бизнес-процессов и их исполнением. Эта статья представляет простой, но наглядный пример того, как BPMN диаграмма может быть использована для создания BPEL процесса.

Когда рисуется BPMN диаграмма для BPEL(version 1.1)[1], необходимо решить, какой будет базовая структура BPEL документа. То есть, будет ли BPEL элемент базироваться на структуре графа (элемент потока) или на блочной структуре (элемент последовательности)? Этот выбор будет влиять на то, сколько стрелок (Sequence Flow) будет изображено для связей элементов. В блочной структуре связи элементов используются только в специфических секциях процесса, где встречаются параллельные действия. В графической структуре наибольшее количество стрелок будет нарисовано для связи элементов, поскольку весь процесс BPEL находится внутри элементов потока. Т.к. BPMN 1.0 спецификация [2] берет за основу подход рисования BPMN элементов для BPEL, используя блочную структуру, эта статья будет основана на использовании графической структуры.

Пример: процесс заказа путешествия

Пример, который будет использован в этой статье — это базовая версия процесса заказа путешествия. Этот пример будет иллюстрировать несколько ситуаций, которые встречаются внутри BPMN, и как они рисуются для BPEL, такие как параллельные потоки и петли. На Рисунке 1 показано оригинальное представление BPEL процесса[3].

Рисунок 1. Процесс заказа путешествия, выполнен в WebSphere Studio

Рисунок 2 показывает, как тот же самый процесс может быть смоделирован с использованием BPMN. Можно отметить, что рисунок 2 показывает модель процесса, выполненную в горизонтальном направлении, слева направо, в то время как оригинальная диагамма на Рисунке 1 выполнена вертикально, сверху вниз. Инструментарий, в котором создается строго BPEL процесс, склонен располагать процесс вертикально. Это не универсально, поскольку бизнес-аналитики предпочитают располагать диаграммы горизонтально, а IT-специалисты — вертикально. BPMN допускает любое расположение диаграмм, однако большинство BPMN-диаграмм горизонтально ориентированы.

Рисунок 2. Процесс заказа путешествия в BPMN

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

Установка BPEL информации

BPMN-диаграмма, такая, как на Рисунке 2, может быть использована в разных методологиях и для разных целей, от высокоуровневого описания моделей до детального моделирования, предназначенного для исполнения процессов. Когда одной из целей является определение исполнения процесса и создание BPEL файла для этой цели, тогда модель процесса создается с использованием специально предназначенного для этого инструментария. Диаграмма сама по себе не показывает всей информации, необходимой для создания BPEL файла, т.к. тогда она будет слишком беспорядочной, что сделает ее нечитаемой. BPMN диаграмма предназначена для воспроизведения базовой структуры и потока действий и данных внутри бизнес-процесса. Таким образом, необходим инструмент моделирования, способный «добыть» остальную информацию, необходимую для создания исполняемого BPEL файла. В следующей секции будут более ярко освещены детали, остающиеся за видимостью диаграммы, и будет показано, как они обеспечивают содержание для BPEL.

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

В Примере 1 показывается, как основная информация о BPMN диаграмме и о процессе заказа путешествия внутри этой диаграммы будет нанесена на карту, чтобы настроить предварительную информацию для BPEL

Рисунок 3. Пример 1. Нанесение на карту базовых атрибутов бизнес-процесса

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

Элементы partnerLink определяютcя до определения process, а информация об этих элементах будет находиться в Properties of the Tasks BPMN процесса. Tasks of the Process имеют тип Service, и выполняется как WEB-сервис. Определяются в Participant of the Web Service. Participants и их свойства наносятся на карту partnerLink элементов.

Пример 2 показывает два примера того, как Properties, определенные для выполнения WEB-сервисов для Task нанесены на карту partnerLink элементам, определенным в заголовке BPEL документа.

Рисунок 4. Пример 2. Нанесение на карту Web Service Properties для partnerLink

BPEL код для описанного partnerLink приведен в Примере 3.

Рисунок 5. Пример 3. Установка partnerLink элементов для процесса

Элемент variable также определяется до определения process. Свойства связываются с процессом внутри BPMN диаграммы. Инструмент моделирования позволяет проектировщику определить эти свойства. Свойства типа structure используются для того, чтобы сгрупировать набор Properties в пакет, который наносится на карту BPEL элемента message. Элемент message на самом деле определяется WSDL документом, который поддерживает BPEL документ. Элемент variable определяется в BPEL документе и ссылается на элемент message.

Пример 4 демонстрирует два варианта того, как Properties, определенные для Process наносятся на карту элементов variable и message, которые определяются в заголовке BPEL документа и во вспомогательных WSDL документах.

Рисунок 6. Пример 4. Нанесение на карту Mapping Process Properties для BPEL variable и message

BPEL код для определения variable приведен в Примере 5.

Рисунок 7. Пример 5. Установка variable Elements для process

WSDL код для определения message показан в Примере 6.

Рисунок 8. Пример 6. Установка элементов message для WSDL документа

Все стрелки (Sequence Flow) на Рисунке 2, кроме четырех, наносятся на карту BPEL элементов link. Кроме этого process -у понадобятся три элемента link, которых нет на Рисунке 2. Это исключение будет объяснено ниже. Когда элемент flow для process определен, определение link предшествует определению шагов процесса. BPEL код для определения link показан на Рисунке 7. Инструментом моделирования для каждого link автоматически генерится name.

Рисунок 9. Пример 7. Установка элементов link для flow

Старт процеса

Процесс стартует с получения сообщения о необходимости заказать путешествие, которое инициируется Message Start Event (Рисунок 10). После получения требования проверяется информация о кредитной карте. В случае ошибочного номера карты с Check Credit Card действие передается шагу (действию) Handle Fault (Рисунок 2). Карта для этого типа ошибок будет рассмотрена ниже в разделе «Упрвление ошибками».

Рисунок 10. Начало процесса заказа путешествия

Receive Message Start Event — это механизм, который инициирует процесс при получении сообщения о заявке. Это наносится на карту для BPEL элемента receive.

Пример 8 показывает свойства Receive Message Start Event, и как эти свойства наносятся на карту для атрибутов элемента receive.

Рисунок 11. Пример 8. Нанесение на карту Message Start Event

Пример 9 показывает результирующий BPEL код, который генерится для Receive Message Start Event.

Рисунок 12. Пример 9. BPEL код для "Receive" start Event

Заметьте, что на Рисунке 10 на задании Check Credit Card в верхнем углу есть маленькие иконки. Они показывают, как нужно печатать задание. Подобные изображения будут и на последующих рисунках. Эти иконки не являются частью стандарта BPMN, но входят в расширенный BPMN. Ожидается, что инструменты для моделирования будут использовать подобные иконки как дополнительный инструментарий. Месторасположение иконок определяется проектировщиком либо инструментарием. В этой статье они нужны для того, чтобы показать, как диаграмма будет наноситься на карту BPEL.

Задание Check Credit Card следует за Start Event по стрелке(Sequence Flow). Стрелка показывает зависимую связь между элементами , нанесенными на карту от старта до задания. Зависимость примет форму BPEL элемента link ("link1" в Примере 7). Элемент link связывается с шагом с включением элемента source, добавленного к элементу receive (Пример 9) и элемента target, добавленного к первому элементу, нанесенному на карту от Check Credit Card (шаг assign в Примере 11 ниже).

Задание «Check Credit Card» наносится на карту BPEL элементу invoke. Но это задание, как видно на Рисунке 9, имеет две иконки в верхнем углу. Первая иконка (две горизонтальных голубых полосы) показывает, что для основного задания необходимо нанести на карту данные. Некоторые данные, полученные при вводе процесса (Message start Event) наносятся на карту к структуре данных сообщения для Check Credit Card сервиса. Как видно на Рисунке 1, что оригинальный процесс содержит раздельные шаги каждый раз, когда необходимо заносить данные на карту. Однако, многие методологии бизнес-процессов не рассматривают такое занесение данных как раздельные задания, что гарантировало бы им собственную форму и место на диаграмме. Такое занесение данных обычно включается как отдельная пре- или пост-шаговая функция для бизнес-задания, несмотря на то, что она может быть использована в некоторых случаях как автономное задание, как мы позже увидим в процессе. Как и для группы, такое занесение данных может быть определено как свойство задания и занесено на карту BPEL элемента assign. Индивидуальные свойства занесения на карту комбинируются, чтобы стать набором элементов copy внутри элементов assign.

Вторая иконка (розовые и зеленые стрелочки) показывает, что основные функции задания будут сервисами, осуществленными через WEB-сервисы, которые наносятся на карту к BPEL элементу invoke.

Пример 10 показывает свойства задания «Check Credit Card», и как эти свойства наносятся на карту атрибутам assign и invoke.

Рисунок 13. Пример 10. Нанесение на карту задания «Check Credit Card»

На Примере 11 показывается результирующий BPEL код, который генерируется для задания «Check Credit Card».

Рисунок 14. Пример 11. BPEL код для задания «Check Credit Card»

Существуют логические связи, в которых элемент assign должен предшествовать элементу invoke, как определено свойствами задания. Такие связи будут результироваться в BPEL элементе link ("link2"). В этом случае нет соответствующих стрелок на BPMN диаграмме, как это было для link ("link1").

Создание параллельного потока

После задания Check Credit Card возможны три основных действия — резервирование машины, гостиницы и самолета (Рисунок 15). Эти действия не зависят друг от друга, т.к. они могут выполняться одновременно. Резервирование машины наиболее сложное из них, поэтому будет рассмотрено в следующем разделе. В этом разделе затронуто только нанесение на карту данных, которые предшествуют заказу автомобиля.

Рисунок 15. Распараллеливание действий внутри процесса

Распараллеливание обозначается тремя стрелками, выходящими из Check Credit Card. Три действия, на которые указывают стрелки, могут выполняться одновременно. Каждая из трез стрелок превращается в три BPEL элемента link ("link3", "link6" и "link9"). Эти три элемента link включаются в элемент source в Check Credit Card invoke элемента (Пример 11). Они соответствуют target элементу в каждом из трех assign элементов, определенных ниже (Пример 12, Пример 13, Пример 15).

Начнем снизу Рисунка 15. Нанесение на карту для Check Flight Reservation и его свойства такие же, как для Check Credit Card (Пример 10). В этом случае также результат заносится на карту элемента assign, который предшествует invoke элементу. Элемент link ("link4"), для которого нет связующей стрелки, должен быть добавлен для того, чтобы создать логическую зависимость между assign и invoke.

В Примере 12 показан результирующий BPEL код, который генерируется для Check Flight Reservation.

Рисунок 16. Пример 12. BPEL код для задания "Check Flight Reservation"

Задание Check Hotel Reservation очень похоже на Check Flight Reservation. В этом случае элемент assign также предшествует invoke элементу. И снова, элемент link ("link7") создается для того, чтобы создать зависимость между assign и invoke.

Пример 13 приводит результирующий BPEL код, который генерируется для Check Hotel Reservation.

Рисунок 17. Пример 13. BPEL код для задания "Check Hotel Reservation"

Задание в верху Рисунка 15 готовит данные для Check Car Reservation (Рисунок 20). Другие задания на Рисунке 15 имеют скрытую картографию данных, на что указывает иконка в верхнем углу фигуры. Это невозможно для задания резервирования автомобиля (Check Car Reservation), т.к. задание для проверки резервирования находится внутри петли. Нанесение данных на карту нужно один раз, в то время как проверка резервирования может производиться несколько раз. Поэтому нанесение данных на карту выделено в отдельное задание, которое кроме этого ничего больше не делает.

В Примере 14 показаны свойства Data Map задания, и как эти свойства наносятся на карту атрибутов элемента assign.

Рисунок 18. Пример 14. Нанесение на карту "Data Map" задания

Пример 15 воспроизводит результирующий BPEL код, который генерируется для Data Map задания.

Рисунок 19. Пример 15. BPEL код для Data Map задания

Нанесение на карту петли

Петля встречается в той части процесса, где проверяется заказ машины и оценивается результат действия (Рисунок 20).

Рисунок 20. Петля внутри процесса

Два задания могут выполняться множество раз, пока не будет выполнено условие проверки. Петля состоит из решения Gateway, которое разделяет поток в зависимости от достигнутого результата. Стрелка Check Again выходит из Gateway и связывается с ранеестоящим объектом, образуя петлю.

Для случаев, когда Gateway не образует петлю — в нашем примере такая ситуация не рассматривается — нанесение на карту BPEL будет зависить от того, на какой структуре он базируется — на графической (flow) или блочной (sequence).

Для блочной структуры Gateway показыватся как switch. Каждая исходящая стрелочка наносится на карту case элемента внутри switch, и Expression для стрелочки будет наноситься на карту в condition для case.

Для нанесения на карту графической структуры, каждая выходящая из Gateway стрелка наносится на карту отдельным link элементом (входящие в Gateway стрелочки не наносятся на карту BPEL элементов). Condition для каждой стрелочки будут transitionCondition элемента source на шаге, который предшествует Gateway. В нашем случае это invoke от задания Evaluate Reservation Result.

Однако, т.к. петля создана стрелкой из Gateway, и из-за ациклической природы flow, элементы link не могут быть использованы в target элементе, который находится на верхнем шаге flow, это означает, что элемент while создан, чтобы управлять петлей. Содержимое while задает граничные условия для Gateway. Как видно на Рисунке 20, задания Check Car Reservation и Evaluate Reservation Result находятся внутри петли, и наносятся на карту в содержимое BPEL while. Согласно решению для всего процесса, содержимое while будет нанесено на карту для графически структуированных элементов. Это означает, что главный элемент while будет flow, и нанесение на карту BPMN заданий будет соответствовать этому flow.

BPMN Check Again стрелка, которая связывает задание Check Car Reservation имеет разветвляющиеся условия (Condition). Эти Condition обычно заносятся на карту как атрибут condition для while. В нашем случае, однако, условия написаны на языке программирования Java, и расширение формы элемента condition используется для поддержки Java кода.

Пример 16 показывает результирующий BPEL код, который генерируется для петли из Gateway.

Рисунок 21. Пример 16. BPEL код для петли из Gateway

Задание Check Car Reservation и его свойства заносятся на карту invoke элемента. Пример 17 показывает результирующий BPEL код для задания Check Car Reservation.

Рисунок 22. Пример 17. BPEL код задания Check Car Reservation

Задание Evaluate Reservation Result отлично от предыдущих заданий процесса. Для BPMN это задание типа Script. Это означает, что когда процесс доходит до этого задания, сервис не будет вызываться, но движок, который исполняет процесс будет выполнять a-скрипт, который будет определен для этого задания. В нашем случае это скрипт, написанный на языке Java. Скрипт будет проверять результат трех резервирований (гостиница, самолет, машина), и определять, выполнены ли все три удачно или поездка не может быть заказана как планировалось.

Чтобы выполнить скрипт, BPMN действие invoke должно поддерживать Java код, который будет исполнять движок процесса. Расширение будет дополнением элемента script, который содержит элемент javaCode, который, в свою очередь,содержит код скрипта.

Пример 18 показывает свойства задания Evaluate Reservation Result, и как эти свойства наносятся на карту атрибутов элемента invoke.

Рисунок 23. Пример 18. Нанесение на карту задания "Evaluate Reservation Result"

Пример 19 показывает результирующий BPEL код для задания Evaluate Reservation Result.

Рисунок 24. Пример 19. BPEL код для задания "Evaluate Reservation Result"

На Рисунке 20 есть стрелка между Check Car Reservation и Evaluate Reservation Result. Эта стрелка нанесена на карту элемента link ("link13"), который будет называться в source элементе "carReservationRequest" — invoke, и target элементом в "evaluateReservationRequest" invoke. Стрелка между заданием Evaluate Reservation Result и Gateway обозначает конец петли, и, тем самым, конец while. Таким образом, элемент link не требуется.

Синхронизация параллельных потоков

Процесс имеет три параллельных пути, следующих за Check Credit Card. Эти три пути сходятся и синхронизируются перед заданием Confirmation, что представлено Parallel Gateway (Рисунок 25). Это означает, что все три пути должны быть завершены в этой точке, прежде чем процесс будет продолжен.

Рисунок 25. Синхронизация потока внутри процесса

Задания Confirmation выполняет скрипт, написанный на Java. Поэтому оно наносится на BPEL карту так же, как Evaluate Reservation Result и его свойства (Пример 18).

Пример 20 показывает BPEL код для Confirmation.

Рисунок 26. Пример 20. BPEL код для Confirmation

Внутри BPEL кода для process синхронизация путей будет происходить в «Confirmation» invoke. Это не отдельный элемент синхронизации, такой как Parallel Gateway в BPMN. BPEL использует элемент link внутри flow, чтобы создать зависимости, включая синхронизацию, между действиями. Из-за того, что «Confirmation» invoke имеет три target элемента (для "link9","link10","link11" — см. Пример 20), этот invoke должен ожидать, пока получит сигнал от всех трех link элементов, прежде чем сможет быть выполнен. Source элементы для этого элемента будут внутри «flightReservationRequest» invoke, «hotelReservationRequest» invoke и while действия соответственно.

Недостаток joinCondition для «Confirmation» invoke в том, что должен быть хотя бы один положительный сигнал, но фвктически должны быть все три сигнала, положительные или отрицательные, означающие, что все три действия должны быть завершены, тем самым синхронизируя поток.

Заметим, что стрелка Done из Gateway, которая нанесена на карту "link12" элемента link, имеет условие, которое используется для разветвления от Gateway. Таким образом, source элемент с именем "link12" может иметь определение transitionCondition. В действительности в этом нет необходимости, т.к. link "link12" не будет инициироваться до тех пор, пока while, его source не завершится. Это означает, что для каждого transitionCondition для этого link всегда будет истина, когда он запускается. Если есть другая исходящая стрелка из Gateway, тогда Condition для стрелки влияли бы на прохождение процесса.

Конец потока

После задания Confirmation процесс заканчивается отсылкой ответа инициатору процесса (Рисунок 27). Сообщение отсылается в Message End Event.

Рисунок 27. Завершение процесса

Message End Event наносится на карту Reply элемента. К тому же, стрелка от Confirmation до Reply End Event наносится на карту link элементу "link12" c присвоением имен source и target элементам link соответствующих BPEL действий.

Пример 21 показывает свойства Reply Message End Event, и как эти свойства наносятся на карту атрибутам элемента reply.

Рисунок 28. Пример 21. Нанесение на карту "Reply" End Event

Пример 22 показывает результирующий BPEL код, который генерируется для Reply Message End Event.

Рисунок 29. Пример 22. BPEL код для "Reply" Message End Event

Обработка ошибок

Как видно на Рисунке 30, задание Check Credit Card имеет дополнительное событие ошибки, прикрепленное сбоку. Это событие реагирует на специфические ошибки, прерывания задания, и направляет поток по соответствующей стрелке. Ошибка инициируется, если введен неправильный номер кредитной карты.

Рисунок 30. Обработка ошибки в процессе

При возникновении ошибки задание Handle Fault создаст сообщение об ошибке, которое будет отослано инициатору процесса. Reply Message End Event отсылает это сообщение. Это означает, что процесс будет завершен и все остальные действия не понадобятся. Таким образом, дополнительный Event ведет к End Event, прерывая процесс. BPEL механизм для прерванного процесса — это элемент faultHandlers внутри scope. Этот scope является оболочкой всего содержимого процесса, что означает, что основной flow процесса (см. Пример 7) фактически содержится внутри scope-along с faultHandlers. Flow запускается внутри scope, если только он не прерывается faultHandlers.

Содержимое faultHandlers запускается в том случае, если он будет активирован. Это означает, что задание Handle Fault и Reply Message End Event на карте будут находится внутри faultHandlers. Занание Handle Fault — это скрипт, поэтому в BPEL он выглядит так же, как Evaluate Reservation Result (см. Пример 18). Карта Reply End Event выглядит также, как и карта Reply End Event для основного процесса (см. Пример 22).

Соглавно тому, как основной процесс и петля описываются в BPEL, секция обработки ошибок будет размещена внутри flow (внутри faultHandlers). Стрелка от Error Intermediate Event к заданию Handle Fault не будет отображаться link элементом, т.к. задание Handle Fault при нанесении на карту является первым действием внутри flow faultHandlers. А стрелка от Handle Fault к Reply End Event отображается link ("link14") с source и target наименованиями link-ов в соответствующих BPEL действиях.

Пример 23 показывает соответствующий BPEL код, который создается для Process Fault Handling, включая код для Handle Fault и Reply End Event.