Как мы выбирали процессный движок: месяц мучений ради идеала26.05.2023 15:01

Последние несколько лет IBS развивает собственную low-code-платформу «Планета» для самых разных бизнес-задач в рамках цифровизации управления деятельностью компании. В ходе разработки нам понадобилось встроить в ядро системы BPM-решение (Business Process Management — управление бизнес-процессами). Чтобы не изобретать велосипед, было решено задействовать готовое open-source-решение и дальше «плясать» уже от него. Эта статья — о трудностях выбора и сравнении разных инструментов автоматизации бизнес-процессов по определенным требованиям.

Хабр, привет! Меня зовут Артем Терзьян, я Java-разработчик в IBS. Именно на мои плечи пала нелегкая задача выбора идеального BPMN-движка для реализации с его помощью бизнес-процессов в рамках нашей собственной платформы. Надеюсь, приведенный обзор поможет кому-то сэкономить время при столкновении с аналогичной задачей.

Лонг-лист

BPM-решения можно разделить на две большие группы: процессные движки (BPMN) и полноценные системы (BPMS).

Я сразу отказался от идеи использовать полноценную BPMS по причине неудобства ее встраивания, потери контроля над изменениями и сложности кастомизации. Так как пользовательская часть системы реализуется в рамках самой «Планеты», а часть администрирования со временем должна настраиваться под заказчика, я смотрел именно в сторону движков, которые можно будет самостоятельно использовать, встраивать и по необходимости модифицировать. Дальше речь пойдет только о них.

Шорт-лист

Критерии, по которым я сформировал шорт-лист BPMN-движков:

• Тип лицензии: Apache 2.0, BSD, MIT, неформальная, etc.

• Активная работа команды продукта: частые коммиты, релизы, мерджи и багфиксы (чтобы продукт не оказался вдруг заброшен).

• Расширяемость своими силами: наличие API для самостоятельной разработки.

• Наличие бесплатной версии (чтобы не переустанавливать винду после окончания пробного периода).

• Связь с Java — куда же без нее.

Таким образом сложился мой топ-4:

• jBPM,

• Activiti,

• Flowable,

• Camunda.

Итак, кандидаты подобраны, лидеры определены. Но это лишь часть пути. Чтобы прочувствовать дальнейшее взаимодействие с движками, нужно реализовать с их помощью реальный бизнес-процесс.

Создаем схему процесса

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

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

Схема процесса (диаграмма в нотации BPMN 2.0) была создана с помощью редактора BPMN.io (кстати, отличный ресурс, всем советую):

Кружки — это события, ромбы — развилки (aka шлюзы), прямоугольники — действия. Ромб с пентагоном в круге — это развилка, ожидающая события, — специальная конструкция в нотации BPMN с ограниченным количеством возможных продолжений. Ромб с Х — это разделяющая развилка, отправляющая процесс по одному из предоставленных путей. Прямоугольник с шестеренками — некий скрытый процесс, логика которого реализуется в рамках кода

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

1. jBPM

jBPM — BPMN-движок от компании JBoss (принадлежит Red Hat). Поддерживает нотацию BPMN 2.0, а также способен работать с DMN (decision model and notation — управление решениями) и CMMN (case management model and notation — управление делами).

Масштабируемость jBPM — через кластер: отдельные независимые экземпляры; распределение задач за счет единой базы данных; использование кэшей, в том числе распределенных.

Из преимуществ: Drag&Drop-плагин для Eclipse; поддержка взаимозаменяемости и транзакции на основе JPA / JTA; интеграции с EJB / OSGi / Spring; дополнительный репозиторий для развертывания конкретных процессов и связанных с ним знаний; админка с пользовательским интерфейсом для управления экземплярами процесса, списками и формой задач, а также для создания отчетности.

Для работы необходимо установить Eclipse и расширение для jBPM. Нюанс в том, что в примерах используется старая версия расширения, а на сайте доступна уже новая. Ладно, все равно пробуем…

Для создания проекта нужно пройти стандартный путь с New Project, выбрав jBPM. И в этот момент начинаются сложности. Необходимо задать runtime, которого у нас нет. Указанная ссылка для скачивания специального jar ведет в пустоту. В интернете также не нашлось внятной информации по тому, где взять этот самый runtime для jBPM.

Альтернативой работы через специальный runtime является Maven. Но при создании проекта через систему сборки появляются ошибки работы с библиотеками jBPM. Чтобы это как-то решить, я попробовал разные версии плагина — даже ту, что была в примере. Увы, с Eclipse ни одна из них так и не срослась.

Но есть и другой путь. Разработчики предоставляют собранный дистрибутив, в котором лежит сервер, документация, модули и много чего полезного. Запустить сервер можно через скрипт, который поднимет WildFly и задеплоит туда приложения по созданию, настройке и запуску процессов. Это и даст возможность все-таки создать диаграмму и посмотреть, как все работает. Запустить jBPM на 17 версии Java у меня не получилось, так что пришлось перенастроиться на 1.8.

Принцип автоматизации процесса, который даст возможность взаимодействовать с процессом в рамках запущенного сервера приложений:

=> создание схемы процесса

=> настройка блоков и определение модели необходимых данных

=> реализация библиотеки со стандартным сборщиком (Maven), куда нужно добавить API от jBPM

=> загрузка библиотеки на сервер и добавление в проект как зависимости

=> донастройка проекта с добавлением объектов из загруженной библиотеки

=> деплой и старт процесса из веб-интерфейса.

Инструментарий элементов в jBPM широкий и интуитивно понятный. Специализированные задачи вынесены в отдельный блок со множеством вариантов обработчиков (REST, Mail, Log, WebService и другие). Туда же можно добавить и свои обработчики, предварительно загрузив их на сервер и добавив в проект. Таким образом можно переносить из проекта в проект удачные решения, дополняя и расширяя свою библиотеку.

Помимо обработчиков, логика может содержаться и в самой диаграмме. Можно написать код, который будет выполняться до и/или после перехода на очередной этап. При этом поддерживается Java-синтаксис (хоть и без форматирования и подсветки кода). Сразу уточню, что данная возможность присутствует у всех решений, которые мы рассмотрим.

В самом интерфейсе есть много опций: сохранение, загрузка, валидация, проигрывание (прогон) схемы. Также к особенностям можно отнести встроенный функционал версионирования: прямо в редакторе можно начать новую ветку, вести изменения в ней, а затем объединить ее с основной веткой.

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

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

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

Во второй директории лежат модели, которые будут использоваться в процессе. Я поместил в нее и свои обработчики процессов — мне показалось, что так будет удобнее взаимодействовать с моделями и вести бизнес-логику для диаграмм.

Последняя директория — это SpringBoot-приложение. Благодаря дополнительным конфигурациям приложение знает про нашу схему из первой директории. Также мы добавляем в зависимости проект из второй директории. Дальше наступает чисто техническая часть по созданию REST API для запуска своего процесса.

2. Activiti

Activiti — продукт Alfresco Software для автоматизации работы с BPMN, который включает в себя ряд взаимосвязанных приложений:

• Modeler — графический веб-интерфейс для создания рабочих процессов,

• Designer — подключаемый модуль Eclipse для разработки рабочих процессов,

• Engine — основной процессор,

• Explorer — веб-инструмент для развертывания определений процессов, запуска новых экземпляров процессов и выполнения работы над рабочими процессами,

• Cycle — веб-приложение для совместной работы бизнес-пользователей и разработчиков программного обеспечения.

Масштабируемость Activiti — под вопросом: маркетинговый сайт продукта говорит про возможности кластера, облака и K8s, но при этом деталей в технической реализации этого использования нигде нет. Получается, все это может быть реализовано, потому что это Java, а остальное будет лежать на плечах пользователя.

