OpenConnector на своём сервере или хостинг OOMOL? Сначала запустите интеграцию

Когда вы подключаете Google, Zoom или monday.com к приложению или агенту, возникает вопрос: раз OpenConnector — проект с открытым исходным кодом, почему бы сразу не развернуть свой шлюз?

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

Большинству команд, которым нужно быстро выпустить функцию, мы рекомендуем начать с хостинга OOMOL и подключить сервис через SDK. Разворачивайте OpenConnector самостоятельно, если сервис подключения и учётные данные должны оставаться в вашей инфраструктуре или требуется изменить шлюз либо реализацию коннекторов.

Можно двигаться поэтапно: запустить интеграцию на хостинге, параллельно подготовить собственные OAuth-приложения и мигрировать, когда всё будет готово.

Отталкивайтесь от текущих задач

Что вам нужно сейчас	Рекомендуемый вариант
Быстро подключить приложения; внешний хостинг допустим	Начать с хостинга OOMOL
Совместно использовать подключения и централизованно управлять доступом участников и операциями	Командные функции хостинга OOMOL
Использовать собственные OAuth-приложения, настройка или проверка которых ещё не завершена	Начать на хостинге и оценить миграцию после подготовки
Хранить учётные данные, шлюз и записи выполнения в своей инфраструктуре	Развернуть OpenConnector самостоятельно
Изменять код коннекторов, поведение шлюза или контролировать исходящие соединения	Развернуть OpenConnector самостоятельно

Размер компании тоже может повлиять на выбор. Но прежде всего стоит понять, какой уровень контроля нужен команде и какой объём обслуживания она готова взять на себя.

Собственное развёртывание часто начинается с OAuth

Запустив OpenConnector через Docker, вы получаете шлюз подключения. Чтобы обращаться к сервисам с OAuth, также нужно создать своё OAuth-приложение в консоли разработчика каждого сервиса.

Здесь есть два разных набора учётных данных. Client ID и Client Secret идентифицируют приложение. Токен доступа, выдаваемый после разрешения пользователя, позволяет обращаться к одобренным им ресурсам.

Первый набор вы готовите заранее. Второй появляется в процессе авторизации аккаунта.

Например, для Google нужно создать проект, включить нужные API, создать OAuth-клиент, указать URL обратного вызова и выбрать запрашиваемые разрешения. В зависимости от разрешений и сценария использования может потребоваться проверка приложения. Официальная документация Google OAuth

У других OAuth-сервисов свои правила настройки и распространения приложений. Одно подключение обычно проще обслуживать. Несколько приложений требуют отдельно поддерживать настройки клиентов, URL обратных вызовов, области доступа и статусы проверок.

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

OpenConnector сохраняет настройки OAuth, подключает аккаунты и выполняет операции. Если вы используете собственные OAuth-приложения, их создание и выполнение требований поставщиков остаются задачей команды. Подробности — в руководстве по настройке OAuth-приложений.

Хостинг оставляет больше времени на интеграцию

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

Для интеграций с поддержкой управляемых OAuth-приложений OOMOL сокращает работу по созданию и обслуживанию отдельного приложения у каждого поставщика. Вы по-прежнему подключаете свои аккаунты и подтверждаете разрешения. Сервисам с API key или другими способами аутентификации также нужны соответствующие настройки.

После подключения аккаунта хостинг OOMOL отвечает за хранение учётных данных, обновление токенов и вызовы приложений. Ваш сервер выбирает подключение через SDK, отправляет параметры и получает результат. Исходные токены поставщиков не нужно помещать в бизнес-код или запросы к агенту. Руководство по облачному Connector

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

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

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

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

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

Выбирайте OpenConnector для контроля над средой исполнения

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

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

Открытый исходный код даёт контроль и над реализацией. Исходники среды выполнения, определений коннекторов, кода исполнения операций и веб-консоли доступны публично. То же относится к Connector SDK и oo CLI. Можно изучать вызовы, добавлять интеграции и менять реализацию на основе существующего проекта. Требования к авторизации и условия использования сторонних API продолжают действовать отдельно.

Контроль предполагает обслуживание. Кто-то должен отвечать за ключи, защиту доступа, обновления, резервное копирование и устранение сбоев. Безопасность зависит от того, как выполняется эта работа.

Выберите вариант под свою среду:

• Docker Compose: запуск на своих серверах или в корпоративной сети с самостоятельным управлением хранением и доступом.
• Cloudflare Workers: самостоятельное управление OpenConnector на инфраструктуре Cloudflare, включая D1 и R2, если облачная среда допустима.
• Запуск из исходников: разработка коннекторов, отладка и изменение OpenConnector.

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

Внутреннему шлюзу тоже нужен подходящий исходящий доступ. Вызовы внешних SaaS, таких как Google или Zoom, требуют связи с их API и адресами авторизации. В полностью изолированной сети сначала выясните, есть ли у целевого сервиса доступный внутренний интерфейс.

Инструкции — в руководстве по самостоятельному развёртыванию OpenConnector.

Начните на хостинге и мигрируйте после подготовки

Если вы планируете собственные OAuth-приложения, но ещё настраиваете их или ждёте проверки, ведите две задачи параллельно: проверяйте бизнес-интеграцию на хостинге и готовьте учётные данные и инфраструктуру для своего развёртывания.

Оба варианта используют пакет SDK @oomol-lab/connector. В нём есть Connector для хостинга, ProjectConnector для конечных пользователей продукта и OpenConnector для самостоятельно управляемой среды. Клиенты используют общие типы операций и соглашения о вызовах, но отличаются аутентификацией, границами аккаунтов и доступными методами. Справочник TypeScript SDK

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

Подготовка к миграции включает:

1. Развёртывание и защиту OpenConnector в новой среде, настройку своих OAuth-приложений.
2. Создание подключений аккаунтов и проверку нужных областей доступа.
3. Изменение клиента SDK, URL сервиса, токена среды выполнения и выбора подключения.
4. Проверку поддержки нужных операций и функций команд, пользователей проекта и разрешений, от которых зависит приложение.
5. Проверку одной часто используемой операции, затем постепенное переключение остальных вызовов.

Подключения аккаунтов и функции управления хостингом требуют отдельной работы. Общий SDK позволяет сохранить вызовы и структуры параметров, сокращая объём повторной интеграции с каждым API.

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

Начните с одной реальной операции

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

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

Если собственное развёртывание уже обязательно, подготовьте среду по руководству OpenConnector и завершите настройку OAuth-приложений.

Выберите подходящий для текущих задач старт. Хостинг помогает быстрее запустить интеграцию, а открытый OpenConnector позволяет при необходимости управлять её кодом, учётными данными и средой исполнения.