REUNICO | Разработка и сопровождение ПО: Все, что вы хотели знать о Camunda, но боялись спросить

Все, что вы хотели знать о Camunda, но боялись спросить

Всем привет!

Мы устали отвечать клиентам на однотипные вопросы и решили составить список наиболее популярных и максимально подробно ответили на них. 🤘 Итак, долгожданная статья, основанная на личном опыте.

Все, что вы хотели знать о Camunda, но боялись спросить


Что такое Camunda?

Чтобы не повторяться: Описание Camunda BPM на нашем сайте. Там же: о преимуществах использования Camunda перед legacy BPMS и самописными процессными движками, сценариях применения, пользе для бизнеса и разработчика.

С чего начать изучение Camunda?

Официальный сайт: Get started, а также документация по системе. Документацию нет смысла заучивать, достаточно обращаться к ней по необходимости, используя как справочник. Если пользуетесь поисковыми системами, то после перехода по ссылке обратите внимание, что вы находитесь на странице с актуальной версией документации (выпадающий список для переключения версии находится в левом верхнем углу страницы).

Видеокурс от Nial Deehan на Vimeo. Наглядно, интересно и познавательно.

Лучшие практики Camunda. До недавнего времени эта информация была доступна только для партнеров. Хорошая база знаний, сгруппированная по предметным областям, стейкхолдерам, этапам проекта.

Видеоматериалы по Camunda на нашем канале Youtube.

При наличии достаточного опыта и, в случае, если вы являетесь пользователем Enterprise версии Camunda (или сотрудником компании-партнера) - можно попробовать свои силы в прохождении сертификации. Области знаний, проверяемые на экзамене, приведены на рисунке ниже.

Camunda Certification

Сайзинги

Официальные рекомендации по конфигурации узлов:

  • Начальная: 1-2 CPU, 1-8 GB RAM
  • Средняя: 2-4 CPU, 4-16 GB RAM
  • Нагруженная: 4-64 CPU, 16-128 GB RAM

Как показывает практика, начальной конфигурации достаточно для большинства проектов. Производительность рекомендуется увеличивать путем горизонтального масштабирования (увеличение числа узлов в кластере Camunda). О средней конфигурации стоит задуматься, в случаях:

  • Запуск более 100 экземпляров процесса в секунду
  • Делегатный код, активно использующий ресурсы процессора

Факторы, определяющие требуемый объем базы данных:

  • Выбранный уровень аудита (истории изменений). Чем подробнее (FULL) - тем больше объем базы
  • Хранение бизнес-контекста в переменных процесса (JSON, XML, сериализованные POJO)
  • Срок жизни экземпляра процесса (чем длиннее процесс - тем больший объем требует он)

Ноутбук, Core i5, 8 GB RAM - позволяет запускать от 100 до 500 инстансов процесса в секунду. Из личного наблюдения, факторы влияющие на производительность:

  • Число асинхронных задач, сопровождающихся записью состояния процесса в базу (flush)
  • Вызовы Java-кода (listeners, delegates)
  • Вызовы во внешние системы

Высоконагруженные решения

Goldman Sachs

Использование механизма выполнения процессов Camunda для процессов оркестровки в глобально распределенной среде.

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

24 Hour Fitness

Одно из крупнейших предприятий в области здоровья и фитнеса в США, обслуживает почти четыре миллиона членов в более чем 400 клубах. Как круглосуточный бизнес, когда участники получают доступ к клубам и онлайн-приложениям круглосуточно, сбои системы неприемлемы.

Архитектор решений Джимми Флойд объясняет: «Мы проталкиваем огромные объемы через Камунду, на завершение которой нужны миллисекунды». Это включает:

- Развернуто около 330 описаний процессов с более чем 90 миллионами выполненных экземпляров процессов в день.
- Около 80 миллионов DMN моделей развернуто с более чем 90 миллионами оцененных решений в день

Внедрение Camunda в ИТ-ландшафт предприятия

  • Java-приложения: shared container-managed engine
  • Отличный от Java техстек (.NET, PHP, Python): standalone remote engine, взаимодействие через REST
  • Java (Spring, Spring Boot, микросервисная архитектура): embedded engine - встраивание Camunda в приложение или микросервис

Варианты реализации UI

От простого в реализации (с ограниченным функционалом) к трудоемкому (с богатыми возможностями для пользователей):

  • Tasklist + Generated Forms
  • Tasklist + Embedded Forms (Camunda Form SDK)
  • External Forms
  • Доработка, плагины Tasklist
  • Custom UI - Angular / React + Camunda REST API

Способы интеграции с внешними системами

  • Делегатный код, реализующий потребителя / поставщика для Kafka, JMS (Active MQ, Rabbit MQ)
  • Делегатный код + фреймворк наподобие Apache CXF
  • Out-of-box коннекторы Camunda (http-connector, soap-connector) - позволяют работать с REST, SOAP веб-сервисами
  • Camunda REST API
  • JDBC, JPA для работы с данными, справочниками

Возможности переиспользования, повторного использования компонентов процесса

  • Описания процессов, обернутые в call activity
  • Spring Beans + Delegate Expression
  • Java Delegates

Обеспечение отказоустойчивости

  • 1+N nodes + shared database + балансировка (nginx)
  • 1+N docker nodes + shared database + swarm

CI/CD

Применимо все то же, что применяется при разработке любых Java-приложений: исходный код и модели процессов хранятся в системе контроля версий (git, Gitlab, Bitbucket); тестирование процессов - JUnit (+ camunda-bpm-assert); сборка и поставка - Jenkins, хранение артефактов - Nexus.

Поддержка стандартов информационной безопасности

«Из коробки» не задекларировано, поскольку это не задача процессного движка, а скорее аспекты применения конкретных исполняемых сред, операционных систем, СУБД, СКЗИ.

Тем не менее, для пользовательских компонентов (Tasklist, Cockpit, Admin) соблюдаются стандартные лучшие практики в части обеспечения безопасности веб-приложений. Существуют богатые возможности по настройке прав доступа и авторизаций. Поддерживается LDAP-аутентификация и SSO.

Возможность исполнения разных версий процессов

Могут одновременно исполняться несколько версий одного и того же процесса (версия процесса обновляется, если система обнаруживает изменения в описании процесса (при перезапуске embedded engine, загрузке модели процесса через REST / Java API / Cockpit, развертывании артефакта с описанием процесса в контейнере сервлетов). Существующие экземпляры процессов при изменении описания не затрагиваются, но могут быть смигрированы на новую версию.

Camunda BPM vs Activiti BPM

Camunda ответвилась от Activiti в 2013 году. С этого момента кодовая база Camunda развивается самостоятельно, значительная часть ядра переписана с нуля, что обеспечило более высокую производительность и отказоустойчивость (в сравнении с оригинальным кодом).

График, приведенный ниже, показывает динамику объема исходного кода Camunda в сравнении с Activiti, подтверждающую, что Camunda является более живым и активно развивающимся open-source проектом.



Основатели Camunda также являются одними из разработчиков стандартов BPMN и DMN. Camunda BPM отличается ориентированностью на нотации и строгостью следования стандартам.

Материалы по теме:
Пять причин перейти с Activiti на Camunda
Camunda Engine Evolution since Activiti Fork

Наиболее распространенные ошибки при внедрении Camunda

1. Надеяться исключительно на собственную компетенцию

Можно обратиться к сертифицированному партнеру, а можно и нет (если хочется самостоятельно погрызть кактус, собрать грабли и набить шишки).

2. Помещать весь бизнес-контекст в переменные процесса

Известны примеры, когда волей разработчика в переменные процесса записывались объекты, имеющие сотни и тысячи атрибутов. Типичные последствия - неконсистентность данных и снижение производительности. Общей рекомендацией является помещать в переменные процесса идентификаторы (ключи) обрабатывамых объектов, оставляя бизнес-контекст за пределами процесса.

Интересная статья по теме: A Data-centric View on Traditional BPM.

3. Некачественное моделирование процессов

Существует ряд антипаттернов, которых стоит избегать, например: "процесс-бог"

Camunda антипаттерн

Правильный подход (декомпозиция на отдельные процессы в границах микросервисов):

Camunda collaboration diagram

Кроме того, стоит придерживаться рекомендаций по моделированию процессов, описанных в Best Practices: Creating Readable Process Models.

4. Пытаться обойтись без бизнес-аналитика или разработчика

В первом случае имеем некачественные модели процессов, кое как натянутые на процессный движок. Во втором - хаотичное нагромождение Javascript-кода, разного рода скриптов и плагинов в standalone сборке системы.

В отличие от разного рода iBPMS, no-code, low-code систем Camunda подчеркивает важность сотрудничества бизнеса и ИТ в деле построения процессных приложений.

5. Начинать масштабный проект без PoC или пилота

Успешно зарекомендовавшая себя последовательность этапов:

  1. Оценить необходимость внедрения, сравнить Camunda с альтернативными решениями.
  2. Выбрать подходящий для автоматизации бизнес-процесс. Предпочтение стоит отдавать процессам, максимально демонстрирующий премущества использования BPM и раскрывающим потенциал системы. Желательно, чтобы в выбранном процессе присутствовали как пользовательские, так и сервисные задачи. Стоит избегать политизированных или излишне сложных процессов.
  3. Proof of Concept. Смоделируйте целевой процесс. Он должен быть четким, понятным и точным, иметь максимальную прозрачность. Для выполнения пользовательских задач на данном этапе рекомендуется использовать стандартный Tasklist Camunda, чтобы не тратить силы на реализацию кастомного интерфейса. Следует избегать трудоемкой разработки, сконцентрировав усилия на достижении целей PoC.
  4. Последующие процессы. Постарайтесь не делать слишком много параллельных проектов в начале, чтобы новые знания влияли на вашу будущую работу. Если у вас есть параллельные пилоты, организуйте обмен знаниями между командами. В идеале пусть команда первого пилота непосредственно реализует следующий процесс.

6. Запускать mission critical процессное приложение без enterprise лицензии

Вы бы стали ездить на автомобиле без страховки?

Наличие преднастроенных бизнес-процессов

Camunda не включает в поставку преднастроенные бизнес-процессы. Вместе со standalone сборкой системы поставляются примеры процессных приложений (например invoice receipt), но они предназначены прежде всего для ознакомительных целей.

Компания Реюнико готова предоставить клиентам ряд типовых процессных приложений:

  • Банковская сфера: заключение договора РКО и открытие расчетного счета; кредитный конвейер; скоринг
  • Страхование: калькуляция страховых продуктов; продажа полисов
  • Ритейл и процессинги: программа лояльности
  • Customer success management и претензионная деятельность
  • Взаимодействие между подразделениями компании, предприятиями холдинга (обмен и согласование документов)