Видеокурс Camunda 8: Введение

Друзья, всем привет!

На связи Мстислав, компания Реюнико. И у меня для вас отличные новости! Мы выпускаем бесплатный видеокурс для команд разработки, желающих освоить Camunda 8.

В рамках этого видеокурса мы расскажем:

• Как можно использовать Camunda 8 в качестве песочницы, среды для моделирования и отладки исполняемых процессов?

• Какой инструментарий для этого понадобится?

• Как смоделировать и исполнить в Camunda 8 простой процесс?

• Как обеспечить работу участников процесса – людей?

• Как реализовать сервисные задачи?

• Как моделировать сложные процессы и оркестрировать микросервисы?

• Каким принципам стоит следовать при проектировании решений на Camunda, а чего стоит избегать?

Но для начала, в качестве вступления, я хотел бы рассказать, когда нужна "комунда" и как ее применять.

Иногда мне, как архитектору решений, приходится сталкиваться с непониманием как заказчиков, так и ИТ-специалистов – а зачем нам нужна BPM-система или оркестратор сервисов и как мы будем её использовать?

Это непонимание варьируется от скепсиса (или откровенного хейта) от вчерашних выпускников технических вузов в духе "горе программеры выдумывают сложности, проще все реализовать  в коде", до бизнесменов, представляющих себе Camunda как "волшебную палочку", некий магический low-code BPM-инструмент, позволяющий без разработки автоматизировать любой производственный процесс.

Для того, чтобы правильно ответить на вопрос, нужна ли вам BPM-система в целом (и Camunda в частности), необходимо для начала рассмотреть сценарии, когда она не нужна.

Когда нужна и не нужна Camunda?

Типовые задачи

Мы все знаем поговорку: "Для каждой задачи нужен свой инструмент". И примерно для 80% бизнес-процессов существуют коробочные (out-of-the-box) решения, обеспечивающие их выполнение с меньшими (нежели Camunda) затратами времени и денег. Так, например, для работы бухгалтерии нужна система бухгалтерского учета, для управления материалами веб-сайта – CMS-система, а для взаимодействия с клиентами – CRM. 

Сложность процесса

Применение BPM-системы избыточно, если процесс имеет простую, линейную структуру. Как упрощенно выглядит регистрация нового клиента малого предприятия? Необходимо получить данные клиента из какого-то источника (формы обратной связи на сайте, анкеты клиента, партнерской системы) и ввести их в CRM-систему. Потенциальные ошибки, которые могут возникнуть в таком процессе, скорее всего будут связаны с недоступностью систем и легко могут быть обработаны при помощи retry-механизмов или путем применения асинхронных вызовов.

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

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

Можно ли реализовать такой функционал самостоятельно, без применения системы-оркестратора? Большой вопрос. Наврное да, если у вас есть миллионы долларов и компетентная команда разработки.

Техстек и ИТ-ландшафт

В больших организациях различные бизнес-задачи и функции могут быть автоматизированы с использованием различных технологий. Так, например, подразделение, ответственное за анализ и обработку данных, может использовать Python. Финансовые сервисы могут использовать Java / Spring Boot. А приложения конечного пользователя – разработаны на Node.JS или Go.

Процессы могут включать в себя обращения к системам Enterprise-уровня (Core Banking, CRM, Service Desk), вызов программных интерфейсов (API), обмен данными через брокеры сообщений, выполнение пользовательских задач (выполняемых людьми или программными роботами) и многое другое.

Как управлять таким оркестром? Конечно же, при помощи дирижера, способного обеспечить профессиональное исполнение даже самой сложной мелодии!

Высоконагруженные системы

Высокая нагрузка – это не только про число запросов в секунду, но также и другие важные атрибуты качества:

• Надежность и отказоустойчивость;

• Возможность масштабирования;

• Высокая доступность;

• Производительность.

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

Или, например, ненагруженная запросами система может представлять собой mission-critical приложение и даже незначительный простой может повлечь за собой многомиллионные убытки.

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

Архитектура Camunda 8

Ценой высокой отказоустойчивости Camunda 8 стало усложнение архитектуры. 

Runtime

«‎Сердцем» системы является кластер Zeebe, состоящий из набора реплицирующихся между собой брокеров (Brokers). Каждый брокер хранит описания процессов и исполняющиеся экземпляры в распределенной СУБД RocksDB, представляющей собой хранилище типа ключ-значение (LST-tree). Взаимодействие с внешним миром осуществляется через шлюзы (Gateways) которые могут быть как встроены в брокер, так и работать в виде независимых узлов.

При первом подключении брокер получает информацию о топологии сети и начинает обмен с другими узлами. Данные рантайма шардированы – разделены на заданное настройками число партиций (Partitions). Для каждой из партиций существует 1 лидер (Leader) и N последователей (Followers), которые получают данные от лидера и помещают их в локальные реплики партиции. ​​Каждый брокер кластера является лидером одной партиции и последователем для других. Если по каким-то причинам лидер становится недоступен, происходят выборы и новым лидером становится один из последователей (протокол Raft).

Запуск процессов, получение и завершение задач, отправка сообщений выполняются клиентом (Zeebe Client), компонентом воркера (Job Workers). Воркер и клиент могут быть реализованы с использованием любого языка программирования или фреймворка: Spring Boot, .NET, Go, PHP. Есть даже клиент, написанный на Delphi! Взаимодействие клиента-воркера с кластером Zeebe происходит по протоколу gRPC.

История процессов

История процессов, задач и переменных хранится в индексах Elasticsearch.

Именно с индексом Elasticsearch работают веб-приложения Camunda 8: Tasklist, Operate и Elasticsearch. В нем же они хранят свою служебную информацию.

• Operate – интерфейс оператора, позволяющий в моменте получить текущее состояние бизнес-процессов, внести изменения и обработать возникающие инциденты;

• Tasklist – исполнение пользовательских задач;

• Optimize – приложение для анализа бизнес-процессов, теперь входит в стандартную поставку.

Design-time

Для моделирования процессов можно использовать либо классический Desktop Modeler, либо Web Modeler, предоставляемый как в SaaS-, как и в Self Managed-версии Camunda.

Заключение

Итак, если мое вступление вас не испугало – предлагаю переходить к практике!

Спасибо за внимание и – успехов в освоении Camunda 8!