Web и http сервисы 1с в чем разница
Обновлено: 06.07.2024
Знаю, что на хабре не очень-то жалуют многострадальную 1С. Хотя, с выходом платформы 8.3 (с клиентами под Linux), ее стали любить несколько больше. Кстати, так же, совсем недавно интерфейс одной из основных разработок 1С – конфигурация Управление производственным предприятием – был полностью переведен на английский язык. Много раз я встречал вопросы о том, почему здесь не пишут об 1С. Ответ на них довольно очевиден – существует множество специализированных ресурсов, где можно оперативно обсудить все вопросы и что-то почитать.
Есть все основания полагать, что эта статья здесь не выживет, но я все же рискну, потому что в 1С есть некоторые интересные вещи, о которых стоит рассказать.
С некоторых пор в 1С 8.х появилась возможность использования веб-сервисов: 1С может выступать как поставщиком, так и потребителем. В этой статье я покажу, как использовать 1С в качестве потребителя на примере получения курсов валют с сервера ЦБР.
Веб-сервис
Конфигурирование
Для разработки я взял 1С 8.2 (8.2.15.317 в моем случае) и создал пустую конфигурацию. Для использования внешних веб-сервисов предусмотрен объект WS-ссылки, но использовать его не обязательно, к сервису можно обращаться динамически из кода. Я буду использовать первый вариант, а затем покажу, как можно использовать второй. В конфигурации создал обработку и назвал ее «ЗагрузкаКурсовВалютЦБР». Добавил форму (управляемую) и сделал ее основной. На форме я создал реквизиты и разместил элементы управления так, как показано на рисунке.
1С на основании полученного описания автоматически создаст визуальную карту веб-сервиса. Можно увидеть название веб-сервиса, посмотреть какие у него доступны операции а так же используемые типы данных.
Конфигурирование на этом почти закончено, осталось сделать пару штрихов для того, чтобы наше приложение выглядело более эстетично. Кликнем правой кнопкой мыши по корню конфигурации и вызовем меню «Открыть командный интерфейс рабочего стола». В появившемся окне необходимо снять флаг «Видимость» напротив обработки «Загрузка курсов валют ЦБР». Нажмем кнопку Ок. Далее еще правый клик по корню конфигурации и вызовем меню «Открыть рабочую область рабочего стола», там сделаем настройку как на рисунке:
Эти настройки позволят нам отобразить форму обработки прямо на рабочем столе (имеется ввиду рабочий стол программы 1С) в режиме 1С Предприятие.
Программирование
Теперь осталось наполнить смыслом нашу обработку: заставить ее получать курсы валют и отображать в таблице на форме. В режиме редактирования формы необходимо добавить новую команду формы, назовем ее ЗагрузитьВалюты. Эту команду необходимо связать с кнопкой, расположенной на форме. Действие для команды заполним следующим кодом (прим. автора: ничего себе, на хабре есть подсветка кода 1С, правда она работает не корректно):
Здесь сначала проверяется, заполнена ли дата (если не заполнена, то сообщаем об этом пользователю и больше ничего не делаем). Затем очищается таблица, расположенная на форме и вызывается процедура ЗагрузитьКурсыВалют(), в которую передается дата.
Код процедуры ЗагрузитьКурсыВалют(), пояснения данны в комментариях к коду:
Теперь можно обновлять конфигурацию БД (F7) и запускать 1С Предприятие (F5). Если все сделали верно, то должны увидеть окно как на рисунке ниже:
Чтобы проверить результат, нам нужно ввести дату, на которую хотим получить курсы валют и нажать на кнопку «Загрузить валюты». В случае успешного запроса, таблица на форме заполнится значениями курсов:
Напоследок хочу показать, как можно обратиться динамически к внешнему веб-сервису, то есть без добавления объекта WS-ссылка. Таким образом, мы можем использовать такие веб-сервисы из внешних обработок без привязки к конфигурации.
В процедуре ЗагрузитьКурсыВалют() строку
необходимо заменить двумя следующими строками
Сначала мы создаем так называемые определения для веб-сервиса из его WSDL. Затем так же создаем прокси для обращения к нему.
Как видно, использовать внешние веб-сервисы из 1С в целом довольно просто (хотя и есть некоторая сложность в понимании определения типов, у меня в том числе).
Если данная публикация найдет здесь отклик, то есть еще несколько тем, о которых можно рассказать.
В интернете полно всяких описанных случаев, каких хочешь.Чтобы работник опознавался автоматически нужно на клиенте в обозревателе оставлять печеньки :)
А все остальное вкусовщина. Так что разница просто в документации и в ее способе передачи :)
(3)Конечно не будет отличатся если смотреть очень издалека. Издалека и мальчик от девочки не отличается - человек же.(5) вы меня прям заинтриговали. Чем же принципиально отличаются эти технологии? Кроме того, что соап дает всдл, в котором описаны типы и функции,а для хттп - надо описывать отдельно это все, и обычно юзают фигнб разную типа свагера для этого.
А теперь мы возьмем реальные нагруженные проекты, где вам валются бинарники на вход (типо зипы, или base64bin), а не голый хмл.
Внимание, вопрос - чем хттп отличается от соапа в данной случае?
Как всегда дьявол кроется в деталях.
Понятно желание автора опубликовать свой опыт, но даже на этом ресурсе прилично материалов с которыми можно состыковаться.
Оочень большие картинки, в которых немного толку.
Что хотели показать первой схемой? То что 1С есть другие веб серверы которые умеют работать с СУБД? Обычно такая же трехзвенка, и NGINX/Apache используют сокеты/сервисы а конкретном языке программирования.
"Такая страничка с двумя полями уже может передавать данные на внешний HTTP сервис: " - описание формата запроса который прилетает в сервис нет.
Откройте для себя тег CODE редактора, в статье еще можно указать язык, для адекватной подсветки (касается и примеров кода на 1С)
"Вот пример документации. Заголовок, ответ, пример, описание полей данных:" - откройте для себя OpenAPI с переиспользованием в тестах postman например.
"Когда отправляем партнеру ответ, пишем в лог." - в каком формате ведете лог?
"это разделение методов обработки самого HTTP запроса и методов обработки данных, которые являются методами бизнес-логики." - возможно дойдете до одной точки входа в сервис и предобработки запроса, наработки по этой теме есть в двух статьях.
Оформите ссылку на код нормально, например на репо github.
Прошлись по верхам, получилась маркетинговая статья.
Irwin; kirillkr; Yashazz; litonchik; dreamadv; alexeyo51; igo1; CSiER; artbear; vano-ekt; rpgshnik; Drivingblind; ardn; + 13 – Ответить (4) Дык это и есть сбор хайпа и плюсиков - позиционируется как "обзор" или "для новичков" в зависимости от характера упрёков авторам, а реальная полезность весьма низкая. Увы.* Неопытность автора в данном вопросе следует из отсутствия предваряющего все "коллекции" указания версии. Т.е. грамотно д.б. так: GET/v213/orders/ и т.п.
* Из предыдущего следует, что обработка методов разных версий будет различаться.
* Обязательно должен существовать тестовый стенд новых версий, чтобы партнёры могли выполнять адаптацию и тестирование своих КИС на готовность к новой версии.
* Новые версии апи должны проходить как минимум одну неделю на тестовой среде для возможности партнёрам адаптировать свои системы.
* Должна существовать рассылка с добровольной подпиской на неё о новых версиях апи, чтобы партнёры могли поймать момент, когда вы инициируете процесс выкатки новой версии апи.
* Упоминаются входящие данные в типе структуры и вопрос валидации данных. Это взаимосвязанные вещи и решаются они использованием пакетов XDTO и объектной модели данных - не колхоз из структур и массивов, а объекты XDTO.
* Все объекты XDTO д.б. тщательным образом описаны в пакете. Где есть явные ограничения на значения, везде надо их указывать отдельно в типах XDTO, чтобы точнее валидировать входящие и исходящие данные.
* Почему-то автор избегал упоминания такого распространённого продукта как swagger. Он как раз предназначен для документирования апи и очень удобен для любых платформ партнёров.
И я бы обратил внимание, что GET-запросы уместны только в случае ограниченных данных. Если же вы хотите получить статус по списку заказов, то этот список может не влезть в 4К(зависит от веб-серверов) поля QUERY запроса. Очень хорошо, что вы понимаете изначальную суть GET и POST запросов и разницу между ними, но на текущий момент (кажется, в вики это описано) они утратили изначальный смысл. Обычно все используют запросы POST и информация из QUERY перемещается в BODY запроса в формате json. Там нет ограничений на объём. Попробуйте, это удобнее.
Написав пару простейших Get-запросов я отлаживал их на опубликованной на веб-сервере IIS файловой базе, набирая адрес запроса в адресной строке.
При этом нужно помнить, что нужно указать авторизацию, причем имя пользователя на русском этот сайт не понимает, завел пользователя на английском:
В адрес я ввожу адрес POST-запроса, выбираю метод POST, ввожу содержимое запроса (JSON) после чего нажимаю SEND и получаю ответ (JSON) в правом окошке.
//Устанавливаем тело из JSON-строки
Ответ . УстановитьТелоИзСтроки ( СтрокаДЖ );
Однако по странному изгибу мысли заказчика у меня возникла проблема. Дело в том, что создание заказа выполнялось через часть URL post, а изменение заказа через часть URL post/guid.
Т.е. если раньше у меня был один шаблон URL на каждый метод, тут пришлось сделать два шаблона и я не сразу понял, как это должно выглядеть. Но потом догадался, в итоге вышло так:
orderCreate имеет шаблон /order, а orderWork имеет шабон /order/. Изначально я все это пытался впихнуть в один шаблон order, не вышло.
Соответственно, для отладки PATCH-запросов я использую тот же сайт, только выбираю метод PATCH.
Со временем я столкнулся с ошибкой, которую не смог выявить без отладки, поэтому написал небольшую обработку, где вводил JSON-текст запроса, а она уже имитировала вызов метода сервиса:
&НаКлиенте
Процедура APIСозданияЗаказа ( Команда )
APIСозданияЗаказаНаСервере ();
КонецПроцедуры
Если вы ничего не понимаете в WEB технологиях и такие слова, как json, get, post и прочее для вас ничего не значат и вы просто заядлый 1С-ник до мозга костей, но вам кровь из носу надо подружить 1С со сторонними приложениями или сайтом, то эта статья для вас.
Начну с того, что когда-то я был вынужден самостоятельно разбираться с Web-сервисами. Тогда как-то потихоньку мне удалось освоить это дело и понять, что и куда надо нажать, чтобы все заработало. Благо конфигурация, с которой пришлось работать, уже была напичкана Web-сервисами и можно было подглядеть и сделать по аналогии, а также в интернете мне удалось найти достаточно статей по этому делу. И так, на примерах (для меня это лучший способ изучения), я освоил это дело, и теперь меня они уже не пугают.
Уж не знаю, можно ли тут писать кириллицей, но чтобы вас в прогрессивном мире не засмеяли, пишите латиницей).
Дальше переходим на закладку Шаблоны URL и добавляем новый шаблон.
Тут важно само свойство Шаблон:
С помощью шаблона вы впоследствии сможете обратить к тем данным, которые вам передали. ИТАК: все данные, которые вы хотите получить извне, можно разделить на 2 блока - обязательные и не обязательные.
Обязательные данные/параметры запихиваем в шаблон, тем самым если тот, кто обращается к сервису, их не заполнил, то сервис априори выдаст ошибку, а вы при разработке текста модуля обработчика будете уверены, что эти данные есть. Как это делается: в строке Шаблон в фигурных скобках "<>", чередуя с со знаком "/", пишем имена переменных. Например, нам обязательно нужен артикул - тогда пишем /. Если нам надо получить артикул, имя и имя пользователя, строка шаблона будет выглядеть так: /// и т.д. Каждый из таких параметров в тексте модуля обработчика можно будет получить так: Запрос.ПараметрыURL["<имя параметра>"]. Если обязательных нет, то шаблон выглядит так: /*.
Не обязательные данные, которые мы хотим получать через сервис, в шаблоне НЕ описываются. При построении ссылки, для обращения к сервису они описываются в конце ссылки после знака "?", разделяются символом амперсанда "&" и имеют структуру <имя параметра>=<значение параметра>. В тексте модуля обработчика к ним можно обратиться конструкцией: Запрос.ПараметрыЗапроса.Получить("<имя параметра>"). НО: важно помнить, раз они не обязательны, то их может и не быть, соответственно значение проверяем на Неопределено.
Администрирование - Публикация на веб сервере.
Читайте также: