Как отправить soap запрос через браузер
Описанный метод позволяет обратиться к веб-сервисам 1С из html-страницы через JavaScript. В качестве примера выводится список справочников. При нажатии на любой справочник выводятся первые буквы наименований. При нажатии на букву выводятся данные с наименованиями, начинающимися на эту букву.
Способ применим для случаев, когда веб-сервис и html-страница опубликованы на одном сервере. В этом случае не возникает кросс-доменных проблем. Например, если домены будут отличаться, то Chrome выдаст ошибку:
Failed to load resource: Origin localhost:3299 is not allowed by Access-Control-Allow-Origin
Не вдаваясь в подробности публикации веб-сервисов, предположим, что на стороне 1С создан и опубликован веб-сервис catalogs с операцией Execute. На входе — параметр script типа string, на выходе тип string. Операция запускает на стороне произвольный код script из параметра и возвращает JSON-сериализацию от переменной result.
С JSON-сериализацией удобно работать средствами JavaScript и преобразовать строку в объект/массив одной командой eval(resultText). В Интернете можно найти несколько JSON-сериализаторов для 1С.
Удостоверимся, что веб-сервис отвечает, введя его адрес:
На форме сверху разместим элементы настройки веб-сервера: wsUrl — адрес веб-сервиса, wsUser — логин, wsPassword — пароль. На стороне веб-сервиса 1С включена basic autherization. Логин и пароль соответствуют пользователю, прописанному в 1С.
Левая панель отвечает за отображение доступных справочников catalogsList, правая — за отображение букв (letters) и данных (catalogRecords).
JavaScript
Функция обращения к SOAP веб-сервису определена следующим образом:
Получение списка наименований каталогов.
Получение первых букв наименований справочника
Получение данных для каталога , где первая буква входит в условие .
При нажатии на кнопку Обновить происходит вызов функции
и при успешном выполнении вызывается обработчик processSuccess
Веб-сервис возвращает xml, где значимым является содержимое m:return-тэга — JSON-сериализация. Перевести его в объекты JavaScript можно через eval-вызов. Обработчик очищает перечень справочников и заново его формирует через li-тэги с атрибутом catalog. Каждому элементу устанавливается класс catalogTitle.
Веб-сервис возвращает xml, где значимым является содержимое m:return-тэга — JSON-сериализация. Перевести его в объекты JavaScript можно через eval-вызов. Обработчик очищает перечень справочников и заново его формирует через li-тэги с атрибутом catalog. Каждому элементу устанавливается класс catalogTitle.
Аналогично обрабатываются нажатия на все управляющие элементы. Нажатие на справочник очищает буквы и данные, перезаполняет буквы. Нажатие на букву перезаполняет данные из справочника. За обработку кода на 1С отвечают куски кода в script-блоках с типом «text/1c».
Приложение выглядит так:
Нерешенная проблема авторизации на браузере IE
Существует проблема авторизации на IE. На IE 8/9 не удалось решить проблему basic authorization аналогичным для остальных браузеров методом.
На IE Ajax не работает с использованием user/password — свойств $.ajax. На FF и Chrome все работает нормально. По какой-то причине на сервер в случае с IE не передается заголовок
Authorization: Basic 0JHQsNGF0YjQuNC10LLQn9CYICjRgNGD0LrQvtCy0L7QtNC40YLQtdC70YwpOg==
Если кто-нибудь знает причину и как обойти, пожалуйста, напишите в комментариях.
Выводы
Предложенный подход на основе SOAP имеет право на существование для несложных задач, так как сопровождается достаточно большим числом JavaScript кода. Возможно, в будущем удастся создать JavaScript фреймворк для упрощения процесса создания приложений.
Разработчики в этом способе самостоятельно отвечают за безопасность. Необходимо проверять входные параметры при записи, не позволять запуск произвольных скриптов, переданных с клиента. В статье выполнение произвольного кода показано только для примера. Унифицировать можно выполнение произвольного запроса, но это связано с опасностью SQL-инъекций.
Внешние компоненты Native API от 1С не будут работать в данной среде. Это значит, что нужно дополнительно решать проблему с написанием драйверов для оборудования.
Описанный метод позволяет обратиться к веб-сервисам 1С из html-страницы через JavaScript. В качестве примера выводится список справочников. При нажатии на любой справочник выводятся первые буквы наименований. При нажатии на букву выводятся данные с наименованиями, начинающимися на эту букву.
Описанный метод позволяет обратиться к веб-сервисам 1С из html-страницы через JavaScript. В качестве примера выводится список справочников. При нажатии на любой справочник выводятся первые буквы наименований. При нажатии на букву выводятся данные с наименованиями, начинающимися на эту букву.
Способ применим для случаев, когда веб-сервис и html-страница опубликованы на одном сервере. В этом случае не возникает кросс-доменных проблем. Например, если домены будут отличаться, то Chrome выдаст ошибку:
Не вдаваясь в подробности публикации веб-сервисов, предположим, что на стороне 1С создан и опубликован веб-сервис catalogs с операцией Execute. На входе - параметр script типа string, на выходе тип string. Операция запускает на стороне произвольный код script из параметра и возвращает JSON-сериализацию от переменной result.
С JSON-сериализацией удобно работать средствами JavaScript и преобразовать строку в объект/массив одной командой eval(resultText). В Интернете можно найти несколько JSON-сериализаторов для 1С.
Удостоверимся, что веб-сервис отвечает, введя его адрес:
На форме сверху разместим элементы настройки веб-сервера: wsUrl - адрес веб-сервиса, wsUser - логин, wsPassword - пароль. На стороне веб-сервиса 1С включена basic autherization. Логин и пароль соответствуют пользователю, прописанному в 1С.
Левая панель отвечает за отображение доступных справочников catalogsList, правая - за отображение букв (letters) и данных (catalogRecords).
JavaScript
Функция обращения к SOAP веб-сервису определена следующим образом:
Получение списка наименований каталогов.
Получение первых букв наименований справочника
Получение данных для каталога , где первая буква входит в условие .
При нажатии на кнопку Обновить происходит вызов функции
и при успешном выполнении вызывается обработчик processSuccess
Веб-сервис возвращает xml, где значимым является содержимое m:return-тэга - JSON-сериализация. Перевести его в объекты JavaScript можно через eval-вызов. Обработчик очищает перечень справочников и заново его формирует через li-тэги с атрибутом catalog. Каждому элементу устанавливается класс catalogTitle.
Веб-сервис возвращает xml, где значимым является содержимое m:return-тэга - JSON-сериализация. Перевести его в объекты JavaScript можно через eval-вызов. Обработчик очищает перечень справочников и заново его формирует через li-тэги с атрибутом catalog. Каждому элементу устанавливается класс catalogTitle.
Аналогично обрабатываются нажатия на все управляющие элементы. Нажатие на справочник очищает буквы и данные, перезаполняет буквы. Нажатие на букву перезаполняет данные из справочника. За обработку кода на 1С отвечают куски кода в script-блоках с типом "text/1c".
Приложение выглядит так:
Нерешенная проблема авторизации на браузере IE
Существует проблема авторизации на IE. На IE 8/9 не удалось решить проблему basic authorization аналогичным для остальных браузеров методом.
На IE Ajax не работает с использованием user/password - свойств $.ajax. На FF и Chrome все работает нормально. По какой-то причине на сервер в случае с IE не передается заголовок
Authorization: Basic 0JHQsNGF0YjQuNC10LLQn9CYICjRgNGD0LrQvtCy0L7QtNC40YLQtdC70YwpOg==
Если кто-нибудь знает причину и как обойти, пожалуйста, напишите в комментариях.
Выводы
Предложенный подход на основе SOAP имеет право на существование для несложных задач, так как сопровождается достаточно большим числом JavaScript кода. Возможно, в будущем удастся создать JavaScript фреймворк для упрощения процесса создания приложений.
Разработчики в этом способе самостоятельно отвечают за безопасность. Необходимо проверять входные параметры при записи, не позволять запуск произвольных скриптов, переданных с клиента. В статье выполнение произвольного кода показано только для примера. Унифицировать можно выполнение произвольного запроса, но это связано с опасностью SQL-инъекций.
Внешние компоненты Native API от 1С не будут работать в данной среде. Это значит, что нужно дополнительно решать проблему с написанием драйверов для оборудования.
Disclaimer: Статей на эту тему написано очень много и, как вы, конечно, догадались, это очередная. Возможно, вы узнаете из неё что-то новое, но ничего сверхсекретного, что нельзя было бы нагуглить самостоятельно, здесь не описано. Только заметки из личного опыта.
Вступление
Рассматривать будем только ситуацию, когда есть сторонний web-сервис и стоит задача наладить обмен данными.
Строение сервиса описывается в файле WSDL (англ. Web Services Description Language)
Файл чаще всего доступен по ссылке, где находится точка входа в сам web-сервис. Я написал «чаще всего», так как бывают исключения. Например, Web-сервис на базе SAP не публикует wsdl и его можно получить только выгрузив из самого приложения.
И так, у нас есть описание web-сервиса, логин, пароль. Давайте подключимся.
Отлично! Мы подключились к web-сервису! По идее это основа любого варианта обмена, так как позволяет создавать объект структуры данных на основании wsdl, а работать с таким объектом одно удовольствие.
Рассмотрим XML который нам выдает SoapUI
Теперь опишем его программно
В этот самый момент и возникает множество нюансов. Попробуем рассмотреть каждый.
Рецепт 1. Отправляем XDTO-объект целиком
Остается лишь обработать результат, который нам вернул сервис и на этом всё. Согласитесь, что это очень удобно!
Но на практике не всегда бывает так. Например 1с не ладит с префиксацией определенных тэгов внутри xml, когда пространство имен корнеового тэга отличается от пространства дочерних. В таких случаях приходится собирать soap вручную. Так же приходилось сталкиваться с web-сервисами, которые в качестве параметра ждут xml в чистом виде. Маразм, но все же делается это не слишком сложно.
Рецепт 2. Отправляем чистый xml в качестве параметра
Если не удалять пространство имен, которое 1с добавляет по умолчанию, то стало больше всего на 5 строк кода. Чаще всего я заворачиваю преобразование xml в функцию, так как обычно вызываем более одного метода.
В этом варианте нам придется собрать soap вручную. По сути мы просто оборачиваем xml из рецепта 2 в оболочку soap, где в зависимости от требований web-сервиса мы можем менять наш soap как душе угодно.
Далее описываем заголовки согласно документации. Некоторые сервисы спокойно прожуют наш запрос и без заголовков, тут надо смотреть конкретный случай. Если вы не знаете какие заголовки прописывать, то самый простой способ это подглядеть запрос в SoapUI переключившись во вкладку RAW.
Функция получения Base64 строки выглядит так (подсмотрел здесь):
Здесь по сути тоже самое, что и в предыдущем варианте, но работаем с COMОбъектом. Строку соединения указываем полностью, вместе с протоколом. Особое внимание следует уделить только флагам игнорирования ошибок SSL-сертификатов. Они нужны, если мы работаем по SSL, но без определенного сертификата, так как создать новое защищенное соединение в таком варианте не предоставляется возможным (или я не умею как). В остальном механизм схож с предыдущим.
На данный момент это все рецепты, что у меня есть. Если столкнусь с новыми, то обязательно дополню статью.
Обработка результата
В рецепте 1 мы чаще всего получаем готовый XDTO-объект и работаем с ним как со структурой. Во всех остальных случаях можно преобразовывать xml-ответ в XDTO
Вместо заключения
1. Начинайте работу с web-сервисами с программы SoapUI. Она предназначена для таких работ и позволит быстрее понять как работает тот или иной сервис. Для освоения есть статья про SoapUI.
4. Если вас пугает XDTO, то рекомендую ознакомится с циклом статей злого бобра Андрея XDTO - это просто.
5. Если аутентификация предполагает использование Cookie, то нашлась следующая статья.
P.S. Если у вас появились вопросы, предложения по улучшению кода, есть собственные рецепты, отличные от описанных, вы нашли ошибки или считаете, что автор "ниправ" и ему "не место в 1с", то пишите комментарии, и мы все обсудим.
UPD:
1. Добавил по просьбе join2us XML, который выдавал SoapUI
2. Исправил ошибки найденные пользователем VasilVtoroy
I would like to send a number to a SOAP "server"(I don't know if I can call it a server, correct me if I'm wrong) and receive a response using HTML, I've seen many questions with answers containing examples of sending an XML request such as below, but I have no idea on how to receive and see a response on HTML, sorry I'm new to SOAP.
P.S.: Of course, by HTML I meant JavaScript within the HTML :P
Thanks in Advance!
SOAP's XML from my server
1 Answer 1
Well, a SOAP server is designed to receive SOAP requests and send SOAP responses.
Since SOAP is basically XML, instead of expecting an HTML response from the server, it would be more appropriate to look for a mean to parse the XML of the SOAP response and display it in HTML.
But as I'm typing this answer, I think you may have misunderstood the goal of a SOAP server. It seems to me that you want to display the raw SOAP response directly to the client browser. But a SOAP server is not intended to work that way.
Let's take an example. I want to know the weather forecast of my city for tomorrow. I go to dummyweatherforecast.com and type the name of my city in the search field. But dummyweatherforecast.com does not store all the weather forecasts by itself. It may instead contact a SOAP server (specifically designed to provide weather forecasts) with a SOAP request containing the name of my city. The SOAP server returns a SOAP response with different weather information (sunny/cloudy, temperature, etc.) and then dummyweatherforecast.com processes this SOAP response (that is, as a reminder, XML) to display it to the client with a beautiful sentence like "It will be sunny tomorrow, with 86°F. Take your swimsuit !" ornamented with a beautiful sun iconography.
As you see, the client doesn't even know that a SOAP communication is held between dummyweatherforecast.com and the SOAP server. And this how SOAP is used : by servers themselves, and rarely directly by clients. This is what we call "web services", even though this term refers to a more general set of technologies used to make computers talk to each others.
I hope this brightened your mind a little bit.
PS : by the way, the link you give for your server points to an IP not available publicly (192.168 adresses are for private networks).
Давайте рассмотрим на примере, который вы можете прямо сейчас взять и повторить. Показывать я буду на системе Users, которая находится в открытом доступе. А запросы будем посылать через бесплатный инструмент Soap Ui.
1. Запустить Soap Ui.
2. File — New SOAP Project
5. Развернуть проект по кнопочке «+» слева от названия → мы увидим все методы, которые можно вызывать.
6. Выберем, например, метод регистрации — doRegister. Разворачиваем его: Soap Ui при чтении WSDL сам создает базовый запрос на каждый метод. Смотрим, что внутри Request 1
Проверяем, что такого пользователя пока не существует |
Отправляем запрос |
О, ответ
Не верим ответу по API. проверяем в системе |
Вставили в Soap Ui WSDL-ку, и инструмент сам сгенерил нам реквесты. Выбираем любой, заполняем, отправляем! А главное — вы можете прямо сейчас повторить все то же самое (разве что другие емейл и имя пользователю дать, уникальные). Круто же? 5 минут назад впервые услышал про SOAP-запросы, а тут Р-р-р-раз, и отправил первый запрос
См также:
Освоение тестирования SOAP API — полезная статья с более подробным описанием, что такое WSDL, XSD, и других страшных слов ツ
А от меня еще пара заметок по инструменту из серии HOWTO
Авторизоваться
Это Users — открытая система. У вас в компании наверняка API будет скрыто под паролем. Для указания авторизации слева внизу запроса нажмите Auth → раскройте выпадающий список → Add New Authorization → Basic → и там уже вводите логин и пароль.
Так добавлять авторизацию |
Это добавит авторизацию на уровне одного конкретного запроса. Если запросов много и разных, можно настроить авторизацию глобально для всего проекта — слева внизу Properties
Читайте также: