1с odata сущность не найдена

Обновлено: 05.07.2024

oData одним из последних появился в инструментах интеграции поддерживаемых платформой 1С. В данной статье хотел бы показать пример его использования. О преимуществах и недостатках oData предлагаю поделиться в комментариях исходя из реального опыта использования.

Цель публикации. Дать разработчикам простой инструментарий обмена между идентичными конфигурациями.

Что делает обработка простым языком.

Итак, задача в которой я решил использовать REST-сервис (oData) был обмен документами идентичных конфигураций. В решении есть обработка реквизитов присущих только документам, с которыми мне пришлось работать, но большая часть реквизитов заполняется по универсальным правилам.

Обмен состоит из двух частей:

Часть. Получение с сервера из регистра сведений документов, запись их на клиенте, очистка записей регистра сведений сервера.
Часть. Отправка с клиента на сервер документов. Регистр присутствует и здесь, но т.к. oData никак не участвует в его обработке, то описывать его не буду.

Резюмируя, методы работы с oData в нашем решении, мы рассмотрим:

А) Получение данных из регистра по отбору измерений.

Б) Обработка полученного JSON и запись документов.

В) Удаление записи регистра сведений по ключевым измерениям.

Г) Формирование тела запроса для записи документов на сервере.

Д) Перезапись документа, если он уже есть на сервере.

Что делает обработка (ближе к коду):

Небольшая вводная перед кодом.

Про установку Интернет-сервера (Apache, или IIS) есть много статей. Публикация базы делается через одну кнопку в меню Администрирование:

И установкой флага «Публиковать стандартный интерфейс OData»:

Если у вас не пионерская платформа по использованию интерфейса oData, то нужно включить доступ на объекты базы-сервера.

Так же можно просмотреть объекты, на которые открыт доступ:

Получение данных

Первая процедура «Обработать Регистр» (Листинг 1.) получает уникальные идентификаторы нужных нам объектов.

В Адресе запроса регистр пишем, как он называется в конфигураторе, например «ЦеныВалют» после слова «InformationRegister_», это будет выглядеть так: InformationRegister_ЦеныВалют. Обращение на чтение регистра происходит с помощью Get-запроса, поэтому все передается в параметрах и может быть записано одной строкой в браузере. В частности, наш запрос можно записать строкой:

localhost/server_odata/odata/standard.odata/InformationRegister_<Ваш регистр>?$filter=<Измерение регистра> eq '<Значение>'&$format=json

В данном примере мы используем фильтр по измерению регистра, оно записывается как в конфигураторе, со значением, указанном в апострофах, это такие запятые 'сверху'. Если тип измерения – перечисление, то записываем его как в конфигураторе. Например, «filter=СтавкаНДС eq 'БезНДС'». Слово «eq» обозначает равенство.

Далее преобразуем его в массив соответствий и обращением к нужному нам измерению (Объект), получаем УИД объекта, который необходимо получить.

Далее идет процедура «ПолучитьИОбработатьСсылку(СсылкаУИД)», которая с помощью УИД получает все данные нашего объекта бит_ЗаявкаНаРасходованиеСредств. В данном случае мы используем канонический запрос с использованием GUID, который получает конкретный объект. Запрос такой:

Обращаю ваше внимание на то, что в процедуре «Обработать Регистр» мы использовали функцию «ПрочитатьJSON» без параметров «"ФункцияВостановленияЧтения",ЭтаФорма,,Реквизиты». Связано это с тем, что в первой функции мы не преобразовывали данные из JSON и получали УИД в виде строки. В процедуре «ПолучитьИОбработатьСсылку(СсылкаУИД)» мы уже работаем с ссылкой.

Далее идет создание и заполнение документа. Для удобства преобразовал полученное из JSON соответствие в структуру, предварительно удалив из него строку с ключом "odata.metadata". Код процедуры преобразования «ПолучитьСтруктуруИзСоответствия» взял из Статьи не меняя.

Отправка данных

Для отправки данных используется процедура «ЗаписатьСписаниеНаСервере». (Листинг 2)

Суть процедуры состоит в том, что мы пытаемся создать новый документ на сервере, если этого не удается, пытаемся перезаписать имеющийся.

Для начала нам нужно подготовить данные, которые мы будем передавать на сервер. Формат тот же JSON. Процедура формирования данных для отправки обратно их получению. Сначала создаем соответствие из необходимых реквизитов с нужными значениями. Откуда же взять имена ключей соответствия? Да оттуда же. Из прямого обращения к oData, например из строки браузера. Хоть мы и условились, что базы идентичны, все-таки, рекомендую получать структуру данных из базы сервера. Запрос нам уже знаком: «localhost/server_odata/odata/standard.odata/Document_СписаниеСРасчетногоСчета(guid'<СсылкаУИД>')?$format=application/json» Подставляем какой-нибудь из имеющихся УИДов базы сервера и видим имена. Секрет в том, что большая часть из них совпадают с именами реквизитов в конфигураторе. То есть, придумывать ключи и прописывать их в большинстве случаев не предется. В этом большой плюс и универсальность данных механизмов. Все описанные процедуры могут быть использованы для других объектов базы с небольшими изменениями. Но изменения все же есть.

Рассмотрим процедуру «ПолучитьСоответсвиеДокумента».

Первое, что опишем «в рукопашную» - это реквизит «Контрагент». Дело в том, что контрагент имеет составной тип, поэтому необходимо передавать информацию о типе. Так как в нашем случае Контрагент всегда имеет тип контрагент, то тип его «захардкодим»:

, значение этого параметра можно взять все из того же результата запроса к элементу справочника базы сервера.

Само значение контрагента так же передается УИДом, но в ключе не пишем префикс «_Key».

Заполнение стандартных реквизитов происходит в функции «СоздатьОписанияОбязательнихРеквизитовДокумента» взятой из Статьи без изменений.

Далее создаются три списка значений для дальнейшей обработки:

СписокСсылок. Из него будут обрабатываться реквизиты ссылочного типа.
СписокПеречисленией. Из него будут обрабатываться перечисления.
СписокИсключений. Те реквизиты, которые не будут обрабатываться.

Примечание. Эти списки заполняются как для реквизитов документа, так и для реквизитов табличных частей.

Далее в процедуре «СоздатьОписанияДополнительнихРеквизитов» мы заполняем все оставшиеся реквизиты документа.

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

Процедура «СоздатьОписанияТабличныхЧастей» чуть посложнее, тем, что надо обходить табличные части по отдельности и не забывать про номер строки, но принцип тот же.

Примечание. Метод Записать (Put) отрабатывает, но он не записывает реквизиты, которые были пустыми. Узнал об этом опытным путем. На сервере ставил точки останова в процедурах ПриЗаписи и ПередЗаписью. В процедуре ПередЗаписью данные были, а в процедуре ПриЗаписи – уже нет.

Обращаю внимание на строку заголовка «Заголовки.Вставить("1C_OData-DataLoadMode", Истина);». Это строка переводит флаг «ОбменДанными.Загрузка» в значение «Истина»

Вместо заключения. В чем преимущества oData. В чем недостатки (мое незнание возможностей, или ограничения сервиса)

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

P.S. В качестве примера прикрепил обработку скачивания заявки с сервера и создания документа на клиенте по УИДу. Переделал под типовую файловую демо-базу.
То же самое с создание документа на стороне сервера не удалось. Ошибка на сервере в процедуре "ОбработкаЗаполнения" без расшифровки. К отладке подключиться на сервере не смог. Возможно из-за того, что база файловая. Поэтому выкладываю как есть. Если нужен строительный материал, берите.

Тестировал на: 1С:Предприятие 8.3 (8.3.16.1148)
Бухгалтерия предприятия КОРП + БИТ.ФИНАНС 3.0 (3.0.43.240/3.1.26.5)
Исходник работал на измененной: Бухгалтерия предприятия КОРП + БИТ.ФИНАНС 3.0 (3.0.69.35/3.1.41.3)

Начиная с версии 8.3.5 1С Предприятие умеет генерировать REST интерфейс для всей конфигурации, используя протокол OData. Это значит, что стороннее приложение может получить доступ ко всей базе 1С буквально за пару кликов.

Базы данных, которые размещаются на Платформе42, поддерживаются автоматическим REST-сервисом по протоколу OData версии 3.0. И мы подготовили для вас большую инструкцию – знакомство с OData. Чтобы не пугать вас «простыней», мы разбили ее на 11 блоков. В этой статье вы найдете краткие обзоры блоков и ссылки на подробную информацию.

Возможности и настройка

Из этой инструкции вы получите общее представление об интерфейсе OData. Тут мы рассказываем об основных возможностях протокола и о том, как настроить автоматический REST-сервис для запроса и обновления данных. Если хотите познакомиться и узнать, какие задачи можно решить при помощи OData – вам сюда.

Общие принципы работы

Здесь мы разбираем специальную терминологию OData. Рассмотрим в отдельности каждый термин из тех, которыми будем оперировать в дальнейшем, узнаем, как выполнить обращение к стандартному интерфейсу OData и подробно разберем верный URL-запрос.

Представление данных

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

Правила формирования имени ресурса

Из этого текста вы узнаете, по какому принципу формируется идентификатор имени ресурса, к каким объектам можно получить доступ при помощи стандартного интерфейса OData и как уточняется имя ресурса при помощи суффикса. Возможные виды суффиксов тоже разберем.

Правила формирования условия отбора

В данном разделе мы приводим информации по различным способам формирования отбора получаемых данных, которые используются в стандартном интерфейсе OData системы «1С:Предприятие». Инструкция большая и детальная, советуем ознакомиться «с чувством, с толком, с расстановкой».

Параметры запроса

Здесь рассматриваем четыре основных параметра запроса: $count, $inlinecount, $orderby и $expand. Узнаем, что они позволяют сделать, как их правильно использовать и какие подводные камни могут встретиться на пути погружения в тему.

Способы получения описания стандартного интерфейса OData

