Использование REST web-сервисов в "1C:Предприятии 8". Личный опыт.

04.12.16

Интеграция - WEB-интеграция

Часть 1. Чтение данных

Использование REST web-сервисов в "1C:Предприятии 8". Личный опыт.

Когда мне понадобилось использовать REST сервисы в 1С, я столкнулся с "лаконичностью" имеющейся документации и минимумом реальных примеров. Данная статья основана, в первую очередь, на материалах фирмы 1С (http://its.1c.ru/db/metod8dev/content/3790/hdoc/_top/post и http://v8.1c.ru/o7/201312rest/ и https://wonderland.v8.1c.ru/blog/rasshirenie-podderzhki-protokola-odata/) и собственном опыте и призвана немного прояснить тему.

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

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

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

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

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

  • Функциональность приложения делится на набор ресурсов. Каждый ресурс может выполнять определенное действие (REST ресурс является аналогом SOAP операции). Например, ресурс получения новостей выдает список заголовков текущих новостей;
  • Каждый ресурс имеет уникальный идентификатор (URL), по которому к нему можно обратиться как из программного кода, так и из Web-браузера;
  • Все ресурсы используют унифицированный интерфейс для передачи данных между клиентом и ресурсом. Интерфейс имеет ограниченный набор операций и типов данных для передачи. Как правило, в качестве транспорта используется инфраструктура HTTP, а набор операций, которые можно выполнить над ресурсом, определяется HTTP стандартом. Наиболее используемыми операциями могут быть: HTTP GET - получение данных от ресурса и HTTP POST отправка данных в ресурс. Также могут использоваться HTTP PUT, HTTP DELETE и т. д.;
  • REST протокол взаимодействия (RESTful) должен быть клиент-серверным и не иметь состояния.

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

  1. Возможность работы на уже существующей HTTP инфраструктуре - Web-серверах, Web-браузерах и др. 
  2. Простота использования и высокая совместимость между реализациями за счет того, что кодирование данных сведено к минимуму. Кодируются только прикладные данные (т. е. то, что нужно передать), вспомогательная маркировка данных (например, такая как soap:Envelope) не используется.
  3. Хорошая масштабируемость, т. к. REST протоколы не поддерживают состояния между вызовами.
  4. Хорошая безопасность, которая опять-таки основана на HTTP инфраструктуре.

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

  1. Сложно использовать вне HTTP, т. к. нет ни соответствующих стандартов, ни существующих реализаций.
  2. Сложно использовать в Entreprise решениях, где требуется поддержка достаточно сложного состояния (например, наличия сессий и др.).
  3. Полная зависимость от транспорта в таких вопросах, как безопасность, маршрутизация сообщений и пр., что может негативно сказаться на работе такого сервиса в гетерогенной среде.

Протокол, который основывается на принципах 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С

Начиная с версии 8.3.5.1068.  платформа может автоматически формировать REST интерфейс для всего прикладного решения. REST интерфейс позволяет читать данные 1С:Предприятия, изменять их, создавать новые объекты данных и удалять существующие. В качестве протокола доступа платформа использует протокол OData версии 3.0. Это открытый веб-протокол для запроса и обновления данных. Он позволяет оперировать данными, используя в качестве запросов HTTP-команды. Получать ответы можно в различных форматах, но пока платформа поддерживает только работу с данными в формате Atom/XML.

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

  • В конфигураторе вы публикуете REST интерфейс - флажок Публиковать стандартный интерфейс OData;
  • После этого объекты прикладного решения становятся доступны через этот интерфейс;
  • Способы аутентификации OData клиентов полностью совпадают со способами, используемыми для веб-сервисов;
  • OData клиенты могут запросить через HTTP документ метаданных, описывающий доступные объекты прикладного решения;
  • OData клиенты выполняют операции создания, чтения, модификации и удаления данных прикладного решения.

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

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

Чтение данных через REST

Чтение данных выполняется GET-запросом. Сначала устанавливаем HTTPСоединение с базой. Потом формируем текст запроса. Например, получение списка УИДов элементов справочника Контрагенты выглядит так:

/Base1C/odata/standard.odata/Catalog_Контрагенты?$select=Ref_Key&$format=json;odata=nometadata

Что означает это заклинание?

"Base1C" - имя базы, как оно опубликовано на веб-сервере,

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

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

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

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

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

Из текста запроса создаем объект HTTPЗапрос:

Запрос = Новый HTTPЗапрос(СтрокаЗапроса);

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

Ответ = HTTPсоединение.Получить(Запрос);

Полученный объект HTTPОтвет надо разобрать, удобнее анализировать строку:

ОтветСтрокой = Ответ.ПолучитьТелоКакСтроку();

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

{

"value": [{

"Ref_Key": "a913b5c7-9594-4680-8013-e6a8ff2ef33e"

},{

"Ref_Key": "e29427d9-9cbb-421d-8089-e9859b2427c3"

},{

}

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

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


Если нужно получить не один реквизит, текст запроса выглядит так:

/Base1C/odata/standard.odata/Catalog_Контрагенты?$select=Ref_Key,Description &$format=json;odata=nometadata

нужные поля добавляются через запятую в select.

Как правило все записи справочника читать не требуется, используем оператор filter:

СтрокаЗапроса = СтрокаЗапроса + "&$filter=Ref_Key eq guid'" + KeyID + "'";

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

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

Code - код,

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

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

Parent_Key - родитель.

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

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

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

 Для документов:

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

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

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

веб-сервисы REST обмен данными odata

См. также

Интеграция Альфа Авто 5 / Альфа Авто 6 и AUTOCRM / Инфотек

Сайты и интернет-магазины WEB-интеграция Платформа 1С v8.3 Конфигурации 1cv8 1С:Управление торговлей 11 Автомобили, автосервисы Россия Управленческий учет Платные (руб)

Интеграционный модуль обмена между конфигурацией Альфа Авто 5 и Альфа Авто 6 и порталом AUTOCRM. Данный модуль универсален. Позволяет работать с несколькими обменами AUTOCRM разных брендов в одной информационной базе в ручном и автоматическом режиме. Без существенных изменений типовой конфигурации. Проверено с брендами: Интеграция 1С и GEELY Интеграция 1С и HAVAL Интеграция 1С и KIA Интеграция 1С и FORD Интеграция 1С и LADA ГАРАНТИЯ 100% ВНЕДРЕНИЯ!

36000 руб.

03.08.2020    15655    9    17    

9

Модуль для обмена "1С:Предприятие 8. УАТ. ПРОФ" с FortMonitor

WEB-интеграция 8.3.8 Конфигурации 1cv8 Автомобили, автосервисы Беларусь Украина Россия Казахстан Управленческий учет Платные (руб)

Расширение предназначено для конфигурации "1С:Предприятие 8. Управление Автотранспортом. ПРОФ". Функционал модуля: 1. Заполнение регистров сведений по подсистеме "Мониторинг", а именно: события по мониторингу, координаты по мониторингу, пробег и расход по мониторингу, текущее местоположение ТС по мониторингу 2. Заполнение путевого листа: пробег по мониторингу, время выезда/заезда, табличная часть ГСМ, места стоянок по геозонам. 3. Отчеты по данным загруженным в регистры сведений. 4. Предусмотрена автоматическая загрузка данных в фоновом режиме (условия работы данной загрузке читайте в описании товара) Модуль работает без включенной константы по настройкам мониторинга. Модуль формы предоставляется с открытым кодом, общий модуль защищен. Любой заинтересованный пользователь, имеет возможность скачать демо-версию расширения.

22656 руб.

25.05.2021    12809    30    8    

10

Интеграция 1С — Битрикс24. Обмен задачами

Сайты и интернет-магазины Интеграция WEB-интеграция Платформа 1С v8.3 Конфигурации 1cv8 Управленческий учет Платные (руб)

Интеграция 1С и Битрикс24. Разработка имеет двухстороннюю синхронизацию 1С и Битрикс24 задачами. Решение позволяет создавать пользователя в 1С из Битрикс24 и наоборот. Данная разработка технически подходит под все основные конфигурации линейки продуктов 1С:Предприятие 8.3 (8.3.18.1289). При приобретении предоставляется 1 месяц бесплатных обновлений разработки. Доступна демо-версия продукта с подключением Вашего Битрикс24

5040 руб.

04.05.2021    17421    6    15    

13

[Расширение] БОР-Навигатор.Культура

Зарплата Бюджетный учет WEB-интеграция Обмен с ГосИС Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и кадры государственного учреждения 3 Государственные, бюджетные структуры Россия Бюджетный учет Платные (руб)

Расширение конфигурации, включающее в себя объекты, необходимые для подготовки и сдачи отчета "Штатная численность" системы "БОР-Навигатор.Культура" в программе "1С:Зарплата и кадры государственного учреждения", редакция 3.1.

8400 руб.

01.02.2019    25686    9    0    

7

Интеграция с сервисом vetmanager

WEB-интеграция Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бытовые услуги, сервис Платные (руб)

Внешняя обработка разрабатывалась для загрузки документов из Ветменеджер в 1С: Бухгалтерия 3.0

12000 руб.

02.02.2021    16253    41    49    

22
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. pbazeliuk 1954 04.12.16 17:54 Сейчас в теме
Еще, как недостаток, крайняя нестабильность при использовании в системах бизнес-аналитики. Может положить весь кластер "1С:Предприятие" (конфигурация, что падала: 40 Core\192GB RAM\RAID SSD DB\2xSSD tempdb).
5. Dorosh 176 05.12.16 09:26 Сейчас в теме
(1) Не советую использовать REST в бизнес-аналитике. REST в 1с использует оптимистическую блокировку данных. С одной стороны такой подход повышает скорость работы, с другой можно получить не корректные цифры в отчете. Положить кластер у меня пока не получалось, хотя глюков наловил не мало.
11. VasilVtoroy 05.12.16 18:15 Сейчас в теме
(1) А вы дампы в 1С посылали?
12. DitriX 2091 06.12.16 01:08 Сейчас в теме
(1) я надеюсь у вас стоит нескоько апачей и используется слабосвязанная система тикетов?
21. pfilyk 07.12.16 14:03 Сейчас в теме
(1) какую BI используете если не секрет, и чем заменили REST?
2. kiv1c 809 04.12.16 20:38 Сейчас в теме
тема пересекается с моей статьей про web-сервисы!
http://infostart.ru/public/537861/
насколько я понял, преимущество REST в том, что можно получить какие-то данные и манипулировать объектами сразу, не прописывая код отдельно, как в модулях веб-сервисов?
6. Dorosh 176 05.12.16 09:29 Сейчас в теме
(2) Хорошая статья, жаль что я не прочитал ее раньше, когда только осваивал работу с веб-сервисами. Основное достоинство REST - производительность. После "прогрева" системы REST сервис работал в 3-10 раз быстрее чем аналогичные по функционалу SOUP сервис. Такая разница стоит мучений.
22. pfilyk 07.12.16 14:07 Сейчас в теме
(6)
(6)
После "прогрева" системы REST

что вы имеете ввиду?
23. SGordon1 07.12.16 15:11 Сейчас в теме
24. Serginio 938 07.12.16 16:16 Сейчас в теме
(23) http://www.forum.mista.ru/topic.php?id=679547#4
Объект конфигурации Web-сервис содержит модуль, в котором создаются процедуры на встроенном языке, выполняемые при вызове тех или иных операций Web-сервиса. Типы параметров операций Web-сервиса описываются с помощью типов XDTO и могут представлять собой либо значения XDTO, либо объекты XDTO.

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

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

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

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


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

Ну и нужно учитывать, что при каждом вызове метода создается новый сеанс и УстановкаПараметровСеанса для web и HTTP сервисов (в том числе и ODATA Rest ) должны быть минимальными по времени.

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

Повышение производительности веб-сервисов

В версии 8.3.9 мы доработали механизм веб-сервисов (SOAP-сервисы, HTTP-сервисы, сервисы OData). В результате их производительность увеличилась примерно в 10 раз.
Мы проводили тесты на типовой конфигурации Бухгалтерия предприятия. В неё мы добавили HTTP-сервисы, выполняющие выборку из справочника Контрагенты. Тест заключался в том, что клиент выполнял последовательно 100 обращений к сервису. В старом режиме работы для этого потребовалось 29,9 с. В новых режимах работы в среднем 3 с.
Этих результатов удалось достичь за счёт того, что мы реализовали две различные стратегии, обеспечивающие переиспользование сеансов:
Автоматическое переиспользование сеансов из пула;
Управление сеансами с помощью HTTP-заголовков.
При автоматическом переиспользовании сеансов клиент не имеет возможности влиять на количество сеансов и время их жизни. Ему просто автоматически выделяется сеанс из существующего пула сеансов. Такая стратегия подходит для высоконагруженных публичных сервисов, к которым обращаются клиенты, выполняющие шаблонные операции, и обладающие унифицированными привилегиями.
Например, это может быть автоматизация торговой деятельности удаленных торговых точек, предусматривающая периоды пиковой нагрузки на сервер. Для обработки будет выделено нужное количество сеансов. Они будут завершены по мере падения нагрузки.
Другой пример это получение/помещение файлов в конфигурации Документооборот посредством http-сервисов. Для таких операций можно использовать одного и того же специального пользователя.
Стратегия ручного управления сеансами подразумевает, что клиент самостоятельно управляет количеством сеансов и временем их жизни. Эта стратегия лучше подходит для высокоинтегрированных систем в рамках одной организации. Вы можете реализовать собственный алгоритм, который будет управлять временем жизни сеансов и их количеством
NikeeNik; +1 Ответить
25. Dorosh 176 07.12.16 20:09 Сейчас в теме
(22) В (24) подробно описано. Первое обращение к сервису вызывает загрузку и инициализацию используемых библиотек. Оно всегда долгое и учитывать его в замере производительности неверно.
3. tormozit 7133 04.12.16 22:44 Сейчас в теме
Скриншоты за что так ужал? Не видно же текст.
gucci76; 2ncom; Риник; kolya85; Strannik777; Gendelf; Elvina; Drivingblind; binex; purgin; bow; +11 Ответить
4. Alien_job 190 05.12.16 06:26 Сейчас в теме
Эх, не дошли до самого интересного - до записи. Будете продолжать? Почему-то когда я читаю из базы документ, меняю в ответе один реквизит и пытаюсь записать, то в ответ возвращается всякая ерунда (обычно что не заполнена дата).
7. Dorosh 176 05.12.16 09:30 Сейчас в теме
(4) Запись будет в продолжении статьи.
8. vitaliy1911 38 05.12.16 12:29 Сейчас в теме
Для обработки ответов в JSON удобнее использовать метод ПрочитатьJSON объекта ФабрикаXDTO.
Интересно, каким должен быть HTTP-сервис, чтобы он НЕ удовлетворял принципам REST? Можете привести пример?
Не понятна формулировка "Должен быть клиент-серверным и не иметь состояния". А бывают веб-сервисы не клиент-серверные? Что значит "не иметь состояния"? Например, для выполнения длительных операций сервер сначала возвращает клиенту id операции, чтобы клиент мог периодически опрашивать сервис на факт выполнения этой операции — это можно считать состоянием?
9. Dorosh 176 05.12.16 12:53 Сейчас в теме
(8) Я скорее практик чем теоретик. Состояние реализуется элементарно, на глобальных переменных или РС. Если выполнение кода сервиса зависит от значения глобальной переменной, эта переменная хранит состояние сервиса.
15. Darklight 32 06.12.16 14:27 Сейчас в теме
(9)Глобальные переменные не подойдут - при работе с REST-Сервисом их нет. А хранение состояния в регистре сведений возможно - указано мной в (14), но это не то состояние, которое закладывается в определении REST-Сервиса
10. Darklight 32 05.12.16 17:20 Сейчас в теме
(8)HTTP-Сервис - это чуть более широкое понятие, чем HTTP REST-сервис, который имеет обязательное условие унификации форматов запросов и ответов для всего решения. А самое главное, REST-сервис по определению не должен хранить состояния ( и, т.к. за его исполнение отвечает сама платформа 1С, то она не хранит эти состояния) - нельзя начать какую-либо сессию и потом выполнять REST-запросы в рамках её состояния (а HTTP-сервис такое, в общем-то, может позволить). Тут вся главная фишка именно в том, что REST-сервисы создаёт сама платформа, подчиняя их встроенному в платформу унифицированному формату. И не нужно ничего кодить в источнике REST-сервиса, чтобы обращаться к нему. REST-сервисы это как-бы язык запросов: так же как Вы обращаетесь к СУБД за получением каких-либо данных (или их изменения), так же через происходит взаимодействие через REST - и там и там платформа/СУБД универсально обрабатывает поступившие запросы и возвращает результаты. Один запрос - один результат/действие (пакетных REST обращений не бывает). Соответственно REST-сервис никак не может запустить длительную операцию, а потом её опрашивать. Запустили, получили данные, вернули, завершились.

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

REST-Безусловно найдёт своё "место под солнцем" в 1С, скорее у HTTP-сервисов в 1С не так уж много перспектив. Впрочем, сейчас сони вполне могут дополнять REST-сервисы, там, где они ограничены.
13. vitaliy1911 38 06.12.16 09:27 Сейчас в теме
(10) можете раскрыть смысл термина "состояние"? что вы в него вкладываете?
14. Darklight 32 06.12.16 14:18 Сейчас в теме
(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 -Соединения, или иного сетевого соединения с другим ресурсом (в сети, интернете, или файлом); или оборудованием (подключенном через компоненту). Для многих задач хавтит и описанного способа, но не для всех.
16. Darklight 32 06.12.16 17:12 Сейчас в теме
(14) Вспомнил, что у ряда объектов метаданных (связанных с хранением данных) есть события изменения данных (в самих объектах и в приписках на события). В описании REST-Сервисов про них не сказано, но надо полагать они буду срабатывать, при изменении данных через REST. Соответственно, в предложенном мной примере запуска фонового процесса через REST-сервис регл. задании лишнее - если, скажем в модуле набора записей указанного в (14) регистра сведений в событии "ПриЗаписи" разместить алгоритм, который сам будет запускать фоновые задания, то фоновый процесс будет сразу же запускаться после окончания записи в регистр сведений через REST-вызов. Далее достаточно лишь опрашивать через REST регистр сведений с результатом (по тому же ключу).
Формально, состояние клиента есть, и оно хранится в базе данных (получается по ключу, который сформировал клиент в первом обращении), как и есть возможность периодически опрашивать сервер, для получения промежуточных или итоговых данных.
17. Serginio 938 06.12.16 17:42 Сейчас в теме
(16) Вот здесь решали http://www.forum.mista.ru/topic.php?id=785017

Там не только подписки, но и выполнение на сервере итд.
И делать проверку модулей с галками внешнее соединение, сервер
18. Darklight 32 07.12.16 10:20 Сейчас в теме
(17) Там один какой-то срач от неправильного применения REST, до неправильно написанных конфигураций 1С.
А вот стыбзенная мистой (или Вами переложенная на мисту) Ваша публикация LINQ to oDATA интересна, хоть и очень коротка (но это уже немного о другом)!
19. Serginio 938 07.12.16 12:09 Сейчас в теме
(18) Ну я постарался описать возможность использования и дал ссылочки на использовании компонент .Net.
Сам я её не использую. Но смотрю многие стали интересоваться.
У меня есть еще одна статья про .Net Core .Net Core, WCF и ODATA клиенты
33. Dementor 1014 03.12.17 20:49 Сейчас в теме
(10)
До не давних пор WEB-Сервисы в 1С не имели возможности хранить состояния сеанса (теперь могут)

Видимо я что-то пропустил. О каких состояниях сеанса, которые хранятся на сервере между клиентскими вызовами, вы говорили? Если о возможности реализовать собственные состояния на базе РС, то такая возможность была в платформе изначально. А про возможность устанавливать значения параметрам сеанса или создавать глобальные переменные, значения которых не будут пропадать между вызовами, я что-то не слышал.
34. Darklight 32 04.12.17 11:25 Сейчас в теме
(33)Вот тут была инфа.
Там всё очень расплывчато. Хотите - поищите ещё, т.к. это ещё год назад появилось, может есть более толковые статьи на эту тему. Лично сам не проверял :-(
35. Dementor 1014 04.12.17 14:16 Сейчас в теме
(34) спасибо. Разобрался с заголовком IBSession. Не для массового использования, но некоторые задачки интеграции закрыть можно. В принципе все понятно, нужно бы только на каком-то тестовом примере опробовать, прежде чем брать в реальную работу...
36. Darklight 32 04.12.17 14:22 Сейчас в теме
(35)Когда окончательно разберётесь и опробуете на практике - напишите на инфостарте статью - будет Вам плюсик в карму.
20. Region102 07.12.16 13:33 Сейчас в теме
Вообще использование web сервисов для меня это массовость, т.е. ты пишешь какой-то проект на web, а базу 1с используешь как backend. И тут вырисовывается проблема, при этом очень большая, каждое соединение через REST сервис съедает одну лицензию, если не ошибаюсь. Поэтому хорошие люди пишут свои костыли типа metadata.js, реализуя фактически легкий web клиент для высоко нагруженных сервисов обходя проблему лицензирования и не совсем web интерфейса тонкого клиента.
26. premierex 204 10.12.16 12:55 Сейчас в теме
(0) Автор, а почему код ответа больше 299 Вы считаете кодом ошибки?
Вот, например описание кодов ответов более 299:
3xx: Redirection (перенаправление):
300 Multiple Choices («множество выборов»)[2][6].
301 Moved Permanently («перемещено навсегда»)[2][6].
302 Moved Temporarily («перемещено временно»)[2][6].
302 Found («найдено»)[6].
303 See Other (смотреть другое)[2][6].
304 Not Modified (не изменялось)[2][6].
305 Use Proxy («использовать прокси»)[2][6].
306 — зарезервировано (код использовался только в ранних спецификациях)[6].
307 Temporary Redirect («временное перенаправление»)[6].
Эти коды вполне можно тоже обрабатывать. Если сервер сделал redirection, это не значит, что он ваш запрос не обработал или выдал предупреждение об ошибке. В HTTPОтвете, с таким кодом ответа в параметре location, если я не ошибаюсь, должен содержаться URL перенаправления.
27. sansys 76 07.01.17 12:08 Сейчас в теме
Очень познавательная статья, пошёл экспериментировать. +1
28. nodalt 9 18.01.17 17:09 Сейчас в теме
Спасибо за статью.
В тексте:
Получать ответы можно в различных форматах, но пока платформа поддерживает только работу с данными в формате Atom/XML
- вот тут не понял. Ответ же можно получить в формате JSON. Собственно, это далее и демонстрируется ...
29. Alex1Cnic 148 24.01.17 08:18 Сейчас в теме
Мне понравилось, написано просто и ясно, ждем продолжения....
30. DoctorRoza 26.01.17 12:11 Сейчас в теме
31. kiruha 388 07.02.17 14:57 Сейчас в теме
А где посмотреть полную справку по запросам Rest в 1С ? Во встроенной справке не вижу.
32. kiruha 388 07.02.17 15:05 Сейчас в теме
+ интересует скорость такого обмена по сравнению с аналогичными веб сервисами
37. user1522511 13.01.21 16:42 Сейчас в теме
"Создание и изменения объектов через REST будет в следующей части."

А когда будет следующая часть ???

Очень надо !
38. cdiamond 233 21.01.22 20:26 Сейчас в теме
(37) Статья эта мутная, только запутывает и уводит от сути вопроса, особенно касательно работы 1С.
Для тех кто дочитал комменты разъясняю на пальцах:
В 1С есть два объекта конфигурации: web-сервисы и http-сервисы. Первый - это реализация сильно устаревшего протокола SOAP, которая наглухо привязана к устаревшему формату обмена XML, довольно избыточна и трудоёмка в реализации. Забудьте уже про него.
Второй (http-сервисы) это и есть современная основа для реализации REST API протокола, которая вообще не привязана к формату данных, можно использовать хоть простой текст, хоть XML, но лучше всего сериализовать данные в JSON. Этот протокол можно использовать для связи с любой другой системой, даже с проектом на Kubernetes.
Далее. Одна сторона вызывает по http, а вторая этот запрос принимает. Неважно какая сторона сервер, данные можно передавать в любом направлении в одном вызове. Просто когда хочешь предать данные на сервер кладешь свой JSON в тело запроса, а написанный тобой код на сервере примет его, распарсит обратно например в массив структур и создаст объекты если надо. А если хочешь получать от сервера, то кидаешь пустой запрос по адресу REST API, сервер примет его, код в модуле сервиса сделает запрос к базе данных и сформирует ответ в JSON, который ты получишь на клиенте как ответ от сервера. Вот тебе и двусторонний обмен, никаких ограничений нет ни по формату ни по направлению, никаких там блокировок про которые тут кто-то писал, всё поведение зависит полностью от тебя, как напишешь так и полетит.
И наконец про методы GET, POST, DELETE. Это все наследие протокола HTTP, для работы REST API достаточно всего двух методов GET и POST, сами эти названия никакой смысловой нагрузки не несут, их конкретное действие зависит от реализации протокола на стороне сервера. Можете на метод DELETE повесить создание объекта, а методом GET чистить таблицы. С технической точки зрения вообще достаточно одного метода POST на все случаи жизни.
harin66; BBAlien; Rokov; ivlog; janit; gucci76; fxmike; 24rus; user834072; smirnovserg.s@gmail.com; +10 Ответить
Оставьте свое сообщение