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. В случае отсутствия последующих активных Действий экземпляр Подпроцесса/Процесса считается выполненным.
Под рамками подразумевается контекст, в котором осуществляется выполнение Действия. Сюда входят:
Вообще, рамками обособлена одна основная цепочка Действий, берущая начало в крайнем пункте (на границе). И наоборот, все Действия заключены в рамки, которые могут быть вложены в иерархическом порядке.
В ходе выполнения рамки могут иметь несколько своих экземпляров. Они также вкладываются в иерархическом порядке в соответствии с тем, когда были сформированы. В каждом экземпляре рамок могут действовать несколько токенов.
Жизненный цикл экземпляра рамок, в свою очередь, может быть:
В BPMN описаны графические элементы диаграммы, которые могут быть заключены в рамки, а именно:
Рамками определяется семантика:
Заключенные в границы Объекты данных, События и родственные им элементы (correlation keys) могут отображаться на диаграмме или быть скрыты.