Найти в Дзене
REUNICO

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

Оглавление

Всем привет!

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

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

  • Под нагрузкой появляются инциденты и deadlock’и;
  • Деградирует производительность;
  • Система плохо масштабируется.

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

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

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

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

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

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

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

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

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

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

-2

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

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

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

И, наконец…

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

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

-3

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

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

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

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

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

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

-4

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

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

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

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

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

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

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

  • Сделать один универсальный делегат для всего;
  • Поместить в делегат побольше бизнес-логики.

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

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

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

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

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