Event subprocess bpmn что это

Урок 2 : События и шлюзы в BPMN

Второй Урок практического курса BPMN посвящён рассмотрению следующих графических элементов спецификации BPMN и их использованию при описании бизнес-процессов: События и Шлюзы (исключающие, неисключающие и параллельные).

Расширим ранее приведённый пример процесса (Урок 1) с дополнительными действиями.

Рис. 2. Процесс «Обработка заказа»

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

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

Рис.2.1. Промежуточное событие

Маркер – это специальный значок, рисуемый в центре круга События. Он влияет на характер работы События.

— простое Стартовое событие.

— Стартовое событие-сообщение показывает, что от участника поступает Сообщение, которое инициирует запуск Процесса (например, от клиента приходит оплата товара, приходит сообщение об оплате и запускается процесс выдачи товара).

— простое Конечное событие. Данный тип Конечного события не подразумевает какой-то определенный результат.

— Конечное событие-сообщение служит для указания того, что Участник отправил Сообщение в момент завершения Процесса.

— обычное Промежуточное событие.

— маркер часов показывает, что используется событие-таймер. В ход процесса при этом останавливается на определённое время.

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

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

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

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

Подробно с каждым типом событий можно ознакомиться в нотации BPMN (русский перевод) раздел 10.4. «Событие».

Ещё один элемент BPMN, используемый в рамках предыдущего Урока1 – Шлюз (Условия), так же имеет несколько вариаций. В первом примере (Урок 1) был использован Исключающий Шлюз «ИЛИ» (Эксклюзивный). Исключающие Шлюзы включаются в состав бизнес-процесса для разделения Потока операций на несколько альтернативных маршрутов. Для процесса с исключающим типом Шлюза может быть выбран лишь один из предложенных маршрутов (поэтому определяется как Шлюз «ИЛИ»).

Рис.2.2. Исключающий Шлюз

Графический элемент Исключающий Шлюз не имеет внутренних маркеров.

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

Примечание: в процессе-примере Исключительный Шлюз используется два раза: первый Шлюз определяется вопросом «Покупают велосипед или арендуют?» и в зависимости от ответа процесс протекает либо в одном направлении «Оформить заявка на покупку» либо в другом – «Оформить заявку на аренду»; второй Шлюз определяется вопросом «Есть ли заказанный товар на складе?», по результатам которого товар либо бронируют на складе, либо, в случае отсутствия на складе, делают заказ на фабрику-производитель. Обе задачи выполняться одновременно не будут.

Второй тип Шлюза, так же часто используемый в описании процессов – Параллельный Шлюз «И». Данный тип Шлюза используется для создания параллельных маршрутов и их синхронизации (объединения).

Рис. 2.3. Параллельный Шлюз

Графический элемент Параллельный Шлюз содержит внутренний маркер, выполненный в виде знака «+», что позволяет отличить данный тип Шлюза от других.

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

Ещё один, но менее распространённый тип Шлюза – Неисключающий (Неэксклюзивный) Шлюз «И/ИЛИ». Неисключающие Шлюзы используются для разделения потока операций на несколько альтернативных и параллельных маршрутов.

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

Рис.2.4.Неисключающий Шлюз

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

Примечание: В процессе-примере (Рис.2) описаны несколько возможных маршрутов потока операций, разделённые Неисключающим Шлюзом:

Два возможных альтернативных маршрута:

1. При условии, что сумма заказанного товара (велосипеда) больше 20 000 руб., то к заказу добавляется подарок. При этом дополнительного товара заказано не было. Маршрут идёт только в одном направлении.

2. Если сумма товара меньше 20 000руб., и в заказе доптовара нет, то подарок не добавляется. Маршрут также идёт только в одном направлении.

Два возможных параллельных маршрута:

1. Если велосипед заказан на сумму больше 20 000руб., и дополнительно заказаны товары на сумму от 5 000руб., то клиент получит два подарка. Ход процесса идёт параллельно по двум маршрутам.

2. Если сумма велосипеда меньше 20 000руб., но дополнительные товары превышают 5000 руб., то клиент получает подарок. Также процесс проходит по двум направлениям параллельно. Закрывающий Неисключающий Шлюз, также как и Параллельный Шлюз, синхронизирует потоки операций.

В нотации BPMN описывается несколько типов Шлюзов, однако здесь мы привели три наиболее распространённые при описании бизнес-процессов элементы Условия. С остальными типами Шлюзов можно ознакомиться в разделе 10.5 нотации BPMN.

Источник

Event Subprocess

The event subprocess is a subprocess that is triggered by an event. An event subprocess can be added at the process level or at any subprocess level. The event used to trigger an event subprocess is configured using a start event. Therefore, none start events are not supported for event subprocesses. An event subprocess might be triggered using events like message events, error events, signal events, timer events, or compensation events. The subscription to the start event is created when the scope (process instance or subprocess) hosting the event subprocess is created. The subscription is removed when the scope is ended.

An event subprocess may be interrupting or non-interrupting. An interrupting subprocess cancels any executions in the current scope. A non-interrupting event subprocess spawns a new concurrent execution. While an interrupting event subprocess can only be triggered once for each activation of the scope hosting it, a non-interrupting event subprocess can be triggered multiple times. Whether the subprocess is interrupting or non-interrupting is configured using the start event which triggers the event subprocess.

An event subprocess may not have any incoming or outgoing sequence flows. As an event subprocess is triggered by an event, an incoming sequence flow makes no sense. When an event subprocess is ended, either the current scope is ended (in case of an interrupting event subprocess), or the concurrent execution spawned for the non-interrupting subprocess is ended.

The event subprocess is visualized as an embedded subprocess with a dotted outline.

It is represented using XML in the same way as an embedded subprocess. Additionally, the attribute triggeredByEvent must have the value true :

Example

The following is an example of an event subprocess triggered using an Error Start Event. The event subprocess is located at the “process level”, i.e., is scoped to the process instance:

This is what the event subprocess looks like in XML:

As already stated, an event subprocess can also be added to an embedded subprocess. If it is added to an embedded subprocess, it becomes an alternative to a boundary event. Consider the two following process diagrams. In both cases the embedded subprocess throws an error event. Both times the error is caught and handled using a user task.

In both cases the same tasks are executed. However, there are differences between both modeling options:

These two differences can help you decide whether a boundary event or an embedded subprocess is better suited for solving a particular process modeling / implementation problem.

Camunda Extensions

Additional Resources

On this Page:

We are looking for talented people.

camunda.org and docs.camunda.org are part of Camunda Platform | Built by camunda and contributors — Privacy Statement — camunda Services GmbH © 2021

The content on this site is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Источник

Ассоциация BPM-профессионалов

ABPMP Russian Chapter

Глоссарий BPMN

Глоссарий BPMN : 3 комментария

Прошу извинения за запоздалый комментарий, сначала в душе поддержав глоссарий, позже обнаружил некоторые коллизии.
1. Gateway используется для изображения как развилки потока управления, так и его слияния. Не совсем удачно для русского языка говорить, что происходит слияние потока управления с помощью параллельной развилки. «Сходящаяся развилка» тоже не лучшее решение.
2. В словаре UML есть два понятия Activity (деятельность) и Action (действие). Деятельность подразумевает ее декомпозицию на деятельности или действия, а действие всегда атомарно. Наш перевод Activity как «действие» противоречит этому положению.
3. Почему из глоссария изъяли такие термины. как Fork и Trigger?
Пока вопросы «в принципе». Если будет интерес, дам свои предложения.

Уважаемый Андрей Леонидович

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

Терминология BPMN отличается от UML, здесь вместо action в том же значении используется термин task.

Целью проекта было стандартизовать названия элементов BPMN, а не перевести спецификацию. Fork и trigger — это не элементы, а синонимы (для расходящейся развилки и события-инициатора, соответственно). А с точки зрения стандартизации терминологии от синонимов больше вреда, чем пользы.

Источник

Event subprocess

An event subprocess is a subprocess triggered by an event. It can be added globally to the process, or locally inside an embedded subprocess.

An event subprocess must have exactly one start event of one of the following types:

An event subprocess behaves like a boundary event, but is inside the scope instead of attached to the scope. Like a boundary event, the event subprocess can be interrupting or non-interrupting (indicated in BPMN by a solid or dashed border of the start event). The start event of the event subprocess can be triggered when its containing scope is activated.

A non-interrupting event subprocess can be triggered multiple times. An interrupting event subprocess can be triggered only once.

When an interrupting event subprocess is triggered, all active instances of its containing scope are terminated, including instances of other non-interrupting event subprocesses.

If an event subprocess is triggered, its containing scope is not completed until the triggered instance is completed.

Variables#

Unlike a boundary event, an event subprocess is inside the scope. Therefore, it can access and modify all local variables of its containing scope. This is not possible with a boundary event because a boundary event is outside of the scope.

Input mappings can be used to create new local variables in the scope of the event subprocess. These variables are only visible within the event subprocess.

By default, the local variables of the event subprocess are not propagated (i.e. removed with the scope). This behavior can be customized by defining output mappings at the event subprocess. The output mappings are applied on completion of the event subprocess.

Additional resources#

XML representation#

An event subprocess with an interrupting timer start event:

Источник

Event subprocess bpmn что это

Подпроцесс представляет собой Действие, заключающее в себе другие Действия, Шлюзы, События и Потоки операций. Графически Подпроцесс изображается в качестве элемента Потока операций Процесса.

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

Далее будут рассмотрены различные типы Подпроцессов.

Встроенный Подпроцесс (Embedded Sub-Process (Sub-Process))

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

Подпроцесс может быть свернутым (Collapsed Sub-Process), при этом его детали скрыты (см. фигуру 10.25). Подпроцесс также может быть развернутым (Expanded Sub-Process), при этом его детали отображаются внутри Процесса, в котором данный Подпроцесс содержится (см. фигуру 10.26). В случае, если Подпроцесс является свернутым, то используется маркер, позволяющий отличить Подпроцесс от Задачи.

Фигура 10.25 – Графический элемент Свернутый Подпроцесс

Фигура 10.26 – Графический элемент Развернутый Подпроцесс

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

Развернутый Подпроцесс используется для более компактного отображения группы параллельных Действий с использованием минимума деталей. Как показано на фигуре 10.27, Действия «С» и «D» заключены в безымянном развернутом Подпроцессе. Оба этих Действия будут выполняются параллельно. Обратите внимание, что в состав развернутого Подпроцесса не включены ни Стартовое, ни Конечное События. Также в нем не содержится Потока операций, исходящего от этих Событий или подходящего к ним. Такое использование Развернутого Подпроцесса для отображения «параллельных блоков» может сделать использование Стартового и Конечного Событий необязательным.

Фигура 10.27 – Развернутый Подпроцесс, выступающий в роли «параллельного блока».

Цикл Многоэкземплярность Компенсация Ad-Hoc Компенсация + Ad—Hoc

Фигура 10.28 – Маркеры Свернутого Подпроцесса

Свернутый Подпроцесс в BPMN 2.0 относится к Встроенному Подпроцессу, описанному в BPMN 1.2. Повторно используемый Подпроцесс в BPMN 1.2 относится к Действию типа Вызов, описанному в BPMN2.0. Фигура 10.29 представляет собой диаграмму классов Подпроцесса.

Элемент SubProcess наследует атрибуты и ассоциации элементов Activity (см. таблицу 10.3) и элемента FlowElementContainer (см. таблицу 8.45). Таблица 10.20 содержит информацию о дополнительных атрибутах элемента SubProcess.

Таблица 10.20 – Атрибуты элемента SubProcess

triggeredByEvent: boolean = false

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

· Значение «false» указывает на то, что Подпроцесс является стандартным.

· Значение «true» указывает на то, что Подпроцесс работает с Событиями и является причиной возникновения дополнительных ограничений.

triggeredByEvent: boolean = false

Данный атрибут обусловливает наличие списка Артефактов, хранящихся в Подпроцессе.

ReusableSub—Process (CallActivity) Повторно используемый Подпроцесс (Вызов)

Повторно используемый Подпроцесс, описанный в BPMN 1.2, относится к Действию типа Вызов, используемому для вызова предопределенного Подпроцесса.

Событийный Подпроцесс (Event Sub-Process)

Событийным Подпроцессом называется специфический Подпроцесс, используемый внутри Процесса (Подпроцесса). Такой Подпроцесс имеет атрибут triggeredByEvent с установленным значением «true».

Такой Подпроцесс не является частью Стандартного потока операций, включенного в родительский Процесс, и не имеет входящих или исходящих Потоков операций.

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

Фигура 10.30 – Графический элемент Свернутый Событийный Подпроцесс

Фигура 10.31 – Графический элемент Развернутый Событийный Подпроцесс

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

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

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

Фигура 10.32 –Событийные Подпроцессы внутри родительского Подпроцесса

Транзакцией называется специфический тип Подпроцесса, который демонстрирует определенное поведение, контролируемое посредством протокола транзакции (например, WS-Transaction). Граница графического элемента Транзакция выполнена двойной линией (см. фигуру 10.33).

Фигура 10.33 –Подпроцесс Транзакция

Фигура 10.34 – Свернутый Подпроцесс Транзакция

Элемент TransactionSub-Process наследует атрибуты и ассоциации элемента Activity (см. таблицу 10.3) за счет взаимосвязи с Подпроцессом. Таблица 10.21 содержит информацию о дополнительных атрибутах и ассоциациях элемента TransactionSub-Process.

Таблица 10.21 – Атрибуты и ассоциации элемента TransactionSub-Process

method: Transaction- Method

Данный атрибут определяет метод, используемый для совершения Транзакции или её отмены. Для выполняемых процессов данный атрибут ДОЛЖЕН содержать особый URL, например, http://schemas.xmlsoap.org/ws/2004/10/wsat for WS-AtomicTransaction, orhttp://docs.oasis-open.org/ws-tx/wsba/2006/ 06/AtomicOutcome для WS-BusinessActivity. Для сохранения совместимости с BPMN 1.1 данный атрибут также может иметь значения «##compensate», «##store» и «##image».

Использование Транзакции может привести к следующим результатам:

Поведение, которое при удачном завершении демонстрирует Транзакция на конечном этапе, немного отличается от того, как завершается стандартный Подпроцесс. Когда все маршруты, содержащиеся в Транзакции, достигают Конечного события (не имеющего тип Отмена), моментальный возврат Потока операций к родительскому Процессу верхнего уровня, как это происходит в стандартном Подпроцессе, не осуществляется. Прежде всего, Протоколом Транзакции утверждаются все Участники, удачно завершившие Транзакцию. В большинстве случаев так и происходит, после чего Поток операций возвращается в Процесс верхнего уровня. Однако случается, что у одного из Участников возникают проблемы при завершении, что влечет за собой появление Отмены или Риска (Опасности). При таком развитии событий Поток операций направляется к соответствующему Промежуточному событию, даже если оно, скорее всего, было успешно завершено.

Спонтанный Подпроцесс (Ad-Hoc Sub-Process)

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

Графический элемент Спонтанный Подпроцесс содержит маркер, выполненный в виде знака тильды и располагающийся в центре нижней части фигуры Подпроцесса (см фигуру 10.35 и 10.36).

Фигура 10.35 – Графический элемент Свернутый Спонтанный Подпроцесс

Фигура 10.36 – Графический элемент Развернутый Спонтанный Подпроцесс

Элемент Ad-HocSub-Process наследует атрибуты и ассоциации элемента Activity (см. таблицу 10.3) за счет взаимосвязи с Подпроцессом. Таблица 10.22 содержит информацию о дополнительных ассоциациях элемента Ad-HocSub-Process.

Таблица 10.22 – Ассоциации элемента Ad-HocSub-Process

Данный атрибут определяет условия, при которых завершается Процесс. Значение «true» указывает на то, что Процесс будет завершен.

ordering: AdHocOrdering = Parallel

Данный атрибут указывает на то, будут ли Действия, включенные в Процесс, выполняться параллельно или НЕОБХОДИМО последовательное их выполнение. Значением по умолчанию является «parallel». Значение «sequential» ограничивает одновременное выполнение нескольких Действий. В данном случае в определенный период времени может быть выполнено лишь одно Действие. Если выбрано значение «parallel», то одновременно может выполняться любое количество Действий, от нуля и более.

cancelRemaining- Instances: boolean = true

Данный атрибут используется только в том случае, если для вышеописанного атрибута ordering установлено значение «parallel». Указывает на то, будут ли отменены запущенные экземпляры Действий, если значение атрибута completionCondition становится «true».

Действия, включенные в состав Спонтанного Подпроцесса, друг с другом, как правило, не соединяются. В ходе выполнения Подпроцесса запущенными МОГУТ одно или несколько Действий. Действия МОГУТ выполняться многократно. То, когда будет запущено Действие, каким будет следующее Действие, а также другие детали выполнения Действий определяются Исполнителем.

Примерами Процессов, входящих в состав Спонтанного Подпроцесса, являются разработка кода (на низком уровне), поддержка клиентов, а также написание главы книги. Рассмотрим, к примеру, написание главы для книги. Мы видим, что данный Процесс включает следующие Действия: поиск темы, составление текста, редактирование текста, создание дизайна, графическое оформление текста, оформление ссылок и т.д. (см. фигуру 10.37). В таком Процессе МОЖЕТ наблюдаться определенная зависимость Задач друг от друга, например, редактирование текста не может происходить раньше его написания. Однако такая корреляция между экземплярами Задачам по написанию и редактированию текста не обязательна. Редактирование может возникать нерегулярно и зависит от текста, полученного в результате выполнения нескольких экземпляров Задачи по написанию текста.

Фигура 10.37 – Спонтанный Подпроцесс написания главы для книги

Хотя в Спонтанном Подпроцессе структура не определена, в его детали все же может быть добавлена информация о последовательности Действий или корреляции данных. К примеру, можно расширить вышеописанный Спонтанный Подпроцесс написания главы для книги путем добавления в него Объектов данных, Ассоциаций или Потоков операций (см. фигуру 10.38).

Однако использование в Спонтанном Подпроцессе элементов потока должно осуществляться со следующими ограничениями, не имеющими отношения к использованию элементов в Подпроцессах других типов:

Фигура 10.38 – Спонтанный Подпроцесс написания главы для книги с отображением последовательности Действий и зависимых данных

Объект данных, предоставленный для Задач на входе, является дополнительным ограничением для выполнения этих Задач. В данном случае Исполнители, хотя и решают, когда будут выполнены Задачи, уже ограничены в действиях тем, что не могут начать выполнение Задачи без соответствующих данных. Наличие Потока операций между Задачами (например, между разработкой дизайна и оформлением текста в соответствии с дизайном) устанавливает зависимость, согласно которой вторая Задача ДОЛЖНА быть выполнена после выполнения первой. Это не означает, что вторая Задача должна выполняться незамедлительно, но лишь то, что она ДОЛЖНА выполняться после того, как будет завершена первая Задача.

Проблемой для BPM стало отслеживание статуса Спонтанного Подпроцесса. Как правило, Процессы такого типа контролируются при помощи приложений для групповой работы (например, e-mail). BPMN позволяет моделировать Процессы, необязательные для выполнения, хотя определенные механизмы для выполнения процессов, способные отслеживать Спонтанные Подпроцессы, существуют. Исходя из этого, Спонтанный Подпроцесс будет завершен при определенных условиях, которые указываются посредством установки значения для атрибута completionCondition, определяющего, в свою очередь, атрибуты Процесса, корректируемые Действием данного Процесса.

Источник