Преобразование BPMN в BPEL: почему и как

Источник: oracle

При преобразовании модели BPMN в выполняемый BPEL-процесс важно учитывать семантические различия между BPMN и BPEL.

После приобретения компании BEA несколько новых продуктов пополнили Oracle Business Process Analysis Suite в портфеле Oracle по Business Process Management (BPM) - управлению бизнес-процессами. Эти новые инструменты составили комплект, называемый Oracle Business Process Management Suite (включая Oracle Business Process Management Studio, ранее BEA AquaLogic Business Process Management Studio), который является опцией к Oracle WebLogic Suite.

Oracle Business Process Analysis Suite, дополняющий новый Oracle Business Process Management Suite, может использоваться для моделирования бизнес-архитектуры организации формальным образом с использованием нотации Business Process Modeling Notation (BPMN). Одно из преимуществ использования Oracle Business Process Analysis Suite для моделирования бизнес-процессов заключается в том, что можно повторно использовать эти описания (в нотации BPMN) как blueprints (копии) для исполняемых процессов Oracle Business Process Execution Language (BPEL). [ Прим. редактора : термин blueprint еще неоднократно появится в статье. В буквальном переводе это "синяя печать", или "синька", что в старорусском конструкторском языке обозначало копию чертежа, выполненную на прозрачной бумаге (калька) синим химическим карандашом. Вряд ли автор знаком с реалиями конструкторского обеспечения советского периода, скорее, "синьки" - blueprints были общим инструментом конструкторов и технологов всех стран доКомпьютерной цивилизации. ]

Однако, между BPMN и BPEL есть различия, которые нужно уяснить. Прежде всего, BPMN используется на другой, чем BPEL, стадии жизненного цикла BPM. BPMN используется при проектировании и улучшении бизнес-процесса, а BPEL - при его выполнении. На различных стадиях предъявляются и различные требования. Во-вторых, BPMN используется бизнес-аналитиками, а BPEL - техническими аналитиками и программистами. Они используют различные парадигмы и фокусируются на различных аспектах при моделировании процесса.

В данной статье рассматривается BPMN и BPEL и различия между ними и приводится пример на эту тему.

Предварительно должны быть установлены:

Oracle Business Process Analysis Suite 10.1.3.3 или более поздняя версия
Oracle JDeveloper 10.1.3.3 или более поздняя версия

Жизненный цикл управления бизнес-процессами

BPMN - это нотация, основанная на построении блок-схем, для моделирования бизнес-процессов, она принята как стандарт OMG в феврале 2006. Она предназначена для описания действий или активностей (activities), выполняемых организациями для управления и, если нужно, для улучшения своих бизнес-процессов. Корпорация Oracle предлагает ряд инструментов для поддержки жизненного цикла BPM:

Проектирование (новых) или описание (существующих) бизнес-процессов. Oracle Business Process Architect, компонент Oracle Business Process Analysis Suite, может использоваться для этой задачи. Он предоставляет компании широкие возможности моделирования и проектирования бизнес-процессов, IT-систем, ландшафтов и организационных структур. Бизнес-аналитики могут моделировать бизнес-процесс, используя BPMN или запатентованный (proprietary) язык моделирования цепочки процессов, управляемых событиями, ARIS (ARIS modeling language event-driven process chain (EPC)). Oracle Business Process Management Studio также может использоваться с этой целью; однако, он, как правило, используется не для формального моделирования и проектирования бизнес-процессов в масштабах компании, а в "гибких" (agile) проектах, единственной целью которых является описание (существующего) бизнес-процесса.
Моделирование или имитирование бизнес-процесса. С использованием комплекта Oracle Business Process Analysis suite, бизнес-процессы могут быть имитированы с применением соответствующего компонента (simulation component). Этот компонент позволяет бизнес-аналитикам анализировать процессы, выполняя имитации на основе различных сценариев.
Исполнение процесса. Корпорация Oracle как часть Oracle SOA Suite предлагает движок BPEL Process Manager и Oracle JDeveloper для создания BPEL-приложений. Другая возможность - исполнение процесса в Oracle Business Process Management Studio. (Но это не рассматривается в этой статье.)
Мониторинг процесса. Oracle предлагает для этого как средство класса Business Activity Monitoring, так и несколько аналитических (BI) решений.
Улучшение процесса. Результат мониторинга процесса является входом для улучшений этого процесса. Они могут быть спроектированы, имитированы и выполнены с использованием тех же самых средств.

Так почему же мы не можем просто спроектировать наши процессы, используя BPEL? Дело в том, что BPEL - это язык исполнения, что делает его слишком подробным и техническим при использовании бизнес-аналитиками для описании или проектирования бизнес-процессов. Имея это в виду, комитет по спецификации BPMN постарался с BPMN:

Спроектировать нотацию, которая могла бы использоваться как бизнес-аналитиками, так и техническими аналитиками
Разработать нотацию, которая можно было бы преобразовать в языки исполнения типа BPEL

В целом, они достигли обеих этих целей. Бизнес-аналитики воспринимают BPMN достаточно легко, и на рынке имеется немало продуктов для преобразования BPMN в BPEL. Однако, при таком преобразовании возникают некоторые проблемы. У этих проблем разные корни. В следующей секции я кратко опишу оба этих языка моделирования и подчеркну разницу между ними.

Как понимать BPMN

В нотации BPMN диаграмма бизнес-процесса (BPD) состоит из объектов потока (flow objects), в которой соединены объекты (objects), дорожки (swimlanes) и артифакты (artifacts) (Flow - это, очевидно, поток исполнения/управления процесса. - Пер.). Эта спецификация определяет нотацию и семантику BPD. Oracle Business Process Analysis Suite не соответствует на 100% стандарту BPMN. В этой секции я представлю эти элементы и покажу, как процесс может быть смоделирован с Oracle Business Process Analysis Suite.

Объекты потока

Существует три типа объектов потока(flow objects): активности (activities), события (events) и развилки (gateways).

Активности

Активность (activity) - это работа, выполняемая в бизнес-процессе. Существует три типа активностей: задачи (Tasks), зацикленные активности (looped activities) и подпроцессы (subprocesses). Спецификация Oracle Business Process Analysis Suite не позволяет описывать подпроцессы, но их можно смоделировать, редактируя атрибуты BPMN. Такая же ситуация с зацикленными активностями.

В рамках BPMN-средства поставщики могут добавлять маркеры или иконки, если это не влияет на основу (footprint) диаграммы. В комплекте Oracle Business Process Analysis Suite задачи представляются следующими объектами: функция (function), автоматизированная активность (automated activity), уведомление (notification), задача с участием человека (human task) и функция бизнес-правил (business rule function).

События

Событие (event) - это нечто, что происходит во время бизнес-процесса. Оно обычно инициируется чем-то и/или имеет результат. Тип события зависит от места в бизнес-процессе. Есть три типа событий: стартовое событие (start event), промежуточное событие (intermediate event) и конечное событие (end event). В нотации BPMN триггер и результат могут быть смоделированы с использованием окна атрибутов (attributes dialog box).

Развилки

Развилки (Gateways) - это последняя категория объектов потока. Существуют различные типы развилок. Все они сливают (воедино) и разделяют (ветвят) поток. Если поток не нужно контролировать, то развилка не нужна. В комплекте Oracle Business Process Analysis Suite можно моделировать XOR (exclusive or - либо, либо) развилки (на основе данных и событий), OR, AND и сложные развилки.

Соединяющие объекты

Соединяющими объектами (connecting objects) могут быть последовательные потоки (sequence flows), коннекторы (connector) (который соединяет две активности), потоки сообщений (message flows) или потоки ассоциаций (association flows).

Дорожки

В нотации BPMN есть два типа дорожек ( swimlanes ): пулы (pools) и линии (lanes). Пулы используются для обозначения границ организации. Взаимодействия между пулами осуществляются через потоки сообщений (message flows). Последовательным потокам (Sequence flows) не разрешается пересекать границу пула. Это означает, что процесс всегда полностью содержится внутри пула. Lanes могут использоваться для разделения пула - например, чтобы определять различные организационные роли в организации. Последовательные потоки могут пересекать линии.

Артифакты

Последняя категория объектов в BPMN - это артифакты. Существует три типа артифактов: объекты данных (data objects), группы (groups) и аннотации (annotations). Аннотации и группы не поддерживаются в Oracle Business Process Analysis Suite. Объекты данных состоят из группы различных типов: person type function, data cluster и т.д.

Пример BMPN

Зная, какие объекты могут появиться в BPD, мы можем начать пример. В этом примере мы смоделируем часть процесса публикации статьи на Oracle Technology Network (OTN).

Этот процесс начинается после того, как одобрено резюме (abstract). Оно моделируется как стартовое событие (start event) с сообщением. Соответствующий маркер показывается, когда вы выбираете Message в BPMN attribute Trigger/Result.

[ Рассмотрим пример. ] Статья написана и передана на редактирование. Артифакт "Статья" используется для описания информационного носителя. Затем автор ожидает результатов редактирования статьи. Когда статья с замечаниями получена, автор просматривает ее. В зависимости от замечаний редакторов процесс либо заканчивается, либо статья вновь предлагается редакторам, что моделируется развилкой 'exclusive-or-data' и последовательным потоком, направленным обратно к 'edit article'. Процесс заканчивается публикацией статьи.

Как видно, в данном случае имеют место три события: стартовое событие, промежуточное событие и конечное событие. Есть одна развилка типа "exclusive or". И три активности, все они задачи. Все поточные объекты соединены с использованием последовательных потоков. Есть два артифакта: статья, посланная в OTN, и замечания на нее, посланные автору. Они соединены к задачам с использованием ассоциаций (associations). В этой диаграмме мы смогли добавить два пула: один для автора и один для OTN.

Общепринятая практика - это идентификация различных уровней абстракции в процессных моделях. Самые подробные процессы содержат информацию, которая соединяет процесс с IT-системами; более абстрактные модели - нет.

Назначение этих процессных моделей - визуализация бизнес-процессов в организации. Эти модели могут использоваться в различных целях: для автоматизации процесса с IT-сервисами с целью его поддержки и улучшения, для написания инструкций для служащих, для показа аудиторам соответствия требованиям регуляторов (compliance), для получения углубленного представления (insight) о бизнесе. В этой статье будет использоваться вышеизложенная модель для автоматизации и мониторинга процесса сдачи статьи. Для этого ее нужно преобразовать в выполняемый язык BPEL. А перед этим создается вариант конкретного процесса со специфическими деталями реализации. Определяются задачи с участием человека (human tasks) как активности "write article" (писать статью) и "review revision" (учесть замечания). Таким образом, можно контролировать сроки (deadlines) и состояние всего процесса. "Submit article" (предложить статью) преобразуется в уведомление.

BPEL

BPEL включает базисные (basic) и структурированные (structured) активности, переменные, партнерские линки и обработчики (handlers). Для описания всего этого используется XML. Oracle SOA Suite поддерживает спецификацию BPEL4WS 1.1. Кроме того, Oracle добавил расширения, которых в ней нет. Последняя спецификация - это финальная спецификация BPEL 2.0; она может быть найдена на OASIS site .

Активности

В языке BPEL два типа активностей: базисный и структурированный. Базисные активности, с которыми можно работать в Oracle SOA Suite 10g, включают invoke (вызывать), receive (получить), reply (ответить), assign (назначить), throw (направить), wait (ждать), terminate (прервать) и transform (преобразовать). Структурированные активности используются для комбинирования базисных активностей. Следующие активности этого типа поддерживаются в Oracle SOA Suite 10g: sequence (последовательность), flow (поток), flowN (потокN), switch (переключатель), while (пока) и pick (выбрать).

Переменные

Переменные (Variables) используются для запоминания сообщений, которыми обмениваются, и для запоминания состояния процессов. Существует три типа переменных:

Simple type (простой тип). Этот тип переменной содержит простые типы XML Schema (такие, как string (строка), date (дата) и т.д.).
Message type (Тип сообщения). Этот тип содержит сообщение формата WSDL.
Element (элемент). Этот тип содержит элемент XML Sshema.

Переменные могут быть объявлены в начале процесса (global variables - глобальные переменные) или в пределах области применения.

Партнерские линки

Линки/связи (Partner links) к (внешним) сторонам, с которыми взаимодействует BPEL-процесс, - это партнерские линки (Partner links). Партнер может вызывать BPEL-процесс или вызываться им, или пребывать в обеих этих ролях.

Обработчики

Обработчики (Handlers) используются, когда происходит ошибка (fault handlers - обработчики ошибок), для реагирования на события и для выполнения компенсации execute compensation.

BPEL-пример

В директории примеров Oracle SOA Suite есть очень простой пример, который показывает некоторые концепции, о которых мы только что говорили:

<!-- HelloWorld BPEL Process -->
<process name="HelloWorld"
         targetNamespace="http://samples.otn.com/helloworld"
         suppressJoinFailure="yes"
         xmlns:tns="http://samples.otn.com/helloworld"
         xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
         xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
         >
         
    <!-- List of services participating in this BPEL process -->    
    <partnerLinks>
        <!--
        The 'client' role represents the requester of this service. It is 
        used for callback. The location and correlation information associated
        with the client role are automatically set using WS-Addressing.
        -->
        <partnerLink name="client"
                     partnerLinkType="tns:HelloWorld"
                     myRole="HelloWorldProvider"
                     partnerRole="HelloWorldRequester"
                     />
    </partnerLinks>
  
    <!-- List of messages and XML documents used as part of this 
         BPEL process 
         -->    
    <variables>
        <!-- Reference to the message passed as input during initiation -->
        <variable name="input"
                  messageType="tns:HelloWorldRequestMessage"/>
                  
        <!-- Reference to the message that will be sent back to the 
             requestor during callback
             -->
        <variable name="output"
                  messageType="tns:HelloWorldResultMessage"/>
    </variables>

    <!-- Orchestration Logic -->
    
    <sequence>
        
        <!-- Receive input from requestor. 
             Note: This maps to operation defined in HelloWorld.wsdl 
             -->
        <receive name="receiveInput" partnerLink="client"
                 portType="tns:HelloWorld"
                 operation="initiate" variable="input"
                 createInstance="yes"/>
        
        <!-- Generate content of output message based on the content of the
             input message.
             -->
        <assign>
            <copy>
                <from expression="concat('Hello ',bpws:getVariableData('input', 'payload','/tns:name'))"/>
                <to variable="output" part="payload" query="/tns:result"/>
            </copy>
        </assign>

        <!-- Asynchronous callback to the requester.
             Note: the callback location and correlation id is transparently handled 
             using WS-addressing.
             -->
        <invoke name="replyOutput" 
                partnerLink="client"
                portType="tns:HelloWorldCallback"
                operation="onResult" 
                inputVariable="output"
                />
    </sequence>
</process>

Как можно видеть, это асинхронный BPEL-процесс, который получает сообщение, запомненное в переменной "input". Далее в процессе результат конкатенации "Hello" и содержания этого сообщения присваивается переменной "output". Затем это возвращается запрашивающей стороне через активность invoke. В этом примере всего один партнерский линк: клиент, который вызвал процесс, он же получает ответ.

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

В языке BPEL нет оператора Goto

Теперь после обсуждения обоих языков давайте рассмотрим трансляцию от BPMN к BPEL.

В самом общем виде следующее отображение используется в Oracle Business Process Analysis Suite при генерации BPEL-процесса из BPMN-диаграммы:

Все активности (automated, function, notification и т.д.) отображаются в некоторой области. Соответствующие сервисы также генерируются. Например: генерируется сервис уведомления, а также те BPEL-артифакты, которые вызывают этот сервис.
Стартовые сервисы преобразуются в активности получения, за исключением того случая, когда не определен триггер. Если триггер типа 'multiple' определен, генерируется активности типа pick. Сообщение-таймер будет преобразовано в отдельный процесс, который вызывает сгенерированное сообщение о получении (receive message).
Конечные события преобразуются в активности типа invoke, reply, throw, compensation element (элемент компенсации), активность типа terminate и т.д. Тип такого рода активностей зависит от типа результата. Если тип результата не смоделирован, активность не будет сгенерирована в BPEL.
Развилки преобразуются в switch, pick или flow в зависимости от типа развилки и типа объекта потока, который следует за этой развилкой.
Дорожки (Swimlanes) не отображаются в BPEL.
Соединяющие объекты (Connecting objects), как правило, не отображаются в BPEL. (см. спецификацию для некоторых исключений - таких, когда flow используются)
Бизнес-данные отображаются в переменные.
Подпроцессы не отображаются в BPEL scope; они отображаются в активности типа invoke.

Спецификация BPMN объясняет отображение подробно в приложении Annex A. Это отображение не полно, так что не удивляйтесь, если применение различных инструментальных средств приведет к различным правилам преобразования.

Приложение-пример

Для тестирования нашего примера с Oracle JDeveloper и Oracle Business Process Analysis Suite мы сначала импортируем SOA-профили в Oracle Business Process Analysis Suite и затем преобразуем BPMN-диаграмму в BPEL. Потом перейдем к Oracle JDeveloper, инсталлируем Oracle Business Process Analysis Suite plug-in для Oracle JDeveloper и начнем проект, исходя из этого. Мы будем использовать пример процесса из предыдущих параграфов. Сначала мы добавим некоторые детали к этому процессу. Раз вы решили реализовать этот процесс, вы должны решить, какие активности будут автоматизированными, с участием человека (human tasks), какие сообщения будут использоваться при обмене и т.д.

Импортируйте базу данных из этого примера.
1. Перейдите к Explorer view, кликнув его иконку
2. Кликните по правой клавише Right-click LOCAL и выберите Restore…
3. Перейдите к OTN.adb (см. sample code zip) и кликните OK
Импортируйте SOA-профили.
1. Создайте новую группу в базе данных OTN в месте, куда вы хотите импортировать SOA-профили и назовите ее "SOA profiles".
2. Кликните по правой клавише SOA Profiles и выберите SOA, а затем Import SOA profiles.... (см. рисунок ниже)
3. Ответьте Yes, если будет вопрос, надо ли использовать только что выбранную группу. Когда профили будут успешно импортированы, появляется уведомление.
генерируйте BPEL-процесс.
1. Перейдите к процессу, который мы создали ранее (WriteAndReviewArticle).
2. Кликните по правой клавише the claims process и выберите SOA, а затем Transform business process into BPEL process....
3. Кликните Yes, чтобы проверить (validate) этот бизнес-процесс.
4. Примите все значения по умолчанию и кликните Finish.
Просмотрите сгенерированный BPEL.
1. Кликните по правой клавише этот процесс.
2. Выберите Go to BPEL process.

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

Инсталлируйте Oracle Business Process Analysis Suite plug-in в Oracle JDeveloper.
1. Распакуйте pcbpel_bundle.zip в директорию.
2. Повторно стартуйте Oracle JDeveloper.
Создайте соединение к серверу Oracle Business Process Analysis Suite.
1. Перейдите к Connections Navigator.
2. Кликните по правой клавише Oracle BPA Server и выберите New BPA Server Connection....
3. Введите установки (settings) (в этом случае мы используем локальный Oracle Lite server со значениями по умолчанию username/password system/manager).
4. Протестируйте это соединение на Test tab.
создайте новый BPEL-проект на базе blueprint.
1. Выберите New... и затем BPEL Process project.
2. Выберите Existing Blueprint в мастере (wizard).
3. Выберите этот blueprint из списка, кликая по иконке Browse BPA Server.
4. Выберите эту WriteAndEditArticle копию (blueprint)
5. Кликните Next.
6. Оставьте значения по умолчанию для входных и выходных элементов и выберите Finish.
Теперь скелет BPEL-процесса перенесен в Oracle JDeveloper. Разработчик добавляет детали, нужные для реализации, этому процессу. Структура модели защищена: разработчик может добавлять новые области применения (scopes) между существующими, но не может удалять какие-либо существующие. Новые версии этой модели на BPMN могут быть импортированы из Oracle JDeveloper.

Изменения в процессе, сделанные в Oracle JDeveloper, видимы в Oracle Business Process Analysis Suite как предложения по улучшению после того, как вы их выгрузите из Oracle JDeveloper. Их можно обнаружить через explorer view в Oracle Business Process Analysis Suite.

Обработка несовместимых процессов Handling Incompatible Processes

Одна типичная проблема заключается в том, что при преобразовании правильной (valid) BPMN-модели в BPEL-процесс генерируются ошибки. Это, как правило, происходит если две или более активностей "текут" обратно (flowing back) к предыдущей активности. Это следует из того факта, что BPMN поддерживает произвольные (arbitrary) циклы, а BPEL - только структурированные циклы с одной входной и одной выходной точкой (while).

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

Когда вы проверяете этот бизнес-процесс, Oracle Business Process Analysis Suite сообщит, что эта BPMN-диаграмма верна. Но когда вы преобразуете ее в BPEL-процесс, то получите следующую ошибку:

Как вы видите, это семантическая ошибка: это верно в BPMN, но не может быть преобразовано в [Q: "into"?] BPEL. Диаграмма показывает ошибку в активности write article:

Есть несколько решений этой проблемы. Обычно наилучшим способом ее разрешения является удаление обобщений (generalizations) из процесса. Обобщения, которые вы делаете в IT-системах, не имеют места в бизнес-процессе. Например, в бизнес-процессе есть различие между первым (напишите статью и предложите ее) и последующим действиями. Вы не можете избежать первого редактирования и замечаний, но каждое действие-редактирование после этого должно быть сведено к минимуму. Поэтому вместо редактирования статьи мы создаем новую активность с названием correct article (корректирование статьи). В наших IT-системах мы, очевидно, хотим повторно использовать компоненты и сервисы при выполнении этих активностей. Мы также добавляем событие, чтобы показать, что мы ожидаем сообщения о замечаниях (revision) или публикации. Наконец, мы также изменяем поток реакций на замечания (review flow): даже если автор согласен со всеми изменениями, сделанными редактором, он все-таки должен явно одобрить эти изменения. Суммируя, мы изменяем модель следующим образом:
1. мы добавляем развилку чтобы различить разные сообщения от издателя: сообщение с замечаниями (revision message) и сообщение о публикации (publication message).
2. мы добавляем новую активность: accept revision (принять замечания).
3. мы добавляем еще одну активность: correct article (вместо edit article).
4. и мы добавляем активность: resend article (повторно отослать статью - вместо send article).
Этот поток процесса по-прежнему относительно легко понимать. Мы можем теперь сгенерировать его копию (blueprint) и начать редактировать его в Oracle JDeveloper. Результирующая BPEL-модель немного сложнее. Поэтому отметим, чтобы чего-либо не упустить: чем больше потоков и циклов в BPMN-диаграмме, тем больше отличий будет в соответствующей BPEL-модели. BPEL-модель будет также расширена с назначениями (assignments) и действиями копирования (copy actions), которые сугубо техничны по своей природе. Коммуникации между разработчиками и бизнес-пользователями становятся труднее, так как модели отличаются между собой; это усложняет решение проблем, добавление функций и улучшение бизнес-процессов. Все это надо учитывать при проектировании процессов в Oracle Business Process Analysis Suite. Организуя процессы в модули меньшего размера и с использованием различных уровней абстракции может значительно сократить расхождения между BPMN и BPEL.

Решение, которое описано в этой статье, очевидно, работает только тогда, когда бизнес-процессы могут быть переписаны. Иногда встречаются процессы с истинным go-to. В таком случае реализация процесса может быть выполнена легче с использованием Oracle BPM studio.

Заключение

В этой статье было показано, как преобразовать модель BPMN из Oracle Business Process Analysis Suite в выполняемый BPEL-процесс, генерируя корию (blueprint). При использовании этого метода важно учитывать семантическую разницу между BPMN и BPEL. Обобщения должны быть сведены к техническим аспектам: BPEL и сервисам. Это позволяет легче менять процесс и транслировать его в BPEL.

Ссылки по теме