Релиз OpenBPM 2.0

На связи инженерная команда компании “Хоулмонт”. Мы занимаемся развитием российской платформы OpenBPM. Это так называемый bpm-движок и набор профессиональных инструментов, сгруппированных вокруг него для комплексной автоматизации предприятий. Мы рады сообщить о выпуске OpenBPM Engine v.2.0, являющимся дальнейшим развитием идеи форков “7-ой камунды”.

Это релиз объединяет усилия многих команд, опирается на свежие версии java-фреймворков и содержит принципиальные отличия. Переход на Spring Boot 4 и активное использование Spring AI открывает принципиально новые возможности для разработчиков процессных приложений. Там много технологических инноваций и поэтому требуется ознакомиться с руководствами по миграции, помогающими осуществить перевод проектов на эту технологическую основу в более плавном и предсказуемом режиме.

Расскажем обо всем по порядку.

Четвертый Spring Boot вышел не так давно, в ноябре 2025 года, он выстроен на принципиально новом фундаменте: Spring Framework 7, Jakarta EE 11, Hibernate ORM 7.1, Spring Security 7, Spring Data 2025.1, Jackson 3 и JUnit 6. Как пишут коллеги - “радиус поражения оказался гораздо шире, чем кажется по номеру версии”. Предыдущие open-source версии фреймворка уже сняты с поддержки и перестали получать функциональные обновления и патчи безопасности (Spring Boot 3.4 перестал обновляться в декабре 2025 года, а Spring Boot 3.5 в июне 2026). Так что переход, так или иначе, надо будет планировать.

Движок

Что касается OpenBPM Engine v.2.0, то он, прежде всего, сохраняет функциональную совместимость по схеме данных и по API с Camunda 7 CE, так что переживать особо не стоит, вот так сразу ничего не сломается.

Новая сборка BPM-движка протестирована и поддерживается на Java 17, Java 21 и Java 25. Мы ориентируемся на JDK LTS релизы. Независимые обзоры и описание практических кейсов (вот здесь, здесь или здесь) позволяют утверждать, что даже простая пересборка проектов на JDK 25 (а потом и на JDK 27/29) позволяет добиться общего прироста производительности на 10%.

Технически релиз OpenBPM Engine v.2.0 основан на следующих сборках:

• Spring Boot 4.0 (дальше мы целимся в 4.1 и последующие LTS версии).

• Spring Framework 7.0.

• Quarkus 3.33 LTS.

• PostgreSQL 14+, MariaDB 10.11 LTS, MySQL 8.4 LTS, поддержка уровней совместимости с Oracle, MS SQL Server и DB2 остается без изменений.

• В качестве сервера приложений поддержан Apache Tomcat 11.

• Для тестирования обеспечена поддержка JUnit 6, а для тестирования контейнеров теперь доступен Testcontainers 2.0.

Для исполнения сценариев поддерживаются следующие библиотеки (в том числе их можно легко подключать в run-сборку):

• Groovy 5.0.

• Jython 2.7.4.

• GraalVM JS 25.0.

• GraalVM Ruby 9.1.

При этом устаревший движок JavaScript Nashorn был из зависимостей удален. OpenBPM Engine поддерживает новый высокопроизводительный движок JavaScript GraalVM. Это изменение необходимо учитывать при миграции проектов Camunda 7, так как в Camunda использовался устаревший стандарт ECMAScript 5, который может не корректно работать под управлением новой среды исполнения. Поэтому переносу скриптов необходимо будет уделить больше внимания.

Баги и фичи

В сборке bpm-движка была исправлена проблемная ситуация с формирование протоколов работы. Ключ определения процесса, используемый в логировании MDC (Mapped Diagnostic Context), теперь берется из сохраненного значения базы данных, а не из объекта в памяти, что обеспечивает согласованность корреляции логов.

Для усиления безопасности была введена возможность дополнительной изоляции пути хранения сеансового cookie для Spring Boot приложений.

