Условия и шлюзы
Потоки операций соединяют элементы процесса. Условия на потоках операций и шлюзы определяют, по какому пути пойдет процесс. В Jmix BPM условие можно задать выражением, результатом пользовательской задачи или результатом бизнес-задачи.
Потоки операций
Поток операций (sequence flow) — элемент BPMN, который задает порядок выполнения действий в бизнес-процессе. Он определяет логическое движение работы или информации от одного действия к другому и показывает, в какой последовательности должны выполняться задачи или подпроцессы.
Потоки операций соединяют два действия на диаграмме BPMN и показывают направление движения процесса и зависимости между действиями. Они играют важную роль в визуализации и моделировании хода работы в бизнес-процессе и помогают сделать модель процесса ясной и последовательной.
Графическое и XML-представление
Поток операций изображается стрелкой от исходного элемента к целевому. Стрелка всегда указывает на целевой элемент.
В XML-файле потоки операций представлены отдельными объектами среди других элементов BPMN:
<sequenceFlow id="Flow_1sjggq6" sourceRef="Event_15w11z6" targetRef="Gateway_0r2ejfv" />
В описании потока операций есть два атрибута XML: sourceRef и targetRef, которые ссылаются на элементы, где начинается и заканчивается стрелка.
Входящие и исходящие потоки
Поток операций соединяет два действия, поэтому для первого он исходящий, а для второго — входящий.
Рекомендуется, чтобы у каждого действия был только один входящий и только один исходящий поток.
В XML-файле ссылки на потоки операций видны в описании соответствующего элемента BPMN:
<task id="Activity_1pncn0v" name="Activity">
<incoming>Flow_1tncfsd</incoming>
<outgoing>Flow_1nxsuoi</outgoing>
</task>
Свойства потока операций
В моделере BPMN можно задать следующие свойства потока операций:
Свойство |
Описание |
Id |
Идентификатор элемента. Он генерируется автоматически, но его можно заменить на более понятный, чтобы логи было проще читать. |
Name |
Имя элемента. |
Condition source |
Источник условия: Expression, User task outcome или Business rule task result. См. Условия. |
Condition expression |
Условие для источника Expression. См. Выражения. |
User task id, User task outcome |
Пользовательская задача и ее результат для источника User task outcome. См. Результаты пользовательской задачи. |
Condition type |
Условие завершения для пользовательской задачи с множественным экземпляром. Доступно для источника User task outcome, если выбранная пользовательская задача выполняется как множественный экземпляр. См. Множественный экземпляр. |
Business rule task, Decision table output variable name, Decision table output value |
Задача бизнес-правила и ее результат для источника Business rule task result. См. Результат бизнес-задачи. |
Execution listeners |
См. Слушатели выполнения. |
Documentation |
Описание и дополнительные сведения об элементе. |
Условный поток операций
BPMN 2.0 определяет условный поток как отдельный элемент нотации. Графически он изображается как обычный поток операций с маленьким ромбом в начале соединительной линии, см. ниже:
Условный поток можно использовать только как исходящий поток действия. Условие вычисляется во время выполнения, чтобы определить, будет ли использован поток операций.
В Jmix BPM условие может быть у любого потока операций, но оно вычисляется и используется только там, где это нужно.
|
Использовать условные потоки крайне не рекомендуется из-за риска ошибок. Например, на рисунке выше процесс остановится, если условие равно false и других путей нет. |
Поток операций по умолчанию
У всех задач и шлюзов BPMN 2.0 может быть поток операций по умолчанию. Он выбирается только как исходящий поток операций действия или шлюза.
Поток операций по умолчанию изображается как обычный поток операций с косой чертой в начале.
Поведение потока по умолчанию зависит от элемента, с которым он используется. Условия на потоке операций по умолчанию всегда игнорируются.
Использование условных потоков и потоков по умолчанию
Хотя спецификация BPMN позволяет использовать условные потоки и потоки по умолчанию так, как на рисунке ниже, избегайте этого. Такая диаграмма хуже читается и становится неоднозначной.
Вместо условных потоков и потоков по умолчанию, исходящих из действия, лучше использовать шлюз:
В этом примере используется эксклюзивный шлюз, но возможны также параллельный и инклюзивный шлюзы.
Условия
Условие определяет, когда выбирается поток. В Jmix BPM условие можно задать из следующих источников:
-
Выражение (Expression)
-
Результаты пользовательской задачи (User task outcome)
-
Результат бизнес-задачи (Business rule task result)
|
В эксклюзивном шлюзе проверьте, что у каждого исходящего потока, кроме потока по умолчанию, есть условие. Шлюз считает пустое условие истинным и выбирает первый в порядке XML поток, условие которого истинно или пусто. Текстовая подпись над стрелкой для движка ничего не значит. |
Выражения
Это логическое выражение, которое может обращаться к переменным процесса и сравнивать их с литералами или другими переменными. В нем также можно вызывать методы бинов Spring.
Например:
${orderAmount > 1000}
${price > 100 && price <= 500}
${accountant.username == "jane"}
${jbt_MyService.getRandom > 0.5}
${jbt_MyService.evaluateCondition()}
В последнем случае метод должен возвращать значение типа boolean.
Результаты пользовательской задачи
Если в процессе есть пользовательская задача с результатами (outcomes), можно выбрать результат, который активирует этот поток.
Чтобы настроить условие на основе результата, выберите пользовательскую задачу, а затем результат.
Выбирая пользовательскую задачу для условия, убедитесь, что она выполняется до вычисления условия. Иначе во время выполнения возникнет ошибка.
Условия и пользовательская задача с множественным экземпляром
Если пользовательская задача выполняется как множественный экземпляр, появляется дополнительный параметр — condition type:
Доступны следующие варианты:
-
Anyone completed with the outcome
-
Everyone completed with the outcome
-
No one completed with the outcome
С помощью этого параметра можно организовать своего рода голосование.
Например, этот поток будет выбран, если хотя бы один пользователь выполнил задачу с результатом yes.
Результат бизнес-задачи
Задача бизнес-правила возвращает результат, который можно использовать в условии шлюза.
Чтобы настроить условие на основе результата бизнес-правила, выберите задачу бизнес-правила, выходную переменную таблицы решений и выходное значение.
Убедитесь, что выбранная задача бизнес-правила выполняется до шлюза.
Шлюзы
Шлюзы управляют ходом процесса: они определяют, при каких условиях процесс должен пойти по разным путям. Каждый тип шлюза направляет ход процесса по-своему, на основе условий или событий.
Шлюзы помогают моделировать точки принятия решений, ветвление, слияние и синхронизацию в процессе и позволяют точно представлять более сложные и динамичные процессы.
Типы шлюзов
Jmix BPM поддерживает четыре типа шлюзов BPMN:
-
Эксклюзивный шлюз
-
Параллельный шлюз
-
Инклюзивный шлюз
-
Шлюз на основе событий
Complex gateway не поддерживается.
Шлюзы разделения и слияния
Все шлюзы, кроме шлюза на основе событий, могут играть в модели процесса две роли:
-
Разделение (fork) — процесс разделяется на несколько путей;
-
Слияние (join) — пути объединяются.
Как правило, шлюзы разделения и слияния используются парами, но это не обязательно. Если процесс разделился, каждый путь может продолжаться до конечного события.
|
Шлюзы управляют ходом выполнения процесса, создавая или поглощая токены. |
Свойства шлюзов
В моделере BPMN можно задать следующие свойства шлюза:
Свойство |
Описание |
Id |
Идентификатор элемента. Он генерируется автоматически, но его можно заменить на более понятный, чтобы логи было проще читать. |
Name |
Имя элемента. |
Asynchronous execution |
Начиная с Jmix 3.1 |
Documentation |
Описание и дополнительные сведения об элементе. |
Эксклюзивный шлюз
Эксклюзивный шлюз (XOR-шлюз) используется, чтобы моделировать в процессе решение на основе данных, например значений переменных процесса или значений, которые возвращает метод бина.
Когда исполнение доходит до этого шлюза, все условия исходящих потоков операций вычисляются в том порядке, в котором определены потоки.
Для продолжения процесса выбирается первый поток операций, условие которого равно true. Пустое условие всегда считается равным true.
«Первый» здесь означает порядок, в котором потоки операций определены в теле XML-файла, а не обязательно порядок, в котором они перечислены в описании шлюза.
Это различие подчеркивает, что порядок потоков определяется структурой XML-файла, а не их визуальным представлением или текстовым описанием в шлюзе.
Эксклюзивные шлюзы часто называют вопросами, например «Документ согласован?». Но у самого шлюза нет никакой внутренней логики. Чтобы шлюз действительно работал, на исходящих потоках нужно задать условия. См. Условия.
Поток по умолчанию
Если один из исходящих потоков отмечен как поток по умолчанию (косой чертой), он выбирается, только когда условия всех остальных потоков равны false.
Если у потока по умолчанию есть условие, оно игнорируется.
При моделировании эксклюзивного шлюза настоятельно рекомендуется использовать поток по умолчанию. Но это не обязательно.
Использование эксклюзивного шлюза
Не совмещайте разделение и слияние
Формально спецификация BPMN позволяет использовать один шлюз в двух ролях, но так делать не рекомендуется.
Поэтому не используйте эксклюзивный шлюз так, как на рисунке, где шлюз одновременно разделяет и объединяет пути:
Лучше разделить роли между двумя шлюзами (один для слияния, другой для разделения), как на следующем рисунке:
Несколько истинных условий
В этом примере у эксклюзивного шлюза два условия, и оба очевидно истинны. Условие № 1 вычисляется первым, потому что в XML-файле процесса оно находится выше условия № 2. Однако в описании шлюза первым стоит условие № 2.
<process id="exclusion-gateway-demo" name="exclusion-gateway-demo" isExecutable="true">
<exclusiveGateway id="Gateway_0r2ejfv"> (3)
<incoming>Flow_1sjggq6</incoming>
<outgoing>Flow_2</outgoing>
<outgoing>Flow_1</outgoing>
</exclusiveGateway>
<endEvent id="Event_0kn6j1t" name="1">
<incoming>Flow_1</incoming>
</endEvent>
<sequenceFlow id="Flow_1" name="1 > 0" sourceRef="Gateway_0r2ejfv" targetRef="Event_0kn6j1t"> (2)
<extensionElements>
<jmix:conditionDetails conditionSource="expression" />
</extensionElements>
<conditionExpression xsi:type="tFormalExpression">${1>0}</conditionExpression>
</sequenceFlow>
<endEvent id="Event_1wmb937" name="2">
<incoming>Flow_2</incoming>
</endEvent>
<sequenceFlow id="Flow_2" name="2 > 0" sourceRef="Gateway_0r2ejfv" targetRef="Event_1wmb937"> (1)
<extensionElements>
<jmix:conditionDetails conditionSource="expression" />
</extensionElements>
<conditionExpression xsi:type="tFormalExpression">${2>0}</conditionExpression>
</sequenceFlow>
<startEvent id="Event_15w11z6">
<outgoing>Flow_1sjggq6</outgoing>
</startEvent>
<sequenceFlow id="Flow_1sjggq6" sourceRef="Event_15w11z6" targetRef="Gateway_0r2ejfv" />
</process>
| 1 | поток операций с условием № 1 |
| 2 | поток операций с условием № 2 |
| 3 | раздел описания шлюза, поток № 2 перед № 1 |
Каскады эксклюзивных шлюзов
Эксклюзивный шлюз работает как оператор switch в программировании, а не как if.
У него может быть сколько угодно исходящих потоков.
Поэтому не стоит строить каскады шлюзов «да — нет»: для выбора нужного исходящего потока операций можно использовать более сложные условия.
Не моделируйте так:
Здесь два шлюза вычисляют простые условия Sky == blue и Sea == green. Если оба истинны, процесс идет дальше. Но модель выглядит сложной.
Более сложные условия позволяют обойтись без каскадов шлюзов:
На этом рисунке используется составное условие Sky == blue && Sea == green, поэтому нужен только один шлюз.
Параллельный шлюз
Параллельный шлюз (AND-шлюз) используется, чтобы разделить процесс на несколько параллельных путей или объединить несколько параллельных путей обратно в один.
Когда исполнение доходит до параллельного шлюза, процесс разделяется на столько путей, сколько у шлюза исходящих потоков.
Если есть параллельный шлюз слияния, процесс ждет, пока не будут выполнены все входящие потоки, то есть пока все параллельные пути не дойдут до шлюза слияния. Затем процесс продолжается после шлюза слияния.
На самом деле объединять параллельные пути не обязательно. У каждого из них может быть свое конечное событие. Но весь процесс завершается только после завершения всех параллельных путей.
Использование параллельного шлюза
Не совмещайте разделение и слияние
Не используйте один и тот же параллельный шлюз для разделения и слияния:
Формально это возможно, но крайне не рекомендуется.
Используйте каскады
Учтите, что параллельный шлюз не обязательно должен быть «сбалансированным» (с одинаковым числом входящих и исходящих потоков операций у соответствующих параллельных шлюзов).
Параллельный шлюз просто ждет все входящие потоки операций и создает параллельный путь выполнения для каждого исходящего потока операций, независимо от других конструкций модели процесса. Поэтому следующий процесс допустим в BPMN 2.0:
И эта модель тоже корректна:
Инклюзивный шлюз
Инклюзивный шлюз (OR-шлюз) можно рассматривать как сочетание эксклюзивного и параллельного шлюзов.
Как и в эксклюзивном шлюзе, на исходящих потоках операций можно задать условия, и инклюзивный шлюз их вычислит.
Но главное отличие в том, что инклюзивный шлюз, как и параллельный, может выбрать больше одного потока операций.
От параллельного шлюза он отличается тем, что ждет только те входящие потоки, которые будут выполнены (их условия истинны). После слияния процесс продолжается после инклюзивного шлюза.
В этом примере первый пользователь заполняет чек-лист, в котором отмечает, кто должен участвовать в согласовании. В отличие от параллельного процесса, задачу согласования получат только выбранные сотрудники.
Допустим, выбраны Accountant и Team leader. Тогда шлюз слияния будет ждать, пока оба не выполнят задачу.
Шлюз на основе событий
Шлюз на основе событий позволяет принимать решение на основе событий.
У шлюза на основе событий должно быть не меньше двух исходящих потоков операций. Каждый поток операций должен вести к промежуточному перехватывающему событию таймера, сообщения или сигнала.
Сразу после шлюза на основе событий никакие другие действия не допускаются.
Когда исполнение процесса доходит до шлюза на основе событий, шлюз работает как состояние ожидания: исполнение приостанавливается.
Кроме того, для каждого исходящего потока операций создается подписка на событие.
Процесс пойдет по пути того события, которое сработает первым.
Учтите, что потоки операций, исходящие из шлюза на основе событий, отличаются от обычных потоков операций. Эти потоки операций на самом деле никогда «не выполняются». Напротив, они позволяют движку процессов определить, на какие события должно подписаться исполнение, пришедшее в шлюз на основе событий.
Использование шлюза на основе событий
Типичный случай использования шлюза на основе событий — запрос к ненадежному внешнему сервису. Этот сервис может отказать или вернуть ошибку в любой момент, когда процесс отправляет запрос.
Со шлюзом на основе событий это можно смоделировать так, как показано на рисунке:
В этом примере сервисная задача отправляет запрос в сервис, а затем процесс доходит до шлюза на основе событий — состояния ожидания.
Здесь возможны три варианта:
-
Success — получено сообщение OK, и процесс продолжает обычный путь.
-
Failure — получено сообщение об ошибке, и его можно обработать. При необходимости для разных ошибок можно использовать разные сообщения.
-
Timeout — время истекло, и нужно решить, что делать, например повторить запрос.
Такой шаблон делает диаграмму понятнее.