6.07. Справочник по BPMN 2.0

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВНЕ ДЛЯ НОВИЧКОВВ РАЗРАБОТКЕ

Аналитику Архитектору Руководителю Техническому писателю

Справочник по BPMN 2.0

1. Flow Objects (Объекты потока)

Flow Objects — основные узлы поведенческой модели. Определяют события, действия и решения в потоке управления.

1.1 Events (События)

События инициируют, изменяют или завершают процесс. В BPMN 2.0 все события визуально — круги. Тип события определяется:

Границей: тонкая (start), жирная (end), пунктирная (intermediate)
Внутренней иконкой: указывает на триггер или результат
Заливкой: белая (catching), чёрная (throwing), двойная (non-interrupting)

Тип события	BPMN-класс	Иконка	Граница	Заполнение	Семантика	Ключевые атрибуты	Допустимые значения / примечания
Start Event	`bpmn:startEvent`	отсутствует, timer, message, signal, error, escalation, conditional, link, multiple	Тонкая	Белое	Инициирует процесс или подпроцесс	`isInterrupting` (только для attached)	`true` (по умолчанию для start), `false` (только у attached intermediate)
Message Start	`bpmn:startEvent`	конверт	Тонкая	Белое	Ожидает входящего сообщения	`messageRef`	Ссылка на объявленный `bpmn:message` с указанием `itemRef` (структура данных)
Timer Start	`bpmn:startEvent`	часы	Тонкая	Белое	Запускается по расписанию	`timerEventDefinition` → `timeDate`, `timeDuration`, `timeCycle`	`timeDate`: ISO 8601 (напр., `2025-12-18T12:00:00+03:00`) `timeDuration`: `PT30M` (30 минут) `timeCycle`: `R5/PT1H` (5 раз по часу) или cron-подобный `0 0 12 * * ?` (если поддерживается движком)
Signal Start	`bpmn:startEvent`	треугольник с восклицанием	Тонкая	Белое	Запускается при трансляции сигнала	`signalRef`	Ссылка на `bpmn:signal` (глобальное или локальное имя). Трансляция — `throwEvent` с `signalEventDefinition`
Error Start	—	—	—	—	Не существует. Error Event не может быть стартовым.	—	—
Conditional Start	`bpmn:startEvent`	шестиугольник («шестерёнка»)	Тонкая	Белое	Запускается при выполнении условия	`conditionExpression`	Выражение в языке, поддерживаемом движком (FEEL, XPath, JUEL). Пример: `${systemStatus == "online"}`
Intermediate Catch Event	`bpmn:intermediateCatchEvent`	см. подтипы	Пунктирная	Белое	Ожидает внешнего или временного триггера в середине потока	—	—
Message Intermediate Catch	`bpmn:intermediateCatchEvent`	конверт	Пунктирная	Белое	Ожидает входящего сообщения в потоке	`messageRef`	Как у Message Start. Может иметь `outputSet` для маппинга входных данных
Timer Intermediate Catch	`bpmn:intermediateCatchEvent`	часы	Пунктирная	Белое	Пауза до наступления времени	`timerEventDefinition`	Как у Timer Start. Используется для задержки, таймаутов, SLA-контроля
Signal Intermediate Catch	`bpmn:intermediateCatchEvent`	треугольник с восклицанием	Пунктирная	Белое	Ожидает широковещательного сигнала	`signalRef`	Перехватывает сигнал по имени. Поддерживает `eventDefinitions` множественных типов в одном событии (multiple catch)
Conditional Intermediate Catch	`bpmn:intermediateCatchEvent`	шестиугольник	Пунктирная	Белое	Ожидает выполнения условия в реальном времени	`conditionExpression`	Выражение переоценивается периодически. Не блокируется — продолжает опрос. Используется редко, требует поддержки движком
Link Intermediate Catch	`bpmn:intermediateCatchEvent`	стрелка в круг	Пунктирная	Белое	Принимает управление от Link Throw	`name`	Строковый идентификатор. Пара (catch, throw) должна иметь одинаковое имя. Используется для визуального разрыва потока без семантики события
Intermediate Throw Event	`bpmn:intermediateThrowEvent`	см. подтипы	Пунктирная	Чёрное	Генерирует сигнал, сообщение, ошибку и др.	—	—
Message Throw	`bpmn:intermediateThrowEvent`	конверт	Пунктирная	Чёрное	Отправляет сообщение	`messageRef`, `inputSet`	Указывает получателя через `participantRef` в collaboration или через correlation keys. Может инициировать message start другого пула
Signal Throw	`bpmn:intermediateThrowEvent`	треугольник с восклицанием	Пунктирная	Чёрное	Транслирует сигнал всем заинтересованным процессам	`signalRef`	Глобальная трансляция (если `scope="global"`). Локальная — только в рамках того же процесса (движки могут не поддерживать scope явно)
Escalation Throw	`bpmn:intermediateThrowEvent`	перевёрнутый треугольник	Пунктирная	Чёрное	Инициирует эскалацию (не прерывает текущий поток)	`escalationRef`	Ссылка на `bpmn:escalation`. Перехватывается `escalationEventDefinition` в boundary или intermediate catch
Compensation Throw	`bpmn:intermediateThrowEvent`	стрелка влево-вправо (↔)	Пунктирная	Чёрное	Запускает компенсацию (откат) ранее выполненной активности	`activityRef`	Указывает `bpmn:activity`, для которой вызывается компенсационный обработчик (`compensateEventDefinition` в её boundary)
Link Throw	`bpmn:intermediateThrowEvent`	стрелка из круга	Пунктирная	Чёрное	Передаёт управление на Link Catch с тем же именем	`name`	Парный элемент. Используется для избежания пересечений линий. Не несёт семантики, только визуальный переход
End Event	`bpmn:endEvent`	см. подтипы	Жирная	Чёрное	Завершает поток выполнения (токен выбрасывается)	—	—
None End	`bpmn:endEvent`	отсутствует	Жирная	Чёрное	Нормальное завершение потока без результата	—	Единственный обязательный тип. Все процессы должны иметь хотя бы одно окончание
Message End	`bpmn:endEvent`	конверт	Жирная	Чёрное	Отправляет сообщение и завершает поток	`messageRef`	Аналогично Message Throw, но с немедленным завершением после отправки
Signal End	`bpmn:endEvent`	треугольник с восклицанием	Жирная	Чёрное	Транслирует сигнал и завершает поток	`signalRef`	Часто используется для оповещения о завершении (напр., `processCompleted`)
Error End	`bpmn:endEvent`	«молния» (зигзаг)	Жирная	Чёрное	Завершает поток с ошибкой	`errorRef`	Ссылка на `bpmn:error`. Перехватывается boundary error event родительского подпроцесса. Если не перехвачен — ошибка процесса
Escalation End	`bpmn:endEvent`	перевёрнутый треугольник	Жирная	Чёрное	Завершает поток с эскалацией	`escalationRef`	Аналогично Error End, но означает управляемое исключение (не фатальную ошибку)
Cancel End	`bpmn:endEvent`	«X» в круге	Жирная	Чёрное	Отменяет транзакционный подпроцесс (transaction)	—	Может существовать только внутри `transaction`. Приводит к выполнению компенсаций и переходу к cancel boundary event
Terminate End	`bpmn:endEvent`	круг в круге	Жирная	Чёрное	Немедленно завершает весь процесс (все токены, все пулы)	—	Используется крайне редко. Эквивалент `System.exit()` — нет graceful shutdown

Особые события: Boundary Events (Прикреплённые)

Boundary Event — bpmn:boundaryEvent, дочерний элемент bpmn:activity.
Атрибуты:

attachedToRef — ссылка на bpmn:activity
cancelActivity — true (прерывающий, interrupting), false (non-interrupting)

Тип	Прерывающий (`cancelActivity="true"`)	Non-interrupting (`cancelActivity="false"`)
Timer	Останавливает активность по таймауту. Пример: SLA превышен → переход в escalation	Позволяет активности продолжать работу, но запускает параллельную ветку. Пример: напоминание каждые 24ч
Message	Реагирует на входящее сообщение (напр., «отмена заявки») и останавливает активность	Реагирует на сообщение, не останавливая основную работу. Пример: уведомление о статусе
Error	Перехватывает `errorEndEvent` или исключение из вызова сервиса	Не поддерживается для error. Error — всегда interrupting
Escalation	Перехватывает `escalationThrow/EndEvent`	Поддерживается. Запускает обработку, активность продолжает выполнение
Signal	Реагирует на сигнал	Поддерживается. Часто используется для broadcast-управления (pause/resume)
Compensation	Только non-interrupting. `cancelActivity` игнорируется. Всегда вызывается при компенсации	—

Boundary Event не может быть стартовым или конечным — только промежуточным.
Один элемент активности может иметь множество boundary events разных типов.

2. Activities (Действия)

Activity — элемент, потребляющий время и/или ресурсы. В BPMN все действия прямоугольные. Углы определяют тип:

Прямые углы — Task (атомарное действие)
Скошенные углы — Sub-Process (группа действий)
Двойная обводка — Transaction или Call Activity (зависимо от контекста)

Действия делятся на:

Task — неделимая работа
Sub-Process — составное действие, разворачиваемое в диаграмме или свёрнутое
Call Activity — вызов глобального процесса или глобального подпроцесса по ссылке

Общие атрибуты всех bpmn:activity:

id — уникальный идентификатор в области видимости (обязательный)
name — человекочитаемое имя (необязательный, но рекомендован)
isForCompensation — true, если действие участвует в компенсации (например, откатывает изменения при ошибке)
startQuantity, completionQuantity — устаревшие, не используются в BPMN 2.0 (игнорируются движками)
default — ссылка на исходящий sequence flow по умолчанию (если условия на других потоках не выполнились)
ioSpecification — декларация входных/выходных данных (см. ниже)
dataInputAssociation, dataOutputAssociation — маппинг данных между окружением и задачей
property — локальные переменные активности (внутреннее состояние)
extensionElements — расширения (движко-специфичные параметры, например, camunda:asyncBefore, flowable:candidateUsers)

2.1 Task (Задача)

bpmn:task — базовый тип действия. Специализируется через атрибут implementation или через специализированные подтипы.

