Реализация алгоритма определения возможных быстрых бесконечных циклов в бизнес-процессах и другие изменения, вошедшие в версию 4.6.0 платформы RunaWFE Free (OSSDEVCONF-2025)

Ссылки сюда (1) →

Короткая ссылка: 20251003F

Докладчик

Андрей Михеев

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

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

Презентация

Аннотация

Ключевые слова: BPMN, BPMS, opensource, схема бизнес-процесса, граф состояний бизнес-процесса.

Задача определения возможных быстрых бесконечных циклов в исполняющихся экземплярах бизнес-процессов

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

Проект RunaWFE Free [1] развивает свободную систему управления бизнес-процессами для автоматизации деятельности предприятия путём её представления в виде исполняемых экземпляров бизнес-процессов. Бизнес-процесс содержит ориентированный граф из узлов, соединённых переходами. Перемещение токена (точки управления) по этому графу приводит к генерации заданий для пользователей или информационных систем в одних узлах и к выбору маршрутов дальнейшего движения токенов — в других. Графы бизнес-процессов должны разрабатываться таким образом, чтобы задания выполнялись согласованно и в правильной последовательности.

Ошибки проектирования бизнес-процессов могут привести к тому, что в их графах будут содержаться участки, на которых во время эксплуатации возникнут циклические перемещения токенов только по узлам, в которых производится выбор дальнейшего маршрута и не генерируется никаких заданий. В случае большого количества экземпляров таких процессов нагрузка на систему окажется значительной, что может помешать её нормальной работе. Пример графа такого бизнес-процесса приведён на рис. 1. На этом рисунке пронумерованы все переходы между узлами. Узлы с надписью «Действие» соответствуют узлам, в которых генерируются задания пользователям. Такие задания выполняются относительно медленно. Правила выбора следующего перехода в исключающих шлюзах (элементах в виде ромбиков) могут оказаться так настроены, что токены будут бесконечно переходить по переходам 3, 5 и 4.

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

Для исследования бизнес-процесса воспользуемся математической конструкцией «граф состояний» [2]. В этой конструкции состояние экземпляра бизнес-процесса определяется положением токенов на переходах графа бизнес-процесса. В данной работе будем обозначать состояние экземпляра номером перехода, на котором находится точка управления. В случае экземпляров с несколькими точками управления данный подход можно обобщить следующим образом: состояние будем обозначать упорядоченным по неубыванию перечислением через запятую номеров переходов, в которых находятся токены. То есть, если на каком-то переходе находятся два токена, то этот переход будет присутствовать дважды.

В графе состояний бизнес-процесса, приведённого на рис. 1, первым элементом графа будет положение точки управления на переходе, исходящем из узла «Начало», то есть (1). Из этого положения точка управления может переместиться на переход 2 или 3 в зависимости от бизнес-правила в узле-исключающем шлюзе. Таким образом, из узла (1) в графе состояний будут переходы в узлы (2) и (3). На следующем шаге из узла (2) можно будет перейти только в узел (8), а из узла (3) — в узел (5) или (7). На рис. 2 приведён граф состояний бизнес-процесса после двух шагов построения.

Из состояния (8) можно перейти только в конечное состояние, в котором на графе отсутствуют токены, обозначаемое как (). Из состояния (7) можно перейти в состояние (10), а из него — только в конечное состояние. Из состояния (5) можно перейти в состояние (4) или (6). Из состояния (4) можно опять перейти в состояние (2) или (3). А из состояния (6) — только в состояние (9), из которого — в конечное состояние. Обозначим в графе состояний рёбра, соответствующие выполнению заданий, буквой «М», так как задания выполняются медленно и переход по этим рёбрам будет происходить медленно. По остальным рёбрам, не обозначенным буквой «М», переход осуществляется быстро. На рис. 3 приведён полностью построенный граф состояний рассматриваемого бизнес-процесса.

Видно, что в графе есть единственный цикл из элементов (3), (5), (4), все рёбра в котором соответствуют «быстрым» элементам. Эти рёбра выделены жирным цветом. Математически доказывается, что если в экземпляре не может быть ситуации бесконечно возрастающего количества точек управления и граф состояний бизнес-процесса не содержит циклов, состоящих только из «быстрых» рёбер, то при выполнении экземпляров этого бизнес-процесса не могут возникать бесконечные циклы, состоящие только из «быстрых» элементов. Алгоритм проверки ограниченности точек управления был построен в работе [2].

Задача определения на этапе проектирования возможности возникновения быстрых циклов была исследована математически, и на основе этого исследования в версии 4.6.0 свободного ПО RunaWFE Free был реализован соответствующий алгоритм. В редакторе бизнес-процессов (среде разработки) появилась команда «Проверить мгновенные циклы» (рис. 4).

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

Другие изменения в версии 4.6.0

Добавлен элемент «Событийный подпроцесс». В палитре появился элемент «Событийный подпроцесс». Этот подпроцесс не связан переходами с графом основного бизнес-процесса (рис. 6). Активируется он по стартовому событию — сигналу — только если в момент появления сигнала в основном процессе есть хотя бы одна точка управления (рис. 7).

Добавлена возможность создания, удаления и передвижения точек управления экземпляра бизнес-процесса через интерфейс. На странице экземпляра бизнес-процесса появилась кнопка «Управление токенами» (рис. 8).

При её выборе открывается форма, в которой администратор системы может добавить, удалить или переместить точку управления (рис. 9).

Ещё изменения в версии 4.6.0:

• добавлен пункт меню «Зависшие процессы» для поиска проблем в экземплярах бизнес-процессов;
• добавлена поддержка электронно-цифровой подписи для подписи PDF-файла;
• в свойствах пользователя добавлены оповещения о задачах и сообщениях чата;
• добавлена возможность архивирования экземпляров бизнес-процессов;
• добавлен графический элемент формы для выбора значения из таблицы слоя бизнес-объектов;
• добавлено логирование отмены заданий в истории экземпляра бизнес-процесса;
• в версиях определений бизнес-процессов добавлена возможность аудита изменений по файлам;
• сделаны расширенные всплывающие подсказки в дизайнере бизнес-процессов;
• взаимодействие дизайнера с сервером переведено с WebServices API на REST API;
• конструктор исключающего шлюза переведён на groovy AST.

Литература

• Ссылки на проект RunaWFE Free: http://runawfe.org, https://github.com/processtech/, https://sourceforge.net/projects/runawfe/
• Миронов А. М., Михеев А. Г., Пятецкий В. Е. Алгоритм проверки ограниченности количества точек управления в экземпляре бизнес-процесса // Проблемы управления, № 1, 2015, с. 30–37. http://www.mathnet.ru/php/getFT.phtml?jrnid=pu&paperid=896&what=fullt&option_lang=rus