Что такое коннектор? Как выглядит код коннектора? И как коннекторы могут использоваться в различных сценариях?

От переводчика: это статья 2022 года, но она важна для общего понимания архитектуры коннекторов Camunda и сценариев использования, поэтому ее стоит прочитать. Лучше автора идеи об этом никто не расскажет.
Что касается современного состояния вопроса, то многое изменилось в лучшую сторону. Когда коннекторы в Camunda только появились , они действительно вызывали много критики: архитектура была нестабильной, SDK недоступен, в self-managed среде использовать их было нельзя, и документация оставляла желать лучшего.
Сейчас это все в прошлом – смотрите краткую справку в конце статьи.
А пока слово Бернду Рюкеру.

Когда в этом году была выпущена Camunda Platform 8, мы анонсировали коннекторы и предоставили несколько предварительных версий коннекторов в нашем SaaS-решении, например, отправка email через SendGrid, вызов REST API или отправка сообщения в Slack.

С тех пор многие задавались вопросом, что такое коннектор, как он разрабатывается и как его можно использовать в Self-Managed-окружении. Мы пока не публиковали много информации о технической архитектуре коннекторов, поскольку она всё ещё находится в разработке. Тем не менее, я отлично понимаю, что вам может быть интересно узнать больше, чтобы вдохновиться коннекторами так же, как и я.

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

Что такое коннектор?

Коннектор — это компонент, который взаимодействует со сторонней системой через API, позволяя таким образом управлять этой системой с помощью Camunda (или, наоборот, позволяя этой системе влиять на оркестрацию в Camunda).

Коннектор состоит из небольшого программного кода, необходимого для взаимодействия со сторонней системой, и некоторых элементов пользовательского интерфейса, встроенных в Camunda Modeler.

Звучит довольно обобщённо, согласен. Давайте станем чуть конкретнее и различим типы коннекторов:

1. Исходящие коннекторы (Outbound connectors)

Необходимо выполнить действие во внешней системе, когда процесс достигает задачи сервиса. Например, вызвать REST-эндпоинт или отправить сообщение в Slack.

2. Входящие коннекторы (Inbound connectors)

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

Вебхук (Webhook): HTTP-эндпоинт становится доступен извне и может, например, запустить экземпляр процесса при вызове.
Подписка (Subscription): Открывается подписка на события во внешней системе, например, в системе обмена сообщениями или Apache Kafka, и новые события сопоставляются с ожидающим экземпляром процесса в Camunda.
Опрос (Polling): Внешний API регулярно опрашивается на наличие новых событий, например, проверка папки в Google Drive или на FTP.

Пример исходящего коннектора

Рассмотрим кратко один из исходящих коннекторов — REST-коннектор. Вы можете задать ряд свойств, например, какой URL вызывать и каким HTTP-методом. Это настраивается через Web Modeler, а значит, эти свойства в конечном итоге попадают в XML BPMN-модели процесса. Перевод интерфейса в XML осуществляется с помощью механизма шаблонов элементов (element templates). Это делает использование коннекторов удобным и наглядным.

Теперь нам также необходим код, который действительно выполняет исходящий вызов. Интеграционная архитектура Camunda Platform 8 предоставляет набор средств разработки (SDK), с помощью которого можно программировать такой коннектор. Упрощённо говоря, исходящий REST-коннектор реализует метод execute , который вызывается каждый раз, когда экземпляр процесса должен выполнить вызов через коннектор. При этом передаётся контекст, содержащий все входные данные, конфигурацию и абстракцию для хранилища секретной информации.

Однако нужен и связующий код, который будет вызывать эту функцию каждый раз, когда экземпляр процесса достигает соответствующей задачи сервиса. Эту роль выполняет исполняющая среда коннекторов (connector runtime). Она регистрирует обработчики заданий (job workers) в Zeebe и вызывает функцию коннектора при поступлении новых заданий.

Эта исполняющая среда коннекторов (connector runtime) не зависит от конкретного кода коннектора, который выполняется. На самом деле одна среда может обслуживать сразу несколько коннекторов. Поэтому каждый коннектор содержит собственные метаданные.

С учётом этого мы создали исполняемую среду на базе Spring Boot, которая может обнаруживать все исходящие коннекторы в classpath и регистрировать необходимые job workers. Это делает тестирование отдельного коннектора невероятно простым: вы можете запускать его локально. Кроме того, вы можете собрать Spring Boot-приложение, включающее все нужные коннекторы, для работы в Self-Managed-установке Camunda Platform 8.

Параллельно мы разработали исполняющую среду и для нашей облачной SaaS-платформы, работающей в Google Cloud. Хотя у нас также используется универсальная исполняющая среда на базе Java, все исходящие коннекторы развёрнуты в виде Google Functions. В этом случае секреты обрабатываются через Google Cloud Security Manager.

Самое замечательное здесь — это то, что код самого коннектора не знает ничего об окружении, в котором он выполняется, что делает возможным использование коннекторов по всему экосистемному стеку Camunda Platform 8.

Пример входящего (inbound) коннектора

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

Сейчас мы проектируем и валидируем архитектуру входящих коннекторов, так что она находится в стадии активной доработки. Тем не менее, уже можно выделить несколько ключевых принципов, которые, скорее всего, сохранятся:

Параметры можно будет настраивать через UI в Camunda Modeler, и они будут сохраняться в BPMN-модели.
Основной код коннектора будет исполняться в различных средах.
Метаданные будут использоваться для того, чтобы runtime мог автоматически обнаруживать и запускать новые коннекторы.

