О нотации BPMN написано множество материалов. В них детально разбираются элементы нотации и принципы их взаимодействия. В этой статье мы не будем повторять основы BPMN, а сосредоточимся на примерах корректного и некорректного построения диаграмм.
Сначала проанализируем несколько вариантов реализации сценария с зависимыми экземплярами.
Кредитная проверка
Разберём простой кейс. Предположим, у нас есть банковское приложение, где требуется проводить кредитную проверку клиента. Например, нам нужно удостовериться, что у клиента, запрашивающего новый кредит, нет текущих непогашенных обязательств. При этом важно, чтобы при выполнении одной проверки клиента, параллельно не запускалась вторая проверка того же клиента. Это может быть критично, так как общее количество проверок влияет на финальный результат.
Допустим, мы проводим проверку кредитоспособности клиента и в этот момент поступает второй запрос на того же клиента. Рациональным решением будет проверка существующих запущенных экземпляров на уровне данных перед началом фактической проверки.
В первом примере мы используем сигнальное событие для проверки активных экземпляров по одному клиенту. Сигнальное событие представляет собой наиболее простой и лаконичный способ моделирования взаимодействия между разными экземплярами.
Основная проблема сигнала заключается в его широковещательной природе — он не адресован конкретному экземпляру. Фактически, сигнал игнорирует конкретного клиента, а все активные экземпляры одновременно получают это сообщение. В результате, такая диаграмма не совсем точно отражает требуемую логику проверки кредитоспособности.
Усложним нашу диаграмму. Мы сохраним сигнальное событие, но добавим механизм определения конкретного получателя (единственного экземпляра) для сообщения. Это потребует выполнения дополнительного запроса данных перед завершением экземпляра. Однако именно такой подход корректно решает проблему, возникающую при использовании сигнальных событий.
Проанализируем альтернативный подход, исключающий необходимость взаимодействия между экземплярами. В данном случае экземпляр самостоятельно выполняет периодическую проверку возможности перехода к кредитной проверке. Однако такой метод имеет существенный недостаток — возможные задержки выполнения и дополнительные ресурсные затраты, обусловленные циклической природой проверки.
Мы рассмотрели три различных подхода к реализации процесса проверки кредитоспособности, каждый из которых обладает определенными преимуществами и ограничениями.
Создание счета
Предположим, нам требуется смоделировать в BPMN процесс, включающий выполнение бизнес-правил. В качестве примера возьмем процедуру создания счета. Для формирования счета необходимо предварительно рассчитать размер скидки, где основными параметрами расчета выступают сумма заказа и категория клиента.
При моделировании мы сосредоточимся на последовательности операций. В данном случае процесс включает два последовательных этапа: вычисление скидки и непосредственно создание счета, причем расчет скидки всегда предшествует формированию счета.
В итоге мы получаем предельно простую и понятную схему процесса.
Детализированное моделирование алгоритма расчета скидки в BPMN (с подробным описанием работы Rule Engine) нецелесообразно.
Каждый дополнительный критерий для системы правил экспоненциально увеличивает сложность модели. При этом сам механизм расчета скидки не является частью workflow приложения — это исключительно бизнес-логика, которую не следует включать в BPMN-диаграмму.
Следовательно, приведенная схема некорректна с позиций BPMN, поскольку излишне детализирует реализацию бизнес-правил.
Оптимальным решением является раздельное представление процессной логики и бизнес-правил, отображая на диаграмме исключительно workflow-компоненты.
Проблемы структурирования
Проанализируем типичную ошибку в организации BPMN-диаграмм. Рассмотрим пример юридической практики: адвокат оказывает консультационные услуги клиентам. Процесс выглядит следующим образом:
- Клиент обращается за юридической помощью по требованию
- Юрист проводит консультацию и фиксирует отработанные часы
- В конце месяца бухгалтер анализирует учет рабочего времени и формирует счет
В данном случае сложность моделирования заключается не в этапах процесса, а в способе их визуального представления на диаграмме.
Процесс «Предоставление юридических консультаций» (Provide Legal Advice) выполняется многократно в течение месяца, тогда как процесс «Ежемесячное выставление счетов» (Monthly Invoicing) запускается лишь раз в месяц. Следовательно, эти процессы должны быть представлены как отдельные пулы в модели.
Хотя пулы взаимосвязаны — они используют общие данные (табель учета рабочего времени клиента). Однако BPMN предоставляет ограниченные возможности для отображения таких зависимостей, поскольку стандарт ориентирован прежде всего на управление потоками работ, а не данными.
Для визуализации этой связи мы можем использовать элемент Data Store, что и показано на диаграмме.
Некорректная реализация
Теперь рассмотрим ошибочный вариант моделирования, где оба процесса объединены в единый пул. В таком случае вся логика оказывается смешанной в рамках одного контейнера.
Подобное моделирование крайне неочевидно и может вводить в заблуждение. Фактически, оно подразумевает отправку отдельного счета за каждую консультацию по окончании месяца. Однако в большинстве случаев это некорректно, так как предполагается формирование единого счета, включающего все консультации за месяц.
Отношение «один ко многим»
Рассмотрим другой пример моделирования. Единичный экземпляр процесса (например, «Импорт заказов») может инициировать множество экземпляров другого процесса (например, в ERP-системе). Для реализации подобных сценариев обычно используют:
- Мультиэкземпляры
- Циклические конструкции
- Запуск процессов через механизм сообщений
Примеры таких конструкций:
Оптимальное применение данной конструкции оправдано, когда Process Engine задействует сервис determine assignee для распределения новых задач.
Альтернативный подход к реализации аналогичной функциональности заключается в использовании системы правил на этапе determine assignee, которая также отвечает за назначение последующих задач.
Применение данной конструкции оправдано в случаях, когда Process Engine задействует службу determine assignee для распределения новых задач.
Альтернативная реализация подразумевает использование системы бизнес-правил на этапе determine assignee, которая также выполняет назначение последующих задач.
Третий возможный подход предполагает, что Process Engine самостоятельно определяет получателя задачи, используя, например, предопределенное выражение для назначения.
В статье были разобраны примеры простых процессов и их визуализации в BPMN. Часть рассмотренных вариантов оказалась некорректной или содержащей ошибки. Это наглядно показало случаи:
- избыточного отображения деталей (как в примере с расчетом скидки)
- принципиально неверного моделирования (как в сценарии с ежемесячным выставлением счетов)
Представленные примеры помогают понять принципы грамотного использования BPMN-компонентов для создания точных и информативных диаграмм процессов.