Ошибки моделирования bpmn

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

Если на собеседовании вас спрашивают «Имеете ли вы опыт моделирования бизнес-процессов», то в неявном виде вас спрашивают об опыте использования нотации BPMN. Мне могут возразить, что есть и другие нотации, например UML Activity diagram или старый-добрый IDEF0. Но на сегодняшний день место лидера за BPMN.

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

В интернете есть целый ряд статей, посвященных рассмотрению ошибок, которые чаще всего допускают при создании диаграмм в нотации BPMN (ссылка 1, ссылка 2, ссылка 3, …). Отталкиваясь от них и от своего десятилетного опыта я написал эту статью.

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

• Ошибки формальные – диаграмма не соответствует нотации BPMN.

• Ошибки стиля – диаграмма формально верная, но читать или модифицировать ее неудобно. Стилевые предпочтения у всех свои.

• Логические ошибки – элементы использованы правильные, стиль соблюден, но есть проблемы в логике того, что смоделировано.

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

1. Не BPMN

В диаграмме использованы элементы, отсутствующие в BPMN. Это символы UML, IDEF и других нотаций. Или это самодельные, придуманные автором символы. Самый просто способ убедиться в том, что вы используете корректные элементы — обратиться к постеру BPMN elements

2. Пулы (Pool) та дорожки (Lane)

Во-первых, пулов и дорожек на диаграмме может не быть. Однако их наличие упрощает понимание диаграммы.

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

Дорожки позволяют нам показать участников описываемого процесса – кто какую задачу в рамках процесса выполняет. Если вдаваться в детали, то дорожки – элемент чисто визуальный. Исполнителя/исполнителей для каждой задачи указывают в ее свойствах. Вот как это выглядит в Bizagi:

Можно увидеть, что здесь есть возможность указать участников и указать их вовлеченность в выполнение задачи по RACI-матрице.

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

Итак,

• конкретных исполнителей/подразделения в рамках одной организации, участвующих в процессе — моделируем дорожками;

• процессы или внешних контрагентов моделируем пулами;

• исполнителей в простых случаях обозначаем в названии дорожки;

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

3. Глагол в названии
Название задачи должно содержать глагол: «Создать заявку», «Отправить запрос». Некоторые вместо этого пишут «Создание заявки», или еще хуже «Заявка». Это ошибка в стиле.

4. Подробное описание процесса, о котором мы ничего не знаем

В пункте 2 мы упоминали свернутый пул, моделирующий независимую сущность. К примеру, вы показываете процесс обработки заказа, поступившего от клиента. Клиента лучше всего изобразить свернутым пулом. Что там делается у клиента – для нас загадка, предсказать процесс сложно, повлиять мы на него не можем. Со стороны нашего процесса мы должны определить, какие действия со стороны клиента мы собираемся ожидать и это все. Но детальный процесс для клиента лучше не придумывать. Это пример логической ошибки.

5. «Долгая-долгая история»

Если процесс содержит много шагов, то диаграмма начинает напоминать детскую игру «змейка»:

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

Для разрешения этой ситуации есть 2 варианта:

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

2. Или использовать промежуточное событие «Ссылка» (Link):

6. «Потерянное письмо»

Следующая ошибка — логическая и, на мой взгляд, не очевидна. И критичной она становится только в том случае, когда вы моделируете не только для визуализации, а для выполнения с помощью BPMN-engine.

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

Теперь давайте рассмотрим пример диаграммы:

Если Task 2 будет завершен раньше, чем Task 1, то отправленное Process 2 сообщение потеряется, потому что Process 1 начинает его ожидать только после завершения Task 1. А до этого момента «почтальона» никто не встречает. Для исправления этой ситуации мы можем изменить диаграмму следующим образом:

Здесь мы письмо начинаем ждать сразу после отправки со стороны Process 1.

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

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

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

8. «Конец-делу венец» или завершение без описания.

All’s Well That Ends Well или «Все хорошо, что хорошо заканчивается». Не оставляйте финальное событие без подписи. Особенно эта подпись необходима, когда завершающих событий у нас несколько, как на последнем рисунке в пункте 7. Укажите, какой результат мы получили, когда дошли до этого красного кружка. Это упростит восприятие диаграммы читателем, а engine зафиксирует в протоколе, чем закончился экземпляр процесса.

9. «и швец, и жнец, и на дуде игрец»

Часто в диаграммах можно увидеть, что одна развилка (gateway) используется одновременно и для сведения, и для разветвления потоков:

Практики и теоретики рекомендуют использовать одну развилку либо для сведения, либо для разветвления. Меняем диаграмму следующим образом:

10. «Смешались в кучу кони, люди»

Благодаря наличию в BPMN развилки «Или/Или» мы можем моделировать различные варианты развития событий. Однако есть рекомендация отделять описание бизнес-правил от описания бизнес-процесса. Это и диаграммы упрощает, и внесение изменений делает проще. К примеру, изменение правил расчета кредитного рейтинга меняются гораздо чаще, чем процесс выдачи кредита. Поэтому от такой диаграммы:

мы можем перейти к следующей, используя специальный тип задачи «Business Rule Task»:

Продолжение следует…

Расписание тренингов по бизнес-анализу и анализу данных от Art of Business Analysis

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

Введение

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

Для выполнения этой задачи нужны: эффективная система управления проектом, методология, инструмент (система моделирования) и человеческие ресурсы, адекватные по численности и подготовке. Если инструмент можно легко купить, то с методологией и ресурсами всё не так просто. Качество управления проектом сильно зависит от конкретного руководителя.

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

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

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

Кроме того, рассматривается вопрос о принципиальной возможности обучения сотрудников (не специалистов по орг. развитию или ИТ) нотации BPMN для комплексного описания бизнес-процессов организации.

Исходные данные для анализа

Исходные данные для анализа таковы. В ряде компаний (нефтедобыча, производство, ритейл и проч.) проводилось обучение временных рабочих групп (ВРГ) численностью 25–30 человек. Некоторые участники когда-то занимались «описанием» процессов при помощи «диаграмм с ромбиками» (в Business Studio — это нотация «Процедура») или сталкивались с нотацией eEPC. Но большинство специалистов созданием графических схем не занимались.

Обучение проводилось в течение 2 дней на основе методического пособия «Моделирование бизнес-процессов в нотации BPMN. Пособие для начинающих. Часть I» (В. В. Репин, 2018 год). В первый день слушателей последовательно знакомили с основами нотации BPMN. Они выполняли ряд связанных между собой заданий, моделируя процесс в среде Business Studio и двигаясь от простого к сложному.

Во второй день рассматривались более сложные примеры и выполнялось комплексное задание на описание группы связанных между собой процессов. Это задание выполнялось в небольших рабочих группах по 2–3 человека. После описания процессов группы выполняли анализ качества моделей на основе чек-листа. Проводился разбор ошибок.

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

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

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

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

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

Типовые ошибки моделирования, допускаемые начинающими

Проблема мышки

Первая и, вероятно, самая главная проблема при моделировании процессов в нотации BPMN начинающими — это проблема «Мышки» (я использую этот термина на обучении вместо токена). Для многих сотрудников понимание сути потока работ и мышки, которая бегает от одной операции процесса к другой по стрелкам типа sequence flow, является довольно сложным. Но если не концентрировать внимание на потоке и не отслеживать мысленно различные пути мышки, то можно упустить из вида многие детали реального процесса. Модель в этом случае становится весьма неточной. В ней упускается множество практически важных моментов. В результате, схема вроде как нарисована, но ни выполнить ее анализ, ни обосновать изменения нельзя. Это одна из причин разочарования некоторых руководителей в графических схемах бизнес-процессов как в практическом инструменте развития бизнеса.

Оборванные входы-выходы

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

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

Обсуждая входы/выходы можно отметить два аспекта. Технически на схеме в нотации BPMN в среде Business Studio можно показывать взаимодействие между разными процессами при помощи стрелки типа massage flow, связывая конкретную операцию процесса со свернутым пулом (другой процесс). Для последующей возможности вывода информации о входах/выходах в отчеты к этой стрелке должен быть привязан конкретный документ. Часто неопытные пользователи забывают это делать. Но сама по себе стрелка massage flow без привязанного к ней документа с точки зрения комплексной модели в Business Studio не несет конкретной информации.

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

Бывает обратная ситуация — на модели верхнего уровня входы/выходы есть, а при переходе на уровень вниз на процессы, описанные в нотации BPMN, эти входы/выходы теряются. Иногда на моделях нижнего уровня в нотации BPMN показывают информационные связи с процессами уровня + 2 выше. Как следствие — низкое качество модели компании в целом.

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

На мой взгляд, наличие потока документов на схеме процесса в нотации BPMN в Business Studio необходимо и практически полезно для целей анализа, регламентации и автоматизации.

На рисунке 1 приведен фрагмент схемы процесса с «оборванным» входом для операции «Проверить корректность заполнения заявки». Для операции «Проверить возможность выполнения заявки по режиму» входы/выходы вообще отсутствуют.

Рис. 1. Оборванные и отсутствующие входы-выходы (фрагмент схемы).

Некорректная логика процесса

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

Рис. 2. Пример логической ошибки (фрагмент схемы процесса). Нет входов/выходов.

Непонимание межпроцессного взаимодействия

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

Во-первых, многие интерпретируют маркер в виде конверта как некоторый документ, отправляемый от одной операции процесса к другой. Это понимание на основе бытового здравого смысла приводит к некорректному использованию событий отправки сообщения между операциями одного процесса, без отправки в другой процесс. Некоторые искренне удивляются, почему это ошибка — «ведь результат работы (конверт) отправлен из одной операции в другую?!».

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

• отправляют сообщение в другой процесс (свернутый пул на схеме в Business Studio), который не должен запускаться (инициироваться) — с ним просто есть взаимодействие по входам-выходам (причем, чаще всего, опосредованное — через базу данных или файл-сервер компании);
• отправляют сообщение в свернутый пул под названием «Все процессы», «Поставщик» или, что хуже всего, «Отдел такой-то…» (в Business Studio можно создать свернутый пул из так называемой «Внешней ссылки»);
• отправляют сообщение в процесс, который находится в дереве на 2–3 уровня выше описываемого и сформирован в нотации IDEF0 — отправка «на деревню дедушке»;
• показав отправку сообщения на схеме описываемого процесса, не открывают другой процесс и не дают себе труд продумать, куда попадает отправленное сообщение и как оно повлияет на выполнение другого процесса.

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

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

Использование таймеров

Событие-таймер используется как по ходу процесса, так и в виде граничного события. Как пример типичной ошибки начинающих приведу следующую формулировку события-таймера: «Не позднее 2-го числа месяца». Когда должен сработать таймер — непонятно. Другой пример — «Ежедневно» (см. рис. 4).

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

Рис. 4. Некорректное использование события-таймера (фрагмент схемы).
Нет входов/выходов.

Описание процесса для одного объекта, которых в реальности множество

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

Процесс в процессе (рекурсия)

Довольно часто можно наблюдать такую картину. Берем для анализа процесс под ‘каким-то названием. Начинаем смотреть его детальную схему в BPMN. Видим кучу действий с бумажками (служебки, распоряжения, отчеты, поручения и проч.). Где-то среди всей этой волокиты видим операцию, название которой в точности повторяет название процесса в целом. И это называется описать процесс! Проблема в том, что работу, реально добавляющую ценность, обкладывают бумажками и «закапывают» на нижний уровень, описание которого проектом не предусмотрено. Эту ошибку допускают очень многие, даже довольно опытные сотрудники и бизнес-аналитики! Кстати, наличие таких моделей, как правило, означает, что модель вышестоящего уровня архитектурно плохо выстроена.

Красота схемы

Здесь все печально. Только 10–15% сотрудников стремятся сделать схемы красивыми. Для остальных это третьестепенная задача. Но некрасивую схему не хочется брать в руки, а тем более анализировать. Визуальная красота схемы — залог ее проработанности, что снижает трудоемкость последующих согласований и внесения изменений.

Накопление опыта и исправление ошибок

По ходу выполнения проекта сотрудники накапливают опыт моделирования процессов. Степень проработки и качество моделей процессов становятся существенно выше. При интенсивной работе ВРГ (2–3 модели процессов в неделю), через 1–1,5 месяца можно говорить о приемлемом уровне качества описания моделей процессов.

Хотел бы отметить, что для освоения навыков моделирования процессов на операционном уровне (в нотации BPMN) очень полезно показать сотрудникам имитацию выполнения процесса в Business Studio. Еще лучше, если после этого они сами попробуют запустить на имитацию отрисованный ими процесс, причем сначала пошагово, чтобы почувствовать себя той самой «мышкой» (токеном). Это упражнение дает хорошее понимание сути моделирования процессов Work Flow.

Выводы

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

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

• «мышка» или идеология исполняемых процессов;
• информационное взаимодействие внутри процесса и между процессами («стыковка по входам/выходам»);
• корректное использование событий отправки-получения сообщений и синхронизация процессов между собой по событиям;
• соблюдение уровней при описании межпроцессного взаимодействия (процесс BPMN может отправить сообщение только в процесс BPMN);
• корректное использование событий-таймеров;
• четкое отслеживание множественных объектов для обработки;
• визуальная наглядность схемы («Красота схемы»).

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

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

Важно отметить, что осознанность и мотивация на качественный результат у участников ВРГ — так же критически важные аспекты моделирования бизнес-процессов.

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

Опубликовано по материалам портала http://www.finexpert.ru/

Опубликовано по материалам:
http://finexpert.ru/view/modelirovanie_biznes_protsessov_v_notatsii_BPMN_nachinayushchimi_tipovye_oshibki/941

Ноябрь 2018 г.

Рекомендуемые материалы по тематике

Графическое описание процедур БП

Глоссарий. Должностная инструкция

О настоящем и будущем процессного управления в России — интервью Владимира Репина в рамках проекта «Управление из первых рук»

Оптимизация процессов снабжения в ПАО «Распадская угольная компания»

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