Ранее, при запуске в одном приложении Spring Boot OpenBPM совместно с другими поставщиками аутентификации (например, Keycloak) веб-приложение OpenBPM Engine и бэкэнд использовали один и тот же сессионный cookie (JSESSIONID). Одновременные запросы с фронтенда могли перезаписать сессионный cookie, вызывая конфликты сессий и неожиданные выходы из системы. Для исправления этой ситуации было введено новое свойство конфигурации, позволяющее принудительно задать ограниченную область действия атрибута path в cookie-файле сессии веб-приложений OpenBPM Engine, изолируя его от cookie-файлов, устанавливаемых остальной частью прикладного приложения. По умолчанию свойство имеет значение false - то есть уже существующие развертывания не затрагиваются.

В сборку OpenBPM Engine был добавлен новый независимый от среды выполнения интерфейс проверки работоспособности Health SPI, который позволяет подключать проверки работоспособности к различным средам развертывания (Spring Boot, Quarkus и обычная Java). Интерфейс состоит из трех общедоступных типов:

• HealthService - центральный интерфейс проверки состояния здоровья.

• HealthResult - неизменяемая запись, содержащая результат проверки.

• FrontendHealthContributor - дополнительный SPI для включения сведений о доступности веб-приложения.

Для портативной run-сборки OpenBPM Engine была выделена легковесная и не использующая кэширование точка подключения /health. Она предназначена для балансировщиков нагрузки и мониторов доступности. Точка возвращает HTTP 200 (UP) или 503 (DOWN), и по умолчанию отключена (но легко включается через переменную конфигурации по пути openbpm.run.health.rest-endpoint.enabled).

В плане расширения интеграционных возможностей движка мы доработали дистрибутивные реализации для REST API и Kafka коннекторов. Их параметрами можно управлять непосредственно из спецификации конкретного “кубика” сервисного таска на BPMN схеме процесса. То есть прямо в expression выражениях стал доступен новый компонент “${kafka. ...}” для отправки сообщений, а также для подключения слушателя топиков по специализированным заголовкам. Подключение к инстансу Kafka настраивается стандартными свойствами “spring.kafka.*” в конфигурационном .yml файле вашего процессного приложения. Значение (value) из исходного сообщения десериализуется и кладётся в переменную процесса “kafkaResult “ (имя настраивается свойством openbpm.kafka.resultVariableName). Сообщение в транспортном формате восстанавливается типизированным Java-объектом, а прочие значения передаются JSON или строкой.

Сборка и перфоманс

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

Также был расширен процесс функционального тестирования. Вместе с кодовой базой мы унаследовали почти две с половиной тысячи классов юнит-тестов, восемь десятков интеграционных тестов и полсотни спецификаций веб интерфейса. Но они проверяют только ядро bpm-движка. Поэтому поверх них мы выстроили комплексную приёмку релиза, где работаем с поставкой в том виде, в каком её получает конечный пользователь: собранные дистрибутивы и веб приложения, поведение которых требует проверки на конкретных ОС/СУБД и версиях Java.

Единый чек-лист из более чем сотни проверок мы проходим для каждой формы поставки (портативные сборки Tomcat и Run, Docker-образы и Spring Boot стартер) и в разном окружении. При этом в каждом из окружений разворачиваем один и тот же набор процессных моделей, DMN-таблиц, форм и прикладного Java-кода: делегаты, слушатели, плагины движка, скрипты на Groovy и JS.

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

Для проведения нагрузочных испытаний мы вынесли тестирование на отдельную инфраструктуру: сервера, среду мониторинга и планировщик автоматических прогонов нагрузки. А также перешли на автоматическое тестирование производительности по "бутылочному горлышку" пропускной способности исполнения джобов, чтобы стабилизировать результаты и настроить политики отслеживания деградаций. Это позволило сравнивать версии между собой, получать целевые цифры для тестирования новых гипотез (новых версий СУБД и их режимов работы, а также разных режимов работы bpm-движка, оптимизированных под конкретный тип транзакционной нагрузки).

Нагрузочное тестирование проводится нами постоянно для подтверждения показателей производительности bpm-движка при выпуске новых версий. Контрольный процесс реализован с акцентом на массовое исполнение операций. Он намеренно был выполнен в «толстом» стиле, с переключением runtime контекста, чтобы минимизировать влияние случайных отклонений в работе REST API эндпоинтов. Количественные метрики подобраны таким образом, чтобы можно было сравнивать результаты последних нагрузочных испытаний с ранее определёнными доверительными интервалами. Если по результатам испытаний все значения метрик укладываются в доверительный интервал, то испытания признается успешными.

