Как сделать soap запрос без wsdl файла
Обновлено: 06.07.2024
Применение SOAP при интеграции систем
Для начинающих аналитиков,
не имеющих опыта web-разработки
В предыдущей статье мы говорили про то, что REST — это архитектурный стиль, который Рой Филдинг сформулировал в своей диссертации в 2000 году.
С протоколом SOAP дела обстоят несколько иначе.
SOAP — это не стиль, а протокол. Аббревиатура SOAP так и расшифровывается: Simple Object Access Protocol — простой протокол доступа к объектам. То есть правила передачи информации в SOAP строго стандартизированы, есть спецификация, которой нужно соответствовать.
SOAP появился 1998 году и был передан в организацию World Wide Web Consortium (W3C) — международная организация, которая курирует развитие интернета.
Если сравнить это с тем фактом, что Рой Филдинг просто представил REST в своей диссертации, то вы поймете, почему SOAP завоевал популярность очень быстро.
Тем не менее на данный момент можно говорить о том, что в основном для интеграции систем используется REST.
Для того, чтобы наглядно показать отличие REST от SOAP, приведем вот такую аналогию. Представьте себе дерево, в котором есть дупло, и из этого дупла выглядывает птичка. Когда вы обращаетесь к какому-то приложению, вы как будто обращайтесь к такому дереву и стучитесь в окошко. Условно можно считать, что в это окошко выглядывает некоторая функция.
Если вы работаете с REST, то можно себе представить дерево, в котором есть много таких окошек — большое количество птичек, каждая из которых выглядывает из своего дупла. Это дупло называется Endpoint, но это отдельный разговор. Важно, что каждый раз, обращаясь к дуплу, вы обращаетесь только к одной функции.
SOAP основывается на технологии удаленного вызова процедур. Сервис, который работает на базе SOAP — это дерево с одним-единственным дуплом. Но каждый раз, обращаясь к этому дуплу, вы должны указать название процедуры, то есть название функции, которую вы хотите вызвать, потому что функций там может быть несколько. И, разумеется, вы должны передать те входные данные, которые нужны для процедуры, которую вы собираетесь вызвать.
Я начну с того, что понятия не имею о том, что я пытаюсь сделать. Мои навыки PHP - начинающий, а мой опыт работы с веб-сервисами - NULL.
Во всяком случае, я понятия не имею, как создать вызов из PHP. :-( Я посмотрел на NuSOAP для PHP, а также встроенный SoapClient, но без удачи. Я думаю , проблема в том, что я пытаюсь вызвать сложный метод, не полностью понимая, с какой лягушкой я связываюсь.
Поэтому я использовал SoapUI для извлечения файла определения и создания запроса, который отлично работает, и я получаю всю необходимую информацию. Проблема в том, что я понятия не имею , как мне сделать PHP-файл, создающий точно такой же запрос, что и SoapUI (и, следовательно, получающий правильный ответ).
XML-запрос, который генерирует SoapUI для меня, выглядит следующим образом:
Кто-нибудь может мне помочь в каком-то направлении? Желательно правильный. : -)
Я знаю, что вы не можете протестировать URL-адрес, поскольку он защищен IP-адресом, но мне бы очень хотелось узнать, как выполнить вышеуказанный вызов из файла /функции PHP.
3 ответа
Прежде всего, я сам здесь новичок, поэтому не могу гарантировать полностью правильный ответ, но могу дать вам хотя бы несколько советов.
Используйте SoapClient вместо NuSoap. SoapClient написан на C, NuSoap на PHP, поэтому SoapClient работает быстрее.
Если с вашим WSDL-файлом все в порядке, то все, что вам нужно сделать, это:
После этого SoapClient позаботится обо всем остальном и сделает все процедуры, определенные в WSDL, непосредственно доступными.
Результат будет иметь тип stdClass или массив с элементами типа stdClass.
Без WSDL вам пришлось бы самостоятельно указывать все детали, тип параметров, пространства имен и . и вызывать через __ soapCall () напрямую.
В любом случае вы можете проверить структуру $ result с помощью var_dump () & Со.
Как сказал Раффаэль, вам лучше использовать SoapClient, предлагаемый PHP SOAP EXTENSION.
Чтобы проверить свой сервис:
сначала объявите массив опций, где вы можете указать, например, не гоняться за wsdl (это полезно в среде разработки).
затем создайте клиент, начиная с имеющегося у вас wsdl:
вызовите метод searchTargetGroup следующим образом. Суть в том, чтобы правильно построить параметр questionTargetGroup, это должно работать:
Многие сайты и некоторые серверные приложения позволяют обращаться к ним по сети посредством стандартизированного протокола SOAP. Они выкладывают открытый API, через который позволяют вызывать некоторые их методы с передачей параметров. При этом масштабы таких систем могут быть совершенно разными: получение прогноза погоды, сеть 1C крупной организации или система бронирования авиабилетов.
В веб-разработке часто приходится интегрировать сторонние сервисы в свой сайт. Например, предположим, что нам нужно получить время восхода солнца, время захода и долготу дня для определённого города с веб-сервиса GisMeteo.
И с сервера возвращается нужный нам ответ GetSunInfoResponse в XML-формате:
На стороне сервера нужно только запрограммировать нужные методы вроде GetOrders и опубликовать сервис.
Это даёт возможность сделать корпоративный веб-портал для работников организации, подключенный к сервису 1С. Или даже разработать мобильное приложение.
Действительно, по этому адресу мы можем послать POST-запрос GetOrders :
и получить список заказов, возвращаемый в виде вложенного XML-файла в поле return :
Эти три параметра должны быть именно такими, какими их предоставляет сервер.
Смотря на такие «адские» XML-структуры вам наверняка покажется, что это ужасно сложно использовать. На самом деле, это только эмоциональное первое впечатление. Как бы это ни выглядело сложным, вам не придётся разбираться в формате и что-то парсить.
В PHP для работы с веб-сервисами имеется класс SoapClient. Если вы работаете в Windows и столкнулись с отсутствием этого класса, то подключите расширение php_soap.dll в файле php.ini .
Работать с этим компонентом можно в двух режимах. Различаются они только способом формирования запросов.
Работа в WSDL-режиме
Обычно на сервере имеется специально сгенерированный WSDL-файл c описанием всех доступных методов и адресов веб-сервиса. У GisMeteo он выглядит так.
Для уже знакомого нам метода GetSunInfo в нём имеется отдельная секция с определением полей запроса и ответа:
Ниже находится информация о необходимом для его вызова значении action и используемых режимах работы:
И в самом конце файла расположена секция для определения location для работы по протоколам SOAP 1.1 и SOAP 1.2 соответственно:
Аналогичные секции присутствуют в WSDL файле, генерируемом веб-сервисом 1С.
Формат запроса заказов может быть таким:
Полное имя метода с пространством имён таким:
А адреса доступа такими:
Теперь достаточно указать этот файл при создании объекта класса SoapClient :
или воспользоваться локальной копией файла:
В классе SoapClient реализован магический метод __call , который позволяет работать с удалёнными методами прямо по их имени:
Результат $result не надо парсить вручную, так как он уже будет представлять из себя объект с полями, повторяющими XML-структуру ответа. Например, долготу дня можно будет получить так:
Аргументы метода могут передаваться в виде массива или объекта. Попробуем, например, получить курсы валют на текущий день по протоколу SOAP с сайта Центробанка с помощью метода GetCursOnDate . В отличие от получения погоды, этот метод возвращает ответ с единственным полезным нам полем any , в котором содержится вложенный XML документ с валютами. Но ничего страшного, так как его легко будет превратить в объект с помощью SimpleXMLElement .
Создадим файл curs.php :
и запустим его в консоли:
Через некоторое время мы увидим результат:
Здесь мы WSDL-файл загружаем прямо с сервера и кешируем его в памяти на некоторое время. Но если в каком-либо сервисе этот файл занимает несколько мегабайт, то для экономии трафика его лучше скачать к себе и подключать из локальной папки.
Работа в ручном режиме
Если у вас есть необходимость подключаться к какому-то специфическому веб-сервису, у которого отсутствует WSDL-файл, либо если вы хотите указывать все параметры вручную, то вам будет нужен режим работы без WSDL.
В данном случае клиенту неоткуда будет брать информацию об адресе сервиса, пространствах имён и полных имён методов для SOAPAction . Поэтому адрес сервиса location и пространство имён uri надо будет указать вручную:
Параметром exceptions мы включаем механизм генерирования исключений, позволяющий обрабатывать их конструкцией try < . >catch (SoapFault $e) . Другими параметрами можно указать, например, используемый прокси-сервер.
Все методы класса SoapClient доступны извне. Послать команду на сервер теперь нужно непосредственным вызовом __soapCall , указав имя метода для построения XML-запроса и полное имя SOAPAction. Получим из 1С список заказов за последние 90 дней:
Метод __soapCall позаботится о построении XML-структуры запроса и вызовет метод __doRequest , который отправит запрос на сервер.
Но при желании мы можем опуститься ещё ниже и вызвать метод __doRequest . В этом случае XML-запрос нужно составить самому:
Смешанное использование
Иногда встречаются ситуации, когда нужно использовать нестандартные параметры запроса. Например, специфические заголовки. Рассмотрим пример получения информации о пользователе из eBay:
Можно заметить, что здесь есть WSDL файл, но для работы нам нужно передавать токен авторизованного пользователя в дополнительных заголовках. И в этом случае нам помог вызов метода __soapCall .
Интеграция с веб-сервисом в Yii2
Аналогично нашим предыдущим скриптам, мы можем производить операции в любом месте нашего приложения:
То есть для данного случая нам просто нужно поместить WSDL-файл в любое место и прописать авторизационные данные в конфигурационном файле.
Это простейший случай, но использование этого кода, например, в контроллере не очень уместно. Вместо этого клиент целесообразнее вынести в отдельный компонент. Этим мы сейчас и займёмся.
Вместо использования динамически создаваемых структур или ассоциативных массивов для передачи аргументов запроса:
лучше использовать одноимённые запросам классы:
Это удобнее тем, что в любом хорошем редакторе или IDE работает автоподстановка полей и подсветка опечаток. Кроме того, в своём классе мы можем релизовать любой дополнительный функционал.
Например, создав базовый класс для наших команд, наследуемый от класса yii\base\Model :
мы превращаем все структуры в модели и легко можем добавить в них правила валидации:
и проверять корректность заполненных данных перед отправкой запроса:
И ещё один нюанс. У нас сделано так, что имя метода и класса его параметров совпадают:
Соответственно, имя метода можно получить из имени класса:
и вызывать этот метод у клиента динамически любым способом из этих двух:
Теперь, пользуясь этими нюансами, мы можем создать компонент приложения с единственным методом send , который будет автоматически определять имя метода и вызывать его у клиента:
и подключить его в конфигурационном файле:
чтобы теперь обращаться к нему как к Yii::$app->webservice :
Этого уже вполне достаточно для нормальной работы.
Но если у вас очень сложный сервис, ответы которого нужно довольно рутинно парсить (или ответ приходит в нестандартной кодировке, которую надо всегда расшифровывать), то можно наделить логикой и ответы.
Создадим базовый класс для ответа:
Теперь отнаследуем от него класс, который будет обрабатывать ответ метода получения курса валют GetCursOnDate . Одноимённый класс, но в папке response :
Дополним наш компонент функционалом оборачивания пришедшего от клиента ответа в полученный из имени метода класс:
После этого вместо голого ответа от клиента в переменной $response мы уже получим наш объект и сможем использовать его методы.
Теперь весь код получения курса доллара через SOAP клиент занимает всего несколько строк:
и может полноценно использоваться в любом месте приложения. Всё связанное с SOAP мы полностью инкапсулируем внутри нашего компонента webservice . Теперь в тестовой конфигурации можно легко подменить класс WebService , чтобы заменить рабочий компонент на его заглушку.
После того, как оставите комментарий к данной статье, советую прочесть ещё пару интересных статей:
Допустим, вы интегрируете системы, используя веб-сервисы, или ваши клиентские приложения взаимодействуют с сервером посредством веб-сервисов, в этом случае вам просто необходимо использовать инструмент SoapUI для тестирования веб-сервисов и клиентов. Работа с программой SoapUI очень проста и позволяет воочию увидеть передаваемые и получаемые данные. Кроме того вы сможете провести нагрузочное тестирование вашего веб-сервиса и симулировать работу веб-сервиса.
О SoapUI
Итак, что же такое SoapUI? Это кроссплатформенное клиентское оконное приложение, написанное на языке Java. Использовать основной функционал приложения можно бесплатно. В платной версии программы, которая называется SoapUI Pro, вы сможете делать чуть больше, например, устанавливать плагины с помощью менеджера плагинов, проводить тесты драйверов данных, перехватывать трафик, оценивать покрытие ваших веб-сервисов тестами и создавать отчёты. Официальная страничка проекта находится здесь, скачать дистрибутив бесплатной версии программы можно здесь. Если бесплатной версии вам не хватает, вы можете скачать пробную версию SoapUI Pro здесь.
Если для разработки вы используете IDE IntelliJ, NetBeans или Eclipse, то вы можете интегрировать SoapUI прямо в IDE используя плагины. Как это сделать написано здесь. Я не буду останавливаться на этом варианте. Здесь я опишу лишь вариант использования SoapUI, как самостоятельного приложения. Установка на компьютер под управлением Windows проходит быстро и не вызывает вопросов, поэтому на этом этапе я тоже не буду заострять внимание.
Тестирование веб-сервиса
Прежде чем продолжить изучать программу SoapUI сделаем тестовый веб-сервис. Я сделаю это в Visual Studio, у моего сервиса будет только две функции GetSum1 и GetSum2, которые работают одинаково, но принимают и отдают результат по-разному.
После этого мы увидим, что для нашего тестового веб-сервиса создались запросы, причём для версий протокола SOAP 1.1 и 1.2. Дважды щёлкните на запрос «Request 1» и справа откроется дочернее окошко «Request 1», в котором вы увидите сформированный запрос.
Теперь вычислим сумму с отрицательным числом. Как видно на картинки, функция GetSum1 с отрицательными числами работает дольше. Это ожидаемый результат, т.к. в функции GetSum1 специально стоит задержка 100мс, если хотя бы одно из полученных чисел отрицательное.
Если вместо числа передать строку, то вы увидите ошибку.
Третий параметр у нас необязательный. Проверим, что будет, если мы его уберём из запроса. После выполнения мы увидим, что сумма посчиталась, ошибок нет.
Как видите, проверить работу веб-сервиса можно очень просто и быстро.
Тесты
Теперь попробуем создать тесты для сервиса. Сначала добавьте в проект набор тестов (TestSuite).
Затем в набор тестов добавьте тестовый случай (TestCase).
Теперь в новый тестовый случай можно добавить шаги для теста. Добавим тестовый запрос «Test Request».
В диалоге «New TestRequest» выбираем тестируемую функцию «GetSum1».
После добавления шага теста можно задать параметры и выполнить тест. Для выполнения теста также нажимаем зелёный треугольник.
Как видите после тестирования слева от названия шага «Test Request» отобразилась зелёная картинка-статус, сигнализирующая, что тест выполнен успешно. Теперь в первом параметре передайте строку и запустите тест. После тестирования вы можете увидеть, что картинка-статус поменяла цвет на красный, а на нижней левой панели отображается, что пошло не так. В нашем примере – это SOAP-ошибка «Not SOAP Fault - FAILED». Там же на закладке «Request Log» вы можете посмотреть, когда выполнялся тест, сколько по времени и сколько байт было возвращено.
Теперь сделаем тестирование диапазона значений. Будем подставлять в параметр «a» значения от 1 до 5 и проверять сумму. Для этого сначала нужно добавить свойство, которое будет хранить текущее значение параметра «a», например, в тестовый случай «TestCase 1». Для этого дважды щёлкните по нему на панели «Navigator». Затем в открывшемся дочернем окне «TestCase 1» откройте вкладку «Properties», щёлкните на кнопку с плюсом и задайте новому свойству имя «aValue» и значение 1.
Теперь переключитесь в тестовый запрос «Test Request» (дважды щёлкнув по нему на панели «Navigator») сотрите значение в параметре «a» и щёлкните по тому месту, где нужно будет вставить значение свойства, правой клавишей мышки и в меню выберите только что добавленный параметр «Get Data. -> TestCase: [TestCase 1] -> Property [aValue]».
После этого вместо статического значения параметра вы увидите текст $ . Можете теперь запустить тест и удостовериться, что при тестировании будет подставлена единица вместо строки $ и сумма получится равная 7.
Кстати, для более удобного доступа к свойствам вы можете включить режим отображения свойств на панели навигатора (маленькая кнопка слева сверху на панели). Тогда свойства можно просматривать прямо на панели «Navigator». После этого дважды щёлкнув на свойство в навигаторе, вы можете поменять его значение.
Как видите из картинки, свойства могут быть заданы для проекта в целом, для отдельного набора тестов (TestSuite) или для отдельной тестовой ситуации (TestCase).
Теперь сделаем установку свойству «aValue» значения 1 в начале тестирования. Для этого откройте тестовый случай «TestCase 1», откройте вкладку «Setup Script» (скрипт инициализации вызывается перед выполнением тестового случая) и добавьте сюда следующий код:
Здесь нужно сразу заметить, что все скрипты в SoapUI по умолчанию пишутся на языке Groovy, и в статье я буду использовать этот скрипт. Справку по языку можно получить здесь. По желанию вы можете использовать JavaScript для написания скриптов, тогда для правильной интерпретации ваших скриптов нужно установить в свойстве проекта «Script Language» значение «Javascript». В этом случае для интерпретации скриптов будет использоваться движок Rhino.
Также обратите внимание, что над каждым окошком для написания скрипта перечислены доступные глобальные переменные. На картинке сверху – это переменные log, testCase, context и testRunner.
Теперь после каждого шага «Test Request» нам нужно увеличивать значение свойства «aValue» на единицу. Чтобы это сделать, добавьте в тестовую ситуацию (TestCase) шаг «Groovy Script» - пункт контекстного меню «Add Step -> Groovy Script».
После добавления шага напишите следующий скрипт для изменения значения свойства:
Здесь вы сразу можете выполнить скрипт и увидеть на панели навигатора изменённое значение свойства «aValue», а на вкладке «Log Output» увидите наш лог.
Теперь попробуем циклично выполнять шаги «Test Requset» и «Groovy Script». Для того чтобы это сделать добавьте к скрипту следующие строчки:
Как видите, цикл будет выполняться пока значение свойства «aValue» меньше 10. Теперь откройте тестовый случай «TestCase 1» и выполните его. Как видите на вкладке «TestCase Log», всего выполнилось 18 шагов (9 «Test Request» и 9 «Groovy Script»).
Теперь нужно отловить ошибку в вычислениях, которую мы специально заложили в веб-сервисе. Сервис должен вернуть -1, если первый параметр функции «GetSum1» равен 5. Для этого будем проверять результат работы функции. Чтобы добавить утверждение, которое будет проверять SoapUI, щёлкните по кнопке «Add an assertion to this item» (см. картинку), и в диалоге выбора утверждения выберите «Script Assertion».
И в диалоге «Script Assertion» пропишите скрипт проверки результата.
Здесь же сразу можно проверить результат, выполнив скрипт. На картинке видно, что скрипт выполнился успешно – утверждение истинно.
Теперь поменяем в качестве эксперимента параметр «aValue» – установим значение 5 и выполним тест «Test Request». После выполнения вы увидите, что тест провален (красная иконка в навигаторе) и увидите, какое утверждение не выполнено. В нашем случае – это утверждение «Script Assertion».
Теперь выполним всю ситуацию «TestCase 1». После выполнения на вкладке «TestCase Log» мы видим, что тестирование прошло с ошибкой. Выполнение было прервано на шаге 9. Предыдущие шаги были выполнены без ошибок. Дважды щёлкнув на шаг 9 в логе, мы можем узнать, какой запрос был передан веб-сервису и что было возвращено (в нашем случае сумма посчиталась неправильно).
Аналогичным образом вы можете добавлять любое количество тестов любой сложности. А затем при каждом обновлении вашего сервиса выполнять все тесты сразу, чтобы проверять его работоспособность.
Нагрузочное тестирование
Чтобы проверить, выдерживает ли сервер требуемую нагрузку, или понять, какие функции выполняются медленно, мы можем провести нагрузочное тестирование. В нашем примере умышленно сделана большая задержка в функции «GetSum2». Давайте обнаружим эту задержку с помощью нагрузочного тестирования.
Сначала сделайте новую тестовую ситуацию «TestCase 2», добавьте в неё тестовый запрос «Test Request 1» для функции веб-сервиса «GetSum1» и тестовый запрос «Test Request 2» для функции «GetSum2». Вместо статических значений параметров поставьте следующий скрипт: $ . Так в качестве значений параметров будут устанавливаться отрицательные и положительные числа подобранные случайным образом. У вас должны получиться следующие SOAP-запросы:
для функции «GetSum1» и для функции «GetSum2»:
Теперь добавьте нагрузочный тест (пункт контекстного меню «New LoadTest»).
После добавления нагрузочного теста сразу всё готово к его запуску. Здесь вы можете задать количество потоков, стратегию выполнения и параметры для каждой стратегии (вы можете параллельно выполнять несколько тестов, используя разную стратегию). Выполните тест.
После выполнения в таблице вы увидите минимальное и максимальное время выполнения теста, среднее значение, количество ошибок и пр. На вкладке «LoadTest Log» будет указано время начала и окончания теста. Также вы можете посмотреть статистику и историю на графиках.
По таблице вы можете заметить, что тест «Test Request 2» выполняется дольше. В среднем 203,55 мс, а тест «Test Request 1» выполняется быстрее примерно в 2 раза. Вот мы и обнаружили, что в функции «GetSum2» есть задержка при выполнении.
Тестирование клиента
Теперь давайте попробуем создать имитацию веб-сервиса с помощью программы SoapUI. Это может пригодиться для тестирования клиента веб-сервиса. Ведь с помощью такого имитатора веб-сервиса вы сможете протестировать все возможные ситуации на клиенте.
Чтобы создать веб-сервис, щёлкните по SOAP-интерфейсу и в контекстном меню выберите пункт «Generate SOAP Mock Service».
В поднявшемся диалоге вы можете выбрать функции, для которых нужно создать операции сервиса, путь к сервису и порт. Нажмите «OK».
Мы здесь сделаем расчёт суммы и возврат результата с помощью скрипта. Откройте вкладку «Script» и напишите следующий код:
После этого в SOAP-ответе вместо вопроса можно подставить следующую строку: $ . У вас должен получиться такой ответ:
Вот так это выглядит в программе:
Теперь, можете запустить сервис. Для этого переключитесь в навигаторе на сервис, у меня это «Service1Soap MockService» и щёлкните по зелёному треугольнику. После запуска сверху будет двигаться бегунок показывающий, что сервис работает.
Теперь можно тестировать клиента. Я для примера сделал консольное приложение в Visual Studio, добавил в проект ссылку, указав ссылку на WSDL (WSDL можно получить, щёлкнув по кнопке с изображением зелёной фигуры, на картинке сверху она обведена зелёным кружком). Далее можно вызывать функцию сервиса «GetSum1». Вот код консольного приложения:
После выполнения приведённого кода программы в консоль будет выведен результат 7.
Также при создании сервиса вы можете тестировать его здесь же прямо из программы SoapUI.
Заключение
SoapUI – это мощный инструмент, который постоянно развивается, и при разработке веб-сервисов – это незаменимый инструмент для тестирования. Полное описание программы сделать в одной статье невозможно, да и не имеет смысла, ведь у каждого разные задачи. Но на сайте разработчика есть хорошее описание программы с примерами и справка по всем классам, которые можно использовать в скриптах.
Читайте также: