Как прочитать присоединенные файлы номенклатуры через REST OData в 1С?

← На главную

При интеграции 1С с интернет-магазинами или внешними витринами данных часто возникает задача получения изображений или документов, прикрепленных к объектам (например, к справочнику Номенклатура). Использование стандартного интерфейса OData кажется логичным решением, однако разработчики часто сталкиваются с тем, что в самом справочнике присоединенных файлов данных нет — там хранятся лишь метаданные. Разберем по шагам, где на самом деле лежат файлы и как правильно составить запрос для их извлечения.

Выясняем архитектуру хранения файлов

В современных конфигурациях 1С, построенных на базе Библиотеки стандартных подсистем (БСП), файлы физически не хранятся внутри справочника НоменклатураПрисоединенныеФайлы. Это сделано для оптимизации производительности базы данных. Рассмотрим ситуацию: когда вы обращаетесь к Catalog_НоменклатураПрисоединенныеФайлы, вы видите поля ФайлХранилище_Base64Data или ТекстХранилище_Base64Data. Зачастую они либо пусты, либо содержат лишь короткий XML-заголовок.

Проанализируем поле ТипХраненияФайла. В 1С существует два основных варианта хранения контента:

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

Если в вашей конфигурации выбран первый вариант, то данные следует искать в регистре сведений ДвоичныеДанныеФайлов. Если же файлы хранятся в томах, получить их содержимое напрямую через стандартный OData невозможно — интерфейс OData умеет транслировать в Base64 только то, что физически находится в таблицах SQL.

Запрос к метаданным присоединенного файла

Прежде чем получить содержимое, нам нужно узнать уникальный идентификатор (GUID) файла. Выполним типичный запрос к справочнику присоединенных файлов номенклатуры:


GET /odata/standard.odata/Catalog_НоменклатураПрисоединенныеФайлы?$format=json&$filter=ВладелецФайла_Key eq guid'ваш-guid-номенклатуры'

В ответе мы получим объект, где ключевым полем для нас будет Ref_Key. Это идентификатор записи в справочнике присоединенных файлов. Именно его мы будем использовать для поиска в регистре двоичных данных.

Получение двоичных данных через регистр

Теперь перейдем к самому важному этапу. Чтобы извлечь файл, необходимо обратиться к сущности InformationRegister_ДвоичныеДанныеФайлов. Особенность этого регистра заключается в том, что он использует составной ключ. Посмотрим, как правильно сформировать URL для запроса:


GET /odata/standard.odata/InformationRegister_ДвоичныеДанныеФайлов(Файл=guid'19e6e7ca-f3be-11e8-83b2-14dae924f847', Файл_Type='StandardODATA.Catalog_НоменклатураПрисоединенныеФайлы')?$format=json

Разберем параметры этого запроса подробнее:

Файл: здесь мы указываем Ref_Key, который получили на предыдущем шаге из справочника.
Файл_Type: это обязательный параметр для составных типов данных в OData. Мы должны явно указать, к какому справочнику относится наш идентификатор. Для номенклатуры это обычно StandardODATA.Catalog_НоменклатураПрисоединенныеФайлы.

Если запрос составлен верно, в теле ответа вы увидите поле ДвоичныеДанныеФайла_Base64Data. Это и есть искомый файл в кодировке Base64.

Обработка полученной Base64 строки

При работе с полученными данными важно обратить внимание на один технический нюанс. Платформа 1С при сериализации двоичных данных в JSON может добавлять символы переноса строк \r\n для форматирования длинного текста. Рассмотрим пример:


{
  "ДвоичныеДанныеФайла_Base64Data": "iVBORw0KGgoAAAANSUhEUgAA...\r\n...base64data..."
}

Перед тем как декодировать эту строку в картинку или файл, обязательно удалите все символы переноса строк. В противном случае стандартные библиотеки декодирования во многих языках программирования (PHP, Python, JS) могут выдать ошибку или создать поврежденный файл.

Разбор типичных ошибок

Выясним причины, по которым запрос может возвращать ошибки 404 или "Сущность не найдена" (Code 8):

Настройка автоматического интерфейса: Проверьте в конфигураторе или в специальной обработке «Настройка автоматического интерфейса OData», включен ли регистр ДвоичныеДанныеФайлов в состав публикуемых объектов. Если объект не добавлен в состав, OData его «не видит».
Права доступа: Учетная запись, под которой выполняется запрос, должна иметь права на «Чтение» регистра ДвоичныеДанныеФайлов. Наличия прав только на справочник присоединенных файлов недостаточно.
Синтаксис GUID: В некоторых версиях платформы 1С критично наличие префикса guid перед кавычками и использование одинарных кавычек внутри скобок ключа.

Ограничения и рекомендации

Проанализируем производительность данного метода. Передача файлов через OData в формате Base64 создает значительную нагрузку на сервер 1С. Поскольку Base64 увеличивает объем данных примерно на 33%, а платформа должна сформировать весь JSON-ответ в памяти перед отправкой, не рекомендуется использовать этот метод для файлов размером более 10–15 МБ.

Если ваша задача подразумевает массовую выгрузку тяжелых изображений, лучше рассмотреть вариант хранения файлов в томах на диске и отдачу их через прямой HTTP-ссылки или создание собственного легкого HTTP-сервиса на стороне 1С, который будет транслировать поток данных без избыточной упаковки в JSON.

В итоге, алгоритм действий выглядит так: получаем ссылку из справочника -> запрашиваем данные из регистра сведений с указанием типа -> очищаем Base64 от мусорных символов -> сохраняем результат.