Camunda — экосистема для исполняемого BPMN 2.0: от моделирования процесса до оркестрации, мониторинга и операционной работы с инстансами. Для системного аналитика это мост между аналитической BPMN-моделью (потоки, шлюзы, события, пулы — см. соседние материалы раздела) и реализацией: модель должна быть не «картинкой для презентации», а готовой к деплою — с корректной семантикой, исполнимыми задачами, сообщениями, таймерами и явными контрактами с внешними системами. Эта статья — не tutorial по платформе, а исполняемая семантика и границы артефакта SA: что зафиксировать в BPMN/DMN/Forms, чтобы dev и ops могли работать без устных дополнений.

1. Суть темы

Camunda Platform — набор компонент для цикла design → automate → monitor → improve: моделер, workflow-движок, UI для операций и интеграции с внешними сервисами. Аналитик работает в Camunda Modeler и отвечает за то, чтобы BPMN-диаграмма отражала бизнес-процесс и содержала достаточно деталей для исполнения движком. На этапе improve SA задаёт, какие метрики процесса нужны бизнесу (длительность этапов, bottlenecks, SLA); сбор и визуализация KPI — в Optimize, операционный разбор инстансов — в Operate / Cockpit.

Граница этой статьи:

В зоне этой статьиВынесено в соседние заметки
Camunda Modeler, исполнимость, деплой, роль SA в цикле «модель → тест → prod»Элементы нотации BPMN — 06.02.01 Потоки, шлюзы, события, 06.02.02 Пулы, дорожки и артефакты, 06.02.03 Типовые паттерны BPMN
Связь BPMN с DMN, формами, job workers / external tasksЧистая нотация и введение — 03.04.01 BPMN 2.0 - введение и основы
Полный пакет артефактов сквозной фичи10.01.08 Шаблон сквозной фичи (BPMN-процесс)
ArchiMate, C4, слои предприятия06.03.01 Мотивационный слой, 06.03.05 C4-модель

Когда Modeler + чеклист, а когда шаблон 10.01.08: для локального процесса или proof-of-concept достаточно исполняемой BPMN в Modeler и чеклиста из раздела 3. Шаблон 10.01.08 Шаблон сквозной фичи (BPMN-процесс) нужен, когда процесс — центр сквозной фичи с несколькими интеграциями, ролями, NFR и трассировкой к требованиям: там SA собирает BPMN вместе с контрактами API, формами, матрицей трассировки и критериями приёмки.

Две линейки продукта не смешивайте в одном проектном глоссарии без явного указания версии:

ЛинейкаДвижокТипичный SA-фокус
Camunda 7Process Engine (встраиваемый Java, REST)serviceTask, Java delegates, external task pattern, Cockpit + Tasklist
Camunda 8Zeebe (распределённый workflow)Modeler → Operate / Tasklist / Optimize, job workers, connectors, gRPC/REST API
flowchart LR
    SA[Системный аналитик] -->|BPMN/DMN XML| M[Camunda Modeler]
    M -->|deploy| E[Workflow Engine<br/>7: Process Engine / 8: Zeebe]
    E --> O[Operate / Cockpit]
    E --> T[Tasklist]
    E --> Opt[Optimize]
    E <-->|jobs / REST| W[Workers / сервисы]
    SA -->|спецификация| W
    Opt -->|KPI / process mining| SA

Минимальный исполняемый процесс в XML Camunda Modeler: старт, пользовательская задача, исключающий шлюз и два завершения.

<?xml version="1.0" encoding="UTF-8"?>
<bpmn:definitions xmlns:bpmn="http://www.omg.org/spec/BPMN/20100524/MODEL" xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI" xmlns:dc="http://www.omg.org/spec/DD/20100524/DC" xmlns:di="http://www.omg.org/spec/DD/20100524/DI" xmlns:camunda="http://camunda.org/schema/1.0/bpmn" id="Definitions_camunda_leave" targetNamespace="http://bpmn.io/schema/bpmn" exporter="Camunda Modeler" exporterVersion="5.0.0">
  <bpmn:collaboration id="Collaboration_camunda_leave"><bpmn:participant id="c_pool" name="Согласование отпуска" processRef="Process_leave" /></bpmn:collaboration>
  <bpmn:process id="Process_leave" name="Согласование отпуска" isExecutable="true"><bpmn:laneSet id="LaneSet_c_pool"><bpmn:lane id="c_mgr" name="1. Руководитель"><bpmn:flowNodeRef>c_s</bpmn:flowNodeRef><bpmn:flowNodeRef>c_t</bpmn:flowNodeRef><bpmn:flowNodeRef>c_g</bpmn:flowNodeRef><bpmn:flowNodeRef>c_yes</bpmn:flowNodeRef><bpmn:flowNodeRef>c_no</bpmn:flowNodeRef></bpmn:lane></bpmn:laneSet><bpmn:startEvent id="c_s" name="Заявка&#10;создана"><bpmn:outgoing>Flow_0</bpmn:outgoing></bpmn:startEvent><bpmn:userTask id="c_t" name="Проверить&#10;заявку" camunda:assignee="manager"><bpmn:incoming>Flow_0</bpmn:incoming><bpmn:outgoing>Flow_1</bpmn:outgoing></bpmn:userTask><bpmn:exclusiveGateway id="c_g" name="Согласовано?"><bpmn:incoming>Flow_1</bpmn:incoming><bpmn:outgoing>Flow_2</bpmn:outgoing><bpmn:outgoing>Flow_3</bpmn:outgoing></bpmn:exclusiveGateway><bpmn:endEvent id="c_yes" name="Согласовано"><bpmn:incoming>Flow_2</bpmn:incoming></bpmn:endEvent><bpmn:endEvent id="c_no" name="Отклонено"><bpmn:incoming>Flow_3</bpmn:incoming></bpmn:endEvent><bpmn:sequenceFlow id="Flow_0" sourceRef="c_s" targetRef="c_t" /><bpmn:sequenceFlow id="Flow_1" sourceRef="c_t" targetRef="c_g" /><bpmn:sequenceFlow id="Flow_2" name="да" sourceRef="c_g" targetRef="c_yes" /><bpmn:sequenceFlow id="Flow_3" name="нет" sourceRef="c_g" targetRef="c_no" /></bpmn:process>
  <bpmndi:BPMNDiagram id="BPMNDiagram_camunda_leave">
    <bpmndi:BPMNPlane id="BPMNPlane_camunda_leave" bpmnElement="Collaboration_camunda_leave">
      <bpmndi:BPMNShape id="c_pool_di" bpmnElement="c_pool" isHorizontal="true"><dc:Bounds x="80" y="40" width="696" height="324" /></bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="c_mgr_di" bpmnElement="c_mgr" isHorizontal="true"><dc:Bounds x="110" y="40" width="666" height="324" /></bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="c_s_di" bpmnElement="c_s"><dc:Bounds x="153" y="108" width="36" height="36" /><bpmndi:BPMNLabel><dc:Bounds x="145" y="152" width="53" height="28" /></bpmndi:BPMNLabel></bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="c_t_di" bpmnElement="c_t"><dc:Bounds x="280" y="86" width="180" height="80" /></bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="c_g_di" bpmnElement="c_g" isMarkerVisible="true"><dc:Bounds x="544" y="101" width="50" height="50" /><bpmndi:BPMNLabel><dc:Bounds x="527" y="69" width="85" height="14" /></bpmndi:BPMNLabel></bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="c_yes_di" bpmnElement="c_yes"><dc:Bounds x="685" y="108" width="36" height="36" /><bpmndi:BPMNLabel><dc:Bounds x="664" y="152" width="78" height="14" /></bpmndi:BPMNLabel></bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="c_no_di" bpmnElement="c_no"><dc:Bounds x="685" y="266" width="36" height="36" /><bpmndi:BPMNLabel><dc:Bounds x="670" y="310" width="66" height="14" /></bpmndi:BPMNLabel></bpmndi:BPMNShape>
      <bpmndi:BPMNEdge id="Flow_0_di" bpmnElement="Flow_0"><di:waypoint x="189" y="126" /><di:waypoint x="280" y="126" /></bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Flow_1_di" bpmnElement="Flow_1"><di:waypoint x="460" y="126" /><di:waypoint x="544" y="126" /></bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Flow_2_di" bpmnElement="Flow_2"><di:waypoint x="594" y="126" /><di:waypoint x="685" y="126" /><bpmndi:BPMNLabel><dc:Bounds x="602" y="108" width="24" height="14" /></bpmndi:BPMNLabel></bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Flow_3_di" bpmnElement="Flow_3"><di:waypoint x="569" y="151" /><di:waypoint x="569" y="284" /><di:waypoint x="685" y="284" /><bpmndi:BPMNLabel><dc:Bounds x="577" y="157" width="27" height="14" /></bpmndi:BPMNLabel></bpmndi:BPMNEdge>
    </bpmndi:BPMNPlane>
  </bpmndi:BPMNDiagram>
</bpmn:definitions>

Camunda не заменяет BPMN как нотацию — она исполняет подмножество BPMN 2.0 с платформенными расширениями (camunda:* в XML). Одна и та же диаграмма может быть корректной BPMN для документирования и непригодной для deploy: unsupported elements, отсутствие обязательных атрибутов Camunda, черновик из draw.io без executable-флага. Перед деплоем проверяйте модель в Modeler и матрицу поддержки выбранного движка.

2. Ключевые понятия

Camunda Modeler

Desktop-приложение для BPMN 2.0, DMN (Decision Model and Notation) и Camunda Forms. Основной артефакт для деплоя — BPMN 2.0 XML. Modeler поддерживает Camunda-расширения: тип задачи, job type / topic, input/output mapping, form key и др. Без них диаграмма остаётся визуальной схемой.

Исполняемый процесс (executable process)

BPMN-процесс с isExecutable="true", который движок может инстанцировать и проводить по токенам: start/end events, tasks, gateways, message/timer/signal events — в пределах поддержки выбранной версии движка. Неисполнимая модель допустима на этапе обсуждения с бизнесом, но не деплоится «как есть».

Process definition и process instance

ПонятиеСмысл
Process definitionЗадеплоенная версия модели — шаблон процесса
Process instanceОдин конкретный прогон (case) с переменными процесса и текущим состоянием токенов

Новая версия definition применяется к новым инстансам; уже запущенные продолжают по версии старта. Политику версионирования и миграции running instances фиксируйте с командой заранее — риски миграции 7 → 8 см. 08.05 Управление рисками на этапе анализа.

Переменные процесса

Единый словарь переменных — основа форм, API и мониторинга в Operate. SA фиксирует имя, тип, источник и область видимости:

УровеньГде живётКто заполняетТипичное использование
Process variableВесь инстансStart event, service task, user task (submit)orderId, amount, статус кейса
Local variableEmbedded/called subprocess, scope задачиI/O mapping, scriptПромежуточные значения без «загрязнения» родителя
Task variable (C7)User taskForm submit, TasklistПоля формы до complete
Input/output mappingГраница task / call activitySA задаёт mapping в ModelerПроброс customerId в worker; изоляция внутренних имён

Расхождение имён между формой, BPMN mapping и OpenAPI worker — частый источник инцидентов. Согласуйте словарь с 10.01.14 Шаблон глоссария и словаря данных.

User task, Tasklist и Camunda Forms

User task — задача для человека. И в Camunda 7, и в Camunda 8 human workflow идёт через Tasklist: assignee, candidate groups, form reference. SA описывает роли (согласуйте с 10.01.11 Шаблон ролевой модели), поля формы и SLA по NFR.

Camunda Forms — отдельный контур от кастомного FE:

Способ привязкиСмысл для SA
Form key (C7) / linked form (C8)Ссылка на задеплоенную форму по id; поля формы → переменные процесса при complete
Embedded form (C7, legacy)HTML/JSON inline в BPMN — редко для новых проектов
Custom FE + RESTTasklist не используется; форма вне Camunda — тогда 10.01.09 Шаблон описания экранной формы и логики на FE

SA для Tasklist-контура описывает: id формы, список полей (label, type, required, binding к variable), validation rules, read-only vs editable. В Camunda 8 форма деплоится вместе с BPMN (единый deployable resource); в C7 form key указывает на deployed form definition. Поля формы и process variables должны совпадать по именам или явному mapping — иначе на test-стенде задача complete без ожидаемых данных. Для сложной FE-логики (мастера, условные блоки) — либо Camunda Form с JS validation, либо custom app + external task pattern; границу зафиксируйте в спецификации.

Service task

Service task — автоматическое действие. Реализация зависит от линейки:

ЛинейкаТипичная реализацияЧто фиксирует SA на диаграмме
Camunda 7Java delegate, external task (topic + long polling)Implementation type, topic, I/O, контракт ошибок
Camunda 8Job worker (gRPC/REST), connector (готовая интеграция)Job type, input/output mapping, retries

Контракт API — в 03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf) или 10.01.04 Шаблон спецификации REST API; протокол — в 03.05.02 Синхронные протоколы (REST, gRPC, GraphQL); версионирование called-сервисов — 03.05.07 Управление версионированием API и жизненным циклом.

Connector (Camunda 8) — преднастроенная интеграция (REST, messaging и др.) без собственного worker-кода. SA выбирает connector, когда сценарий типовой и покрыт catalog; custom job worker — когда нужен контроль над логикой, идемпотентностью и observability. Connector не снимает обязанность описать I/O, ошибки и idempotency на уровне процесса.

Job / job worker (Camunda 8 / Zeebe)

Паттерн отделения оркестрации от исполнения: движок создаёт job, worker забирает, выполняет логику, complete/fail. External task в Camunda 7 решает ту же задачу, но это другой API и семантика polling — не называйте его «job worker». Для SA важна граница ответственности на схеме: что делает процесс vs что делает сервис.

Message correlation и signal

Message — точечная доставка: message catch event связывается с конкретным инстансом через correlation keys (переменные процесса). Критично для паттернов «ожидание ответа от внешней системы» — см. 06.02.03 Типовые паттерны BPMN.

Signal — broadcast без correlation: один signal может затронуть много инстансов процесса. Используйте для event-driven сценариев («отменить все заявки по событию X»); стыкуется с 03.05.06 Event-Driven Architecture. Не подменяйте signal там, где нужна адресная доставка message.

Таймеры

Timer start / intermediate / boundary задают когда срабатывает событие:

ТипСмысл для SA
Duration (PT24H)Относительная задержка от активации
DateАбсолютная дата/время
CycleПериодический запуск (timer start)

Boundary timer на user task — эскалация по SLA: явно укажите interrupting (прерывает задачу) или non-interrupting (параллельная ветка напоминания). Business calendar (рабочие часы) vs технический SLA — разные требования; последние оформляйте как NFR.

Event subprocess

Event subprocess — подпроцесс, активируемый событием внутри родительского процесса, часто для «глобальных» реакций: отмена кейса, SLA на весь процесс, реакция на message/signal вне локальной задачи. Два режима:

РежимПоведениеТипичный сценарий
InterruptingПрерывает основной потокГлобальный timeout кейса, аварийная отмена
Non-interruptingПараллельная веткаФоновое уведомление, audit-log

Boundary event на одной задаче покрывает локальную эскалацию; event subprocess — когда событие относится ко всему инстансу. Нотация стартовых событий subprocess — в 06.02.01 Потоки, шлюзы, события.

Multi-instance (MI)

Parallel или sequential multi-instance на task/subprocess — стандартный способ моделировать согласование N участников, а не ручной loop в subprocess. Перед моделированием проверьте поддержку MI в матрице Camunda 7/8; completion condition (${nrOfCompletedInstances == 3}) и переменные коллекции (assigneeList) должны быть в спецификации.

Call activity и embedded subprocess

КонструкцияКогда выбирать
Embedded subprocessЛогический блок внутри одного deployable process; версионируется вместе с родителем
Call activityПереиспользуемый subprocess с отдельным deploy и lifecycle

Для call activity SA документирует: called element (process id), input/output mapping между родителем и дочерним процессом, политику версий called process (always latest vs pinned version). Типичный источник инцидентов при деплое — несогласованный mapping или ссылка на несуществующую версию.

DMN

Таблицы решений вызываются из BPMN через Business Rule Task со ссылкой на decision definition (DMN). Отдельного BPMN-элемента «decision task» нет — не путайте с DMN-элементом decision. SA определяет границу «процесс vs правило»: табличные разветвления — в DMN, каркас потока — в BPMN.

При деплое DMN создаётся новая decision definition version — симметрично process definition. Зафиксируйте: I/O Business Rule Task ↔ input/output decision table, политику «always latest» vs pinned version (как у call activity), кто утверждает изменение правил без изменения BPMN.

Компенсация, saga и ошибки

Три механизма, которые SA не смешивает:

МеханизмНазначениеОтличие
BPMN Error (throw/catch, boundary)Ожидаемый бизнес-отказ → управляемая веткаНе откатывает уже выполненные шаги
Compensation (compensation throw/catch, transaction subprocess)Откат успешно завершённых activity при отмене транзакцииСвязана с transaction boundary; не substitute для boundary error
Failed job / retryТехнический сбой workerПовтор исполнения, не бизнес-ветка

Паттерны saga и compensation boundary — в 06.02.03 Типовые паттерны BPMN; здесь важно: компенсация ≠ BPMN error и ≠ incident после исчерпания retries.

Ошибки: BPMN error, failed job, incident

МеханизмСемантикаКто инициирует
BPMN Error (error throw / catch, boundary event)Ожидаемая **бизнес-**ошибка («отказ», «лимит превышен») → управляемая ветка процессаWorker/delegate бросает error code; процесс ловит boundary
Failed job / external task failureТехнический сбой исполнения (timeout, 500, недоступность сервиса)Worker fail; движок применяет retry policy
Incident (Operate / Cockpit)Job исчерпал retries или модель неконсистентна — инстанс застрял, нужна ops-реакцияДвижок создаёт incident

SA описывает error codes и boundary events для бизнес-веток; retry count и backoff — с dev. Резолв incident (retry, skip, migrate variable) — зона ops; SA участвует в разборе root cause и правке модели/контракта.

Deployment

Публикация BPMN/DMN/Forms XML в движок. SA фиксирует workflow артефактов, а не только технический способ upload:

РешениеЧто описать в требованиях
Источник истиныGit-репозиторий моделей (07.05 Системы контроля версий (Git) для документации), не «XML только у аналитика на диске»
Кто деплоитSA → dev на dev; prod — через CI/CD (07.06 CICD и конвейеры — влияние на требования) с approval
ВерсионированиеTag/release модели; связь commit ↔ process definition version в Operate/Cockpit
Стендыdev/test/prod; запрет ручного deploy в prod из Modeler без процесса

Деплой создаёт новую process/decision definition version; мониторинг — через Operate (Camunda 8) или Cockpit (Camunda 7).

Безопасность и многотенантность

В корпоративном контуре SA фиксирует в требованиях (детали — 08.07 Основы кибербезопасности для системного аналитика, 03.05.05 Безопасность API):

  • Аутентификация Tasklist — SSO/OIDC; mapping пользователя IdP → assignee.
  • Candidate groups vs реальные группы IdP — имена групп в BPMN должны совпадать с тем, что отдаёт identity provider (см. 10.01.11 Шаблон ролевой модели).
  • Tenant (Camunda 8) / authorization на REST API (C7) — изоляция процессов между подразделениями или клиентами; tenant id при старте инстанса.

Camunda 7 vs Camunda 8 (концептуально)

АспектCamunda 7Camunda 8
ДвижокEmbedded Process Engine (Java)Zeebe, cloud-native
Service tasksJava delegate, external taskJob workers, connectors
Human tasksTasklistTasklist
МониторингCockpitOperate
Аналитика процессаOptimize (optional)Optimize
Условия на шлюзахJUEL (${amount > 1000})FEEL (amount > 1000)
Выражения DMNFEEL (частично) / JUELFEEL
РасширенияЗрелая экосистема pluginsИной набор supported BPMN-элементов

Перед моделированием зафиксируйте версию, синтаксис условий на gateway и тестовые данные переменных — согласуйте с dev. Проверьте официальную матрицу поддержки BPMN-элементов: не весь BPMN 2.0 исполняется одинаково.

3. Как применяется в работе аналитика

Где SA добавляет ценность

  1. Модель «к исполнению»: каждый user task — роль, form key/linked form, I/O; каждый service task — система, контракт (sync/async), error codes; compensation boundary — где нужен откат (см. 06.02.03 Типовые паттерны BPMN).
  2. Границы процесса: один deployable process vs call activity / embedded subprocess — согласовано с 06.02.02 Пулы, дорожки и артефакты.
  3. Переменные процесса: единый словарь с областями видимости — основа для форм, API и Operate.
  4. События и интеграции: message (correlation) vs signal (broadcast); boundary vs event subprocess для локальных и глобальных исключений.
  5. Happy path + исключения: BPMN errors vs technical retries vs compensation — то, что видно в Operate при разборе инцидентов.
  6. Multi-instance: параллельное/последовательное согласование — MI вместо ad-hoc циклов.
  7. Трассируемость: осмысленные id и name, документация в Modeler — 02.03.04 Трассировка требований (концепция), при необходимости 10.01.15 Шаблон матрицы трассировки.
  8. Review модели: walkthrough, чеклист, mock workers / process test на test-стенде — 08.03 Тестирование требований (статическое тестирование), 02.04.01 Верификация и валидация (V&V).
  9. DMN: правила, которые бизнес меняет чаще процесса, — в decision tables с версионированием.
  10. Метрики для Optimize: какие длительности этапов, объёмы, SLA отслеживать — SA формулирует; дашборды настраивает ops/аналитика данных.

Типовой workflow SA в Camunda-контуре

flowchart TD
    A[Черновик BPMN в Modeler] --> B[Walkthrough с бизнесом]
    B --> C[Проверка исполнимости с dev]
    C --> D[Deploy на dev/test]
    D --> E[Прогон сценариев в Operate / Cockpit]
    E --> F{Инциденты / расхождения?}
    F -->|да| C
    F -->|нет| G[Документирование + handover]

На этапе E аналитик смотрит не только happy path: переменные инстанса, stuck tokens, incidents — обратная связь к качеству модели. Критерии приёмки процесса — 02.04.02 Критерии приёмки (Acceptance Criteria).

Чеклист артефактов перед передачей в разработку

ПроверкаЧто должно быть
Executable flagisExecutable="true" на процессе
СтартЯвная политика старта: message/timer start + кто инициирует (REST API, scheduler, message); несколько none start в одном процессе — почти всегда ошибка моделирования
ПотокиВсе sequence flows замкнуты; у exclusive gateway — явные условия (FEEL в C8 / JUEL в C7), согласованные тестовые данные
User tasksAssignee / candidate groups, form key или linked form, поля ↔ variables, I/O
Service tasks (C7)Delegate или external task + topic, I/O, error codes, retries, idempotency key где возможен повтор
Service tasks (C8)Job type или connector, I/O, error codes, retries, idempotency key
Call activityCalled process id, I/O mapping, политика версии
Multi-instanceКоллекция, completion condition
Сообщения / signalsКаталог имён; для message — correlation keys и idempotency при redelivery
Таймеры / event subprocessDuration/date/cycle; interrupting vs non-interrupting; глобальные timeout/отмена — event subprocess
ИсключенияBoundary error/timer; compensation boundary — отдельно от BPMN error
ПеременныеСловарь с scope (process/local/mapping)
Версия платформыCamunda 7 или 8, supported elements — в глоссарии
DMNBusiness Rule Task → decision definition; I/O; политика версии decision
БезопасностьCandidate groups ↔ IdP; tenant при multi-tenant

Связь с интеграцией

Service task и message events — точки стыковки с интеграционными интерфейсами. Асинхронные ожидания — message correlation и асинхронное взаимодействие. Деплой моделей — часть CI/CD-контура; XML-модели — в Git.

Минимальный пример: service task и ошибки

На диаграмме — business-level имя («Проверить кредитный лимит»). В properties Modeler — техническая привязка:

  • Job type (C8) / topic (C7 external task): credit-check
  • Input mapping: customerId, amount
  • Output mapping: creditApproved, rejectReason
  • Business error: worker бросает BPMN error CREDIT_DENIED → boundary error event «Отказ» на задаче
  • Technical error: worker fail / HTTP 503 → retries по политике; после исчерпания — incident в Operate (ops retry/skip; SA правит модель при систематических сбоях)
  • Compensation (если до этого был успешный reserve limit): отдельный compensation handler — не путать с boundary error «Отказ»

SA не пишет код worker, но закрывает контракт: данные, error codes, ветки процесса, граница SA vs ops на инцидентах.

4. Типовые ошибки и ограничения

Ограничения платформы

  • Не весь BPMN 2.0 исполняется: complex gateways, choreography, редкие события часто только для документирования — см. раздел 1 про valid BPMN ≠ deployable.
  • Camunda extensions привязывают модель к платформе; export «чистого» BPMN может потребоваться для другого engine.
  • Granularity: крупный процесс → сложный мониторинг; слишком много мелких call activity → overhead версионирования и I/O mapping.
  • Миграция 7 → 8 нетривиальна: другой движок, API workers, FEEL вместо JUEL. Не смешивайте термины в документации — риски зафиксируйте по 08.05 Управление рисками на этапе анализа.

Типичные ошибки аналитика

ОшибкаПоследствиеКак избежать
Модель не executable, но ожидают deployПроцесс не стартуетЯвно разделять черновик и модель к деплою
Несколько none start eventsНеоднозначный старт, deploy errorMessage/timer start + документированный инициатор
«Decision task» вместо Business Rule TaskDev ищет несуществующий элементТолько Business Rule Task + decision definition
Business error без error code / boundaryНеконтролируемый fail → incidentError throw/catch в спецификации
Compensation смешана с BPMN errorНеверный откат или веткаРаздел 2 «Компенсация, saga и ошибки»; паттерны — 06.02.03 Типовые паттерны BPMN
Только boundary, без event subprocessНет глобальной отмены/timeout кейсаEvent subprocess для process-level исключений
Implicit gateway logicНепредсказуемая веткаУсловие на каждом исходящем потоке; FEEL/JUEL по линейке
Message/signal без семантикиЗависшие или лишние инстансыMessage = correlation; signal = broadcast
Call activity без I/O mappingIncident при старте дочернего процессаMapping + версия called process
Loop subprocess вместо MIНеподдерживаемая или хрупкая логикаMulti-instance для N согласующих
User task без form/variablesРазрыв UX и процессаForm key + согласование полей с variables
Form fields ≠ process variablesComplete без данных на test-стендеЕдиный словарь; linked form в deploy bundle (C8)
Service task как «чёрный ящик»Incidents без playbooksКонтракт ошибок, retries, boundary, idempotency
C7 external task назван «job worker»Путаница в реализацииТермины по линейке из таблицы «Camunda 7 vs Camunda 8»
Только ideal flowDev додумывает escalationTimer boundary, event subprocess, компенсации
Candidate groups не совпадают с IdPЗадачи не видны в TasklistСогласование с 10.01.11 Шаблон ролевой модели

Критерий «модель готова»

Модель готова к передаче, если на test-стенде можно пройти сценарий в Operate/Cockpit без устных дополнений: все start policies, user tasks с формами, service tasks с mock workers, message/timer/signal, MI, call activity, event subprocess, заявленные BPMN errors, boundary timers и compensation (где применимо). Статическая проверка до прогона — 08.03 Тестирование требований (статическое тестирование); формальная V&V — 02.04.01 Верификация и валидация (V&V). Если нужны пояснения «dev сам поймёт» — модель не завершена.

Граница ролей SA и ops

Зона SAЗона ops
Семантика модели, контракты, error codes, SLA в диаграммеRetry/skip incident, migrate variables, hotfix deploy
Root cause после инцидента → правка BPMN/DMN/specЕжедневный мониторинг Operate/Cockpit
Требования к метрикам для OptimizeНастройка Optimize, алерты
Требования к auth Tasklist, tenant, candidate groupsНастройка IdP, authorization engine

Связи с другими разделами базы

Источники и дополнительные материалы

Официальная документация Camunda

Стандарты