Компания “Хоулмонт” будет предлагать российский движок в составе платформы OpenBPM, как самостоятельный коммерческий продукт, расширяя линейку уже существующих продуктов компании, таких как “СЭД Тезис” и система быстрой разработки “Джеймикс”.
Команда развития российского BPM-движка, помимо фич, обеспечивает выполнение ключевых производственных процессов:
- Подготовку различных сборок, в том числе тех, которых не было у Camunda (с расширенными механизмами мониторинга).
- Регулярное обновление зависимостей, оперативную пересборку версий при выявлении CVE в коде движка и/или среди подключаемых библиотек.
- Проведение периодических нагрузочных испытаний движка с публикацией результатов.
- Проведение периодической проверки на совместимость с суверенным окружением (ОС, JDK, БД).
И, конечно, решаются регламетно-административные задачи:
- Наличие свидетельств Роспатента и включение в реестр Российского ПО МинЦифры дают возможность полноценного использования в контуре КИИ.
- Построение конвейера РБПО по актуальным требованиям в РФ.
Технологические фичи движкаПрактически все проекты импортозамещения, в области ОС, СУБД, инфраструктурного ПО начинались с повторения функционала зарубежных аналогов. А далее, по мере накопления эксплуатационного опыта, появлялись и реализовывались идеи, существенно расширяющие функциональность. И на сегодняшний день многие российские продукты успешно перешагнули статус “клонов” и поставляются на рынок, в том числе западный, как самостоятельные решения с уникальной ценностью для конечных пользователей. В OpenBPM мы учли это и дополнили продукт инструментами продуктивности для участников BPM команд. Мы не только перекрыли фичи Camunda Enterprise, но и подготовили собственный план развития под современные эксплуатационные требования и технологии AI.
Прежде всего, мы выделили из поставки BPM-движка функционал мониторинга среды исполнения в отдельный независимый компонент. Это позволило:
- Создать единый центр управления, способный администрировать несколько независимых инсталляций BPM-движка.
- Обеспечить унифицированное управление не только какой-то одной версией движка, а одновременно разными версиями, и даже разными типами движков, в той или иной степени совместимыми по API.
- Реализовать расширенную интеллектуальную навигацию между различными процессными артефактами (комплектами деплоя, схемами процессов и подпроцессов, схемами таблиц принятия решений, экземплярами в разных статусах исполнения и т.д.)
- Реализовать собственный подход к построению тепловых карт процессов, учитывающий не только количественные, но и интервальные показатели.
- Обеспечить настраиваемую модель сбора метрик, которые BPM-движок способен отдавать в автоматизированном режиме.
Кроме того, использование российского фреймворка Jmix, с помощью которого были разработаны новые компоненты, включая единый центр управления, позволило добавить функционал корпоративного уровня:
- Расширенные возможности по аутентификации и авторизации.
- Расширенную настройку прав доступа, как на уровне доступных операторам функций, так и на уровне прикладных данных.
- Механизмы отчетов и визуализации метрик.
По сравнению с оригинальной Camunda 7, код BPM-движка также претерпел изменения в лучшую сторону. Здесь мы объединили усилия с командой проекта Operaton и в результате были решены следующие задачи:
- Программный код был очищен от не используемых в open-source версии компонентов (встроенных систем телеметрии и управления лицензиями, доставшихся в наследство от Camunda Enterprise).
- Была упразднена поддержка морально устаревших технологий (таких как старые версии серверов приложений, JavaEE и Spring Framework 5).
Технологические ограниченияАрхитектура движка принципиально не изменилась, поэтому важно отметить, что у Camunda 7 и у Camunda 8 разные области применения и разные подходы к построению среды исполнения процессов.
Движок Camunda 8 не зависит от внешней базы и записывает данные непосредственно в файловую систему на тех же серверах, на которых он развернут. Такой подход обеспечивает хорошую горизонтальную масштабируемость и позволяет работать на очень больших масштабах. Но ценой этому является более сложная внутренняя организация, значительное усложнение программной архитектуры, более высокие требования по обслуживанию инфраструктуры. Также важно отметить, что начиная с версии 8.6 Camunda изменила лицензионную политику, и теперь для промышленного использования необходимо приобретать Enterprise лицензию.
Движок Camunda 7 хранит данные в реляционной базе, которая в ряде кейсов может выступать узким местом. Тем не менее, имеются примеры решений, где движок позволяет запускать десятки процессов в секунду и исполнять в параллельном режиме более миллиона задач. А такой производительности более чем достаточно для подавляющего числа прикладных кейсов.
Поэтому мы уверены, что “потолок” применения архитектуры 7-ой версии еще не достигнут и активно помогаем разработчикам избегать типичных ошибок проектирования:
Миграция проектов с Camunda 7Преемственность по REST API, к сожалению, не перекрывает все возможные кейсы использования BPM-движка в прикладных решениях. Поэтому мы готовим разнообразные сценарии быстрой миграции и подбираем инструменты для них. Отдельного внимания, как мы убедились на практике, заслуживают проекты с устаревшими версиями движка Camunda 7, а также новые требования по переносу исполняемой среды бизнес-процессов в полностью российское программное окружение (ОС, JDK, СУБД).