Схема маршрутизации шлюза
Маршрутизация запросов к нескольким службам или нескольким экземплярам служб с помощью одной конечной точки. Шаблон полезен при желании:
- Предоставление нескольких служб в одной конечной точке и маршрутизация в соответствующую службу на основе запроса
- Предоставление нескольких экземпляров одной службы в одной конечной точке для балансировки нагрузки или целей доступности
- Предоставление разных версий одной и той же службы в одной конечной точке и маршрутизации трафика между различными версиями
Контекст и проблема
Если клиенту необходимо использовать несколько служб, несколько экземпляров служб или сочетание обоих служб, клиент должен обновляться при добавлении или удалении служб. Рассмотрим следующие сценарии.
- Несколько разрозненных служб . Приложение электронной коммерции может предоставлять такие службы, как поиск, отзывы, корзина, проверка и журнал заказов. В каждой службе реализован отдельный API-интерфейс, с которым должны взаимодействовать клиенты. При этом каждый клиент должен иметь информацию обо всех конечных точках для подключения к этим службам. Если изменяется любой API, приходится обновлять все клиенты. Если вы разделяете одну службу на две или несколько служб, приходится изменять код в самой службе и во всех клиентах.
- Несколько экземпляров одной и той же службы . Системе может потребоваться выполнение нескольких экземпляров одной службы в одном или разных регионах. Выполнение нескольких экземпляров можно выполнять для балансировки нагрузки или для удовлетворения требований к доступности. Каждый раз, когда экземпляр выполняется вверх или вниз по требованию, клиент должен обновляться.
- Несколько версий одной и той же службы. В рамках стратегии развертывания новые версии службы можно развертывать вместе с существующими версиями. Это называется голубым зеленым развертыванием. В этих сценариях клиент должен обновляться при каждом изменении процента трафика, который направляется в новую версию и существующую конечную точку.
Решение
Установите шлюз перед набором приложений, служб и развертываний. Используйте маршрутизацию на уровне приложений (уровень 7) для передачи запросов в соответствующие экземпляры.
В этом шаблоне клиентское приложение должно только знать о одной конечной точке и взаимодействовать с одной конечной точкой. Ниже показано, как шаблон маршрутизации шлюза решает три сценария, описанные в контексте и разделе проблем.
Несколько разрозненных служб
Шаблон маршрутизации шлюза полезен в этом сценарии, когда клиент использует несколько служб. Если служба консолидирована, разложена или заменена, клиент не обязательно требует обновления. Он может по-прежнему направлять запросы в шлюз, а изменения затронут только маршрутизацию.
Кроме того, шлюз обеспечивает абстракцию серверных служб для клиентов. Это позволяет использовать несложный формат запросов и вносить любые изменения в серверные службы за шлюзом. Запросы от клиента можно направлять для обработки в любую службу или несколько служб в зависимости от ситуации. При этом вы можете свободно добавлять, разделять или реорганизовывать службы, ничего не изменяя в клиенте.
Несколько экземпляров одной службы
Эластичность является ключевым фактором в облачных вычислениях. Службы можно спянуть до удовлетворения растущего спроса или сложить вниз, когда спрос низкий, чтобы сэкономить деньги. Сложность регистрации и отмены регистрации экземпляров служб инкапсулируется в шлюзе. Клиент не знает о увеличении или снижении количества служб.
Экземпляры служб можно развертывать в одном или нескольких регионах. Шаблон geode описывает, как многорегионное, активное развертывание может повысить задержку и повысить доступность службы.
Несколько версий одной службы
Этот шаблон можно использовать для развертываний, позволяя управлять развертыванием обновлений для пользователей. Когда вы развертываете новую версию службы, она может работать параллельно с предыдущей. С помощью маршрутизации вы можете предоставлять клиентам разные версии службы, позволяя гибко применять разные стратегии обновления: добавочное, параллельное или полное развертывание выпусков. Если после развертывания новой версии службы возникнут проблемы, вы сможете быстро отменить любые изменения с помощью маршрутизации, и эти изменения никак не затронут клиенты.
Проблемы и рекомендации
- Служба шлюза может ввести одну точку сбоя. Убедитесь, что он правильно разработан для удовлетворения требований к доступности. Рассмотрите возможности устойчивости и отказоустойчивости в реализации.
- Служба шлюза может привести к узким местам. Убедитесь, что шлюз достаточно производителен для планируемой нагрузки и что его будет легко масштабировать в соответствии с ожидаемым темпом роста.
- Выполните нагрузочное тестирование шлюза, чтобы исключить возможность каскадных сбоев служб.
- Маршрутизация шлюза выполняется на 7-м уровне. Для этого можно использовать IP-адреса, порты, заголовки запросов и (или) URL-адреса.
- Службы шлюза могут быть глобальными или региональными. Azure Front Door — это глобальный шлюз, а Шлюз приложений Azure — региональный. Используйте глобальный шлюз, если для решения требуется развертывание служб с несколькими регионами. Рассмотрите возможность использования Шлюз приложений, если у вас есть региональная рабочая нагрузка, требующая детального управления балансировкой трафика. Например, необходимо сбалансировать трафик между виртуальными машинами.
- Служба шлюза — это общедоступная конечная точка для служб, которые она находится перед. Рассмотрите возможность ограничения доступа к серверным службам общедоступной сети, делая службы доступными только через шлюз или через частную виртуальную сеть.
Когда следует использовать этот шаблон
Используйте этот шаблон в следующих случаях:
- если клиенту нужно использовать несколько служб, доступ к которым возможен через шлюз;
- Вы хотите упростить клиентские приложения с помощью одной конечной точки.
- если вам нужно перенаправлять на виртуальные внутренние конечные точки запросы, поступающие на конечные точки, которые доступны из внешних сетей (например, чтобы предоставить доступ к портам виртуальной машины через IP-адреса виртуального кластера).
- Клиент должен использовать службы, работающие в нескольких регионах, для получения преимуществ задержки или доступности.
- Клиенту необходимо использовать переменное число экземпляров службы.
- Вы хотите реализовать стратегию развертывания, в которой клиенты обращаются к нескольким версиям службы одновременно.
Такая схема не очень удобна, если вы используете простое приложение для доступа всего к одной или двум службам.
Проектирование рабочей нагрузки
Архитектор должен оценить, как шаблон маршрутизации шлюза можно использовать в проектировании рабочих нагрузок для решения целей и принципов, описанных в основных принципах платформы Azure Well-Architected Framework. Например:
| Принцип | Как этот шаблон поддерживает цели основных компонентов |
|---|---|
| Решения по проектированию надежности помогают рабочей нагрузке стать устойчивой к сбоям и обеспечить восстановление до полнофункционального состояния после сбоя. | Маршрутизация шлюза позволяет маршрутизировать трафик только к здоровым узлам в системе. |
Как и любое решение по проектированию, рассмотрите любые компромиссы по целям других столпов, которые могут быть представлены с этим шаблоном.
Пример
Ниже приведен простой пример файла конфигурации для сервера, на котором Nginx выполняет функции маршрутизатора и передает запросы к приложениям, размещенным в разных виртуальных каталогах на разных компьютерах серверной части.
server < listen 80; server_name domain.com; location /app1 < proxy_pass http://10.0.3.10:80; >location /app2 < proxy_pass http://10.0.3.20:80; >location /app3 < proxy_pass http://10.0.3.30:80; >> Для реализации шаблона маршрутизации шлюза можно использовать следующие службы Azure:
- Экземпляр Шлюз приложений, обеспечивающий маршрутизацию регионального уровня 7.
- Экземпляр Azure Front Door, который обеспечивает глобальную маршрутизацию уровня 7.
Связанные ресурсы
- Схема отдельных серверных частей для каждого интерфейса
- Схема агрегирования на шлюзе
- Схема разгрузки шлюза
Нотация BPMN
Нотация BPMN (Business Process Model and Notation — модель бизнес-процессов и нотация) используется для описания процессов нижнего уровня. Диаграмма процесса в нотации BPMN представляет собой алгоритм выполнения процесса. На диаграмме могут быть определены события, исполнители, материальные и документальные потоки, сопровождающие выполнение процесса. Каждый процесс может быть декомпозирован на более низкие уровни. Декомпозиция может производиться в нотациях BPMN или EPC. При декомпозиции процесса BPMN, расположенного на диаграмме SADT, стрелки с диаграммы SADT на диаграмму BPMN не переносятся.
В нотации BPMN выделяют пять основных категорий элементов:
элементы потока (события, процессы и шлюзы);
данные (объекты данных и базы данных);
соединяющие элементы (потоки управления, потоки сообщений и ассоциации);
зоны ответственности (пулы и дорожки);
артефакты (сноски).
| Название | Кнопка | Графический символ | Описание |
|---|---|---|---|
| Процесс (Задача, Подпроцесс) |  |
  |
Блок представляет собой процесс — действие или набор действий, выполняемых над исходным объектом (документом, ТМЦ и прочим) с целью получения заданного результата. Внутри блока помещается наименование процесса. Временная последовательность выполнения процессов задается расположением процессов на диаграмме слева направо (сверху вниз на вертикальной диаграмме процесса BPMN). Процессы BPMN подразделяются на задачи и подпроцессы. |
Задача — это простое действие (или операция), которое не имеет дальнейшей декомпозиции в рамках рассматриваемого процесса. Задачи подразделяются на типы, каждый из которых (за исключением абстрактной задачи) обозначается своим маркером в левом верхнем углу блока задачи:
— Абстрактная задача (задача с неопределенным типом);
— Пользовательская задача (задача, которую выполняет человек при содействии других людей или программного обеспечения);
— Сервисная задача (задача, предназначенная для оказания услуги, которая может являться как web-сервисом, так и автоматизированным приложением);
— Отправка сообщений (задача, суть которой заключается в отправлении сообщения внешнему участнику за пределы рассматриваемого процесса);
— Получение сообщений (задача, суть которой заключается в получении сообщения от внешнего участника, находящегося за пределами рассматриваемого процесса);
— Ручное выполнение (задача, выполнение которой подразумевает действия человека и исключает использование каких-либо автоматизированных механизмов исполнения или приложений);
— Бизнес-правило (задача, суть которой заключается в выполнении бизнес-правила);
— Задача-сценарий (задача, суть которой заключается в выполнении некоторого сценария (или скрипта) — некоторой автоматической операции).
По умолчанию создается Задача с типом «Абстрактная задача».
На Рис.1 изображена задача с типом «Отправка сообщений».
Рисунок 1. Задача
Подпроцесс — это декомпозированный процесс, включенный в состав рассматриваемого процесса, который описан более подробно на своей диаграмме. На диаграмме подпроцесс обозначается блоком со знаком «плюс» в центре нижней части фигуры. Подпроцессы подразделяются на типы:
— Подпроцесс (подпроцесс с неопределенным типом);
— Событийный подпроцесс (подпроцесс, не имеющий входящих и исходящих потоков управления. Событийный подпроцесс запускается всякий раз, когда его стартовое событие запускается во время выполнения родительского процесса);
— Транзакция (подпроцесс, состоящий из набора процессов, которые в совокупности представляют некий неделимый процесс: либо весь процесс выполняется полностью, либо не выполняется вообще. Транзакции используются тогда, когда необходимо выполнить несколько процессов, но при каких-то исключительных ситуациях необходимо «откатить» выполняемые процессы);
— Ad-Hoc процесс (подпроцесс, представляющий собой группу процессов, взаимодействие между которыми не поддаются строго регламентированным правилам. Определяется только набор процессов, однако, их последовательность и количество выполнений определяются исполнителями этих процессов).
По умолчанию создается подпроцесс с типом «Подпроцесс».
На Рис.2 изображен событийный подпроцесс.
Рисунок 2. Подпроцесс
Для процессов BPMN (и для задач, и для подпроцессов) предусмотрено обозначение циклического выполнения. Для процесса BPMN можно задать следующие типы циклов:
— Стандартный цикл (используется, когда количество циклов заранее неизвестно. Процесс будет выполняться в цикле, пока верно некоторое условие);
— Многоэкземплярный параллельный цикл (используется, когда количество циклов известно заранее. При этом экземпляры процесса будет выполняться параллельно);
— Многоэкземплярный последовательный цикл (используется, когда количество циклов известно заранее. При этом экземпляры процесса будет выполняться последовательно).
Для процесса BPMN можно задать специальный тип процесса — Компенсация. Некоторые процессы могут приводить к нежелательным результатам, которые следует отменить. Процессы-компенсации как раз предусмотрены для отмены результатов выполнения некоторого процесса. Процессы-компенсации не должны иметь входящих и исходящих потоков управления и могут соединяться входящей ассоциацией с граничным событием с типом «Компенсация». Пример соединения события и процесса с типом «Компенсация» специальным типом соединения «Ассоциация» см. в описании к элементу «Ассоциация», приведенному в данной таблице ниже.
Изменение типа задачи или подпроцесса, типа цикла или выбор для процесса типа «Компенсация» осуществляется при помощи подменю в контекстном меню, вызываемом от процесса на диаграмме. Подробнее об особенностях работы с процессами на диаграмме процесса в нотации BPMN см. в Руководство пользователя в статье Процессы.
Промежуточные события (обработчики) могут присоединяться к границе процесса. Такие события называются граничными. Граничное событие изображает событие, возникающее при выполнении процесса, к границе которого это событие присоединено. Причем граничное событие может прервать выполнение процесса — граничное прерывающее, и не прерывать — граничное непрерывающее. Граничное непрерывающее событие изображается пунктирными линиями.
На Рис.4 изображено использование граничного прерывающего события. Если при выполнении Процесса 1 возникнет Событие 2, то выполнение Процесса 1 прервется и на текущей диаграмме дальнейшее выполнение процесса будет происходить по потоку, исходящему от граничного события, т.е. начнется выполнение Процесса 3.
Рисунок 4. Граничное прерывающее событие
На Рис.5 изображено использование граничного непрерывающего события. Если при выполнении Процесса 1 возникнет Событие 2, то выполнение Процесса 1 продолжится. На текущей диаграмме дальнейшее выполнение процесса будет происходить по потоку, исходящему от граничного события, т.е. начнется выполнение Процесса 3. А также после выполнения Процесса 1 начнет выполняться Процесс 2
Рисунок 5. Граничное непрерывающее событие
Подробнее об особенностях работы с событиями на диаграмме процесса в нотации BPMN см. в Руководство пользователя в статье События.
На Рис.7 параллельный шлюз используется для слияния потоков управления или синхронизации параллельных веток выполнения процесса. Выполнение Процесса 3 запустится только тогда, когда выполнится и Процесс 1, и Процесс 2.
Подробнее об особенностях работы со шлюзами на диаграмме процесса в нотации BPMN см. в Руководство пользователя в статье Шлюзы.
Эксклюзивный шлюз может использоваться и для слияния потоков управления. В данном случае шлюз просто пропускает через себя все потоки управления без синхронизации. На Рис.9 Процесс 3 будет выполнен дважды: после выполнения Процесса 1 и после выполнения Процесса 2.
Подробнее об особенностях работы со шлюзами на диаграмме процесса в нотации BPMN см. в Руководство пользователя в статье Шлюзы.
Рисунок 10
Показать ветвление потоков управления подобно неэксклюзивному шлюзу можно при помощи условных потоков управления (Рис.19).
Неэксклюзивный шлюз может использоваться для слияния потоков управления. В данном случае шлюз может использоваться для синхронизации. На Рис.11 Процесс 3 будет выполнен только тогда, когда выполнится и Процесс 1, и Процесс 2.
Рисунок 11
Об особенностях работы со шлюзами на диаграмме процесса в нотации BPMN см. в Руководство пользователя в статье Шлюзы.
Рисунок 12
Об особенностях работы со шлюзами на диаграмме процесса в нотации BPMN см. в Руководство пользователя в статье Шлюзы.
Рисунок 13
Существует 2 типа шлюзов по событиям, которые могут быть использованы в начале процесса:
— эксклюзивный шлюз по событиям (для запуска процесса) (Рис.14);
— параллельный шлюз по событиям (для запуска процесса) (Рис.15).
В случае, когда шлюз по событиям используется для запуска процесса, у него не должно быть входящих связей.
Эксклюзивный шлюз по событиям (для запуска процесса) аналогичен обычному эксклюзивному шлюзу по событиям: событие, идущее после шлюза и возникшее первым, определяет дальнейший ход выполнения процесса.
На Рис.14 выполнение процесса начнется с возникновения одного из событий, идущих после шлюза:
— если первым возникнет Событие 1, то дальнейшее выполнение процесса будет осуществляться только по потоку управления, исходящему из этого события, т.е. выполнится Процесс 1;
— если первым возникнет Событие 2, то дальнейшее выполнение процесса будет осуществляться только по потоку управления, исходящему из этого события, т.е. выполнится Процесс 2.
Рисунок 14
При использовании параллельного шлюза по событиям (для запуска процесса) выполнение процесса запускается по всем возникшим событиям, идущим после шлюза.
На Рис.15 Процесс 1 и Процесс 2 будут выполнены, если возникнут события, идущие перед этими процессами.
Рисунок 15
Подробнее об особенностях работы со шлюзами на диаграмме процесса в нотации BPMN см. в Руководство пользователя в статье Шлюзы.
Все шлюзы в BPMN с примерами
Шлюзы в BPMN (gateways) это такие развилки, которые либо распараллеливают процесс на несколько потоков, либо собирают несколько потоков процесса в один.
Бизнес процесс — это последовательность действий, которая должна привести к созданию продукта или услуги. И нотация BPMN служит для моделирования именно таких процессов. Но! Иногда проще понять принцип работы того или иного инструмента на простых примерах, которые не имеют отношения к бизнесу, но зато всем знакомы. Чем я и воспользуюсь в данной статье.
Виды шлюзов BPMN
5 основных шлюзов
 |