Рассказываем при помощи каких GET-запросов можно получить сокращенное и полное описания стандартного интерфейса OData. Расскажем, каким образом формировать параметр $format при выполнении запроса, если данные получены в формате json.

Способы получения данных

А в этой инструкции расскажем, как получать и списки сущностей, и сами сущности. Эти способы получения данных отличаются URL, по которому происходит обращение к данным. Вы узнаете, чем отличается URL набора сущностей от канонического URL экземпляра сущности.

Выполнение функций и действий

Посмотрим, как формируется URL ресурса, если с сущностью или с набором сущностей связана функция (например, работа с виртуальными таблицами регистров выполняется именно через функции).

Ошибочные ситуации

Вот мы и подошли к самому интересному – к кодам ошибок, их описанию. Посмотрим, как происходит информирование об ошибках со стороны клиентского приложения и об ошибках со стороны сервера, какие коды назначаются и что с этим делать.

Примеры типовых операций

И немного практики напоследок. Рассмотрим несколько типовых операций в их практическом применении. Пошагово разберем работу с одним объектом, работу с планами обмена и другие вещи, с которыми вам наверняка придется столкнуться.

Чтобы иметь полное представление о стандартном интерфейсе OData, ознакомьтесь со всеми представленными выше инструкциями. Или сохраняйте в закладки, чтобы обращаться к этому тексту по мере необходимости.

Взаимодействие с базой данных 1С возможно следующими методами:

Подготовка базы для взаимодействия по API.

Публикация на web-сервере.

Настройка сквозной авторизации.

При обращении к базе данных по API потребуется сквозная авторизация. Для ее обеспечения следует создать в базе пользователя с логином и паролем аналогичными учетным данным для основного или дополнительного пользователей. Также следует дать данному пользователю полные, либо необходимые для взаимодействия права.

Проверка наличия сервиса в конфигурации.

По умолчанию будут опубликованы все стандартные web-сервисы конфигурации. В таком режиме публикации к web-сервисам следует обращаться по ALIAS.

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

Проверить правильность выполняемых действий можно следующим образом.

В любой конфигурации есть стандартный WS «EnterpriseDataExchange», к нему можно обратиться следующим образом.

Открыть подраздел Web-сервисы выбрать «EnterpriseDataExchange», в примере это «EnterpriseDataExchange_1_0_1_1» проверяем во вкладке «Прочее» его ALIAS – «EnterpriseDataExchange_1_0_1_1.1cws».

Теперь обращаемся к сервису через браузер добавив к ссылке на базу /ws/EnterpriseDataExchange_1_0_1_1.1.1cws?wsdl

При запросе логина и пароля следует ввести учетные данные пользователя, которые использовались для настройки сквозной авторизации.

Если при ответе на запрос получаем xml данные, значит предварительная настройка произведена корректно.

Взаимодействие посредствам web-сервисов.

Перед началом обращения к web-сервисам баз данных по API следует предварительно выполнить условия, указанные в предыдущем пункте данной статьи, это публикация информационной базы и настройка сквозной авторизации.

Для взаимодействия с базой данных через web-сервисы (WS). Просмотреть доступные для работы сервисы можно открыв базу в режиме конфигуратора, раскрыть раздел «Общие», раскрыть подраздел «Web-сервисы».

Как говорилось ранее, все WS по умолчанию уже опубликованы, к ним следует обращаться по alias, синтаксис можно посмотреть в конфигураторе через свойства конкретного сервиса, раздел «Прочее».

В запросе расширение «.1cws» меняем на «?wsdl»

Для публикации нестандартных сервисов, следует создать обращение в техническую поддержку, указать базу и сервис, который следует опубликовать.

Далее следует составить обращение в техническую поддержку, указать базу и сервис, который следует опубликовать. Инженеры внесут правки в публикацию, после чего её можно проверить, сделав соответствующий запрос через браузер, запрос должен иметь следующую форму:

Также необходимо учитывать тот факт, что для работы некоторых сервисов (например, для телефонии) необходима анонимная аутентификация, в рамках сервиса её допускается включать только для баз, работающих на SQL.

Взаимодействие по средствам стандартного интерфейса ODATA

Перед началом обращения к интерфейсу ODATA следует предварительно выполнить условия публикации информационной базы и настройку сквозной авторизации (описаны выше). Далее следует составить обращение в техническую поддержку, указать базу в которой следует опубликовать интерфейс ODATA.

После внесения правок в публикацию можно будет проверять обращение к базе через стандартный интерфейс, в формате json, пример:

Odata работает.
Теперь нужно обратиться к объекту к базе, сделаем на примере справочника Контрагенты:

Следует войти в режим «Предприятие», открыть «Все функции» - «Обработки» и найти «Настройка автоматического REST-сервиса».

Во вкладке «Состав» следует выбрать нужные для отображения данные и сохранить изменения.

Теперь при выполнении запроса

Мы получаем ответ:

Запрос отработан корректно.

Взаимодействие с базами через FTP

Помимо вышеперечисленных вариантов с файлами и папками на облачном диске w можно взаимодействовать напрямую через ftp.

Читайте также: