Пример события ошибки 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

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

Это описание элементов BPMN 2.0 поможет вам.

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

Нотация BPMN 2.0 — самая гибкая и простая. Гибкость достигается благодаря набору элементов и правилам нотации. Простота — за счет наглядности. Процессы и ситуации могут быть по разному изображены в модели. Например, циклы или ссылки на части процесса могут быть смоделированы как минимум тремя способами. Все зависит от вашего выбора, целей моделирования и того, на кого модель ориентирована.

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

BPMN 2.0 — почти полное описание элементов нотации

Операции

Как и другие элементы нотации, операции бывают нескольких типов. Каждый тип конкретизирует действие, с которым связана операция. Типы операций определяются условным обозначением внутри прямоугольника «операция».

Сервисная операция

Операция, которая выполняется сервисом или механизмом. Иными словами, это операции, выполняемые автоматически. Пример — рассчитать цену с учетом скидки. Операция выполняется программой автоматически. Этот тип операций удобно использовать, когда вы отображаете работу программы или инструмента. Или показываете взаимодействие человека и программы. Кстати, пул, который означает сотрудника в модели, также может обозначать программу. Если задать один пул как программу, а другой как пользователя, то можно раскрыть процесс взаимодействия. Такое возможно только в нотации BPMN 2.0.

Пользовательская операция

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

Ручная операция

Операция, которая выполняется сотрудником самостоятельно, без применения каких-то сервисов или инструментов. Пример — почистить апельсин.

Отправка сообщения

Операция, результатом которой является отправленное сообщение. И вот первый пример гибкости нотации — операция «отправить электронное письмо» может быть как типом «пользовательская операция», так и «отправка сообщения». Какой тип использовать, зависит от целей моделирования конкретного процесса и правил, которые вы для себя приняли.

Получение сообщения

Операция, связанная с получением сообщения. Пример — получить письмо на почте.

Выполнение сценария

Операция, которая подразумевает выполнение сценария. Сценарий создается заранее и представляет собой последовательность действий. По сути , сценарий — это тоже процесс. Проще всего понять сценарий как процедуру. Например, проверить документ. Эта операция подразумевает выполнение ряда действий, т.е. мы проверяем конкретные пункты в документе. Это и есть сценарий. Если вы используете этот тип операции, то нужно обязательно указать, какой сценарий используется. Кстати, когда для проверки используется чек-лист, то такая операция явно имеет тип «выполнение сценария», а чек-лист — это сценарий.

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

Выполнение бизнес-правила

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

Бизнес-правило — это уникальная штука! И с точки зрения моделирования бизнес процессов, и с точки зрения выполнения. Есть мнение, что описанные бизнес процессы строги и не дают свободу действий сотрудникам. Это неверно. И как раз бизнес-правила дают допустимую свободу действий модели — с точки зрения развития процесса, сотруднику — с точки зрения действий.

Операция-ссылка

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

Операция-вызов

Отличается от ссылки тем, что если вы используете операцию-вызов, то еще и используете ресурсы этой операции или процесса. Т.е. «одалживаете» сам процесс из другого места.

Процессы в BPMN 2.0

Повторно используемый процесс

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

Процесс-ссылка

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

Событийный процесс

Особый вид процесса. Особенность заключается в том, что такой процесс не имеет входящих/исходящих потоков. Т.е. на диаграмме он не соединен стрелками с другими процессами/операциями. А запускается он, когда в процессе наступает событие, такое же, какое указано в событийном процессе в качестве старта. Зачем это нужно? Иногда не нужно включать процесс в основной поток. 

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

Спонтанный процесс (ad-hoc)

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

Циклы

Циклическими могут быть как операции, так и процессы.

Стандартное повторение

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

Множественный цикл

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

Компенсация

Операция или процесс компенсации выполняется в том случае, если в процессе произошло что-либо, что требует дополнительных действий для его завершения. Например, при согласовании документа необходимо внести поправки. В таком случае выполняется компенсирующее действие «внести поправки», которое позволяет завершить процесс согласования. Форма компенсации очень удобна для моделирования. Компенсация — отличительная черта нотации BPMN 2.0.

События в BPMN 2.0

Все виды событий — стартовые, промежуточные и события окончания — тоже делятся на типы. Точнее, они имеют разные тригеры — спусковые крючки. Спусковой крючок — это тип условия, при котором наступает событие. Например, событие — получение сигнала. Тип события — сигнал. Спусковой крючок — его получение.

Тригеры событий схожи во всех типах, но имеют свои особенности. Поэтому каждое событие рассматривается с точки зрения трех типов.

Входящие / исходящие события

Перед тем, как приступить к тригерам, объясню, что такое входящие и исходящие события.

Событие с входящим тригером (входящее событие) означает, что оно наступает, если мы получаем какой то сигнал, сообщение и т.д. Например получение письма — входящий тригер.

Событие с исходящим тригером (исходящее событие) означает, что событие свершается, если что-то отправлено. Опять же — отправлено письмо. Исходящими событиями удобно отображать выполнение условия по передаче информации.

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

Промежуточные события могут быть как входящими (получение информации), так и исходящими (отправление информации). К таким событиям относятся: сообщение, эскалация, компенсация, ссылка, сигнал, множественное.

Спусковые крючки событий

Сообщение

Событие наступило, когда было получено или отправлено какое-то сообщение. Событие начала — поступило письмо от заказчика с подтверждением оплаты (только входящее).

Промежуточное событие — отправлен отчет (исходящее). Получена спецификация заказа (входящее)

Событие окончания — отправлено подтверждение отгрузки товара клиенту (только исходящее)

Время

Событие, обозначающее время. Это может быть конкретное время или дата — 10:00 А может быть интервал — каждый понедельник. При наступлении определенного времени процесс начнется.

Пример — событие «последний рабочий день месяца» запускает процесс «инвентаризация». Таймер не может быть событием окончания. Это противоречит сути процессного подхода — каждый процесс производит продукт. А если процесс может быть завершен просто по времени, то это дает возможность не получить продукт в итоге.

Ошибка

Сигнал об ошибке. Такой тип события всегда связан с другим процессом. Т.е. в каком-то процессе возникла ошибка, которая запускает последующий процесс. Пример: событие «ошибка соединения», запускает процесс проверки интернет-соединения с компьютером.

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

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

Событие окончания — из примера со стартовым событием «отсутствуют сопроводительные документы» завершает процесс отгрузки товара.

А еще с помощью промежуточного события «ошибка» отображают риски в процессе. Ну и способы работы с ними.

Эскалация

Запускает процесс, который ускоряет выполнение другого процесса, если тот выполняется неправильно. Событие «Эскалация» всегда связано с другим процессом, который передает (эскалирует) выполнение процесса другому человеку или системе, а тот его принимает.

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

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

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

Отмена

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

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

Событие окончания «никто не пришел» отменяет подготовку вечеринки и все, что было для нее сделано.

Событие отмены не может быть стартовым.

Компенсация

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

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

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

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

Состояние

Событие, обозначающее некое состояние объекта. Состояние относится к параметрам. Например, стартовое событие «температура процессора превысила 70 градусов» запускает процесс охлаждения процессора. Или стартовое событие, обозначающее состояние вашей второй половины как «плохое настроение», запускает процесс приготовления его/ее любимого блюда. То же касается и промежуточных событий — состояние какого-то объекта определяет ветку развития процесса.

Событие окончания не может иметь тригер состояния.

Сигнал

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

Событие начала «свисток чайника» — это сигнал, который запускает процесс заваривания чая.

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

Событие окончания «выключение света на сцене» передает сигнал об окончании выступления и завершает процесс.

Множественное

Событие предполагает множество вариантов, но для его наступления достаточно хотя бы одного. Или какой-то одной комбинации событий. Бывают такие случаи, когда нет необходимости конкретизировать каждое событие и можно их объединить в группу. В таком случае достаточно просто перечислить, какие варианты наступления события могут быть.

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

То же касается и промежуточного и события окончания. Единственный нюанс — промежуточное событие может быть как исходящим, так и входящим. Событие окончания может быть только исходящим.

Параллельное множественное

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

Ссылка

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

Пример: событие «ужин закончился», которое является завершающим событием процесса «ужин», ссылается на процесс «помыть посуду» и запускает его. Промежуточные процессы могут ссылаться как на внешние процессы, так и на процессы внутри себя.

Ссылки могут быть как входящими, так и исходящими.

Терминация

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

Прерывающее и непрерывающее событие

Ну и последнее, что надо знать о свойствах событий. Каждое событие в нотации BPMN 2.0 может прерывать или не прерывать процесс. Это относится только к событиям начала и промежуточным событиям. Прерывание означает что наступление события необходимо для продолжения процесса. Если же событие не влияет на ход процесса, не определяет или не изменяет его, то оно просто учитывается. Например, автоматическая фиксация какого-нибудь KPI не влияет на процесс, но тем не менее может быть отображена на схеме. Также непрерывающими событиями можно отображать совокупность условий, которые на данный момент не влияют на процесс, но будучи выполненными вместе собираются в Множественное или Множественное параллельное событие, которое уже влияет на процесс. Примеры подобных ситуаций я соберу в отдельной статье.

Шлюзы BPMN 2.0

Шлюз «Исключающее ИЛИ», основанный на данных (XOR)

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

Шлюз «Исключающее ИЛИ», основанный на событиях (XOR)

Как и в предыдущем варианте, процесс может развиваться только по одному пути, но теперь он определяется на основании событий. Т.е. в зависимости от того, какое событие произойдет, дальше процесс и будет развиваться. Например, если клиент перезвонил в оговоренный срок, то дальше просто происходит беседа с ним. Если же звонка не было, то менеджеру самому необходимо связаться с клиентом.

Шлюз ИЛИ (OR)

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

Комплексное решение, объединение

В нотации BPMN 2.0 во всех случаях множественных решений требуется заранее заданное условие, чтобы развилка сработала. Почему-то в голову пришел вот такой пример — для того чтобы сработало заклинание, его необходимо произнести (выполнить процесс) только в полнолуние, в апреле високосного года, или при убывающей луне 29 февраля. Т.е. вы сможете пройти развилку и выполнить операцию, только если выполнен один из наборов условий.

Параллельная развилка, объединение (AND)

Здесь все просто. Для того, чтобы процесс стал развиваться дальше, необходимо выполнение всех условий, входящих в развилку. Если же из развилки выходит несколько потоков, то они развиваются параллельно. Пример: чтобы войти в дверь, закрытую на 3 замка, вам нужно открыть каждый из них. Дверь — это и есть развилка))

Объекты данных BPMN 2.0

Исходящие данные

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

Входящие данные

Используется чтобы показать, что для выполнения процесса или операции необходимы некоторые данные. Например, для идентификации клиента, обратившегося в колл-центр, необходим номер договора.

Потоки BPMN 2.0

Поток по умолчанию

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

Условный поток

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



На сегодня все. Я рассказал почти обо всех элементах нотации BPMN 2.0. Хотите освежить в памяти описание базовых элементов? Оно находится здесь. Есть еще дополнительные типы диаграмм и элементов, например диаграмма Хореографии и Диаграмма взаимодействия, но они используются не так часто. О них как-нибудь потом.

8.2 События

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

• Улавливание: когда процесс выполняется до события, он будет ждать запуска. Тип триггера определяется объявлением типа во внутренней диаграмме или XML. Событие захвата и событие запуска отображаются в зависимости от того, заполнена ли внутренняя диаграмма (белый цвет).
• Бросок: когда процесс выполняется до события, событие запускается. Тип триггера определяется объявлением типа во внутренней диаграмме или XML. События запуска и события захвата различаются на дисплее в зависимости от того, заполнена ли внутренняя диаграмма (заполнена черным цветом).

8.2.1 Определения событий

Определение события определяет семантику события. Если определения события нет, это событие не делает ничего особенного. Начальное событие без установки определения события ничего не сделает при запуске процесса. Если мы добавляем определение события к стартовому событию (например, определение события таймера), мы объявляем «тип» события, запускающего процесс (прослушиватель событий таймера будет запущен в определенное время).

8.2.2 Определения событий таймера

Событие таймера — это событие, инициируемое в указанное время. Его можно использовать для [Start Event] (# Start Events Start Event), [Intermediate Event] (#Intermediate Catching Events event) или [Boundary Event] (#Boundary Events ).

Определение таймера должно содержать один из элементов, описанных ниже:

• timeDate. ИспользоватьISO 8601 В формате указывается определенное время, время срабатывания события. Пример:

    <timerEventDefinition>
        <timeDate>2011-03-11T12:13:14</timeDate>
    </timerEventDefinition>

• timeDuration. Укажите, как долго ждать перед таймером, timeDuration можно установить как дочерний элемент timerEventDefinition. использоватьISO 8601 Установленный формат (указанный в BPMN 2.0). Пример (подождите 10 дней).

    <timerEventDefinition>
        <timeDuration>P10D</timeDuration>
    </timerEventDefinition>

• timeCycle. Укажите интервал повторного выполнения, который можно использовать для периодического запуска экземпляра процесса или отправки нескольких напоминаний в течение периода ожидания. Элемент timeCycle может использовать два формата. ПервыйISO 8601 Стандартный формат. Пример (повторяется 3 раза с интервалом 10 часов каждый раз):

    <timerEventDefinition>
        <timeCycle>R3/PT10H</timeCycle>
    </timerEventDefinition>

Кроме того, вы можете использовать выражения cron для указания timeCycle. Следующий пример начинается с часа и выполняется каждые 5 минут:

0 0/5 * * * ?

См. Выражение cronУчебникиЧтобы узнать, как использовать

* Примечание. Первое число означает секунды, а не минуты, как обычно в Unix cron.
Повторяющийся период времени может лучше обрабатывать относительное время, он может вычислять некоторые конкретные моменты времени (например, время начала пользовательских задач), а выражение cron может обрабатывать абсолютное время — это Это особенно полезно для [Начало события таймера] (Событие запуска таймера с заданным временем начала). *

Вы можете использовать выражения в определении события таймера, чтобы вы могли влиять на это определение таймера через переменные процесса. Определение процесса должно содержать строку в формате ISO 8601 (или cron), чтобы соответствовать соответствующему типу времени.

    <boundaryEvent id="escalationTimer" cancelActivity="true" attachedToRef="firstLineSupport">
         <timerEventDefinition>
          <timeDuration>${duration}</timeDuration>
        </timerEventDefinition>
      </boundaryEvent>

Примечание. Таймер сработает только после включения исполнителя задания. (Для параметра jobExecutorActivate в activiti.cfg.xml необходимо установить значение true, но исполнитель задания по умолчанию закрыт).

8.2.3 Определения событий ошибок

Событие ошибки запускается указанной ошибкой.

Важное напоминание: ошибки BPMN полностью отличаются от исключений Java. На самом деле ничего общего между ними нет. События ошибок BPMN предназначены для моделирования бизнес-исключений. Исключением Java является использованиеКонкретный способиметь дело с.

Определение события ошибки будет ссылаться на элемент ошибки. Ниже приводится пример элемента ошибки со ссылкой на сообщение об ошибке:

    <endEvent id="myErrorEndEvent">
      <errorEventDefinition errorRef="myError" />
    </endEvent>  

Обработчик события ошибки, который ссылается на тот же элемент ошибки, перехватит эту ошибку.

8.2.4 Определения сигнальных событий

Событие сигнала ссылается на именованный сигнал. Сигнальные глобальные события (семантика трансляции). Будет отправлено на все активированные процессоры.

В определении сигнального события используется элемент signalEventDefinition. Атрибут signalRef относится к дочернему элементу signal, определенному в корневом узле определений. Ниже приведен пример процесса, в котором сигнал генерируется и фиксируется промежуточным событием.

    <definitions... >
            <!-- declaration of the signal -->
            <signal id="alertSignal" name="alert" />

            <process id="catchSignal">
                    <intermediateThrowEvent id="throwSignalEvent" name="Alert">
                            <!-- signal event definition -->
                            <signalEventDefinition signalRef="alertSignal" />
                    </intermediateThrowEvent>
                    ...
                    <intermediateCatchEvent id="catchSignalEvent" name="On Alert">
                            <!-- signal event definition -->
                            <signalEventDefinition signalRef="alertSignal" />
                    </intermediateCatchEvent>
                    ...             
            </process>
    </definitions>

signalEventDefinition относится к тому же элементу сигнала.

8.2.4.1 Создание сигнального события

Сигнал может быть инициирован экземпляром процесса через узел bpmn или через API. Следующие методы в org.activiti.engine.RuntimeService можно использовать для ручного запуска сигнала.

    RuntimeService.signalEventReceived(String signalName);
    RuntimeService.signalEventReceived(String signalName, String executionId);

signalEventReceived (String signalName); и signalEventReceived (String signalName, String
executionId); Разница в том, что первый метод отправляет сигнал всем подписанным процессорам глобально (широковещательная семантика), а второй метод отправляет информацию только указанному исполнению .

8.2.4.2 Регистрация сигнального события

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

8.2.4.3 Запрос подписок на сигнальные события

Вы можете запросить выполнение всех подписанных определенных сигнальных событий:

    List<Execution> executions = runtimeService.createExecutionQuery()
          .signalEventSubscriptionName("alert")
          .list();

Мы можем использовать метод signalEventReceived (String signalName, String executionId) для отправки сигналов этим исполнениям.

8.2.4.4 Объем событий сигнала

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

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

Если вы хотите ограничить область действия сигнального события, вы можете использовать атрибут области, определенный сигнальным событием (не стандартный атрибут BPMN2.0):

    <signal id="alertSignal" name="alert" activiti:scope="processInstance"/>

Значение этого атрибута по умолчанию — global.

8.2.4.5 Примеры сигнальных событий

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

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

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

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

Примечание. Событие сигнала не устанавливает соединение с конкретным экземпляром процесса. Если вы хотите отправить сообщение только указанному экземпляру процесса, вам необходимо связать вручную, а затем использовать signalEventReceived (String signalName, String executionId) и соответствующийМеханизм запроса。

8.2.5 Определения событий сообщений

Ссылочное имя сообщения о событии для события сообщения. У сообщения есть имя и полезная нагрузка. В отличие от сигнала, событие сообщения всегда указывает на получателя.

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

    <definitions id="definitions" 
      xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL"
      xmlns:activiti="http://activiti.org/bpmn"
      targetNamespace="Examples"
      xmlns:tns="Examples">

      <message id="newInvoice" name="newInvoiceMessage" />
      <message id="payment" name="paymentMessage" />

      <process id="invoiceProcess">  

        <startEvent id="messageStart" >
            <messageEventDefinition messageRef="newInvoice" />
        </startEvent>
        ...    
        <intermediateCatchEvent id="paymentEvt" >
            <messageEventDefinition messageRef="payment" />
        </intermediateCatchEvent>
        ...
      </process>

    </definitions>

8.2.5.1 Создание события сообщения

В качестве встроенного механизма процессов activit i не может получать сообщения. Эти связанные со средой, связанные с платформой действия, такие как подключение к очередям или темам JMS (Java Message Service) или выполнение запросов WebService или REST. Прием этого сообщения реализуется на уровне приложения или архитектуры, а механизм процесса встроен в него.

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

    ProcessInstance startProcessInstanceByMessage(String messageName);
    ProcessInstance startProcessInstanceByMessage(String messageName, Map<String, Object> processVariables);
    ProcessInstance startProcessInstanceByMessage(String messageName, String businessKey, Map<String, Object> processVariables);           

Эти методы позволяют использовать соответствующие экземпляры процессов системы сообщений.

Если сообщение должно быть обработано запущенным экземпляром процесса, сначала найдите соответствующий экземпляр процесса на основе сообщения (см. Следующий раздел), а затем запустите процесс ожидания. RuntimeService предоставляет следующие методы для запуска процесса для продолжения выполнения на основе подписки на события сообщений.

    void messageEventReceived(String messageName, String executionId);
    void messageEventReceived(String messageName, String executionId, HashMap<String, Object> processVariables);    

8.2.5.2 Запрос подписок на события сообщений

Activiti поддерживает события начала сообщения и события промежуточного сообщения.

• В случае события запуска сообщения подписка на событие сообщения назначается определенному определению процесса. Эту подписку на новости можно запросить с помощью ProcessDefinitionQuery:

    ProcessDefinition processDefinition = repositoryService.createProcessDefinitionQuery()
          .messageEventSubscription("newCallCenterBooking")
          .singleResult();

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

• Когда событие сообщения зафиксировано в середине, подписка на событие сообщения будет назначена конкретному выполнению. Эту подписку на новостное событие можно запросить с помощью ExecutionQuery:

    Execution execution = runtimeService.createExecutionQuery()
          .messageEventSubscriptionName("paymentReceived")
          .variableValueEquals("orderId", message.getOrderId())
          .singleResult();

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

8.2.5.3 Примеры событий сообщений

Ниже приведен пример процесса, запущенного с двумя разными сообщениями:

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

8.2.6 Стартовые события

Событие start используется для указания, где начинается процесс. Тип начального события (запускается ли процесс при получении события или в указанное время и т. Д.) Определяет, как запускается процесс, что показано на разных небольших диаграммах в событии. В XML эти типы различаются объявлением разных дочерних элементов.

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

В стартовом событии вы можете установить следующие атрибуты, специфичные для действий:

• Инициатор: при запуске процесса сохранить текущего вошедшего в систему пользователя с именем переменной. Вот примеры:

    <startEvent id="request" activiti:initiator="initiator" />

Пользователь, вошедший в систему, должен быть установлен с помощью метода IdentityService.setAuthenticatedUserId (String) и включен в код try-finally следующим образом:

    try {
      identityService.setAuthenticatedUserId("bono");
      runtimeService.startProcessInstanceByKey("someProcessKey");
    } finally {
      identityService.setAuthenticatedUserId(null);
    }

Этот код взят из Activiti Explorer, поэтому его можно использовать вместе с [Глава 9. Формы] (../ Глава 9. Формы / README.md).

8.2.7 Отсутствие стартового события

8.2.7.1 Описание

Пустое стартовое событие технически означает, что не указаны триггерные условия для запуска экземпляра процесса. Это означает, что движок не может предсказать, когда запустится экземпляр процесса. Пустое стартовое событие используется, когда экземпляр процесса должен быть запущен через API, путем вызова метода startProcessInstanceByXXX.

    ProcessInstance processInstance = runtimeService.startProcessInstanceByXXX();

Примечание: у каждого подпроцесса есть пустое стартовое событие.

8.2.7.2 Графические обозначения Графические обозначения

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

8.2.7.3 Содержимое представления XML

XML-структура пустого стартового события является обычным определением стартового события без каких-либо дочерних элементов (другие типы стартовых событий имеют дочерний элемент для объявления своего типа)

    <startEvent id="start" name="my start event" />

8.2.7.4 Пользовательские расширения для события без запуска

formKey: относится к шаблону формы, который пользователь должен заполнить при запуске нового экземпляра процесса. Для получения дополнительной информации см. [Глава 9. Формы] (../ Глава 9. Формы / README.md). Примеры:

    <startEvent id="request" activiti:formKey="org/activiti/examples/taskforms/request.form" />

8.2.8 Событие запуска таймера

8.2.8.1 Описание

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

Примечание. Подпроцессы не могут использовать события запуска по времени.

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

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

8.2.8.2 Графические обозначения Графические обозначения

Событие начала отсчета времени отображается в виде круга со таблицей внутри.

8.2.8.3 Содержимое представления XML

XML-содержимое события начала отсчета времени является объявлением общего события запуска и включает подэлемент определения времени. Пожалуйста, обратитесь к [Определения событий таймера] (# Определения событий таймера Определение события таймера) для получения подробной информации.

Пример: процесс будет запускаться 4 раза с интервалом в 5 минут каждый раз, начиная с 12:13 11 марта 2011 года.

    <startEvent id="theStart">
            <timerEventDefinition>
                <timeCycle>R4/2011-03-11T12:13/PT5M</timeCycle>
            </timerEventDefinition>
     </startEvent>

Пример: процесс начнется один раз в выбранное время.

    <startEvent id="theStart">
            <timerEventDefinition>
                <timeDate>2011-03-11T12:13:14</timeDate>
            </timerEventDefinition>
    </startEvent>

8.2.9 Message Start Event

8.2.9.1 Описание

[Сообщение] (#Message Event Definitions Event Definition) Событие start может использовать именованное сообщение для запуска экземпляра процесса. Это помогает нам использовать имя сообщения для выбора правильного стартового события.

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

• Имя события запуска сообщения не может повторяться в данном определении процесса. Определение процесса не может содержать несколько событий запуска сообщения с одним и тем же именем. Если два или более события запуска сообщения применяют одно и то же событие, или два или более событий сообщения ссылаются на одно и то же имя сообщения, activiti выдаст исключение при публикации определения процесса.
• Имя события запуска сообщения не может повторяться во всех опубликованных определениях процесса. Если одно или несколько событий начала сообщения относятся к сообщению с тем же именем, и это событие начала сообщения было развернуто в разных определениях процесса, activiti выдаст исключение при публикации.
• Версия процесса: при выпуске новой версии определения процесса ранее подписанная подписка на сообщения будет отменена. Если в новой версии нет события сообщения, оно будет обработано таким же образом.

Запустите экземпляр процесса, событие запуска сообщения может быть запущено с помощью следующих методов в RuntimeService:

    ProcessInstance startProcessInstanceByMessage(String messageName);
    ProcessInstance startProcessInstanceByMessage(String messageName, Map<String, Object> processVariables);
    ProcessInstance startProcessInstanceByMessage(String messageName, String businessKey, Map<String, Object< processVariables); 

Здесь messageName — это атрибут имени элемента сообщения, на который ссылается атрибут messageRef объекта messageEventDefinition.запускатьПри работе с экземпляром процесса учитывайте следующие факторы:

• Событие запуска сообщения поддерживает только процессы верхнего уровня. Событие запуска сообщения не поддерживает встроенные подпроцессы.
• Если определение процесса имеет несколько событий запуска сообщения, runtimeService.startProcessInstanceByMessage (…) выберет
  Соответствующее начальное событие.
• Если в определении процесса есть несколько событий запуска сообщения и пустое событие запуска.
  runtimeService.startProcessInstanceByKey (…) и runtimeService.startProcessInstanceById (…) запустят экземпляр процесса с пустым стартовым событием.
• Если в определении процесса есть несколько событий запуска сообщения и нет пустого события запуска,
  runtimeService.startProcessInstanceByKey (…) и runtimeService.startProcessInstanceById (…) вызовут исключения.
• Если определение процесса имеет только одно событие запуска сообщения, runtimeService.startProcessInstanceByKey (…) и
  runtimeService.startProcessInstanceById (…) будет использовать это сообщение для запуска события для запуска экземпляра процесса.
• Если процесс запускается ссылкой вызова (callActivity), событие запуска сообщения поддерживает только следующие ситуации:
• В дополнение к событию запуска сообщения существует отдельное пустое событие запуска.
• У процесса есть только одно событие запуска сообщения и нет пустого события запуска.

8.2.9.2 Графические обозначения Графические обозначения

Событие начала сообщения — это круг со значком события сообщения посередине. Значок белого цвета без заливки, что указывает на режим захвата (приема).

8.2.9.3 Содержимое представления XML

XML-содержимое события запуска сообщения включает дочерний элемент messageEventDefinition в обычном приложении события запуска:

    <definitions id="definitions" 
      xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL"
      xmlns:activiti="http://activiti.org/bpmn"
      targetNamespace="Examples"
      xmlns:tns="Examples">
      <message id="newInvoice" name="newInvoiceMessage" />  
      <process id="invoiceProcess">   
        <startEvent id="messageStart" >
            <messageEventDefinition messageRef="tns:newInvoice" />
        </startEvent>
        ...    
      </process>
    </definitions>

8.2.10 Signal Start Event

8.2.10.1 Описание

[signal] (# Signal Event Definitions signal определение события) Стартовое событие может использоваться для запуска экземпляра процесса через именованный сигнал (сигнал). Сигнал может быть инициирован с помощью «промежуточной транзакции передачи сигнала» внутри экземпляра процесса или через API (метод runtimService.signalEventReceivedXXX). В обоих случаях будет запущено событие signalStartEvent с тем же именем во всех экземплярах процесса.

Обратите внимание, что в обоих случаях вы можете запускать экземпляр процесса синхронно или асинхронно.

В API необходимо передать signalName, которое является значением атрибута name элемента signal, на который будет ссылаться атрибут signalRef signalEventDefinition.

8.2.10.2 Графические обозначения Графические обозначения

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

8.2.10.3 Содержимое представления XML

Формат XML signalStartEvent — это стандартное объявление startEvent, которое содержит дочерний элемент signalEventDefinition:

 <signal id="theSignal" name="The Signal" />
    <process id="processWithSignalStart1">
        <startEvent id="theStart">
          <signalEventDefinition id="theSignalEventDefinition" signalRef="theSignal"  />
        </startEvent>
        <sequenceFlow id="flow1" sourceRef="theStart" targetRef="theTask" />
        <userTask id="theTask" name="Task in process A" />
        <sequenceFlow id="flow2" sourceRef="theTask" targetRef="theEnd" />
        <endEvent id="theEnd" />
    </process>

8.2.11 Error Start Event

8.2.11.1 Описание

[Ошибка] (определение события ошибки #Error Event Definitions) start-событие может использоваться для запуска подпроцесса события. Событие запуска ошибки нельзя использовать для запуска экземпляра процесса.

События запуска при ошибке — это события прерывания.

8.2.11.2 Графические обозначения Графические обозначения

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

8.2.11.3 Содержимое представления XML

XML-содержимое события запуска из ошибки является общим определением события запуска и содержит дочерний элемент errorEventDefinition.

    <startEvent id="messageStart" >
            <errorEventDefinition errorRef="someError" />
    </startEvent>

8.2.12 Конечные события

Конечное событие указывает на конец (под) процесса (ветви). Завершить мероприятиеВсе триггерные события. Это означает, что когда процесс достигнет конечного события, будет инициирован результат. Тип результата обозначается внутренним черным значком события. В содержимом XML он объявляется содержащимися дочерними элементами.

8.2.13 Нет конечного события

8.2.13.1 Описание

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

8.2.13.2 Графические обозначения Графические обозначения

Пустое конечное событие — это толстый круг без маленькой диаграммы внутри (без типа результата).

8.2.13.3 содержимое XML-представления

XML-содержимое пустого конечного события является обычным определением конечного события и не содержит дочерних элементов (другие типы конечных событий будут содержать дочерние элементы объявленного типа)

    <endEvent id="end" name="my end event" />

8.2.14 Ошибка конечного события

8.2.14.1 Описание

Когда процесс выполняетсяОшибка конечного события, Текущая ветвь процесса завершится ошибкой. Эта ошибка может быть обнаружена соответствующим средним событием [пограничная ошибка] (# «Граничные события Событие). Если соответствующее событие пограничной ошибки не обнаружено, будет выдано исключение.

8.2.14.2 Графические обозначения Графические обозначения

Конечное событие ошибки — это стандартное конечное событие (жирный кружок) со значком ошибки внутри. Диаграмма ошибок полностью черная, что указывает на синтаксис триггера.

8.2.14.3 содержимое XML-представления

Содержимое конечного события ошибки — это событие ошибки, а дочерний элемент — errorEventDefinition.

    <endEvent id="myErrorEndEvent">
      <errorEventDefinition errorRef="myError" />
    </endEvent>          

Атрибут errorRef относится к элементу ошибки, определенному вне процесса:

    <error id="myError" errorCode="123" />
    ...
    <process id="myProcess">  
    ...      

ErrorCode of error используется для поиска совпадающих событий ошибки границы захвата. Если errorRef не соответствует ни одной ошибке, errorRef будет использоваться как сокращение errorCode. Это акроним от слова activiti. более конкретно
Допустим, вы видите следующий код:

    <error id="myError" errorCode="error123" />
    ...
    <process id="myProcess">  
    ...  
      <endEvent id="myErrorEndEvent">
        <errorEventDefinition errorRef="myError" />
      </endEvent>

Эквивалентно

    <endEvent id="myErrorEndEvent">
      <errorEventDefinition errorRef="error123" />
    </endEvent> 

Обратите внимание, что errorRef должен соответствовать формату BPMN 2.0 и быть допустимым QName.

8.2.15 Отмена конечного события

[тест]

8.2.15.1 Описание

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

8.2.15.2 Графические обозначения Графические обозначения

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

8.2.15.3 Содержимое представления XML

Содержимое конечного события отмены — это конечное событие, включая дочерний элемент cancelEventDefinition.

    <endEvent id="myCancelEndEvent">
      <cancelEventDefinition />
    </endEvent>     

8.2.16 Граничные события

Граничные события — это события захвата, которые прикрепляются к ссылке. (Граничное событие не может вызвать событие). Это означает, что когда узел запущен, событие будет отслеживать соответствующий тип триггера. Когда событие фиксируется, узел будет прерван, и в то же время будет выполнено последующее соединение события.

Таким образом, определение пограничных событий такое же:

    <boundaryEvent id="myBoundaryEvent" attachedToRef="theActivity">
          <XXXEventDefinition/>
    </boundaryEvent>

Граничное событие определяется следующим образом:

• Уникальный идентификатор (объем процесса)
• Используйте атрибут catch для ссылки на узел одежды события. Обратите внимание, что граничные события и связанные с ними узлы находятся на одном уровне. (Например, граничные события не содержатся в узлах).
• Дочерние элементы XML формата XXXEventDefinition (например, TimerEventDefinition, ErrorEventDefinition и т. Д.) Определяют тип граничного события. Для получения более подробной информации обратитесь к соответствующему типу пограничного события.

8.2.17 Граничное событие таймера

8.2.17.1 Описание

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

8.2.17.2 Графические обозначения Графические обозначения

Временное граничное событие — это стандартное граничное событие (кружок на границе) с маленьким значком таймера внутри.

8.2.17.3 Содержимое представления XML

Определение граничной задачи таймера — это формальное [пограничное событие] (граничное событие #Boundary Events). Дочерним элементом указанного типа является элемент timerEventDefinition.

    <boundaryEvent id="escalationTimer" cancelActivity="true" attachedToRef="firstLineSupport">
       <timerEventDefinition>
        <timeDuration>PT4H</timeDuration>
      </timerEventDefinition>
    </boundaryEvent>    

Пожалуйста, обратитесь к [Определения событий таймера] (# Определения событий таймера Определения событий таймера) для получения более подробной информации о конфигурации времени.

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

Классический сценарий — отправить электронное письмо с обновлением, не прерывая выполнение обычного процесса.

Потому что в BPMN 2.0 по-прежнему существует разница между прерванными и непрерываемыми событиями. По умолчанию это событие прерывания. В случае непрерывающего события исходная ссылка не будет прервана, и эта ссылка останется на месте. Соответственно, будет создана новая ветка, и выполнение будет продолжено в потоке события. В содержимом XML установите для свойства cancelActivity значение false:

    <boundaryEvent id="escalationTimer" cancelActivity="false" attachedToRef="firstLineSupport"/>

Примечание. Граничные временные события могут использоваться, только если включен исполнитель задания. (Например, установите для параметра jobExecutorActivate в activiti.cfg.xml значение true, поскольку исполнитель заданий по умолчанию отключен по умолчанию)

8.2.17.4 Известная проблема с граничными событиями

Известная проблема синхронизации с использованием граничных событий. В настоящее время не может быть нескольких исходящих подключений после пограничного события (ссылкаACT-47. Решение этой проблемы — использовать параллельный шлюз после подключения

8.2.18 Граничное событие ошибки

8.2.18.1 Описание

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

Определите событие граничной ошибки, в основном используемое для встроенныхПодпроцесс,илиУзел вызоваВ случае подпроцесса он создаст область для всех внутренних узлов. Ошибки вызываются [конечным событием ошибки] (конечным событием ошибки). Эта ошибка будет передана в верхнюю область видимости, пока не будет найдено определение события ошибки, соответствующее граничному событию ошибки.

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

8.2.18.2 Графические обозначения Графические обозначения

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

8.2.18.3 Содержимое представления XML

Событие пограничной ошибки определяется как нормальное [пограничное событие] (граничное событие #Boundary Events):

    <boundaryEvent id="catchError" attachedToRef="mySubProcess">
      <errorEventDefinition errorRef="myError"/>
    </boundaryEvent>

Как и событие завершения ошибки, errorRef относится к определению ошибки вне элемента процесса:

    <error id="myError" errorCode="123" />
    ...
    <process id="myProcess">
    ...

errorCode используется для сопоставления зафиксированной ошибки:

• Если errorRef не задан, граничные события ошибок будут фиксировать все события ошибок, независимо от кода errorCode.
• Если errorRef установлен и имеется ссылка на существующую ошибку, граничное событие будет фиксировать только ошибки с тем же кодом ошибки.
• Если errorRef установлен, но в BPMN 2.0 ошибка не определена, errorRef будет использоваться как errorCode (аналогично использованию события конца ошибки)

8.2.18.4 Пример

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

Этот процесс также представлен в демонстрации. XML процесса и модульные тесты можно найти в пакете org.activiti.examples.bpmn.event.error.

8.2.19 Событие границы сигнала

8.2.19.1 Описание

Средний захват границы узла [сигнал] (определение события сигнала #Signal Event Definitions), или просто называемый событием пограничного сигнала, он захватит сигнал с тем же именем сигнала, на которое ссылается определение сигнала.

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

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

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

8.2.19.2 Графические обозначения Графические обозначения

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

8.2.19.3 Содержание XML-представления

Событие пограничного сигнала определяется как обычное пограничное событие:

    <boundaryEvent id="boundary" attachedToRef="task" cancelActivity="true">       
              <signalEventDefinition signalRef="alertSignal"/>
    </boundaryEvent>

8.2.19.4 Пример

ссылкаОпределение события сигналаглава

8.2.20 Событие границы сообщения

8.2.20.1 Описание

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

8.2.20.2 Графические обозначения Графические обозначения

Событие граничное [сообщение] (#Message Event Definitions Event Definition) отображается как обычное промежуточное событие (маленький кружок в кружке), расположенное на краю узла, а внутри — небольшой значок сообщения. Значок сообщения белый (без заливки), что указывает на семантику захвата.

Обратите внимание, что событие пограничного сообщения может быть прервано (справа) или не прерываться (слева).

8.2.20.3 Содержимое представления XML

Событие пограничного сообщения определяется как стандартное пограничное событие:

    <boundaryEvent id="boundary" attachedToRef="task" cancelActivity="true">       
              <messageEventDefinition messageRef="newCustomerMessage"/>
    </boundaryEvent>

8.2.20.4 Пример

См. Главу [Определения событий сообщений] (# Определения событий сообщений).

8.2.21 Отмена граничного события

[тест]

8.2.21.1 Описание

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

Примечание. У каждого подпроцесса транзакции может быть только одно граничное событие отмены.

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

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

8.2.21.2 Графические обозначения Графические обозначения

Граничное событие отмены отображается как обычное промежуточное событие (маленький кружок внутри круга) .На краю узла есть маленький значок отмены внутри. Значок отмены белого цвета (без заливки), что указывает на захват семантики.

8.2.21.3 Содержимое представления XML

Отмена граничного события определяется как обычное [граничное событие] (граничное событие #Boundary Events):

    <boundaryEvent id="boundary" attachedToRef="transaction" >       
              <cancelEventDefinition />
    </boundaryEvent>

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

8.2.22 Граничное событие компенсации

[тест]

8.2.22.1 Описание

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

Граничные события компенсации должны использовать прямую ссылку для установки уникального процессора компенсации.

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

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

Примечание. Граничные события компенсации не поддерживают встроенные подпроцессы.

8.2.22.2 Графические обозначения Графические обозначения

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

8.2.22.3 Содержимое представления XML

Граничные события компенсации определяются как стандартные [граничные события] (граничные события #Boundary Events):

    <boundaryEvent id="compensateBookHotelEvt" attachedToRef="bookHotel" >       
              <compensateEventDefinition />
    </boundaryEvent>

    <association associationDirection="One" id="a1"  sourceRef="compensateBookHotelEvt" targetRef="undoBookHotel" />

    <serviceTask id="undoBookHotel" isForCompensation="true" activiti:class="..." />

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

8.2.23 Промежуточные отловы

Все промежуточные события захвата определяются одинаково:

    <intermediateCatchEvent id="myIntermediateCatchEvent" >
          <XXXEventDefinition/>
    </intermediateCatchEvent>

Определение промежуточных событий захвата включает:

• Уникальный идентификатор (в рамках процесса)
• Дочерний элемент XML (например, TimerEventDefinition и т. Д.) Со структурой XXXEventDefinition определяет тип промежуточного события захвата. Для получения более подробной информации обратитесь к конкретному типу события захвата.

8.2.24 Таймер промежуточного захвата события

8.2.24.1 Описание

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

8.2.24.2 Графические обозначения Графические обозначения

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

8.2.24.3 Содержимое представления XML

Промежуточное событие таймера определяется как стандартное промежуточное событие захвата. Дочерним элементом указанного типа является элемент timerEventDefinition.

    <intermediateCatchEvent id="timer">
            <timerEventDefinition>
                <timeDuration>PT5M</timeDuration>
            </timerEventDefinition>
    </intermediateCatchEvent>

См. [Определения событий таймера] (# Определения событий таймера Определения событий таймера) для получения информации о конфигурации.

8.2.25 Signal Intermediate Catching Event

8.2.25.1 Описание

Промежуточный захват [Сигнал] (#Signal Event Definitions ) событие Захватывает сигнал с тем же именем, ссылаясь на определение сигнала.

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

8.2.25.2 Графические обозначения Графические обозначения

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

8.2.25.3 Содержимое представления XML

Промежуточные события сигнала определяются как обычные [Промежуточные события улавливания] (#Intermediate Catching Events Intermediate Catching Events). Дочерним элементом соответствующего типа является элемент signalEventDefinition.

    <intermediateCatchEvent id="signal">
            <signalEventDefinition signalRef="newCustomerSignal" />
    </intermediateCatchEvent>

8.2.25.4 Пример

См. Главу [Определения событий сигналов] (# Определения событий сигналов Определения событий сигналов).

8.2.26 Сообщение о промежуточном перехвате события

8.2.26.1 Описание

Промежуточный захват [сообщение] (#Message Event Definitions Event Definition) событие для захвата сообщения с определенным именем.

8.2.26.2 Графические обозначения Графические обозначения

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

8.2.26.3 Содержимое представления XML

Промежуточные события сообщений определены как стандартные [Промежуточные события отлова] (#Intermediate Catching Events Intermediate Catching Events). Дочерним элементом указанного типа является элемент messageEventDefinition.

    <intermediateCatchEvent id="message">
            <messageEventDefinition signalRef="newCustomerMessage" />
    </intermediateCatchEvent>

8.2.26.4 Пример

См. Главу [Определения событий сообщений] (# Определения событий сообщений).

8.2.27 Промежуточный бросок

Определение всех внутренних триггерных событий одинаково

    <intermediateThrowEvent id="myIntermediateThrowEvent" >
          <XXXEventDefinition/>
    </intermediateThrowEvent>

Определение события внутреннего триггера содержит

• Уникальный идентификатор (объем процесса)
• Используйте дочерний элемент XML (например, signalEventDefinition и т. Д.) В формате XXXEventDefinition, чтобы определить тип промежуточного триггерного события. Для получения дополнительной информации см. Соответствующий тип триггерного события.

8.2.28 Intermediate Throwing None Event

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

Добавив прослушиватель выполнения, вы можете хорошо отслеживать некоторые KPI.

    <intermediateThrowEvent id="noneEvent">
      <extensionElements>
        <activiti:executionListener class="org.activiti.engine.test.bpmn.event.IntermediateNoneEventTest$MyExecutionListener" event="start" />
      </extensionElements>
    </intermediateThrowEvent>

Здесь вы можете добавить свой собственный код для отправки события в инструмент BAM или DWH. Движок ничего не сделает для этого события, он передаст напрямую

8.2.29 Событие по метанию промежуточных сигналов

8.2.29.1 Описание

Промежуточное событие триггера [сигнал] (определение события сигнала #Signal Event Definitions) генерирует событие сигнала для определенного сигнала.

В активити сигнал будет транслироваться на все активированные процессоры (например, так, чтобы событие сигнала было зафиксировано). Сигналы могут подаваться синхронно и асинхронно.

• В конфигурации по умолчанию сигнал отправляется синхронно. То есть экземпляр процесса, который генерирует событие, будет ждать, пока сигнал не будет отправлен всем захваченным экземплярам процесса, прежде чем продолжить. Захваченный экземпляр процесса также будет выполнен в той же транзакции, которая запустила экземпляр процесса, а это означает, что если в определенном процессе мониторинга возникнет техническая проблема (выдача исключения), все связанные экземпляры завершатся ошибкой.
• Сигналы также можно отправлять асинхронно. В это время он решит, какие процессоры будут активными после достижения сигнального события. Для этих активированных процессоров асинхронное напоминание (задача) будет сохранено и отправлено в jobExecutor.

8.2.29.2 Графические обозначения Графические обозначения

Событие запуска промежуточного сигнала отображается как нормальное промежуточное событие (кружок внутри круга) с маленьким значком сигнала внутри. Значок сигнала черный (заполненный), что указывает на семантику триггера.

8.2.29.3 Содержимое представления XML

Промежуточное событие сообщения определяется как стандартное промежуточное инициирующее событие. Дочерним элементом указанного типа является элемент signalEventDefinition.

    <intermediateThrowEvent id="signal">
            <signalEventDefinition signalRef="newCustomerSignal" />
    </intermediateThrowEvent>

Асинхронные сигнальные события следующие:

    <intermediateThrowEvent id="signal">
            <signalEventDefinition signalRef="newCustomerSignal" activiti:async="true" />
    </intermediateThrowEvent>

8.2.29.4 Пример

Обратитесь к главе определения событий [Сигнал] (#Signal Event Definitions).

8.2.30 Compensation Intermediate Throwing Event

[тест]

8.2.30.1 Описание

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

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

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

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

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

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

• Процессор компенсации не может получить доступ к переменным, созданным внутри подпроцесса и добавленным в ветвь синхронизации.
• Переменные процесса, назначенные ветви, находятся на верхнем уровне отношения наследования (переменные процесса, назначенные экземпляру процесса, не включаются в моментальный снимок): когда запускается компенсация, процессор компенсации получает доступ к этим переменным процесса через их местоположение.
• Моментальные снимки переменных используются только для встроенных подпроцессов, а не для других узлов.

Известные ограничения:

• waitForCompletion = ”false” пока не поддерживается. Когда компенсация запускается промежуточным событием компенсации запуска, событие не ожидает,
  После успешного завершения компенсации.
• Компенсация осуществляется параллельными филиалами. Порядок выполнения параллельных ветвей противоположен порядку завершения компенсируемого узла. В будущем activiti может поддерживать варианты для последовательного выполнения компенсации.
• Компенсация не распространяется на экземпляр подпроцесса, вызываемого callActivity.

8.2.30.2 Графические обозначения Графические обозначения

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

8.2.30.3 Содержимое представления XML

Промежуточные события компенсации определяются как обычные промежуточные триггерные события. Дочерний элемент соответствующего типа
— это элемент компенсацииEventDefinition.

    <intermediateThrowEvent id="throwCompensation">
            <compensateEventDefinition />
    </intermediateThrowEvent>

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

    <intermediateThrowEvent id="throwCompensation">
            <compensateEventDefinition activityRef="bookHotel" />
    </intermediateThrowEvent>

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

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). Допускается использование материалов сайта без уведомления авторов, но с явным указанием источника.