Исключаю щий шлюз (эксклюзивный, Exclusive Gateway), « или/или » — выбор только одного пути; |
 |
Параллельный шлюз (Parallel Gateway), « и » — выбор всех путей; |
 |
Неисключающий шлюз (неэсклюзивный, Inclusive Gateway), « и/или » — выбор одного или нескольких; |
 |
Событийный шлюз (Event Gateway) — выбор первого события, которое случится; |
 |
Сложный шлюз (Complex Gateway) – прочие варианты. |
2 дополнительных шлюза
Эти шлюзы используются как стартовые элементы
 |
Эксклюзивный событийный шлюз (Exclusive Event-Based Gateway) — выбор одного из нескольких стартовых событий; |
 |
Параллельный событийный шлюз (Parallel Event-Based Gateway) — ожидание нескольких стартовых событий. |
Подробное описание шлюзов в BPMN с примерами
1. Шлюз «ИЛИ/ИЛИ» (исключающий, Exclusive Gateway)
Графически данный шлюз отображается так или так 
1.1 Расходящаяся развилка /шлюз «или/или»
На данном шлюзе можно выбрать только один путь, по которому процесс пойдет дальше.
Когда токен поступает в расходящийся шлюз «или/или», он проходит дальше по одному из выбранных путей.
Тот путь, который отмечен штрихом называется путь «по умолчанию» (на картинке выше — «Прямо»). Этот путь будет выбран в том случае, если никакое из условий на потоках не сработало. Он может показывать «благополучный» вариант (happy path), который надо выбрать в любом случае. Или, наоборот, дополнительный исключающий путь, который обрабатывает все нестандартные ситуации.
В приведенном выше примере, если путник пойдет, например, назад, то некая невидимая сила направит его прямо.
Если бы автор процесса захотел, чтобы нестандартное действие путника приводило к его телепортации домой, то нужно было бы добавить 4-й поток управления. Затем выбрать его потоком «по умолчанию» и направить к задаче «Телепортироваться домой».
Что такое токен? Представьте, что когда процесс начинается, то в стартовом событии появляется токен. Он будет путешествовать по процессу и показывать, где мы сейчас в нем находимся. Когда этот токен будет проходить через шлюзы, то в соответствии с заданными правилами, он будет выбирать, куда ему (или им, если количество токенов увеличится) нужно двигаться дальше. Подробнее см. видео
1.2 Сходящаяся развилка/ шлюз «или/или»
Когда в сходящийся шлюз поступает токен, он пропускает дальше тоже только один токен.
Сходящийся шлюз «или/или» позволяет избежать дублирования задач, которые будут общими для разбежавшихся веток процесса. На примере выше: если выбрал направление прямо или налево, то потом надо «Найти яблочного вора».
1.3 Сходящийся и одновременно расходящийся шлюз «или/или»
Сразу отмечу, что крайне не рекомендуется использовать одни и те же шлюзы в BPMN для обоих действий (сведение и разведение потоков). Это затрудняет чтение схемы и в некоторых случаях может приводить к нарушениям в логике.
Рассмотрим еще один пример, который проиллюстрирует эту проблему.
Предположим, что документ был определен как тип А. Когда токен поступит на шлюз №2, у нас не будет результата проверки, ведь она не выполнялась. Чтобы такая ситуация обработалась корректно, надо правильно отметить «поток по умолчанию». Но до этого момента нужно будет догадываться, что усложнит чтение и понимание схемы.
Как исправить эту ситуацию? Добавить еще один шлюз «или/или»:
Теперь шлюзы расставлены корректно, и схема читается без дополнительных усилий и траты времени на понимание хитрости с потоком по умолчанию.
Подробнее про исключающие шлюзы в BPMN с применением контекста можно прочитать в этой статье.
2. Шлюз «И» (параллельный, Parallel Gateway)
Графически данный шлюз отображается так
2.1 Расходящаяся развилка/ шлюз «И» (на схеме ниже — шлюз №1)
На данном шлюзе процесс распараллеливается и идет одновременно по всем исходящим потокам. Другими словами, один токен, вошедший в такой шлюз порождает вместо себя столько токенов, сколько потоков управления выходят из шлюза. На картинке ниже этих токенов генерируется два.
2.3 Сходящаяся развилка/ шлюз «И» (на схеме выше — шлюз №2)
Этот шлюз будет собирать токены, до тех пор, пока не соберет столько, сколько потоков в него входит. Затем данный шлюз сгенерирует один токен, который отправится дальше по процессу.
2.3 Сходящийся и одновременно расходящийся шлюз «и»
Если шлюз «и» является одновременно и собирающим, и разводящим потоки (что не рекомендуется делать по правилам хорошего стиля BPMN), то он будет действовать по сумме вышеописанных правил.
Рассмотрим такой шлюз на приведенной ниже схеме «Постановка спектакля». Сначала шлюз №2 дождется пока в него поступит количество токенов, равное количеству входящих потоков — 3. Затем, когда поступят все 3, он запустит по двум исходящим потокам по одному токену.
Какие ошибки возникают при совместном использовании шлюзов «или/или» и «и»?
Самая распространенная ошибка при совместном использовании исключающего и параллельного шлюза, это использовать их в паре:
В приведенном выше варианте шлюз №1 сгенерирует два токена, которые запустят выполнение задач 1 и 2. А после того как выполнится любая из задач 1 или 2, ее токен пройдет дальше на шлюз №2 «или/или», где будет сразу пропущен дальше, чтобы запустить выполнение задачи №3. Затем, когда выполнится оставшаяся задача, ее токен тоже пройдет дальше и снова инициирует выполнение задачи №3. Таким образом, задача №3 выполнится 2 раза.
А что если шлюзы поменять местами? Сначала будет выполнена только одна из задач, так как шлюз «или/или» выбирает только 1 поток управления, по которому он запустит токен. Затем шлюз №2 будет ждать второй токен, чтобы запустить процесс дальше. И так как второй токен не был сгенерирован, то задача №3 не будет выполнена никогда.
3. Шлюз «и/или» (неисключающий, inclusive Gateway)
Графически данный шлюз отображается так
3.1 Расходящаяся развилка/шлюз «и/или»
На данном шлюзе процесс может пойти по одному (обязательно) или нескольким потокам управления.
На схеме мы проверяем, какие существуют способы коммуникации и дальше пользуемся теми, которые доступны. То есть, если в базе указан телефон и e-mail, то мы свяжемся этими двумя способами.
3.2 Сходящаяся развилка/ шлюз «и/или»
Особенностью данного шлюза является то, что он «знает» сколько токенов ему нужно получить на вход, чтобы запустить процесс дальше. Если на расходящемся шлюзе сгенерируется два токена, то сходящийся дождется двух токенов и затем сгенерирует один исходящий.
А если в пути один из токенов завершит свое «существование», то сходящийся шлюз «и/или» ждать его не будет.
4. Событийный шлюз (Event-Based Gateway)
Графически событийный шлюз отображается так
На всех потоках, исходящих из этого шлюза, обязательно должны быть события (Message, Signal, Timer, Conditional). Когда токен поступает на такой шлюз, то для каждого исходящего потока управления создается свой токен. Они останавливаются на своих событиях и ждут, когда эти события случатся. Как только случается первое событие, все остальные токены автоматически «умирают».
«Кто первый встал — того и тапки! »
Также на потоках, исходящих из этого шлюза, могут располагаться Задачи, принимающие сообщение. Важно помнить, что согласно нотации на одном событийном шлюзе нельзя одновременно использовать и события с месседжем (кружочки со значком конверта), и задачи с месседжем (прямоугольники с конвертом). Пример:
5. Эксклюзивный событийный шлюз (Exclusive Event-Based Gateway).
Этот шлюз используется как стартовый элемент. Он похож на обычный событийный шлюз, но выглядит немного иначе (с одинарной круговой линией)
Часто в программах моделирования он встречается в виде стартового события (то есть без ромба вокруг):
В каком случае может использоваться данный шлюз/старт? Если у нас есть несколько стартовых событий, которые в дальнейшем приводят к выполнению одних и тех же задач в бизнес-процесса.
Однако, если вы просто отобразите два разных старта, то смысл будет тот же самый. Такой вариант получится нагляднее, и не нужно будет пояснять значение дополнительного элемента.
6. Параллельный событийный шлюз (Parallel Event-Based Gateway)
Параллельный событийный шлюз выглядит так:
Он редко встречается в программах моделирования, а если и встречается, то обычно в виде стартового события:
Когда в стартовом событии рождается токен, он всегда создает новый экземпляр процесса. И если стартовых событий несколько (или используется эксклюзивный событийный шлюз), то каждый раз, когда случается стартовое событие, создается новый экземпляр процесса. Можно провести такую аналогию: схема процесса — это класс, а экземпляр процесса — это конкретный объект класса. Или более бытовой пример: схема — это формочка для выпекания печенья, а экземпляры — сами печеньки ��
Параллельный событийный шлюз (или аналогичное стартовое событие) может пригодится в ситуации, когда нам надо в уже существующий экземпляр процесса «запустить » еще один токен, по другому событию. Например, необходимо передать документы курьеру, после того как их подготовят и после того как поступят деньги от клиента. То есть оба события должны наступить, но мы не знаем в каком порядке это случатся.
Допустим, клиент перечислил деньги. Создастся новый экземпляр процесса, в котором токен из события «Деньги перечислены » переместится в шлюз «и » и будет ждать там второго токена. Затем, когда мы подготовим документы, возможны два варианта. Либо будет создан второй экземпляр процесса (если это документы для другого клиента) . Либо в нашем первом экземпляре процесса токен из события «Документы готовы » тоже переместится к шлюзу «и ». Шлюз получит на вход 2 токена и сгенерирует новый токен, который побежит по процессу дальше. То есть начнет выполняться задача «Передать документы курьеру » .
Как параллельный событийный шлюз поймет, что нужно добавить токен в уже существующий экземпляр процесса, а не создать новый экземпляр? По контексту. Например, по номеру заявки который будет известен в каждом стартовом событии.
А вот как этот процесс мог бы выглядеть, если бы мы использовали Эксклюзивный событийный шлюз вместо параллельного:
7. Сложный шлюз (Complex Gateway)
Еще один редко используемый в BPMN шлюз. Отображается он так:
Этот шлюз используется в тех ситуациях, когда все остальные шлюзы не могут отобразить логику переходов. Его крайне не рекомендуется использовать, так как к нему либо нужны будут пояснения автор схемы.
Как можно изменить эту схему, чтобы она стала понятна без лишних комментариев? Например, так:
Заключение
Для большинства процессов согласовательного уровня рекомендуется использовать 2-3 вида шлюзов («или/или » , «и » , «и/или » ), так как в этом случае схемы легче читаются и понимаются. Однако, остальные шлюзы могут сильно выручить и упростить схему аналитического уровня, если правильно их применять. А при отрисовке схем исполнительного уровня следует помнить, что не все шлюзы в BPMN поддерживаются в различных BPMS и BPM движках. Например, в Camunda не поддерживаются эксклюзивный и параллельный событийные шлюзы. Чем отличаются BPMS и BPM движки, можно прочитать тут.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Назначение нотации BPMN
Нотация BPMN наиболее удобна для декомпозиции, для описания нижних уровней бизнес-процессов, особенно там, где требуется показывать действия участников процессов. Это объясняется самой сутью, методологией, лежащей в основе нотации – это методология workflow – поток работ.
То есть BPMN – это не просто структура процесса, функции, это алгоритм! Это уже не просто некое «до-аналитическое» предположение, что процесс состоит из «вот таких» блоков/функций, это уже четкая последовательность выполняемых действий ее конкретными участниками.
Система обозначений нотации BPMN
BPMN использует в качестве обозначений такие графические элементы, как:
- элементы потока (события, процессы и шлюзы);
- данные (объекты данных и базы данных);
- соединяющие элементы (потоки управления, потоки сообщений и ассоциации);
- зоны ответственности (пулы и дорожки);
- артефакты (сноски).
Процесс / задача
Процесс, задача – это определенное действие или набор действий, совершаемых для получения какого-то результата. Блок процесса или задачи представляет собой прямоугольник. Внутри блока указывается наименование процесса или задачи.
Подпроцесс – это процесс который описан более подробно, то есть декомпозирован, на отдельной своей диаграмме (модели).
В системе обозначений нотации BPMN есть еще разновидности процессов, такие как «цикл», «компенсация» и т.д. Мы не будем на них останавливаться, так как при более глубоком знакомстве с нотацией BPMN изучение этих блоков не представляет сложности, они интуитивно понятны.
Выделим, пожалуй, наиболее интересный блок – это блок ad-hoc процессов, потому что четкая, безальтернативная регламентация деятельности – это вопрос выбора модели компании, бизнеса. Смотря на шаг вперед, мы понимаем, что выбор будущего – это «бирюзовая модель» по классификации, введенной Фредериком Лалу, предполагающая если не отсутствие регламентов как таковых, то иной принцип их выработки и исполнения.
Ad-Hoc процесс – такой подпроцесс, действия которого не поддаются четко регламентированным правилам или алгоритмам, эти правила определяются исполнителем. Возможны варианты, когда есть заранее определенный набор действий для каких-либо случаев, но их последовательность, реальное исполнение – это выбор исполнителя.
События
Событие – это состояние, которое влияет или контролирует дальнейшее выполнение бизнес-процесса. Блок события в BPMN обозначается кругом. Внутри блока указывается наименование события.
Относительно точки выполнения процесса события делятся на:
- стартовое, обозначающее старт процесса
- промежуточное, произошедшее при выполнении процесса
- конечное, обозначающее завершение процесса
Любое событие может возникать из-за какой-то причины, а может инициировать само какой-то результат. Первые события называются – «обработчики», вторые – «инициаторами». Причина возникновения событий-обработчиков и результат процессов-инициаторов называется триггер.
События-обработчики — это все стартовые и некоторые промежуточные события. Если встречается событие-обработчик, то процесс ожидает наступления этого события, т.е. ожидает появления причины возникновения этого события. На диаграмме триггер внутри события, являющегося обработчиком, показывается незакрашенным.
События-инициаторы – это некоторые промежуточные события (включая промежуточное событие с типом «Неопределенное») и все конечные события. Если встречается событие-инициатор, то процесс просто выполняется дальше и ничего не ожидает. На диаграмме триггер внутри события, являющегося инициатором, показывается закрашенным.
Пример различных типов событий:
— Событие 1 — стартовое событие с типом триггера «Сообщение»;
— Событие 2 — промежуточное событие (обработчик) с типом триггера «Таймер»;
— Событие 3 — промежуточное событие (инициатор) с типом триггера «Сигнал»;
— Событие 4 — конечное событие с типом триггера «Сообщение».
Шлюзы
Параллельный шлюз (AND, «И») используется для обозначения слияния/ветвления потоков управления в рамках процесса.
Пример использования параллельного шлюза при ветвлении/разделении потоков:
В примере выше параллельный шлюз используется для ветвления потоков управления или создания параллельных веток выполнения процесса: после выполнения Процесса 1 запустится выполнение и Процесса 2, и Процесса 3.
Пример использования параллельного шлюза при слиянии потоков:
В примере выше параллельный шлюз используется для слияния потоков управления или синхронизации параллельных веток выполнения процесса. Выполнение Процесса 3 запустится только тогда, когда выполнится и Процесс 1, и Процесс 2.
Эксклюзивный шлюз
Эксклюзивный шлюз (XOR, «Исключающее ИЛИ») используется для ветвления потока управления на несколько альтернативных потоков, когда выполнение процесса зависит от выполнения некоторого условия.
Условия на диаграмме задаются при помощи условных потоков управления, исходящих из шлюза. При использовании эксклюзивного шлюза можно продолжить выполнение процесса только по одному из возможных условных потоков управления. Среди потоков управления, исходящих из эксклюзивного шлюза, допускается использование потока управления по умолчанию: если ни одно из условий не выполняется, дальнейшее выполнение процесса продолжится по потоку управления по умолчанию.
после выполнения Процесса 1 (рисунок выше) дальнейшее выполнение процесса может продолжиться только по одному потоку, исходящему из шлюза:
— если Условие 1 верно, то выполнится только Процесс 3;
— если Условие 2 верно, то выполнится только Процесс 4;
— если ни Условие 1, ни Условия 2 не верны, то выполнится только Процесс 2.
Эксклюзивный шлюз может использоваться и для слияния потоков управления. В данном случае шлюз просто пропускает через себя все потоки управления без синхронизации.
На рисунке выше Процесс 3 будет выполнен дважды: после выполнения Процесса 1 и после выполнения Процесса 2.
Неэксклюзивный шлюз
Неэксклюзивный шлюз (OR, «ИЛИ») используется для ветвления потока управления на несколько потоков, когда выполнение процесса зависит от выполнения условий. При этом каждое из указанных условий является независимым, и дальнейшее выполнение процесса может продолжиться сразу по нескольким потокам управления, если условия будут выполнены.
Условия на диаграмме задаются при помощи условных потоков управления, исходящих из шлюза. Среди потоков управления, исходящих из неэксклюзивного шлюза, допускается использование потока управления по умолчанию: если ни одно из условий не выполняется, дальнейшее выполнение процесса продолжится по потоку управления по умолчанию.
Неэксклюзивный шлюз может использоваться для ветвления и для слияния потоков управления.
На рисунке выше Процесс 3 будет выполнен только тогда, когда выполнится и Процесс 1, и Процесс 2 (пример слияния, или синхронизации).
Еще шлюзы
В BPMN различают также еще два типа шлюзов:
- комплексный шлюз
- эксклюзивный шлюз по событиям
Комплексный шлюз используется для ветвления потока управления на несколько потоков, когда выполнение процесса зависит от выполнения условий. По своему действию комплексный шлюз аналогичен неэксклюзивному шлюзу.
Эксклюзивный шлюз по событиям (XOR, «Исключающее ИЛИ») используется для ветвления потока управления на несколько альтернативных потоков, когда дальнейшее выполнение процесса зависит от возникновения некоторого события-обработчика, следующего после шлюза.
На рисунке выше после выполнения Процесса 1 дальнейшее выполнение процесса может продолжиться только по одной ветке, исходящей из шлюза:
— если первым возникло Событие 1, то выполнится только Процесс 2;
— если первым возникло Событие 2, то выполнится только Процесс 3.
Поток управления
Поток управления — стрелка используется для связи элементов потока BPMN (событий, процессов, шлюзов). Поток управления отображает ход выполнения процесса. При необходимости поток может быть именованным.
Стандартный поток управления является неконтролируемым, т.е. на поток не воздействуют никакие условия, и поток не проходит через шлюзы.
Условный поток управления — стрелка используется для отображения потока управления и используется тогда, когда необходимо показать, что по рассматриваемому потоку будет происходить дальнейшее выполнение процесса только в том случае, если выполнится условие, указанное в названии потока.
Поток управления по умолчанию — стрелка используется для отображения потока управления и используется тогда, когда необходимо показать, что по рассматриваемому потоку будет происходить дальнейшее выполнение процесса только в том случае, если не выполнилось ни одно из условий, заданных на условных потоках управления, исходящих из процесса или эксклюзивного/неэксклюзивного шлюза.
Другие обозначения
Поток сообщений — Стрелка используется для отображения межпроцессного взаимодействия — для связи элементов потока со свернутыми пулами. При необходимости поток может быть именованным.
Поток сообщений не отображает ход выполнения процесса, а показывает передачу сообщений или объектов из одного процесса в другой процесс или внешнюю ссылку.
Ассоциация — Стрелка используется для отображения связи объектов данных и баз данных с процессами. Связь может быть направленной и ненаправленной в зависимости от соединяемых элементов и типа связи.
Пул — предназначен для отображения потока рассматриваемого процесса. Содержимое пула — это и есть тот процесс, диаграмма которого рассматривается. На диаграмме развернутый пул может быть только один.
Дорожка — предназначена для отображения организационных единиц (должности, подразделения, роли, внешнего субъекта) — исполнителей задач и подпроцессов процесса BPMN. Внутри блока помещается наименование организационной единицы.
Свёрнутый пул — элемент, обозначающий внешний (по отношению к текущей диаграмме) процесс или внешнюю ссылку. Внутри блока помещается наименование внешнего процесса или внешней ссылки.
Объект данных — используется для отображения на диаграмме объектов деятельности, сопровождающих выполнение процесса. Рядом с блоком размещается наименование объекта данных.
В качестве объекта данных может использоваться объект любого из следующих справочников: Бумажный документ, Электронный документ, ТМЦ, Информация, Программные продукты, Термины, Прочее.
База данных — используется для отображения на диаграмме базы данных, сопровождающей выполнение процесса. Рядом с элементом размещается наименование объекта данных.
Набор объектов — используется для отображения на диаграмме наборов объектов, сопровождающих выполнение процесса. Рядом с элементом размещается наименование набора объектов.
Сноска — выносной элемент, предназначенный для нанесения текстовых комментариев. Элемент может быть использован на диаграммах процессов в любых нотациях.
Немного о правилах нотации
В нотации BPMN есть безусловные правила применения тех или иных блоков нотации: задач, стрелок, шлюзов, и так далее. Но есть и правила, о которых хотелось бы также сказать — правила методологические.
Сколько блоков задач/действий можно умещать на одной диаграмме/модели? С точки зрения нотации – сколько влезет, при чем в прямом смысле – столько, сколько сможете разместить блоков внутри пула процесса. Но с точки зрения анализа, есть не прописанное нигде правило, но которым пользуются аналитики: блоков задач/действий в одном процессе должно быть столько, чтобы не «уходить» на второй этаж пула.
То есть все действия одного процесса должны умещаться в линию в пуле, если в рамках одной дорожки действий слишком много и они не помещаются в линию, значит что-то не так с декомпозицией, это «излишнее» дробление на действия, скорее всего должно быть произведено на следующем уровне декомпозиции, включено в подпроцесс, свернуто и раскрыто в отдельной диаграмме.