Стенд развернут на базе ОС RedOS 8 и имеет 4 vCPU x86, 16 Gb RAM. БД, приложение и экспортёры метрик запущены на одном хосте без изоляции ресурсов. От движка к БД обычно устанавливается 20 соединений, а планировщик движка получает 8 потоков исполнения. История исполнения экземпляров процессов включена в режиме “ACTIVITY”.

По результатам нагрузочных прогонов для версии OpenBPM Engine 2.0 достигается показатель около 450-490 активностей в секунду, что соответствует стандартным показателям работы движка.

Целевые цифры получаются при практически полном исчерпании ресурсов CPU, значения load average около 6-8 при 4 vCpu, что соответствует ситуации высокой утилизации процессорных ядер. При этом характер нагрузки даёт около 100% попадания в кеш БД, в связи с чем в данных сценариях нет ограничений в i/o.

Инструменты

Естественно, что новый релиз затронул не только сборку bpm-движка, но и модульную экосистему наших профессиональных инструментов. Появилась долгожданная возможность “поговорить” со схемой или с конкретным экземпляром бизнес-процесса. Это стало возможным за счет того, что встроенный AI-агент автоматически переключает контекст в зависимости от анализируемого администратором в данный момент времени процессного объекта.

При этом AI-агент в составе генерируемого текста научился формировать “кликабельные” ссылки для быстрой навигации внутри модуля Control. Разумеется, режим рассуждений работает не только точечно, но и поверх списочных объектов, включая предварительно настроенные шаблоны для решения типовых задач. Правда, качество сильно зависит от мощности LLM-модели, минимально приемлемой для локального инференса является Qwen2.5:14B.

Из стадии R&D в ранний доступ поступил наш новый инструмент моделирования на основе AI-агентов. По нему пока что нет красивого оформленного лендинга, но внутри подразделений заказной разработки “Хоулмонт” инженерный прототип модуля Workspace работает уже несколько месяцев.

Мы разрабатываем простой и надежный инструмент для следующего поколения “вайбкодеров”, для так называемых бизнес-инженеров (или business technologist, если следовать современной методологии Gartner). Это автоматизация процессов на базе AI, которая не требует долгого погружения. Конечным бенефициаром здесь является бизнес-заказчик, в пределе он сам сможет общаться с AI-поверхностью и подтверждать/реализовывать свои намерения на современных open-source технологиях.

Наш подход полностью соответствует перспективным тенденциям разработки процессных приложений через AI-поверхность, когда агенты забирают на себя большую часть рутинных задач:

• Агент проводит анализ схем бизнес-процессов для выявления узких мест и подготовки рекомендаций по совершенствованию (либо на основе уже имеющегося процессного репозитория, либо на основе схем слабо автоматизированных процессов, восстановленных по результатам работы систем Task & Process Mining).

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

• Агент подбирает инструменты реализации, готовит исполняемый контур, собирает работоспособный PoC, генерирует пакетов тестовых данных для иллюстрации решения бизнес-задачи. То есть агент наглядно показывает бизнес-заказчику как будут воплощены его намерения.

• Агент генерирует план работ, обсчитывает смету реализации, проводит первичную оценку рисков, готовит рекомендаций по организации последующего мониторинга, бизнес-анализа и цикла совершенствования процесса.

Предполагается, что экосистема профессиональных инструментов вокруг bpm движка OpenBPM Engine позволит бизнес-инженеру комплексно решить поставленную задачу:

• Всесторонне обработать инсайты, полученные на этапах бизнес-анализа (например, по результатам работы систем Task & Process Mining).

• Верифицировать намерения бизнеса.

• Создать спецификацию для реализации.

• Целенаправленно подключить команду разработки и dev-sec-ops, провести генерацию и деплой процессных артефактов в продуктивном контуре.

• Раздать права и запустить в эксплуатацию.

• Поставить на мониторинг.

• Подтвердить достижение экономического эффекта.

• Определить направления для последующего углубленного бизнес-анализа, адаптации и улучшений.

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

Вместо эпилога

Это достаточно длинный и амбициозный путь, который нашей команде еще предстоит пройти, предоставив нашим клиентам лучшие в своем классе платформы для комплексной автоматизации бизнеса. Пожалуйста, присоединяйтесь! Мы будем рады попутчикам и помощникам на этом пути.