В этом году вышел релиз 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 интеграции, которые разделяют на:

1. Входящие — позволяют запустить какой-либо процесс извне (снаружи);

2. Исходящие — позволяют обращаться к сторонним системам.

Выделяют также коннекторы различных уровней — от подключения к брокеру сообщений, к примеру, 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