Проект RunaWFE Free. Разработка элемента «событийный подпроцесс» (Михаил Смирнов, OSSDEVCONF-2023)

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

Короткая ссылка: 20231001B

Докладчик

Михаил Смирнов

Для расширения возможностей реагирования на события в рамках процессного управления был разработан элемент «событийный подпроцесс» для свободного ПО RunaWFE Free. Элемент соответствует стандарту BPMN 2.0 и может быть использован для описания асинхронных задач.

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

Презентация

Thesis

События в процессном управлении

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

Для взаимодействия экземпляров бизнес-процесов между собой в системах управления бизнес-процессами используются события. При таком взаимодействии одни экземпляры генерируют события, а другие их обрабатывают. В RunaWFE Free межпроцессное взаимодействие реализовано на основе Java Message Service. До настоящей работы оно выполнялось при помощи элементов двух типов: «Генерация события» и «Обработка события». Элементы располагаются на схеме бизнес-процесса. При прохождении точки управления через элемент «Генерация события» элемент генерирует события. При приходе точки управления в узел «Обработка события» она остаётся в этом узле до наступления соответствующего события, а после его наступления — переходит дальше по схеме бизнес-процесса.

Однако существуют ситуации, в которых определённые события должны быть обработаны без привязки к элементу, находящемуся на схеме основной ветки бизнес-процесса. Для этого в стандарте BPMN 2.0 используется событийный подпроцесс, который не связан переходами с узлом — началом бизнес-процесса, и может быть активирован по сигналу в любой момент при условии, что экземпляр бизнес-процесса активен (не завершён). В данной работе для платформы RunaWFE Free был реализован такой элемент. Реализован только непрерывающий вариант событийного подпроцесса, не останавливающий ход основного процесса при наступлении стартового события для подпроцесса.

Реализация элемента «событийный подпроцесс» в редакторе бизнес-процессов RunaWFE Free

Рассмотрим пример «Подготовка конференции> (Рис.~1 и Рис.~2). В основном процессе выполняются задачи, необходимые для проведения конференции. Параллельно могут приходить заявки от слушателей и докладчиков. Заявки будут приниматься до тех пор, пока процесс не завершится, т.е. пока не наступит конец регистрации. Событийные подпроцессы, в отличие от всех остальных элементов, не имеют входящих или исходящих переходов. На схеме они обведены пунктирной рамкой. Граница начального узла в событийном подпроцессе также пунктирная.

За событийный подпроцесс отвечают две сущности: схема подпроцесса и элемент на схеме. Так как редактор основан на Eclipse, все элементы описываются в plugin.xml. Для каждого элемента определяются название, иконка и класс, который его представляет. Элемент событийного подпроцесса реализован как новый класс, потомок подпроцесса-композиции, который не содержит никаких новых полей и методов. Такой пустой класс удобен, так как архитектурно предполагается, что все элементы имеют разные классы. Типы элементов проверяются через «Java Reflection».

Начало событийного подпроцесса должно содержать обработку события или таймер. При сохранении процесса с начальным узлом без события редактор сообщает об ошибке (Рис.~3).

Реализация элемента «событийный подпроцесс» на сервере RunaWFE Free

Событийный подпроцесс принимает сообщения только когда активен родительский процесс (то есть в нём есть хотя бы одна активная точка управления). Были рассмотрены 2 варианта реализации:

• Событийный подпроцесс соединяется невидимым переходом с началом «родителя», что делает его обычным элементом на

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

• Создаётся таблица с триггерами. При старте процесса в таблицу добавляется триггер на каждый стартовый узел

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

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

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

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

Активный событийный подпроцесс выделяется пунктирной чёрной рамкой (Рис.~4), выполненный — зелёной рамкой (Рис.~5). На сервере рамки около элементов рисуются поверх изображения процесса из редактора. Для определения состояния элемента используется журнал переходов точки управления. В начале всем элементам процесса присвоено состояние «не активный». Журнал просматривается в хронологическом порядке, и каждая его запись меняет состояние инцидентных переходу элементов. Начало перехода меняет состояние на «выполненный», а конец на «активный». В результате получаем актуальные состояния всех элементов. В алгоритме используется журнал, так как различить состояния «неактивный» и «выполненный», зная только текущее состояние процесса, затруднительно.

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

Заключение

Для поддержки элемента стандарта BPMN 2.0 «событийный подпроцесс» в данной работе были реализованы изменения в клиентской и серверной частях платформы RunaWFE Free. Изменения загружены на портал github. Серверная часть доступна по ссылке [2]. Клиентская часть (редактор бизнес-процессов) — [3].