Настройка автоматического rest сервиса 1с

Обновлено: 06.01.2025

REST API работает только если при работе с ТСД используется сервер Mobile SMARTS. При прямом подключении ТСД к компьютеру через кабель/крэдл или при обмене с учетной системой через папку использовать REST API не получится.

Функционал REST API в локальном и глобальном ядре полностью идентичен, т.е. код процедур и функций практически полностью совпадает. Поэтому, если требуются доработки, их нужно делать синхронно в 3 местах - глобальное ядро, локальное ядро УФ, локальное ядро ОФ.

Коды состояния бывают в диапазоне от 100 до 500 и выше, их можно разделить на следующие группы:

200+: запрос успешен, в обработке используются:

200 — запрос успешно выполнен;
204 — запрос успешно выполнен, но ответ не содержит тела. Используется при выгрузке/очистке справочников Mobile SMARTS, удалении документа Mobile SMARTS, изменении статуса документа Mobile SMARTS.

401 — не удалось авторизоваться на сервере Mobile SMARTS для выполнения запроса, например, из-за неверного логина/пароля или по причине того что истек срок действия токена, поэтому потребуется переавторизация.

В обработке для реализации REST API используются прикладные объекты 1С такие как:

GET – используется для получения со стороны севера определенного ресурса (настройку Mobile SMARTS, документ, список документов Mobile SMARTS, метаданные базы Mobile SMARTS). Если вы производите этот запрос, сервер ищет информацию и отправляет ее вам назад. По сути, он производит операцию чтения на сервере. Дефолтный тип запросов.
POST – нужен для создания определенного ресурса на сервере. Сервер создает в базе данных новую сущность и оповещает вас, был ли процесс создания успешным. По сути, это операции создания настройки Mobile SMARTS, документа Mobile SMARTS, выгрузки справочников Mobile SMARTS.
PUT и PATCH – используются для обновления определенной информации на сервере, например, статуса документа Mobile SMARTS. В таком случае сервер просто изменяет информацию существующих сущностей в базе данных и оповещает об успехе выполнения операции.
DELETE – как и следует из названия, удаляет указанную сущность из базы (удаление настройки Mobile SMARTS, документа Mobile SMARTS, очистка справочника Mobile SMARTS) или сигнализирует об ошибке, если такой сущности в базе не было.

для номенклатуры - "Products/BeginUploadProducts"
для ячеек - "Cells/BeginUpdate"
для прочих сравочников - "Tables/"+ИмяТаблицыENG+
"/BeginOverwrite"

для номенклатуры - "Products/AddProductsToUpload"
для ячеек - "Cells"
для прочих справочников - "Tables/"+ИмяТаблицыENG

для номенклатуры - "Products/ResetUploadProducts"
для ячеек - "Cells/ResetUpdate"
для прочих справочников - "Tables/"+ИмяТаблицыENG+
"/ResetOverwrite"

для номенклатуры - "Products/EndUploadProducts"
для ячеек - "Cells/EndUpdate"
для прочих справочников - "Tables/"+ИмяТаблицыENG+"/EndOverwrite"

для номенклатуры - "Products/BeginUploadProducts"
для ячеек - "Cells/BeginUpdate"
для прочих сравочников - "Tables/"+ИмяТаблицыENG+
"/BeginOverwrite"

для номенклатуры - "Products/EndUploadProducts"
для ячеек - "Cells/EndUpdate"
для прочих справочников - "Tables/"+ИмяТаблицыENG+
"/EndOverwrite"

Получение реквизитов шапки документа - "DocTypes('" +
СтруктураДокумента.uni + "')?$expand=fields"
Получение реквизитов табличной части документа - "DocTypes('" +
СтруктураДокумента.uni + "')?$expand=columns"
Получение списка доп.таблиц, которые не определены в метаданных
документа, но существуют у самого экземпляра документа - "DocTypes('" + СтруктураДокумента.uni + "')?$expand=tables($expand=fields)"

