Промежуточное событие ошибка

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

10.4.3 Конечное событие

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

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

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

Фигура 10.71 – Графический элемент Конечное событие

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

Конечное событие имеет следующие особенности:

• Процессы МОГУТ содержать несколько Конечных событий на каждом уровне.
• Конечного события является ОПЦИОНАЛЬНЫМ. Процесс определенного уровня — Процесс или Развернутый Подпроцесс – МОЖЕТ содержать в своем составе Конечное событие, однако, это не является необходимым условием.
  • В случае, если диаграмма не содержит Конечного события, то скрытое Конечное событие НЕ ДОЛЖНО оказывать влияние на результат Процесса.
  • В случае, если диаграмма содержит Стартовое событие, то ДОЛЖНО БЫТЬ по-меньшей мере и одно Конечное событие.
  • В случае, если диаграмма не содержит Конечного события, то Элементы потока, не имеющие Исходящих потоков операций (не являющиеся источниками Потоков операций), указывают на окончание какого-либо маршрута, содержащегося в Процессе. Однако Процесс НЕ ДОЛЖЕН БЫТЬ завершен до тех пор, пока к концу не придут все параллельные маршруты.

Примечание: Диаграмма Процесса может содержать Процессы разных уровней (например, Развернутый Подпроцесс или Действие Вызов, используемое для вызова других Процессов). Использование Стартового и Конечного событий является свободным для Процессов любого уровня, содержащихся в диаграмме.

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

End Event Results Результаты Конечного события

По типу результата Конечные события делятся на: Неопределенные, Сообщения, Эскалации, Ошибки, Отмены, Компенсации, Сигналы, Завершения, Множественные. Каждый из этих девяти типов Конечного события определяет то, каким образом Поток операций достигнет этого События.

Таблица 10.87 – Типы Конечного события

Соединение с Потоком операций

Для того, чтобы увидеть полный список графических элементов и узнать, каким образом они МОГУТ являться целями и источниками Потока операций, обратитесь к пункту 7.5.1 «Правила Соединения Потоков Операций».

• Конечное событие ДОЛЖНО являться целью Потока операций.
• Конечное событие МОЖЕТ иметь множество Входящих потоков операций.

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

• Конечное событие НЕ ДОЛЖНО являться источником Потока операций. Оно НЕ ДОЛЖНО иметь Исходящих потоков операций.
  • Исключением является ситуация, когда Конечное событие включено в состав Развернутого Подпроцесса и соединено с границами этого Подпроцесса. В данном случае, Поток операций, направленный от Процесса более высокого уровня, на выходе МОЖЕТ быть присоединен к Конечному событию, а не границам Подпроцесса.

Соединение с Потоком сообщений

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

Примечание: Все Потоки сообщений ДОЛЖНЫ соединять два разных Пула. Они МОГУТ быть присоединены к границам Пула, а также к Элементам потока внутри этого Пула. Они НЕ ДОЛЖНЫ использоваться для соединения двух элементов внутри одного Пула.

• Конечное событие НЕ ДОЛЖНО являться целью Потока сообщений. Оно не должно иметь Входящих потоков сообщений.
• Конечное событие МОЖЕТ являться источником Потока сообщений и иметь как несколько Исходящих потоков сообщений, так и ни одного. Любой Исходящий поток сообщений, направленный от Конечного события, будет содержать Сообщение, отсылаемое при запуске этого События.
  • Если от Конечного события отходит несколько Исходящих потоков сообщений, то атрибут Result Конечного сообщения ДОЛЖЕН иметь значение Message или Multiple.
  • Если от Конечного события отходит более одного Исходящего потоа сообщений, то атрибут Result Конечного сообщения ДОЛЖЕН иметь значение Multiple.

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

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

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

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

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

Фигура 10.72 – Графический элемент Промежуточное событие

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

Триггеры Промежуточного события

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

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

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

Промежуточное событие в составе Стандартного потока операций

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

• Если Промежуточное событие запускает триггер (приводит к какому-то результату), то такой триггер срабатывает немедленно (например, отсылается Сообщение); при этом дальнейший ход токена будет совпадать с ходом основного Исходящего потока операций.
• Если Промежуточное событие реагирует на триггер, то токен не покидает данное Событие до тех пор, пока не появится триггер (например, получение сообщения). После этого дальнейший ход токена будет совпадать с ходом основного Исходящего потока операций.

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

Таблица 10.89 – Промежуточное событие в составе Стандартного потока операций

Промежуточное событие, соединенное с Действием

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

Таблица 10.90 – Типы Промежуточного события, соединенного с Действием

Атрибуты Событий, присоединенных к границам элементов

Элемент BoundaryEvent — Промежуточное событие, присоединенное к границам других Элементов потока — наследует атрибуты и ассоциации элемента CatchEvent (см. таблицу 8.44). Таблица 10.91 содержит информацию о дополнительных атрибутах и ассоциациях элемента BoundaryEvent.

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

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

Таблица 10.92 – Возможные значения атрибута cancelActivity

Соединение с Действием

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

• Непосредственно к границе Действия МОЖЕТ БЫТЬ присоединено одно или более Промежуточных событий.
  • Присоединенное Промежуточное событие ДОЛЖНО БЫТЬ одного из следующих типов (EventDefinition): Сообщение (Message), Таймер (Timer), Ошибка (Error), Эскалация (Escalation), Отмена (Cancel), Компенсация (Compensation), Условие (Conditional), Сигнал (Signal), Множественный (Multiple), Параллельный Множественный (Parallel Multiple).

• Промежуточное событие типа Отмена МОЖЕТ БЫТЬ присоединено к границе Подпроцесса только при значении атрибута Transaction Подпроцесса, равном «true».

Соединение с Потоком операций

Для того, чтобы увидеть полный список графических элементов и узнать, каким образом они МОГУТ являться целями и источниками Потока операций, обратитесь к пункту 7.5.1 «Правила Соединения Потоков Операций».

• Если Промежуточное событие присоединено к границе Действия, то:
  • Промежуточное событие НЕ ДОЛЖНО являться целью Потока операций или иметь каких-либо Входящих потоков операций.
    • Промежуточное событие ДОЛЖНО являться источником Потока операций.
    • Промежуточное событие МОЖЕТ являться источником множества Потоков операций. Для каждого такого Потока операций ДОЛЖЕН БЫТЬ создан новый параллельный маршрут.

• Исключением является Промежуточное событие Компенсация, которое НЕ ДОЛЖНО ИМЕТЬ Исходящих потоков операций, однако, МОЖЕТ иметь исходящую Ассоциацию.
• В состав Стандартного потока операций МОГУТ входить Промежуточные события следующих типов (EventDefinition): Неопределенное (None), Сообщение (Message), Таймер (Timer), Эскалация (Escalation), Компенсация (Compensation), Условие (Conditional), Связь (Link), Сигнал (Signal), Множественный (Multiple), Параллельный Множественный (Parallel Multiple). В Стандартном потоке операций НЕ ДОЛЖНЫ участвовать Промежуточные события типов Отмена (Cancel) и Ошибка (Error).
  • Если Промежуточное событие включено в состав Стандартного потока операций, то:
    • Промежуточное событие ДОЛЖНО являться целью Потока операций. Примечание: В отличие от BPMN 2.0, BPMN 1.2 допускает возможность отсутствия у некоторых Промежуточных событий Входящих потоков операций.
    • Промежуточное событие МОЖЕТ иметь множество Входящих потоков операций.Примечание: Если Промежуточное событие имеет множество Входящих потоков операций, то Поток операций считается неконтролируемым. Это означает, что Событие будет запущено по прибытии токена по одному из маршрутов (для того, чтобы отреагировать на триггер или запустить его). Данное Событие не будет ожидать прибытия других токенов по оставшимся маршрутам. Если по тому же или какому-либо другому маршруту прибывает другой токен, запускается другой экземпляр События. Если возникает необходимость в контроле Потока операций, все маршруты должны быть соединены посредством Шлюза, предшествующего Событию (дополнительную информацию о Шлюзах смотрите в разделе 10.5 «Шлюзы»).

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

• Промежуточное событие типа Связь НЕ ДОЛЖНО являться источником и целью Потока операций одновременно.

Для использования Промежуточного события Связь в качестве Соединителя страниц или объекта «GOTO» необходимо учитывать следующие требования:

• Промежуточное событие Связь МОЖЕТ являться как целью (Событие Связь как цель), так и источником (Событие Связь как источник) Потока операций. Однако оно НЕ ДОЛЖНО являться и целью, и источником одновременно.
  • Одно Событие Связь, используемое как цель, МОЖЕТ иметь множество Событий Связь, используемых как источники.
  • Одно Событие Связь, используемое как источник, НЕ ДОЛЖНО иметь множество Событий Связь, используемых как цели.

Соединение с Потоком сообщений

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

Примечание: Все Потоки сообщений ДОЛЖНЫ соединять два разных Пула. Они МОГУТ быть присоединены к границам Пула, а также к Элементам потока внутри этого Пула. Они НЕ ДОЛЖНЫ использоваться для соединения двух элементов внутри одного Пула.

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

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

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

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

Это описание элементов BPMN 2.0 поможет вам.

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

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

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

BPMN 2.0 — почти полное описание элементов нотации

Операции

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

Сервисная операция

Операция, которая выполняется сервисом или механизмом. Иными словами, это операции, выполняемые автоматически. Пример — рассчитать цену с учетом скидки. Операция выполняется программой автоматически. Этот тип операций удобно использовать, когда вы отображаете работу программы или инструмента. Или показываете взаимодействие человека и программы. Кстати, пул, который означает сотрудника в модели, также может обозначать программу. Если задать один пул как программу, а другой как пользователя, то можно раскрыть процесс взаимодействия. Такое возможно только в нотации BPMN 2.0.

Пользовательская операция

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

Ручная операция

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

Отправка сообщения

Операция, результатом которой является отправленное сообщение. И вот первый пример гибкости нотации — операция «отправить электронное письмо» может быть как типом «пользовательская операция», так и «отправка сообщения». Какой тип использовать, зависит от целей моделирования конкретного процесса и правил, которые вы для себя приняли.

Получение сообщения

Операция, связанная с получением сообщения. Пример — получить письмо на почте.

Выполнение сценария

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

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

Выполнение бизнес-правила

Операция, которая запускает действие какого-то правила. Сценарии и правила схожи. И то, и другое создается и известно заранее. Но есть и разница. Сценарий — ряд действий, который нужно выполнить, чтобы завершить задачу. Правило же предполагает наличие определенных условий и вариантов действий. Сценарий выполнять обязательно. Правило дает выбор. Пример операции, связанной с бизнес-правилом — принять решение о закупке. В качестве правила будет выступать условие — закупка разрешена в рамках определенной суммы. Если сумма закупки выше, то нужно согласовать с вышестоящим руководством. Кстати, в этом примере операция «правило» может запустить операцию «сценарий».

Бизнес-правило — это уникальная штука! И с точки зрения моделирования бизнес процессов, и с точки зрения выполнения. Есть мнение, что описанные бизнес процессы строги и не дают свободу действий сотрудникам. Это неверно. И как раз бизнес-правила дают допустимую свободу действий модели — с точки зрения развития процесса, сотруднику — с точки зрения действий.

Операция-ссылка

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

Операция-вызов

Отличается от ссылки тем, что если вы используете операцию-вызов, то еще и используете ресурсы этой операции или процесса. Т.е. «одалживаете» сам процесс из другого места.

Процессы в BPMN 2.0

Повторно используемый процесс

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

Процесс-ссылка

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

Событийный процесс

Особый вид процесса. Особенность заключается в том, что такой процесс не имеет входящих/исходящих потоков. Т.е. на диаграмме он не соединен стрелками с другими процессами/операциями. А запускается он, когда в процессе наступает событие, такое же, какое указано в событийном процессе в качестве старта. Зачем это нужно? Иногда не нужно включать процесс в основной поток. 

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

Спонтанный процесс (ad-hoc)

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

Циклы

Циклическими могут быть как операции, так и процессы.

Стандартное повторение

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

Множественный цикл

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

Компенсация

Операция или процесс компенсации выполняется в том случае, если в процессе произошло что-либо, что требует дополнительных действий для его завершения. Например, при согласовании документа необходимо внести поправки. В таком случае выполняется компенсирующее действие «внести поправки», которое позволяет завершить процесс согласования. Форма компенсации очень удобна для моделирования. Компенсация — отличительная черта нотации BPMN 2.0.

События в BPMN 2.0

Все виды событий — стартовые, промежуточные и события окончания — тоже делятся на типы. Точнее, они имеют разные тригеры — спусковые крючки. Спусковой крючок — это тип условия, при котором наступает событие. Например, событие — получение сигнала. Тип события — сигнал. Спусковой крючок — его получение.

Тригеры событий схожи во всех типах, но имеют свои особенности. Поэтому каждое событие рассматривается с точки зрения трех типов.

Входящие / исходящие события

Перед тем, как приступить к тригерам, объясню, что такое входящие и исходящие события.

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

Событие с исходящим тригером (исходящее событие) означает, что событие свершается, если что-то отправлено. Опять же — отправлено письмо. Исходящими событиями удобно отображать выполнение условия по передаче информации.

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

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

Спусковые крючки событий

Сообщение

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

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

Событие окончания — отправлено подтверждение отгрузки товара клиенту (только исходящее)

Время

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

Пример — событие «последний рабочий день месяца» запускает процесс «инвентаризация». Таймер не может быть событием окончания. Это противоречит сути процессного подхода — каждый процесс производит продукт. А если процесс может быть завершен просто по времени, то это дает возможность не получить продукт в итоге.

Ошибка

Сигнал об ошибке. Такой тип события всегда связан с другим процессом. Т.е. в каком-то процессе возникла ошибка, которая запускает последующий процесс. Пример: событие «ошибка соединения», запускает процесс проверки интернет-соединения с компьютером.

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

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

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

А еще с помощью промежуточного события «ошибка» отображают риски в процессе. Ну и способы работы с ними.

Эскалация

Запускает процесс, который ускоряет выполнение другого процесса, если тот выполняется неправильно. Событие «Эскалация» всегда связано с другим процессом, который передает (эскалирует) выполнение процесса другому человеку или системе, а тот его принимает.

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

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

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

Отмена

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

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

Событие окончания «никто не пришел» отменяет подготовку вечеринки и все, что было для нее сделано.

Событие отмены не может быть стартовым.

Компенсация

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

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

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

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

Состояние

Событие, обозначающее некое состояние объекта. Состояние относится к параметрам. Например, стартовое событие «температура процессора превысила 70 градусов» запускает процесс охлаждения процессора. Или стартовое событие, обозначающее состояние вашей второй половины как «плохое настроение», запускает процесс приготовления его/ее любимого блюда. То же касается и промежуточных событий — состояние какого-то объекта определяет ветку развития процесса.

Событие окончания не может иметь тригер состояния.

Сигнал

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

Событие начала «свисток чайника» — это сигнал, который запускает процесс заваривания чая.

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

Событие окончания «выключение света на сцене» передает сигнал об окончании выступления и завершает процесс.

Множественное

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

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

То же касается и промежуточного и события окончания. Единственный нюанс — промежуточное событие может быть как исходящим, так и входящим. Событие окончания может быть только исходящим.

Параллельное множественное

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

Ссылка

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

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

Ссылки могут быть как входящими, так и исходящими.

Терминация

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

Прерывающее и непрерывающее событие

Ну и последнее, что надо знать о свойствах событий. Каждое событие в нотации BPMN 2.0 может прерывать или не прерывать процесс. Это относится только к событиям начала и промежуточным событиям. Прерывание означает что наступление события необходимо для продолжения процесса. Если же событие не влияет на ход процесса, не определяет или не изменяет его, то оно просто учитывается. Например, автоматическая фиксация какого-нибудь KPI не влияет на процесс, но тем не менее может быть отображена на схеме. Также непрерывающими событиями можно отображать совокупность условий, которые на данный момент не влияют на процесс, но будучи выполненными вместе собираются в Множественное или Множественное параллельное событие, которое уже влияет на процесс. Примеры подобных ситуаций я соберу в отдельной статье.

Шлюзы BPMN 2.0

Шлюз «Исключающее ИЛИ», основанный на данных (XOR)

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

Шлюз «Исключающее ИЛИ», основанный на событиях (XOR)

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

Шлюз ИЛИ (OR)

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

Комплексное решение, объединение

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

Параллельная развилка, объединение (AND)

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

Объекты данных BPMN 2.0

Исходящие данные

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

Входящие данные

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

Потоки BPMN 2.0

Поток по умолчанию

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

Условный поток

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



На сегодня все. Я рассказал почти обо всех элементах нотации BPMN 2.0. Хотите освежить в памяти описание базовых элементов? Оно находится здесь. Есть еще дополнительные типы диаграмм и элементов, например диаграмма Хореографии и Диаграмма взаимодействия, но они используются не так часто. О них как-нибудь потом.

In process automation, you often encounter deviations from the default scenario. One way to resolve these deviations is using a BPMN error event, which allows a process model to react to errors within a task.

For example, if an invalid credit card is used in the process below, the process takes a different path than usual and uses the default payment method to collect money.

Defining the error​

In BPMN, errors define possible errors that can occur. Error events are elements in the process referring to defined errors. An error can be referenced by one or more error events.

An error must define an errorCode (e.g. InvalidCreditCard). The errorCode is a string used to match a thrown error to the error catch events.

Throwing the error​

An error can be thrown within the process using an error end event.

Alternatively, you can inform Zeebe that a business error occurred using a client command. This throw error client command can only be used while processing a job.

In addition to throwing the error, this also disables the job and stops it from being activated or completed by other job workers. See the gRPC command for details.

Catching the error​

A thrown error can be caught by an error catch event, specifically using an error boundary event or an error event subprocess.

Starting at the scope where the error was thrown, the error code is matched against the attached error boundary events and error event sub processes at that level. An error is caught by the first event in the scope hierarchy matching the error code. At each scope, the error is either caught, or propagated to the parent scope.

If the process instance is created via call activity, the error can also be caught in the calling parent process instance.

Error boundary events and error event subprocesses must be interrupting. This means the process instance will not continue along the regular path, but instead follow the path that leads out of the catching error event.

If the error is thrown for a job, the associated task is terminated first. To continue the execution, the error boundary event or error event subprocess that caught the error is activated.

Unhandled errors​

When an error is thrown and not caught, an incident (i.e. Unhandled error event) is raised to indicate the failure. The incident is attached to the corresponding element where the error was thrown (i.e. the task of the processed job or the error end event).

When you resolve the incident attached to a task, it ignores the error, re-enables the job, and allows it to be activated and completed by a job worker once again.

The incident attached to an error end event cannot be resolved by a user because the failure is in the process itself. The process cannot be changed to catch the error for this process instance.

Business error vs. technical error​

In real life, you’ll also have to deal with technical problems that you don’t want to treat using error events.

Suppose the credit card service becomes temporarily unavailable. You don’t want to model the retrying, as you would have to add it to each and every service task. This will bloat the visual model and confuse business personnel. Instead, either retry or fall back to incidents as described above. This is hidden in the visual.

In this context, we found the terms business error and technical error can be confusing, as they emphasize the source of the error too much. This can lead to long discussions about whether a certain problem is technical or not, and if you are allowed to see technical errors in a business process model.

It’s much more important to look at how you react to certain errors. Even a technical problem can qualify for a business reaction. For example, you could decide to continue a process in the event that a scoring service is not available, and simply give every customer a good rating instead of blocking progress. The error is clearly technical, but the reaction is a business decision.

In general, we recommend talking about business reactions, which are modeled in your process, and technical reactions, which are handled generically using retries or incidents.

Additional resources​

XML representation​

A boundary error event:

<bpmn:error id="invalid-credit-card-error" errorCode="Invalid Credit Card" />

<bpmn:boundaryEvent id="invalid-credit-card" name="Invalid Credit Card" attachedToRef="collect-money">
 <bpmn:errorEventDefinition errorRef="invalid-credit-card-error" />
</bpmn:boundaryEvent>

References​

• Incidents

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

10.4.6 Обработка Событий

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

Обработка Стартовых событий

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

Эксклюзивный запуск Процесса. Большинство общепринятых сценариев запуска Процесса предполагают запуск его экземпляра с помощью одного из возможных Стартовых событий. Всякий раз, когда такое Событие появляется на диаграмме Процесса, формируется новый его экзмепляр. Из приведенных ниже примеров видно, как два События соединены с одним Действием (см. фигуру 10.97). В ходе выполнения Процесс появление любого из этих Событий определяет последующее создание нового экземпляра данного экземпляра Процесса, а также запускает Действие. Обратите внимание, что одиночное Стартовое событие Множественного типа, содержащее значения MessageEventDefinition, будет вести себя также.

Фигура 10.97 – Эксклюзивный запуск Процесса

Фигура 10.98 отображает Процесс, запускаемый с помощью основанного на событиях Шлюза.

Фигура 10.98 – Процесс, запускаемый с помощью основанного на событиях Шлюза

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

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

Синхронизация Событий. Если разработчику модели требуется объединить в одном Процессе несколько отдельных Стартовых событий, он ДОЛЖЕН отобразить это в соответствии со схемой, приведенной в фигуре 10.99

Фигура 10.99 – Синхронизация Событий при запуске Процесса

Стартовое событие Параллельного Множественного типа МОЖЕТ объединять несколько отдельных Стартовых событий, каждое из которых ДОЛЖНО хотя бы раз происходить для того, чтобы сформировался новый экземпляр Процесса. Потоки операций, отходящие от такого События, имеют стандартное направление. Для получения более подробной информации об обработке Стартовых событий см. раздел 13.4.1.

Обработка Событий Стандартного потока операций (Промежуточных событий)

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

Обработка Событий, присоединенных к границам Действия (Промежуточных событий, сединенных с границей Действия, и Событийных Подпроцессов)

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

Промежуточное Событие, прерывающее Действие, к которому присоединено, определяется посредством установки значения «true» для атрибута cancelActivity. В какой бы момент ни происходило это Событие, выполнение соответствующего ему Действия прерывается. При этом формируется токен, следующий по направлению Потока операций и запускающий следующий элемент Процесса (связанный с Событием с помощью безусловного Потока операций, называемого Потоком исключений).

Промежуточное Событие, не прерывающее Действие, к которому присоединено, определяется посредством установки значения «false» для атрибута cancelActivity. В какой бы момент ни происходило это Событие, выполнение соответствующего ему Действия продолжается. Поскольку параллельно с продолжение выполнения Действия для направленного от События Потока пераций формируется токен, ДОЛЖНО учитываться то, что данный маршрут сливается с основным Потоком операций Процесса. В данном случае токен, как правило, завершается собственным Конечным Событием.

На фигуре 10.100 отображен фрагмент Процесса заказа тура, содержащий Подпроцесс. Данный Процесс состоит из основной части и трех Подпроцессов, работающих с событиями, которые направлены на обработку Событий в рамках одного контекста: Событийный Подпроцесс типа Ошибка – для отмены работы Подпроцесса; Событийный Подпроцесс типа Сообщение – для обновления статуса Подпроцесса при ожидании разрешения продолжать его выполнение; Событийный Подпроцесс типа Компенсация.

Фигура 10.100 – Пример Процесса, содержащего работающие Событийные Подпроцессы для встроенной обработки Событий

На фигуре 10.101 отображен фрагмент вышеописанного Процесса бронирования тура, содержащий не Подпроцессы, а обработчики присоединенных к Действиям Событий. Обратите внимание, что в данном случае обработчикам Событий не доступен контекст Подпроцесса «Booking»; они работают за его пределами. Это значит, что компенсация здесь представлена в виде черного ящика.

Фигура 10.101 – Пример Процесса, содержащего обработчик присоединенных к Действиям Событий

Необходимо учитывать разницу между прерывающими и непрерывающими Событиями. Обработка этих Событий описана в разделах выше. Если Событие является прерывающим (Ошибка, Эскалация, Сообщение, Сигнал, Таймер, Условие, Множественное, Параллельное Множественное), то для Событий одного типа ДОЛЖЕН использоваться только один Подпроцесс, работающий с Событиями. Это исключает последующее использование для них каких-либо других непрерывающих обработчиков.

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

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

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

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

Обработчики прерывающих Событий (Ошибка, Эскалация, Сообщение, Сигнал, Таймер, Условие, Параллельный Множественный)

Значение атрибута cancelActivity обработчиков прерывающих Событий равно «true». Неважно, на каком этапе Процесса возникает Событие, обрабатывается ли оно на границе с Действием или в общем потоке, выполнение относящегося к нему Действия прерывается. Если указан обработчик Ошибки общего потока (в Подпроцессе), он работает в рамках данного Подпроцесса. Если в наличие есть присоединенное в границе Действия Событие Ошибка, то Потоки операций направляются от этого События. Выполнение родительского Действия отменяется либо после завершения обработки Ошибки, либо при отхождении от границ События Потока операций.

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

Обработчики непрерывающих Событий (Эскалация, Сообщение, Сигнал, Таймер, Условие, Множнственный Параллельный Множественный)

Значение атрибута cancelActivity обработчиков прерывающих Событий равно «false».

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

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

В приведенном выше примере Процесса обработчик Событий позвляет обновлять данные кредитной карты

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

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

Обработка Конечных событий

При использовании Конечного события Завершение выполнение всех оставшихся в Процессе Действий завершается.

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

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

10.4.7 Рамки

Под рамками подразумевается контекст, в котором осуществляется выполнение Действия. Сюда входят:

• Доступные Объекты данных (включая входные и выходные данные).
• Доступные События для обработки и инициирования триггеров.
• Диалоги, имеющие быть в данном контексте.

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

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

Жизненный цикл экземпляра рамок, в свою очередь, может быть:

• Активирован
• Выполняется
• Выполнен
• Компенсируется
• Компенсирован
• С ошибкой
• Отменяется
• Отменен

В BPMN описаны графические элементы диаграммы, которые могут быть заключены в рамки, а именно:

• Хореография (Choreography)
• Пул
• Подпроцесс
• Задача
• Действие
• Многоуровневые элементы

Рамками определяется семантика:

• Видимости Объектов данных (включая входные и выходные данные).
• Выполнения Событий.
• Начала/завершения выполнения токена.

Заключенные в границы Объекты данных, События и родственные им элементы (correlation keys) могут отображаться на диаграмме или быть скрыты.

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

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

Online Modeler

Our modeler is an online and desktop tool for designing, discussing and sharing BPMN diagrams with your team.

Try Modeler

Overview

BPMN Symbol Overview

Artifacts

Events

Heads up!
For understanding the principle behavior of events in BPMN, check out Events: Basic Concepts.

Participants

Introducing Pools, the conductor and the orchestra

We already described how to use lanes to assign responsibility for tasks or subprocesses to different task managers. Lanes always exist in a pool, and the lane boundaries represent process boundaries from start to end. To BPMN, the pool represents a higher-ranking instance compared to its lanes. The pool assumes process control – in other words, it assigns the tasks. It behaves like the conductor of an orchestra, and so this type of process is called “orchestration.”

In the diagram below, the “conductor” arranges for Falko to process task 2 as soon as Robert completes task 1. The conductor has the highest-level control of the process, and each instrument in the orchestra plays the tune the conductor decides upon:

process conductor

Robert

start

task 1

Stefan

task 4

Christian

task 3

Falko

task 2

Do you think this is unrealistic? Many experienced process modelers have problems with this way of thinking. They would prefer to model a process sequence like that shown below on the assumption that no almighty conductor exists in their company, and that individual process participants have to coordinate and cooperate on their own:

Robert

start

task 1

passing on to
Falko

Stefan

task 4

Christian

task 3

passing on to
Stefan

Falko

task 2

passing on to
Christian

But to coordinate cooperation with BPMN requires explicit modeling. You assign each task manager a separate pool, and the process passes from one to the next as a message flow as shown in below. In principle, this creates four independent conductors. These have control over their respective mini-processes, but they can’t do anything other than to send messages that trigger their successor processes:

Stefan

task 4

start

Christian

task 3

passing on to
Stefan

start

Falko

task 2

passing on to
Christian

start

Robert

start

task 1

passing on to
Falko

That seems complicated – and you don’t have to choose this method for practical modeling. It reveals a basic principle, however, that you must understand. Even though BPMN lanes look very much like those of other process notations, they represent an entirely different way of thinking, which we attribute to BPMN’s origin in the world of process automation. In that world, the process engine controls all tasks in the process, even though different task managers may execute them. So the process engine equates to the mysterious, almighty process conductor.

Have you heard of service orchestration in connection with Service Oriented Architecture (SOA)? That’s almost exactly the task of a process engine, except that these services are not only fully automated web services; they also can be tasks executed by human process participants as directed by the process engine. What does that signify, however, for purely functional process modeling, in which you also describe processes not controlled by such a process engine? There’s no general answer to that question.

You can eliminate pools and work just with lanes, modeling the message exchange as normal tasks as shown before. That’s traditional, and it’s a pragmatic solution during, say, a transitional period that allows your co-workers to adapt. In the medium and long terms, however, avoiding pools denies you a powerful device for increasing the significance of process models.

We will show the usefulness of this new thinking by example. One thing to remember is that if you strive to harmonize your functional and technical process models to achieve a better alignment of business and IT, you inevitably face this type of process modeling whether you use BPMN or not.

Pools: The art of collaboration

We already examined the process represented below in connection with the event-based gateway:

Now consider the broader picture, and think about how this process happens from the point of view of the pizza delivery service. Presumably, it looks like here: As soon as we receive an order, we bake the pizza. Our delivery person takes it to the customer and collects the money, whereby the process completes successfully.

pizza sales
supplier

pizza baker

Order
received

bake pizza

delivery boy

deliver pizza

take the money

end

We want to link the two processes, that is, to examine the interaction of customer and delivery service from a neutral perspective. We can try to model this interaction by means of a pool and lanes as in here:

pizza- process

customer

hunger
noticed

choose pizza

order pizza

pizza
received

eat pizza

call pizza
delivery service

60 minutes

pizza received

supplier

pizza baker

bake pizza

delivery boy

deliver pizza

take the
money

But this doesn’t work well: There are tasks and events that reference interaction within the pool – waiting for the delivery, for instance, or collecting the money. Other tasks are carried out by roles oblivious to their partners, such as baking the pizza and eating the pizza. It is impossible to differentiate the two visually. Strictly speaking, the diagram is not semantically correct because message events always refer to messages received by the process from outside, and that’s not the case here.

If we go with pools, the whole process looks like below. Both processes in the combined representation would look just as they did before, but now they connect through message flows. BPMN calls this form of visualization a collaboration diagram. It shows two independent processes collaborating.

pizza sale
supplier

Lieferjunge

deliver pizza

take
the money

end

Pizza-Bäcker

bake pizza

order received

pizza order
customer

hunger
noticed

choose pizza

order pizza

eat pizza

hunger
satisfied

pizza received

60 minutes

pizza received

call pizza
delivery service

In two cases, the message flows do not end in an activity or event, but at the participants’ respective pool boundaries. The first one comes from the “inquire at delivery service” task; the second one connects to the “collect money” task. The rationale behind the first one is that our inquiry does not influence the sequence flow of the deliverer. The pizza service may provide information or speed up its order processing in anticipation of a new order, but the baking, delivering, and collecting of money doesn’t change just because an inquiry came in. As for the “collect money” messages, there’s a flaw in the model of the customer process: we have to pay for the pizza before we eat it, and that task is still missing. We added it to the diagram below, and now we can connect the message flows directly to the “pay for pizza” task.

pizza sales
supplier

delivery boy

deliver pizza

end

take
the money

pizza baker

bake pizza

order
received

pizza order
customer

hunger
noticed

choose pizza

order pizza

eat pizza

hunger
satisfied

pizza received

60 minutes

call pizza
delivery service

pay for pizza

Create your own model or check out the “Order and Deliver Pizza” example diagram with Camunda’s free online modeler.

Collapsing Pools

It often happens that we don’t know the processes of all parties in detail. We may know the processes of our own company, for example, but not those of a partner company. As long as our partner and we adhere to agreed-upon interfaces, such as receiving or sending certain messages, things can still operate smoothly. As customers of the pizza delivery service, we expect the deliverer to:

• Accept pizza orders,
• Deliver ordered pizzas and collect the money, and
• Be available for inquiries.

As customers, we have little interest in the deliverer’s internal process. Maybe he bakes and then delivers the pizza; maybe when he’s out of supplies, he gets another pizza service to bake the pizza and deliver it. That’s his problem – we simply expect to receive our pizza. In modeling such cases, we can hide the deliverer’s process and collapse the pool:

pizza order
customer

hunger
noticed

choose pizza

order pizza

eat pizza

hunger
satisfied

pizza
received

60 minutes

call pizza
delivery service

pay for pizza

pizza
received

supplier

We could go a step further and collapse the customer’s pool too. Now we see only the messages to be exchanged, assuming that we label the arrows to give us the general idea. The downside is that we can’t recognize interdependencies any more. We can’t see if the inquiry always goes out, or only takes place under certain conditions – the actual case:

pizza delivery – supplier

pizza order – customer

inquiry

order

take the money

delivery

pay

Lanes

We have talked about what to do in our processes, but we have not yet explained who is responsible for executing which tasks. In BPMN, you can answer this question with lanes.

Hover over orange symbols for explanation

The diagram shows that the tasks in our sample process were assigned to particular people. We can derive the following process description from the assignments: If Christian is hungry, he chooses a certain recipe. Depending on what Christian chooses, he can either take care of it himself (cook pasta), or he can get his roommates on board. If the latter, Falko cooks steak and Robert prepares salad. In the end, Christian eats. The three lanes (Christian, Falko, Robert) are united in one pool designated “flat-sharing community.”

Activities

Task

So far, we have used only tasks of undefined types, though BPMN provides the opportunity to work with task types just as it does for event types. Primarily, task types are intended to model processes that are technically executable. Task types are applied infrequently in practice. We know from experience, however, that task types can be particularly useful when modeling engineering requirements.

Hover over orange symbols for explanation

Task Markers

In addition to those various types of tasks, we can mark tasks as loops, multiple instances, or compensations. Markers can be combined with the assigned types.

Loop

A loop task repeats until a defined condition either applies or ceases to apply. Perhaps we suggest various dishes to our dinner guests until everyone agrees. Then, we can prepare the meal:

time for
dinner

suggest dish

prepare meal

meal
prepared

until everyone
agrees

In the example, we executed the task first and checked afterwards to see if we needed it to execute again. Programmers know the principle as the “do-while” construct. We can also apply a “while-do” construct, however, and so check for a condition before the task instead of afterward. This occurs rarely, but it makes sense if the task may not execute at all.

You can attach the condition on which a loop task executes for the first time or, as shown in the example, apply the condition on repeated executions as an annotation to the task. You can store this condition as an attribute in a formal language of your BPMN tool as well. That makes sense if the process is to be executed by a process engine.

Multiple Instance

The individual cycles of a loop task must follow each other. If for example we live in a flat-sharing community and the roommates feel like eating pizza, the “choose pizza” task must be repeated for each roommate before we can order. You’d sit together and pass a menu around until finally everyone has made a decision. There are student apartments where they do handle it like that – more evidence that students have too much time on their hands! It is much more efficient for all roommates to look at the menu at once, and they choose a pizza together. You can model this process using the “multiple task” (see below). A multiple task instantiates repeatedly and can be executed in sequence or in parallel, with the latter being the more interesting case.

shared flat
craves pizza

choose pizza

order pizza

pizza
ordered

everyone in the
flat

Do you think the example is absurd? How does your company check invoices for group orders, such as for office supplies? Do you forward the invoice from one employee to the next, so that each person can sign off on the items he or she ordered, before you pay the invoice? If so, you live in a flat-sharing community, and you urgently should consider optimizing your process. Automating invoices is still one of the top BPM projects, and the top goal of such projects often is one of parallelization.

Compensation

We explain the benefit of the compensation event by means of an example. The compensation task type is applied exclusively in the context of a compensation event. Accordingly, it is integrated in the process diagram only by associations, never by sequence flows.

The possible combination of the compensation with a loop or multiple instance as shown below is worth mentioning. In this case, both markers are placed in parallel. As with the other markers, the compensation can be combined with the task types already introduced. A manual compensation task that repeats until it succeeds or that executes repeatedly and in parallel as far as possible, is therefore eminently practical.

…

book trip

…

cancel trip

…

invite all
friends via
mass email

…

uninvite
everyone via
phonecall

manual loop
compensation

manual parallel
compensation

call the travel agency
again and again until it
carves in

Subprocess

Encapsulate complexity

The examples in this tutorial either deal with simple processes, or they diagram complex processes superficially so that the models fit on one page. When modeling your process landscape, you don’t have this luxury. You have to rough out your processes so that you can get the general ideas in place and recognize correlations. Then you have to develop a detailed description, so that you can analyze exactly where the weak points are or how you’ll have to execute the process in practice. The possible top-down refinements or bottom-up aggregations mark the difference between true process models and banal flow charts, between sophisticated BPM software products and mere drawing programs.

BPMN provides us with the subprocess to help with the expanding/collapsing view. A subprocess describes a detailed sequence, but it takes no more space in the diagram of the parent process than does a task. Both tasks and subprocesses are part of the activities class and are therefore represented as rectangles with rounded corners. The only difference is the plus sign, indicating a stored detailed sequence for the subprocess:

main process

start

task

subprocess

end

What good is that to us? That depends most on how your BPMN tool supports the following options for connecting subprocesses with their parent processes:

• Representation in a separate process diagram: The subprocess symbol links to a separate diagram. If your BPMN tool displays the process model in a web browser, for instance, clicking on the symbol would open a new page to display the detail diagram.
• Expanding in the process diagram of the parent process: The activity with the plus sign is called a collapsed subprocess. The plus sign suggests that you could click on it and make the subprocess expand. The BPMN specification provides for this option, though not all tool suppliers implement it. The diagram below shows how the subprocess was directly expanded in the diagram of the parent process. A tool supporting this function enables you to expand and collapse the subprocess directly in the diagram, respectively, to show or hide details.

main process

start

end

task

subprocess

task

task

Direct expansion may seem appealing, but often it is not useful in practice. Expanding the subprocess requires that all the adjacent symbols in the diagram shift to make room. This can result in sluggish performance with a complex diagram, and it can be visually nasty. The most important thing is that your tool provides for linking and that you can usefully navigate through the diagrams. In other words, it supports the first option above. Yes, it can be helpful to have your subprocess modeled and expandable directly from the parent process. That means process segments remain localized, and you can attach events too. This is, however, the less important option.

The sequence flow of the parent process ends in both cases at the left edge of the subprocess. The next sequence flow starts at the right edge. This means that sequence flows are not allowed to exceed the boundaries of the subprocess, which not every beginner knows, and which becomes a problem when a subprocess expands. Visualize a token that behaves as follows:

• The parent process starts, and a token is born.
• The token runs through the task and arrives at the subprocess, which causes the parent process to create an instance of the subprocess.
• Within the subprocess, a separate token is born which runs through the subprocess from the start to the end event, but the token of the parent process waits until the subprocess completes.
• When the subprocess token arrives at the end event, it is consumed, which completes the subprocess. Now the token of the parent process moves to its own end event.

The encapsulation in subprocesses that we’re describing isn’t restricted to two levels. You could just as easily have a parent process as a subprocess, or you could model further subprocesses on the level of a defined subprocess. How many levels you use and the level of detail you apply to model them is up to you. BPMN doesn’t specify this, and there can be no cross-company or cross-scenario cookbook to define levels. Participants in our BPMN workshops don’t like this, but there’s no point in hiding the fact nor attempting to explain it away. In the following chapters, we work often with subprocesses in explaining our best practices, but the truth is the number of refinement levels and their respective levels of detail is always situational. It depends on the organization, the roles of the project participants, and the goals for the process you’re modeling.

Attaching Events

We already learned about intermediate events that can be attached to tasks. The same events can be attached to subprocesses as well, which opens up a wide range of opportunity in process modeling. As shown in the diagram below, we can represent how a spontaneous dinner invitation leads to canceling our cooking process. In the process shown, however, we could ignore the invitation if our meal had already been prepared and we are already eating it:

hunger
noticed

choose recipe

prepare meal

eat meal

go out for dinner

hunger
satisfied

Where message, timer, and conditional events are involved, the parent process always aborts the subprocess when reacting to external circumstances. With error, cancellation, and escalation events, however, the subprocess reports these events to the parent process. This isn’t as abstract as it may sound.

stock maintenance

minimum stock
level reached

procurement

article
procured

delete article
from catalogue

article
deleted

order processing

order
received

check
availability

article
available?

ship article

financial
management

end

inform
customer

delete article
from catalogue

end

procurement

procurement

start

place order

available?

expect delivery

…

not
available

not
available

not
available

yes

no

yes

no

In the bottom right of the diagram above, the item procurement task can fail because the item is no longer available. Because item procurement is a global subprocess, it triggers an error event to tell the parent process that something went wrong. In business terms, this may mean that the customer who wanted to buy the item tells a salesperson that his or her order failed because the item is out of stock.

It is interesting that parent processes can handle the error message differently. While the disappointed customer must be informed within the scope of the order process, it is sufficient for the stock maintenance process to delete the item from the catalog. The respective parent processes decide what circumstances require canceling the subprocess and what happens next. That’s a principle that you can use to build flexible and modular process landscapes.

The signal event serves two functions. A parent process can react to a signal received from the outside while it executes a subprocess – this is much like a message event. But we also use the signal event to let the subprocess communicate things other than errors to the parent process. Primarily, this is because we can’t model this type of communication with message events. BPMN assumes that we always send messages to other participants who are outside of our pool boundaries; the communication between parent and subprocess doesn’t fit that mold. We don’t use signal events for directed communication, but rather to broadcast information akin to advertisements on the radio.

A better alternative provided in BPMN 2.0 is the escalation event. The subprocess can use an escalation event to report directly to the parent process, and the message won’t be regarded as an error message. Also, the parent process can receive and process messages from escalation events without canceling the subprocess because non-interrupting intermediate events can be attached:

order processing

order
received

check
availability

article
available?

ship article

financial
management

end

inform
customer

delete article
from catalogue

end

procurement

inform
customer

end

not available

procurement

start

place order

available?

expect delivery

…

not
available

late
delivery

late delivery

yes

no

in< 2
days

in> 2
days

no

Call Activity

Modularization and reuse

In version 1.2, BPMN differentiated between embedded and reusable subprocesses by assigning an attribute to a subprocess. In version 2.0, BPMN maintains this differentiation in principle, but it is defined differently. A subprocess now is embedded intrinsically, and it can be reused only by defining it as a global subprocess, and then referencing it by means of a call activity. We therefore refer to embedded subprocesses and global subprocesses in the following.

An embedded subprocess can occur only within a parent process to which it belongs. An embedded subprocess cannot contain pools and lanes, but it can be placed within the pool or the lane of the parent process. Furthermore, an embedded subprocess may have only a none start event; start events such as messages or timers are not permitted. An embedded subprocess has essentially nothing more than a kind of delimited scope within the parent process, which may serve two goals:

• To encapsulate complexity (as already described)
• To formulate a “collective statement” on a part of the parent process by attaching events or placing markers. We deal with this option later.

On the other hand, global subprocesses may occur in completely different parent processes. There are a great many subprocesses that, in practice, are used over and over. A good example is the procurement of an item because a customer ordered it or you need to re-stock supply. Another example is invoicing because you’ve delivered or repaired an item as shown in the diagram below. In the example, notice that call activities differ from regular activities by their considerably thicker borders:

financial settlement

start

send invoice

…

…

payment
received

term of payment
exceeded

order processing

check
availability

order
received

article
available?

ship article

end

article
procurement

financial
settlement

stock maintenance

minimum stock
levle reached

article
procured

article
procurement

repair

repair order
received

carry out repair

end

financial
management

article procurement

start

place order

…

yes

no

The connection a global subprocesses has to its parent is considerably less close, and they can have their own pools and lanes. You can think of the participant responsible for a subprocess as a service provider for various parent processes. It is a like a shared service center.

The loose connection also affects data transfer between the parent and the subprocess. BPMN assumes that embedded subprocesses can read all the data of the parent process directly, but an explicit assignment is required for global subprocesses to be able to read it. That may seem like merely a technical aspect at first, one that modelers and the consumers of their models care to know about but won’t wish to bother with. After some consideration, however, you may see the impact this difference makes on the organization. Consider this: When your accounting department wants to issue an invoice for a repair, it always needs:

• A billing address
• The date of performance delivery
• A description of performance
• An amount to invoice
• An expected date of payment

The owners of order processing, not just the repair department, must provide this data. Accounting will want the data in a standard format, won’t it? This corresponds well to what BPMN calls required data mapping between parent processes and global subprocesses. (Do you notice how often these weird techie issues correspond to the organizational needs and expectations of a process?) BPMN simply forces us to formalize many matters that seem self-evident, or that remained unconscious or forgotten in the process design. Formalization is our best chance of keeping up in a fast-changing environment with ever more complex processes.

Adhoc

One marker available only for subprocesses is called ad-hoc. Recognize it by the tilde character as shown in the diagram below:

2 days before
departure

switch off
heating

create auto
response

give key to
neighbour

pack bags

…

Use the ad-hoc subprocess to mark a segment in which the contained activities (tasks or subprocesses) can be:

• Executed in any order,
• Executed several times, or
• Skipped.

Any party who executes this subprocess decides what to do and when to do it. You could say that the “barely structured” nature of what happens inside this subprocess reduces the whole idea of process modeling to an absurdity because what happens and when are the things we most want to control. On the other hand, this is the reality of many processes, and you can’t model them without representing their free-form character. Frequent examples are when a process relies largely on implicit knowledge or creativity, or when different employees carry out a process differently. You can use the ad-hoc subprocess to flag what may be an undesirable actual state. Doing so could be a step on the path to a more standardized procedure.

BPMN 2.0 specifies which symbols must, which may, and which are forbidden to occur within an ad-hoc subprocess. They are:

• Must: Activities
• May: Data objects, sequence flows, associations, groups, message flows, gateways, and intermediate events
• Forbidden: Start and end events, symbols for conversations and choreographies

By means of the specification, mixed forms – so-called weakly structured processes – can be modeled as shown in here:

textbook shall be writtenrecruitauthorsplan contentsresearch topicswrite textcreate graphicsinclude graphics into textreleasecontributiongeneratemanuscriptmanuscriptcompleteeach author!

Event Subprocess

BPMN 2.0 introduced a completely new construct, the event subprocess. We locate an event subprocess within another process or subprocess. Recognize them by their dotted-line frames.

A single start event always triggers an event subprocess, and this can only happen while the enclosing process or subprocess remains active. For event subprocesses, there can be interrupting (continuous line) and non-interrupting (dashed line) events. This is the same differentiation made as for attached intermediate events. Depending on the type of start event, the event subprocess will cancel the enclosing subprocess, or it will execute simultaneously. You can trigger non-interrupting event subprocesses as often as you wish, as long as the enclosing subprocess remains active.

Okay, that’s pretty abstract, but we can demonstrate how an event subprocess works with an example:

invite friends for
dinner

meal preparations

include guest

a new guest has
announced himself

take new guest
into account

provide meal

cooking meal
failed

order meal

choose recipe

prepare meal

eat meal

We invited a couple of friends for dinner. This starts the “dinner preparation” subprocess of choosing a recipe and then preparing the meal. While we are doing that, the telephone rings. Another guest invites himself to dinner. Spontaneous as we are, we just increase the amount of food or set another place at the table without interrupting the meal preparation. If an accident happens during preparation, however, the error immediately triggers the interrupting event subprocess for remedial action. We order food for delivery. When this event subprocess completes, we exit the enclosing subprocess through the regular exit and attend to eating the meal.

You can see below how event subprocesses are represented in collapsed state: The frame is a dotted line, and we have again used the plus sign to represent collapsed subprocesses. In the top left corner, we also have the start event triggering the subprocess.

invite friends for
dinner

meal preparations

choose recipe

prepare meal

include guest

provide meal

eat meal

The event types that can trigger both interrupting and non-interrupting event subprocesses are:

