BPMN-движки Camunda и Flowable

ОБЯЗАТЕЛЬНО

Аналитику Архитектору Разработчику

---

Зачем это в энциклопедии

BPMN-движок — это сервис исполнения моделей в нотации BPMN 2.0: он создаёт экземпляры процессов, двигает токены по диаграмме, ждёт сообщений и таймеров, создаёт пользовательские задачи и вызывает автоматические шаги (HTTP, очереди, скрипты). Camunda и Flowable — два распространённых открытых движка на JVM с похожей идеологией (оба выросли из общего кода Activiti). Для аналитика и архитектора важно понимать, где заканчивается картинка для согласования и начинается исполняемая модель, как процесс оркестрирует микросервисы и какие риски несёт долгоживущее состояние в движке.

Базовые уровни BPMN и нотация — в статьях Моделирование бизнес-процессов и Справочник по нотации BPMN 2.0. Здесь — практика работы с движком: моделирование под исполнение, оркестрация, интеграции и эксплуатация.

---

Общая картина

Слой	Что делает
Модель	BPMN XML (и при желании DMN для решений), хранится как артефакт репозитория или пакет деплоя.
Движок процессов	Интерпретирует модель, ведёт состояние экземпляров, транзакции БД, job-планировщик для асинхронных шагов и таймеров.
Исполнители шагов	Java-делегаты, скрипты, коннекторы, внешние задачи (external task), вызовы REST — в зависимости от выбранного паттерна.
UI и задачи	Встроенный tasklist / портал или собственное приложение по REST API движка.
Наблюдаемость	История шагов, инциденты, метрики, журналы для расследования «застрявших» процессов.

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

---

Camunda и Flowable — сходства и различия

Оба движка:

• исполняют BPMN 2.0 и обычно DMN для таблиц решений;
• хранят состояние в реляционной БД (PostgreSQL, Oracle и др.);
• дают REST API и Java API;
• поддерживают деплой нескольких версий определения процесса и миграцию экземпляров (инструменты и зрелость миграций нужно проверять по версии продукта).

Camunda сильна в платформенной подаче: Camunda 7 как встраиваемый движок, Camunda 8 как отдельный кластер с Zeebe и новой моделью масштабирования. Документация, обучение и коммерческая поддержка развиты широко.

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

Выбор конкретной версии и редакции (Community / Enterprise) — вопрос лицензии, поддержки, roadmap и интеграции с вашим стеком, а не «правильного» названия на рынке.

Camunda 7 — встраиваемый процессный движок на реляционной БД, привычный для Spring-приложений и классической модели job-исполнителя.

Camunda 8 — отдельная платформа на Zeebe (распределённое хранение состояния, горизонтальное масштабирование воркеров), другая модель операций и клиентских SDK; миграция с 7-ки — отдельный инженерный проект, а не «обновление версии».

Flowable поставляется модулями (engine, REST, UI); команда собирает нужный контур сама, что удобно для встраивания в продукт.

---

Моделирование под исполнение

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

• Старт и завершение — хотя бы один путь от стартового события к конечному; для параллельных веток — явные parallel gateway, чтобы не полагаться на неявный join/split без контроля.
• Идентификаторы — стабильные id элементов; переименование name не ломает API, смена id ломает отчёты и скрипты.
• Переменные процесса — контракт данных между шагами: имена, типы, кто пишет и кто читает; сложные структуры лучше версионировать осознанно.
• User task — поля исполнителя (assignee, candidateGroups), формы (встроенные или ссылки на UI приложения), сроки и приоритеты, если движок их использует.
• Service task — явный тип коннектора или делегата; таймауты и boundary на ошибку, если внешний вызов может упасть или зависнуть.
• Сообщения — объявления message в BPMN и корреляция входящих сообщений с экземпляром (ключи из бизнес-идентификаторов заказа, заявки и т.д.), иначе движок не поймёт, какой процесс продолжить.

Инструменты: Camunda Modeler, Flowable Modeler или IDE с плагином — везде важны валидация и экспорт чистого BPMN XML в пайплайн сборки.

---

Оркестрация и типовые паттерны

Вызов подпроцесса (call activity) — переиспользуемый фрагмент: единая модель «проверка клиента» вызывается из разных продуктовых процессов.

Отправка и ожидание сообщения — send task / message throw и receive task / message catch согласованы с внешним контрактом: внешняя система должна знать тип сообщения и поля корреляции.

Параллельное согласование — multi-instance на user task или параллельный шлюз с несколькими ветками и явным слиянием; условие завершения (например, «достаточно двух из трёх») задаётся выражением на multi-instance или отдельной логикой после join.

Таймеры и эскалации — boundary timer на user task для напоминаний и эскалации на руководителя; таймеры переводят токен на отдельную ветку, не забывая про отмену основной задачи, если это прерывающее событие.

Долгие операции — вынос тяжёлого вызова в асинхронный шаг (часто asyncBefore/asyncAfter в расширениях Camunda или аналог во Flowable), чтобы не держать транзакцию БД движка на время HTTP-запроса.

Компенсация — для бизнес-отката шагов, уже зафиксировавших побочный эффект; требует явного проектирования компенсирующих задач, это не автоматический SQL-rollback.

Связка «процесс + распределённые транзакции» между сервисами обычно строится как сага на уровне архитектуры; BPMN может координировать шаги саги, но идемпотентность и обратимые действия должны быть заложены в сервисах.

---

Интеграция с приложениями

Типичные варианты:

1. Встроенный движок (embedded) — Spring Boot + библиотека движка; процессы деплоятся вместе с приложением. Плюс — простая отладка; минус — масштабирование исполнения процессов связано с масштабированием приложения.

2. Отдельный runtime — кластер движка, к нему ходят микросервисы по REST. Плюс — изоляция нагрузки; минус — сетевая зависимость и версионирование API.

3. External task (характерно для Camunda 7) — движок ставит задачу в очередь, воркеры на других сервисах забирают работу. Удобно на полиглотном стеке (не только Java).

4. Делегаты и listeners — Java-классы, вызываемые из шагов; быстрый путь в монолите, но жёсткая связка кода и модели.

5. DMN — вынесение ветвления по тарифам, скорингам и правилам в таблицу решений, вызываемую из business rule task; снижает «зоопарк» условий в шлюзах.

Для аналитика полезно требовать к модели приложение матрицы данных (какие переменные на входе/выходе каждого шага) и каталог сообщений для межсистемных обменов.

---

Деплой, версии и жизненный цикл

• Деплой создаёт новую версию определения процесса; старые экземпляры по умолчанию остаются на своей версии.
• Новые экземпляры стартуют на последней версии (если не зафиксировано иное).
• Изменение логики «на лету» для уже бегущих кейсов — тема миграции схем; это отдельный проект с тестами и откатом.
• Инциденты (failed job) нужно обрабатывать в эксплуатации: повтор, ручная коррекция переменных, отмена экземпляра.

---

Наблюдаемость и качество

• Включите корреляцию с бизнес-ключом (businessKey) — поиск экземпляра по номеру заказа в поддержке.
• Логируйте идентификаторы экземпляра и задачи во внешних вызовах.
• Ограничивайте сложность одной диаграммы: крупные ветвления выносят в call activity и подпроцессы.
• Пишите автотесты для критичных путей (в Camunda есть test scaffolding; у Flowable — свои подходы к поднятию in-memory engine).

---

Типовые проблемы при внедрении

Симптом	Что обычно стоит проверить
Входящее сообщение «теряется» или создаёт лишний экземпляр	Объявление message, ключи корреляции, совпадение полей с внешней системой.
Процесс «висит» после сервисной задачи	Незавершённый асинхронный переход, упавший job без инцидент-процедуры, блокировка в БД.
После деплоя ломаются старые кейсы	Экземпляры на старой версии, несовместимые изменения id элементов или контракта переменных.
Диаграмма валидна в Modeler, движок ругается при старте	Расширения другого вендора, неподдерживаемый элемент, неверный namespace.

---

Когда BPMN-движок уместен

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

Чистый request/response без долгих ожиданий и ветвления чаще проще реализовать кодом или stateless pipeline. Высокочастотные короткие потоки часто выносят в брокер сообщений или стриминг без центрального процессного движка.

---

С чего начать практику

• Поднять демо (docker-compose с движком и БД), развернуть один сквозной процесс с user task и service task.
• Пройти путь старта из REST, завершения user task, проверки истории в cockpit/admin.
• Зафиксировать соглашение по именованию переменных и сообщений в команде.

Дальше — углубление в корреляцию, мультиинстансы, границы транзакций и паттерны интеграции с вашей шиной или API-шлюзом.

---

Мини-кейс — согласование заявки с таймерами и эскалацией

Типичный сценарий для BPMN-движка:

1. Сотрудник создаёт заявку на расход.
2. Процесс определяет маршрут согласования по сумме (DMN или gateway).
3. Руководитель получает user task с дедлайном 24 часа.
4. Если задача просрочена, срабатывает boundary timer и создаётся эскалация.
5. После согласования сервис проводит заявку во внешней ERP.
6. При ошибке ERP процесс ставит инцидент и переводит кейс в ручную обработку.

В таком кейсе движок прозрачно фиксирует историю шагов, сроки, участников и итоговое решение. Это ценно для аудита и сопровождения.

---

Когда лучше код, а когда BPMN

Практическое правило выбора:

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

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

---

Анти-паттерны внедрения BPMN-движка

• Диаграммы проектируются как презентации без контракта переменных и сообщений.
• В одном процессе скапливают десятки веток без декомпозиции в call activity.
• Используют нестабильные id элементов и ломают миграции/отчёты.
• Игнорируют стратегию обработки инцидентов и ретраев в эксплуатации.
• Моделируют компенсацию формально, без реальных обратимых действий в сервисах.

Эти ошибки приводят к сложной поддержке и "зависающим" экземплярам в продакшене.

---

Чек-лист для запуска в промышленную эксплуатацию

• определён владелец процесса и владелец технической поддержки движка;
• зафиксирован контракт переменных, сообщений и businessKey;
• есть регламент по failed jobs, ручной коррекции и эскалации;
• настроены метрики, алерты и дашборды по инцидентам/латентности шагов;
• протестированы сценарии миграции версий процесса;
• проверены права доступа к tasklist/cockpit/API и аудит действий.

Этот чек-лист помогает перейти от "модель запускается" к "процесс управляем в бою".

---

Release-кейс — изменение процесса без остановки бизнеса

Ситуация: в процессе согласования расходов меняется правило лимита, а в системе уже идут активные экземпляры.

Практичный подход:

1. Деплой новой версии процесса с обновлённой логикой.
2. Новые экземпляры стартуют на новой версии.
3. Для старых экземпляров выбирают стратегию: доживание на старой версии или миграция.
4. Миграцию выполняют по группе кейсов с проверкой инцидентов и бизнес-метрик.
5. В релизных заметках фиксируют ограничения и план завершения перехода.

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

---

Шаблон артефакта — BPMN release checklist

BPMN Release Checklist:
[ ] Новая версия процесса задеплоена и провалидирована
[ ] Контракты переменных/сообщений обновлены
[ ] Стратегия миграции активных экземпляров согласована
[ ] Подготовлен rollback plan
[ ] Настроены алерты по failed jobs и таймерам
[ ] Поддержка получила runbook и контакты owner команды

Чек-лист особенно полезен для релизов с долгоживущими экземплярами процесса.

---

Готовые поля для Jira и YouTrack

Issue Type: Change / Release
Summary: [BPMN] Релиз процесса <process_key> vX
Process Key/Version: ...
Business Owner / Tech Owner: ...
Migration Strategy: stay / migrate / mixed
Runbook Link: ...
Rollback Plan: ...
Monitoring:
- failed jobs alert
- timer lag alert
- incident dashboard
Post-release Check:
[ ] новые экземпляры идут по vX
[ ] инцидентов выше порога нет
[ ] support подтверждает стабильность

Пример заполнения:

Issue Type: Change / Release
Summary: [BPMN] Релиз процесса expense_approval v12
Process Key/Version: expense_approval / 12
Business Owner / Tech Owner: finance.pm / platform.arch
Migration Strategy: mixed
Runbook Link: wiki/processes/expense_approval_v12_runbook
Rollback Plan: rollback to v11 + stop new starts on v12
Monitoring:
- failed jobs alert
- timer lag alert
- incident dashboard
Post-release Check:
[x] новые экземпляры идут по v12
[x] инцидентов выше порога нет
[ ] support подтверждает стабильность

---

В подборках

Связанные материалы: Моделирование бизнес-процессов, Справочник BPMN 2.0, Основы интеграционного взаимодействия.

---