книги / Построение моделей бизнес-процессов
..pdf
Рис. 68. Представление параллельных действий
Подпроцессы могут быть встроенными (embedded) и повторно используемыми, глобальными (global). Встроенный подпроцесс является частью родительского и известен только внутри него, и не может использоваться повторно. В качестве стартового события встроенного подпроцесса может быть только одно и только неопределенного типа (простое) событие. Допускается отсутствие стартового и конечного событий в развернутом подпроцессе. Данные, определенныев родительском процессе, доступныподпроцессу.
Простой пример применения встроенного подпроцесса показан на рис. 69. Здесь представлен подпроцесс в раскрытом виде с прикрепленным событием Эскалация. Наступление этого события прерывает действия операциониста (его подпроцесса) и направляет поток к менеджеру.
Глобальный подпроцесс представляет собой отдельный модуль, разрабатываемый независимо от вызывающего процесса и известный глобально. Он может использоваться многократно путем вызова из разных процессов, что реализуется действием «Вызов». В момент вызова управление передается глобальному (внешнему) подпроцессу, а по его завершении возвращается родительскому процессу. Стартовым и конечным событиями глобального подпроцесса могут быть только события неопределенного типа (простые).
Пример процесса с разными подпроцессами приведен на рис. 70.
81
Рис. 69. Банковский процесс обработки кредитной заявки
Рис. 70. Процесс выполнения заказа поставщиком
На данной диаграмме использованы элементы раскрытого встроенного подпроцесса «Доставить заказ» и свернутого глобального подпроцесса «Принять оплату». Очевидно, что на фирме действие принять оплату имеет место и в других процессах и поэтому оно оформлено как внешний подпроцесс.
Теперь рассмотрим другой вариант процесса выполнения заказа на поставку товара (рис. 71). Получение заказа запускает про-
82
цесс. Проверяется возможность выполнения заказа (наличие товара). Если товар есть, его отправляют клиенту и затем производят с ним финансовые расчеты. Последнее действие есть встроенный подпроцесс, представленный в свернутом виде, детали которого не раскрываются. Если заказанного товара нет, возникает необходимость доставить нужный товар. Для получения товара действие Вызов запускает внешний подпроцесс Procureуment, обеспечивающий поставку товара. Во время его выполнения возможны задержки исполнения или ошибки, на что указывают события на границе действия. Задержку улавливает непрерывающее событие Эскалация, наступление которого инициирует дополнительный поток, идущий к действию информировать клиента о задержке. При этом процесс не прерывается, и токен остается в действии Вызов до его завершения или появления ошибки. Наступление события Ошибка прерывает дальнейшее выполнение процесса, и основной поток (и токен) направляется от этого события к действиям «информировать клиента» и «удалить отсутствующий товар из каталога», после выполнения которых процесс завершается.
Рис. 71 . Процесс поставки товара
Глобальный подпроцесс Procurement приведен на рис. 72. Его исполнение начинается с проверки наличия поставщика требуемого
83
товара. Если такового нет, генерируется ошибка. Если же поставщик есть, то при возможном сроке поставки не более 2 дней оформляется заказ поставщику и по получении товара, что фиксируется промежуточным событием получение сообщения, процесс завершается. При большей задержке генерируется Эскалация и далее ожидается поступление товара. Генерируемые триггеры улавливаются соответствующими обрабатывающими их событиями, прикрепленнымик границе действияВызов(см. рис. 71).
Рис. 72. Подпроцесс Procurement
Другой процесс, в котором тоже использован подпроцесс Procurement, показан на рис. 73. Это процесс управления запасами. Процесс запускается, когда уровень запасов становится меньше минимально допустимого. Затем вызывается глобальный подпроцесс, исполнение которого приводит к поставке товара (пополнению запасов), и процесс успешно завершается. При невозможности поставки активируется событие Ошибка и поток перенаправляется к действию «удалить товар из каталога», после выполнения которого фиксируется неуспешное завершение процесса.
Помимо рассмотренных подпроцессов спецификация BPMN определяет такой вид подпроцесса, как событийный. Событий-
84
ный подпроцесс это специфический подпроцесс, используемый внутри процесса или подпроцесса. Он не является частью стандартного потока операций, включенного в родительский процесс, и не имеет входящих или исходящих потоков операций. Более того, он запускается не потоком операций процесса как встроенный подпроцесс, а только своим стартовым событием. Графическое изображение событийного подпроцесса отличается от других подпроцессов границей в виде тонкой пунктирной линии.
Рис. 73. Процесс управления запасами
Событийный подпроцесс может не запускаться ни разу или запускаться один и более раз в ходе выполнения родительского процесса. Стартовое событие событийного подпроцесса может быть только одним из следующих типов: Сообщение, Ошибка, Эскалация, Компенсация, Условие, Сигнал, Множественный. Событийный подпроцесс может иметь более одного стартового события. Запуск событийного подпроцесса может привести к следующим последствиям в родительском процессе: а) родительский процесс прерывается, б) родительский процесс продолжает выполняться без прерывания. То, каким будет результат, определяется типом наступившего стартового события.
Рассмотрим примеры, иллюстрирующие применение событийных подпроцессов.
85
На рис. 74 показан фрагмент процесса с встроенным подпроцессом, содержащим событийный подпроцесс. Триггером стартового события событийногоподпроцессаявляется Компенсация.
Рис. 74. Событийный процесс для компенсации
После выполнения родительского подпроцесса, в результате которого будет зарезервирован товар, может поступить отказ. В этом случае промежуточным событием генерируется триггер компенсации, который улавливается стартовым событием событийного подпроцесса и запускает его, прерывая выполнение родительского подпроцесса. При этом событийный подпроцесс выполняет компенсацию – отменяет резервирование.
Следующий пример иллюстрирует ситуацию с двумя событийными подпроцессами, входящими в один встроенный (родительский) подпроцесс (рис. 75).
Некто пригласил друзей к себе на обед, затем составил меню и стал готовить еду. Во время приготовления еды может поступить сообщение о желании не приглашенного ранее друга прийти в гости. Это сообщение запускает событийный подпроцесс без прерывания родительского, и пригласивший корректирует количество необходимой еды. Данный событийный подпроцесс будет выполняться столько раз, сколько придет подобных сообщений во время выполнения родительского подпроцесса. Если во время приготовления возникла неисправимая проблема (выключили электричество или сильно подгорела еда), вырабатывается Ошибка и запуска-
86
ется событийный подпроцесс с прерыванием приготовления еды и выполнением заказа еды на стороне.
Рис. 75. Процесс «Приглашение на обед»
Третий пример приведен на рис. 76. На нем представлена основная часть диаграммы процесса заказа путешествия. Перед бронированием считывается информация с кредитной карты. Подпроцесс бронирования обеспечивает заказ авиабилета и бронирование номера в отеле, и содержит 3 событийных подпроцесса. Во время выполнения этого подпроцесса может поступить сообщение об изменении данных кредитной карты, которое запускает событийный подпроцесс обновления информации по карте. После выполнения подпроцесса Заказ производится оплата с карты, и весь процесс успешно завершается. Если оплата не удалась, граничное событие Ошибка перенаправляет поток к промежуточному генерирующему событию Компенсация. Триггер последнего улавливает стартовое событие Компенсация событийного подпроцесса, и оно запускает
87
этот подпроцесс. Выполнение событийного подпроцесса компенсации приводит к генерации промежуточными событиями триггеров компенсации и обновлению записи клиента. Эти триггеры активируют граничные события действий, выполнивших заказ, которые вызывают соответствующие обработчики компенсаций, обеспечивающие отмену заказа как билета, так и отеля. Далее поток операций процесса подходит к эксклюзивному шлюзу и в зависимости от лимита повторений процедуры заказа либо возвращается на начало процедуры (получение данных по кредитной карте), либо запускает задачу информированияклиентао неудаче, ипроцесс завершается.
Рис. 76. Процесс «Заказ путешествия»
Во время бронирования может возникнуть ситуация, когда не удается забронировать отель или билет (недоступен сайт, сбой программы и т.п.). Тогда вырабатывается ошибка, на которую
88
реагирует событийный подпроцесс со стартовым событием Ошибка. Он генерирует триггеры компенсации, обрабатываемые граничными событиями действий заказа. В результате вызываются обработчики компенсации, и успешно завершенные действия отменяются. Этот подпроцесс завершается событием, генерирующим вторую ошибку, которую обрабатывает граничное событие основного подпроцесса Заказ. Поток от граничного события направляется либо на начало основного подпроцесса, либо при достижении лимита повторений заказа – на информирование клиента о невозможности заказа, и весь процесс завершается.
Нотация BPMN содержит особый вид подпроцесса, который называется Транзакция. Его графический элемент отличается границей, изображенной двойной сплошной линией. Подпроцесс может быть представлен на диаграмме как в свернутом, так и развернутом виде (рис. 77).
Подпроцессу Транзакция свойственно определенное поведение, контролируемое посредством протокола транзакции (например, WS-Transaction). Данный подпроцесс представляет собой совокупность логически связанных действий, которые либо все успешно завершаются, либо отменяются с откатом данных к исходным значениям. Как видно на рис. 77, выполнение подпроцесса Транзакция может закончиться однимиз следующих результатов:
1.Успешное завершение. Поток операций идет от подпроцесса к следующему действию родительского процесса.
2.Неуспешное завершение, транзакция прерывается промежуточным событием Отмена, что приводит к запуску действий отмены: будет выполнена компенсация определенных действий подпроцесса или произойдет возврат к процессу. Заметим, что промежуточное событие Отмена может использоваться только как прикрепленное к границе подпроцесса Транзакция.
Существует два механизма, способных сигнализировать об отмене транзакции:
а) поток операций транзакции достигает промежуточного события Отмена.
89
б) сообщение об отмене может быть получено посредством протокола транзакции, поддерживающего выполнение данной транзакции.
Рис. 77. Развернутый и свернутый подпроцесс Транзакция
3. Риск, опасность (Hazards). Появление риска означает, что какое-то действие в транзакции выполняется крайне неверно, и поэтому она не может ни удачно завершиться, ни вызвать отмену. Это исключительная ситуация обрабатывается прерывающим промежуточным событием Ошибка. При этом выполнение текущего действия прекращается без компенсации, а поток операций возобновляется от события Ошибка.
90