В этом году вышел релиз Camunda 8 — это последнее обновление мажорной версии платформы за минувшие семь лет. В статье я поделюсь собственным опытом работы в «восьмерке» и расскажу об основных отличиях от предыдущей версии, но при этом не полезу глубоко «под капот», а опишу их глазами аналитика. Мой коллега Сергей, бекенд-разработчик, ёмко и в то же время достаточно точно определил основную суть и назначение этого инструмента: «Совместное использование 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», где вы можете найти подходящее решение для вашей задачи. «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. С другой — большое количество символов, обилие переходов между тасками, зачастую без шлюзов, использование большей части доступных символов событий и развитие процесса во всех возможных направлениях поначалу просто сбивали с толку. Перед нами встала задача не только переделать схемы под обновленную версию Camunda, но и привести их в порядок, сохранив всю заложенную логику. Каким образом? События и ссылки мы заменили сообщениями. Комплексные шлюзы — совокупным использованием параллельных и исключающих. В итоге совместными усилиями нам удалось достаточно быстро оптимизировать все процессы. Отсутствие части элементов нотации никак не помешало, напротив облегчило восприятие получившихся схем. В своей работы мы в основном полагались на официальную документацию — Overview Components | Camunda Platform 8 Docs. Новая версия Camunda, может и ограничивает «всю мощь» BPMN, но взамен предлагает не меньшее могущество. При этом новый «Modeler» становится ещё более приспособленным, гибким для работы бизнес-аналитика, дает ему всё меньше поводов заглядывать «под капот». Может сложиться впечатление, что обновление — своего рода попытка вовсе исключить из процесса разработки продукта аналитика как единицу. Но наша деятельность не ограничивается только моделированием диаграмм. Обновление мажорной версии в большей степени направлено на повышение производительности платформы. При этом оно также способствует ускорению описания и согласования бизнес-процессов с заказчиком и облегчает взаимодействие с разработчиками. У последних становится меньше поводов возвращать схемы на доработку, а сэкономленное время всегда можно потратить на другие задачи проекта. Вот таким стало мое знакомство с обновленной версией платформы Camunda. По мере накопления опыта и набора критической массы, я продолжу знакомить вас с тонкостями работы аналитика с этим инструментом, а пока — делитесь собственными результатами и задавайте вопросы в комментариях. Аналитик IRLIX