30.07.24

Camunda 7: худшие практики

15 мин · Обучающие

Всем привет!


На связи Мстислав, архитектор решений и основатель компании REUNICO.


Одной из наиболее востребованных наших услуг является Аудит и оптимизация решений на Camunda Platform. Обращаются за ней по таким причинам:


  • Под нагрузкой появляются инциденты и deadlock’и;

  • Деградирует производительность;

  • Система плохо масштабируется.


Почему же так происходит?


Я собрал наиболее частые причины таких явлений, описав их в духе “вредных советов”. 


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


Дисклеймер. “Советы” для разработчика, описанные ниже, характерны для 7-й версии Camunda в силу особенностей архитектуры системы и API. У Camunda 8 свои “боли”, это тема для отдельной публикации.


Вредные советы аналитику


Low/no/fast-code подход


Чтобы автоматизировать бизнес-процесс не обязательно привлекать разработчиков. Справится и аналитик. Ведь главное – смоделировать процесс! С задачами прекрасно справятся коннекторы, скрипты Groovy и JS. Для моделирования достаточно освоить азы BPMN, а тестирование можно и на конечного пользователя  возложить.


когда наваял всю необходимую логику на JavaScript

(когда наваял всю необходимую логику на JavaScript)


Используйте BPM-систему для выполнения рутинных операций чтения-записи


Пусть Camunda возьмет на себя роль бэкенда и будет отвечать за запись и чтение бизнес-данных – зато на диаграмме все подробно.


пользователь ввел - Camunda записала

(пользователь ввел - Camunda записала)



Моделируйте сквозные процессы


Руководство любит прозрачность и наглядность. Следовательно, процесс нужно моделировать таким образом, чтобы вместить все его активности на одной диаграмме – от начала и до завершения. Особенно, если длиться он будет полгода.


И, наконец…


…Моделируйте процессы максимально сложно!


Правило KISS (Keep It Simple Stupid) и Best Practices придумали слабаки и джуны. Лучше я сделаю процесс посложнее, пусть все видят, какой я крутой сеньор. Не важно, что другим будет сложно его понять – главное, что его понимаю я. А для большего удобства я ещё буду моделировать его сверху вниз, забуду именовать элементы, сделаю кучу дорожек и раскрашу элементы.


люблю создавать запутанные модели процессов

(люблю создавать запутанные модели процессов)



Вредные советы для разработчика



Передавайте данные через Camunda


Зачем лишний раз усложнять архитектуру? Давайте передавать сообщения и файлы в переменных процесса, раз система позволяет это делать. Чем больше бизнес-данных в контексте процесса, тем лучше! Тем более, что Cockpit предоставляет удобный интерфейс для их просмотра.



Избегайте точек сохранения


Каждая точка сохранения (Save Point) приводит к записям в базу, а ведь база - это “бутылочное горлышко” у Camunda. А ещё возрастает нагрузка на Job Executor. Поэтому хватит и точек сохранения, устанавливаемых по-умолчанию. А с последствиями длинных транзакций пусть на проде разбираются инженеры DevOps и DBA.


база – бутылочное горлышко

(база – бутылочное горлышко)


Используйте возможности Java API по-максимуму


Не стесняйтесь пользоваться всеми возможностями, которые предоставляет Camunda Java API, ведь все знают, что Camunda создана в первую очередь для джавистов!


Если не хватает функциональности того или иного элемента BPMN – берите AbstractBpmnActivityBehavior, смело переопределяйте методы и пишите собственную логику.


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


Не пишите простой делегатный код


Почему усложнять могут только аналитики? Ведь и в написании делегатов можно показать свое мастерство:


  • Сделать один универсальный делегат для всего;

  • Поместить в делегат побольше бизнес-логики.


А правилам clean delegates пусть следуют новички.



Вместо заключения


Надеюсь, никто из читавших статью не воспринял эти “советы” всерьез и не собирается следовать им! 


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


Если вы находитесь на этапе проектирования архитектуры решения и моделирования процессов – ознакомьтесь с рекомендациями на сайте Camunda, а ещё лучше – приходите к нам на тренинги!