Привет, Хабр! Меня зовут Виктор Овчинников, я руковожу направлением интеграции и развитием платформы Digital Q.Integration в «Диасофт».

Недавно мы с коллегой Андреем Даниленко, ведущим разработчиком, провели вебинар, на котором рассказали про коннектор к 1С, и в комментариях попросили выложить более подробный технический разбор, что там происходит «под капотом» с точки зрения OData, и как выглядит этот сценарий на живых примерах. Здесь я делаю детальный текстовый анализ. Приглашаю всех присоединиться и при желании посмотреть запись вебинара: https://rutube.ru/video/9344562315beaaf94430d7c4de16ed74/?r=wd&p=KqHZJOTtxfoFzqSMgPuwYg

Развилка, на которой спотыкается почти любая интеграция с 1С

Разработчик 1С в команде интеграции – это отдельная роль, отдельная компетенция и отдельная строка в бюджете, которая появляется ровно в тот момент, когда 1С нужно с чем-то связать. Традиционный способ – зайти внутрь конфигурации и настроить там обмен данными: HTTP-сервисы, SOAP, промежуточные регистры сведений. Вариантов исполнения несколько, но суть одна. Логика живет внутри 1С, и вы напрямую работаете с ее объектами.

Дальше начинается та часть работы, о которой обычно не думают заранее. Конфигурация, в которую что-то дописали, перестает быть типовой, а значит, каждое официальное обновление платформы превращается в отдельный маленький проект: перенести изменения, свериться, протестировать заново. И это займет не часы, а недели. Таков естественный темп работы внутри 1С, а не поверх системы.

Когда мы проектировали коннектор для Digital Q.Integration, то отталкивались от простого принципа: интеграция не должна создавать пользователю новых проблем. Мы не хотим, чтобы для подключения к 1С клиенту приходилось нанимать разработчика 1С, лезть в конфигурацию и потом каждый год мучиться с обновлением. Отсюда и выбор фундамента: не доработка, а стандартный протокол OData.

Два пути – честно, по одной таблице

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

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

Что вообще такое OData

OData расшифровывается как Open Data Protocol – открытый протокол данных. У него интересная история. В 2007 году его придумали в Microsoft: к тому моменту в индустрии уже был ODBC – стандарт для единообразного доступа к базам данных, и создатели OData решили сделать то же самое, но для веба. Отсюда формулировка: «OData – это ODBC для веба».

Дальше произошло то, что случается не с каждым корпоративным протоколом: Microsoft передала его на стандартизацию в независимый консорциум OASIS, и в 2014 году OASIS утвердил версию OData 4.0 как официальный открытый стандарт. А в 2016 году был сделан еще один шаг – OData 4.0 опубликовали как стандарт ISO/IEC 20802. Это высшая форма международного признания, которую может получить протокол, и для нас это принципиально: мы строим коннектор не на проприетарном закрытом решении, а на фундаменте, которому можно доверять на годы вперед.

Технически «под капотом» нет ничего экзотического: обычный REST поверх HTTP, где GET – на чтение, POST – на создание, PATCH – на изменение, DELETE – на удаление. Данные отдаются в JSON (и опционально в Atom). Но REST сам по себе не говорит, как именно должны выглядеть запросы – а вот здесь OData и добавляет главную ценность: стандартизацию.

Три параметра стоят того, чтобы задержаться на них подробнее:

• Метаданные ($metadata). Любой OData-сервис умеет рассказать о себе сам: делаете запрос к специальному адресу – получаете машиночитаемое описание всех сущностей, их полей и связей (EDM-модель). Практический смысл: инструмент интеграции сам распознает структуру вашей 1С, не заставляя вас вручную вбивать список полей.

• Единая адресация. У каждой коллекции и записи предсказуемо устроенный URL.

• System Query Options. Унифицированный набор параметров, которые добавляются прямо в URL: $filter – фильтрация по условию (например, только контрагенты из Москвы); $select – выбор только нужных полей, чтобы не тащить всю карточку целиком; $expand – раскрытие связанных сущностей одним запросом вместо нескольких; $orderby – сортировка результата; $top/$skip – пагинация постраничных выборок; $count – получение количества записей.

Пример реального запроса к справочнику контрагентов: взять только наименование и ИНН, отфильтровать по городу Москва, отсортировать по наименованию, вернуть первые 100 записей. Все это выражается стандартными параметрами прямо в URL – разработчику 1С не нужно писать специальный метод под каждую такую выборку.

Когда OData включают в 1С, платформа берет объекты информационной базы – справочники, документы, регистры сведений и накопления – и автоматически публикует их как OData-сущности: справочник контрагентов становится коллекцией, каждый его элемент – записью этой коллекции. Ноль программирования: этот интерфейс генерирует сама платформа 1С, вам нужно только опубликовать базу на веб-сервере с включенным OData-интерфейсом. Авторизация обычно строится на HTTP Basic – под конкретным пользователем информационной базы, с его правами. К этому нюансу я еще вернусь в разделе про ограничения.

Честно о плюсах и минусах

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

Сильные стороны OData:

• Международный стандарт с предсказуемым поведением и долгой перспективой.

• Самодокументируемость – сервис описывает себя сам, инструмент интеграции читает структуру автоматически.

• Не нужны разработчик 1С и доработка конфигурации.

• Богатый набор запросов «из коробки» – фильтрация, выборка полей, сортировка, пагинация, раскрытие связей.

• Широкая поддержка индустрией.

Ограничения:

• OData слабо подходит для сложной бизнес-логики – он про данные, а не про серверные процедуры вроде «создать документ, провести его, пересчитать остатки».

• Производительность на очень больших выборках: протокол ориентирован на умеренный объем, тащить миллион записей одним махом – плохая идея, отсюда и важность параметров $top и $skip.

• Права и безопасность требуют продумывания – доступ идет под конкретным пользователем, и открыть «всё всем» здесь очень плохая идея.

• Не все объекты одинаково удобно публикуются, и в облачных инсталляциях есть частные нюансы.

Ключевая мысль, ради которой я все это перечислил: минусы OData лежат ровно в той плоскости, которую может и должна закрывать интеграционная платформа – сложная логика, обработка больших объемов через пагинацию, безопасное хранение учетных данных, удобный маппинг, обработка ошибок. Формула получается такая: надежный стандарт OData плюс слой удобства интеграционной платформы поверх него.

Как это устроено в Digital Q.Integration

Мы «обернули» сам протокол в отдельный компонент коннектора. Он дает автоматическое формирование запроса по заданным параметрам, доступ ко всем параметрам для тонкой настройки (ту самую связку $filter/$select/$expand, которую мы разобрали выше) – и ничего лишнего.

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

• добавить заголовок с константой метода – GetObjectData;

• добавить параметры выборки в тело запроса – тип, наименование объекта, условия;

• отправить запрос в топик коннектора – q1cconnector-start-command;

• получить результат в reply-топике.

Коннектор поддерживает несколько методов: help – получить справку по API коннектора (HTTP-описание протоколов и форматов); список объектов – перечень сущностей (справочников, документов, регистров), доступных в базе; метаданные объекта – атрибутный состав конкретной сущности, чтобы понимать, как строить выборку; получение данных – собственно запрос данных по категории и типу объекта, с полным арсеналом $filter/$select и т. д., с возможностью переключить формат ответа между JSON и XML одной опцией команды, без дополнительной реализации; получение данных со связанными объектами – аналог $expand: достает вложенный объект (например, валюту в договоре контрагента) одним запросом вместо двух-трех.

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

Кейс: интеграция Digital Q.CRM с 1С

Коннектор – это не витрина для вебинара, мы используем его внутри компании: на нем построена двусторонняя интеграция Digital Q.CRM с 1С. Через коннектор синхронизируются данные о контрагентах, юридических лицах, договоры со связанной информацией, лиды, продуктовый справочник и связи объектов – данные идут в обе стороны, из 1С в CRM и обратно. Дополнительно реализован запуск процедур – это уже тот случай сложной бизнес-логики, про который говорилось в разделе про ограничения OData: он закрывается не самим протоколом, а слоем платформы поверх него.

Итог

OData дает стандартный, самодокументируемый доступ к данным 1С без доработки конфигурации – это фундамент, на котором можно строить интеграцию без выделенного разработчика 1С в команде и без риска сломать механизм обмена при каждом обновлении платформы. Слабое место – сложная бизнес-логика и очень большие выборки – нивелируется не самим протоколом, а тем, что вы строите поверх него: обработкой ошибок, пагинацией, маппингом различий между инсталляциями, безопасным хранением учетных данных. У нас это Digital Q.Integration, но сам принцип работает в разных ситуациях, а не только в рамках одного конкретного продукта: не бороться с ограничениями протокола внутри самого протокола, а выносить эту сложность на уровень платформы, которая создавалась именно для интеграции, а не для учета.

А как у вас устроена интеграция с 1С? Тоже переходили на OData или предпочли доработку конфигурации под конкретные задачи? Особенно интересно знать, если вы сталкивались с тем самым автодописыванием атрибутов. И любопытно, насколько это распространено за пределами одной демобазы.