• Message
• Timer
• Escalation
• Conditional
• Signal
• Multiple
• Multiple parallel

There are two more types for the interrupting event subprocesses:

• Error
• Compensation

Gateways

Data-based Exclusive Gateways

Hover over orange symbols for explanation

Certain things can only be done under certain circumstances, so few processes always take the same course. In our simple example, we want to go into the details of cookery. Driven by hunger, we think about what we are going to cook today. We only know three recipes, so we choose one. We can either cook pasta or cook a steak or prepare a salad. Let’s say that these options are exclusive – we will never prepare more than one at a time. The point of decision on what to do next is called gateway. We decide based on available data (the chosen recipe) and we follow only one of the paths, which is a data-based exclusive gateway. We abbreviate “exclusive gateway” as XOR.

Heads up!
Bear in mind that a gateway is not a task! You have to determine facts and needs before reaching a gateway.

Best Practice: Naming Conventions

As in the diagram above, we place the crucial question before the gateway. This is our convention, which has proved its value in our projects. Possible answers go on parallel paths after the gateway, which is how the BPMN specification shows them. We always work with XOR gateways as follows:

• Model the task that requires a decision for the XOR gateway.
• Model the XOR gateway after that.
• Create a question with mutually exclusive answers.
• Model one outgoing path (or sequence flow) for each possible answer, and label the path with the answer.

FAQ: Do I have to draw the “X”-Marker inside the rhombus? I have already seen that symbol without any marker…

BPMN uses two symbols for XOR gateways:

They are identical in meaning. We always use the version with the X because it seems less ambiguous.

Parallel Gateways

Suppose that now we want a salad on the side. If you want salad no matter what, you could model it as we have done in this diagram:

Hover over orange symbols for explanation

The total of the task times equals the running time of the process, which was a total of 48 minutes for pasta and 43 minutes for steak. Congratulations: you’ve just analyzed your first process based on key data!

Still, this means waiting 23 or even 28 minutes until you can start to eat. Insufferable! You’re really hungry, but what can you do? Maybe you don’t prepare the salad first and then cook the pasta or the steak, but you work on both at the same time – in parallel. The appropriate symbol is the parallel gateway, or the “AND gateway” for short, as shown in here:

Hover over orange symbols for explanation

Diagramming tasks as parallel does not make simultaneous processing compulsory. In contrast to the example shown before, it is also not imperative that you prepare the salad before starting other tasks. Parallel preparation does, however, reduce our total time by 10 minutes. It is classic process optimization to make tasks parallel as much as possible.

Check yourself: What if we draw the same process, but leave the AND merge out for lack of space, and the path from the “prepare salad” task leads directly to the XOR merge. What happens if we instantiate the process, and we decide in favor of pasta?

The token is generated and then cloned as always at the AND split. As soon as we finish preparing the salad, the token passes through the XOR merge and “eat meal” executes. Five minutes later,”cook pasta” also completes. Its token passes through the XOR merge and “eat meal” executes again! That’s not the behavior we wanted.

hunger
noticed

Choose recipe

Desired dish?

Cook pasta

cook steak

prepare salad

Eat meal

Hunger
satisfied

10 Minutes

10 Minutes

20 Minutes

3 Minutes

15 Minutes

Pasta

Steak

Data-based inclusive gateways

We want to make our process even more flexible: When we are hungry, we want to eat

• Only a salad,
• A salad and “something real,” like pasta or steak, or
• Only something real.

If you want a more compact representation, you can use the data-based inclusive gateway – the OR gateway for short:

Hover over orange symbols for explanation

Heads up! In practice, handling OR gateways is not as simple as these examples imply. It’s easy to understand that progress depends on waiting for another token to reach an OR merge. It can be harder to trace the synchronization rules with complex diagrams that sprawl across several pages.

Event-based Gateways

We learned about the exclusive data-based (XOR) gateway option as a way to use different paths with regard to the data being processed. Users of other process notations recognize this type of branching, but BPMN gives us another way to design process paths: the event-based gateway – event gateway, for short. This gateway does not route based on data, but rather by which event takes place next. To understand the benefit, consider the process shown below: We order pizza and wait for it to be delivered. We can eat only after we receive the pizza, but what if the pizza doesn’t arrive after 60 minutes? We’ll make an anxious phone call, that’s what! We can model this with the event gateway:

Hover over orange symbols for explanation

As you can see here, not all intermediate events combine with the event gateway. You can, however, combine it with the receive task.

…

message

…

time

…

condition

…

signal

…

multiple

…

receive task

…

Events

Basic Concepts

Tasks and gateways are two of three flow elements we’ve come to know so far: Things (tasks) have to be done under certain circumstances (gateways). What flow element is still missing? The things (events) that are supposed to happen. Events are no less important for BPMN process models than tasks or gateways. We should start with some basic principles for applying them. We already saw Start events, intermediate events, and end events. Those three event types are also catching and/or throwing events:

Catching events are events with a defined trigger. We consider that they take place once the trigger has activated or fired. As an intellectual construct, that is relatively intricate, so we simplify by calling them catching events. The point is that these events influence the course of the process and therefore must be modeled. Catching events may result in:

• The process starting
• The process or a process path continuing
• The task currently processed or the sub-process being canceled
• Another process path being used while a task or a sub-process executes

Throwing events are assumed by BPMN to trigger themselves instead of reacting to a trigger. You could say that they are active compared to passive catching events. We call them throwing events for short, because the process triggers them. Throwing events can be:

• Triggered during the process
• Triggered at the end of the process

We can also model attached intermediate events with BPMN. These do not explicitly require waiting, but they do interrupt our activities, both tasks and sub-processes. Such intermediate events are attached because we position them at the boundary of the activity we want to interrupt.

Hover over orange symbols for explanation

A token running through the process would behave this way:

• The token moves to task 1, which starts accordingly.
• If event 1 occurs while task 1 is being processed, task 1 is immediately canceled, and the token moves through the exception flow to task 3.
• On the other hand, if event 1 does not occur, task 1 will be processed, and the token moves through the regular sequence flow to task 2.
• If event 1 occurs only after task 1 completes, it will be ignored.

Through BPMN version 1.2, with the exception of compensation events, attached intermediate events inevitably resulted in canceled activities. BPMN 2.0 defines a new symbol: the non-interrupting intermediate event. It sounds awkward, but it is useful:

Hover over orange symbols for explanation

The token moves through the process as follows:

• The token moves to task 1, which starts accordingly.
• If event 1 occurs while task 1 is being processed, the token is cloned. Task 1 continues to be processed while the second token moves to task 3, which is now also processed. This procedure may even take place repeatedly, that is, the event can occur many times. Each occurrence results in another cloned token.
• If event 1 does not occur, task 1 will be completed, and the token moves through the regular sequence flow to task 2.
• If event 1 occurs only after task 1 completes, it ceases to matter.

In the following sections, we introduce the event types to be used when working with BPMN. We also explain how you can react to different events using the event-based gateway.

Message

Sooner or later, most processes require communication, which can be represented in BPMN by means of the message event. You’ll recognize it as the small envelope. The meaning of “message” in BPMN is not restricted to letters, e-mails, or calls. Any action that refers to a specific addressee and represents or contains information for the addressee is a message.

Hover over orange symbols for explanation

FAQ: Could I replace the task “order pizza” with a throwing message event?

Yes, you could:

hunger
noticed

choose pizza

pizza
ordered

pizza
received

eat pizza

hunger
satisfied

Heads up! We are not always happy with the throwing intermediate event. Implying a “send message” task without modeling it explicitly can easily confuse inexperienced consumers of our models. We choose not to use throwing intermediate events for messages and instead use a task. There are also special BPMN task types for sending and receiving messages.

In the example below, we show a message leading to cancellation. In this scenario, we administer a web application. When a user notifies us that the website does not work, we immediately search for the error. But maybe the user is mistaken, and the website is fine. Maybe the user’s Internet connection is defective. If the user tells us about the false alarm, we cancel the search and swear at the user for wasting our time. If the error is actually found, however, we eliminate it and simultaneously figure out who caused the error. If the user caused the error, we can swear at the user for a different reason. If the user is not at fault, however, we thank him or her graciously for letting us know about the problem.

