Что такое OData в 1С и что он даёт
OData (Open Data Protocol) — это протокол доступа к данным поверх HTTP. Платформа 1С:Предприятие поддерживает автоматический стандартный интерфейс OData, начиная с версии 8.3.5. Реализована спецификация OData версии 3.0, а ответы отдаются в формате Atom/XML или JSON — на выбор клиента.
Ключевое слово здесь — автоматический. Вам не нужно писать HTTP-сервисы вручную, описывать методы и вручную разбирать тело запроса. Платформа сама публикует справочники, документы и другие объекты конфигурации как REST-ресурсы: у каждого объекта появляется свой набор адресов для чтения и записи. Это снимает большой пласт рутинной серверной работы, которая обычно требуется при интеграции.
Что это даёт на практике. Внешняя система — CRM, интернет-магазин, мобильное приложение, сценарий на n8n или Make — может обращаться к данным 1С по обычным HTTP-запросам, получать JSON и отправлять изменения. Поддерживается полный CRUD: GET для чтения, POST для создания, PUT и PATCH для обновления, DELETE для удаления. Фактически это стандартный, документированный на уровне протокола способ связать 1С с остальным ИТ-ландшафтом.
OData — не единственный вариант интеграции 1С, и не всегда оптимальный: для сложной бизнес-логики часто удобнее собственные HTTP-сервисы, а для обмена между базами — планы обмена. Сравнение подходов мы разбираем в отдельном материале — методы интеграции 1С. Но когда нужен быстрый типовой доступ к данным по REST, OData обычно оказывается самым коротким путём.
Как опубликовать OData за час: пошагово
Публикация стандартного интерфейса OData состоит из двух смысловых частей: настройка публикации на веб-сервере и указание состава публикуемых объектов. Пропуск второй части — самая частая причина, по которой «всё настроил, а данных нет».
Шаг 1. Веб-сервер
OData работает только через веб-сервер. Нужен установленный и настроенный IIS или Apache, через который платформа опубликует базу. Без веб-сервера REST-интерфейс поднять нельзя — это обязательное условие.
Шаг 2. Публикация из Конфигуратора
В Конфигураторе откройте меню Администрирование → Публикация на веб-сервере. В открывшемся окне помимо обычных настроек публикации есть галка «Публиковать стандартный интерфейс OData» — её и нужно включить. После этого платформа сформирует публикацию, через которую станут доступны адреса OData.
Шаг 3. Состав публикуемых объектов
Важный нюанс: из коробки состав публикуемых объектов пуст. Даже при включённой галке ни один справочник или документ не будет отдаваться, пока вы явно не добавите его в состав. Настройка состава выполняется в режиме Предприятия — там указывается, какие именно объекты конфигурации выставляются наружу через OData.
Если после публикации запросы к объектам возвращают пусто или ошибку доступа, первым делом проверьте состав публикуемых объектов в режиме Предприятия. По умолчанию он пустой, и это штатное поведение, а не сбой.
После этих шагов базовый адрес интерфейса выглядит так: .../odata/standard.odata. Относительно него строятся все обращения к конкретным объектам, которые мы разберём дальше.
Чтение данных: GET, $filter, $select
Чтение — самый простой сценарий. Каждому объекту конфигурации соответствует своя коллекция под базовым адресом .../odata/standard.odata. Имена коллекций строятся по типу объекта: справочники начинаются с префикса Catalog_, документы — с Document_.
Например, чтобы получить элементы справочника «Товары», выполняется запрос:
- GET .../odata/standard.odata/Catalog_Товары
Документы читаются аналогично, только с префиксом Document_ и соответствующим именем объекта. В ответ приходит коллекция записей в выбранном формате — XML или JSON.
Опции запроса
OData в 1С поддерживает стандартные системные опции протокола, которые передаются в строке запроса. Основные, которые понадобятся почти всегда:
- $select — вернуть только нужные поля, а не всю запись целиком. Уменьшает объём ответа и нагрузку.
- $filter — отобрать записи по условию, чтобы не тянуть весь справочник и не фильтровать на стороне клиента.
- $top — ограничить количество возвращаемых записей.
Отдельно стоит отметить фильтрацию по табличным частям. OData позволяет фильтровать по содержимому табличной части через функцию any() — например, конструкцией вида Товары/any(...) можно отобрать документы, у которых в табличной части «Товары» есть строка, удовлетворяющая условию. Это удобно, когда нужно найти документы по позициям внутри них, а не по реквизитам шапки.
Комбинируя $select и $filter, вы забираете из базы ровно то, что нужно, одним запросом. Для интеграционных сценариев это важно: чем аккуратнее запрос, тем меньше данных ходит по сети и тем предсказуемее нагрузка на сервер 1С.
А это может работать само в вашем бизнесе?
Запишитесь на бесплатный разбор процесса (30 минут). Разберём один сценарий и честно скажем, окупается ли автоматизация.
Получить бесплатный аудитЗапись: создание документов и справочников (POST/PATCH)
OData в 1С — это не только чтение. Протокол поддерживает полный набор операций записи: POST, PUT, PATCH и DELETE. Это позволяет внешней системе не просто выгружать данные, но и создавать и изменять объекты в базе.
Создание
Новый объект создаётся запросом POST на соответствующую коллекцию. Например, чтобы завести новый элемент или документ, вы отправляете POST на коллекцию этого объекта (Catalog_... для справочника, Document_... для документа), передавая в теле запроса поля новой записи. Платформа создаёт объект и возвращает его представление, включая присвоенные системой идентификаторы.
Обновление
Для изменения существующего объекта применяются PATCH (частичное обновление — меняются только переданные поля) или PUT (полная замена). PATCH обычно предпочтительнее: он безопаснее в том смысле, что не затрагивает поля, которые вы не передавали.
Удаление
Удаление объекта выполняется методом DELETE по адресу конкретной записи. Здесь стоит быть особенно осторожным в интеграциях: удаление данных учёта — операция ответственная, и в большинстве сценариев вместо физического удаления работают с пометкой на удаление.
Один принципиальный момент про документы разберём отдельно в разделе о подводных камнях: запись документа через OData создаёт объект, но это не то же самое, что проведение. Если по вашему сценарию из записанного документа должны сформироваться движения по регистрам, одной записи через OData недостаточно.
Связка «запись через OData плюс уведомление пользователю» хорошо ложится на автоматизацию: например, при создании документа внешняя система может отправить сообщение в мессенджер. Такой сценарий мы показываем в материале про Telegram-бота для 1С.
Права доступа и безопасность
OData не вводит отдельную «свою» модель прав — доступ регулируется правами пользователя 1С, под которым выполняется запрос. Это важное и удобное свойство: те же роли и ограничения, что работают в обычном сеансе, действуют и через REST. Если у пользователя нет права на чтение или изменение объекта, через OData он его тоже не получит.
Из этого следуют несколько практических правил безопасности.
- Публикуйте только нужные объекты. Состав публикуемых объектов — это ваш периметр. Чем меньше выставлено наружу, тем меньше поверхность для ошибок и злоупотреблений. Не добавляйте в состав то, что интеграции реально не требуется.
- Заводите отдельного пользователя для интеграции. Отдельная учётная запись с минимально необходимым набором прав позволяет точно ограничить, что именно может делать внешняя система, и отделить её действия от действий живых пользователей.
- Помните, что права работают в обе стороны. Через OData доступны те же операции записи и удаления, что и права пользователя в системе. Избыточные права интеграционной учётки — это риск не только чтения лишнего, но и нежелательной модификации данных.
Отдельно стоит подумать про транспорт: раз OData ходит через веб-сервер по HTTP, имеет смысл закрывать доступ по HTTPS и ограничивать, откуда можно обращаться к публикации. Конкретная конфигурация здесь зависит от вашего веб-сервера и сетевого окружения, поэтому детали настройки лучше согласовывать с администратором инфраструктуры.
Подводные камни (пустой состав, проведение, производительность)
OData снимает много рутины, но есть несколько мест, где легко споткнуться. Разберём самые частые.
Пустой состав публикуемых объектов
Повторим, потому что это грабли номер один: из коробки состав публикуемых объектов пуст. Включённая галка публикации сама по себе не открывает ни одного объекта. Если запросы возвращают пусто, а конфигурация вроде бы настроена — почти наверняка дело в том, что нужный объект не добавлен в состав в режиме Предприятия.
Запись документа не равна проведению
Это ключевой концептуальный момент. Когда вы создаёте или изменяете документ через OData, платформа записывает объект, но проведение — это отдельная логика. Движения по регистрам, влияние на учёт и остатки происходят при проведении, а не при простой записи. Поэтому если бизнес-сценарий предполагает, что документ должен быть проведён, нельзя рассчитывать, что запись через OData сделает это автоматически. Проведение придётся обеспечивать отдельно — и это стоит заложить в архитектуру интеграции с самого начала.
Производительность
REST-удобство соблазняет тянуть данные широко и часто. Несколько ориентиров, чтобы не создавать лишнюю нагрузку на сервер 1С:
- Запрашивайте только нужные поля через $select — не забирайте запись целиком, если нужны два реквизита.
- Ограничивайте выборки через $filter и $top, а не фильтруйте большие объёмы на стороне клиента.
- Аккуратно относитесь к фильтрам по табличным частям через any() — они мощные, но по нагрузке тяжелее, чем фильтр по реквизитам шапки.
Точное поведение под нагрузкой зависит от объёма данных, конфигурации и оборудования, поэтому реальные сценарии стоит проверять на тестовой базе, приближенной к боевой. Общий принцип простой: чем точнее запрос, тем меньше данных ходит по сети и тем стабильнее ведёт себя интеграция.