В этом году вышел релиз Camunda 8 — это последнее обновление мажорной версии платформы за минувшие семь лет. В статье я поделюсь собственным опытом работы в «восьмерке» и расскажу об основных отличиях от предыдущей версии, но при этом не полезу глубоко «под капот», а опишу их глазами аналитика.
Что такое Camunda: систематизируем сведения из интернета
Мой коллега Сергей, бекенд-разработчик, ёмко и в то же время достаточно точно определил основную суть и назначение этого инструмента:
«Совместное использование BPMN и Camunda приводит к наибольшей степени вовлеченности участников разработки в бизнес-процессы, к более детальному пониманию всех цепочек процессов, и в итоге — к получению командного компаса по лабиринтам процессов».
Camunda — тот самый Low-Code, который дает много готовых решений для автоматизации бизнес-процессов «из коробки». Не буду здесь подробно их расписывать: возможности платформы хорошо описаны на официальном сайте. Важно понимать, что Camunda — это BPMN и Java.
Если использование языка Java дает широкий простор для творчества разработчикам, то BPMN позволяет остальным членам команды лучше понимать друг друга. Почему? — Наличие диаграмм обеспечивают необходимую наглядность, что обеспечивает лучшее понимание логики бизнес-процессов.
Существует множество роликов и публикаций, посвященных платформе Camunda и опыту ее применения в различных проектах. В этих материалах достаточно подробно описаны сложности и ошибки, с которыми сталкиваются команды на практике, а также есть рекомендации, как их избежать. Эти советы сохраняют свою актуальность и сегодня, но при одном условии: важно учитывать изменения, которые появились с выходом новой версии Camunda. С некоторыми из них, существенными для задач аналитика, познакомимся ниже.
Что нового и какие вопросы вызывает восьмая версия
Как уже было отмечено, члены проектной команды взаимодействуют, опираясь на BPMN-диаграммы, которые позволяют всем одинаково понимать логику бизнес-процессов.
BPMN также помогает взаимодействовать с представителями бизнеса: заказчик после вводной демонстрации и необходимых пояснений понимает нотацию и достаточно хорошо ориентируется в элементах диаграммы. Бывает и такое, что заказчик сам знает и активно использует BPMN.
Тем не менее, обилие элементов нотации (~480 элементов), в частности большое количество событий и шлюзов, может сбить с толку команду и вызвать затруднения при работе со схемами бизнес-процессов.
Хорошая новость как раз в том, что в восьмой версии Camunda сократили число элементов, доступных для построения диаграмм.
Что же изменилось?
События (Эвенты)
Из новой версии исключили:
1. Стартовые события следующих типов:
conditional start event;
signal start event (от сигналов, к слову, вообще отказались).
2. Промежуточные события следующих типов:
escalation intermediate throw event;
conditional intermediate catch event;
link intermediate catch event;
link intermediate throw event;
compensation intermediate throw event;
signal intermediate catch event;
signal intermediate throw event.
3. Завершающие события следующих типов:
escalation end event;
compensation end event;
signal end event;
terminate end event — пожалуй, самая большая потеря, так как «terminate end event» — достаточно удобная штука. На мой взгляд.
4. Boundary events следующих типов:
escalation boundary event;
conditional boundary event;
compensation boundary event;
signal boundary event;
escalation boundary event (non-interrupting);
conditional boundary event (non-interrupting);
signal boundary event (non-interrupting).
А что осталось?
1. Помимо простых событий каждого вида по-прежнему доступны:
message start event;
timer start event;
message intermediate catch event;
message intermediate throw event;
timer intermediate event;
message end event;
error end event.
2. А также следующий набор boundary events:
message boundary event;
timer boundary event;
error boundary event;
message boundary event (non-interrupting);
timer boundary event (non-interrupting).
Шлюзы
Шлюзы следующих типов также не поддерживаются новой версией платформы:
inclusive gateway;
complex gateway.
Доступны только:
parallel gateway;
event based gateway;
exclusive gateway.
Таски
Набор доступных тасков не изменился. Изменения затронули внутреннюю структуру.
Одно из заметных преобразований — отсутствие блока «Implementation» среди атрибутов сервис-таска. Его заменили на «Task definition», который теперь не содержит предопределенных типов. К примеру, необходимости указывать «JavaClass» больше нет: не таск ссылается на «JavaClass», а сам код обращается к нужному таску. А для сервис-таска достаточно указать атрибут type и число попыток запуска в случае неудачи — атрибут retries (по умолчанию равен 3).
Такое решение по началу сбивает с толку, но по своей сути оно намного ближе к Low-Code по сравнению с тем, что было в предыдущей версии.
Коннекторы
Появились коннекторы, своего рода Low-Code интеграции, которые разделяют на:
Входящие — позволяют запустить какой-либо процесс извне (снаружи);
Исходящие — позволяют обращаться к сторонним системам.
Выделяют также коннекторы различных уровней — от подключения к брокеру сообщений, к примеру, Apache Kafka, до отправки e-mail и хранения файлов.
Готовый набор коннекторов содержит «Integration Framework», где вы можете найти подходящее решение для вашей задачи.
Modeler
«Cawemo» заменил облачный «Camunda Modeler», у которого также осталось десктопная версия.
В ней по-прежнему можно создавать и редактировать модели седьмой версии, но с переносом их в восьмую могут возникнуть сложности. Официальная документация содержит инструкцию — Migrating from Camunda Platform 7 — по миграции между версиями, но не всегда это возможно. К счастью, поддержка седьмой версии останется на ближайшие 5 лет.
Другие изменения
Да, этот материал преимущественно для аналитиков, но всё же полезно знать и о других важных изменениях. Коротко затронем основные.
Платформа в новой версии разворачивается отдельно. Встраивать движок в приложение через «Springboot» теперь нельзя. Бизнес-процесс и «Workers» разделены. «Workers» интегрируются через коннекторы.
В «Camunda Automate» вошли «Zeebe» (заменил «Engine»), «Tasklist» и «Operate», который заменил «Cockpit».
«Zeebe» теперь обеспечивает возможность одновременной обработки большего числа инстансов, поскольку обновленная версия платформы не содержит узкое место, которым являлась реляционная БД. Её функции выполняют «Zeebe broker» и «Zeebe gateway».
Gateway содержит информацию о «Workers» и знает, какие таски они могут выполнять. Таски привязываются к воркерам через тот самый атрибут type, о которым я упоминал выше. Это также обеспечивает переиспользование воркеров, достаточно указать нужное значение атрибута type. Broker выступает балансировщиком нагрузки и коммутирует инстансы и воркеры между собой. Атрибут retries при этом определяет число попыток вызова.
БД в «семёрке» представляла собой один кластер, «Zeebe» разворачивается в нескольких нодах. Все данные об инстансах хранятся в брокере, а исторические данные пишутся в «Elastic», куда обращаются «Tasklist» и «Operate». В «семёрке» они обращались в БД, что создавало дополнительную нагрузку.
Сам «Tasklist» не сильно изменился. Из интересного — в UI появилась возможность забирать данные прямо из «GraphQL».
«Operate» появился из-за перехода на «Zeebe» и необходимости взаимодействовать с «Elastic». Здесь также обновился интерфейс, который, по заверениям разработчиков, стал более удобным.
Как все это отражается на практике
Уменьшение числа доступных элементов для построения диаграмм незначительно сказывается на возможностях моделирования бизнес-процессов, но при этом размывает границу между схемами различных уровней моделирования. Иными словами, схемы становятся проще, а причин отдельно проектировать модели согласовательного и аналитического уровней — меньше.
Что происходит, когда бизнес-сторона «может в BPMN»
С одной стороны, нашей команде повезло: на одном из моих проектов заказчик предоставил большое количество схем в нотации BPMN для всего своего процесса, где полностью расписал логику, используя «всю мощь» BPMN.
С другой — большое количество символов, обилие переходов между тасками, зачастую без шлюзов, использование большей части доступных символов событий и развитие процесса во всех возможных направлениях поначалу просто сбивали с толку.
Перед нами встала задача не только переделать схемы под обновленную версию Camunda, но и привести их в порядок, сохранив всю заложенную логику. Каким образом?
События и ссылки мы заменили сообщениями. Комплексные шлюзы — совокупным использованием параллельных и исключающих. В итоге совместными усилиями нам удалось достаточно быстро оптимизировать все процессы. Отсутствие части элементов нотации никак не помешало, напротив облегчило восприятие получившихся схем. В своей работы мы в основном полагались на официальную документацию — Overview Components | Camunda Platform 8 Docs.
Заключение
Новая версия Camunda, может и ограничивает «всю мощь» BPMN, но взамен предлагает не меньшее могущество. При этом новый «Modeler» становится ещё более приспособленным, гибким для работы бизнес-аналитика, дает ему всё меньше поводов заглядывать «под капот».
Может сложиться впечатление, что обновление — своего рода попытка вовсе исключить из процесса разработки продукта аналитика как единицу. Но наша деятельность не ограничивается только моделированием диаграмм.
Обновление мажорной версии в большей степени направлено на повышение производительности платформы. При этом оно также способствует ускорению описания и согласования бизнес-процессов с заказчиком и облегчает взаимодействие с разработчиками. У последних становится меньше поводов возвращать схемы на доработку, а сэкономленное время всегда можно потратить на другие задачи проекта.
Вот таким стало мое знакомство с обновленной версией платформы Camunda. По мере накопления опыта и набора критической массы, я продолжу знакомить вас с тонкостями работы аналитика с этим инструментом, а пока — делитесь собственными результатами и задавайте вопросы в комментариях.
Олег Саверкин
Аналитик IRLIX