Когда Alfresco Software захотели свой BPMN-движок, они не придумали ничего лучше, чем переманить к себе двух ведущих разработчиков jBPM из Red Hat. Конечно, код никто не копировал, но опыт, полученный в работе над jBPM, очевидно, был переосмыслен в новом продукте — Activiti.

Видимо, по наследству разработка BPMN-диаграмм в Activiti также может быть реализована через плагин для Eclipse. В данном случае мне повезло больше, плагин установился и запустился нормально. Возможно, плагин jBPM отрабатывает аналогично, но я опишу специфику формирования диаграммы таким способом именно на примере Activiti.

Справа мы видим стандартный для BPMN набор элементов диаграммы. При этом есть вкладка с именными элементами от вендора. А вот информацию о возможности добавить кастомные задачи, как это было в jBPM, я нигде не нашел.

Диаграмма формируется путем выбора первого элемента — стартового события. От него появляется меню с возможностью изменить текущий объект и выбрать следующий. При выборе следующего события система строит последовательность вызовов элементов. Что не получилось, это ставить блоки набора элементов и соединять их между собой: стрелка постоянно сбрасывалась. По этой причине пришлось пару раз пересобирать схему.

Настраивается диаграмма в нижнем окне. Во вкладках можно указать общую информацию, настроить связь с классом или методом и добавить слушателей. В качестве реализации задач можно выбрать как класс, так и метод. Это становится возможным при использовании Spring и аннотации @Bean — достаточно просто вписать название метода. Для того чтобы использовать класс, нужно реализовать интерфейс JavaDelegate. Таким образом мы получаем готовую диаграмму.

Из того, что не получилось сделать в рамках плагина: сообщение для MessageEvent«а требовалось не только проставить в самом элементе, но и зарегистрировать в диаграмме. У меня этого плагин делать не стал, но, покопавшись в примерах, я нашел подходящий вариант и прописал напрямую в xml.

Для реализации приложения у Activiti есть spring-starter. Он предоставляет все необходимые библиотеки для запуска embedded-ядра BPMN. Создаем контроллеры и делегаты, настраиваем security — и можно работать. Диаграмма кладется в директорию resources/process и автоматически подгружается в приложение при запуске. Тогда же происходит и валидация процесса. Когда встречались ошибки, приходилось останавливать запуск и править схему. После исправления всех недочетов остальное, как обычно, дело техники: нужно вызвать API с передачей требуемого объекта и наблюдать за логами.

Стоит отметить, что у Activiti есть свой сервер, собираемый при помощи docker-compose. В нем есть различные инструменты, в том числе и приложение для создания диаграмм, наподобие того, что предоставляет jBPM. Но на данном этапе я не планировал заводить сущностей сверх необходимого.

3. Flowable

Flowable — открытый проект для сообщества. Движок интегрируется со Spring, обладает богатым API Java и REST. Масштабируемость: кластер, много инстансов движка, общая база данных, балансировка нагрузки между нодами.

Ирония появления Flowable заключается в повторении истории Activiti. В 2016 году несколько ведущих разработчиков покинули компанию Alfresco Software и стали разрабатывать свой open-source-проект на базе Activiti. Первая версия имела номер 5.22 и являлась форком Activiti 5.21, а первый полноценный релиз Flowable 6.0 был форком Activiti 6.

С учетом такого родства базовые возможности Flowable и Activiti идентичны: поддержка BPMN / CMMN / DMN, генерация пользовательского интерфейса и дизайнер для создания диаграмм, представленный в виде плагина и веб-приложения.

Из приятных отличий: плагин оказался для IntelliJ IDEA. Интерфейс взаимодействия немного другой. Вместо списка всех элементов у нас есть контекстное меню. Среди стандартных задач есть и специфические, характерные только для Flowable.