Редактировать/добавить документ - "Docs" + данные документа
Выгрузить табличную часть, например, declaredItems - "Docs('"+idДокумента+"')/declaredItems"
Принудительное сохранение документа, когда
все строки уже загружены - "Docs('"+idДокумента+"')/EndUpdate"

10.0.0.29	— пример IP-адреса сервера Mobile SMARTS
e1fc20aa-ff42-47df-9e5b-a94ba38b8935	— пример ID базы Mobile SMARTS

REST_API_ПодключитьсяКБазеSMARTS

Ключ	Значение	Комментарий
"@odata.context"	"http://localhost:18686/MobileSMARTS/api/v1/$metadata"
"value"	Массив	Метаданные базы Mobile SMARTS

REST_API_ПолучитьТокенSMARTS

Ключ	Значение	Комментарий
"Expires_in"	86 400	Срок действия токена в секундах
"Access_token"	"8ee184cb1eb7b4b945a69bbc5bd198a5"	Токен доступа
"Token_type"	"bearer"	Тип токена
"Refresh_token"	"b8140b77fa61fa5399735ab60f7a9f16"	Токен обновления

REST_API_ПолучитьОписаниеБазы

REST_API_ПолучитьЗначениеНастройкиБазыSMARTS

REST_API_ЗаполнитьНастройкиSMARTS

REST_API_ЗаписатьНастройкиSMARTS

REST_API_УдалитьНастройкиSMARTS

REST_API_ВыгрузитьТаблицуНаСерверSMARTS

Будут выполнены 3 запроса: начать выгрузку, выгрузка, завершить выгрузку (или прервать выгрузку, в случае ошибки), пример дан для выгрузки номенклатуры. В случае выгрузки ячеек или дополнительных таблиц будут изменяться только наименования методов (см. таблицу выше), все остальное выполняется по тому же алгоритму

Запрос 1 — Начать выгрузку

Запрос 2 — Начать выгрузку

Запрос 3 — Завершить выгрузку / прервать выгрузку

REST_API_ОчиститьТаблицуНаСервереSMARTS

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

REST_API_ПолучитьМетаданныеДокументовMS - состоит из 7 запросов

Запрос1 — Получение списка типов документов

Запрос 2 — Получение метаданных и реквизитов шапки документа на примере документа «Агрегация»

Запрос 3 — Получение метаданных и реквизитов табличной части документа на примере документа «Агрегация»

Запрос 4 — Получение списка доп.таблиц, которые не определены в метаданных документа, но существуют у самого экземпляра документа на примере документа «Агрегация»

Запрос 5 — Получение списка дополнительных таблиц

Запрос 6 -— Получение списка пользователей — «Users»

Запрос 7 — Получение списка устройств — «Devices»

REST_API_ПолучитьСписокДокументовНаСервереSMARTS

REST_API_ПолучитьДанныеДокументаНаСервереSMARTS

REST_API_ЗаписатьДокументВБазуSMARTS

Запрос 1 — Выгрузка шапки документа

Запрос 2 — Выгрузка табличных частей документа, например, declaredItems

Запрос 3 — Принудительное сохранение документа, когда все строки уже загружены

Итак, начнем сначала.

Что такое REST и зачем он нужен

REST (REpresentation State Transfer) подход является одним из наиболее популярных подходов, использующихся для реализации web-сервисов в Интернете. REST web-сервисы являются более легковесными альтернативами SOAP веб-сервисам.

REST с технической точки зрения не является ни технологией, ни стандартом. Это всего лишь подход, если можно так сказать, набор принципов, которые помогают реализовать "правильный" web-сервис. Под "правильным" здесь понимается масштабируемый, безопасный, надежный, легкий в использовании и т. д.

REST определяет следующие принципы построения web-сервисов:

Преимуществами REST подхода являются:

Недостатки REST'а являются продолжением его достоинств:

Протокол, который основывается на принципах REST, является RESTful протоколом. Два наиболее популярных типа RESTful протоколов - это JSON (JavaScript Object Notation) и POX (Plain Old XML). JSON использует для кодирования данных JavaScript и в основном применяется в Ajax (Asynchronous JavaScript and XML) клиентах для обмена данными с сервером. Поскольку Ajax клиенты работают в браузере, который понимает JavaScript, то использование JavaScript позволяет сэкономить как на объеме передаваемых данных, так и на времени разбора данных. Однако использование JSON в других клиентах проблематично, т. к. клиенты, как правило, не поддерживают JavaScript.

POX использует для кодирования данных XML и поэтому может использоваться практически везде.

REST в 1С

Использовать стандартный интерфейс OData прикладного решения просто:

По умолчанию после публикации объекты конфигурации не доступны. Прежде чем обращаться к ним, необходимо разрешить доступ, например с помощью типовой обработки "Настройка автоматического REST сервиса". В обработке можно задать отдельного пользователя REST сервиса:

и указать доступные объекты конфигурации:

"odata/standard.odata" - "магическое" слово, означающее доступ через odata интерфейс

"Catalog_Контрагенты" - состоит из указания на тип объекта "Catalog" - справочник и типа справочника

"select" - оператор чтения данных, после него через "=" идет описание считываемых данных, в данном случае это "Ref_Key" - уникальный идентификатор

"format=json" - задает формат представления считываемых данных JSON

"odata=nometadata" - заклинание, указывающее не передавать в ответе описание метаданных.

и отправляем его:

Если все хорошо, в ОтветСтрокой находится что-то вроде:

Разобрать ответ можно например так:

Если Ответ.КодСостояния > 299 Тогда ТекстОшибки = "Error, код ошибки: " + Ответ.КодСостояния + " |" + ОтветСтрокой; Иначе КолСтрок = СтрЧислоСтрок(ОтветСтрокой); Для НомерСтроки=1 По КолСтрок Цикл СтрокаАнализа = СтрПолучитьСтроку(ОтветСтрокой, НомерСтроки); Если СтрНайти(СтрокаАнализа,"Ref_Key") > 0 Тогда ПозицияДо = СтрНайти(СтрокаАнализа, """",НаправлениеПоиска.СКонца); ПозицияС = СтрНайти(СтрокаАнализа, """Ref_Key"": """); Если (ПозицияС > 0) И (ПозицияДо = (ПозицияС + 48)) Тогда НачалоID = ПозицияС + 12; GUID = Сред(СтрокаАнализа, НачалоID, 36); РезультатМассив.Добавить(GUID); КонецЕсли; КонецЕсли; КонецЦикла; БулевРезФун = Истина; ТекстОшибки = "OK. Считано элементов: " + Формат(РезультатМассив.Количество(), "ЧН=0; ЧГ &$filter=Ref_Key eq guid'" + KeyID + "'";

где в KeyID строковое представление УИД

Наименование реквизитов как видите порой неочевидно. Необходимо запомнить:

DeletionMark - пометка удаления,

IsFolder - признак группы,

Если реквизит ссылочного типа, к его имени следует добавить суффикс _Key, например Организация_Key.

Для документов используется схожий синтаксис:

/Base1C/odata/standard.odata/Document_СчетНаОплатуПокупателю?$select=Ref_Key, Number, Date&$format=json;odata=nometadata

Number - номер документа,

Date - дата документа.

Создание и изменения объектов через REST будет в следующей части.

Специальные предложения

Еще, как недостаток, крайняя нестабильность при использовании в системах бизнес-аналитики. Может положить весь кластер "1С:Предприятие" (конфигурация, что падала: 40 Core\192GB RAM\RAID SSD DB\2xSSD tempdb). (1) Не советую использовать REST в бизнес-аналитике. REST в 1с использует оптимистическую блокировку данных. С одной стороны такой подход повышает скорость работы, с другой можно получить не корректные цифры в отчете. Положить кластер у меня пока не получалось, хотя глюков наловил не мало. (1) я надеюсь у вас стоит нескоько апачей и используется слабосвязанная система тикетов? (1) какую BI используете если не секрет, и чем заменили REST? (2) Хорошая статья, жаль что я не прочитал ее раньше, когда только осваивал работу с веб-сервисами. Основное достоинство REST - производительность. После "прогрева" системы REST сервис работал в 3-10 раз быстрее чем аналогичные по функционалу SOUP сервис. Такая разница стоит мучений.

Вызов Web-сервиса происходит следующим образом:

? из пула соединений выбирается подходящее соединение с информационной базой; при отсутствии необходимого соединения соединение создается;

? создается новый сеанс и для созданного сеанса вызывается событие УстановкаПараметровСеанса (в модуле сеанса);

? выполняется вызов затребованного метода Web-сервиса, при этом происходит вызов обработчика УстановкаПараметровСеанса() (в модуле сеанса) каждый раз, когда происходит обращение к неинициализированному параметру сеанса.

Если в пуле нет соединений, то создается новое соединение с загрузкой метаданных, что аналогично запуску 1С с нужной конфигурацией.

В новых версиях, программа может выбирать нужный сеанс из пула при этом УстановкаПараметровСеанса производиться не будет.

(22) В (24) подробно описано. Первое обращение к сервису вызывает загрузку и инициализацию используемых библиотек. Оно всегда долгое и учитывать его в замере производительности неверно. Риник; kolya85; Strannik777; Gendelf; Elvina; Drivingblind; binex; purgin; bow; + 9 – Ответить Эх, не дошли до самого интересного - до записи. Будете продолжать? Почему-то когда я читаю из базы документ, меняю в ответе один реквизит и пытаюсь записать, то в ответ возвращается всякая ерунда (обычно что не заполнена дата). (8) Я скорее практик чем теоретик. Состояние реализуется элементарно, на глобальных переменных или РС. Если выполнение кода сервиса зависит от значения глобальной переменной, эта переменная хранит состояние сервиса. (9)Глобальные переменные не подойдут - при работе с REST-Сервисом их нет. А хранение состояния в регистре сведений возможно - указано мной в (14), но это не то состояние, которое закладывается в определении REST-Сервиса

До не давних пор WEB-Сервисы в 1С не имели возможности хранить состояния сеанса (теперь могут) + необходимость их предварительно кодить на 1С, чтобы использовать - это их главное отличи от REST-Сервисов (но зато WEB-Сервисы более универсальны (ведь в их реализации можно написать любой алгоритм); а области данных, доступ к которым можно получить в ИБ через REST-сейчас очень ограничены, например управлять пользователями нельзя).

(10) можете раскрыть смысл термина "состояние"? что вы в него вкладываете?

(13)В простейшем виде. Состояние - любая управляемая (на которую клиент может целенаправленно влиять) информация, которая сохраняется на сервере после выполнения последней команды, и может быть получена (учтена) при выполнении следующей команды (при этом, при параллельном выполнении множества команд, в т.ч. от разных клиентов) нужная информация (созданная первой командой) будет автоматически (не важно как) сопоставляться со второй командой и соотноситься с исходным клиентом (когда это требуется).
За исключением тривиального примера: когда целем выполнения первой команды есть ТОЛЬКО создание этой информации. А второй команды - только её получение!
Путь будет так, простите, коли запутанно или не точно раскрыл термин. Я не профессор. Понятн, что за уши к этму определению можно приникнуть многое, но делать это не стоит.

(8)Дополнительно поясняю: описанный вам пример является требует наличия состояния на сервере, но не соответствует определению REST-сервиса. Насколько я понимаю, REST-Сервисы вообще не предназначены для запуска выполнения таких фоновых процессов. Но если они уже запущены, или запускаются косвенно после внесения изменений в данные, то формально, можно организовтаь что вы хотите, например так (как уже было предложено в (9)):
1. Допустим на сервере 1С есть регл. задание - которое выполняет какую-либо фоновую обработку (возможно через запуск отдельных фоновых заданий - это не принципиально).
2. Это регл задание, например, мониторит рег. сведений - на наличе записи с запросом на выполнение регл задачи (например произвольного алгоритма из строкового ресурса)
3. Тогда REST запросом - можно внести в этот регистр эту запись + некий ключ
4. Регл. задание это увидит и запусит фоновое выполнение этой задачи, передав ей этот ключ
5. Фоновое задание выполнит переданный алгоритм, например, некоторую часть (как это определяется к сути данного вопроса не относится) и запишет в тот же или другой рег. сведений по имеющемуся ключу результат (окончательный или промежуточный)
6. Внешний процесс через REST-Сервис будет опрашивать этот регистр по тому же ключу на наличие результата.
7. При необходимости через REST-сервис можно внести запись в регистр сведений, что выполнение нужно прервать (или внести изменения)
8. Эту запись то же регл задание может увидеть и прервать выполнение фонового задания с соответствующим ключём (или это может сделать само фоновое задание, тогда оно может внести любое изменения в ход своего выполнения).

Формально говоря, REST-Сервисы можно использовать и для выполнения каких-то фоновых процессов и опроса их результатов. И даже состояние в этом случае сохраняется в информационной базе. Но это лишь обходные уловки, реализация которых требует внесения изменений в конфигурацию. А сами данные состояния клиента, просто хранятся в базе данных. Но тем не менее, описанный мной выше алгоритм взаимодействия вполне может быть использован в рабочих системах.
По-другому запустить выполнение алгоритма через REST-Сервис в 1С (это ограничение текущей реализации 1С 8.3.9) пока нельзя. Но, думаю, со временем это изменится. И тогда, запустить, скажем фоновое выполнение задания можно будет и через REST. Но хранить состояния всё равно нужно будет в ИБ во вспомогательных хранилищах. И это не будет текущим состоянием сеанса. Это буду данные в базе данных.

Варианты хранения такого состояния ограничены лишь тем, что можно сохранить в БД. Например, не удастся так хранить состояние COM -Соединения, или иного сетевого соединения с другим ресурсом (в сети, интернете, или файлом); или оборудованием (подключенном через компоненту). Для многих задач хавтит и описанного способа, но не для всех.

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

Там не только подписки, но и выполнение на сервере итд.
И делать проверку модулей с галками внешнее соединение, сервер

В статье мы настроим серверную часть 1С для использования REST API 1С:Предприятие в веб-разработке. Настройку будем производить на рабочем терминальном сервере Windows Server 2008 R2 с установленной на нем файловой 1С:Бухгалтерия 8.3 Базовая, к которой одновременно будет иметь доступ бухгалтер. В качестве веб-сервера будем использовать родной в среде Windows Internet Informational Services 7.

Подготовка и настройка Windows Server и IIS

Для использования API 1C нам необходим веб-сервер, который будет обрабатывать запросы от разрабатываемого нами веб-приложения. Поскольку мы не перестраиваем инфраструктуру, используем уже установленную платформу 1С:Предприятие и конфигурацию 1С:Бухгалтерия Базовая 8.3. В качестве веб-сервера было принято решение не устанавливать сторонние сервисы, а использовать MS IIS.

Запускаем Диспетчер сервера и нажимаем Добавить роль. Ставим галочку напротив Веб-сервер (IIS). В следующем окне проверяем наличие галочек напротив устанавливаемых компонентов.

В следующем окне проверяем наличие галочек напротив устанавливаемых компонентов.

Для папки, где лежит база данных 1С добавляем права на чтение и изменения для групп IIS_USERS, IUSR. А также на запуск C:\Program Files (x86)\1cv8\8.3.xx.xxxx\bin для тех же групп.

Далее добавляем новое приложение в секции Default Web Site.

В пуле приложений DefaultAppPool добавляем возможность запуск 32-хразрядных приложений – нажимаем «Дополнительные параметры» и изменяем значение опции «Разрешены 32-разрядные приложения» на True.

Чтобы REST API 1с был доступен из сети Интернет (я надеюсь, ваш Windows сервер не имеет прямого выхода в интернет), необходимо выполнить проброс портов - пример этого действия на оборудовании Mikrotik читайте в этой статье.

Публикация веб-сервисов 1С для использования его REST API веб-приложением

Публикация веб-сервисов 1С предназначена не только для использования REST API от 1С, но и для работы с 1С:Предприятие через веб-браузер. Для использования этих возможностей, необходимо установить «Модули расширения веб-сервера» через установщик технологической платформы 1С. Убедившись в том, что модули расширения веб-сервера 1С установлены, переходим в конфигуратор. Для этого запускаем 1С с правами администратора и открываем конфигуратор интересующей нас базы данных.

Далее открываем пункт меню Администрирование-Публикация на веб-сервере. В открывшемся окне вводим произвольное Имя, указываем веб-сервер (Internet Information Services), ставим галочки «Публиковать стандартный интерфейс OData», а также 2 галочки «Публиковать Web-сервисы».

ExternalAPI
ПередачаДанных
УниверсальнаяИнтеграцияВнутренняя

Нажимаем на кнопку «Опубликовать» и соглашаемся на перезапуск сервера IIS.

Моя базовая версия запустилась, но отказалась находить лицензию. Это никак не помешает в работе с API, а использовать веб-клиента 1С не планировалось.

Поэтому добившись в окне браузера стартовой загрузки 1С, можно переходить к настройке прав доступа нашего веб-приложения к данным 1С, получаемым через API. Для этого создадим пользователя(ей), от имени которых будем работать с API.

Открываем меню Администрирование-Пользователи, добавляем пользователя, обращая внимание, что его имя и пароль не должны содержать русских символов. И добавляем ему необходимые права.

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

Открываем пункт меню «Все функции», далее «Обработки»-Настройки стандартного интерфейса OData.

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

На вкладке «Состав» нажимаем кнопку «Загрузить метаданные» - это действие наполнит список всеми возможными справочниками, документами и прочими объектами, которые могут быть доступны через API 1C. С помощью поиска или просто пролистывая ставим галочки напротив тех объектов, которые планируем использовать при разработке веб-приложения. Зависимости будут автоматически добавлены. После этого нажимаем кнопку Сохранить и переходим к стадии проверки работоспособности API.

Тестирование API 1C и настройка CORS

В ответ браузер выведет окно ввода логина и пароля – пользователя которого мы создали на предыдущем шаге. При успешной авторизации мы должны получить JSON-строку, содержащую 10 первых записей справочника Номенклатура, которые не помечены на удаление, не являются папками и отсортированы по наименованию по возрастанию.

Прекрасно! Теперь можно опробовать работу API в реальной разработке. Создадим простенькое приложение, запрашивающее данные из API 1С:Предприятие через библиотеку axios.

И здесь нас поджидает фиаско в виде ошибки:

Для этого установим Microsoft Web Platform Installer. После чего пункт Установщик веб-платформы будет отображаться в конфигураторе IIS.

С его помощью мы сможем настроить политику безопасности CORS. Воспользуемся поиском – найдем CORS и установим найденный компонент. Теперь переходим к его настройке.

Запускаем редактор конфигураций сайта 1С. Выбираем в выпадающем списке «Раздел» system.WebServer-cors. Установим Enabled в true. Раскрываем пункт «Коллекция» нажатием на … .

allowMethods - нажатием на кнопку … раскрываем список и добавляем все методы, которые будут нами использоваться в связке нашего веб-приложения с API 1C:Предприятие.

Соответственно, если планируется использовать другие хосты для отправки запросов к IIS – добавляем аналогичным образом.

Теперь самое время попробовать наше первое тестовое веб-приложение.

Как мы убедились, запрос правильно отрабатывает и API 1С корректно передало данные в наше веб-приложение.

Начиная с версии 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, ознакомьтесь со всеми представленными выше инструкциями. Или сохраняйте в закладки, чтобы обращаться к этому тексту по мере необходимости.

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