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

← На главную

При интеграции сторонних приложений с системами на базе 1С разработчики часто сталкиваются с необходимостью передавать в базу документы вместе со сканами или текстовыми файлами. Рассмотрим типичную проблему: при попытке загрузить присоединенный файл к документу (например, к документу «Счет от поставщика») через стандартный интерфейс OData сервер возвращает ошибку 500, либо файл создается, но его невозможно открыть. Проанализируем ситуацию и разберем по шагам, почему это происходит и как правильно реализовать загрузку.

Суть проблемы при использовании OData

Посмотрим на классический пример. Разработчик отправляет POST-запрос к сущности Catalog_СчетНаОплатуПоставщикаПрисоединенныеФайлы. В теле JSON передаются реквизиты файла, включая его бинарное содержимое в формате Base64:


{
    "ДатаСоздания": "2023-10-10T12:00:00",
    "ТипХраненияФайла": "ВИнформационнойБазе",
    "Description": "file.txt",
    "Расширение": "txt",
    "ВладелецФайла_Key": "87f9c2d1-...",
    "ФайлХранилище_Type": "application/octet-stream",
    "ФайлХранилище_Base64Data": "SGVsbG8gV29ybGQ="
}

В этом случае платформа может вернуть Internal Server Error (Ошибка 500) без подробностей в технологическом журнале. Если убрать параметры ФайлХранилище_Type и ФайлХранилище_Base64Data, запись в справочнике успешно создается, но сам файл остается пустым.

Даже если удается подобрать MIME-тип и добиться успешного ответа от сервера (запись появляется в списке присоединенных файлов, а при GET-запросе поле ФайлХранилище_Base64Data выглядит заполненным), при попытке открыть файл в интерфейсе 1С появится сообщение: «Не удается открыть присоединенный файл, данные файла недоступны». В регистре СведенияОФайлах появится запись с нулевым размером.

Выясним причину: почему стандартный OData не работает с файлами

Чтобы понять причину такого поведения, проанализируем архитектуру современных конфигураций 1С, построенных на базе Библиотеки стандартных подсистем (БСП):

Прямая запись без бизнес-логики: Стандартный интерфейс OData в 1С осуществляет запись в таблицы базы данных на низком уровне. Он полностью игнорирует прикладную логику БСП. Запись через OData пропускает обязательные служебные обработчики, которые должны вычислять размер файла, рассчитывать его контрольную сумму (MD5/SHA-256) и корректно заполнять регистр СведенияОФайлах. В итоге мы получаем «битую» карточку файла.
Назначение реквизита ФайлХранилище: В современных типовых конфигурациях бинарные данные физически больше не хранятся в реквизите ФайлХранилище справочника ...ПрисоединенныеФайлы. Этот реквизит сейчас используется преимущественно в механизмах обмена данными (в планах обмена). Сам справочник теперь служит исключительно для хранения карточки файла (его метаданных).
Реальное место хранения файлов: Механизмы БСП предусматривают два варианта физического размещения файлов. Если установлен тип хранения «В информационной базе», бинарный код помещается в независимый регистр сведений ДвоичныеДанныеФайлов. Если выбран тип «В томах на диске», файлы уходят в сетевой каталог сервера. OData физически не умеет сохранять файлы в сетевые директории томов.

Рабочие способы решения задачи

Разберем проверенные способы, как обойти эти ограничения и успешно загрузить файл в 1С.

Способ 1. Многошаговая загрузка через OData (Только для хранения в базе)

Если в настройках 1С строго задано хранение файлов в информационной базе (а не в томах на диске), вы можете использовать стандартный OData, но процесс нужно разбить на два этапа:

Создание метаданных: Первым POST-запросом создайте элемент в справочнике ...ПрисоединенныеФайлы (передайте наименование, владельца, расширение, но без бинарных данных). Получите GUID созданной карточки.
Запись бинарных данных: Вторым запросом отправьте бинарные данные (Base64) напрямую в регистр сведений ДвоичныеДанныеФайлов, связав их с полученным GUID карточки файла. При этом вам придется самостоятельно заботиться о заполнении связанных служебных регистров (например, сведений о размере).

Способ 2. Создание собственного HTTP-сервиса (Рекомендуемый подход)

Так как OData идет в обход бизнес-логики, наиболее надежной и правильной практикой является разработка собственного HTTP-сервиса внутри конфигурации 1С. Рассмотрим этот подход:

Создайте HTTP-сервис в Конфигураторе, который будет принимать POST-запросы.
В теле запроса передавайте всю необходимую информацию: GUID документа-владельца, имя файла и строку Base64.
В обработчике сервиса преобразуйте Base64 обратно в двоичные данные.
Вызовите штатную экспортную процедуру БСП РаботаСФайлами.ДобавитьФайл() (или её аналоги в зависимости от версии БСП) и передайте в неё полученные данные.

Этот метод автоматически решит все проблемы: БСП сама рассчитает размер, вычислит контрольную сумму, создаст записи в регистрах СведенияОФайлах и ДвоичныеДанныеФайлов, а если в базе включено хранение в томах — корректно сохранит файл на жестком диске сервера.

Способ 3. Использование Web-сервисов (SOAP)

По аналогии с HTTP-сервисом, вы можете разработать классический SOAP Web-сервис. Он также будет принимать сериализованные бинарные данные в качестве параметра и маршрутизировать их через стандартный программный интерфейс БСП. Выбор между HTTP и Web-сервисом зависит исключительно от архитектурных предпочтений команды, реализующей интеграцию.

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