Проблем с формированием блоков на диаграмме у меня не было. Все элементы без проблем добавлялись из контекстного меню и так же легко связывались друг с другом. Конфигурирование происходит через экран настроек, где все пункты представлены в одном большом списке. Так же, как и в Activiti, плагин Flowable подсказывает имена классов при указании обработчика. Правда, у меня возникли небольшие затруднения с настройкой, причем не только с MessageEvent, но и с TimerEvent. В интерфейсе отсутствовал пункт по указанию специфичных параметров (длительности для таймера и метки для сообщения). Но памятуя, что Flowable — это форк Activiti, донастроить диаграмму через XML было не так сложно.

Реализация кода проекта идентична предыдущему движку. Единственное, что в данном случае потребовалось поменять, — это импорты. Теперь мы используем org.flowable вместо org.activiti. Делегаты и сервисы те же. Принцип обработки событий тоже не поменялся.

4. Camunda

Camunda — еще один форк Activiti. Справедливее даже сказать, первый форк. Сделан он был еще в 2013 году. В общих чертах: возможности все те же, кроме пары нюансов.

Для создания диаграмм Camunda предоставляет десктопное приложение — Camunda Modeler. Здесь немного другой интерфейс, но, чтобы создать простую диаграмму, много времени не понадобится. Доступные элементы представлены не только с функциональной (задачи, события, ветвления), но и с выразительной точки зрения (объединение в группы и пулы, отображение хранилищ данных). Создать диаграмму в режиме drag & drop можно полностью, без каких-либо заминок.

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

Общей является и опция использования Camunda вместе со Spring Boot. Но здесь есть одна особенность. Помимо возможности подключить REST-библиотеку Camunda, посредством которой в приложение по http загружаются диаграммы, есть зависимость WEB, предоставляющая пользовательский интерфейс. В рамках этого интерфейса у нас есть три инструмента: админка для работы с пользователями, монитор для контроля выполнения процессов и панель созданных задач, в рамках которой можно взаимодействовать с процессами, если в диаграмме присутствуют User Tasks.

Основные сервисы и классы для работы с ядром BPMN отличаются по API, хотя названия и расположение остались каноничными. Адаптация кода под Camunda сильно много времени не отняла, тем более что сам проект довольно простой.

Ознакомиться с MVP-версиями пилотного процесса в каждой из четырех рассмотренных выше систем можно в репозитории.

Попытка определиться с выбором

Все мы, работающие в ИТ, хорошо понимаем, что нет универсального инструмента, как и нет серебряной пули. Мы можем плакать, но продолжать поддерживать старый/неудобный/глючный (нужное подчеркнуть) инструмент, потому что переделывать — слишком дорого / долго (очень дорого) / неизвестно как (безумно дорого). У нас может даже развиться стокгольмский синдром, и мы станем, хоть и невольно, противиться переменам, так как вложили в работу не только время, но и душу.

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

Один из важных факторов — активность проекта на GitHub. Коммиты и запросы на слияние (merge requests) могут говорить о том, что проект развивается и кому-то интересен. Star и Fork также могут выступать в качестве ориентиров. Сравним наших кандидатов (здесь и далее я решил для наглядности добавить к сравнению движок Bonita BPM):

Также можно обратиться к программистским инструментам № 2 и № 1: Stack Overflow и Google соответственно. Stack Overflow покажет, есть ли у людей вопросы по инструменту и решаются ли они. А с помощью Google Trends мы оценим общую заинтересованность пользователей в том или ином продукте — по числу поисковых запросов с его названием (делаем скидку на то, что люди могут искать не движок Activiti, а настолку Activity):

И «Оскар» получает…

В итоге я остановил свой выбор на Camunda 7-й версии. По всем ключевым для нас показателям она оказалась явным лидером. Этот движок пользуется большой популярностью, часто совершенствуется и хорошо масштабируется.

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

P.S. Пишите в комментариях, если вы тоже когда-нибудь мучились с выбором движка. Интересно почитать ход ваших мыслей :)

P.P. S. Если кто-то хочет подтянуть свои знания по Camunda, мы набираем слушателей на онлайн-тренинг «BPMN: Исполнение бизнес-процессов в Camunda».

© Habrahabr.ru