BPMN: события и подпроцессы
Согласование висит четвёртый день. Никто не виноват и никто не забыл: в схеме просто нет ни одного элемента, который умеет замечать время. Задачи ждут человека, стрелки ждут задачи, а часы никто не поставил.
Стержень: события выражают то, что происходит само - сроки, внешние сигналы, нештатные исходы. Таймер, сообщение и ошибка покрывают почти всё.
// Формулировки: «как выразить эскалацию по сроку?», «что такое граничное событие?», «ждём ответ партнёра или сутки»
Событие - то, что случается само
Разница с задачей простая. Задачу кто-то делает: человек заполняет форму, система дёргает сервис. Событие происходит без исполнителя: наступило первое число, пришло сообщение от партнёра, истекли трое суток. Именно поэтому события и отличают схему процесса от обычной блок-схемы.
Рисуют их кружками, а различают по месту и по толщине контура. Стартовое запускает процесс, промежуточное встречается по ходу, завершающее заканчивает ветку. Кроме того, событие бывает ловящим (ждём, когда случится) и бросающим (сами объявляем, что случилось).
// Практический смысл различия: ловящее событие останавливает токен и держит его, пока не сработает. Задача его тоже держит, но задачу надо кому-то выполнять, а ловящее событие ждёт бесплатно и не занимает ничью очередь.
Граничный таймер: снять или напомнить
Самый частый рабочий приём. На задачу согласования вешают кружок с часами и подписью «3 дня». Согласовали за два - таймер снимается вместе с задачей, процесс идёт обычным путём. Не согласовали - таймер срабатывает.
Дальше выбор из двух вариантов, и он меняет смысл. Прерывающий таймер (сплошной контур) отменяет задачу и уводит поток на эскалацию: согласование забирают у исполнителя и отдают руководителю. Непрерывающий (пунктирный) рождает вторую фишку, а задача продолжает висеть у того же человека - так делают напоминания, и таких можно повесить три штуки на разные сроки.
// Альтернативы работают хуже. Отдельная задача «проверить срок» требует, чтобы её кто-то выполнял, а срок тикает сам. Условие на исходящей стрелке проверяется только после завершения задачи - то есть по сроку не сработает никогда, потому что задача как раз и не завершена.
Сообщение и ошибка
Событие-сообщение передаёт данные или управление между пулами: на схеме это пара кружков с конвертом, соединённых пунктиром. Один участник бросает, второй ловит. Это единственный легальный способ связать два пула.
Событие-ошибка описывает не падение движка, а деловой исход, с которым подпроцесс не справился сам: контрагент не прошёл проверку, комплект документов неполный, лимит исчерпан. Ошибка всплывает наружу, ловится граничным событием у родительского процесса, и вся логика обработки лежит там.
// Различать эти два вида отказов обязательно. Технический сбой - недоступную базу, таймаут вызова - обрабатывает инфраструктура повторами, и на схеме бизнес-процесса ему не место. Деловой исход обязан быть на схеме, потому что решение по нему принимает бизнес, а не дежурный инженер.
Гонка событий и хвосты
Процесс ждёт ответа партнёра, но не дольше суток. Кто первый - тот и определяет дальнейший путь. Это гонка, и для неё есть отдельный элемент: событийный шлюз. За ним стоят несколько ловящих событий, срабатывает первое, остальные снимаются.
Другие конструкции здесь дают не то поведение. Последовательные события ждали бы сначала одного, потом второго. Параллельный шлюз дождался бы обоих, а таймер срабатывает всегда - значит процесс не двинется, пока не пройдут сутки, даже если партнёр ответил через минуту.
// Гигиена схемы: у каждой ветки есть завершающее событие. Оборванная ветка оставляет токен на доске, экземпляр числится незавершённым, висит в списках месяцами и портит статистику по длительности - средний срок процесса уезжает в бесконечность из-за трёх забытых хвостов.
Как отвечать: «Согласование должно уходить руководителю, если не сделано за три дня»
Вешаю на задачу согласования граничное прерывающее событие-таймер на три дня. Срок истёк - задача снимается у исполнителя, поток уходит по ветке эскалации к руководителю; согласовали раньше - таймер снимается вместе с задачей, и процесс идёт обычным путём. Отдельной задачей «проверить срок» это делать не стоит: её кто-то должен выполнять, а время идёт само. Условие на исходящей стрелке тоже не подойдёт - оно проверяется после завершения задачи, а задача как раз и висит. Если бизнесу нужно не забирать работу, а напомнить, беру непрерывающий вариант: он рождает параллельную ветку с уведомлением, а задача остаётся у того же человека. Часто просят оба сразу: напоминание на первый день, эскалация на третий.
Кандидат даёт точную конструкцию, объясняет, почему альтернативы не работают, и различает прерывающий и непрерывающий варианты.
На чём валятся
- −− Заводят отдельную задачу проверки срока вместо граничного таймера.
- −− Вешают условие на исходящую стрелку, ожидая срабатывания по времени.
- −− Берут прерывающий таймер там, где нужно всего лишь напомнить.
- −− Путают событие-ошибку с техническим сбоем движка.
- −− Ставят параллельный шлюз вместо событийного - таймер срабатывает всегда.
- −− Оставляют ветку без завершающего события и получают вечно незакрытые экземпляры.
Проверьте себя
Пять вопросов из банка по этой подтеме. Всего их 13, остальные разбираются в тренажёре.
- Согласование должно уходить руководителю, если не выполнено за три дня. Как это выразить?A)Отдельной задачей проверки срокаB)Комментарием к задаче на схемеC)Граничным таймером на задаче согласованияD)Условием на исходящем потоке задачи
показать ответ и разбор
+C)Граничным таймером на задаче согласования// разбор: Таймер на границе задачи — штатный и самый читаемый способ выразить срок: истёк — поток уходит на эскалацию, не истёк — процесс идёт своим чередом. Отдельная задача проверки требует, чтобы кто-то её выполнял, а условие на потоке проверяется только после завершения задачи, то есть никогда не сработает.
- Что означает событие-ошибка в подпроцессе?A)Сбой сервера при выполнении процессаB)Ошибку в самой схеме процессаC)Отказ движка выполнять подпроцессD)Деловую ситуацию, обрабатываемую снаружи
показать ответ и разбор
+D)Деловую ситуацию, обрабатываемую снаружи// разбор: Событие-ошибка описывает не технический сбой, а деловой исход, который подпроцесс обработать не может: контрагент не прошёл проверку, документов не хватает. Оно всплывает наружу и ловится граничным событием у родителя, где и находится логика обработки.
- Процесс должен ждать либо ответа партнёра, либо истечения суток. Чем это выразить?A)Двумя последовательными событиямиB)Событийным шлюзом с двумя веткамиC)Параллельным шлюзом с ожиданиемD)Циклом с проверкой каждый час
показать ответ и разбор
+B)Событийным шлюзом с двумя ветками// разбор: Событийный шлюз ждёт первое из нескольких событий: пришло сообщение — идём по одной ветке, сработал таймер — по другой. Вторая ветка после этого отменяется. Именно эта конструкция описывает ожидание с предельным сроком, которое иначе выражается громоздко и с ошибками.
- Почему у каждой ветки процесса должно быть завершающее событие?A)Так требуют правила оформления схемB)Иначе схема не пройдёт валидацию редактораC)Иначе непонятно, где экземпляр завершаетсяD)Иначе движок не сможет её загрузить
показать ответ и разбор
+C)Иначе непонятно, где экземпляр завершается// разбор: Висящая ветка оставляет токен в неопределённом состоянии: экземпляр процесса формально не закончен, висит в списках и портит статистику по длительности. При разборе такие хвосты выглядят как незакрытые заявки, которых на самом деле давно нет. Явное завершение делает жизненный цикл однозначным.
- Что стоит проверить в схеме перед передачей её в разработку?A)Одинаковый размер всех элементовB)Тупики и незакрытые ветвленияC)Количество шагов в каждой дорожкеD)Наличие подписи автора на схеме
показать ответ и разбор
+B)Тупики и незакрытые ветвления// разбор: Основные дефекты схем однотипны: несимметричные шлюзы, ветки без завершения, шлюз без ветки «иначе», задача без исполнителя. Каждый из них превращается в зависший экземпляр в проде. Полезно прогнать схему по чек-листу и мысленно провести токен по всем путям.
дальше
Теорию прочитали. Навык ставится повторением
В Сеньорчике эта подтема идёт в ежедневных сессиях: движок возвращает её, пока ответы не станут уверенными, и ведёт прогресс отдельно по каждой подтеме. Теория внутри тоже бесплатна, лимит только на количество вопросов в день.