Программируемый коннектор DATAREON — это собственный компонент на C#, который реализует интерфейсы DATAREON Platform и работает внутри неё как обычный коннектор. Его используют, когда участок интеграции не укладывается в стандартные коннекторы: бинарный формат, легаси-система, оборудование, нестандартный протокол, файлы без структуры. Разработчик пишет только специфичную логику обмена с источником, а маршрутизация, мониторинг, обработка ошибок и повторные попытки остаются на платформе.
Главная мысль, которую я объясняю заказчикам: нестандартная точка в интеграции — не повод строить отдельную самописную систему. Достаточно закрыть кодом именно эту точку, а всё остальное оставить на стандартных механизмах шины.
Когда стандартных коннекторов достаточно
DATAREON Platform — low-code платформа, которая совмещает две роли: сервисная шина предприятия (ESB) для централизации обменов и платформа управления данными (хранилища, витрины, MDM). Из коробки у неё есть коннекторы к самым частым источникам:
| Тип источника | Чем подключается |
|---|---|
| Конфигурации 1С | Стандартный коннектор к 1С |
| Веб-сервисы, REST API | REST и SOAP коннекторы |
| Базы данных | Коннекторы к MS SQL, PostgreSQL |
| Файлы со структурой | Файловый коннектор (JSON, XML) |
| Почта | Почтовый коннектор |
Для большинства проектов этого хватает: обмен между 1С:ERP, БП, ЗУП, сайтом и CRM собирается из стандартных блоков и настраивается, а не программируется.
Где стандартные коннекторы заканчиваются
Корпоративные ИТ-ландшафты редко бывают «чистыми». Типовые ситуации, когда готового коннектора нет:
- Легаси-системы без API, с обменом через специфичные файлы или собственный протокол.
- Бинарные форматы и промышленное оборудование.
- Особые требования к безопасности: шифрование, подпись, нестандартная аутентификация.
- Неструктурированные файлы: DOCX, XLSX, PDF, чертежи, которые нужно собрать, а не разобрать.
- Мессенджеры и внешние сервисы с нетривиальной логикой авторизации и лимитами.
В этот момент у команды появляется соблазн написать отдельный сервис интеграции «на всё». Это ошибка, если нестандартен только один участок маршрута: появляется вторая система со своим мониторингом, логами, деплоем и людьми, которые её понимают.
Как устроен программируемый коннектор
Программируемый коннектор — это библиотека на C#, реализующая интерфейсы платформы. После подключения она становится частью общего контура:
| Отвечает разработчик | Отвечает платформа |
|---|---|
| Подключение к источнику или приёмнику | Запуск и остановка компонента |
| Чтение и запись данных в специфичном формате | Мониторинг и журналирование |
| Преобразование в сообщение платформы | Маршрутизация и преобразования на остальных участках |
| Обработка ошибок источника | Повторные попытки и контроль доставки |
Коннектор не живёт «рядом» с шиной как надстройка, а работает внутри её механизмов управления. Администратор видит его в той же консоли, что и стандартные коннекторы, а ошибки попадают в общий журнал.
Гибридный маршрут на примере сбора файлов
Хорошо иллюстрирует подход типовая задача крупных компаний: документы лежат в локальных папках, на сетевых шарах, FTP и в облаках. Нет единой структуры, есть дубли версий, споры об актуальности и риск потери. Нужно централизованное хранилище, например NextCloud, но так, чтобы сотрудники продолжали сохранять файлы как привыкли.
Разберём маршрут по участкам:
- Приёмник. У NextCloud есть REST/WebDAV API — значит, подходит стандартный REST-коннектор без доработок.
- Источники. Стандартный файловый коннектор рассчитан на структурированные JSON и XML, а здесь DOCX, XLSX, PDF, DWG. Это и есть нестандартный участок.
Решение: программируемый коннектор-коллектор, который следит за источниками и забирает новые файлы. Дальше работает стандартная логика платформы.
источник (папка, шара, FTP) → программируемый коннектор-коллектор
→ обработка и классификация на платформе
→ стандартный REST/WebDAV-коннектор → централизованное хранилище
Классифицировать файлы можно по расширению, исходному пути и имени, при необходимости — по метаданным. Аудит действий и повторные попытки доставки обеспечивает платформа. Пользователям не нужно ничего менять в своей работе и проходить обучение — это часто важнее технической элегантности.
Как принять решение: чек-лист для ИТ-директора
Перед тем как заказывать разработку коннектора, проверьте:
- Действительно ли нет стандартного пути. Часто у «легаси» есть база данных, к которой можно подключиться SQL-коннектором, или выгрузка в файл, который можно сделать структурированным.
- Какой участок нестандартен. Источник, приёмник или преобразование? Код нужен только там.
- Кто будет сопровождать C#-код. Это отдельная компетенция; заложите документацию и передачу знаний.
- Как коннектор будет тестироваться и обновляться вместе с версиями платформы.
- Что с нагрузкой и объёмами. Сбор сотен тысяч файлов или поток телеметрии требует продуманных порций и контроля повторов.
Сроки, риски и стоимость
Разработка программируемого коннектора — это небольшой самостоятельный проект: анализ интерфейса источника, разработка, тестирование на реальных данных, ввод в эксплуатацию. Сроки зависят от сложности протокола и качества документации источника — от пары недель для простых случаев до нескольких месяцев для оборудования и закрытых протоколов.
Основные риски:
- Источник без документации: время уходит на исследование протокола.
- Изменения на стороне источника ломают коннектор — нужен мониторинг и тесты.
- Код без владельца: через год никто не помнит, как он работает.
Стоимость оценивается после анализа источника; ориентир для расчёта работ — ставка 2 500 ₽/ч. Почти всегда это дешевле, чем отдельная интеграционная система, которую придётся сопровождать параллельно с шиной.
Не заменяйте стандартные механизмы там, где они работают. Расширяйте платформу только в той точке, где возникает специфическая задача.
Если вы строите интеграционный контур на шине данных или выбираете между шинами, помогу с архитектурой в рамках услуги интеграционной шины 1С; подключение 1С-систем к внешним сервисам — интеграция 1С по API.
Коротко
- Программируемый коннектор DATAREON — компонент на C#, встроенный в механизмы платформы.
- Он нужен для бинарных форматов, легаси-систем, оборудования и неструктурированных файлов.
- Пишите код только для нестандартного участка, остальное оставьте стандартным коннекторам.
- Мониторинг, журналирование и повторные попытки коннектор получает от платформы.
- Перед разработкой проверьте, нет ли стандартного пути, и определите, кто будет сопровождать код.
