О нотации BPMN написано немало публикаций. В них разбираются различные объекты этой нотации и способы их взаимодействия. Поэтому в этой статье мы не будем говорить об основах BPMN, а вместо этого разберем различные случаи правильного и не очень построения диаграмм.
Для начала рассмотрим несколько вариантов реализации примера с зависимыми экземплярами.
Кредитная проверка
Рассмотрим простой пример. Допустим у нас имеется банковское приложение, в котором необходимо выполнить кредитную проверку клиента. К примеру, мы хотим убедиться, что у клиента, запрашивающего новый кредит нет непогашенных кредитных обязательств. При этом, нам нужно, чтобы при выполнении одной кредитной проверки клиента, у нас одновременно не выполнялась еще одна проверка того же клиента. Причина может заключаться в том, что общее количество выполненных кредитных проверок влияет на результат проверки.
Предположим, что мы выполняем проверку кредитоспособности клиента и в это же время получаем второй запрос на того же клиента. Логичным решением является проверка наличия совпадающих экземпляров на уровне данных перед началом фактической проверки кредитоспособности.
В первом примере мы воспользуемся сигнальным событием проверки наличия запущенных событий для одного клиента. Сигнальное событие — это самый простой и компактный способ моделирования взаимодействия между различными экземплярами.
Проблема сигнала в том, что он работает как широковещательный и не обращается к какому‑либо конкретному экземпляру. Поэтому, строго говоря, клиент игнорируется, а все ожидающие экземпляры его ловят. Поэтому данная диаграмма будет не совсем точно отображать необходимый нам процесс проверки кредитоспособности клиента.
Давайте немного усложним нашу диаграмму. У нас по прежнему будет присутствовать сигнальное событие, но нам необходимо будет также определить получателя (один экземпляр) сообщения. В результате, нам придется вызвать второй запрос данных перед завершением экземпляра. Однако это правильный способ решения проблемы, возникающей при использовании сигнального события.
Рассмотрим еще один вариант реализации, в котором нам не нужно никакого взаимодействия между экземплярами. Экземпляр сам периодически проверяет, может ли он перейти к проверке кредитоспособности. Недостатком данного варианта является то, что это может привести к задержкам и накладным расходам из‑за использования цикла.
Таким образом, мы можем реализовать процесс проверки кредитоспособности тремя различными способами, при этом каждый из них имеет свои достоинства и недостатки.
Создание счета
Допустим, мы хотим смоделировать процесс в BPMN, и этот процесс вызывает некоторые бизнес‑правила. Здесь, в качестве примера рассмотрим создание счета. Для того чтобы создать счет, необходимо рассчитать скидку. Сумма заказа и тип клиента являются соответствующими критериями для расчета скидки.
При моделировании мы будем фокусироваться на потоке процесса, и в данном примере процесс состоит из двух этапов: расчета скидки и создания счета. При этом, скидка рассчитывается до создания счета.
В результате получается очень простой процесс.
Моделировать сам расчет скидки в BPMN‑модели (то есть подробно расписывать содержимое элемента Rule Engine) не имеет смысла.
Для дерева решений правил при каждом дополнительном критерии будет существенно увеличиваться сложность. При этом, расчет скидки не относится к функциональности приложения. Это бизнес правило и его не нужно отображать в BPMN‑модели.
Поэтому представленная ниже схема является неверной с точки зрения BPMN, так как содержит ненужную информацию по работе бизнес правил.
Поэтому имеет смысл разделить процессные и бизнес‑правила и отображать на диаграмме только то, что связано с работой процессов.
Неправильная структура
Рассмотри еще одну распространенную проблему, связанную со структурированием диаграмм BPMN. Допустим, есть адвокат, который предлагает юридические консультации своим клиентам. Услуга работает следующим образом: клиенты могут обратиться за юридической помощью, когда им это необходимо. Юрист предоставляет требуемую консультацию и заносит оплачиваемые часы в табель учета рабочего времени клиента. По окончании месяца бухгалтер юриста определяет количество оплачиваемых часов на основании табеля учета рабочего времени и выставляет счет‑фактуру.
Это достаточно распространенный сценарий моделирования и здесь сложность представляют не этапы процессов, а структура диаграммы.
Процесс «Предоставление юридических консультаций (provide legal advice)» выполняется много раз в месяц. Процесс Monthly Invoicing выполняется только один раз в месяц. Поэтому эти два процесса должны быть смоделированы как отдельные пулы.
Конечно, эти два пула не являются полностью независимыми друг от друга. Они работают с одними и теми же данными — табелем учета рабочего времени клиента (Customer Time Sheet). Наши возможности по моделированию такой связи между данными в BPMN очень ограничены. Это связано с тем, что BPMN ориентирован на поток управления, а не на поток данных.
Однако мы можем использовать элемент хранилища данных, чтобы смоделировать эту связь на уровне данных, что и продемонстрировано на диаграмме.
Рассмотри неправильный вариант реализации данного процесса. В этом примере оба процесса смешаны в один. Как видите здесь всего один пул в который помещены все процессы.
В лучшем случае это очень неявный способ моделирования. Это означает, что за каждую предоставленную юридическую консультацию по окончании месяца высылается счет‑фактура. В большинстве случаев такой способ моделирования неверен, так как у нас предполагается выставление единого счета фактуры за все консультации в конце месяца, а не отдельные счета за каждую консультацию.
Один к N
Посмотрим еще один пример сценария моделирования. Единственный экземпляр процесса (например Импорт заказов) приводит к появлению множества отдельных экземпляров другого процесса (например ERP‑системы). Типичными конструкциями являются мультиэкземпляры или циклы, запускающие другие процессы с помощью сообщений (потоки сообщений). Например, вот такие:
Использование подобной конструкции имеет смысл, если Process Engine использует службу determine assignee для назначения новой задачи.
Другой вариант реализации подобной задачи предполагает, что мы используем механизм правил на шаге determine assignee также для назначения новой задачи.
И третий вариант, при котором наш Process Engine сам определяет нового получателя, например, с помощью заданного выражения.
Как видно, в таком случае диаграмма существенно упрощается.
Заключение
Мы рассмотрели несколько простых процессов и их представления в виде диаграмм BPMN. При этом некоторые из представленных вариантов были не совсем корректными или попросту ошибочными. Таким образом мы наглядно продемонстрировали ситуации, когда диаграмма содержит избыточную информацию, как в случае с подсчетом скидки, а когда она будет полностью неправильной, как в случае с выставлением счетов в конце месяца.
На основании представленных примеров можно сделать выводы о том, как можно правильно использовать компоненты BPMN для построения диаграмм, корректно отображающих процессы.
Если вам нужно быстро освоить BPMN или углубить понимание принципов моделирования, рекомендую посетить два практических урока в Otus. Разберете ключевые моменты и подходы, которые пригодятся при проектировании бизнес-процессов:
14 апреля. Соглашение о моделировании в BPMN
22 апреля. Быстрый старт в моделировании BPMN