Процессный движок (Process Engine)

Процессный движок - компонент системы, отвечающий за выполнение и управление бизнес-процессами, смоделированными в виде диаграмм BPMN (Business Process Model and Notation).

Он интерпретирует BPMN-модель процесса и:

• управляет переходами между этапами (Activities);
• отслеживает состояния процесса;
• обрабатывает события (Events);
• запускает задачи для пользователей (User Tasks) и автоматические действия (Service Tasks).

В UniBPM процессный движок управляет жизненным циклом (статусной моделью) заявки, создает пользовательские и сервисные задачи.

Ключевые принципы

1. В качестве процессного движка UniBPM может использоваться:

• Собственное процессное ядро (на базе Camunda 7);
• Camunda 7 Run;
• Camunda 8 (Zeebe).

2. Пространству (Workflow) соответствует отдельный тенант в процессном движке. Тенант - логический разделитель (изолятор) внутри движка процессов, который позволяет разграничивать доступ к процессам, задачам и данным между различными группами пользователей или организаций.

3. Каждой заявке, находящейся на стадии обработки, сопоставлен экземпляр процесса в процессном движке.

Модель процесса и экземпляр процесса

Модель процесса (Process Definition) - это описание процесса в нотации BPMN 2.0. Рабочие версии моделируются и хранятся в UniBPM, исполняемые — разворачиваются в процессном движке.

Экземпляр процесса (Process Instance) - это конкретный запуск (исполнение) процесса, смоделированного в BPMN. Если бизнес-процесс — это “шаблон” (модель), то экземпляр — это его “живое выполнение”, с уникальным идентификатором, текущим состоянием, переменными и историей. Каждый раз, когда стартует процесс (вручную, по событию или по расписанию), создаётся новый экземпляр процесса.

По аналогии с ООП: Process Definition - это Класс, Process Instance - экземпляр класса.

Запуск экземпляра процесса

Запуск экземпляра процесса в UniBPM выполняется асинхронно с использованием паттерна Transactional Outbox.

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

Общая схема

1. При возникновении события, требующего запуска процесса (например, создание заявки), система не обращается напрямую к процессному движку.
2. Вместо этого в таблицу bd_process_start_outbox записывается запись со следующими данными:

• идентификатор заявки;
• businessKey;
• ключ процесса (processDefinitionKey);
• идентификатор тенанта (tenantId);
• набор переменных процесса.

Эта операция выполняется в той же транзакции, что и изменение бизнес-данных (например, создание заявки).

Обработка outbox

Отдельный фоновый компонент системы — ProcessStartWorker — периодически выбирает записи из таблицы outbox и запускает соответствующие процессы в процессном движке.

Алгоритм работы воркера:

1. Забрать пакет записей из bd_process_start_outbox со статусом NEW или FAILED.
2. Захватить запись (locking) для обработки конкретным воркером.
3. Запустить процесс в процессном движке.
4. Получить processInstanceId.
5. Сохранить processInstanceId в таблице outbox.
6. Записать processInstanceId в заявку.
7. Перевести запись outbox в статус DONE.

Защита от повторного запуска

Для предотвращения повторного запуска процесса используется следующий механизм:

• processInstanceId сохраняется в outbox сразу после успешного старта процесса;
• при выборе записей воркер обрабатывает только строки, у которых process_instance_id IS NULL.

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

Преимущества подхода

Использование Transactional Outbox обеспечивает:

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

Таким образом, запуск процессов в UniBPM является надёжной асинхронной операцией, не влияющей на транзакции пользовательских операций.