Вот прототип коннектора, принимающего сообщения AMQP (например, от RabbitMQ):

Статус и дальнейшие шаги

На данный момент только небольшая часть нашей работы над коннекторами доступна публично. Поэтому в версии Camunda Platform 8.0 существуют некоторые ограничения:

SDK для коннекторов пока недоступен для широкой публики — мы хотим сначала его доработать, чтобы избежать ситуации, когда написанные на ранней версии SDK коннекторы придется переделывать. (Уже доступен – см. ниже.)
Код существующих коннекторов (REST, SendGrid и Slack) не опубликован и пока не может быть запущен в Self-Managed-среде. (Уже может!)
UI-поддержка доступна только в Web Modeler, но не в Desktop Modeler.

Мы активно работаем над этими направлениями и планируем выпустить SDK коннекторов до конца года. После этого мы сможем предоставить исходники и бинарники существующих коннекторов, чтобы их можно было запускать в Self-Managed или анализировать их внутреннюю реализацию.

Вместе с SDK мы планируем выпустить шаблоны коннекторов (connector templates), которые позволят удобно определять UI-параметры и атрибуты, необходимые для вашего коннектора, а также делиться этими шаблонами с другими членами вашей команды.

Параллельно мы работаем над новыми встроенными коннекторами (например, Slack-коннектор был выпущен на прошлой неделе) и делаем их open source. Мы также сотрудничаем с партнёрами, которые хотят разрабатывать и публиковать свои коннекторы в экосистеме Camunda. В будущем мы хотим запустить специальный каталог (или маркетплейс), где можно будет легко найти доступные коннекторы, их возможности и ограничения.

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

Итог

Ключевой строительный блок для реализации коннекторов — это наш SDK для входящих и исходящих коннекторов. Исходящие коннекторы могут быть реализованы на базе webhook, подписки или polling-механизма. Это позволяет писать код коннектора, независимый от среды исполнения, и использовать его как в Camunda SaaS, так и в Self-Managed-среде.

В свою очередь, шаблоны коннекторов обеспечат удобный процесс моделирования при использовании коннекторов в BPMN-моделях. Мы уже продвинулись далеко вперёд — и впереди нас ждёт много интересного. Оставайтесь с нами!

Как обстоят дела по состоянию на сегодня

🧩 SDK для коннекторов

Camunda официально выпустила Connector SDK, который позволяет разрабатывать собственные коннекторы на Java. SDK абстрагирует детали взаимодействия с Zeebe и предоставляет удобные API для обработки входных и исходящих данных, работы с секретами и управления конфигурацией. Это позволяет создавать коннекторы, которые можно использовать как в SaaS, так и в Self-Managed средах. Кроме того, существует экспериментальная реализация SDK на Node.js от сообщества, которая следует API Java-версии.GitHub

🧱 Шаблоны коннекторов (Connector Templates)

Шаблоны коннекторов — это JSON-файлы, которые определяют, как BPMN-элемент отображается и настраивается в Camunda Modeler. Они позволяют создавать удобный UI для настройки параметров коннектора. В Web Modeler можно создавать и публиковать шаблоны прямо в интерфейсе. В Desktop Modeler шаблоны подключаются через файловую систему.

🔌 Готовые коннекторы и маркетплейс

Camunda предоставляет набор готовых коннекторов, включая интеграции с REST, Slack, SendGrid, Google Drive, AWS Lambda и другими сервисами. Эти коннекторы доступны как в Web Modeler, так и для использования в Self-Managed средах. Также существует Camunda Marketplace, где можно найти дополнительные коннекторы, разработанные Camunda, партнёрами и сообществом.Camunda 8 Docs | Camunda 8 Docs

📦 Поддержка Self-Managed

С версии Camunda 8.1 появилась возможность запускать готовые коннекторы в Self-Managed установках. Это означает, что теперь можно использовать как стандартные, так и собственные коннекторы в локальных средах.

🛠️ Разработка собственных коннекторов

С помощью Connector SDK и шаблонов коннекторов можно создавать собственные интеграции с любыми внешними системами. Это особенно полезно для интеграции с легаси-системами или внутренними сервисами, специфичными для вашей организации.

7️⃣ Коннекторы в "семерке"

Коннекторы, как они реализованы в Camunda 8, не могут быть напрямую использованы в Camunda 7. Camunda 8 и Camunda 7 имеют разные архитектуры и подходы, и коннекторы для Camunda 8 ориентированы на работу с Zeebe (системой обработки рабочих процессов в Camunda 8), тогда как Camunda 7 использует более традиционную BPMN-платформу с движком на основе Activiti.

В Camunda 7 коннекторы, как правило, реализуются через внешние задачи (External Tasks) или сервисные задачи (Service Tasks), и можно интегрировать сторонние сервисы через эти механизмы, но это делается с использованием другого подхода, чем в Camunda 8.

Если вы хотите интегрировать внешние системы с Camunda 7, вам нужно будет использовать другие способы, такие как написание собственного кода для взаимодействия с внешними сервисами (например, через REST API, JMS, или другие протоколы), а не через коннекторы, предназначенные для Camunda 8.

Подписывайтесь на наши телеграм каналы:
Jmix.ru — платформа быстрой разработки B2B и B2G веб-приложений на Java.
BPM Developers — про бизнес-процессы: новости, гайды, полезная информация и юмор.

Технический взгляд на архитектуру коннекторов Camunda