Когда стандартных коннекторов недостаточно: как решать нешаблонные задачи интеграции на DATAREON Platform

В большинстве интеграционных проектов не нужно разрабатывать собственные механизмы обмена данными. В DATAREON Platform есть стандартные готовые коннекторы для распространённых систем и сценариев: к 1С, веб-сервисам и REST API, MS SQL, PostgreSQL, файлам и электронной почте. То есть значительную часть задач можно решать стандартными средствами.

Но корпоративные ИТ-ландшафты редко состоят только из типовых систем и предсказуемых интерфейсов. Это могут быть бинарные форматы обмена, легаси-системы, требование передавать данные через нестандартный протокол или работать с файлами без чёткой структуры.

В этот момент перед командой возникает вопрос: что делать с тем участком интеграции, который не укладывается в стандартный сценарий?

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

Так можно расширить интеграционные возможности без полного переписывания — достаточно использовать программируемый коннектор.

Начнём с основ: DATAREON Platform — это low-code-платформа для управления корпоративными данными и интеграционными потоками. Она выполняет две связанные роли:

• ESB-шина — позволяет централизовать интеграции и вместо множества разрозненных связей между системами выстроить единый управляемый контур обмена.

• Платформа управления данными — в ней можно работать с витринами и хранилищами, решать задачи MDM и использовать Банк данных.

В описанных выше нестандартных сценариях в DATAREON Platform можно использовать программируемый коннектор — библиотеку на C#, которая реализует специальные интерфейсы DATAREON Platform и становится частью её общего контура.

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

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

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

В компании — многотысячный штат, инфраструктурные объекты по всей стране и сложная ИТ-инфраструктура, в которой используются 1С, веб-системы на MySQL, Kafka и Active Directory.

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

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

На первый взгляд задача выглядит как обычная интеграция файлового хранилища. Но именно здесь проявилась разница между типовым и нестандартным участком маршрута.
Стандартный коннектор «Файловый каталог» рассчитан на работу со структурированными данными вроде JSON и XML. В нашем сценарии требовалось работать с DOCX, XLSX, PDF, DWG и другими форматами.

На стороне NextCloud ситуация была другой. У системы есть REST/WebDAV API, поэтому для передачи файлов можно было использовать стандартный REST-коннектор платформы без его доработки.

Таким образом, нестандартной оказалась только одна часть маршрута — получение файлов из разнородных источников. Именно поэтому не потребовалось создавать самописную интеграцию целиком.

Для сбора файлов был разработан программируемый коннектор-коллектор. Он мониторит источники — локальные папки, сетевые шары и FTP-ресурсы — и собирает новые файлы.

Дальше в работу вступает стандартная логика платформы. Файл проходит обработку и классификацию, после чего передается в NextCloud через стандартный REST/WebDAV-коннектор.

В результате маршрут выглядит следующим образом:

источник → программируемый коннектор → обработка и классификация → стандартный коннектор → NextCloud.

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

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

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

Как файл проходит путь от папки до централизованного хранилища:

1. Сохранение. Документ сохраняется в привычном месте — локальной папке, сетевой шаре или другом подключенном источнике. 
2. Обнаружение. Система сама находит новый файл. Программируемый коннектор собирает его и передает в дальнейшую обработку.
3. Классификация. Файл можно определить по расширению, исходному пути и имени. При необходимости для классификации могут использоваться метаданные или заголовки документов.
4. Загрузка. Файл передается в нужное место в NextCloud через стандартный REST/WebDAV-коннектор.
5. Работа сотрудника не меняется. Интеграционный контур сам забирает документы из существующих источников и доставляет их в централизованное хранилище.

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

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

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

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

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

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

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

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

Программируемый коннектор позволяет точечно расширить возможности DATAREON Platform: нестандартную логику реализовать в отдельном компоненте, а управление интеграционным потоком, обработку и типовые соединения оставить на стороне платформы.

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

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