user reports:
“website
is down!”

search for bug

fix bug

users
fault?

insult user

user insulted

thank user

user thanked

user reports:
“sorry, false
alarm!”

yes

no

Timer

The timer event is often used when working with BPMN because it is so flexible to apply. A clock icon represents the timer event. The diagram below shows a few examples of applications:

holidays

2 months
prior to trip

choose
destination

book trip

pack bags

…

2 days
prior to trip

user support

every 2
hours

check email
inbox

view most
important topic

handle most
important topic

…

coffee break
10 minutes

working day

Monday-Friday
at 07 am

get up

do morning
toilette

take bus to work

…

08 am

Valentine 2010

02/14/2010
08 am

get up

buy bouquet

wake beloved
with bouquet

…

02/14/2010
09 am

Time moves on no matter what we or our processes do, so timer events can exist only as catching starts or intermediate events.

You can model countdown times with an attached timer event. They are used this way frequently. You can specify upper time limits – the maximum time allowed for a processing task – for instance:

Hover over orange symbols for explanation

Non-interrupting timer events became possible with BPMN 2.0:

Hover over orange symbols for explanation

Error

Do your processes run completely error-free? If not, you can identify potential errors in your models as a step toward eliminating them, or as part of modeling escalation processes. In BPMN, error events are represented by a flash symbol.

The BPMN specification does not specify what an error may be. As the modeler, you have to decide that.

An error is a serious event in BPMN, so if catching, it can be modeled only as an attached intermediate event. This means that an error during task execution must be handled in a specific way: As a throwing event, it can be modeled only at the end of a process path so that the participant knows the process has failed. The parent process should likewise recognize the failure.

You can find example of error events e.g. in the Implementation section for “Event Subprocesses”.

Conditional

Sometimes we only want a process to start or to continue if a certain condition is true. Anything can be a condition, and conditions are independent of processes, which is why the condition (like the timer event) can only exist as a catching event. A process cannot therefore conditional event trigger a conditional event.

We can enhance our pizza process with conditions. If we want to have frozen pizza, the process starts as shown in the diagram below. We take the pizza from the freezer and turn on the oven. But only after the temperature in the oven reaches 180 C do we put the pizza in, and only after it is done do we take it out to eat.

frozen pizza
desired

take pizza from
freezer

switch on oven

oven to 180°

put pizza in oven

pizza
ready

eat pizza

hunger
satisfied

Signal

Signals are similar to messages, which is why you can model them in BPMN as events just as you can with messages. The symbol for a signal is a triangle. The essential difference between a signal and a message is that that latter is always addressed to a specific recipient. (An e-mail contains the e-mail address of the recipient, a call starts with dialing the telephone number, and so on.) In contrast, a signal is more like a newspaper advertisement or a television commercial. It is relatively undirected. Anyone who receives the signal and wants to react may do so.

pizza spot
seen on TV

buy pizza

get an appetite
for pizza

eat pizza

evaluate pizza
on pizzatest.de

We saw a new frozen pizza on TV, and we are keen to try it. The diagram above illustrates this new situation. We buy the pizza, but we keep it in the freezer until we’re really hungry for pizza. That’s a conditional event. After trying the new pizza, we go to Pizzatest.de to rate the new product. That’s a signal. It is a signal for the general public too. (Pizzatest.de actually exists, by the way, which proves again that you can find simply everything on the Internet!)

Termination

Let’s look at the abstract example below. We already discussed (simple) Key Performance Indicator (KPI) analysis, and we therefore know that this process always takes 55 minutes. After task 1, tasks 2 and 3 can be processed simultaneously. Processing task 2 takes more time than does processing task 3, which is why it determines the runtime of the process. A token that runs through the process is cloned in the AND split. The first token stays in task 2 for 45 minutes; the second token stays in task 3 for 30 minutes. The second token arrives at the none event first, where it is consumed. After 15 more minutes, the first token arrives at the upper none event, where it is consumed too. Since no more tokens are available, the process instance finishes after 55 minutes.

start

task 1

task 2

end 1

task 3

end 2

30 minutes

45 minutes

10 minutes

So far, so good, but what happens if we already know that, after having completed task 3, task 2 has become redundant? This is a frequent situation with parallel task executions related to content. In such cases, we can apply the pattern shown in here:

Hover over orange symbols for explanation

Link

The link event is a special case. It has no significance related to content, but it facilitates the diagram-creation process. As shown below, you can draw two associated links as an alternative to a sequence flow. Here, “associated” means there is a throwing link event as the “exit point,” and a catching link event as the “entrance point,” and the two events are marked as a pair – in our example by the designation “A.”

…

task 1

A

A

task 2

…

…

task 1

task 2

…

=

Link events can be very useful if:

• You have to distribute a process diagram across several pages. Links orient the reader from one page to the next.
• You draw comprehensive process diagrams with many sequence flows. Links help avoid what otherwise might look like a “spaghetti” diagram.

Link events can be used as intermediate events only.

Compensation

We execute tasks in our processes that sometimes have to be canceled later under certain circumstances.

Typical examples are:

• Booking a train or airline ticket
• Reserving a rental car
• Charging a credit card
• Commissioning a service provider

Below, we see this process: On Friday at 1 p.m. we agree with our partner either to go to the theater or to spend the evening with friends. In both cases, we have to do something binding, either to reserve the theater tickets or make the arrangements with our friends. When evening arrives, perhaps we no longer feel like going out at all. We then have to cancel the arrangements we made with the theater or our friends before we can collapse in front of the TV in peace:

Friday 1 pm

arrange date

planned
activities?

book theatre
tickets

arrange date
with friends

Friday 6 pm

still wanting
to go?

carry out activity

what was
the plan?

cancel theatre
tickets

watch TV

cancel friends

theatre

friends

yes

no

theatre

friends

We can represent the latter part of the model more compactly with a compensation event, as shown in here:

Hover over orange symbols for explanation

There are special rules for handling compensations:

• Throwing compensations refer to their own processes, so the event is effective within the pool. This shows how this event type differs from a throwing message event.
• Other attached events can take effect only while the activities to which they are attached remain active. In contrast, an attached compensation takes effect only if the process triggers a compensation and the activity to which the compensation is attached successfully completed.
• Attached compensation events connect to compensation tasks through associations, and not through sequence flows, which would otherwise be common usage. BPMN thus emphasizes that compensations are beyond the regular process sequence; executing one is an exception.

Best Practice: Using Compensation Events

This example may be too simple to illustrate how much work this construct can save you. If you think of the complex business processes that frequently require compensations, however, you’ll see how much leaner your models can be. You’ll also be quick to spot the circumstances that demand compensations. We use compensation events only occasionally to describe complex processes.

Multiple

We can use the multiple event to summarize several events with a single symbol. The diagram below applies the multiple event to our pizza scenario. In the example, we try a new pizza after having seen it on TV or after a friend recommended it. After eating it, we will rate the pizza on Pizzatest.de and in turn inform our friend if we also recommend this pizza.

Hover over orange symbols for explanation

Best Practice: Avoiding Multiple Events

You have to decide if multiple events serve your purposes. We concede their benefit in rough functional process descriptions, but they cease to be as useful in the more advanced technical-implementation phase. You can’t afford to leave relevant details hiding in the descriptive text. We don’t find the multiple event to be intuitive, nor is it helpful on a functional level. It may make your diagrams larger to model all events separately, but the resulting diagrams will be both more comprehensive and more comprehensible. The bottom line is that we have never used this symbol in practice, nor have we seen anybody else doing so.The model in here describes the same process, but the events are fully modeled:

pizza commercial seen on TVfriend recommended pizza buy pizzacrave pizzaeat pizzaevaluate pizzaon pizzatest.desend evaluationto friend

Parallel

The parallel event was added in BPMN 2.0 to supplement the multiple event. While a catching multiple event has XOR semantics – it occurs as soon as one of its contained events occurs – the parallel event uses AND semantics. It doesn’t occur until all of its contained events occur. Because the throwing multiple event already implies AND semantics, the specification defines parallel events as catching events only.

Escalation

The BPMN 2.0 specification added the escalation event. Mainly, it shows communication between parent and sub-processes.

Cancel

You can use the cancel event only in the context of the transactions.