camunda что это такое
Camunda: автоматизация бизнес-процессов и оркестрация микросервисов
Три года назад Леруа Мерлен начала масштабную программу ИТ-трансформации с использованием таких прогрессивных течений, как микросервисная архитектура, предметно-ориентированное проектирование (оно же DDD) и формирование собственных in-house-команд разработки. Пилотным проектом этой программы стало построение омниканальной платформы продаж, то есть возможность для клиента сделать взаимодействие с компанией удобным и доступным через любой существующий канал продаж, будь то сайт, магазин, колл-центр и т. д., в том числе наша платформа дает возможность взаимодействовать с различными партнерами для получения бизнес-синергии. Этой статьей мы начинаем рассказ об опыте использования open-source-платформы Camunda в Леруа Мерлен.
При построении правильной архитектуры этого решения было важно рассмотреть самый сложный кейс: клиент решил сделать ремонт в своей ванной комнате, он создает проект вместе с сотрудником Леруа Мерлен, далее они планируют основные вехи реализации проекта: доставка товаров для ремонта с разных складов, работа мастера по ремонту и установке сантехники.
Платформа Леруа Мерлен
Когда мы сделали это упражнение, нам стало понятно, что одним из центральных бизнес-объектов должен стать клиентский заказ, который умеет координировать с объектами других доменов: фулфилмент заказа, доставка, оплата, исполнение услуг мастера, коммуникации и т. д. Другими словами, выбранный бизнес-сценарий заказа отправляет команды другим системам (исполнителям), которые, в свою очередь, занимаются своими профильными задачами и отчитываются координатору по ходу исполнения. Пример такого BPMN-процесса может выглядеть так:
Причем дочерние домены-исполнители могут под капотом также иметь свою внутреннюю координацию внутренних партнеров, оставаясь при этом автономными и несвязанными.
Как создать единую точку оркестрации для множества микросервисов в многослойной архитектуре?
В процессе построения микросервисной архитектуры мы пришли к трехуровневой модели данных. Слой микросервисов функционировал поверх этих данных. Нужен был оркестратор для трехслойной модели экспозиции API и типов микросервисов.
Слой объектных интерфейсов (Object API) — набор небольших, линейно независимых функций доступа к данным. На этом слое находятся репозитории CRUD (create, read, update, delete) мастер-данных, унаследованные приложения, лицензионное коммерческое коробочное ПО и части глобальных ИТ-продуктов группы ADEO.
Слой бизнес-процессов и оркестрации (Process API) — функционал единых бизнес-правил компании.
Слой адаптации (Experience API) — средства адаптации к конкретным прикладным задачам: сервисы класса Back-End-for-Front-End; ПО для мобильных и десктоп-приложений; функционал композитных сервисов (mash-up); средства интеграции с партнерами, клиентами и окружающей компанию экосистемой; бизнес-логика приложений, специфичных для конкретных видов бизнеса.
Мы проанализировали квадрант Гартнера, посоветовались с коллегами и выяснили, что рынок таких решений сильно растет, есть и мастодонты типа Pega или IBM. Но все они проприетарные. Для нас же главным критерием выбора был открытый код, возможность самостоятельно его дорабатывать. Соответственно, проприетарные движки отпали автоматически.
Еще было важно, чтобы решение соответствовало нашим требованиям к микросервисной архитектуре — независимый деплой с возможностью работы в cloud-native-режиме. Это значит, что движок может раскатываться в контейнеры в любом baas-решении, которое мы выбираем.
Круг сузился до тех решений, которые поддерживают контейнерную сборку и остаются все еще в тренде с точки зрения квадранта, то есть имеют сильное open-source-комьюнити. В итоге наш выбор остановился на open-source-решении Camunda.
Мы сразу же оценили ряд важных преимуществ.
Open source: платформа активно развивается, все больше и больше компаний начинают использовать этот движок, в интернете можно найти много статей и подробной документации, в том числе блог и книгу Бернда Рюкера — отца-основателя решения. В Москве регулярно проводят митапы, где докладчики рассказывают успешные кейсы применения Camunda на своих проектах.
BPMN, DMN (low-code): разработка процессов автоматизации и оркестрации осуществляется в нотации BPMN, что делает флоу исполнения понятным и прозрачным для всех участников команды. Обычно процессы проектируют системные аналитики.
Java, External tasks: существует два основных паттерна реализации логики для задач BPMN-процесса. Первый способ — это написание java-делегатов внутри движка для каждой задачи на Java/Kotlin, используя Java API движка и Spring. External tasks — исполнение задач процесса внешними сервисами-обработчиками, которые можно написать на любом языке разработки.
Масштабируемость, отказоустойчивость: при правильной конфигурации и хорошей инфраструктуре движок держит высокую нагрузку и горизонтально масштабируется за счет увеличения количества воркеров. На продакшн-среде мы запускали больше 200к активных процессов.
Мониторинг: Camunda из коробки дает удобный UI-cockpit, он позволяет в реальном времени просматривать все запущенные процессы. Провалившись в процесс, можно увидеть точку исполнения, возникшие ошибки. Например, некоторые процессы умеют автоматически генерировать инциденты для службы поддержки, после чего специалист может найти проблемный процесс и посмотреть его состояние для разбора этого инцидента.
Паттерны использования Camunda
C момента запуска в Леруа Мерлен пилотного проекта с использованием Camunda прошло уже несколько лет, за это время основное применение платформа в компании нашла в качестве оркестратора микросервисов. По мере того как количество сервисов в домене увеличивается, команды сталкиваются с необходимостью иметь stateful-оркестрацию вызова этих сервисов, а также им приходится работать с распределенными транзакциями и применять паттерн SAGA с возможностью делать компенсационные операции. Camunda помогает решать эти задачи.
С точки зрения разработки мы используем два основных подхода:
подход №1
1) разворачиваем Camunda как отдельный сервис и начинаем наполнять его кастомными Java/Kotlin-реализациями с помощью интерфейса JavaDelegate, итого получается spring-приложение, с которым привычно работать разработчикам. Аналитики рисуют BPMN-схемы флоу-процесса (сам процесс, как правило, привязывается к бизнес-объекту, например, клиентский заказ или процесс оплаты заказа), а разработчики имплементируют логику вызова микросервисов слоя объектных интерфейсов, при этом вызовы могут быть как синхронными (с использованием REST API), так и асинхронным (отправка команд или ожидание ивентов-событий).
подход №2
2) в паттерне «External tasks» также разворачиваем Camunda как отдельный сервис, но реализация бизнес-логики уже имплементируется на стороне внешних сервисов, стек которых не имеет значения, главное, чтобы они могли выполнять http-запросы к Camunda, для того чтобы получить список активных задач и взять их в работу.
Это решение дает лучшую производительность и подходит для highload-решений, поскольку Camunda выполняет только задачу BPM-оркестратора, а исполнение самих задач ложится на внешние сервисы.
Цепочки по выполнению распределенных транзакций с применением шаблона SAGA мы также реализуем на платформе Camunda, но об этом расскажем в отдельной статье позже.
Иногда мы сталкиваемся с тем, что стейкхолдеры приходят к нам с запросом автоматизации рутинных бизнес-процессов.
Если абстрагироваться от оркестрации микросервисов, основной задачей становится необходимость вовлечь людей в процесс и дать некоторый UI, где пользователи могут исполнять свои задачи, — например, подтверждать/отклонять заявки, заполнять данные в поля, прикреплять документы и т. д. Примером такой реализации в нашей компании выступает процесс онбординга новых провайдеров услуг, где есть разные роли согласующих, анкеты и документы. Camunda позволяет очень быстро автоматизировать процесс «из коробки», поскольку само решение имеет функционал UI работы с пользовательскими задачи (user tasks) и ролевой моделью. Наш опыт показал, что функционал Camunda User tasks подходит для быстрого старта, но по мере развития лучше написать свой менеджер тасков и кастомный front.
В этой статье стоит упомянуть новое решение ZeeBee от команды Camunda, главной особенностью которого является то, что в отличие от Camunda ZeeBe не персистит каждый свой стейт процесса в БД, что дает лучшую производительность. Пожалуй, основным минусом ZeeBee в данный момент является бедная поддержка нотации BPMN и отсутствие DMN. На данный момент в качестве домашнего задания мы уже тестируем ZeeBee, смотрим опыт других коллег и думаем над пилотным внедрением. Хотя будем честными, сейчас Camunda нас удовлетворяет практически по всем параметрам.
Camunda — что это такое?
Camunda — это BPM-движок для автоматизации бизнес-процессов. Что значат эти слова и какую пользу вы можете получить от использования этого движка читайте в этой статье.
Какое вам дело до Camunda
Camunda может очень сильно, в десятки раз (например если вы устали от «статусов»), снизить затраты на автоматизацию бизнес-процессов и\или оркестрацию микросервисов. Это достигается за счёт:
Пример бизнес-процесса в BPMN
Компоненты системы
Camunda — это набор приложений Modeler, Task List, BPMN Engine, DMN Engine, Cockpit, Admin,Optimize.
Архитектура приложений Camunda
Интерфейс camunda tasklist
Структура BPMN Engine
Слабая связность компонентов между собой позволяет их заменять, разрабатывая свои. Например, я написал свой Cockpit, который намного функциональнее бесплатного.
Как попробовать Camunda самому
Standalone вариант использования
2. Библиотека внутрь java-приложения — это значит, что вы указываете зависимости в своем приложении и работаете с camunda через Java API.
Embedded вариант использования
В этом видео можно посмотреть как сделать своё первое stand-alone приложение:
Весь движок и часть веб-приложений бесплатны, начать использовать их можно прямо сейчас.
В итоге
За счёт бесплатности и классной архитектуры система может решать кучу ваших проблем и прямо сейчас. Если вы планируете её использовать в своей работе и хотите быстро разобраться, как интегрировать этот BPM-движок в вашу инфраструктуру и как лучше построить архитектуру приложений, то мои консультации могут вам помочь.
Вы уже работаете с системой? Как вам? Расскажите в комментариях и поделитесь этой статьей в соц.сетях.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Стильная, модная, молодежная разработка BPM на Camunda
BPM-разработка — дело непростое. Это обусловлено тем, что процесс должен быть читаемым и понятным заказчику, а не только корректным с технической точки зрения.
Не все средства разработки бизнес-процессов позволяют найти компромисс между понятным описанием и технической функциональностью. Многие продвинутые средства разработки и описания процессов часто имеют еще один недостаток: они настолько крутые, мощные и сложные, что, пока их делали, технологии сильно шагнули вперед и разработка таким инструментом стала неактуальной.
2018 год принципиально изменил наш подход к разработке бизнес-процессов. Ниже — о том, как эволюционировал этот подход и как менялись мы.
Вместо пролога
Наш отдел занимается разработкой бизнес-процессов — начиная от самых маленьких и незначительных, заканчивая крупными и крайне прибыльными. До последнего времени для разработки мы использовали продукт от IBM, который позволяет достаточно быстро выпустить в продакшен работающий бизнес-процесс.
IBM BPM — мощная платформа, которая включает богатый набор возможностей, таких как описание самих процессов, UI-форм, интеграционных модулей. К тому же эта платформа имеет довольно низкий порог входа, что позволяет начинающим разработчикам практически сразу погружаться в проект. Но есть у этого продукта и недостатки, которые если и не тормозят разработку, то уж точно не способствуют скорости и качеству:
Со всеми этими ограничениями трудно находиться на плаву. Чуть менее года назад поступило предложение попробовать движок Camunda для описания бизнес-процессов. Для начала был выбран не очень большой, но достаточно важный процесс по регистрации терминалов для юрлиц.
Так как его мы переписывали полностью, старого кода почти не было, мы могли практически ни в чем себя не ограничивать и поэтому в качестве языка разработки выбрали Kotlin. Было интересно попробовать этот новый язык, о котором слышали по большей части положительные отзывы. На некоторых других проектах в нашем отделе был успешный опыт внедрения. Финальный стек получился таким: Camunda, Spring Boot 2, Kotlin, Postgre.
Что это такое Camunda?
Camunda — это open-source-платформа для моделирования бизнес-процессов, которая написана на Java и в качестве языка разработки использует Java. Она представляет собой набор библиотек, которые и позволяют выполнять описанные процессы. Для интеграции Camunda в проект достаточно добавить несколько зависимостей. Для хранения процессов можно выбрать in-memory или персистентную СУБД — в зависимости от задач. Мы выбрали Postgre, так как нам важна история для «разбора полетов». По умолчанию платформа разворачивается на H2.
Разработка состоит из двух частей: создание flow-процесса в специальной утилите Camunda Modeler и написание java-кода, который обрабатывает шаги процесса, описанные на диаграмме. Чтобы из процесса вызвать java-код, достаточно реализовать интерфейс JavaDelegate, поднять этот Bean (можно указать делагат по полному имени, но через Bean удобнее и гибче) в контексте и указать его id на нужном шаге процесса. На Kotlin делегат выглядит еще более лаконично. Логика работы делегатов довольно проста: что-то вычитали из контекста, выполнили какие-то действия и положили обратно в контекст.
Рабочее окно Camunda Modeler
Пример делегата на Java:
Пример делегата на Kotlin:
В делегате можно описывать бизнес-логику, интеграции и всё, что душе угодно.
Мы стараемся создавать прослойку в виде бизнесового компонента с логикой, а сам делегат использовать только как связующее звено с flow процесса, чтобы как можно меньше смешивать код и процесс.
В большинстве случаев этот подход удобен и работает успешно. Взаимодействие с процессом происходит через DelegateExecution, который позволяет, например, работать с контекстом, инцидентами и так далее.
Это то, чего мы хотели?
В самом начале, при выборе инструмента, мы искали решение со следующими возможностями:
Хорошо читаемый трейс, возможность задания числа попыток выполнить шаг перед падением, кастомный обработчик при падении — например, если при падении мы хотим поменять статус некоторой сущности на Error. Последнее сделать достаточно легко, просто реализовав DefaultIncidentHandler. Правда, есть забавный момент при работе этого обработчика: код восстановления из ошибки срабатывает при каждом заходе на шаг процесса. Не могу сказать, что это — супербаг или проблема. Скорее, об этом нужно просто помнить и учитывать при разработке.
Мы решили это примерно так:
GUI у Camunda есть, и он неплохой.
Но если хочется чуть больше, например миграцию инстансов между версиями процессов, то уже придется потрудиться. В дефолтном UI только минимальный функционал, зато есть очень мощный Rest API, который позволяет создать свою админку — крутую и навороченную.
Именно по пути своей админки мы пошли. Наш архитектор бизнес-процессов в довольно короткий срок ее запилил, включив туда функции просмотра истории по уже завершенным процессам, миграции между версиями и так далее.
Rest у Camunda действительно мощный и позволяет творить с процессами практически что угодно. Например, стартовать процесс можно по /process-definition/key/aProcessDefinitionKey/start таким нехитрым запросом:
Пример взят из официальной документации, которая содержит обширное описание различных кейсов использования этого API.
Для юнит-тестирования мы используем обычный Junit. Плюс есть довольно интересная библиотека для тестирования самого процесса — ‘org.camunda.bpm.extension’, name: ‘camunda-bpm-assert’. С ее помощью можно описывать тесты для проверки flow-процесса.
Это довольно удобно, так как искать проблемы в случае багов во flow зачастую сложнее, чем в коде. Такое тестирование защищает, например, от неаккуратного рефакторинга и несколько раз действительно нас выручало.
Необходимость в Java 8 частично отпала, так как использование Kotlin на многих процессах устранило потребность в «восьмерке». Kotlin очень хорошо вписался в проект и позволил сосредоточиться только на написании бизнес-логики. Трудно поверить, но в основном всё то, что говорят о крутости Kotlin, — правда. Сущности с большим числом полей, которыми славятся практически все приложения с интеграциями, теперь выглядят не так страшно, и маппинги между сущностями стали гораздо более читабельными. Часто критикуемое null safety действительно работает и выручает в большинстве случаев.
Community у Camunda достаточно развитое. Об этом говорит тот факт, что постоянно появляются новые библиотеки на GitHub для тестирования и метрик.
Приятно, что Camunda отлично интегрируется со Spring. Добавить необходимых зависимостей, пару аннотаций и пару конфигурационных бинов — собственно, вот и вся интеграция! В результате мы пишем обычное spring-приложение, к которому все привыкли, добавляя flow бизнес-процесса. Взаимодействие происходит через Java API, которое позволяет выполнять манипуляции с процессами из java-кода.
Например, запустить процесс можно всего одной командой:
Здесь MyTestProcess — Id-шник процесса, а не инстанса. MyBusinessKey — уникальный ключ для запускаемого инстанса процесса. Мы обычно используем для этого поля некое бизнесовое значение — для более быстрой навигации между инстансами и поиском.
Примерно таким же образом можно разбудить «заснувший» процесс.
Заметных минусов или каких-то проблем, с которыми мы столкнулись, особо вспомнить не получается. В итоге за довольно короткий промежуток времени получилось сделать вполне рабочий процесс и благополучно вывести его в продакшен. На платформе внедряются другие процессы и вполне успешно. Сейчас на Camunda у нас запущено около 15 приложений, на которых единовременно крутится около 100 тысяч процессов.
Вместо эпилога
Вот несколько ресурсов, которые были полезны при внедрении описанного выше стека. Рекомендую ознакомиться с ними, если интересна дополнительная информация по теме.
Моделирование бизнес-процессов: практика использования Camunda BPM в Java разработке
Авторизуйтесь
Моделирование бизнес-процессов: практика использования Camunda BPM в Java разработке
ведущий Java-разработчик ростовского офиса компании Usetech
Меня зовут Евгений Тришечкин, я ведущий Java разработчик ростовского офиса компании Usetech, и сегодня хочу поделиться с вами применением Camunda BPM в Java разработке.
В рамках статьи я расскажу об основных компонентах системы управления бизнес-процессами Camunda. Покажу развертывание системы, моделирование и деплой простого процесса. А также, на примере созданного процесса, проиллюстрирую взаимодействие Java/SpringBoot приложения с Camunda.
Давайте сначала разберемся с терминологией и выясним, что же такое BPM, BPMS и BPMN.
BPM (Business process management) — концепция управления организацией, рассматривающая бизнес-процессы как особые ресурсы предприятия, непрерывно адаптируемые к постоянным изменениям, и полагающаяся на такие принципы, как понятность и видимость бизнес-процессов в организации за счет их моделирования с использованием формальных нотаций, использования программного обеспечения моделирования, симуляции, мониторинга и анализа бизнес-процессов, возможность динамического перестроения моделей бизнес-процессов силами участников и средствами программных систем.
Другими словами, BPM отвечает на вопросы, где, когда, зачем, как и какая задача выполняется и кто отвечает за ее выполнение.
BPMS (Business Process Management System) – программное обеспечение, обеспечивающее прикладную реализацию концепции BPM.
BPMN (Business Process Modeling Notation) – нотация (система графических обозначений и их описание в формате XML) бизнес-процесса.
BPMS на рынке существует великое множество, включая лидеров рынка – Oracle или IBM. Из названия понятно, что эти системы очень мощные, сильные, дорогие и подходят далеко не каждой организации, а стоимость их внедрения может начинаться от 100.000 евро и выше. Понятно, что только крупные компании могут себе позволить внедрить такую систему.
Компания Camunda Services, которая является вендором Camunda BPM, долгое время занималась консультированием организаций в области управления бизнес-процессами, но в результате создала свой продукт и начала активно его развивать.
В сети есть разные сравнения Аctivity и Camunda и, по большей части, они в пользу последней, да и список компаний, использующих камунду достаточно обширный: Deutsche Bank, Goldman Sachs Group, Тинькофф банк, Сбер, Теле 2 и т.д.
Мы все понимаем, что бизнес-процесс должен быть максимально понятным. Моделирование процессов происходит с применением нотаций (нотации — это система графических обозначений и их описание в формате XML). Нотаций существует довольно много, но самая популярная из них, конечно, текущая версия BPMN 2.0 (2.0.2 – 2014 г), которая постепенно развивается и пополняется новыми элементами.
Рассмотрим пример бизнес-процесса, описанном нотацией BPMN:
На картинке изображен процесс регистрации нового пользователя на портале, в достаточно упрощенном формате.
Здесь нарисован пул процесса и отдельными линиями – дорожки процесса. Каждая дорожка — это отдельная роль бизнес-процессов. Верхняя — это инициатор процессов, посередине – портал и внизу – ответственный за исполнение бизнес-процессов.
Зеленый кружок — стартовые события процессов, красные кружки – конечные события процессов.
Прямоугольник — задачи (=таски), которые исполняются во время жизненного цикла бизнес-процесса.
Задачи со значком шестеренок — сервисные задачи, которые не требуют участия оператора.
Задачи со значком человечка – это те задачи, которые требуют участия человека.
Данная система создана для примера и сильно упрощена, в полноценных системах присутствуют и другие элементы, шлюзы, которые реализуют ветвление, есть перехватчики событий, таймеры, и многое другое.
Что же такое Camunda BPM?
DMN – это модель принятия решения, которая представляет собой таблицу входных значений и результирующего выходного значения. Полезна в таких задачах, как принятие решения. Допустим, нужно принять решения о выдаче кредита или открытии счета и именно в этой таблице DMN вы найдете множество вводных параметров и выходной параметр, то есть результат – выдавать кредит или нет.
Компоненты CAMUNDA BPM (Community)
Давайте подробнее рассмотрим компоненты комьюнити версии Camunda:
Компоненты Camunda BPM (Enterprise)
Enterprise версия – платная, договор, тех поддержка 24\7 и в техническом плане она получше комьюнити версии. Например, появляются:
Enterprise Cockpit — расширенная версия Camunda Cockpit, содержащая в себе дополнительные функции: развертывание описаний процессов, перезапуск экземпляров процессов, расширенный поиск по экземплярам процессов, миграция экземпляров процессов между версиями.
Camunda Optimize — оптимизация и улучшение бизнес-процессов, выявление «узких мест», отчеты и «тепловые карты» процессов, все это помогает улучшить, оптимизировать и модернизировать бизнес-процессы.
Пример тепловой карты процесса
Тепловая карта показывает относительную частоту выполнения той или иной задачи в процессе. Она помогает визуализировать результат и принять решение, какой участок более нагружен и за счет каких ресурсов\действий его можно разгрузить.
Способы развертывания Camunda BPM
Как я ранее писал, Camunda BPM написана на тех. стеке Java, поэтому у нее есть много способов развертывания.
Первый и самый простой – встроенная библиотека в приложении и именно его мы будем подробно разбирать.
Второй способ тоже подходит для Java приложений — сервис внутри сервера приложений или контейнера сервлетов («расшаренный» сервис), который могут использовать другие приложения, развернутые в контейнере.
Третий способ, если приложения написаны не на Java, развернуть Camunda как отдельно стоящий сервер и приложение будут с ним контактировать по Rest API удаленно.
Четвертый способ для высоконагруженных систем — кластерное развёртывание для высоконагруженных систем, когда есть общая база данных и несколько нод с камундой.
Практическая часть – пробуем Camunda своими руками
Внутри мы видим один класс Application — @SpringBootApplication, как я и писал ранее, камунда хорошо интегрируется со SpringBoot. А также в проекте есть файл с настройками приложения и файл с описанием процесса в формате BPM.
Процесс состоит из следующих этапов: стартовое событие, пользовательская задача, конечное событие. Пользовательская задача, самая простая, выглядит так: пользователь открыл задачу, нажал – завершить задачу и процесс завершился.
Но давайте немного усложним задачу и внесем изменения в процесс. Процесс мы сделаем процессом регистрации пользователя на портале, тот пример, о котором мы говорили в начале статьи и к которому обещал вернуться. Для этого нам нужно изменить стартовое событие и добавить туда переменную «username», которая добавляется через Camunda Modeler (кросс-платформенное решение, скачивается с официального сайта, бесплатное)
В результате у нас получилось модифицировать стартовое событие. Дальше необходимо модифицировать пользовательскую задачу, тут же добавляем форму с именем пользователя. Причем имя пользователя мы делаем «read only», чтобы тот человек, который будет утверждать создание нового пользователя не мог изменить его имя. А также добавляем переменную «decision», которая позволяет утвердить или отклонить эту регистрацию.
Запускаем экземпляр процесса. Для запуска экземпляра процесса заходим в приложение Camunda Tasklist (веб-приложение, через которое конечные пользователи могут зайти, посмотреть какие задачи на них назначены и выполнить какие-то действия) и нажимаем «Запустить процесс».
Находим свой демо процесс, который мы создали и видим форму запуска процесса.
После этого появляется окошко для ввода имени пользователя (переменная username), заполняем его и запускаем процесс.
Процесс запущен, и мы видим, что на пользователя Demo упала задача. Задача, как и ожидается называлась отклонить или утвердить регистрацию. Выделяем ее и видим форму, которую мы создавали. Также мы видим имя пользователя, которое нельзя редактировать, а решение – можно. Завершаем задачу, нажав кнопку «Complete» и на этом процесс завершается.
Давайте добавим немного экшена в процесс и усложним задачу – создадим ветвления.
Для этого добавляем к существующему процессу — шлюз, который будет «ветвить» этот алгоритм:
И также создаем конечное событие. В результате у нас появляются два сервисных таска: создать нового пользователя и отправить уведомление. Сервисные таски, как я уже писал ранее, это таски, которые не требуют участия оператора в их выполнении. Следовательно, в них должна быть заложена логика и здесь мы покажем простой способ взаимодействия с Java кодом.
Выделяем модуль или сервисный таск и в нем прописываем implementation, выбирая способ Delegate Expression и добавляем в Delegate Expression собственное имя. Собственно этот бин нам и нужно создать в коде.
Аналогично поступим в другим сервисным таском – отправить уведомление.
Также пропишем Delegate Expression, добавляем ему имя бина «notifyUser» и создаем соответствующий компонент, реализующий JavaDelegate в коде.
Вот этот способ через DelegateExecution работает только в случае с Java приложениями.
Возникает вопрос: а что делать, если приложение не на Java или если Camunda развернута на отдельном сервер?
В этом случае выбираете способ имплементации не Delegate Expression, а External и просто указываете какой-то топик, куда будет отправлен месседж и, соответственно, через очереди будет делегироваться выполнение в ваш код.
Последний шаг – запустить все то, что мы создали. Вводим имя
Видим таск «утвердить\отклонить регистрацию». Допустим, мы отклоняем регистрацию. Тогда не ставим галочку в поле «Утвердить?» и нажимаем «Complete».
После этого переходим в логи и видим, что пользователю Дарт Вейдер отказано в регистрации
Если мы принимаем регистрацию, то ставим галочку в поле «Утвердить?» и нажимаем «Complete». В этом случае процесс исполняется по другой ветке и в логах отображается по-другому.
Вместо вывода
Выше я описал самую простую схему процесса. В реальности же системы намного сложнее с множественными ветвлениями, а в эти диаграммы BPM можно вставлять другие таски, которые могут реализовать нотации DMN.
Camunda не позиционирует себя как low-code или no-code система. Camunda позиционирует себя как систему, где должно быть разумное сочетание, своеобразный симбиоз, между бизнесом, аналитиками и разработкой.