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

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

С такой ситуацией столкнулся один из корпоративных заказчиков DBI. Управленческий сервис на базе Camunda регулярно давал сбои, требовал доработок и не обеспечивал стабильной работы в продуктивной среде. Для заказчика это стало задачей по замене инструмента и созданию более управляемой архитектуры автоматизации бизнес-процессов.

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

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

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

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

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

В проекте было несколько ключевых ограничений:

1.    Снизить зависимость от разработки при изменении бизнес-процессов.
Раньше бизнес-аналитик готовил концепт процесса, после чего разработчик формировал финальную BPMN-схему для согласования или обработки заявок. Такой подход требовал участия технической команды даже при настройке типовых процессов. Поэтому в новом решении было важно заложить конфигурационный подход к описанию процессов: изменения должны были вноситься не через доработку программного кода, а через настройку структуры процесса. При этом сама конфигурация через JSON остаётся трудоёмкой и требует понимания логики процесса, поэтому её нельзя приравнивать к простой настройке через пользовательский интерфейс.

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

На раннем этапе использовался паттерн External Task, при котором выполнение задач выносится во внешний сервис. Изначально это должно было повысить гибкость и снизить нагрузку на ядро системы.

Однако в эксплуатации он оказался нестабильным: возникали дубли выполнения задач, а иногда процесс «замирал» — при формально работающей системе задачи переставали поступать во внешний сервис.

Попытки точечной настройки давали лишь краткосрочный эффект и не устраняли проблему полностью. Команда проверяла гипотезы, связанные с версией базы данных, количеством соединений и HTTP-клиентом. Одна из гипотез была связана с тем, что при большом количестве BPMN-файлов и экземпляров процессов Camunda могла создавать повышенную нагрузку на соединения с базой данных.

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

Команда рассмотрела несколько альтернатив:

Apache Camel подходил как мощный Java-фреймворк для интеграций, но не закрывал требования заказчика как готовая основа для бизнес-процессов. У него нет собственного удобного пользовательского интерфейса для бизнес-пользователей, а описание процессов через XML сохраняло бы зависимость от технических специалистов.

Airflow рассматривался как open-source платформа для оркестрации сложных workflow, но его сильная сторона — технические задачи, связанные с трансформацией и передачей данных. Для бизнес-процессов с согласованиями, маршрутизацией заявок и участием бизнес-пользователей он подходил хуже.

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

Наиболее перспективной основой стала n8n — open-source платформа для автоматизации рабочих процессов. Она позволяла совместить гибкость workflow-подхода с возможностью развивать процессы через конфигурацию, а не через постоянное написание новой логики с нуля.

Используя установленный standalone n8n на платформе заказчика, команда DBI за два месяца разработала новый Java-сервис для управления и маршрутизации бизнес-процессов.

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

Java-сервис выполняет две ключевые функции:

• Вызывает следующий шаг или параллельный процесс;
• Устанавливает callback-правило — условие обратного вызова, по которому задача активируется и передаётся на следующий этап процесса.
• Java-сервис в связке с n8n: как устроено решение.

Такой Java-сервис можно рассматривать как промежуточный слой управления workflow: он связывает пользовательский интерфейс, конфигурацию процесса и выполнение шагов в n8n. Это позволило отделить управление маршрутом процесса от конкретной BPMN-схемы и дать бизнесу больше гибкости при настройке логики согласований.

Java-сервис стал внутренней разработкой, которая закрывает несколько задач.

• Управляет переходами между шагами процесса. Сервис определяет, какой этап должен быть вызван следующим, и поддерживает параллельные процессы там, где это требуется логикой маршрута.
• Работает с callback-правилами: фиксирует условие, при котором задача активируется и переходит к следующему этапу.
• Позволяет описывать процесс через конфигурацию. Это важно для бизнес-пользователей: чтобы изменить или создать бизнес-процесс, не нужно каждый раз формировать новую BPMN-схему силами разработки для типового сценария согласования или обработки заявки.
• Фиксирует состояние процесса. Для этого используется snapshot — моментальный снимок конкретного шага, который позволяет понимать, на каком этапе находится экземпляр процесса.
• Поддерживает отображение информации на пользовательском интерфейсе, отделяя динамическую UI-логику от основной серверной модели.

В основе решения лежит разделение конфигурации процесса и текущего состояния заявки.

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

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

Данные, которые возникают при взаимодействии пользователя с задачей и служат детализацией заявки, вынесли в коллекцию Map. Динамическая логика, связанная с пользовательским интерфейсом и детализацией заявки, хранится в JSONB. Такой подход помогает адаптировать решение под разные UI/UX-сценарии без жёсткой привязки к одной модели данных.

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

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

Ключевые элементы архитектуры:

• Java-сервис для управления маршрутизацией процессов;
• n8n как основа автоматизации workflow;
• объект заявки как конфигурация процесса;
• snapshot для фиксации состояния шага;
• JSON / JSONB для хранения динамической логики;
• база данных с пагинацией и индексацией.

Работа началась с анализа причин нестабильности существующего сервиса. Команда проверила гипотезы, связанные с версией базы данных, количеством соединений и обрывами HTTP-соединений между External Task и Camunda.

Когда стало понятно, что точечные доработки не дают устойчивого эффекта, команда перешла к выбору альтернативной технологической основы. Были рассмотрены Apache Camel, Airflow, Temporal и n8n. По итогам анализа n8n оказался наиболее подходящим вариантом с учётом требований заказчика к гибкости и созданию процессов с минимальным участием разработки.

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

В результате проблемный компонент на базе Camunda был заменён новым Java-сервисом, который работает в связке с n8n и обеспечивает управление процессами через конфигурацию.

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

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

Изменился и подход к созданию бизнес-процессов. Раньше бизнес-аналитик передавал концепт процесса разработчику, а разработчик формировал финальную BPMN-схему. Теперь бизнес-аналитик может самостоятельно заполнять конфигурацию процесса. Это не отменяет роль разработки в развитии и сопровождении решения, но снижает её вовлечённость в создание типовых бизнес-маршрутов.

За счёт конфигурационного подхода создание типовых бизнес-процессов стало занимать меньше времени: бизнес-аналитику больше не нужно проходить полный цикл постановки задачи разработчику и подготовки BPMN-схемы.

Таким образом, проект дал заказчику три ключевых результата:

• стабильную работу функциональной части системы без ежедневных перезапусков;
• отказ от сервиса на базе Camunda;
• более самостоятельную настройку бизнес-процессов через конфигурацию.

Изначально Java-сервис создавался под требования одного корпоративного клиента. Однако архитектура решения не привязана к конкретной отрасли: в её основе лежат универсальные элементы управления процессами — конфигурация маршрута, фиксация состояния, callback-правила и взаимодействие с workflow-платформой.

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

Потенциальные сценарии применения включают:

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

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