Тип задачи	BPMN-класс	Иконка	Семантика	Ключевые атрибуты	Допустимые значения / примечания
None Task	`bpmn:task`	отсутствует	Абстрактное действие, не имеющее специфики реализации	—	Используется на ранних этапах моделирования. В исполнимой модели заменяется на конкретный тип
Service Task	`bpmn:serviceTask`	шестерёнка	Автоматическое выполнение через внешний сервис	`implementation`, `operationRef`, `resultVariable`, `expression`, `class`, `delegateExpression`, `type`	`implementation`: – `"##WebService"` — вызов SOAP/WSDL-операции (`operationRef` обязателен) – `"##unspecified"` — вызов по контракту (рекомендуется указать `operationRef`) – `"other"` — кастомная реализация (движко-зависимо) `class` — полное имя Java-класса (Camunda, Flowable) `expression` — выражение (JUEL, FEEL), возвращающее результат `resultVariable` — имя переменной, куда сохранить результат
User Task	`bpmn:userTask`	силуэт человека	Работа, выполняемая человеком через UI	`implementation`, `renderer`, `candidateUsers`, `candidateGroups`, `assignee`, `priority`, `dueDate`, `formKey`	`implementation`: – `"##unspecified"` (по умолчанию) – `"##taskForm"` — форма встроенная в движок `assignee` — конкретный исполнитель (строка, может быть выражением `${manager}`) `candidateUsers`, `candidateGroups` — списки потенциальных исполнителей (через запятую или выражение) `formKey` — идентификатор формы (URL, BPMN ID, шаблон) `priority` — целое число (1–100, зависит от движка) `dueDate` — ISO 8601 или выражение `${now() + PT24H}`
Script Task	`bpmn:scriptTask`	«`<>`» (скобки)	Выполнение скрипта внутри движка	`script`, `scriptFormat`, `resultVariable`	`scriptFormat`: – `"http://www.java.com/java"` (Groovy, если движок поддерживает) – `"http://www.groovy.org/groovy"` – `"http://www.ecmascript.org"` (JavaScript, напр., Nashorn) – `"FEEL"` (Friendly Enough Expression Language — DMN-совместимый) `script` — тело скрипта (в XML CDATA или атрибуте) `resultVariable` — имя переменной результата, если скрипт возвращает значение
Send Task	`bpmn:sendTask`	конверт с «→»	Отправка сообщения без ожидания ответа	`implementation`, `messageRef`, `operationRef`	Аналог `messageIntermediateThrowEvent`, но в форме задачи. Может иметь `inputSet` для данных сообщения. Не блокирует поток — завершается сразу после отправки
Receive Task	`bpmn:receiveTask`	конверт с «←»	Ожидание входящего сообщения до продолжения	`messageRef`, `instantiate`, `operationRef`	Блокирует поток до получения сообщения через correlation. `instantiate="true"` — может инициировать процесс (устаревшее, лучше использовать message start). Часто заменяется `messageIntermediateCatchEvent`
Manual Task	`bpmn:manualTask`	рука с «+»	Работа, выполняемая вручную вне ИТ-системы	—	Нет автоматизации. Просто маркер для документирования офлайн-операций (напр., «подписать бумажный документ»). Не создаёт задач в UI
Business Rule Task	`bpmn:businessRuleTask`	ромб с «шестерёнкой»	Применение правил (правил принятия решений)	`implementation`, `resultVariable`, `ruleFlowGroup`, `decisionRef`, `decisionRefBinding`, `mapDecisionResult`	`implementation`: – `"##DRL"` — Drools Rule Language (jBPM) – `"##DMN"` — вызов DMN-решения (рекомендуется) `decisionRef` — ID `bpmn:decision` (DMN) `decisionRefBinding` — `"latest"`, `"deployment"`, `"version"` `mapDecisionResult` — `"resultList"`, `"singleEntry"`, `"singleResult"` (Camunda)
Decision Task	—	—	Не существует как отдельный тип. Реализуется через `businessRuleTask` с `implementation="##DMN"`	—	В BPMN 2.0 Decision Task — не самостоятельный элемент. Диаграммы решений (DMN) вызываются из `businessRuleTask` или через `callActivity` к `bpmn:decisionTask` (но `decisionTask` — устаревшее понятие, не входит в BPMN 2.0)

2.2 Sub-Process (Подпроцесс)

Группирует действия. Имеет собственное пространство имён, переменные, события.

Общие атрибуты bpmn:subProcess:

triggeredByEvent — true, если это Event Sub-Process (срабатывает от события, а не по sequence flow)
completionCondition — выражение для завершения мультиинстанса (см. ниже)

Типы Sub-Process:

Тип	BPMN-класс	Обводка	Семантика	Особенности
Embedded Sub-Process	`bpmn:subProcess`	Прямая линия	Раскрывается в том же пуле, имеет вход/выход через sequence flow	Содержит свои элементы. Может иметь boundary events. Внутренние потоки не выходят за границы без explicit end/start
Event Sub-Process	`bpmn:subProcess` + `triggeredByEvent="true"`	Прямая линия, без входящего sequence flow	Активируется при срабатывании стартового события внутри него	Обязательно содержит один start event (non-interrupting или interrupting). Может быть attached как к process, так и к activity. Если attached к activity — является non-interrupting по умолчанию, но может быть interrupting, если start event interrupting
Transactional Sub-Process	`bpmn:transaction`	Двойная линия	Гарантирует ACID-подобную семантику: все действия — или завершены успешно, или откачены	Может содержать только `bpmn:activity`, `sequenceFlow`, `boundaryEvent`. Запрещены: gateways, events, call activities. Завершается через: none end → фиксация, error/cancel end → откат
Ad-Hoc Sub-Process	`bpmn:adHocSubProcess`	Прямая линия + надпись «Ad Hoc»	Порядок выполнения действий не фиксирован — определяется во время выполнения	Атрибуты: `ordering` — `"Parallel"` (по умолчанию), `"Sequential"` `completionCondition` — выражение, при котором подпроцесс завершается `cancelRemainingInstances` — `true` (останавливать оставшиеся при выполнении условия)

2.3 Call Activity (Вызов активности)

bpmn:callActivity — ссылка на глобальный элемент. Двойная обводка.

Атрибут	Назначение	Возможные значения
`calledElement`	Ссылка на `bpmn:process` или `bpmn:callableElement` (глобальный подпроцесс)	ID процесса/подпроцесса (например, `"Process_ApplicationReview"`)
`calledElementBinding`	Версия вызываемого элемента	`"latest"` (по умолчанию), `"deployment"`, `"version"`, `"versionTag"`
`calledElementVersion`	Конкретная версия (число)	Целое число (если поддерживается движком)
`calledElementVersionTag`	Тег версии	Строка (напр., `"stable"`, `"v2.1"`)
`inheritBusinessKey`	Наследовать businessKey родителя	`true`/`false` (Camunda)
`caseRef`, `caseBinding`, `caseVersion`	Вызов CMMN-кейса (если движок поддерживает CMMN)	Аналогично `calledElement*`

Call Activity синхронный: поток ожидает завершения вызванного процесса.
Вход/выход данных — через dataInputAssociation / dataOutputAssociation к ioSpecification вызываемого процесса.

2.4 Параметризация данных в действиях

`ioSpecification` (Input/Output Specification)

Декларирует, какие данные принимает/возвращает действие.

dataInput — входной параметр
- id, name, isCollection, itemSubjectRef (ссылка на bpmn:itemDefinition)
dataOutput — выходной параметр
- аналогично
inputSet, outputSet — группировка данных (редко используется)

Пример:

<ioSpecification>
  <dataInput id="di_applicant" name="applicant" itemSubjectRef="Item_Applicant"/>
  <dataOutput id="do_decision" name="approvalResult" itemSubjectRef="Item_Boolean"/>
  <inputSet>
    <dataInputRefs>di_applicant</dataInputRefs>
  </inputSet>
  <outputSet>
    <dataOutputRefs>do_decision</dataOutputRefs>
  </outputSet>
</ioSpecification>

`dataInputAssociation` / `dataOutputAssociation`

Связывают внешние данные (переменные процесса) с dataInput/dataOutput.

sourceRef — переменная/выражение (для input — источник; для output — цель)
targetRef — dataInput или dataOutput
assignment — маппинг полей (если структуры)

Пример маппинга:

<dataInputAssociation>
  <sourceRef>processApplicant</sourceRef>
  <targetRef>di_applicant</targetRef>
  <assignment>
    <from>${processApplicant.name}</from>
    <to>${di_applicant.fullName}</to>
  </assignment>
</dataInputAssociation>

`property`

Локальные переменные действия (не видны за пределами).
Используются для временных расчётов.

<property id="prop_tempScore" name="score" itemSubjectRef="Item_Integer"/>

Доступ в скриптах/выражениях: ${score} или execution.setVariableLocal("score", 90).

2.5 Multi-Instance (Множественное выполнение)

Любое действие может быть выполнено n раз — параллельно или последовательно.

Активируется через multiInstanceLoopCharacteristics.

Атрибут	Назначение	Допустимые значения
`isSequential`	Последовательное выполнение	`true` / `false`
`loopCardinality`	Количество итераций	Выражение: `${users.size()}` или число `5`
`loopDataInputRef`	Коллекция для итерации	Переменная-список: `users`
`loopDataOutputRef`	Результирующая коллекция	Переменная: `results`
`inputDataItem`	Переменная текущего элемента	`user` (внутри итерации — `${user.name}`)
`outputDataItem`	Результат текущей итерации	`result` (добавляется в `loopDataOutputRef`)
`completionCondition`	Условие досрочного завершения	`${nrOfCompletedInstances >= 3}` или `${someResult == true}`

Пример: User Task «Утвердить» → 3 менеджера утверждают параллельно.
isSequential="false", loopDataInputRef="approvers", inputDataItem="approver", completionCondition="${nrOfCompletedInstances/nrOfInstances >= 0.67}" (2 из 3).

Встроенные переменные в multi-instance:

nrOfInstances — общее количество
nrOfActiveInstances — активные сейчас
nrOfCompletedInstances — завершённые
nrOfTerminatedInstances — прерванные

3. Connecting Objects (Соединяющие объекты)

3.1 Sequence Flow (`bpmn:sequenceFlow`)

Определяет порядок выполнения внутри одного пула (process или participant). Представляет поток управления (control flow) или поток объектов (object flow), хотя объектные потоки редко используются в исполнимых моделях.

Обязательные атрибуты:

id — уникальный идентификатор
sourceRef — ссылка на элемент-источник (должен быть Flow Object или Activity)
targetRef — ссылка на элемент-назначение (должен быть Flow Object или Activity)

Опциональные атрибуты:

Атрибут	Назначение	Значения / примечания
`name`	Человекочитаемая метка на линии	Отображается на диаграмме. Может быть пустой.
`conditionExpression`	Условие перехода	Выражение в поддерживаемом языке (FEEL, JUEL, XPath). Пример: `${score >= 75}`. Тип выражения указывается через `language`: – `http://www.omg.org/spec/FEEL/20140401` – `http://www.jboss.org/jbpm/expressions` – `http://www.w3.org/1999/XPath`
`isImmediate`	Немедленное выполнение без оценки условий	`true` / `false`. Устаревшее. Проигнорировано большинством движков.
`default`	Признак default-перехода	Должен быть `true` только у одного исходящего sequence flow у шлюза или задачи. Срабатывает, если ни одно другое условие не выполнилось.

Правила использования:

Sequence Flow не может пересекать границы пулов (pools). Внутри lane — разрешён.
Источник — любой Flow Object или Activity, кроме End Event.
Назначение — любой Flow Object или Activity, кроме Start Event.
У шлюза (gateway) все исходящие потоки, кроме одного, должны иметь conditionExpression, либо один — default="true".
У задачи (task) может быть несколько исходящих потоков. В этом случае все, кроме одного, должны иметь условия или один — default.

Специальные случаи:

Implicit Join — несколько входящих sequence flow в элемент без шлюза. Означает синхронизацию (AND-join): выполнение начинается только после прибытия всех токенов.
Пример: две параллельные ветки → одна задача. Задача стартует после завершения обеих.
Implicit Split — несколько исходящих sequence flow из элемента без шлюза. Означает разветвление (AND-split): создаётся по одному токену на каждый поток.
Пример: задача → две задачи параллельно.

⚠️ Неявные split/join не рекомендуются в сложных моделях — лучше использовать явные шлюзы (parallelGateway).

3.2 Message Flow (`bpmn:messageFlow`)

Определяет обмен сообщениями между разными пулами (participants) или между пулом и внешней сущностью (data store, participant в collaboration).

Обязательные атрибуты:

id
sourceRef — элемент в одном пуле (должен быть Flow Object или Activity, способный отправлять сообщение: send task, message throw, message intermediate, message end)
targetRef — элемент в другом пуле (должен быть способен принимать: receive task, message catch, message start)

Опциональные атрибуты:

Атрибут	Назначение
`name`	Подпись на линии (например, «Запрос одобрения»)
`messageRef`	Ссылка на `bpmn:message` — описывает структуру данных сообщения

Ограничения:

Message Flow не может начинаться или заканчиваться внутри одного пула.
Message Flow не может соединять Flow Object с Artifact (например, data store) напрямую — требуется промежуточное действие (receive/send task).
Message Flow не управляет порядком выполнения внутри пула — только передаёт сигнал/данные. Внутри пула дальнейшее поведение определяется sequence flow.

Correlation (Корреляция сообщений):

Для сопоставления входящего сообщения с конкретным экземпляром процесса используется correlation key.

В messageEventDefinition или operation указывается correlationKey:

<messageEventDefinition messageRef="Msg_Request">
  <correlationKey name="requestId">
    <correlationPropertyRef>Prop_RequestId</correlationPropertyRef>
  </correlationKey>
</messageEventDefinition>

correlationProperty объявляется на уровне process/collaboration:
```
<correlationProperty id="Prop_RequestId" name="requestId" type="string"/>
```
Значение берётся из переменной процесса или выражения.

Без корреляции движок не сможет определить, какой экземпляр процесса должен обработать сообщение — возможна ошибка или создание нового экземпляра (если start event).

3.3 Association (`bpmn:association`)

Соединяет Flow Object или Activity с Artifact (группа, текстовая аннотация, data store) для пояснения. Не влияет на выполнение.

Атрибуты:

id
sourceRef — любой элемент (включая artifact)
targetRef — любой элемент
associationDirection — направление стрелки:
- None (по умолчанию) — линия без стрелок
- One — стрелка к targetRef
- Both — стрелки в обе стороны

Типичные применения:

Источник	Назначение	Семантика
Task / Event	Text Annotation	Пояснение к действию (например, SLA, примечание по безопасности)
Task	Group	Указание, что действие принадлежит группе (логическая, не исполнительная)
Event	Data Store	Указание, что событие читает/пишет в хранилище (неформально)
Activity	Data Object	Связь с объектом данных (например, «формирует отчёт»)

Association не имеет поведенческой семантики. Не сериализуется в execution context. Используется только для документирования.

4. Swimlanes (Дорожки)

Swimlanes организуют ответственность — кто выполняет действие. Два типа: Pool и Lane.

4.1 Pool (`bpmn:participant` в collaboration / `bpmn:process` в standalone diagram)

Представляет отдельный участника взаимодействия (организацию, систему, роль).
В collaboration diagram — прямоугольник с именем наверху. Может содержать внутреннюю диаграмму (expanded) или быть свёрнутым (collapsed).
В standalone process — не отображается явно (подразумевается один pool).

Атрибуты `bpmn:participant`:

Атрибут	Назначение
`id`	Уникальный идентификатор участника
`name`	Имя (напр., «Служба безопасности»)
`processRef`	Ссылка на `bpmn:process`, реализующий поведение пула
`multiplicity`	Мин/макс количество экземпляров (`minimum`, `maximum`) — устаревшее, почти не поддерживается
`interfaceRef`	Ссылка на `bpmn:interface` (для описания контракта взаимодействия)

Collaboration (`bpmn:collaboration`)

Контейнер для нескольких participant и messageFlow.

Должен быть ровно один collaboration на файл BPMN, если есть взаимодействие.
Атрибуты: id, name, isClosed (публичный интерфейс или внутренний).

4.2 Lane (`bpmn:lane`)

Дочерний элемент bpmn:laneSet → bpmn:process или другого lane.

Определяет зону ответственности внутри пула (отдел, роль, система).
Может быть вложенным (многоуровневые дорожки).

Атрибуты:

Атрибут	Назначение
`id`	Уникальный идентификатор
`name`	Имя дорожки (напр., «Аналитик», «СУБД»)
`partitionElementRef`	Ссылка на `bpmn:resourceRole` или `bpmn:performer` (опционально — для RACI)
`childLaneSet`	Вложенные дорожки

Правила:

Элемент (task, event, sub-process) может принадлежать только одной конечной lane (листе иерархии).
Lane не влияет на выполнение — только визуальная/организационная группировка.
В движках lane может использоваться для маршрутизации задач (например, candidateGroups = имя lane).

5. Artifacts (Артефакты)

Элементы, не влияющие на поток выполнения, но дополняющие модель информацией.

5.1 Group (`bpmn:group`)

Визуальная рамка (пунктирная, с закруглёнными углами).
Объединяет элементы по смыслу (не по ответственности — для этого lane).
Атрибуты: id, name, categoryValueRef (для кастомной классификации).
Примеры использования: «Этап проверки», «Блок с повышенными рисками».

5.2 Text Annotation (`bpmn:textAnnotation`)

Блок текста, прикреплённый через association.
Содержит text (CDATA, поддерживает переносы).
Часто используется для:
- описания бизнес-правил,
- указания SLA,
- ссылок на нормативные документы,
- пояснения неочевидных решений.

5.3 Data Object (`bpmn:dataObjectReference`) и Data Store (`bpmn:dataStoreReference`)

Артефакт	Визуал	Семантика	Ключевые атрибуты
Data Object	Прямоугольник с «бумагой» и загнутым углом	Данные, создаваемые/изменяемые в рамках одного экземпляра процесса	`id`, `name`, `itemSubjectRef` (тип), `isCollection`
Data Store	Цилиндр	Постоянное хранилище, общее для всех экземпляров (БД, файловый сервер)	`id`, `name`, `capacity`, `isUnlimited`

Оба могут иметь dataState — «состояние» объекта (например, «черновик», «утверждено»), но это редко поддерживается движками.

6. Choreography Diagram (Хореография)

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

Основной элемент — bpmn:choreographyActivity, объединяющий отправку и приём в одном шаге.

6.1 Choreography Task (`bpmn:choreographyTask`)

Прямоугольник с двойной вертикальной линией по центру. Обозначает один акт обмена: один участник отправляет, другой(ие) получают.

Атрибуты:

Атрибут	Назначение	Примечания
`initiatingParticipantRef`	Участник, инициирующий обмен	Обязательный. Должен быть одним из `participantRef`
`participantRef`	Список участников, участвующих в обмене	Минимум два: инициатор + как минимум один получатель
`messageFlowRef`	Ссылки на `bpmn:messageFlow` внутри choreography	Должны соответствовать направлению: от `initiating` к другим

Пример:

[Клиент] ———→ [Система]
initiatingParticipantRef = "Participant_Client"
participantRef = ["Participant_Client", "Participant_System"]

Семантика: Клиент отправляет запрос Системе.

Внутри choreography diagram запрещены:

sequence flow,

gateways,

события,

sub-processes. Только choreography tasks и choreography sub-processes, соединённые choreography flows.

6.2 Sub-Choreography (`bpmn:subChoreography`)

Группирует choreography tasks. Визуально — прямоугольник со скошенными углами и двойной линией слева.

Может быть раскрыт (expanded) или свёрнут (collapsed).
Имеет собственные participantRef.
Поддерживает вложенность.

6.3 Choreography Flow (`bpmn:choreographyActivity` → `bpmn:choreographyActivity`)

Сплошная стрелка с ромбом у начала (не путать с sequence flow).
Обозначает порядок выполнения актов обмена.

Источник и цель — только choreography activity.
Не может пересекать границы пулов (в choreography пулы отсутствуют — участники объявлены в collaboration).

6.4 Call Choreography (`bpmn:callChoreography`)

Вызов глобально определённой choreography по ссылке (calledChoreographyRef).
Аналог callActivity, но для хореографий.

7. Conversation Diagram (Диаграмма бесед)

Уровень агрегации выше choreography — фокус на бизнес-взаимодействиях, а не технических сообщениях.

Элементы:

bpmn:conversationNode — узел взаимодействия (округлый прямоугольник)
bpmn:callConversation — вызов глобальной conversation
bpmn:subConversation — вложенная беседа
bpmn:conversationLink — связь между узлами (стрелка с пунктиром)

Атрибуты `conversationNode`:

participantRef — участники взаимодействия
messageFlowRef — связанные message flows (необязательно)
correlationKeyRef — ключ корреляции

Семантика: «Юрлицо подаёт заявку» — это conversation node, включающий несколько сообщений (запрос, подтверждение, документы).

Conversation Diagram не предназначен для исполнения. Используется для архитектурного моделирования и согласования между доменами.

8. Extensibility Mechanisms (Механизмы расширения)

BPMN 2.0 предоставляет стандартные способы расширения без нарушения валидности модели.

8.1 Extension Elements (`bpmn:extensionElements`)

Контейнер для кастомных элементов. Располагается внутри любого BPMN-элемента.

Структура:

<serviceTask id="Task_1" name="Validate">
  <extensionElements>
    <my:custom xmlns:my="http://example.com/bpmn-ext">
      <my:timeout unit="seconds">30</my:timeout>
      <my:retry max="3" delay="PT5S"/>
    </my:custom>
    <!-- Camunda-специфичное -->
    <camunda:failedJobRetryTimeCycle xmlns:camunda="http://camunda.org/schema/1.0/bpmn">
      R3/PT1M
    </camunda:failedJobRetryTimeCycle>
  </extensionElements>
</serviceTask>

Правила:

Расширения не влияют на стандартную семантику BPMN.
Движок может игнорировать неизвестные расширения.
Рекомендуется использовать уникальные XML-namespace.

8.2 Extension Attributes

Произвольные атрибуты с префиксом, зарегистрированным в namespace.

Пример:

<userTask id="Task_Approve"
          camunda:assignee="manager"
          flowable:dueDate="${now() + P2D}"
          my:slaLevel="premium" />

8.3 Custom Tasks через `implementation`

Для serviceTask, businessRuleTask и др. можно указать:

<serviceTask implementation="com.example.MyCustomHandler" />

Движок вызывает обработчик по классу или имени, зарегистрированному в реестре.

8.4 Global Definitions (Глобальные объявления)

Общие сущности, используемые в нескольких местах:

Элемент	Назначение	Контейнер
`bpmn:itemDefinition`	Тип данных (структура)	`definitions`
`bpmn:message`	Сообщение (имя + `itemRef`)	`definitions`
`bpmn:signal`	Глобальный сигнал (имя)	`definitions`
`bpmn:escalation`	Эскалация (код + `structureRef`)	`definitions`
`bpmn:error`	Ошибка (код + `errorCode` + `structureRef`)	`definitions`
`bpmn:interface` / `bpmn:operation`	Контракт вызова сервиса	`definitions`
`bpmn:resource` / `bpmn:resourceParameter`	Ресурс и его параметры (не путать с lane)	`definitions`

Пример itemDefinition:

<itemDefinition id="Item_Applicant" structureRef="tns:ApplicantType" />
<itemDefinition id="Item_Boolean" isCollection="false" structureRef="xsd:boolean" />

structureRef может ссылаться на:

XSD-тип (xsd:string),
XML-схему (tns:ApplicantType),
Java-класс (движко-зависимо, например, java.lang.String).

9. Execution Semantics (Семантика выполнения)

Краткий справочник по тому, как BPMN-модель интерпретируется во время исполнения.

9.1 Token Semantics (Семантика токенов)

Выполнение моделируется продвижением токенов по sequence flow.
Токен — лёгкая сущность, представляющая единицу работы.
Условия оцениваются при прибытии токена к шлюзу.
AND-разветвление (parallelGateway) клонирует токен.
XOR-слияние (exclusiveGateway) поглощает один токен (остальные уничтожаются).
OR-слияние (inclusiveGateway) ждёт все прибывшие токены, соответствующие условию входа.

9.2 Состояния экземпляра процесса

Состояние	Условие перехода
`ACTIVE`	Экземпляр создан, есть хотя бы один активный токен
`COMPLETED`	Все токены достигли end event, нет активных задач/таймеров
`TERMINATED`	Выполнен `terminateEndEvent` или вызван `terminate()` API
`SUSPENDED`	Вызван `suspend()` — приостановка вручную или по условию
`ABORTED` / `FAILED`	Ошибка, не перехваченная boundary error event

9.3 Жизненный цикл задачи (User Task)

CREATE — задача создана
ASSIGN — назначена исполнителю
COMPLETE — исполнена (переменные обновлены, токен движется дальше)
DELETE — отменена/удалена (напр., при компенсации)

Дополнительные события (движко-зависимо):

UPDATE, TIMEOUT, ESCALATION

9.4 Transaction и компенсация

В transaction подпроцессе все действия выполняются в рамках логической транзакции.
Если срабатывает errorEndEvent или cancelEndEvent:
1. Все активные задачи внутри отменяются.
2. Выполняются компенсационные обработчики (compensateEventDefinition в boundary events активностей с isForCompensation="true").
3. Управление передаётся на cancelBoundaryEvent родителя.

Компенсация — не откат, а выполнение бизнес-логики отмены (напр., «отозвать начисление», «удалить временный файл»).

10. Best Practices для исполнимых BPMN-моделей

10.1 Валидность и соответствие

Используйте валидаторы (Camunda Modeler, bpmnlint).
Все messageRef, signalRef, errorRef должны иметь соответствующие глобальные объявления.
У исключающего шлюза (exclusiveGateway) должен быть один default flow или все исходящие — с условиями.

10.2 Именование

id: CamelCase с префиксом типа — Task_Validate, Gateway_SplitRisk, Event_Timer_SLA
name: человекочитаемо, глагол + объект — «Проверить кредитную историю», «Дождаться ответа МСК»
Переменные: camelCase — applicantData, approvalThreshold

10.3 Инкапсуляция

Логика принятия решений — в DMN, вызываемом через businessRuleTask.
Сложная обработка — в serviceTask с ссылкой на внешний микросервис или скрипт.
Повторяющиеся фрагменты — в callActivity к глобальным подпроцессам.

10.4 Обработка ошибок

Каждый serviceTask, вызывающий внешний сервис, должен иметь boundaryErrorEvent.
Используйте escalation для бизнес-исключений («клиент не найден»), error — для системных («таймаут соединения»).
Ограничьте глубину вложенности подпроцессов (рекомендуется ≤ 3).

10.5 Производительность

Избегайте conditionalEvent — он создаёт polling-нагрузку.
Для множественных задач используйте multiInstance, а не ручное клонирование.
Асинхронное выполнение (asyncBefore="true") для долгих операций — предотвращает блокировку транзакции БД.

Справочник по BPMN 2.0​

1. Flow Objects (Объекты потока)​

1.1 Events (События)​

Особые события: Boundary Events (Прикреплённые)​

2. Activities (Действия)​

2.1 Task (Задача)​

2.2 Sub-Process (Подпроцесс)​

Типы Sub-Process:​

2.3 Call Activity (Вызов активности)​

2.4 Параметризация данных в действиях​

ioSpecification (Input/Output Specification)​

dataInputAssociation / dataOutputAssociation​

property​

2.5 Multi-Instance (Множественное выполнение)​

3. Connecting Objects (Соединяющие объекты)​

3.1 Sequence Flow (bpmn:sequenceFlow)​

Обязательные атрибуты:​

Опциональные атрибуты:​

Правила использования:​

Специальные случаи:​

3.2 Message Flow (bpmn:messageFlow)​

Обязательные атрибуты:​

Опциональные атрибуты:​

Ограничения:​

Correlation (Корреляция сообщений):​

3.3 Association (bpmn:association)​

Атрибуты:​

Типичные применения:​

4. Swimlanes (Дорожки)​

4.1 Pool (bpmn:participant в collaboration / bpmn:process в standalone diagram)​

Атрибуты bpmn:participant:​

Collaboration (bpmn:collaboration)​

4.2 Lane (bpmn:lane)​

Атрибуты:​

Правила:​

5. Artifacts (Артефакты)​

5.1 Group (bpmn:group)​

5.2 Text Annotation (bpmn:textAnnotation)​

5.3 Data Object (bpmn:dataObjectReference) и Data Store (bpmn:dataStoreReference)​

6. Choreography Diagram (Хореография)​

6.1 Choreography Task (bpmn:choreographyTask)​

Атрибуты:​

Пример:​

6.2 Sub-Choreography (bpmn:subChoreography)​

6.3 Choreography Flow (bpmn:choreographyActivity → bpmn:choreographyActivity)​

6.4 Call Choreography (bpmn:callChoreography)​

7. Conversation Diagram (Диаграмма бесед)​

Атрибуты conversationNode:​

8. Extensibility Mechanisms (Механизмы расширения)​

8.1 Extension Elements (bpmn:extensionElements)​

8.2 Extension Attributes​

8.3 Custom Tasks через implementation​

8.4 Global Definitions (Глобальные объявления)​

9. Execution Semantics (Семантика выполнения)​

9.1 Token Semantics (Семантика токенов)​

9.2 Состояния экземпляра процесса​

9.3 Жизненный цикл задачи (User Task)​

9.4 Transaction и компенсация​

10. Best Practices для исполнимых BPMN-моделей​

10.1 Валидность и соответствие​

10.2 Именование​

10.3 Инкапсуляция​

10.4 Обработка ошибок​

10.5 Производительность​

Справочник по BPMN 2.0

1. Flow Objects (Объекты потока)

1.1 Events (События)

Особые события: Boundary Events (Прикреплённые)

2. Activities (Действия)

2.1 Task (Задача)

2.2 Sub-Process (Подпроцесс)

Типы Sub-Process:

2.3 Call Activity (Вызов активности)

2.4 Параметризация данных в действиях

`ioSpecification` (Input/Output Specification)

`dataInputAssociation` / `dataOutputAssociation`

`property`

2.5 Multi-Instance (Множественное выполнение)

3. Connecting Objects (Соединяющие объекты)

3.1 Sequence Flow (`bpmn:sequenceFlow`)

Обязательные атрибуты:

Опциональные атрибуты:

Правила использования:

Специальные случаи:

3.2 Message Flow (`bpmn:messageFlow`)

Обязательные атрибуты:

Опциональные атрибуты:

Ограничения:

Correlation (Корреляция сообщений):

3.3 Association (`bpmn:association`)

Атрибуты:

Типичные применения:

4. Swimlanes (Дорожки)

4.1 Pool (`bpmn:participant` в collaboration / `bpmn:process` в standalone diagram)

Атрибуты `bpmn:participant`:

Collaboration (`bpmn:collaboration`)

4.2 Lane (`bpmn:lane`)

Атрибуты:

Правила:

5. Artifacts (Артефакты)

5.1 Group (`bpmn:group`)

5.2 Text Annotation (`bpmn:textAnnotation`)

5.3 Data Object (`bpmn:dataObjectReference`) и Data Store (`bpmn:dataStoreReference`)

6. Choreography Diagram (Хореография)

6.1 Choreography Task (`bpmn:choreographyTask`)

Атрибуты:

Пример:

6.2 Sub-Choreography (`bpmn:subChoreography`)

6.3 Choreography Flow (`bpmn:choreographyActivity` → `bpmn:choreographyActivity`)

6.4 Call Choreography (`bpmn:callChoreography`)

7. Conversation Diagram (Диаграмма бесед)

Атрибуты `conversationNode`:

8. Extensibility Mechanisms (Механизмы расширения)

8.1 Extension Elements (`bpmn:extensionElements`)

8.2 Extension Attributes

8.3 Custom Tasks через `implementation`

8.4 Global Definitions (Глобальные объявления)

9. Execution Semantics (Семантика выполнения)

9.1 Token Semantics (Семантика токенов)

9.2 Состояния экземпляра процесса

9.3 Жизненный цикл задачи (User Task)

9.4 Transaction и компенсация

10. Best Practices для исполнимых BPMN-моделей

10.1 Валидность и соответствие

10.2 Именование

10.3 Инкапсуляция

10.4 Обработка ошибок

10.5 Производительность