События ошибки bpmn

In process automation, you often encounter deviations from the default scenario. One way to resolve these deviations is using a BPMN error event, which allows a process model to react to errors within a task.

For example, if an invalid credit card is used in the process below, the process takes a different path than usual and uses the default payment method to collect money.

Defining the error​

In BPMN, errors define possible errors that can occur. Error events are elements in the process referring to
defined errors. An error can be referenced by one or more error events.

An error must define an errorCode (e.g. InvalidCreditCard). The errorCode is a string used to match a thrown
error to the error catch events.

For throwing error events, it is possible to define the errorCode as an expression. When the event is reached,
the expression is evaluated. An error with the result of this expression is thrown. If no expression is used the
statically defined errorCode is used.

For error catch events, the errorCode can be a static value or it can be left empty. An expression can’t be used. A
catch event with an empty errorCode will catch all thrown errors.

Throwing the error​

An error can be thrown within the process using an error end event.

Alternatively, you can inform Zeebe that a business error occurred using a client command. This throw error client
command can only be used while processing a job.

In addition to throwing the error, this also disables the job and stops it from being activated or completed by other job workers. See the gRPC command for details.

Catching the error​

A thrown error can be caught by an error catch event, specifically using an error boundary event or an error event
subprocess.

Starting at the scope where the error was thrown, the error code is matched against the attached error boundary events
and error event sub processes at that level. An error is caught by the first event in the scope hierarchy matching the
error code. At each scope, the error is either caught, or propagated to the parent scope.

If the process instance is created via call activity, the error can also be caught in the calling parent process
instance.

It is not possible to define multiple error catch events with the same errorCode in a single scope. It is also not
permitted to have multiple error catch events without an errorCode in a single scope. The deployment gets rejected in
these cases. However, it is possible to define both an error catch event with an errorCode and one without an
errorCode in the same scope. When this happens, the error catch event that matches the errorCode is prioritized.

Error boundary events and error event subprocesses must be interrupting. This means the process instance will not
continue along the regular path, but instead follow the path that leads out of the catching error event.

If the error is thrown for a job, the associated task is terminated first. To continue the execution, the error boundary
event or error event subprocess that caught the error is activated.

Unhandled errors​

When an error is thrown and not caught, an incident (i.e. Unhandled error event) is raised to indicate the failure. The incident is attached to the corresponding element where the error was thrown (i.e. the task of the processed job or the error end event).

When you resolve the incident attached to a task, it ignores the error, re-enables the job, and allows it to be activated and completed by a job worker once again.

The incident attached to an error end event cannot be resolved by a user because the failure is in the process itself. The process cannot be changed to catch the error for this process instance.

Business error vs. technical error​

In real life, you’ll also have to deal with technical problems that you don’t want to treat using error events.

Suppose the credit card service becomes temporarily unavailable. You don’t want to model the retrying, as you would have to add it to each and every service task. This will bloat the visual model and confuse business personnel. Instead, either retry or fall back to incidents as described above. This is hidden in the visual.

In this context, we found the terms business error and technical error can be confusing, as they emphasize the source of the error too much. This can lead to long discussions about whether a certain problem is technical or not, and if you are allowed to see technical errors in a business process model.

It’s much more important to look at how you react to certain errors. Even a technical problem can qualify for a business reaction. For example, you could decide to continue a process in the event that a scoring service is not available, and simply give every customer a good rating instead of blocking progress. The error is clearly technical, but the reaction is a business decision.

In general, we recommend talking about business reactions, which are modeled in your process, and technical reactions, which are handled generically using retries or incidents.

Variable mappings​

All error variables are merged into the error catch event. These variables can be merged into the process instance by defining an output mapping at the error catch event.

Visit the documentation regarding variable mappings for more information.

Additional resources​

XML representation​

A boundary error event:

<bpmn:error id="invalid-credit-card-error" errorCode="Invalid Credit Card" />

<bpmn:boundaryEvent id="invalid-credit-card-1" name="Invalid Credit Card" attachedToRef="collect-money">
 <bpmn:errorEventDefinition errorRef="invalid-credit-card-error" />
</bpmn:boundaryEvent>

A boundary error event without errorCode:

<bpmn:boundaryEvent id="invalid-credit-card-2" name="Unknown Error" attachedToRef="collect-money">
  <bpmn:errorEventDefinition id="catch-all-errors"/>
</bpmn:boundaryEvent>

References​

• Incidents

Error events are events which are triggered by a defined error.

Business Errors vs. Technical Errors

A BPMN error is meant for business errors — which are different than technical exceptions. So, this is different than Java exceptions — which are, by default, handled in their own way.

You might also want to check out the basics of Threading and Transactions in the User Guide first.

Defining an Error

An error event definition references an error element. The following is an example of an error end event, referencing an error declaration:

<definitions>
  <error id="myError" errorCode="ERROR-OCCURED" name="ERROR-OCCURED"/>
  <!-- ... -->
  <process>
    <!-- ... -->
    <endEvent id="myErrorEndEvent">
      <errorEventDefinition errorRef="myError" />
    </endEvent>
  </process>
</definitions>

You can trigger this error event either with a throwing error event within your process definition or from Delegation Code, see the
Throwing BPMN Errors from Delegation Code section of the User Guide for more information.

Another possibility to define an error is setting of the type (class name) of any Java Exception as error code. Example:

<definitions>
  <error id="myException" errorCode="com.company.MyBusinessException" 
      name="myBusinessException"/>
  <!-- ... -->
  <process>
    <!-- ... -->
    <endEvent id="myErrorEndEvent">
      <errorEventDefinition errorRef="myException" />
    </endEvent>
  </process>
</definitions>

The exception type should only be used for business exceptions and not for technical exceptions in the process.

An error event handler references the same error element to declare that it catches the error.

It is also possible to define an error message with the camunda:errorMessage extension for an error element to give further information about the error.
The referencing error event definition must specify camunda:errorMessageVariable to receive the error message. The error message can also contain expressions.

<definitions>
  <error id="myError" errorCode="ERROR-OCCURED" name="ERROR-OCCURED" 
      camunda:errorMessage="Something went wrong: ${errorCause}" />
  <!-- ... -->
  <process>
    <!-- ... -->
    <endEvent id="myErrorEndEvent">
      <errorEventDefinition errorRef="myError" camunda:errorMessageVariable="err"/>
    </endEvent>
  </process>
</definitions>

When the error thrown by the error end event is catched a process variable with the name err will be created that holds the evaluated message.

For External Tasks, it is also possible to define error events by using a camunda:errorEventDefinition as shown in the following example. It additionally requires an expression that must evaluate to true in order for the BPMN error to be thrown. For further details on how to use those error events, consult the External Tasks Guide.

<serviceTask id="validateAddressTask"
  name="Validate Address"
  camunda:type="external"
  camunda:topic="AddressValidation" >
  <extensionElements>
    <camunda:errorEventDefinition id="addressErrorDefinition" 
      errorRef="addressError" 
      expression="${externalTask.getErrorDetails().contains('address error found')}" />
  </extensionElements>
</serviceTask>

Error Start Event

An error start event can only be used to trigger an Event Sub-Process — it cannot be used to start a process instance. The error start event is always interrupting.

Three optional attributes can be added to the error start event: errorRef, camunda:errorCodeVariable and camunda:errorMessageVariable:

<definitions>
  <error id="myException" errorCode="com.company.MyBusinessException" name="myBusinessException"/>
  ...
  <process>
    ...
    <subProcess id="SubProcess_1" triggeredByEvent="true">>
      <startEvent id="myErrorStartEvent">
        <errorEventDefinition errorRef="myException" camunda:errorCodeVariable="myErrorVariable"
  		  camunda:errorMessageVariable="myErrorMessageVariable" />
      </startEvent>
    ...
    </subProcess>
  ...
  </process>
</definitions>

• If errorRef is omitted, the subprocess will start for every error event that occurs.
• The camunda:errorCodeVariable will contain the error code that was specified with the error.
• The camunda:errorMessageVariable will contain the error message that was specified with the error.

camunda:errorCodeVariable and camunda:errorMessageVariable can be retrieved like any other process variable, but only if the attribute was set.

Error End Event

When process execution arrives at an error end event, the current path of execution is ended and an error is thrown. This error can be caught by a matching intermediate error boundary event. In case no matching error boundary event is found, the execution semantics defaults to the none end event semantics.

Camunda Extensions

Error Event Definition

Error Definition

Error Boundary Event

An intermediate catching error event on the boundary of an activity, or error boundary event for short, catches errors that are thrown within the scope of the activity on which it is defined.

Defining a error boundary event makes most sense on an embedded subprocess, or a call activity, as a subprocess creates a scope for all activities inside the subprocess. Errors are thrown by error end events. Such an error will propagate its parent scopes upwards until a scope is found on which a error boundary event is defined that matches the error event definition.

When an error event is caught, the activity on which the boundary event is defined is destroyed, also destroying all current executions therein (e.g., concurrent activities, nested subprocesses, etc.). Process execution continues following the outgoing sequence flow of the boundary event.

A error boundary event is defined as a typical boundary event. As with the other error events, the errorRef references an error defined outside of the process element:

<definitions>
  <error id="myError" errorCode="ERROR-OCCURED" name="name of error"/>
  <!-- ... -->
  <process>
    <!-- ... -->
    <subProcess id="mySubProcess">
      <!-- ... -->
    </subProcess>
    <boundaryEvent id="catchError" attachedToRef="mySubProcess">
      <errorEventDefinition errorRef="myError" camunda:errorCodeVariable="myErrorVariable"
	    camunda:errorMessageVariable="myErrorMessageVariable" />
    </boundaryEvent>
  </process>
</definitions>

The errorCode is used to match the errors that are caught:

• If errorRef is omitted, the error boundary event will catch any error event, regardless of the errorCode of the error.
• In case an errorRef is provided and it references an existing error, the boundary event will only catch errors with the defined error code.
• If the errorCodeVariable is set, the error code can be retrieved using this variable.
• If the errorMessageVariable is set, the error message can be retrieved using this variable.

Unhandled BPMN Error

It can happen that no catching boundary event was defined for an error event. The default behaviour in this case is to log information and end the current execution.
This behaviour can be changed with enableExceptionsAfterUnhandledBpmnError property set to true
(via the process engine configuration or the deployment descriptor) and Process Engine Exception will be thrown if unhandled BPMN Error occurs.

Catch and Re-Throw Pattern

An error can be handled by the error start event in the event sub process and the same error can be thrown from the event sub process to handle the error on the higher level scope (in the example below, the error thrown from the Event Subprocess is handled by the error boundary event in the Subprocess).

Additional Resources

• Error Events in the BPMN 2.0 Modeling Reference
• Incidents in the User Guide

Ошибки в BPMN допускают многие. Это и понятно — нотация кажется простой и понятной, официальная документация предназначена для программистов, а не людей. Чтобы помогать обычным людям разбираться в BPMN, я провожу онлайн-разборы диаграмм. Люди присылают диаграммы (вы тоже можете), а я рассказываю что с ними не так.

В 2018 году я провёл 10 часов таких разборов. Я пересмотрел все записи и выписал топ-25 ошибок, которые встречались и способы их лечения.

Ошибки в BPMN бывают трех видов:

1. Ошибки формальные — когда диаграмма не соответствует BPMN.
2. Ошибки стиля — когда схема формально правильная, но читать или модифицировать её неудобно. Стилевые предпочтения у всех свои.
3. Ошибки логики — это когда схема правильная, стиль соблюден, но есть проблемы в сути того, что нарисовано.

Формальные ошибки и ошибки стиля исправить легко  — не надо знать предметную область. Ошибки логики исправить сложно, нужно разбираться в каждом отдельном случае.

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

Для тех, кто торопится

Я разработал бесплатный облачный сервис для рисования и обсуждения диаграмм с коллегами, который сам проверяет 80% ошибок. Он очень экономит время и делает обсуждение удобным. Регистрируйтесь!

25. НЕ BPMN (Формальная ошибка BPMN)

В диаграмме использованы символы, которых нет в BPMN. Это символы из Archimate, UML, IDEF и других нотаций.

24-23. Пулы вместо дорожек. Дорожки вместо пулов (стилевая ошибка BPMN)

BPMN предполагает использование пулов для отображения соседнего бизнес-процесса или сущности, на которую мы повлиять не можем (Black box).

А дорожки, наоборот, показывают участников описываемого процесса:

Люди путают их: в дорожках рисуют внешние организации, а собственных сотрудников рисуют в отдельных пулах.

22. Гонка сигналов (Логическая ошибка BPMN)

Изображение взаимодействия процессов, которые могут не выполниться:

Если задача 2 будет выполняться быстрее, чем задача 1, то нижний процесс не сможет отправить сообщение. Это сообщение еще не ждёт верхний процесс.

Вылечить можно так:

Старайтесь избегать таких ситуаций по логике бизнес-процесса.

21. Возврат главного потока назад или вниз (Стилевая ошибка BPMN)

Авторы пытаются вписать процесс змейкой в формат А4.

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

20. Обслуживание “главного” (Логическая ошибка BPMN)

Председатель правления, генеральный директор или еще кто-то “главный” на процессе выступают фигурой, которая сама не участвует в процессе (судя по схеме), а все участники эту фигуру обслуживают. Из-за этого схема становится перегружена этим обслуживаем.

С точки зрения бизнес-процесса “главный” такой же участник, который должен сделать свою часть работы:

19. Всё завершения в одно завершающее событие (Стилевая ошибка BPMN)

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

Разумнее нарисовать схему так:

18. Переход в межпроцессное взаимодействие там, где это не нужно. (Стилевая ошибка BPMN )

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

Такое отображение только усложняет схему и не отличается от такого:

17. Одна задача для множественной обработки (Логическая ошибка BPMN)

В BPMN есть элементы, показывают итерирование по набору сущностей.

Аналитики делают задачу, в названии которой пишут массовую операцию:

Это нормально, но при обработке исключительных случаев ВНУТРИ обработки заказа могут возникнуть проблемы. Поэтому такой квадратик можно развернуть как подпроцесс, работающий по массиву:

16. Инструкция, а не процесс (Логическая ошибка BPMN)

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

Такие задачи можно рисовать одним кубиком:

15. Страх “сложных” символов (Стилевая ошибка BPMN )

Достигнув определённого понимания инструментов и почувствовав в нём уверенность, авторы начинают решать все задачи имеющимися инструментами.

Такие схемы можно отрисовывать, используя богатые возможности BPMN:

14. Использование conditional flow (стилевая ошибка BPMN )

BPMN позволяет на потоки управления навешивать условия.

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

13. Одна развилка для сборка и разведения токенов (стилевая ошибка BPMN)

Нотация настоятельно рекомендует не использовать одну развилку и для сведения и для разведения потоков управления:

Лечится просто:

12. Сверху вниз (стилевая ошибка BPMN)

Известная проблема всех, кто рисовал алгоритмы в институте.

В BPMN схемы моделируются слева направо. Некоторые редакторы, например https://bpmn.io/ не дают размещать пулы или дорожки вертикально.

11. Передать информацию, получить информацию (логическая ошибка BPMN)

Для отображения факта передачи информации не надо ставить задачи:

Сам поток управления и означает факт передачи информации.

Нужно рисовать вот так:

10. Текст вместо символов (стилевая ошибка BPMN)

Много комментариев, которые можно выразить символами BPMN.

Нужно прокачиваться, чтобы лучше знать возможности BPMN.

9. Неверное использование бизнес-правил (стилевая ошибка BPMN)

Символ бизнес-правил напоминает таблицу, поэтому люди вставляют его туда, где предполагается работа с таблицами:

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

8. Разный уровень задач на процессе (логическая ошибка BPMN )

Это ситуация, когда на одной схеме задачи совершенно разного операционного уровня:

Явные правила я пока не придумал, поэтому такие моменты нужно чувствовать.

7.Техника, а не бизнес-процесс (логическая ошибка BPMN)

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

Не вырождайте бизнесовое действие в технологическое, пишите явно что происходит:

6. Много стрелок в\из квадратиков (стилевая ошибка BPMN)

Когда вы вставляете много стрелок в квадратик, вы можете сконфузить читателя  — легко подумать, что 2 стрелки должны прийти вместе:

Используйте развилки для гарантированного и явного описания логики процесса.

5. Не сходятся токены (формальная ошибка BPMN )

Это одна из неявных особенностей BPMN: по схемам движутся токены и их количество меняется в зависимости от пройденных элементов. Нужно уметь в голове проигрывать такие путешествия токенов.

Развилка №2 никогда не пропустит процесс дальше, т.к. ждёт 3 токена на вход (потому что 3 входящих потока), но И/ИЛИ развилка между Task 2 и Task 3 запустит токен только по одному из потоков. Исправляется тем, что мы добавляем исключающую развилку, который “соберёт” токены, перед тем, как их вставить в развилку №2.

4. Перепутаны потоки (формальная ошибка BPMN )

Почему-то коллеги любят сменить в одной дорожке поток управления на поток сообщений, или наоборот:

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

3. Элементы ничем не заканчиваются (стилистическая ошибка BPMN )

BPMN формально разрешает брошенные элементы:

Но это просто отвратительно — у читателя сразу масса вопросов. Где завершение? Забыли нарисовать? Почему есть начало, но нет завершения?

Старайтесь чтобы из задачи всегда был выход.

2. Задачи на клиента (стилистическая ошибка BPMN)

В BPMN есть концепция blackbox — это пул, отражающий сущность, устройство которой мы знать не хотим или не можем. В 99% такой сущностью является клиент. Это значит, что мы не можем поставить клиенту задачу. Мы можем только реагировать на действия (или бездействие) клиента .

Это довольно сильно меняет наш процесс, мы полагаемся только на свои силы и на те вещи, на которые можем влиять:

1. События используются c ошибками(формальная ошибка в BPMN)

Самая частая ошибка, что неудивительно — событий много. Если вы не знаете как работает событие, лучше не используйте его.

События отправки и приема сообщений из-за конвертика воспринимаются как задача нотификации по е-мейлу. А на самом деле — эти символы используются для организации межпроцессного взаимодействия.

В этот пост все события уже не поместятся, ждите следующий.

Заключение

Вышло логично — самые неочевидные вещи с первого взгляда  — самые частые ошибки в BPMN.  Но теперь вы про них знаете и можете избегать в своих схемах.

Напишите в комментарии — какие еще сложности у вас возникают при моделировании в BPMN?  О каких ошибках я забыл?