Подключение по api из 1с

Обновлено: 07.07.2024

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 — Принудительное сохранение документа, когда все строки уже загружены

Тестировалось в УПП 1.3 (8.3.9.2170)

В моем соединении нету пользователя, пароля, не используется защищенное соединение. Если Вам необходимы эти параметры их можно добавить в строке "Все параметры подключения" и вынести поля на форму или написать комментарий я обновлю обработку.

Основной код отправки данных из описанного функционала (у меня использовалось только GET и POST, остальное добавил вдруг кому пригодится):

Кнопки "JSON", "XML", "POST=" - показывают пример заполнения тела в данном формате (я их использовал для тестирования отправки своих данных в разных форматах).

Можете поблагодарить, если Вам помог описанный функционал.

Подключение к сайту и отправка или получение данных по API (POST, GET. ) (с описанием кода):

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

Попробуйте заменить на вот это:

Просмотры 28837

Загрузки 56

Рейтинг 36

Создание 12.08.19 15:30

Обновление 12.08.19 15:30

№ Публикации 1106730

Конфигурация Конфигурации 1cv8

Операционная система Не имеет значения

Вид учета Не имеет значения

Доступ к файлу Абонемент ($m)

Код открыт Да

См. также

Модуль обмена с QIWI Промо

Компании, которые используют систему моментальных платежей QIWI, ценят ее за удобство по скорости выплат и для платежей по запросу. Но такие переводы сложны для учета, а при большом объеме проводимых операций отнимают много времени и превращаются в дополнительную головную боль. Мы сотрудничали с компаниями, которые отправляют большое количество платеже на QIWI, и часто слышали боль бухгалтеров о том, как им сложно работать с такими переводами. Поэтому мы автоматизировали выплаты через QIWI в 1С и создали модуль интеграции 1С c API QIWI Wallet и QIWI TopUp.

5 стартмани

25.05.2020 8217 0 Neti 10

Расширение конфигурации для Web-доступа к 1С (1С в роли back-end)

Для реализации того, чтобы 1С формировала и отдавала страницу, которую можно было бы открыть через браузер было написано расширение, которое позволяет публиковать из 1С произвольные ресурсы, будь то API, сайт или изображения / прочие файлы.

1 стартмани

01.04.2021 8851 11 SaschaG 4

Работа с картами в 1С на примере бесплатной библиотеки Leaflet

Разработка функционала отображения и выбора пунктов доставки на карте прямо в 1С с помощью бесплатной библиотеки Leaflet. Тестирование производилось на платформе 8.3.15.1534 на тонком клиенте.

1 стартмани

31.03.2021 10498 31 Parsec1C 11

1 стартмани

24.03.2021 7136 13 ltfriend 12

BIM: взаимодействие с платформой Autodesk Forge Промо

Предлагаемый пример демонстрирует широкие возможности для взаимодействия «1С:Предприятие» с платформой Autodesk Forge и позволяет вам получить базовые представления о применения технологий информационного моделирования в строительстве. Поддерживаются все версии платформы от 8.3.12 и выше до 8.3.18.

Задача: подключение к REST API по протоколу Oauth 2.0 и получение данных от API для дальнейшего парсинга и загрузки в БД.

Решение состоит из:
* Получение токена авторизации;
* Получение данных с использованием токена авторизации.

Получение токена авторизации

Получение токена авторизации выполняется при помощи POST запроса XTTP, при этом есть нюансы реализации этого запроса для x32 и x64 разрядных версий сервера 1С, а также особенности при работе этого запроса в веб клиенте.

XTTP запрос для получения токена OAuth выглядит следующим образом:

Проблемы при работе с POST XTTP подключением авторизации

1. Ошибка при получении токена на x64 разрядном сервере 1С.

Можно столкнуться с проблемой, когда у клиента 1С в развернута в платном облачном сервисе, где возможности изменить параметры сервера или зарегистрировать дополнительные dll нет возможности, либо запрещено выполнять JavaScript, который в нашем коде создается в строке COMОбъект("MSScriptControl.ScriptControl").

То есть, если подключение XTTP описано на сервере, например в модуле объекта обработки и при этом сервер 1С x64 разрядный, то можно получить следующую ошибку:

: Ошибка при вызове конструктора (COMОбъект): -2147221164(0x80040154): Class not registered.

Если XTTP подключение описано на клиенте в форме обработки, то при выполнении этого кода в браузере Chrome, можно получить следующую ошибку:

Ошибка связана с особенностями запуска ActiveX объектов в браузерах. В Internet explorer текст ошибки может отличаться.

Решение ошибок

Для решения проблемы с исполнением кода на x64 разрядном сервере нужно перенести код подключения на клиент в форму обработки, так как это представлено в примере кода выше. Но при этом получается что в браузере это решение всё ещё работать не будет. Потому что браузер с нужным нам COM объектом работать не может и углубляться в причины этой проблемы будет просто потерей времени. Гораздо более быстрым решением станет реализация этого запроса при помощи JavaScript помещенного в элемент формы с видом ПолеHTMLдокумента.

Решение получения токена в веб клиенте

Есть различные варианты реализации подхода через ПолеHTMLДокумента. Например можно сделать кнопку "Войти" на форме и по этой кнопке вызывать скрипт описанный в HTML документе, а можно сверстать HTML, поместить его в ПолеHTMLДокумента, то есть кнопка "Войти" будет элементом HTML страницы. Я реализовывал второй вариант.

Токен получен. Соответственно токен нужно положить в какой-нибудь реквизит, либо передать токен в основную форму обработки, если форму авторизации вы сделали как отдельную форму настройки.

Получение данных из API с использованием токена авторизации

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

Реализация получения данных для тонкого клиента

Есть нюанс в заголовке XTTPЗапрос.setRequestHeader("Origin", "*"), чтобы запрос к API работал с этим заголовком, нужно обсуждать параметры API с теми кто им заведует. Насколько я знаю, в настройку Origin на сервере API нужно устанавливать значение адреса домена с которого осуществляется подключение. Без настройки этого заголовка на сервере и установки этого заголовка в коде 1С может возникать ошибка авторизации 403.

Реализация получения данных для веб клиента

Аналогично авторизации, необходимо при создании формы заполнить содержание HTML документа на форме. При этом не получиться сделать поле HTML на форме 1С невидимым, иначе оно не инициализируется. Поэтому просто делаем все элементы HTML разметки невидимыми при помощи display:none.

Т.к. время запроса к серверу может в зависимости от нагрузки на сервер быть разным, то нужно предусмотреть ожидание получения результата. Поэтому получения данных из HTML+JS у меня реалезовано не через функцию, а процедуру, в которой после выполнения скрипта подключается обработчик ожидания с вызовом функции, и в этой функции после того как мы увидели, что результат запроса был помещен в div "result" JavaScript'ом, мы получаем из этого div'а текст JSON и отправляем его на обработку в другие процедуры и функции.

Проблемы при работе с GET XTTP подключением получения данных

Чуть выше я уже кратко упомянул проблему, которая возникает при попытке получения данных, когда уже вроде бы должно всё работать. У нас есть токен авторизации, но когда мы пытаемся подключиться для получения данных, мы получаем ошибку авторизации 403. Она так же может отображаться в 1С следующим образом:

: Ошибка при вызове метода контекста (Получить): Ошибка работы с Интернет: Couldn't resolve host name.

Чтобы понять, что надо использовать заголовок Origin и настраивать его на сервере API, а не искать причину в чем то другом, нужно сделать следующее:

1. Создать и сохранить у себя на ПК новый HTML документ следующего вида

Заполняем собственные логин, пароль, и другие параметры в скрипте, и сначала нажимаем "Войти", чтобы получить токен в <div а затем нажимаем "Получить данные по токену", чтобы получить данные JSON в <div >

2. Открываем этот HTML в специальном режиме браузера Chrome:

Открыв браузер таким образом, будет отключена защита браузера CORS, и можно проверить, наш запрос в 1С не работает потому что срабатывает эта защита, или по какой-то другой причине. То есть, если возникнет ошибка в этом режиме браузера и данные мы не получили, то дело НЕ в CORS, а если в этом режиме браузера загружается, а в 1С не грузится с ошибкой "Couldn't resolve host name", то это проблема связана с CORS.

Также можно использовать программу Postman и попробовать выполнить запрос в этой программе.

Дополнительные настройки

Помимо этой проблемы стоит так же предусмотреть возможные проблемы при работе в IE. Рекомендую выполнить следующие настройки в своей системе:
1. IE свойства браузера - зайти в вкладку "Дополнительно" и у становить флаг «Разрешать запуск активного содержимого файлов на моем компьютере»;

2. Если установлен Касперский - нужно снять флаг с настройки «Внедрять в трафик скрипт взаимодействия с веб-страницами», который находится в "Настройки"(шестеренка) -> "Сеть".

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

Что такое 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С возможно следующими методами:

Подготовка базы для взаимодействия по 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.

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