Чтобы объекты расширения конфигурации стали доступны через стандартный интерфейс OData 1С, их нужно явно включить в состав интерфейса. Платформа делает это методом УстановитьСоставСтандартногоИнтерфейсаOData(), а в конфигурациях на БСП обычно используют обработку «Настройка стандартного интерфейса OData». Проблема в том, что эта обработка строит список объектов по своей модели и объекты расширений может в него не включать. Решение — либо добавить объекты в состав интерфейса напрямую, либо заимствовать обработку в расширение и поправить её модель.
Ниже — оба пути, публикация и проверка запросом с фильтром.
Что умеет стандартный интерфейс OData
OData — это REST-интерфейс, который платформа генерирует автоматически по метаданным. Доступны справочники, документы, журналы документов, константы, планы видов характеристик, планы счетов, планы видов расчёта, планы обмена, все виды регистров, бизнес-процессы и задачи.
| Операция | HTTP-метод |
|---|---|
| Получение списка или объекта | GET |
| Создание | POST |
| Изменение | PATCH или PUT |
| Удаление | DELETE |
Аутентификация — Basic: заголовок Authorization с логином и паролем пользователя 1С. Пользователь должен иметь права на выгружаемые объекты. Для интеграций я завожу отдельного пользователя с узкой ролью.
Главное преимущество перед своими HTTP-сервисами — ничего не нужно программировать для типовых операций чтения и записи. Минус — интерфейс жёстко повторяет структуру метаданных, и всё, что не вписывается в CRUD, всё равно потребует HTTP-сервиса или своего API.
Путь 1. Платформенный метод состава интерфейса
Самый прямой способ — получить текущий состав и добавить в него объекты расширения:
// Добавляет объекты расширения в состав стандартного интерфейса OData.
// Выполнять от имени пользователя с административными правами.
Процедура ДобавитьОбъектыРасширенияВOData() Экспорт
Состав = Новый Массив;
Для Каждого ОбъектМетаданных Из ПолучитьСоставСтандартногоИнтерфейсаOData() Цикл
Состав.Добавить(ОбъектМетаданных);
КонецЦикла;
Добавляемые = Новый Массив;
Добавляемые.Добавить(Метаданные.РегистрыСведений.СобытияДоступа);
Добавляемые.Добавить(Метаданные.Справочники.КартыДоступа);
Для Каждого ОбъектМетаданных Из Добавляемые Цикл
Если Состав.Найти(ОбъектМетаданных) = Неопределено Тогда
Состав.Добавить(ОбъектМетаданных);
КонецЕсли;
КонецЦикла;
УстановитьСоставСтандартногоИнтерфейсаOData(Состав);
КонецПроцедурыУчтите связанные объекты: если реквизит регистра ссылается на справочник, этот справочник тоже стоит включить в состав, иначе внешняя система получит идентификатор, который не сможет разыменовать. Обработка БСП добавляет связанные объекты автоматически, при ручном способе это ваша ответственность.
Этот путь хорош, когда объектов немного и состав меняется редко. Минус — администратор, открыв обработку БСП, не увидит эти объекты в списке и может случайно перезаписать состав без них.
Путь 2. Доработка обработки БСП в расширении
Если хочется, чтобы объекты расширения показывались в штатной обработке настройки OData и включались галочкой, обработку дорабатывают через расширение.
- Заимствуйте в расширение обработку «Настройка стандартного интерфейса OData».
- Найдите в её модуле менеджера функцию, которая заполняет модель данных для интерфейса (в версиях БСП, которые я встречал, это
ЗаполнитьМодельДанныхПредоставляемыхДляСтандартногоИнтерфейсаOData), и функцию-фильтр, которая решает, включать ли объект в модель (например, проверка разделённости объекта). - Заимствуйте функцию-фильтр и оберните её аннотацией
&Вокруг, чтобы для объектов расширения возвращать нужный признак.
Пример обёртки. Сигнатура должна в точности совпадать с исходной функцией вашей версии БСП — посмотрите её перед заимствованием:
&Вокруг("ЭтоРазделенныйОбъект")
Функция ИнтеграцияOData_ЭтоРазделенныйОбъект(ОбъектМетаданных)
// Объекты нашего расширения всегда включаем в модель интерфейса
Если ТипЗнч(ОбъектМетаданных) = Тип("ОбъектМетаданных")
И ОбъектМетаданных.РасширениеКонфигурации() <> Неопределено Тогда
Возврат Истина;
КонецЕсли;
Возврат ПродолжитьВызов(ОбъектМетаданных);
КонецФункцииПроверку через РасширениеКонфигурации() я предпочитаю проверке по префиксу в имени: она не сломается, если кто-то назовёт объект не по правилам. Если в базе несколько расширений, а публиковать нужно только одно, сравните РасширениеКонфигурации().Имя с именем своего расширения.
&Вокруг с ПродолжитьВызов лучше, чем &Вместо: при обновлении БСП исходная логика продолжит работать, а ваша вставка затронет только объекты расширения.
После этого объекты расширения появятся в списке обработки. Отметьте их, и обработка покажет связанные объекты, которые тоже нужно включить.
Публикация и проверка
- В публикации базы на веб-сервере включите «Публиковать стандартный интерфейс OData».
- Проверьте список ресурсов:
http://сервер/ИмяПубликации/odata/standard.odata/и метаданные.../standard.odata/$metadata. - Сделайте запрос к объекту расширения:
curl -u integration:Secret123 \
"http://srv/zup/odata/standard.odata/InformationRegister_СобытияДоступа?\$format=json&\$filter=КартаДоступа%20eq%20'121236'"Имя ресурса — префикс вида объекта (Catalog_, Document_, InformationRegister_ и т. д.) плюс имя объекта в метаданных. Строковые значения в $filter — в одинарных кавычках, пробелы в URL кодируются.
Если ответ — 404 по ресурсу, объект не включён в состав. Если 401 или 403 — проблема с пользователем или правами. Настройку публикации, HTTPS и доступа извне делаю в рамках услуги веб-доступ к 1С.
OData или свой HTTP-сервис
Когда объекты в расширении, всегда есть альтернатива — написать в том же расширении HTTP-сервис. Как выбираю я:
| Критерий | OData | Свой HTTP-сервис |
|---|---|---|
| Скорость запуска | Минуты: включить объект в состав | Часы или дни: описать шаблоны и обработчики |
| Формат данных | Повторяет метаданные 1С, имена на русском | Любой, удобный внешней системе |
| Бизнес-логика | Только CRUD по объектам | Любая: проверки, расчёты, пакетные операции |
| Права | Права пользователя на объекты | Права плюс собственные проверки в коде |
| Контракт при доработках | Меняется вместе с метаданными | Стабилен, пока вы его не поменяете |
OData хорош для чтения справочников и регистров аналитическими системами, BI, отчётами на стороне. Для записи данных с проверками и для внешних партнёров я предпочитаю собственный HTTP-сервис: внешняя система не должна зависеть от того, как вы переименовали реквизит в очередной доработке.
Типичные ошибки
- Объект добавлен, но связанные справочники нет — внешняя система получает «висящие» идентификаторы.
- Состав перезаписан обработкой БСП после ручного добавления — объекты расширения пропали.
&Вместовместо&Вокруг— после обновления БСП модель перестаёт заполняться корректно.- Расширение в безопасном режиме или отключено для части пользователей — объект виден не всем.
- Интеграционный пользователь с полными правами — лишний риск; давайте только нужные роли.
OData даёт готовый REST за минуты, но для объектов расширения его нужно явно «пригласить» в состав интерфейса.
Объекты для интеграции я обычно сразу выношу в расширение конфигурации, чтобы не трогать типовую часть и спокойно обновляться.
Итог
- Объекты расширения нужно явно включить в состав стандартного интерфейса OData.
- Быстрый путь —
УстановитьСоставСтандартногоИнтерфейсаOData()с добавлением своих объектов и связанных справочников. - Штатный путь — заимствовать обработку БСП и обернуть её фильтр модели через
&Вокруг, определяя объекты расширения поРасширениеКонфигурации(). - Проверяйте результат запросом к
/odata/standard.odata/с$format=jsonи$filter.
