Видеокурс Camunda 8: DMN и оркестрация сервисов

Обзор

В этой статье рассматриваются вопросы:

• Нотация DMN (Decision Model and Notation);

• Использование бизнес-правил (Business Rule Task);

• Multi-instance задачи.

Это часть цикла "Изучаем Camunda 8 вместе с Reunico":

• Предыдущая статья: Сервисные задачи и шлюзы;

• Плейлист видеокурса по Camunda 8 на YouTube.

Важно! Для выполнения практического задания необходим опыт разработки в среде Spring Boot.

Business Rule Task

Из предыдущего урока мы узнали, что для принятия решений в процессе используется шлюз (Gateway). Шлюз прекрасно работает, когда в решении используется одно условие (например, выбрать нужный набор задач исходя из суммы кредита). 

Как же поступить, когда решение принимается на основе нескольких входных значений и условий?

Рассмотрим пример ниже.

Мы хотим пригласить гостей и нам необходимо определиться с меню. Входные значения, на основании которых мы будем принимать решения:

• Время года – Season (String);

• Число гостей – Number of guests (Number).

В результате моделирования мы получим примерно следующее описание процесса:

Что же делать, если появится еще несколько входных переменных? Например, возраст гостя или предпочтения в напитках? Диаграмма процесса приобретет совершенно нечитаемый вид.

На помощь приходит так называемый Business Rule Task (Задача-выполнение бизнес-правила). 

Назначение этой задачи - вызов системы управления бизнес-правилами (Business Rule Management System). Для этой цели в Camunda 8 может быть вызван:

• Job Worker – через который будет осуществлено обращение к внешнему сервису (например JBoss Drools);

• DMN decision – собственный движок - Decision Engine.

Чтобы использовать Decision Engine, необходимо указать ID вашей таблицы решений (Decision ID) и переменную процесса, куда будет сохранен результат вычислений (Result variable).

Decision Model and Notation

Decision Engine - движок Camunda,  выполняющий бизнес-правил, смоделированные при помощи нотации DMN (Decision Model and Notation). Ключевой частью DMN является элемент Decision (Решение), который представляет собой таблицу, состоящую из:

• Входных значений (Inputs) – выражения, описанные при помощи языка FEEL (могут использовать, например переменные процесса);

• Выходных значений (Outputs);

• Правил (Rules) – унарные выражения, описанные опять же, при помощи FEEL;

• Политики срабатывания (Hit Policy).

Вкратце, таблица решений работает следующим образом:

• Во входные значения помещаются данные, которые будут оцениваться при помощи правил. В роли таких данных выступают, как правило, переменные процесса.

• Входные значения сверяются с условиями, содержащимися в правилах (больше, меньше, равно, содержит и т.д., смотрите документацию FEEL). При сверке принимается во внимание политика срабатывания. Она же используется при формировании выходных значений.

Multi-instance

Multi-instance (мульти инстанс) или множественный экземпляр – признак на активности (задаче, подпроцессе или вызываемой активности), указывающий, что она должна выполняться в нескольких экземплярах. 

В зависимости от типа, активность может выполняться:

• Параллельно (Parallel Multi-Instance);

• Последовательно (Sequential Multi-Instance).

Для работы множественной активности нужно задать следующие поля:

• Input collection – имя переменной, содержащей массив. Число экземпляров мульти инстанса будет = числу элементов этого массив;

• Input element – имя локальной переменной, в которую будет помещен элемент массива, обрабатываемый экземпляром мульти инстанса.

• (опционально) Output collection – имя переменной-массива, которая содержит результаты работы мульти-инстанса. Массив состоит из переменных, указанных в поле Output element.

• Output element (обязателен, если указана Output collection) – имя локальной переменной, которая будет помещена в Output collection.

По сути, мульт-инстанс является аналогом активностей (Activity), выполняющихся последовательно или параллельно, с возможностью динамически определять их количество, основываясь на числе элементов Input collection.

Практическая часть

Этапы практического задания:

1. Добавить и настроить Business Rule Task, который будет определять набор вызываемых сервисов;

2. Добавить и настроить Service Task с признаком Parallel Multi Instance и типом (Type), определяемым динамически из переменной service;

3. Создать таблицу решений (Decision), связанную с Business Rule Task из пункта 1;

4. Развернуть полученные артефакты в Camunda 8 Run;

5. Разработать воркеры (Job Workers);

6. Запустить процесс из Camunda Modeler, указав переменные name, amount, customerType;

7. Проверить корректность работы процесса в Operate.

Видеоурок