Паттерны проектирования

Реакция на определенные события

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

Шлюз 'или', эксклюзивный шлюз (условие если-то)

Шлюз "или" выбирает поток последовательности на основе данных (условий), которому передается управление (opens in a new tab).

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

Во время исполнения экземпляр процесса проверяет условия на шлюзе. Если у шлюза ни одно условие не выполняется и отсутствует поток (ветка) по умолчанию, то создастся инцидент.

Демонстрация работы шлюза "или"/эксклюзивного (opens in a new tab).

Пример логических выражений, которые могут быть использованы на потоках шлюза:

= totalPrice > 100
= order.customer = "Paul"            
= orderCount > 15 or totalPrice > 50            
= valid and orderCount > 0

Работа с логическими выражениями дополнительно описана в документации Camunda (opens in a new tab).

Шлюз 'и', параллельный шлюз

Шлюз "и" позволяет разделить поток на параллельные пути без учета условий на ветках. Параллельный шлюз (opens in a new tab) генерирует новые токены, параллельно активируя несколько поток последовательности (opens in a new tab).

Исходящие потоки (ветки) параллельного шлюза должны быть объединены. Экземпляр процесса будет ожидать на параллельном шлюзе до тех пор пока не выполнятся все оставшиеся потоки (ветки). После чего все токены из параллельных веток преобразуются в один.

Демонстрация работы шлюза "и"/параллельного (opens in a new tab).

Шлюз 'или', инклюзивный шлюз

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

Исходящие потоки (ветки) инклюзивного шлюза должны быть объединены. Экземпляр процесса будет ожидать на инклюзивном шлюзе до тех пор пока не выполнятся все оставшиеся потоки (ветки). После чего все токены преобразуются в один.

В примере выше после запуска процесса будут созданы две задачи, если переменные процесса paymentReceived == falseиshipOrder == true. Если ни одно из условий не выполнится, то будет сгенерирована ошибка - этого можно избежать, пометив один из потоков (веток) "по умолчанию".

Шлюз на основе событий

Шлюз на основе событий позволяет принимать решения на основе событий.

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

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

Правила хорошего тона при моделировании процесса

1. Избегайте пересечения потоков операций на диаграммах

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

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

   Хороший пример

   

   

   Плохой пример

   

   

2. Наименование элементов в BPMN

   Каждый элемент BPMN имеет свое обозначение и наименование. Событие необходимо именовать по формуле «существительное + глагол в прошедшем времени». Например, «сделка состоялась». Процесс (пул) должен содержать имя процесса или субъекта, который его выполняет. Например, «Корпоративный портал» или «Инициатор договора» или «Управление доставкой». Задачи желательно именовать по формуле «отглагольное существительное + наименование объекта, над которым совершается действие». Например, «Подготовка отчета» или «Отгрузка товара» или «Подписание договора». Эксклюзивные шлюзы нужно обозначать вопросами, а потоки операций от них – ответами (условиями).

   Формулы наименований элементов

   

   

   Хороший пример

   

   

   Плохой пример

   

   

3. Симметричное моделирование

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

   Хороший пример

   

   

   Плохой пример

   

   

   Хороший пример

   

   

   Плохой пример

   

   

Использование цикла / повторение одно и того же действия

Цикл позволяет выполнять задачу до тех пор, пока не условие выхода не сработает.

Рассмотрим пример заказа

1. При получении заказа проверяем его наличие на складе.
2. Если товары доступны, то собираем оплату за заказ.
3. случае возникновения ошибки при оплате, через эксклюзивный шлюз 'или' можно сэмитировать повтор оплаты.

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

Данный маркер реализует цикл вида: do-while - выполнение действия пока условие не станет истино. Таким образом шаг с оплатой заказа будет повторяться в случае неудачи.

Действия над несколькими экземплярами (multi-instance)

Шаг процесса повторяется несколько раз - по одному раз для каждого элемента коллекции (на примере цикла foreach).

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

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

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

Определение коллекции для итерации

В поле Collection/Коллекция необходимо указать коллекцию элементров дли итерации.Для предоставления доступа к элементу необходимо в поле Element variable/Переменная элемента указать имя. При необходимости можно указать условие, по которому прервется итерация по коллекции - поле Completion Condition/Условие завершения. Или указать число итерацийLoop Cardinality/Мощность цикла, если нет необходимости пробегаться по всей коллекции.

Работа с коллекцией может быть достаточно ресурсоемкой. В таком случае необходимо поставить признак асинхронности Multi Instance Asynchronous Before='true'.

Скачать пример диаграммы

Подпроцессы

Граничные события

К подпроцессам можно присоединять граничные события BPMN. Это позволяет смоделировать альтернативные варианты исполнения действий родительского процесса в зависимости от состояния дочернего подпроцесса.

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

В BPMN 2.0 вместо события-ошибки предпочтительней использовать событие-эскалацию. Выше приведен пример использования граничного непрерывающего события-эскалации. Граничные непрерывающие события обозначаются кругом из двойной штриховой линии. Они запускают дополнительную ветвь родительского процесса, без прерывания подпроцесса. В примере подпроцесс «Закупка товара» передает информацию о задержке доставки товара в родительский процесс «Обработка заказа». При этом подпроцесс «Закупка товара» продолжает выполнение, а в родительском процессе активируется дополнительная ветвь «Поздняя доставка товара»

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

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

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

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

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

На диаграмме ниже приведен простой пример использования событийных подпроцессов:

Подпроцесс транзакция

Транзакция BPMN – это подпроцесс, для которого может быть задано несколько вариантов выхода:

1. Успешное завершение – изображается в виде потока операций, выходящего из транзакции.
2. Отмена – изображается с помощью граничного события «Отмена». Это событие может быть использовано только c подпроцессом «Транзакция» BPMN. При возникновении события «Отмена» произойдет компенсация («откат назад») определенных действий транзакции, либо возврат к началу процесса.
3. Ошибка. Появление ошибки означает, что действия Транзакции BPMN выполняются неверно и становятся невозможными успешное завершение и отмена Транзакции. Выполнение Транзакции при этом завершается без компенсации, а поток операций родительского процесса продолжается от граничного события «Ошибка».

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

Стратегии обработки ошибок

Каждый процесс имеет успешный сценарий выполнения, но иногда приходится сталкиваться с отклонениями от успешного исполнения. Важно понимать, что согласно спецификации BPMN исключение либо обрабатывается для продолжения процесса, либо завершает экземпляр процесса. Избежать таких ситуации помогают события-ошибки, которые позволяют "отловить" и обработать исключительные ситуации.

Обработка исключительных ситуаций в виде конечных событий

Обработка исключительных ситуаций по ходу исполнения процесса

Обработка ошибки как повторное выполнение действия

Обработка ошибки в подпроцессе

Шаблон Saga или компенсация

Шаблон Saga - когда нет возможности откатить исполненную задачу - следует отменить. Для этого в нотации BPMN предусмотрен механизм компенсации - связывать задачи с задачами отмены.

1. Клиент добавляется в CRM систему.
2. Происходит ошибка, что приводит к откату транзакции и процесс запускает компенсацию.
3. При откате транзакции будут выполнены все компенсирующие действия, в результате которых клиент будет деактивирован.

Обработка нескольких заказов

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

Скачать пример диаграммы

Двухэтапная эскалация

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

Решение 1

Скачать пример диаграммы

Решение 2

Скачать пример диаграммы

Решение 3

Скачать пример диаграммы

DMN