Граничное событие ошибка 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.

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.

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.

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" name="Invalid Credit Card" attachedToRef="collect-money">
 <bpmn:errorEventDefinition errorRef="invalid-credit-card-error" />
</bpmn:boundaryEvent>

References​

• Incidents

<<предыдущая содержание следующая>>

10.4.6 Обработка Событий

BPMN позволяет использовать продвинутые способы управления Событиями, возникающими в ходе выполнения Процесса (например, обработка имеющегося События). Кроме того, BPMN поддерживает добавление События в Процесс (к примеру, инициирование запуска События). Обработка Событий включает в себя обработку и инициирование Событий, а также достижение результата в ходе выполнения Процесса. Существует три типа обработчиков Событий: обработчики, запускающие Событие, обработчики, входящие в состав Стандартного потока операций, и обработчики, присоединенные к Действию либо через границу События, либо посредством других встроенных обработчиков (в Подпроцессе, работающем с данными).

Обработка Стартовых событий

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

Эксклюзивный запуск Процесса. Большинство общепринятых сценариев запуска Процесса предполагают запуск его экземпляра с помощью одного из возможных Стартовых событий. Всякий раз, когда такое Событие появляется на диаграмме Процесса, формируется новый его экзмепляр. Из приведенных ниже примеров видно, как два События соединены с одним Действием (см. фигуру 10.97). В ходе выполнения Процесс появление любого из этих Событий определяет последующее создание нового экземпляра данного экземпляра Процесса, а также запускает Действие. Обратите внимание, что одиночное Стартовое событие Множественного типа, содержащее значения MessageEventDefinition, будет вести себя также.

Фигура 10.97 – Эксклюзивный запуск Процесса

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

Фигура 10.98 – Процесс, запускаемый с помощью основанного на событиях Шлюза

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

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

Синхронизация Событий. Если разработчику модели требуется объединить в одном Процессе несколько отдельных Стартовых событий, он ДОЛЖЕН отобразить это в соответствии со схемой, приведенной в фигуре 10.99

Фигура 10.99 – Синхронизация Событий при запуске Процесса

Стартовое событие Параллельного Множественного типа МОЖЕТ объединять несколько отдельных Стартовых событий, каждое из которых ДОЛЖНО хотя бы раз происходить для того, чтобы сформировался новый экземпляр Процесса. Потоки операций, отходящие от такого События, имеют стандартное направление. Для получения более подробной информации об обработке Стартовых событий см. раздел 13.4.1.

Обработка Событий Стандартного потока операций (Промежуточных событий)

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

Обработка Событий, присоединенных к границам Действия (Промежуточных событий, сединенных с границей Действия, и Событийных Подпроцессов)

Обработка Промежуточного события, соединенного с границами Действия, заключается в завершении запущенного События и либо отмене выполнения Действия, к которому данное Событие присоединено (как результат от Действия направляется Стандартный поток операций), либо запуске обработчика Событий без отмены выполнения Действия (только для Событий типа Сообщение, Сигнал, таймер, Условие; использование Ошибки запрещено).

Промежуточное Событие, прерывающее Действие, к которому присоединено, определяется посредством установки значения «true» для атрибута cancelActivity. В какой бы момент ни происходило это Событие, выполнение соответствующего ему Действия прерывается. При этом формируется токен, следующий по направлению Потока операций и запускающий следующий элемент Процесса (связанный с Событием с помощью безусловного Потока операций, называемого Потоком исключений).

Промежуточное Событие, не прерывающее Действие, к которому присоединено, определяется посредством установки значения «false» для атрибута cancelActivity. В какой бы момент ни происходило это Событие, выполнение соответствующего ему Действия продолжается. Поскольку параллельно с продолжение выполнения Действия для направленного от События Потока пераций формируется токен, ДОЛЖНО учитываться то, что данный маршрут сливается с основным Потоком операций Процесса. В данном случае токен, как правило, завершается собственным Конечным Событием.

На фигуре 10.100 отображен фрагмент Процесса заказа тура, содержащий Подпроцесс. Данный Процесс состоит из основной части и трех Подпроцессов, работающих с событиями, которые направлены на обработку Событий в рамках одного контекста: Событийный Подпроцесс типа Ошибка – для отмены работы Подпроцесса; Событийный Подпроцесс типа Сообщение – для обновления статуса Подпроцесса при ожидании разрешения продолжать его выполнение; Событийный Подпроцесс типа Компенсация.

Фигура 10.100 – Пример Процесса, содержащего работающие Событийные Подпроцессы для встроенной обработки Событий

На фигуре 10.101 отображен фрагмент вышеописанного Процесса бронирования тура, содержащий не Подпроцессы, а обработчики присоединенных к Действиям Событий. Обратите внимание, что в данном случае обработчикам Событий не доступен контекст Подпроцесса «Booking»; они работают за его пределами. Это значит, что компенсация здесь представлена в виде черного ящика.

Фигура 10.101 – Пример Процесса, содержащего обработчик присоединенных к Действиям Событий

Необходимо учитывать разницу между прерывающими и непрерывающими Событиями. Обработка этих Событий описана в разделах выше. Если Событие является прерывающим (Ошибка, Эскалация, Сообщение, Сигнал, Таймер, Условие, Множественное, Параллельное Множественное), то для Событий одного типа ДОЛЖЕН использоваться только один Подпроцесс, работающий с Событиями. Это исключает последующее использование для них каких-либо других непрерывающих обработчиков.

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

Если Событие является непрерывающим (Эскалация, Сообщение, Сигнал, Таймер, Условие, Множественное, Параллельное Множественное), то для Событий одного типа может быть использовано любое количество работающих с данными Подпроцессов; при этом все эти Подпроцессы могут выполнять одновременно. В ходе выполнения порядок их вызова не определен. Вышеописанные ограничения работают и для Событий, присоединенных к Действиям. В ходе выполнения непрерывающего Подпроцесса, работающего с данными, выполнение родительского Действия происходит в обычном режиме.

В случае, если для обработки Событий Подпроцесс использует и Событийный Подпроцесс, и обработчик прикрепленного к границам Действия Событие, и при этом они имеют одно и то же значение EventDefinition, должно учитываться следующее:

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

Обработчики прерывающих Событий (Ошибка, Эскалация, Сообщение, Сигнал, Таймер, Условие, Параллельный Множественный)

Значение атрибута cancelActivity обработчиков прерывающих Событий равно «true». Неважно, на каком этапе Процесса возникает Событие, обрабатывается ли оно на границе с Действием или в общем потоке, выполнение относящегося к нему Действия прерывается. Если указан обработчик Ошибки общего потока (в Подпроцессе), он работает в рамках данного Подпроцесса. Если в наличие есть присоединенное в границе Действия Событие Ошибка, то Потоки операций направляются от этого События. Выполнение родительского Действия отменяется либо после завершения обработки Ошибки, либо при отхождении от границ События Потока операций.

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

Обработчики непрерывающих Событий (Эскалация, Сообщение, Сигнал, Таймер, Условие, Множнственный Параллельный Множественный)

Значение атрибута cancelActivity обработчиков прерывающих Событий равно «false».

Если используется Событийный Подпроцесс, то на каком бы этапе Процесса не возникло Событие, оно завершается, а соответствующий Подпроцесс выполняется. Если задействовано несколько Событий, выполняемых параллельно, они обрабатываются одновременно. Это значит, что одновременно формируются несколько экземпляров Событийного Подпроцесса. Непрерывающее Стартовое событие указывает на то, что экземпляры Событийного Подпроцесса выполняются одновременно для соответствия требованиям выполнения такого Процесса.

Если используется присоединенное к Действию Событие, то на каком бы этапе Процесса не возникло Событие, обработчик работает одновременно с выполнением Действия. Если для такого События также указан и Событийный Подпроцесс (в Подпроцессе), обработчик События работает в контексте указанного Подпроцесса. После этого от границы События отходят Потоки операций. Поскольку параллельно с выполнением Действия для Исходящего потока операций формируется токен, ДОЛЖНО учитываться то, что при слиянии данного Потока операций с основным Потоком операций Процесса, токен завершается своим Конечным событием.

В приведенном выше примере Процесса обработчик Событий позвляет обновлять данные кредитной карты

В ходе выполнения Подпроцесса «Booking». Он запускается событием, содержащим данные кредитной карты. Такое сообщение может быть получено вне зависимости от того, когда поток управления находится в основной части Подпроцесса. При получении такое сообщение, Действия, содержащиеся в соответствующем обработчике Событий, выполняются одновременно с Действиями, включенными в основной состав Подпроцесса.

См. раздел «Промежуточные события» для получения информации о семантике присоединенных к Действиям Промежуточных событий, а также раздел «Подпроцессы, работающие с данными» для получения информации об операционной семантике непрерывающих Подпроцессов, работающих с данными.

Обработка Конечных событий

При использовании Конечного события Завершение выполнение всех оставшихся в Процессе Действий завершается.

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

При использовании других типов Конечных событий их поведение соответствует тому, что определено посредством EventDefinition. В случае отсутствия последующих активных Действий экземпляр Подпроцесса/Процесса считается выполненным.

10.4.7 Рамки

Под рамками подразумевается контекст, в котором осуществляется выполнение Действия. Сюда входят:

• Доступные Объекты данных (включая входные и выходные данные).
• Доступные События для обработки и инициирования триггеров.
• Диалоги, имеющие быть в данном контексте.

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

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

Жизненный цикл экземпляра рамок, в свою очередь, может быть:

• Активирован
• Выполняется
• Выполнен
• Компенсируется
• Компенсирован
• С ошибкой
• Отменяется
• Отменен

В BPMN описаны графические элементы диаграммы, которые могут быть заключены в рамки, а именно:

• Хореография (Choreography)
• Пул
• Подпроцесс
• Задача
• Действие
• Многоуровневые элементы

Рамками определяется семантика:

• Видимости Объектов данных (включая входные и выходные данные).
• Выполнения Событий.
• Начала/завершения выполнения токена.

Заключенные в границы Объекты данных, События и родственные им элементы (correlation keys) могут отображаться на диаграмме или быть скрыты.

<<предыдущая содержание следующая>>

Данные материалы предназначены исключительно для ознакомления в личных целях.Любое воспроизведение, копирование, а так же коммерческое и некоммерческое использование материалов должно согласовываться с авторами материалов (elma@elewise.ru). Допускается использование материалов сайта без уведомления авторов, но с явным указанием источника.