Как отправить soap запрос через браузер

Обновлено: 07.01.2025

Компонент позволяет взаимодействовать с внешним SOAP-сервисом, отправляя ему запросы и получая ответы. SOAP-сервису может быть отправлено несколько последовательных запросов, формируемых из строк входной таблицы с параметрами запросов. На выходных портах обработчика формируются таблицы с ответами сервиса, возвращенными ошибками и дополнительными данными. XML-ответы сервиса преобразуются в табличное представление.

Поддерживаются описание SOAP-сервисов спецификации WSDL 1.1 и протоколы SOAP версий 1.1 и 1.2.

Для работы с SOAP-сервисом необходимо настроенное подключение к SOAP-сервису.

Порты

— Подключение к SOAP-сервису (связь с компонентом Подключение SOAP-сервиса);
— Источник данных запроса (таблица с параметрами запроса), необязательный;
— Управляющие переменные (переменные), необязательный.

Выходные порты

— Выходной набор данных (таблица с ответами SOAP-сервиса);
— Исключения (WSDL fault);
— Дополнительные данные (таблица) содержат описание ошибок и SOAP-ответы сервиса.

Настройка

Перед началом настройки требуется установить связь с узлом подключения к SOAP-сервису. Настройка включает несколько шагов.

Выбор метода запроса

Радиокнопкой необходимо выбрать один из предоставляемых SOAP-сервисом методов (операций).

Настройка запроса

На данном шаге задаются параметры запроса. Слева расположен список полей входного набора данных. Справа расположен список принимаемых SOAP-сервисом параметров. Для дальнейшей настройки необходимо проставить связи между полями и параметрами, сделать это можно несколькими способами:

Методом Drag-and-drop — перетащить метку поля из левого списка полей на элемент списка параметров запроса;
В правой таблице выбрать нужный параметр запроса и в столбце Связанные поля выбрать из выпадающего списка метку поля из входного набора;
Использовать кнопку Связать все автоматически, при этом происходит автоматическое связывание входных полей и параметров запроса, исходя из значений меток и типов данных полей входного набора и параметров.

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

Наличие временной зоны — определяет, указывается ли информация о часовом поясе в рамках стандарта ISO_8601 при передаче параметров запроса типа Дата/Время . Возможные значения:
- Не указывать.
- Не указывать для даты — не указывать временную зону для элементов SOAP-запроса типа Date.
- Указывать всегда.
Настройка ответа сервиса

Необходимо выбрать параметры ответа SOAP-сервиса, которые будут включены в результирующую таблицу в виде отдельных столбцов.

Настройка обрабатываемых исключений

На данном шаге выбираются атрибуты ошибок, которые необходимо вывести в выходном наборе порта Исключения.

Настройка пользовательских заголовков

Дополнительные параметры
- Идентификация запроса.
  - Один запрос в каждой строке входного запроса — каждая строка входной таблицы содержит параметры одного запроса к сервису.
  - Идентификатор запроса — поле входного набора — каждый запрос формируется из нескольких строк входной таблицы с совпадающим идентификатором. Необходимо выбрать поле идентификатора из списка полей входного набора.
  Примечание: поскольку входной набор данных с параметрами запросов является необязательным, то при его отсутствии узел вызова SOAP-сервиса отправит единичный SOAP-запрос без параметров.
  
  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
  
  Сегодня мы поговорим про фундаментальный элемент архитектуры любого современного приложения — про интерфейс приложения или API. Большую часть этой статьи мы посвятим разбору основ популярных реализаций API — REST API и SOAP API. Такие интерфейсы часто называют api restful , они применяются в том или ином виде практически в любом современном веб-приложении, написанном на любом языке программирования.
  
  Что такое программный интерфейс приложения (API)
  
  Перед тем, как начать разговор о REST API, давайте вспомним, что такое API и для чего он нужен. API расшифровывается как Application Program Interface — программный интерфейс приложения. Данное понятие применимо не только к веб-разработке, но и к любым программным продуктам вообще. Наушники, микроволновые печи, телевизоры, микропроцессоры — все они имеют свой API.
  
  Предположим, мы имеем дело с двумя такими совершенно разными разработками, каждая из которых обладает своим собственным API. Эти системы должны как-то взаимодействовать между собой, но есть некоторая сложность — ведь каждая из систем разработана на своем языке, по своим стандартам, со своими драйверами, на своей операционной системе и так далее. Чтобы как-то привести эти системы к общему знаменателю и иметь возможность коммуникации, мы используем API как некие внешние рычаги, которые влияют на внутреннее состояние каждой из систем. По этому принципу работает огромное количество проектов.
  
  REST API — частный случай API
  
  Допустим, мы написали сайт на PHP (Python, Java — не принципиально). PHP генерирует контент на сервере и по сети нам отправляет обратно уже сгенерированный HTML, JavaScript и CSS. Создавая сайт на PHP, вы получили некую статику, напрямую связывая код PHP, стили, HTML. Он взаимодействует с базой данных и выводит данные в шаблон. Предположим, мы задались целью разработать мобильное приложение под данную систему. Мобильное приложение должно работать с той же базой данных и мы должны как-то присоединить его к уже существующей системе.
  
  Раньше многие шли по такому пути — создавали API для системы «сайт плюс база данных», и мобильное приложение работало через API или непосредственно через сам сайт. Но поддерживать и расширять такую концепцию было неудобно, поэтому постепенно перешли к варианту, когда используется связка backend и frontend. Backend по-прежнему работает с базой данных, а frontend является вообще отдельным приложением, которое, грубо говоря, ничего не знает про backend. Frontend является абстрагированный клиентом и может быть написан на Angular, React, Vue или просто на JavaScript.
  
  Критерии RESTful-приложения
  
  Речь идет об отправке с браузера асинхронных запросов к серверу с помощью JavaScript. XML в данном случае не актуален, а процесс асинхронного общения браузера и веб-сервера задается именно REST-правилами. Веб-сервисы, которые полностью соответствуют парадигме Representational State Transfer, обычно называются RESTful. Чтобы приложение было RESTful, оно должно удовлетворять следующим правилам:
  - Архитектура приложения должна выглядеть как клиент-сервер.
  - Взаимодействие клиент—сервер должно быть реализовано без сохранения состояния, то есть между запросами на сервере не сохраняется клиентский контент. Вместо этого информация о состоянии сеанса передается клиенту. В то же время, для поддержания устойчивого состояния, информация о состоянии сессии может использоваться иным сервисом (например, службой базы данных), скажем, на период установления аутентификации.
  - Необходимо обеспечить кэшируемые данные, чтобы упростить взаимодействие клиента с сервером.
  - Приложение должно иметь единый интерфейс между компонентами, чтобы информация передавалась в стандартизированной форме, а не в зависимости от потребностей приложения. Это свойство Рой Филдинг описал как «особенность, которая отличает архитектурный стиль REST от других сетевых стилей».
  - Ограничение многоуровневой системы, при которой взаимодействие клиент-сервер может осуществляться через иерархические уровни.
  - Реализация кода по запросу, позволяющий серверам расширять функциональность клиента путем передачи исполняемого кода в виде апплетов или сценариев.
  SOAP API — стандарт–предшественник REST API
  
  Типы запросов
  - GET — получение данных (допустим, при открытии странички «Википедии», когда идет загрузка HTML, CSS, JavaScript)
  - POST — данный метод служит для создания каких-либо данных, он добавляет новую запись в базе данных
  - Метод PUT меняет данные в модели
  - Метод DELETE — дает возможность удалять какой-то элемент, например, удалить пользователя
  Если мы говорим о REST как о бизнес-логике, то у нас есть объект и мы передаем статус этого объекта. Например, у нас есть сайт пиццерии и новый заказ. Мы можем заказ создать, узнать о нем подробности, можем обновить его или удалить. И чаще всего для этого используется формат JSON.
  
  Коды запросов
  
  Статусы разделены на пять групп по своему значению:
  - 1XX — информационный статус
  - 2XX — статусы, означающие успешное выполнение запроса
  - 3XX — перенаправление
  - 4XX — статусы, указывающие на ошибку на стороне клиента
  - 5XX — статусы, показывающие, что присутствует ошибка на сервере
  Например, редактирование записи на сервере может выполнено успешно (код 200), может быть заблокировано контролем безопасности (код 401 или 403), или не пройти вообще из-за ошибки сервера (код 500).
  
  Чтобы работать с REST API сервисами можно использовать такие инструменты как Postman, SOAP UI (open source утилита по работе с сервисами) и Curl — утилита командной строки, присутствует почти на всех Linux-компьютерах.
  
  Недостатки REST API
  
  Заключение
  
  Теперь вы знаете, что такое REST API и где он применяется. Если говорить понятными словами — это возможность сервера давать доступ клиенту к своим ресурсам. Главный плюс REST API — его простота. Обращение REST API мало чем отличается от обычного запроса к веб-сайту (с небольшим расширением и описанием набора правил, как эти запросы будет происходить).
  
  Подробнее о REST-проектах, построенных с применением данного архитектурного стиля, а также их отличиях от SOAP сервисов можно узнать из видео ниже:
  
  Highload нужны авторы технических текстов. Вы наш человек, если разбираетесь в разработке, знаете языки программирования и умеете просто писать о сложном!
  Откликнуться на вакансию можно здесь .
  
  В этой статье Вы узнаете о том что такое SOAP UI и увидите некоторые примеры использования.
  
  Если Вам проще изучать материал от самого простого к более сложному - рекомендую сперва прочитать первые несколько страниц моего учебника здесь
  
  Введение
  
  SoapUI - это приложение для тестирования веб-сервисов с открытым исходным кодом для сервисно-ориентированных архитектур (SOA) и передач состояния представления (REST).
  
  Разработчик - Eviware Software
  
  Язык программирования, на котором пишут скрипты в SOAP UI, называется Groovy.
  
  Его функциональность охватывает проверку веб-сервисов, вызов, разработку, моделирование и имитацию, функциональное тестирование, нагрузочное тестирование и проверку соответствия.
  
  Коммерческая версия SoapUI Pro, которая в основном фокусируется на функциях, предназначенных для повышения производительности, также была разработана Eviware Software. В 2011 году SmartBear Software приобрела Eviware.
  
  SoapUI был первоначально выпущен в SourceForge в сентябре 2005 года. Это бесплатное программное обеспечение, лицензированное в соответствии с публичной лицензией Европейского Союза.
  
  Начиная с первого релиза, SoapUI был загружен более 2 000 000 раз. Он полностью построен на платформе Java и использует Swing для пользовательского интерфейса. Это означает, что SoapUI является кросс-платформенным. Сегодня SoapUI также поддерживает IDEA, Eclipse и NetBeans.
  
  Ссылку на скачивание SOAP UI можно найти здесь
  
  Как отправлять запросы
  
  New REST Project → Пишем URI → Запрос создаётся, можно добавлять новые.
  
  Method можно выбирать из выпадающего списка.
  
  Проект имеет иерархическую структуру.
  
  Project → Service → Resource → Method → Request
  
  Названия отражают суть:
  
  Request (запрос) это то место, где можно поменять тело запроса и просмотреть ответ сервера. Чтобы отправлять запросы нужно нажимать зелёный треугольник.
  
  Method (метод) указывает GET, POST, PUT или другой метод, который Вы будете использовать. Все дочерние запросы будут иметь один и тот же Method.
  
  Resourse (ресурс) отвечает за ту часть URL, которая добавляется к базовой.
  
  Service (сервис) отвечает за базовую часть URL
  
  Как сохранять проекты
  
  Советую помимо использования «Save all projects» закрывать все новые окна вручную. Тогда SOAP UI предложит Вам сохранить каждый проект по отдельности.
  
  После того, как все новые проекты сохранены, Вы можете закрыть SOAP UI. Я стараюсь закрывать SOAP UI только когда все окна закрыты.
  
  Создание Test Suit in SOAP UI
  
  Коротко:
  
  →Правый клик Project → Create New TestSuit (CTRL + T)
  → Укажите имя для TestSuit → Правый клик на TestSuit
  → New TestCase (CTRL + N) → Укажите имя для TestCase
  → Expand Test Case → Кликните на Test Steps → Add Step
  → Выберите request (e.g. SOAP Request) → Укажите имя для new step
  → Выберите операцию, которая запускает request
  → Добавьте Request в TestCase (OK)
  
  Зелёная « +» иконка плюса появится наверху.
  
  Кликнув на неё Вы можете добавить Assertions.
  
  Подробно:
  
  Правый клик на названии проекта
  Create New TestSuit (CTRL + T)
  
  Укажите имя для TestSuit
  
  → Правый клик на TestSuit
  
  New TestCase (CTRL + N) Укажите имя для TestCase
  
  → Expand Test Case
  
  → Кликните на Test Steps
  
  → Выберите request (e.g. SOAP Request)
  
  → Укажите имя для new step
  
  → Выберите операцию, которая запускает request
  
  → Добавьте Request в TestCase (OK)
  
  Зелёная «+» иконка плюса появится наверху. Кликнув на неё Вы можете добавить Assertions.
  
  Assertions в SOAP UI
  
  Assertions добавляются в TestSuits поэтому, чтобы добавлять Assertions нужно создать хотя бы один TestSuit и затем кликнуть на зелёную+ иконку.
  
  Затем Вы можете выбрать однин из многих доступных в SOAP UI типов assertion.
  
  Property Content → Contains
  
  Выберите Contains. С помощью этого подтверждения (assertion) можно искать присутствует ли в ответе заранее определённое ключевое слово. Оно поддерживает регулярные выражения и применимо ко всем ответам.
  
  Specify unique name of Assertion
  
  Type in content that you expect to receive in case of successfull request
  
  Property Content → Not Contains
  
  Выберите Not Contains. С помощью этого подтверждения (assertion) можно проверить отсутствие в ответе заранее определённого ключевого слова. Оно поддерживает регулярные выражения и применимо ко всем ответам.
  
  Введите уникальное имя для Assertion
  
  Введите сюда то, что Вы точно не хотите видеть в теле ответа
  
  Compliance, Status и Standards
  
  SOAP Response
  
  Выберите SOAP Response. В этим assertion Вы можете проверить что последний полученные ответ является валидным SOAP ответом. Это можно применять только к SOAP TestRequest Steps. Не пытайтесь применять этот assertion к REST запросам.
  
  Двойной клик на Assertion. Никакие дополнительные параметры не нужны этот шаг можно добавить только один раз.
  
  Compliance, Status и Standards
  
  Как Вы уже, наверное, догадались, этот assertion применим только к SOAP TestRequest Steps. Не пытайтесь использовать его для REST запросов.
  
  Обычно это 200, но всё же стоит прочитать спецификацию системы, которую Вы тестируете..
  
  SLA → Response SLA
  
  Выберите Response SLA. С помощью этого assertion Вы можете подтвердить, что последний полученный ответ (Response) был получен в течении определенного времени.
  
  Можно применять к Script TestSteps и TestSteps которые посылают запросы и получают ответы.
  
  Укажите максимальное время ответа (мс)
  
  Если время в которое нужно уложиться не указано в спецификации - поставьте какое-то разумное время.
  
  Property Content → XPath Match
  
  Выберите XPath Match. Этот Assertion использует выражение типа XPath чтобы выбрать содержимое указанного объекта и сравнить результат с ожидаемым значением.
  
  Может быть применён к любому объекту, который содержит XML.
  
  В поле Expected Result напишите true.
  
  Чтобы проверить не наличие как таковое, а значение какой-то величины введите в XPath Expression либо полный путь до величины либо её имя.
  
  А само значение, которое Вы ожидаете получить введите в поле Expected Result.
  
  В случае, если, например, мы не можем соединиться с сервером и все наши assertions зафейлились у них появятся красные индикаторы.
  
  Сервис-имитация
  
  О том как создать сервис-имитацию (mock-service) вы можете прочитать в статье Mock Service
  
  Ответ на этот вопрос зависит от уровня Вашей подготовки, предпочтений и, в каком-то смысле, идеологии.
  
  Начинающему тестировщику SOAP UI пригодится хотя бы потому, что хранить и создавать запросы в нём прощё и быстрее чем другими способами.
  
  Тестировщик с опытом программирования, например, на Python может написать все необходимые скрипты самостоятельно.
  
  Идеологическим приверженцам работы из консоли или только из Linux тоже может показаться что в SOAP UI слишком много UI.
  
  Установка SOAP UI в Linux
  
  Обратите внимание на необходимость предварительной установки Java (JRE).
  
  Как установить Java читайте здесь
  
  Существует официальная инструкция, но если хотите сэкономить время и нервы…
  
  Читайте также: