К возможности языка моделирования bpel bussenes process execute language бизнес процессов относится

Исполняемый язык компьютера

Язык выполнения бизнес-процессов веб-служб (WS- BPEL ), широко известный как BPEL (Business Process Execution Language ), представляет собой стандартный исполняемый язык OASIS для определения действий в рамках бизнес-процессов. с веб-службами. Процессы в BPEL экспортируют и импортируют информацию исключительно с использованием интерфейсов веб-сервисов.

Содержание

• 1 Обзор
• 2 Программирование в большом / малом
• 3 История
• 4 Темы
  • 4.1 Цели проектирования
  • 4.2 Язык BPEL
  • 4.3 Связь BPEL с BPMN
  • 4.4 Добавление поддержки «программирование в малом» к BPEL
  • 4.5 BPEL4People
    • 4.5.1 Цели
  • 4.6 WS-BPEL 2.0
• 5 См. Также
• 6 Ссылки
• 7 Дополнительная литература

Обзор

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

1. Исполняемый бизнес-процесс: моделирует реальное поведение участника бизнес-взаимодействия.
2. Абстрактный бизнес-процесс: это частично определенный процесс, который не предназначен для выполнения. В отличие от исполняемых процессов, абстрактный процесс может скрывать некоторые требуемые конкретные операционные детали. Абстрактные процессы выполняют описательную роль с более чем одним возможным вариантом использования, включая наблюдаемое поведение и / или процесс шаблон .

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

Таким образом, он сериализован в XML и нацелен на обеспечение программирования в целом.

Программирование в большом / малом

Концепции программирования в большом и программирование в малом различают два аспекта написания типа длительно выполняющихся асинхронных процессов, которые обычно встречаются в бизнесе. процессы:

1. Программирование в целом обычно относится к высокоуровневым переходам между состояниями взаимодействия процесса. BPEL называет эту концепцию абстрактным процессом. Абстрактный процесс BPEL представляет собой набор общедоступных моделей поведения в стандартизированной форме. Абстрактный процесс включает такую ​​информацию, как, например, когда ждать сообщений, когда отправлять сообщения, когда компенсировать неудачные транзакции и т. Д.
2. Программирование в малых, напротив, имеет дело с короткими — живое программное поведение, часто выполняемое как единая транзакция и предполагающее доступ к локальной логике и ресурсам, таким как файлы, базы данных и так далее.

История

Истоки WS-BPEL восходят к языку потока веб-служб (WSFL) и Xlang.

. В 2001 году IBM и Microsoft имели каждый определили свои собственные довольно похожие языки «программирование на большом »: WSFL (язык потока веб-сервисов) и Xlang соответственно. Microsoft даже пошла дальше и создала вариант сценария под названием XLANG / s, который позже будет служить основой для их служб оркестровки внутри их BizTalk Server. Они специально задокументировали, что этот язык «проприетарный и не полностью задокументирован».

С появлением и популярностью BPML, а также растущим успехом BPMI.org и движения за открытую BPMS, возглавляемого JBoss и Intalio Inc., IBM и Microsoft решил объединить эти языки в новый язык, BPEL4WS. В апреле 2003 года BEA Systems, IBM, Microsoft, SAP и Siebel Systems представили BPEL4WS 1.1 в OASIS для стандартизации через Технический комитет Web Services BPEL. Хотя BPEL4WS появился как в версии 1.0, так и в версии 1.1, 14 сентября 2004 года технический комитет OASIS WS-BPEL проголосовал за название своей спецификации «WS-BPEL 2.0». (Это изменение в названии привело BPEL в соответствие с другими стандартными соглашениями об именах веб-служб, которые начинаются с «WS-» (аналогично WS-Security), и учитывает значительные улучшения, сделанные между BPEL4WS 1.1 и WS-BPEL 2.0.) Если не обсуждать В конкретной версии обычно используется прозвище BPEL .

В июне 2007 года Active Endpoints, Adobe Systems, BEA, IBM, Oracle и SAP опубликовали спецификации BPEL4People и WS-HumanTask, в которых описывается взаимодействие человека в процессы BPEL могут быть реализованы.

Темы

Цели проектирования

С BPEL было связано десять исходных целей проектирования:

1. Определение бизнес-процессов, которые взаимодействуют с внешними объектами посредством операций веб-сервисов, определенных с помощью WSDL 1.1, и они проявляются как веб-службы, определенные с помощью WSDL 1.1. Взаимодействия являются «абстрактными» в том смысле, что зависимость зависит от определений portType, а не от определений портов.
2. Определяйте бизнес-процессы с помощью языка на основе XML. Не определяйте графическое представление процессов и не предоставляйте какую-либо конкретную методологию проектирования для процессов.
3. Определите набор концепций оркестровки веб-служб, которые предназначены для использования как во внешнем (абстрактном), так и во внутреннем (исполняемом) представлениях бизнес-процесса. Такой бизнес-процесс определяет поведение отдельного автономного объекта, обычно работающего во взаимодействии с другими аналогичными одноранговыми объектами. Признано, что для каждого шаблона использования (т. Е. Абстрактного представления и исполняемого представления) потребуется несколько специализированных расширений, но эти расширения должны быть сведены к минимуму и проверены на соответствие таким требованиям, как импорт / экспорт и проверка соответствия, которые связывают два использования. шаблоны.
4. Обеспечивают как иерархические, так и графические режимы управления и позволяют максимально плавно комбинировать их использование. Это должно уменьшить фрагментацию пространства моделирования процессов.
5. Предоставлять функции манипулирования данными для простого манипулирования данными, необходимыми для определения данных процесса и потока управления.
6. Поддержка механизма идентификации для экземпляров процесса, которые позволяет определять идентификаторы экземпляров на уровне сообщений приложения. Идентификаторы экземпляров должны определяться партнерами и могут изменяться.
7. Поддерживать неявное создание и завершение экземпляров процессов в качестве основного механизма жизненного цикла. Расширенные операции жизненного цикла, такие как «приостановка» и «возобновление», могут быть добавлены в будущих выпусках для расширенного управления жизненным циклом.
8. Определите модель длительной транзакции, основанную на проверенных методах, таких как действия компенсации и определение объема для поддержки сбоя восстановление для частей давно выполняемых бизнес-процессов.
9. Используйте веб-службы в качестве модели для декомпозиции и сборки процессов.
10. Постройте как можно больше стандартов веб-служб (утвержденных и предлагаемых) в компонуемость и модульность.

Язык BPEL

BPEL — это язык оркестровки, а не язык хореографии. Основное различие между оркестровкой и хореографией — исполнимость и контроль. Оркестровка определяет исполняемый процесс, который включает обмен сообщениями с другими системами, так что последовательности обмена сообщениями контролируются разработчиком оркестровки. Хореография определяет протокол для одноранговых взаимодействий, определяя, например, юридические последовательности сообщений, которыми обмениваются, с целью гарантировать совместимость. Такой протокол не является исполняемым напрямую, поскольку он допускает множество различных реализаций (процессов, которые ему соответствуют). Хореография может быть реализована путем написания оркестровки (например, в форме процесса BPEL) для каждого участника, участвующего в ней. Различия в оркестровке и хореографии основаны на аналогиях: оркестровка относится к центральному контролю (дирижером) поведения распределенной системы (оркестр, состоящий из многих игроков), тогда как хореография относится к распределенной системе (танцевальная команда). который действует по правилам (хореография), но без централизованного управления.

Сосредоточение внимания BPEL на современных бизнес-процессах, а также истории WSFL и XLANG привело BPEL к принятию веб-сервисов в качестве своего внешнего механизма связи. Таким образом, средства обмена сообщениями BPEL зависят от использования языка описания веб-служб (WSDL) 1.1 для описания исходящих и входящих сообщений.

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

• Механизм корреляции сообщений на основе свойств
• Типизированные переменные XML и WSDL
• Модель расширяемого языкового модуля, позволяющая писать выражения и запросы на нескольких языках: BPEL поддерживает XPath 1.0 по умолчанию
• конструкции структурного программирования, включая if-then-elseif-else, в то время как, последовательность (для включения выполнения команд по порядку) и поток (для включения параллельного выполнения команд)
• A область видимости система, позволяющая инкапсулировать логику с локальными переменными, обработчики ошибок , обработчики компенсации и обработчики событий
• Сериализованные области для управления параллельным доступом к переменным.

Связь BPEL с BPMN

Там не является стандартной графической нотацией для WS-BPEL, поскольку технический комитет OASIS решил, что это выходит за рамки. Некоторые производители изобрели свои собственные обозначения. Эти нотации используют тот факт, что большинство конструкций в BPEL имеют блочную структуру (например, последовательность, while, pick, scope и т. Д.). Эта функция обеспечивает прямое визуальное представление описаний процессов BPEL в форме структурограмм в стиле напоминает диаграмму Насси – Шнейдермана.

Другие предложили использовать существенно другой язык моделирования бизнес-процессов, а именно Модель и нотацию бизнес-процессов (BPMN), в качестве графического интерфейса для захвата Описание процессов BPEL. В качестве иллюстрации осуществимости этого подхода спецификация BPMN включает неформальное и частичное отображение от BPMN к BPEL 1.1. Более подробное отображение BPMN в BPEL было реализовано в ряде инструментов, включая инструмент с открытым исходным кодом, известный как BPMN2BPEL. Однако разработка этих инструментов выявила фундаментальные различия между BPMN и BPEL, которые делают очень трудным, а в некоторых случаях невозможным создание удобочитаемого кода BPEL из моделей BPMN. Еще более сложной является проблема проектирования BPMN-to-BPEL туда и обратно : генерация кода BPEL из диаграмм BPMN и поддержание исходной модели BPMN и сгенерированного кода BPEL синхронизированными, в том смысле, что любая модификация одного распространяется на другие.

Добавление поддержки «программирование в малом» в BPEL

управляющие структуры BPEL, такие как «if-then-elseif-else» и «while», а также его Возможности управления переменными зависят от использования «программирования на малых» языках для обеспечения логики. Все реализации BPEL должны поддерживать XPath 1.0 в качестве языка по умолчанию. Но дизайн BPEL предусматривает расширяемость, чтобы разработчики систем могли использовать и другие языки. BPELJ — это усилие, связанное с JSR 207, которое может позволить Java функционировать как «программирование на малом» языке внутри BPEL.

BPEL4People

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

Чтобы восполнить этот пробел, BPEL4People расширил BPEL от оркестровки одних только веб-сервисов до оркестровки человеческой деятельности на основе ролей.

Цели

В контексте бизнес-процесса BPEL4People

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

путем расширения BPEL дополнительным независимым синтаксисом и семантикой.

Спецификация WS-HumanTask вводит определение человеческих задач и уведомлений, включая их свойства, поведение и набор операций, используемых для управления человеческими задачами. Протокол координации вводится, чтобы управлять автономностью и жизненным циклом человеческих задач с поддержкой сервисов во взаимодействии.

Спецификация BPEL4People представляет расширение WS-BPEL для решения проблем взаимодействия людей в WS-BPEL как гражданин первого класса. Он определяет новый тип основной деятельности, в которой в качестве реализации используются неавтоматизированные задачи, и позволяет определять задачи, локальные для процесса, или использовать задачи, определенные вне определения процесса. Это расширение основано на спецификации WS-HumanTask.

WS-BPEL 2.0

В версии 2.0 были внесены некоторые изменения и новые функции:

• Новые типы действий: repeatUntil, validate, forEach (параллельный и последовательный), rethrow, extensionActivity,pensateScope
• Переименованные действия: переключатель / case переименован в if / else, terminate переименован в exit
• Обработчик завершения добавлен в действия области для обеспечения явного поведения для завершения
• Инициализация переменной
• XSLT для преобразования переменных (Новая функция расширения XPath bpws: doXslTransform)
• Доступ XPath к данным переменных (синтаксис переменной XPath $ variable [.part] / location)
• Переменные схемы XML в Интернете действия службы (для взаимодействия служб стиля WS-I doc / lit)
• Локально объявленный messageExchange (внутренняя корреляция действий приема и ответа)
• Разъяснение абстрактных процессов (синтаксис и семантика)
• Включение переопределения языка выражений для каждого действия

См. Также

• BPEL4People
• BPELscript
• Модель бизнес-процесса и Обозначение
• Моделирование бизнес-процессов
• Список механизмов BPEL
• Язык разговора веб-служб
• Рабочий процесс
• WS-CDL
• Язык определения процессов XML
• Еще один язык рабочего процесса

Ссылки

Дополнительная литература

Книги по BPEL 2.0

• SOA для бизнес-разработчиков: концепции, BPEL и SCA. ISBN 978-1-58347-065-7

В 2000 г. в Калифорнии была основана некоммерческая организация Business Process Management Initiative (Инициатива по управлению бизнес-процессами, сокр. BPMI). Она поставила своей целью разработку и продвижение открытых, полных и бесплатных стандартов на основе языка XML для поддержки и развития систем BPM в бизнесе (Business Process Management — управление бизнес-процессами).

В марте 2001 г. эта организация опубликовала язык моделирования бизнес-процессов (Business Process Modeling Language, сокр. BPML), в ноябре 2002 г. — спецификацию для графического представления моделирования бизнес-процессов (Business Process Modeling Notation, сокр. BPMN). Последняя версия BPMN-спецификации была выпущена в мае 2004 г. Все это доступно для загрузки на сайте BPMI (http://www.bpmi.org/). Вскоре ожидается появление еще одного продукта — языка запросов для бизнес-процессов (Business Process Query Language, сокр. BPQL).

Язык BPML дополняет язык реализации бизнес-процессов (Business Process Execution Language, сокр. BPEL). BPML может использоваться для определения детальных бизнес-процессов, исполняемых при вызове каждого web-сервиса. BPML преобразует («мэппирует») бизнес-операции в обменные сообщения. Этот язык может использоваться для определения корпоративных бизнес-процессов, комплексных web-сервисов и многостороннего сотрудничества. В разработке BPML-спецификаций участвует целый ряд организаций: CSC, Intalio, SAP, Sun, SeeBeyond, Versata и др.

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

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

Простые типы операций BPML

● Action: выполняет или вызывает выполнение операции, включающей обмен входящими и исходящими сообщениями.

● Assign: присваивает новое значение показателю.

● Call: запускает процесс и ждет его завершения.

● Compensate: инициирует компенсацию для указанных процессов.

● Delay: выражает промежуток времени.

● Empty: ничего не делает.

● Fault: выдает сообщение об ошибке в текущем контексте.

● Raise: активизирует сигнал.

● Spawn: запускает процесс без ожидания его завершения.

● Synch: синхронизирует по сигналу.

Сложные типы операций BPML

● All: выполняет операции параллельно.

● Choice: выполняет операции из одного из составных комплектов, выбранного в ответ на событие.

● Foreach: однократно выполняет операции для каждого пункта из списка.

● Sequence: выполняет операции в последовательном порядке.

● Switch: выполняет операции из одного из составных комплектов, выбранного на основе истинного значения условия.

● Until: выполняет операции один или более раз на основе истинного значения условия.

● While: не выполняет операции или выполняет их один или более раз на основе истинного значения условия.

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

Простые операции — это операции, которые могут привести к выполнению множественных операций, в частности такие, как action, call, compensate и spawn. Но сама простая операция не определяет контекст для выполнения других операций. Приведенный ниже краткий обзор языка дает более детальный анализ разницы между сложными и простыми операциями и показывает, что BPML включает все логические конструкции строгого языка программирования.

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

Сложная операция также определяет, сколько раз должны быть выполнены операции из общего набора операций. Для этого используются следующие стандартные логические конструкции: операция until — повторяет выполнение операций, пока значение условия не станет истинным; операция while — повторяет выполнение операций, пока значение условия остается истинным; и операция foreach — выполняет операции однократно для каждого пункта списка. Все остальные названные выше сложные операции выполняют действия из комплекта операций однократно.

Помимо этого, сложная операция определяет порядок выполнения других операций. Операция sequence обеспечивает выполнение всех действий из комплекта операций в последовательном порядке. Операция all обеспечивает выполнение всех действий из комплекта операций одновременно. Остальные сложные операции языка BPML обеспечивают выполнение операций в последовательном порядке.

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

Простые операции прерывают выполнение (abort) или выдают сообщение об ошибке (fault), если их завершению препятствует неожиданная ошибка. Сложные операции прерываются и разрываются, если одно из действий, входящих в их состав, разрывается таким образом, что его восстановление невозможно.

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

BPEL и BPML — это похожие подходы к решению одной и той же проблемы: определение логики процессов в языке XML таким образом, чтобы результат мог использоваться как исполняемый код программными продуктами на основе BPM. Это развивающиеся языки. Все эти продукты являются решениями одной и той же проблемы, их спецификации и языки концептуально похожи, поэтому со временем они, возможно, будут объединены в единую спецификацию.

Публикации

● Клайв Финкелстайн (Clive Finkelstein). «Корпорация: языки управления бизнес-процессами. BPML» (The Enterprise: Business Process Management Languages Part 2: BPML).

● Сайторганизации Business Process Management Initiative: http://www.bpmi.org/.

Пройдясь поиском по Хабрахабру, удалось обнаружить не так уж и много информации, посвященной, надо сказать, не очень распространённому языку BPEL (Business Process Execution Language). Если говорить в общем, то BPEL – это язык, основанный на формате XML, который позволяет описывать логику бизнес-процессов через использование веб-служб.

Реализаций движков, позволяющих создавать процессы с использованием этого языка, мне известно не так уж и много. В частности, можно упомянуть Oracle BPEL Process Manager и продукт, о котором пойдет речь дальше – Serena Business Manager (SBM). SBM позволяет быстро создавать web-приложения, автоматизирующие какой-нибудь процесс. В модели процесса (workflow) предусмотрена возможность в момент изменения состояния вызвать внешнюю web службу. А если нужно реализовать какую-нибудь логику и одного вызова недостаточно? Вот тут и пригодится процедура, написанная на языке BPEL и исполняемая средствами той же платформы BPM.

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

Задача была поставлена следующим образом – разработать функционал копирования бизнес-сущностей (в моём процессе – TD Links), но не просто так, а с предварительным опросом стороннего веб-сервиса. Этот сервис (bridge) обладает методом, принимающим на вход некоторые атрибуты объекта TD Link. Затем bridge опрашивает стороннюю систему и в ответ сообщает, может ли объект с такими атрибутами существовать в нашей системе. Как он это делает меня не интересует, bridge для меня является «чёрным ящиком».

Кроме того, мне потребовался ещё один веб-сервис, реализующий функции работы с бизнес-сущностями в нашей системе (чтение, создание и т.д.). Называть его буду AppServices.

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

Наиболее важные из них это:

1. Service. Позволяет оформить обращение к веб-службе.
2. Service. Позволяет оформить обращение к веб-службе.
3. Calculate. Используется для работы с переменными, маппинга данных, обработок и т.д.
4. Scope, Compensate и Throw. Шаги для обработки ошибок.

Остальные шаги реализуют базовые функции – циклы и условия.

Итоговый worflow выглядит так:

Так как объекты TD Links существуют в системе не сами по себе, а в связи с другими объектами (типа Stagings), для начала мне потребовалось найти в системе нужные мне Stagings.

AppServices обладает методом, позволяющим делать выборку с использованием SQL-запроса. SQL-запрос собран прямо в виде строки:

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

Сформировав SQL-запрос, можно перейти к вызову нужного метода, выполнив маппинг данных:

Для маппинга могут использоваться как переменные, так и результаты выполнения предыдущих шагов процесса (например, результат запуска веб-службы).

После аналогичным способом (через SQL-запрос) делается выборка объектов для копирования – TD Links и запуск цикла.
И, наконец, этап опроса внешнего веб-сервиса, настраивается также через элемент типа «Service».

Последним шагом выполняем создание копии объекта TD Link, с сохранением в ней результатов, полученных от bridge (в том числе сообщение об ошибке, если оно есть).

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

Что можно сказать в итоге. Из плюсов предложенной реализации можно отметить следующие моменты:

• Простота разработки. По сути, не потребовалось никакого кодирования.
• Быстрота. Создать и отладить небольшой процесс можно за пару часов. При этом мне не пришлось выходить за рамки штатной среды разработки SBM Composer.
• Удобство отладки. Все логи в одном месте; видно, на каком шаге произошел сбой. Кроме того, существует единый лог, куда сбрасываются ошибки во время работы всех работающих процессов.
• Контролируемая легкость внесения изменений. Обновление описаний веб-служб, переименование переменных, внесение изменений в маппинг данных – всё это делается очень легко. И при этом, мои изменения фиксируются во встроенной системе контроля версий – в любой момент можно откатиться до предыдущей работающей версии.
• Возможность запуска с помощью внешнего события. В моем случае процесс инициирует пользователь, нажимая кнопку на пользовательском интерфейсе, но инициатором процесса может быть и некое внешнее событие.

Минусы, конечно, тоже есть:

• Проблематичность реализации сложных алгоритмов. Всё же, инструмент создания workflow ограничен в своих возможностях. Сложную обработку данных все же лучше оформлять в своей собственной web службе.
• Сложности с маппингом данных. Иногда приходится использовать дополнительные шаги процесса для маппинга данных, что несколько утяжеляет процесс.
• Ограничения, накладываемые на веб-службы. Поддерживается только архитектуры SOAP и REST (через специальную обёртку), также есть ряд ограничений, накладываемые на WSDL-файл.

Спасибо всем, кто дочитал пост до конца. Будем рады ответить на ваши вопросы в комментариях.

В настоящий момент существует несколько конкурирующих стандартов для моделирования бизнес-процессов. Нотация управления бизнес-процессами (BPMN), нотация исполняемый язык бизнес-процессов (BPEL), расширенная цепочка событийных событий (eEPC), методология функционального моделирования (IDF0, IDF3). У каждой из данной нотации есть свои преимущества для тех или иных целей, и преимущества использования конкретного программного продукта для описания бизнес-процессов в соответствующих нотациях.

IDEF0 — нотация графического моделирования, используемая для создания функциональной модели, отображающей структуру и функции системы, а также потоки информации и материальных объектов, связывающих эти функции. Стандарт IDEF0 (Integration Definition for Function Modeling) утвержден в США в 1993 как Федеральный стандарт обработки информации. В России находится в статусе руководящего документа с 2000 года и в настоящее время в качестве стандарта не утвержден. Тем не менее методология IDEF0 является одним из популярных подходов для описания бизнес-процессов. К ее особенностям можно отнести:

• использование контекстной диаграммы;
• поддержка декомпозиции;
• доминирование;
• выделение 4 типов стрелок (вход, выход, механизм, управление).

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

Контекстная диаграмма. Самая верхняя диаграмма, на которой объект моделирования представлен единственным блоком с граничными стрелками. Эта диаграмма называется A-0 (А минус нуль). Стрелки на этой диаграмме отображают связи объекта моделирования с окружающей средой. Диаграмма A-0 устанавливает область моделирования и ее границу.

Для декомпозиции верхнеуровневых бизнес-процессов используется нотация IDF3.

Нотация IDEF3 — важнейшая после IDEF0 и предназначена для описания потоков работ (Work Flow Modeling). В течение длительного
времени IDEF3 широко использовалась для создания моделей бизнес-процессов организации на нижнем уровне — при описании работ, выполняемых в подразделениях и на рабочих местах. Данная нотация являлась прототипом для создания нотации Aris eEPC.

Моделирование в нотациях IDF0, IDF3 приобрело популярность в программном продукте Erwin Business Process. Сейчас в данных нотациях можно моделировать в программном продукте Business studio, который создан в России. Программные продукты Erwin и Business studio являются дорогостоящими платными решениями (с 30 дневным бесплатным режимом). Нотация не служит для исполнения бизнес-процессов, а служит только для их анализа.

Нотация ARIS eEPC– расширенная цепочка процесса, управляемого событиями. Нотация разработана специалистами компании IDS Scheer AG (Германия), в частности профессором Шеером.

Применение большого числа различных объектов, связанных различными типами связей значительно увеличивает размер модели и делает ее плохо читаемой. Для понимания смысла нотации eEPC достаточно рассмотреть основные используемые типы объектов и связей. На следующем рисунке представлена простейшая модель eEPC, описывающая фрагмент бизнес-процесса предприятия.

Следует отметить, что реальная длительность выполнения процедур в eEPC визуально отражена быть не может. Это приводит к тому, что при создании моделей возможны ситуации, когда на одного исполнителя будет возложено выполнение двух задач одновременно. Используемые при построении модели символы логики позволяют отразить ветвление и слияние бизнес-процесса. Для получения информации о реальной длительности процессов необходимо использовать другие инструменты описания, например, графики Ганта в системе MS Project.

Данная нотация используется в программном продукте – Aris Express (бесплатная версия), Aris Toolset (платная версия), Business studio (платная версия).  Нотация не служит для исполнения бизнес-процессов, служит только для анализа бизнес-процессов.

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

Распространение BPMN поможет унифицировать способы представления базовых концепций бизнес-процессов (например, открытые и частные бизнес-процессы), а также более сложные концепции (например, обработка исключительных ситуаций, компенсация транзакций). Схемы в нотаци BPMN возможно трансформировать в нотацию BPEL.

Нотация используется как в бесплатных решениях (Bonita BPM, Bizagi и др), так и в платных решениях (Pega BPM, IBM BPM, Elma BPM и др.). Нотация может служить для моделирование исполняемых бизнес-процессов и не исполняемых.

BPEL (англ. Business Process Execution Language) — язык на основе XML для формального описания бизнес-процессов и протоколов их взаимодействия между собой. BPEL расширяет модель взаимодействия веб-служб и включает в эту модель поддержку транзакций.

В общем виде конфигурация BPEL-проекта выглядит следующим образом:

• BPEL-визуальный редактор;
• Сервер управления бизнес-процессами.

Основные файлы BPEL-проекта:

• .bpel — логический синтез и координация веб-служб. Фактически алгоритм исполнения бизнес-процесса. (его графическое представление напоминает блок-схему и диаграмму потоков данных в одном лице).
• .wsdl — описание интерфейсов для обмена сообщениями. «Как достичь веб-службы» (WSDL).
• .xsd — описание структур данных проекта (XML Schema).

Пример описания бизнес-процесса представлен ниже:

<process name=»mathProcess» targetNamespace=»http://example.com/ws-bp/math»

 xmlns=»http://docs.oasis-open.org/wsbpel/2.0/process/executable»

 xmlns:math=»http://manufacturing.org/wsdl/math»>

    <partnerLinks>

        <partnerLink name=»Math» partnerLinkType=»math:exampleMath» myRole=»mathService» />

    </partnerLinks>

    <variables>

        <variable name=»numIn»   messageType=»math:unsignedInt»/>

        <variable name=»numOut»  messageType=»math:unsignedInt»/>

        <variable name=»num»     type=»xsd:unsignedInt»/>

    </variables>

    <sequence>

        <receive partnerLink=»Math» portType=»math:mathPort» operation=»secondDegree» variable=»numIn» createInstance=»yes»/>

        <assign name=»LoopCounterIncrement»>

          <copy>

             <from>$numIn.request</from>

             <to variable=»num»/>

          </copy>

          <copy>

             <from>$num * $num</from>

             <to variable=»numOut» part=»response»/>

          </copy>

        </assign>

        <reply operation=»secondDegree» partnerLink=»Math» portType=»math:mathPort» variable=»numOut»/>

    </sequence>

 </process>

Язык BPML дополняет язык реализации бизнес-процессов (Business Process Execution Language, сокр. BPEL). BPML может использоваться для определения детальных бизнес-процессов, исполняемых при вызове каждого web-сервиса. BPML преобразует («мэппирует») бизнес-операции в обменные сообщения. Этот язык может использоваться для определения корпоративных бизнес-процессов, комплексных web-сервисов и многостороннего сотрудничества. В разработке BPML-спецификаций участвует целый ряд организаций: CSC, Intalio, SAP, Sun, SeeBeyond, Versata и др.

Стандартные операции: 

• Action: выполняет или вызывает выполнение операции, включающей обмен входящими и исходящими сообщениями.
• Assign: присваивает новое значение показателю.
• Call: запускает процесс и ждет его завершения.
• Compensate: инициирует компенсацию для указанных процессов.
• Delay: выражает промежуток времени.
• Empty: ничего не делает.
• Fault: выдает сообщение об ошибке в текущем контексте.
• Raise: активизирует сигнал.
• Spawn: запускает процесс без ожидания его завершения.
• Synch: синхронизирует по сигналу.

В основном, язык BPEL используется в программном продукте Bizagi, Pega BPM, IBM BPM, JBPM. Нотация исключительно служит для исполнения бизнес-процессов.

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

1. Программные продукты, где используются рассмотренные нотации, кроме BPMN, являются платными. Стоимость может доходить до нескольких тысяч долларов.
2. Нотация IDF0 используется для описания верхнеуровневых бизнес-процессов, нотация IDF3 и eEPC служит для описания потока работы. Нотации используются в Erwin Business modeler и Aris. Данные нотации идеально читаются и подходят для анализа системы, бизнес-процессов.
3. Нотация BPMN используется в нескольких профессиональных BPM системах и служит для моделирования исполняемых и не исполняемых бизнес-процессов. Чтение нотации для обычных работников затруднительно.
4. Нотация BPEL используется программистами, чтение обычными пользователями затруднительно.

В Язык выполнения бизнес-процессов веб-служб (WS-BPEL), широко известный как BPEL (Язык выполнения бизнес-процессов), является ОАЗИС^[1] стандартный исполняемый язык для определения действий внутри деловые процессы с веб-сервисы. Процессы в BPEL экспортируют и импортируют информацию исключительно с использованием интерфейсов веб-сервисов.

Обзор

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

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

WS-BPEL нацелен на моделирование поведения процессов,^[2] через язык для спецификации как исполняемых, так и абстрактных бизнес-процессов. Тем самым он расширяет модель взаимодействия веб-сервисов и позволяет поддерживать бизнес-транзакции. Он также определяет совместимую интеграционную модель, которая должна способствовать расширению автоматизированной интеграции процессов как внутри, так и между предприятиями. Его развитие возникло из понятия^[3] который программирование в большом и программирование в малых требуются разные типы языков.

Таким образом, он сериализуется в XML и направлен на обеспечение программирования в целом.

Программирование в большом / малом

Концепции программирование в большом и программирование в малых различают два аспекта написания типа длительно выполняющихся асинхронных процессов, которые обычно встречаются в бизнес-процессах:

1. Программирование в целом обычно относится к высокоуровневым переход состояния взаимодействия процесса. BPEL называет эту концепцию абстрактным процессом. Абстрактный процесс BPEL представляет собой набор общедоступных моделей поведения в стандартизированной форме. Абстрактный процесс включает такую ​​информацию, как время ожидания Сообщения, когда отправлять сообщения, когда компенсировать неудачные транзакции и т. д.
2. Программирование в малом, напротив, имеет дело с кратковременным программным поведением, часто выполняемым как отдельная транзакция и предполагающим доступ к локальной логике и ресурсам, таким как файлы, базы данных и так далее.

История

Истоки WS-BPEL восходят к Язык потока веб-сервисов (WSFL) и Xlang.

В 2001, IBM и Microsoft каждый определил свои довольно похожие, «программирование в большом «языки: WSFL^[4] (Язык потока веб-сервисов) и Xlang,^[5] соответственно. Microsoft даже пошла дальше и создала вариант сценария под названием XLANG / с которые позже будут служить основой для их служб оркестровки на их сервере BizTalk. Они специально задокументировали, что этот язык «проприетарный и не полностью задокументирован».^[6]

С появлением и популярностью BPML, и растущий успех BPMI.org и открытое движение BPMS во главе с JBoss и Intalio Inc., IBM и Microsoft решили объединить эти языки в новый язык, BPEL4WS. В апреле 2003 г. BEA Systems, IBM, Microsoft, SAP, и Siebel Systems представил BPEL4WS 1.1 в OASIS для стандартизации через Технический комитет BPEL по веб-службам.^[7] Несмотря на то что BPEL4WS как версия 1.0, так и версия 1.1, технический комитет OASIS WS-BPEL проголосовал^[8] 14 сентября 2004 г., чтобы назвать их спецификацию «WS-BPEL 2.0 «. (Это изменение в названии выровняло BPEL с другими стандартными соглашениями об именах веб-служб, которые начинаются с» WS- «(аналогично WS-Security) и учитывают значительные улучшения, сделанные между BPEL4WS 1.1 и WS-BPEL 2.0.) Если не обсуждая конкретную версию, прозвище BPEL обычно используется^{[нужна цитата ]}.

В июне 2007 г. активные конечные точки, Adobe Systems, BEA, IBM, Oracle и SAP опубликовали BPEL4Люди и спецификации WS-HumanTask, описывающие, как можно реализовать взаимодействие человека в процессах BPEL.

Темы

Цели дизайна

С BPEL было связано десять первоначальных целей проектирования:

1. Определите бизнес-процессы, которые взаимодействуют с внешними объектами через операции веб-службы, определенные с помощью WSDL 1.1, которые проявляются как веб-службы, определенные с помощью WSDL 1.1. Взаимодействия являются «абстрактными» в том смысле, что зависимость зависит от определений portType, а не от определений портов.
2. Определяйте бизнес-процессы, используя язык на основе XML. Не определяйте графическое представление процессов или не предоставляйте какую-либо конкретную методологию проектирования для процессов.
3. Определите набор концепций оркестрации веб-сервисов, которые предназначены для использования как во внешнем (абстрактном), так и во внутреннем (исполняемом) представлениях бизнес-процесса. Такой бизнес-процесс определяет поведение отдельного автономного объекта, обычно работающего во взаимодействии с другими аналогичными одноранговыми объектами. Признано, что для каждого шаблона использования (т. Е. Абстрактного представления и исполняемого представления) потребуется несколько специализированных расширений, но эти расширения должны быть сведены к минимуму и проверены на соответствие таким требованиям, как импорт / экспорт и проверка соответствия, которые связывают два использования. узоры.
4. Обеспечьте как иерархические, так и графические режимы управления и позвольте их сочетанию максимально плавно. Это должно уменьшить фрагментацию пространства моделирования процессов.
5. Предоставьте функции управления данными для простого управления данными, необходимыми для определения данных процесса и потока управления.
6. Поддержка механизма идентификации для экземпляров процесса, который позволяет определять идентификаторы экземпляров на уровне сообщений приложения. Идентификаторы экземпляров должны определяться партнерами и могут изменяться.
7. Поддерживайте неявное создание и завершение экземпляров процесса в качестве основного механизма жизненного цикла. Расширенные операции жизненного цикла, такие как «приостановка» и «возобновление», могут быть добавлены в будущих выпусках для расширенного управления жизненным циклом.
8. Определите модель длительной транзакции, основанную на проверенных методах, таких как компенсационные действия и определение объема, для поддержки восстановления после сбоев для частей длительных бизнес-процессов.
9. Используйте веб-службы в качестве модели для декомпозиции и сборки процессов.
10. Постройте как можно больше стандартов веб-сервисов (утвержденных и предложенных), используя модульную структуру.

Язык BPEL

BPEL — это оркестровка язык, а не хореография язык. Основное различие между оркестровкой и хореографией — исполнимость и контроль. Оркестровка определяет исполняемый процесс, который включает обмен сообщениями с другими системами, так что последовательности обмена сообщениями контролируются разработчиком оркестровки. Хореография определяет протокол для одноранговых взаимодействий, определяя, например, юридические последовательности сообщений, которыми обмениваются, с целью гарантировать совместимость. Такой протокол не является исполняемым напрямую, поскольку он допускает множество различных реализаций (процессов, которые ему соответствуют). Хореография может быть реализована путем написания оркестровки (например, в форме процесса BPEL) для каждого участника, участвующего в ней. Различия в оркестровке и хореографии основаны на аналогиях: оркестровка относится к центральному контролю (дирижером) поведения распределенной системы (оркестр, состоящий из многих игроков), тогда как хореография относится к распределенной системе (танцевальная команда). который действует по правилам (хореография), но без централизованного управления.

Сосредоточение внимания BPEL на современных бизнес-процессах, а также истории WSFL и XLANG привело к тому, что BPEL выбрал веб-сервисы в качестве своего внешнего механизма связи. Таким образом, средства обмена сообщениями BPEL зависят от использования языка описания веб-служб (WSDL) 1.1 для описания исходящих и входящих сообщений.

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

• Механизм корреляции сообщений на основе свойств
• Типизированные переменные XML и WSDL
• Модель расширяемого языкового модуля, позволяющая писать выражения и запросы на нескольких языках: BPEL поддерживает XPath 1.0 по умолчанию
• Структурированное программирование конструкции, включая if-then-elseif-else, while, последовательность (для включения выполнения команд по порядку) и поток (для включения параллельного выполнения команд)
• А обзор система, позволяющая инкапсуляция логики с локальные переменные, вина-обработчики, обработчики компенсаций и обработчики событий
• Сериализованные области для управления одновременным доступом к переменные.

Связь BPEL с BPMN

Для WS-BPEL не существует стандартной графической записи, так как технический комитет OASIS решил, что это выходит за рамки. Некоторые производители изобрели свои собственные обозначения. Эти нотации используют тот факт, что большинство конструкций в BPEL имеют блочную структуру (например, последовательность, while, pick, scope и т. Д.). Эта функция обеспечивает прямое визуальное представление описаний процессов BPEL в форме структурограммы, в стиле, напоминающем Диаграмма Насси – Шнейдермана.

Другие предложили использовать существенно другой язык моделирования бизнес-процессов, а именно: Модель и обозначение бизнес-процесса (BPMN) в качестве графического интерфейса для сбора описаний процессов BPEL. В качестве иллюстрации осуществимости этого подхода спецификация BPMN включает неформальное и частичное сопоставление^[9] из BPMN в BPEL 1.1. Более подробное отображение BPMN в BPEL было реализовано в ряде инструментов, включая инструмент с открытым исходным кодом, известный как BPMN2BPEL.^[10] Однако разработка этих инструментов выявила фундаментальные различия между BPMN и BPEL, которые делают очень трудным, а в некоторых случаях невозможным создание человек читаемый Код BPEL из моделей BPMN. Еще сложнее проблема BPMN-to-BPEL двусторонняя инженерия: генерация кода BPEL из диаграмм BPMN и поддержание синхронизации исходной модели BPMN и сгенерированного кода BPEL в том смысле, что любая модификация одной модели распространяется на другую.^{[нужна цитата ]}

Добавление поддержки «программирование в малом» в BPEL

Управляющие структуры BPEL, такие как «if-then-elseif-else» и «while», а также его средства управления переменными зависят от использования «программирования на малых» языках для обеспечения логики. Все реализации BPEL должны поддерживать XPath 1.0 в качестве языка по умолчанию. Но дизайн BPEL предусматривает возможность расширения, чтобы разработчики систем могли использовать и другие языки. BPELJ^[11] это усилие, связанное с JSR 207^[12] это может позволить Java функционировать как «программирование на малом» языке внутри BPEL.

BPEL4Люди

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

Чтобы восполнить этот пробел, BPEL4People расширил BPEL из оркестровка только веб-сервисов, чтобы организовать ролевую деятельность человека.

Цели

В контексте бизнес-процесса BPEL4People

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

путем расширения BPEL дополнительным независимым синтаксисом и семантикой.

В WS-HumanTask Спецификация вводит определение человеческих задач и уведомлений, включая их свойства, поведение и набор операций, используемых для управления человеческими задачами. Протокол координации вводится, чтобы управлять автономностью и жизненным циклом человеческих задач с поддержкой сервисов во взаимодействии.

В BPEL4Люди спецификация представляет расширение WS-BPEL для решения вопросов взаимодействия человека в WS-BPEL как первоклассный гражданин. Он определяет новый тип основной деятельности, в которой в качестве реализации используются неавтоматизированные задачи, и позволяет определять задачи, локальные для процесса, или использовать задачи, определенные вне определения процесса. Это расширение основано на спецификации WS-HumanTask.

WS-BPEL 2.0

Версия 2.0 внесла некоторые изменения и новые функции:

• Новые типы действий: repeatUntil, validate, forEach (параллельный и последовательный), rethrow, extensionActivity ,pensateScope
• Переименованные действия: переключатель / case переименован в if / else, прекратить переименован для выхода
• Обработчик завершения добавлен в действия области, чтобы обеспечить явное поведение для завершения
• Инициализация переменной
• XSLT для преобразования переменных (новая функция расширения XPath bpws: doXslTransform)
• Доступ XPath к данным переменных (синтаксис переменной XPath $ variable [.part] / location)
• Переменные схемы XML в действиях веб-сервисов (для взаимодействия сервисов в стиле WS-I doc / lit)
• Локально объявленный messageExchange (внутренняя корреляция действий получения и ответа)
• Разъяснение абстрактных процессов (синтаксис и семантика)
• Включить переопределение языка выражений для каждого действия

Смотрите также

• BPEL4Люди
• BPELscript
• Модель и обозначение бизнес-процесса
• Моделирование бизнес-процессов
• Список двигателей BPEL
• Язык разговора веб-служб
• Рабочий процесс
• WS-CDL
• Язык определения процессов XML
• Еще один язык рабочего процесса

Рекомендации

дальнейшее чтение

Книги по BPEL 2.0

• SOA для бизнес-разработчиков: концепции, BPEL и SCA. ISBN  978-1-58347-065-7

<<предыдущая содержание следующая>>

Общее представление

• 7.1 Область применения BPMN
  • 7.1.1 Использование BPMN
• 7.2. Элементы BPMN
  • 7.2.1 Основные графические элементы моделирования
  • 7.2.2 Полный перечень графических элементов диаграмм бизнес-процессов
• 7.3. Типы Диаграмм Бизнес-процессов (BPMN Diagram Types)
• 7.4. Использование текста, цвета и линий в моделировании диаграмм
• 7.5. Правила соединения элементов потока
  • 7.5.1. Правила соединения потоков операций
  • 7.5.2. Правила соединения потоков сообщений
• 7.6. Расширяемость BPMN
• 7.7. Примеры Процессов BPMN

За короткий промежуток времени был сделан большой скачок в разработке языков на основе XML для реализации бизнес-процессов для Web-сервисов. Такие языки, как WSBPEL (Web Services Business Process Execution Language), служат для формального описания бизнес-процессов. Отличительной особенностью языков такого формата является то, что они были оптимизированы для описания процессов внутри BPM-систем и их взаимодействия с другими. Оптимизация этих языков для приложений сделала их менее удобными для использования людьми (включая разработку Бизнес-процессов, управление ими, мониторинг). Для описания бизнес-процессов WSBPEL использует блоки и диаграммы. В нем применены принципы формальных математических моделей (например, pi-calculus1). Все это способствовало формированию основ выполнения Бизнес-процессов для обработки комплексных внутренних и внешних B2B взаимоотношений, а также выгодного использования Web-сервисов. Для WSBPEL характерно то, что сложные бизнес-процессы могут быть организованы в формате потенциально сложных, разрозненных и интуитивно непонятных моделей, которые с легкостью обрабатываются программами и приложениями, однако, сложны для понимания бизнес-аналитиками и менеджерами, задачами которых являются разработка, управление и мониторинг Процессов. Поэтому языки на основе XML для реализации бизнес-процессов для Web-сервисов не ориентированы на создание удобства использования и способности к взаимодействию на уровне людей.

Людям, занимающимся бизнесом, крайне удобно работать с Бизнес-процессами, отображаемыми в виде блок-схем. Множество бизнес-аналитиков проектируют и описывают бизнес-процессы компаний с помощью простых блок-схем, вследствие чего возникла нерешенная техническая проблема, заключающаяся в различии форматов исходных проектов бизнес-процессов и языков исполнения бизнес-процессов (WSBPEL и др.). Для решения этой проблемы потребовалось создание формального механизма соответствия визуализации бизнес-процессов (нотации) необходимому языку исполнения бизнес-процессов (BPM execution language).

Взаимодействие людей (а не операций приложения) в бизнес-процессах могло быть решено благодаря стандарту BPMN (Business Process Model and Notation). Использование BPMN позволяет создавать множество диаграмм для использования людьми, разрабатывающими бизнес-процессы и управляющими ими. Благодаря BPMN, также осуществляется и соотнесение модели бизнес-процесса с языком исполнения (WSBPEL). Таким образом, создание BPMN обеспечило появление механизма стандартной визуализации бизнес-процессов, описанного с помощью языка исполнения оптимизированных бизнес-процессов.

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

Благодаря тому, что при разработке BPMN была использована B2B концепция построения бизнес-процессов, были расширены возможности нотации в отношении публичных и приватных Процессов, Хореографии (Choreography), а также обработки ошибок, транзакции и компенсаций.

В данной спецификации рассматриваются нотация, варианты моделирования бизнес-процессов, а также формат обмена данными, применение которых поможет пользователям успешно осуществлять использование терминов нотации BPMN (как в моделях, так и на диаграммах) и их замещение при работе с различными инструментами моделирования. Задача данного документа – показать гибкость использования одних и тех же объектов нотации в различных средах моделирования бизнес-процессов.

В спецификации BPMN 2.0 содержится более подробное, нежели содержащееся в спецификации BPMN 1.2, описание возможностей и областей использования нотации, а именно:

• Формализация семантики исполнения всех существующих элементов BPMN,
• Определение механизма изменения как расширений модели бизнес-процесса, так и для расширений графических элементов,
• Детализация состава и корреляции События,
• Расширение определения пользовательских действий,
• Введение элемента Хореография (Choreography)и описание данной модели.

Данная спецификация также разрешает некоторые несоответствия и неточности спецификации BPMN 1.2.

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

• Определение типов организационных структур и их ресурсов,
• Функциональное моделирование структуры организации,
• Создание моделей данных и информационных моделей,
• Моделирование стратегии,
• Создание бизнес-правил.

Поскольку все вышеперечисленные аспекты высокоуровнего моделирования прямо или косвенно относятся к Бизнес-процессам, взаимосвязь нотации BPMN с другими типами высокоуровнего моделирования можно формально определить как BPMN и его взаимосвязь с другими спецификациями.

Несмотря на то, что BPMN описывает поток данных (Сообщений) и связь артефактов с Действиями, её нельзя назвать языком потока данных. Также в спецификацию не включена информация о выполнении операций в режиме симуляции деятельности, мониторинге и разворачивании Бизнес-процесса.

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

Для определения типов данных, выражений и сервисных операций в данной спецификации также использованы другие стандарты: XML Schema, XPath, и WSDL соответственно.

7.1.1. Использование BPMN

Моделирование бизнес-процессов предназначено для описания взаимодействия между огромным количеством информации и множеством целевых групп. BPMN объединяет возможности различных типов моделирования, что позволяет создавать непрерывные (end-to-end) бизнес-процессы. С помощью элементов BPMN пользователи могут легко отделять одну часть диаграммы от другой. Существует три основных типа компонентов (sub-model) модели бизнес-процесса end-to-end:

1. Процесс (Оркестровка), включающий:

a. Приватные невыполняемые (внутренние) Бизнес-процессы (Private non-executable (internal) Business Processes).

b. Приватные выполняемые (внутренние) Бизнес-процессы (Private executable (internal) Business Processes).

c. Публичные Процессы (Public Processes).

2. Хореография (Choreography).

3. Взаимодействие (Collaborations), которое может содержать Процессы и/или Хореографии.

a. Вид обмена сообщениями.

Приватный (внутренний) Бизнес—процесс (Private (Internal) Business Processes)

Приватные Бизнес-процессы (Private (internal) Business-Process) относятся к внутренним процессам компании. Такие Процессы обычно называют Процессами потока операций или Процессами BPM (см. фигуру 10.4). Другое их название – Оркестровка сервисов (используется в веб-сервисах). Приватные процессы могут быть выполняемыми и невыполняемыми. Выполняемый Процесс моделируется для исполнения в соответствии с семантикой, описанной в главе 14. Время от времени на определенных этапах выполнения Процесса может недоставать информации, необходимой для того, чтобы Процесс оставался выполняемым. Невыполняемый Процесс моделируется с целью описания поведения Процесса с точки зрения разработчика модели. Таким образом, информация, необходимая для выполнения Процесса (например, условное выражение), обычно не включается в невыполняемый Процесс.

Фигура 7.1 – Пример приватного Бизнес-процесса

Публичный Процесс

Публичный Процесс (Public Process) служит для отображения взаимодействия между приватным Бизнес-процессом и другим Процессом или Участником (см. фигуру 7.2). В его состав входят лишь те Действия, которые обычно используются для отображения сообщения с другими Участниками. Все остальные «внутренние» Действия приватного Бизнес-процесса не входят в публичный Процесс. Таким образом, посредством публичного Процесса внешний мир может наблюдать за Потоками сообщений и порядком, в котором эти Потоки сообщений должны взаимодействовать с Процессом. Публичный Процесс может моделироваться как отдельно от Взаимодействия, так и с ним, что помогает показать обмен Сообщениями между Действиями публичного Процесса и другими Участниками. Обратите внимание, что в BPMN 1.2 публичный Процесс назван абстрактным.

Фигура 7.2 – Пример публичного Процесса

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

C помощью Взаимодействия (Collaboration)отображаюся взаимоотношения между двумя или более бизнес-сущностями. Обычно в состав Взаимодействия входят две или более Зоны ответственности, представляющие собой Участников Взаимодействия. Обмен Сообщениями между этими Участниками отображается при помощи Потока сообщений, соединяющих два Пула или объекты в них. Также отображаются и Сообщения, входящие в состав данного Потока сообщений. Взаимодействие может отображаться в виде двух или более сообщающихся между собой публичных Процессов (см. фигуру 7.3). Публичные Процессы и Действия, предназначенные для выполнения Участниками Взаимодействия, могут рассматриваться в качестве точек соприкосновения (touch-points). Соответствующие внутренние (выполняемые) Процессы содержат, как правило, намного больше Действий и информации, чем публичные Процессы. Также Пул МОЖЕТ представлять собой черный ящик (black box) или, другими словами, быть пустым. Хореография МОЖЕТ отображаться в пространстве между Пулами, поскольку она разделяет пополам соединяющие их Потоки операций. Во Взаимодействии допускается использование любых комбинаций Пулов, Процессов и Хореографий.

Фигура 7.3 – Пример Процесса Взаимодействия

Хореография (Choreography)

Стандартный Процесс существует внутри Зоны ответсвенности, а Xореография осуществляется между Зонами ответсвенности.

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

Фигура 7.4 – пример Хореографии

Обмен сообщениями (Conversations)

Диаграмма Обмена сообщениями (Conversation) является частным случаем использования диаграммы Взаимодействия и его неформального описания. При этом, однако, Пулы, входящие в Обмен сообщениями, обычно не содержат Процессов, а Хореография (Choreography), как правило, не располагается между Пулами диаграммы Обмена сообщениями. Обмен сообщениями представляет собой логическое отношение типа обмен сообщениями. На деле логическое отношение часто касается бизнес-объектов коммерческих объединений (к примеру, заказ товаров, их перевозка и доставка, выписка счета)

Фигура 7.5 – Пример диаграммы Обмена сообщениями

Диаграмма Точек зрения

Поскольку при помощи диаграммы BPMN МОЖЕТ изображаться Процесс с несколькими Участниками, то каждый из участников может по-разному понимать диаграмму, т.е. у каждого из них есть собственная точка зрения по поводу того, каким образом они будут участвовать в Процессе. Некоторые из Действий будут для кого-то из Участников внутренними (т.е. будут выполняться под контролем этого Участника), а некоторые – внешними. Любой Участник по-своему воспринимает то, какими должны быть внутренние и внешние Действия. Во время выполнения Процесса разница между внешними и внутренними Действиями влияет на то, каким образом данный Участник определяет статус какого-то из Действий или выявляет проблему. Однако сама диаграмма всегда означает одно и то же. На фигуре 7.3 изображен Бизнес-процесс, который может рассматриваться разными Участниками по-разному. С одной стороны, есть Пациент (Patient), с другой стороны – офис Доктора (Doctor’s office). На диаграмме показаны Действия обоих Участников Процесса, однако, когда Процесс выполняется, каждый из Участников контролирует выполнение лишь собственных Действий. Несмотря на то, что для каждого Участника важна его точка зрения на Процесс, на данный момент в BPMN нет никакого графического механизма отображения точек зрения. Разработчику модели или производителю инструмента моделирования предоставляется возможность вводить собственные графически отображаемые реплики о точках зрения на диаграмму.

Понимание поведения диаграммы

На протяжении данного документа обсуждается то, каким образом в Процессе задействован Поток операций. Для облегчения восприятия материала вводится элемент «токен». Токен пересекает Поток операций и проходит сквозь элементы Процесса. Токен является теоритическим понятием и используется для определения поведения выполняемого Процесса. Поведение элементов Процесса определяется путем описания их взаимодействия с токеном, который пересекает Процесс. Однако для инструментов моделирования и исполнения, работающих с BPMN, использование токенов НЕ является ОБЯЗАТЕЛЬНЫМ условием.

Стартовое событие формирует токен, который в итоге ДОЛЖЕН завершится Конечным событием (Конечное событие МОЖЕТ БЫТЬ скрытым в случае, если оно не отображается на диаграмме). Маршрут токена должен легко отслеживаться на протяжении всей диаграммы Процесса, содержащей Потоки операций, Шлюзы и Действия.

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

<<предыдущая содержание следующая>>

Данные материалы предназначены исключительно для ознакомления в личных целях.Любое воспроизведение, копирование, а так же коммерческое и некоммерческое использование материалов должно согласовываться с авторами материалов (elma@elewise.ru). Допускается использование материалов сайта без уведомления авторов, но с явным указанием источника.

До BPEL

Характеристики BPEL

Три ключа к BPEL

От сервисов к процессам

После BPEL

Поддержка обслуживания BPEL

Oracle BPEL Process Manager