Часто перед разработчиками и интеграторами встает задача: как организовать обмен данными с 1С так, чтобы это было «типовым» решением, не требовало снятия конфигурации с поддержки и основывалось на инструментах Библиотеки стандартных подсистем (БСП). В этом материале мы проанализируем, почему попытки использовать БСП как универсальный API-интерфейс часто приводят в тупик, и какие существуют профессиональные способы решения данной задачи.
Прежде всего, давайте разберем саму суть БСП. Многие ошибочно полагают, что она представляет собой набор готовых методов для «выдачи» любых данных из базы во внешние системы. На практике всё иначе: БСП — это фреймворк для внутренних подсистем типовых конфигураций 1С. Она обеспечивает работу с пользователями, обновление конфигурации, версионирование объектов, дополнительные реквизиты и внутренний обмен данными 1С-1С.
Внутри БСП существуют механизмы для обмена данными, такие как Синхронизация данных, но они разработаны для взаимодействия двух конфигураций 1С между собой (через КД 2.x или КД 3.0). Эти механизмы ожидают специфический формат обмена, правила конвертации и настройку узлов. Использовать их для стороннего ПО — это крайне трудоемкая задача, требующая эмуляции логики обмена 1С, что практически невозможно реализовать «без доработок».
Если ваша задача — подключиться к 1С из стороннего ПО и просто получить данные справочника, помните: готового сервиса, который можно было бы включить галочкой в БСП и получить JSON-ответ с данными, не существует. Любая интеграция требует либо открытия стандартного интерфейса платформы, либо написания собственной логики отдачи данных.
Разберем способы, которые действительно позволяют решить задачу получения данных без нарушения целостности конфигурации.
Это самый «типовой» и быстрый путь. Платформа 1С обладает встроенным функционалом OData, который позволяет внешним системам обращаться к данным напрямую через HTTP-запросы.
OData.GET-запрос на адрес http://server/base/odata/standard.odata/Catalog_ВашСправочник.Это решение является наиболее близким к тому, что называют «типовым способом без доработок». Если руководство ставит задачу минимизировать внедрения — OData является единственным стандартизированным вариантом.
Если OData не подходит (например, нужно вернуть данные в специфическом формате или выполнить сложный запрос), единственным профессиональным выходом является создание HTTP-сервиса в Расширении конфигурации.
Важно понимать: использование расширений не является «доработкой» в привычном понимании, так как оно не меняет основной код конфигурации. Вы можете создавать полноценные API, сохраняя конфигурацию на полной поддержке.
Пример простейшей структуры модуля HTTP-сервиса:
Функция ПолучитьСправочникОбработкаGET(Запрос)
// Получаем данные из справочника
Выборка = Справочники.ГруппыПользователей.Выбрать();
Результат = Новый Массив;
Пока Выборка.Следующий() Цикл
Результат.Добавить(Новый Структура("Ссылка, Наименование", Выборка.Ссылка, Выборка.Наименование));
КонецЦикла;
Ответ = Новый HTTPСервисОтвет(200);
Ответ.УстановитьТелоИзСтроки(СериализаторXDTO.ЗаписатьJSON(Результат));
Возврат Ответ;
КонецФункции
После создания такого сервиса в расширении, вы публикуете его на веб-сервере и обращаетесь к нему из внешнего ПО как к любому другому API.
Проанализировав ситуацию, можно сделать однозначные выводы:
OData. Это штатный механизм платформы 1С.Расширения конфигурации. Это современный стандарт разработки, который позволяет расширять функционал 1С, сохраняя возможность обновления конфигурации без проблем.Таким образом, мы выяснили, что для успешной интеграции необходимо либо настроить OData, либо создать собственное расширение с HTTP-сервисом. Других профессиональных способов, соответствующих стандартам 1С, на сегодняшний день не существует.