Видеокурс Camunda 8: Сервисные задачи и шлюзы
Обзор
В рамках данного руководства рассматриваются вопросы:
-
Использование шлюза (Exclusive Gateway) в процессе;
-
Реализация сервисных задач (Service Task).
Это часть цикла "Изучаем Camunda 8 вместе с Reunico":
-
Предыдущая статья: Пользовательские задачи и экранные формы задач
-
Плейлист видеокурса по Camunda 8 на YouTube
Важно! Для выполнения практического задания необходим опыт разработки в среде Spring Boot.
Шлюзы
Шлюзы (Gateways) - это элементы, обеспечивающие ветвление процесса, или иначе говоря:
-
Принятие решения по условию (Exclusive Gateway, Inclusive Gateway);
-
Принятие решения по событию (Event Gateway);
-
Распараллеливание потоков управления (Parallel Gateway);
-
Объединение потоков (Parallel Gateway).
Нам понадобится добавить в процесс шлюз Exclusive Gateway, он же XOR-шлюз, он же "Развилка ИЛИ/ИЛИ".
Как работает этот шлюз?
При поступлении токена на шлюз данного типа, система проверяет условия, заданные на исходящих из шлюза стрелочках-потоках управления (Sequence Flow). В Camunda 8 такие потоки должны иметь условия (Conditions), записанные на языке FEEL (Friendly Enough Expression Language). Экземпляр процесса (токен) выберет первый поток управления, условие которого приобретет истинное значение (true).
В нашем примере мы будем проверять сумму кредита, находящуюся в переменной amount, и если сумма меньше 5000, вызывать сервисную задачу, иначе – оставлять принятие решения за человеком.
Сервисные задачи
Из первого урока "Введение в Camunda 8" мы узнали, что Camunda 8 - это оркестратор, который управляет не только действиями пользователей, но и вызовами методов, сервисов, приложений, API, систем, "умных" устройств IoT и систем принятия решений.
Иначе говоря - Camunda указывает:
-
Какие действия (активности) должны быть выполнены?
-
В каком порядке?
-
Кем?
-
При выполнении каких условий (или при наступлении какого события)?
Кроме того, Camunda позволяет сгруппировать действия (подпроцесс), обеспечить рекурсивность вызовов и скрыть реализацию (Call Activity), откатить выполненные действия (компенсация), распараллелить выполнение и многие другие функции, которые сложно реализовать при самостоятельной разработке SAGA-сервиса.
Если с пользовательскими задачами все понятно – они выполняются пользователем в Tasklist (или во внешнем приложении), то как же передать исполнение задачи системе или сервису?
На помощь приходит паттерн под названием Job Worker.
Job Worker (он же воркер, исполнитель) - это внешний компонент Camunda 8, состоящий из клиента Zeebe и метода, вызывающего бизнес-логику.
Алгоритм работы идентичен выполнению пользовательских задач. Если токен встречает задачу, имеющую тип реализации Job Worker:
-
Выполнение процесса приостанавливается;
-
Создается задача нужного типа (Job type);
-
Клиент Zeebe, подключаясь через gRPC, берет задачу в работу;
-
Вызывает необходимую бизнес-логику, передавая ей управление;
-
После того как бизнес-логика выполнена, клиент снова вызывает кластер Zeebe и сообщает о выполнении задачи (или о возникшем сбое / ошибке).
На сайте Camunda приведены различные способы реализации Job Worker'а. Вы можете разработать собственный клиент Zeebe или выбрать готовое решение под свой техстек. Мы же воспользуемся Spring Zeebe SDK, который предоставляет разработчикам Spring Boot максимально абстрактные и декларативные способы взаимодействия с кластером Camunda 8.
Практика
Ветвление процесса
Перетащим с панели элементов шлюз и добавим его перед задачей "Обработать заявку на кредит". Тип шлюза оставим по-умолчанию (Exclusive Gateway).
После добавления шлюза необходимо перетащить элемент "Задача" с панели элементов, добавить его параллельно пользовательской задаче, присвоить ей тип Service Task и соединить с шлюзом вторым потоком. Должна получиться диаграмма следующего вида:
Шлюзу рекомендуется присвоить имя в виде вопроса, который будет описывать суть принимаемого решения: "Сумма меньше 5000?"
Исходящим из шлюза потокам необходимо дать имена: >=5000, <5000 и прописать условия. Поскольку логика нашего шлюза бинарная (либо больше или равно 5000, либо меньше 5000), мы можем не прописывать условие на втором потоке, а пометить его через "гаечный ключ" потоком по-умолчанию (Default Flow).
Как работает Default Flow? Он будет вызван, если все другие потоки оказались ложными (false).
Таким образом:
-
На потоке <5000 необходимо задать выражение: amount < 5000;
-
Существующий поток, вызывающий пользовательскую задачу (>=5000) является выбранным по-умолчанию (Default Flow), если не отработает условие на нижнем потоке.
Сервисная задача
Для задачи "Обработать автоматически" необходимо задать ее тип (Job Type), который будет использоваться для назначения задачи нужному обработчику (Job Worker) = decision.
Процесс завершен, необходимо развернуть его в кластер Camunda.
Реализация Job Worker
Следующий шаг - разработка исполнителя задачи (Job Worker). Вы можете воспользоваться примером на базе Spring Boot, приведенном в обучающем видео или воспользоваться готовыми клиентами Zeebe.
Запуск процесса
После того, как Job Worker создан и выполняется, необходимо проверить корректность работы шлюза и сервисной задачи. Для того необходимо несколько раз запустить процесс, подав в качестве входных данных разные значения переменной amount:
- 3000
- 10000
- 1000

- В экземплярах процесса, где значение переменной amount 3000 и 1000, будет выполнена задача "Обработать автоматически" и процесс завершится после выполнения задачи.
- Экземпляр процесса, имеющий amount = 10000, создаст пользовательскую задачу "Обработать заявку на кредит", которую необходимо выполнить в Tasklist.
- После выполнения пользовательской задачи мы увидим в Operate, что все экзепляры процесса завершили свою работу.

Поздравляем! Теперь вы умеете создавать исполнителей (Job Worker) и использовать их в сервисных задачах!
Если в ходе выполнения урока возникли вопросы - приглашаем обсудить их на нашем форуме.
другие статьи
Смотреть всёВидеокурс Camunda 8: Создаем первый процесс
Видеокурс Camunda 8: User Tasks & Camunda Forms
Статья описывает, как управлять задачами пользователей в Camunda 8 или как сделать людей участниками исполняемого бизнес-процесса.