Здравствуйте!
В нескольких статьях я расскажу о возможностях протестировать с помощью SoapUI, как работают веб-сервисы 1С. Также приведу примеры возврата из 1С документов в формате PDF и сложных xml-файлов. Некоторые вещи сходны с вот , однако я рассмотрю более сложные примеры работы с веб-сервисами. Но для начала я по шагам рассмотрю процесс запуска веб-сервисов и работы с SoapUI, чтобы легче было разобраться в их функционировании с нуля.
Для начала возьмем каркасную конфигурацию без веб-сервисов и пройдем по шагам процесс их создания.
Добавим новый веб-сервис с именем test1 и создадим в нем операцию hello с возвращаемым типом string. Имена веб-сервисов и операций лучше всегда задавать на латинице.
Также нужно задать URI пространства имен и имя файла публикации:
При нажатии на лупу в поле "Имя процедуры" будет открыт модуль веб-сервиса и можно будет реализовать функцию hello.
Функция hello() возврат "строка из веб-сервиса 1с"; КонецФункции
Теперь, чтобы получившаяся функция была доступна по http, нужно опубликовать наш сервис на веб-сервере. Для этого подойдет Apache 2.2. Я почитал статьи о том, как можно настроить работу с IIS и мне это показалось гораздо сложнее. После установки и запуска Apache 2.2 нужно зайти в меню Администрирование - Публикация на веб-сервере. Поле "каталог" должно быть заполнено и содержать каталог установки Apache. Запомните поля "имя" и "адрес" веб-сервиса, они нам пригодятся на следующем шаге.
Для тестирования создадим отдельного пользователя WsUser, с простым паролем и дадим ему полные права.
После этого устанавливаем и запускаем SoapUI. Эта программа очень удобна для тестирования веб-сервисов, она может получать их описание и делать post-запросы к сервисам.
Заходим в меню File - New SOAP project, задаем имя проекта hellotest а в поле Initial WSDL пропишем вот такую ссылку:
http://localhost/test_ws/ws/test1.1cws?wsdl
В ней часть "test_ws" была задана на прошлом этапе в поле "имя" а test1.1cws в поле "адрес".
Нажимаем ОК и на этом этапе нужно будет авторизоваться, войдя под тестовым пользователем WsUser. Будет создан проект и два элемента binding.
Soap12Binding отличается тем, что работает по новой версии стандарта SOAP 1.2. Откроем в test1Soap12Binding элемент Request1 и увидим вот что:
SoapUI показывает, какой xml будет передано в нашу функцию. Перед запуском теста есть еще один нюанс, по умолчанию SoapUI будет требовать авторизацию для каждого отдельного элемента Request. Поэтому, чтобы не задавать ее каждый раз, нужно кликнуть правой кнопкой мышки на testSoap12Binding, выбрать Show interface view и в открывшемся окне на вкладке "Service Endpoint" задать имя и пароль пользователя веб-сервисов:
Если этого не сделать, то для каждого Request нужно будет задавать авторизацию, в нижней панели по кнопке Auth.
Теперь можно наконец-то выполнить запрос к функции hello и посмотреть ответ:
Отлично, все заработало!
Теперь сделаем новую функцию с параметрами, например проверим работу с датами, сделаем функцию getSaleDocNumbersByDate, которая будет принимать дату документа (расходной накладной) и возвращать номера документов за эту дату строкой. Добавим к операции параметр date с типом dateTime:
код такой:
Функция getSaleDocNumbersByDate(date) // датаНачала = началоДня(date); датаКонца = конецДня(date); выборкаДокументов = документы.Расходная.Выбрать(датаНачала, датаКонца); номера=""; пока выборкаДокументов.Следующий() цикл номера = номера+" №"+выборкаДокументов.Номер+";"; конеццикла; возврат номера; КонецФункции
Теперь в SoapUI правой кнопкой мыши нужно кликнуть на элемент testSoap12Binding и выбрать пункт Update Definition. После этого в проекте появится функция getSaleDocNumbersByDate и готовый Request к ней. Для заполнения даты нужно использовать формат "YYYY-MM-DDThh:mm:ss" (можно посмотреть на w3schools и ОЧЕНЬ рекомендую пользоваться этим сайтом для понимания работы с xml)
Тогда получатся вот такие запрос и ответ:
Если необходимо передавать в функции более сложные параметры (например, xml с несколькими полями), или получать в ответ сложные по структуре xml, то нам не обойтись без пакетов XDTO.
Очень подробно работа с XDTO рассмотрена в цикле статей . По сути, пакет определяет структуру и тип полей используемых xml-файлов.
Я рассмотрю пример передачи и получение xml-файла, тип которого определен в пакете
А также в следующих статьях я рассмотрю примеры:
Задача будет такая: найти документ расходной накладной по заданным во входящем xml номеру и дате и вернуть найденный документ. Возвращать нужно также в виде xml с номером, датой, контрагентом и его кодом и табличной частью товаров.
Создадим пакет packet1 с пространством имен packet1_ns. Для входящего xml-файла определим тип объекта InDocSaleQuery с полем number типа string и полем date типа dateTime. Для выходного файла определим сначала тип для одной строки табличной части товаров: SaleItem с полями name типа string, price sum, quantity типа decimal. А сам документ SaleDoc будет у нас составного типа: поля number, date, partnerName и поле SaleItems у которого будет тип SaleItem и максимальное количество -1. Именно такое поле обозначает, что в нем может присутствовать массив из нескольких элементов. Вот так всё это выглядит в конфигураторе:
Сначала продемонстрирую код функции, а уже затем объясню что происходит
Код:
Функция getSaleDoc(incomingXML) НомерДок = incomingXML.number; ДатаДок = incomingXML.date; запрос = новый запрос; запрос.Текст = "ВЫБРАТЬ | РасходнаяТовары.Номенклатура.Наименование как name, | РасходнаяТовары.Цена как price, | РасходнаяТовары.Количество как quantity, | РасходнаяТовары.Сумма как sum, | РасходнаяТовары.Ссылка |ИЗ | Документ.Расходная.Товары КАК РасходнаяТовары |ГДЕ | РасходнаяТовары.Ссылка.Номер = &Номер | И РасходнаяТовары.Ссылка.Дата = &ДатаДок"; запрос.УстановитьПараметр("Номер",номерДок); запрос.УстановитьПараметр("ДатаДок",ДатаДок); выборка = запрос.Выполнить().Выбрать(); если выборка.Количество()=0 тогда //вернем ошибку ТипДокумента = ФабрикаXDTO.Тип("packet1_ns", "SaleDoc"); ПакетДокумента = ФабрикаXDTO.Создать(ТипДокумента); ПакетДокумента.number = "Документов Не найдено!"; Возврат ПакетДокумента; иначе //создаем типы ТипДокумента = ФабрикаXDTO.Тип("packet1_ns", "SaleDoc"); ТипТабличнойЧасти = ФабрикаXDTO.Тип("packet1_ns", "SaleItem"); ПакетДокумента = ФабрикаXDTO.Создать(ТипДокумента); //выбираем из табличной части сч=0; пока выборка.Следующий() цикл если сч=0 тогда //заполним реквизиты документа док = выборка.ссылка; ПакетДокумента.number = док.Номер; ПакетДокумента.date = док.Дата; ПакетДокумента.partnerName = строка(док.Контрагент); конецесли; //заполняем табличную часть ПакетТабличнойЧасти = ФабрикаXDTO.Создать(ТипТабличнойЧасти); ЗаполнитьЗначенияСвойств(ПакетТабличнойЧасти,выборка); //добавляем ее в документ ПакетДокумента.SaleItems.Добавить(ПакетТабличнойЧасти); сч=сч+1; конеццикла; Возврат ПакетДокумента; конецесли; КонецФункции
Здесь два основных нюанса. Первый: так как был задан тип входящего параметра incomingXML и он был описан этот тип в пакете, то сразу возможно обращаться к полям этого входящего xml. Второй: работа с фабрикой XDTO. Из нее был получен тип для результирующих выходных параметров и создано ЗначениеXDTO этого типа, у которого были заполнены необходимые поля. Также стоит заметить, что в типе SaleDoc следует ввести отдельное поле для ошибки, но для тестовых целей ошибки будут записаны в поле number.
Вот как выглядит результат этого запроса в SoapUI:
Как видно, все работает, но еще есть что улучшить - например, хотелось бы знать какое количество элементов SaleItems у нас в документе.
Об этом и о более сложных примерах я расскажу уже в следующей статье.
В приложенном архиве - выгрузка информационной базы и проект SoapUI.
В последние годы увеличилось использование API и зависимость от веб-сервисов. Вот список из 12 инструментов тестирования веб-сервисов, которые значительно помогут вам.
За последние несколько лет популярность и использование веб-сервисов или API повысились. Веб-сервис или API – это набор процедур или программных компонентов, которые помогают приложению взаимодействовать или выполнять какой-либо процесс / транзакцию, формируя соединение между другим приложением или сервером. В основном существуют два типа веб-сервиса: REST и SOAP для передачи данных и информации через интернет-протокол.
Поскольку эти веб-службы доступны в Интернете и распространяются по разным сетям, они уязвимы для вирусов и угроз безопасности, которые влияют на процессы, основанные на них. Следовательно, тестирование веб-служб или API-интерфейсов становится необходимым для обеспечения правильной работы и корректного ответа на запросы. Тестирование ПО является перспективным направлением в сфере IT, получить необходимые знания Вы можете на
На рынке существует несколько коммерческих и бесплатных инструментов тестирования для тестирования их возможностей подключения, ответа и производительности. Эти инструменты тестирования автоматизируют тестирование для конкретного сценария, такого как функциональное тестирование, нагрузочное тестирование, тестирование производительности и т. д.
Здесь вы найдете 12 отличных инструментов тестирования веб-сервисов, на счет которых вам следует подумать для вашего API или требований тестирования веб-сервисов:
SoapUI – это инструмент для кросс-платформенного тестирования с открытым исходным кодом. Он может автоматизировать функциональные, регрессионные, согласованные и нагрузочные тесты как SOAP, так и REST-сервисов. Он прост в использовании и поддерживает передовые технологии и стандарты для моделирования и стимулирования поведения веб-сервисов.
TestingWhiz это “codeless” инструмент автоматизации тестирования который совместим с API/веб сервисами. Он позволяет проводить функциональное, тестирование совместимости и нагрузочное тестирование и работать с веб-службами REST и SOAP через WSDL-интерфейс через HTTP и FTP.
SOAPSonar обеспечивает комплексное тестирование веб-сервисов для HTML, XML, SOAP, REST и JSON. Он обеспечивает функциональное тестирование, тестирование производительности, совместимости и тестирование безопасности с помощью стандартов OASIS и W3C.
SOAtest – это инструмент для тестирования и проверки API-интерфейсов и приложений, управляемых API. Он обеспечивает надежную поддержку функционального блока, интеграцию, безопасность, симуляцию, проведение нагрузочного тестирования при помощи таких технологий, как REST, JSON, MQ, JMS, TIBCO, HTTP и XML.
TestMaker – это инструмент с открытым исходным кодом для тестирования и мониторинга производительности веб-сервисов и приложений SOA с помощью PushtoTest. Он работает на Jython (Python написанный на Java). TestMaker может перепрофилировать тесты Selenium, тесты SoapUI, тесты Sahi или любые тесты, написанные в Groovy, Java, Python, PHP, Ruby и Perl, в функциональные, нагрузочные тесты.
Postman – еще один инструмент тестирования API / веб-сервисов, который имеет мощную поддержку HTTP-клиента. Он имеет простой в использовании конструктор запросов, который позволяет писать тест-кейсы и управлять данными ответов и временем отклика для эффективного тестирования и управления тест-кейсами API.
VRest – это инструмент, предназначенный для тестирования, тестирования REST APIS и веб-сервисов. Он также поддерживает тестирование веб-приложений, мобильных и настольных приложений, которые взаимодействуют со сторонними API-интерфейсами или службами HTTP.
HttpMaster – еще один эксклюзивный инструмент для тестирования веб-сервисов REST. Это помогает тестировщикам тестировать поведение API REST и проверять выходные данные в таких форматах, как XML, JSON и HTML. Благодаря универсальному HTTP-инструменту HttpMaster также помогает разработчику моделировать активность клиента и поведение ответа приложения API.
Runscope – простой инструмент для проверки и мониторинга производительности API. Runscope также поддерживает тестирование API-интерфейсов и бэкэнд мобильных приложений.
Rapise – это надежный инструмент автоматизации с мощными и расширяемыми функциями. Он основан на открытой и гибкой архитектуре для быстрого функционального тестирования веб-сервисов REST / SOAP. Rapise также обеспечивает поддержку тестирования веб-приложений, встроенных в Java, .NET, Ajax, Silverlight и Flash.
WebInject – это бесплатный инструмент для автоматизированного функционального, приемного и регрессионного тестирования веб-сервисов. Это инструмент командной строки и основан на Perl, что упрощает выполнение тестов, поскольку не требуется тратить время на командную строку. Кроме того, у него нет IDE-интерфейса, который означает, что тесты записываются вне пользовательского интерфейса WebInject. Он может работать на платформах с интерпретатором Perl.
Наконец, Storm – еще один инструмент с открытым исходным кодом от CodePlex для тестирования веб-сервисов, написанных на Java или.NET. В настоящее время он поддерживает только веб-сервис SOAP.
Конечно, список здесь не заканчивается, так как для тестирования веб-сервисов существует огромное множество инструментов.
Запишитесь прямо сейчас или закажите звонок с бесплатной консультацией!
Веб-сервисы в 1С
В данной статье будет рассмотрены вопросы интеграции 1С с уже существующими веб-сервисами и использование самой 1С как веб-сервиса.
При этом под веб-сервисами будет пониматься системы, работающие в интернете и обеспечивающие взаимодействие с ними не только по SOAP (что является именно веб-сервисом), но и другими способами, включая обычные HTTP(S)-запросы.
В платформе 1С81 появилась реализация веб-сервисов.
Но их использование чревато рисками:
Клиенту выдается документ о продаже (чек) только в том случае, если транзакция по сервису прошла успешно. Иначе возможна ситуация, когда клиент получит чек и будет пребывать в уверенности, что получил услугу, а на самом деле это не так.
Веб-сервисы SOAP используют WSDL схемы и объекты XDTO для представления данных.
Для того, чтобы использовать внешний сервис, нужно загрузить его WSDL-схему.
Иногда WSDL-схема не загружается в 1С. Проверить валидность (правильность) схемы можно любым валидатором WSDL-схем, например http://www.validwsdl.com/ .
Нужно загрузить схему на какой-нибудь http-сайт (можно по ftp) и указать адрес файла, в который загружена схема:
Особенность загрузки WSDL в 1С в том, что валидные схемы могут не загружаться. Никакого встроенного валидатора нет, поэтому приходится искать ошибку методом деструктивного анализа, последовательно уменьшая количество элементов в схеме. Можно, например, удалить описание веб-сервиса.
Для тестирования работающего внешнего веб-сервиса используйте обработку «ТестПроизвольногоВебСервиса.epf» из пакета к этой статье.
Тестирование можно использовать на примере сервиса Morpher , склоняющего имена (адрес сервиса http://www.morpher.ru/WebServices/Morpher.asmx?WSDL):
Таким способом можно протестировать любой сервис, который имеет простые точки входа, содержащие параметры простых типов: число, дата, строка.
В обработке можно указать также логин и пароль, которые требуются для авторизации доступа к веб-сервису.
Для отладки можно использовать программу SoapUI, который может передать произвольный запрос веб-сервису и получить от него ответ.
К сожалению, SOAP в 1С достаточно капризно ведет себя при работе через протокол HTTPS, практика показывает, что добиться HTTPS соединения невозможно, хотя возможность и продекларирована в платформе. Сказывается отсутствие средств диагностики и отладки для выяснения причин, из-за которых не устанавливается соединение. Поэтому удобно использовать SOAP через CURL.
Встроенный механизм использования HTTPS подразумевает, что все сертификаты должны быть опубликованы в общем файле pem в каталоге программы 1С.
Правилом хорошего тона является создание в сервисе операцию, которая информирует о том, что сервис доступен. Это облегчает жизнь интеграторов, им будет проще проверять, налажена ли связь с сервисом.
Например, можно использовать операцию Hello без параметров, которая просто возвращает булево значение Истина.
Процедура хорошо описана в документации: file:///C:/Program%20Files/1cv81/AddDoc/RU/V8AddDoc81.htm#_Toc176167634 :
Задача публикации Web-сервисов сводится к размещению конфигурационных файлов *.1cws Web-сервисов в соответствующем каталоге веб-сервера с соответствующими настройками для веб сервера. Для того, чтобы выполнить публикацию Web-сервисов, следует выполнить команду меню «Администрирование | Публикация Web-сервисов».
В результате выполнения этой команды будет открыто окно публикации Web-сервисов.
Окно публикации Web-сервисов содержит путь к веб-серверу и два списка:
С помощью кнопки «Соединение…» следует указать веб-сервер, на котором требуется опубликовать Web-сервисы.
Окно выбора пути к веб-серверу позволяет указать путь двумя способами:
Публикация выбранного Web-сервиса осуществляется с помощью кнопки «Опубликовать»
Для отмены публикации Web-сервиса используется кнопка «Удалить».
Публиковать можно в локальном каталоге или по FTP. Можно публиковать и на удаленный сервер по UNC-пути, если удаленный сервер входит в локальную сеть.
После публикации веб-сервис доступен по адресу «http://localhost/test.1cws» или «http://xxx.ru/test.1cws», где xxx.ru - адрес удаленного сервера а localhost - типовой адрес локального сервера.
Для доступа к сервису нужно пройти аутентификацию.
Вопросы авторизации хорошо рассмотрены тут: http://www.forum.mista.ru/topic.php?id=341168 и в документации file:///c:/Program%20Files/1cv81/AddDoc/RU/V8AddDoc81.htm
Обычно веб-сервис работает под одним конкретным пользователем (чаще - специально созданным). Можно пользователя 1С "прикрепить" средствами Windows-аутентификации к пользователю Windows IUSR_ (для пользователя отключить авторизацию 1С). Как вариант, можно очистить список пользователей 1С, тогда авторизация не требуется.
Если требуется несколько пользователей, то можно создать несколько логинов для веб-сервера, к каждому из них привязать пользователя Windows и соответственно, прописать в 1С доступ к пользователям Windows.
В свойствах Пользователь и Пароль объекта WSПрокси используется не логин 1С, а логин пользователя веб-сервера.
Для тестирования 1С как веб-сервиса используйте обработку «ТестПроизвольногоВебСервиса.epf», как описано в разделе «Тестирование работающего внешнего веб-сервиса».
Файл 1cws и является WSDL-описанием веб-сервиса 1С.
Обычно в рознице сервисы используются для оказания различных услуг населению - прием платежей, погашение кредитов, денежные переводы, покупка программного обеспечения и т.п.
При этом по оказанной услуге в 1С формируется чек, в котором сохраняются параметры транзакции. После чего этот чек распечатывается клиенту с подробной информацией об оказанной услуге. Возможна печать предварительного чека, для того, чтобы клиент подтвердил введенные с его слов данные своей подписью.
Сервис может быть по-разному интегрирован в розничную программу, написанную на языке 1С (УТ, Розница и другие):
Для хранения информации о транзакции в чеке необходимо создать дополнительную табличную часть «Сложные продажи» с реквизитами:
Справочник «Сложные продажи: Параметры» содержит перечень параметров транзакции.
Табличную часть выгоднее использовать, чем набор реквизитов, т.к. у транзакции их может быть очень много, а в других чеках, не связанных с сервисом, эти реквизиты не будут использоваться, и будут занимать лишнее место. Кроме того, такое решение универсально для любого сервиса и не требует реструктуризации данных после внедрения нового сервиса.
Продавцу делается отдельная закладка (или печатная форма, чтобы не менять конфигурацию), в которой он может посмотреть табличку реквизитов транзакции для чека.
Рассмотрим на примере условной услуги Paym для конфигурации «Розница».
Отдельный вопрос - как обеспечить завершенность транзакции. Т.е. если транзакция прошла в сервисе, как сделать, чтобы она не потерялась в 1С. Наиболее оптимальный путь - сверка реестров. Но это предмет отдельного рассмотрения.
Часто в веб-сервисах используется XDTO. Приведем наиболее важные советы и рецепты по использованию XDTO в 1С.
XDTO-пакеты, описанные в ветке «XDTO-объекты» конфигурации, доступны для создания типов и объектов в глобальной фабрике Фабрика XDTO. Это не сразу становится очевидным.
Некоторые типы в схеме не имеют имени, чтобы их получить, надо пройтись по иерархии типов.
В примере был описан список System, содержавший структуры XDTO. Чтобы создать саму структуру, нужно было получить ее тип таки вот образом:
Тип = Фабрика.Тип("urn:my.ru:MasterData:Business", "Business").Свойства.Получить("System").Тип;
В некоторых форматах теги называются xs:, в некоторых xsd:, но 1С благополучно понимает оба формата. Однажды была ситуация, что XSD нормально без ошибок импортировалась в 1С, но не создавала ни одного пакета. Причина была в отсутствии атрибута targetNamespace у тега, соответственно 1С не знала, в какой пакет помещать схему, но ошибок не выдавала.
Учитывая, что сервис - это совокупность двух систем - 1С и внешней, ошибки могут быть в обоих системах, что снижает общую надежность работы.
Для того, чтобы проще было разбираться в причинах отказов в работе сервисов, рекомендуется использовать комплекс мер.
В наше время редко современное приложение обходится без API. Это справедливо как для простого сайта так и для высоконагруженных распределенных систем. Тестирование API — является одной из главных задач в процессе обеспечения качества. Неудивительно, что спрос на тестировщиков, которые умеют тестировать API повышается изо дня в день. На данном курсе вы получите понимание о методах, инструментах и подходах в тестировании API, приобретете необходимые знания, что несомненно благоприятно отразится на Вашей стоимости как специалиста в тестировании.
Данный курс будет полезен слушателям знакомым с основами тестирования ПО, которые хотят расти дальше и повышать свои навыки.
Программа курса:
Занятие 1. Вводная. Протокол SOAP
Занятие 2: Протокол SOAP. Архитектура REST
Занятие 3. Знакомство с SoapUI. Работа с REST проектом
Занятие 4. Работа с REST проектом (XML)
Занятие 5. Работа с REST проектом (JSON)
Занятие 6. Работа с Groovy скриптами
Занятие 7. Дополнительные возможности
Использование программы Web Services Validation Tool for WSDL and SOAP
По всей видимости, с приходом новых технологий и стандартов, таких как XML и HTTP, Web-сервисы обеспечили себе место в пантеоне интернет-инноваций. Но как возникла эта инновация?
Основную концепцию Web-сервисов можно проследить в США до середины 1960-х годов. В транспортной отрасли, например, в железнодорожных и судоходных компаниях, была представлена новая концепция обмена электронными данными между компьютерами, развившаяся далее в технологию EDI (Electronic Data Interchange – обмен электронными данными). Впервые я услышал о EDI от профессора бизнес-школы в 1980 году.
В 1996 году Национальный институт стандартов и технологий США анонсировал стандарт для EDI в издании Federal Information Processing Standards Publications (FIPS PUB 161-2). Согласно опубликованной спецификации, EDI является стандартом обмена строго отформатированными сообщениями между компьютерами. Обработка принимаемых сообщений осуществляется только компьютером, и эти сообщения обычно не предназначены для интерпретации человеком. Это именно то, чем занимаются Web-сервисы, за исключением того, что в середине 1960-х годов не существовало XML, Интернета и World Wide Web.
Для тех, кто не очень знаком с Web-сервисами, я вкратце рассмотрю определения и основные компоненты Web-сервисов.
Web-сервис – это программная система, предназначенная для поддержки межмашинных взаимодействий между вычислительными ресурсами по сети и использующая SOAP-сообщения (Simple Object Access Protocol), определенные консорциумом World Wide Web Consortium.
Simple Object Access Protocol (SOAP) – это простой расширяемый протокол, по которому происходит обмен структурированными и типизированными сообщениями в децентрализованной, распределенной сетевой среде. SOAP-сообщения записываются в формате языка Extensible Markup Language (XML) - простом и гибком текстовом формате, берущем начало от языка Standard Generalized Markup Language (SGML), который был разработан организацией International Organization for Standardization (ISO 8879:1986).
Web Services Description Language (WSDL) – это основанный на XML язык, на котором описывается интерфейс Web-сервисов.
Что произойдет при обмене ошибочными SOAP-сообщениями? Что произошло бы, если бы ошибочное SOAP-сообщение было обработано без предупреждения и даже использовалось для генерирования информации, предназначенной для принятия решения?
На практике невозможно сказать, корректны или нет данные в SOAP-сообщении. Однако можно проверить SOAP-сообщение на корректность, просмотрев его определение интерфейса или WSDL.
В реальной жизни отладить проблемы в SOAP-сообщениях очень непросто. Если в SOAP-сообщении имеется какая-то ошибка, от сервера Web-сервисов принимается код HTTP-ответа 500. Серверы Web-сервисов не предоставляют подробную информацию о том, в какой части SOAP-сообщения имеется проблема. Можно столкнуться с еще худшей ситуацией, когда от сервера Web-сервисов принимаются корректные SOAP-ответы без каких-либо сообщений об ошибках, и ни вы, ни ваши серверы Web-сервисов не могут понять проблемы в ваших SOAP-запросах и ответах. Например, вы хотели запросить текущие котировки акций компании B, но отправили на сервер Web-сервисов SOAP-сообщение с неправильно написанными тегами. Сервер Web-сервисов может проигнорировать неправильные теги и предоставить в ответном SOAP-сообщении значение по умолчанию, например, котировку акций компании A. Если это остается незамеченным, последствия могут быть катастрофическими.
Проблемы такого типа можно заблаговременно предотвратить при помощи инструмента Web Services Validation Tool for WSDL and SOAP. Он позволяет проверять корректность SOAP-сообщений, используя язык Web Service Definition Language (WSDL), еще до развертывания приложений, использующих Web-сервис. Программа анализирует синтаксис и корректность ваших SOAP-сообщений с WSDL и указывает на проблемы, подробно сообщая об ошибках и номерах строк. В результате вы больше не получаете раздражающие сообщения HTTP 500. Ваши SOAP-сообщения зашифрованы? Нет проблем. Программа дешифрует их и проверит для вас корректность дешифрованных SOAP-сообщений.
Эта программа была создана в помощь сотрудникам отдела поддержки IBM Web Services, решающим связанные с Web-сервисами проблемы на сервере IBM® WebSphere Application Server, о которых сообщают клиенты со всего мира. Программа предназначена для проверки корректности SOAP-сообщений. Если SOAP-сообщение имеет цифровую подпись, программа проверит и ее. С помощью Web Services Validation Tool for WSDL and SOAP можно даже отправлять SOAP-сообщения на серверы Web-сервисов и принимать ответные SOAP-сообщения. Программа была создана для того, чтобы исключить проблемы при промышленной эксплуатации за счет использования ее на ранних стадиях разработки, а также для того, чтобы уменьшить время решения проблем, возникающих в процессе эксплуатации.
Мы создадим очень простой Web-сервис. Сначала мы создадим простое Java™-приложение. После проверки работы Java-приложения мы с помощью IBM Rational® Application Developer for WebSphere® Software сгенерируем Web-сервис. Затем мы внесем некоторые изменения в сгенерированный Web-сервис. Наконец, мы используем программу Web Services Validation Tool for WSDL and SOAP для создания, проверки, передачи и приема SOAP-сообщений.
Простой Web-сервис можно создать при помощи программы IBM Rational Application Developer for WebSphere Software. Web-сервисы можно создавать двумя путями:
В следующем примере мы реализуем Web-сервис, используя метод разработки снизу вверх. Сначала мы создадим простое Java-приложение. Затем мы сгенерируем Web-сервис Java bean-компонента из Java-приложения, используя программу IBM Rational Application Developer for WebSphere Software.
Сначала мы создадим Java-приложение, выдающее приветствие. Если имя не указано, приложение возвратит текст "Hello, buddy!". Если имя указано, приложение возвратит текст "Hello,", за которым следует это имя. Ниже приведен код Java-приложения DemoWebService, находящегося в демонстрационном пакете. Метод hello() возвращает строку, зависящую от имени.
Очень важно протестировать Java-приложение перед созданием из него Web-сервиса. Для запуска приложения можно написать класс с методом main(). Можно также использовать функциональность Universal Test Client, предоставляемую продуктом IBM Rational Application Developer v7, для быстрого тестирования без написания тестового кода. Достаточно просто выбрать Universal Test Client из контекстного меню Java-класса для запуска Test Client.
Можно также выполнить тест, указав параметр null, и посмотреть, что произойдет. Если в метод hello() передается параметр null, возвращается строка "Hello, buddy!", как и ожидалось.
Пока все работает хорошо. Приступим к генерированию Web-сервиса из Java-класса, используя метод разработки Web-сервисов снизу вверх.
Если все прошло нормально, вы увидите в Java Resources рядом с DemoWebService.java сгенерированный DemoWebServiceDelegate.java.
При просмотре DemoWebServiceDelegate.java можно обнаружить аннотацию Java Web-сервиса @javax.jws.WebService, которая указывает targetNamespace, serviceName и portName в классе DemoWebServiceDelegate. Создается экземпляр DemoWebService и из метода hello()DemoWebService создается другой метод hello(). При желании более подробно узнать об аннотациях Java Web-сервисов обратитесь к документу Java Specification Request(JSR) 181. Метаданные Web-сервисов для платформы Java.
В проекте клиентской программы можно также обнаружить, что были сгенерированы файлы DemoWebServiceService.wsdl и DemoWebServiceService_schema1.xsd. DemoWebServiceService.wsdl содержит информацию на языке Web Service Definition Language, описывающую сетевые сервисы для созданного ранее Java-приложения. DemoWebServiceService_schema1.xsd содержит XML-схему, описывающую структуру типов данных, использующихся в SOAP-сообщениях.
При просмотре файла DemoWebServiceService.wsdl можно увидеть, что он имеет в корне набор элементов определений (definitions element). В элементе определений имеются 6 элементов:
Types определяет типы данных, используемые при обмене сообщениями. В DemoWebServiceService.wsdl мы импортируем DemoWebServiceService_schema1.xsd вместо определения типов данных в WSDL-файле.
Message определяет сообщения, обмен которыми происходит. У нас есть 2 сообщения: "hello" и "helloResponse". Сообщение hello имеет часть, называемую "parameters". Эта часть имеет элемент "tns:hello". Сообщение helloResponse имеет часть, называемую "parameters", которая аналогична hello. Эта часть имеет элемент "tns:helloResponse". Элементы hello и helloResponse определяются в файле DemoWebServiceService_schema1.xsd. Мы вскоре их рассмотрим.
Port Type – поддерживаемые оконечными точками операции. Каждая операция предоставляет входное и выходное сообщения. Наша операция "hello" состоит из входного сообщения "tns:hello" и выходного сообщения "tns:helloResponse". Эти операции соответствуют обмену запрос-ответ. WSDL предоставляет 4 различных примитива обмена для оконечной точки:
При однонаправленном обмене оконечная точка только принимает сообщение. При обмене "запрос-ответ" оконечная точка принимает сообщение и отправляет соответствующее сообщение. При обмене «требование-ответ» оконечная точка отправляет сообщение и принимает соответствующее сообщение. При обмене "уведомление" оконечная точка только отправляет сообщение.
Binding определяет детали протокола и спецификации формата сообщений для операций и сообщений, определяемых типом порта. Для атрибута style у нас используется значение document. Атрибут style предоставляет 2 различных стиля сообщения: rpc и document. В стиле rpc сообщения содержат параметры и возвращаемые значения. В стиле document сообщения содержат документы. В атрибуте transport указывается URI для транспортировки SOAP. Указанное значение http://schemas.xmlsoap.org/soap/http означает, что в спецификации SOAP будет использоваться HTTP-связывание. URI для HTTP-заголовка SOAPAction для HTTP-связывания SOAP указывается в атрибуте soapAction. Поскольку используется HTTP-связывание SOAP, значение атрибута soapAction является обязательным. Для атрибута soapAction мы используем пустую строку "". Элемент soap:body определяет, как компонуются части сообщения внутри элемента body SOAP-сообщения. Атрибут use предоставляет 2 различных варианта: literal (литерал) и encoded (закодированный). Мы используем literal. Это означает, что мы выбрали определение конкретной схемы, используя либо атрибут type, либо элемент. При использовании варианта encoded применяется тип abstract с правилами кодирования.
Service определяет набор используемых портов.
Port определяет оконечную точку коммуникации, указывая сетевой адрес для связывания.
сетевой адрес для связывания. В нашем случае адресом оконечной точки SOAP является http://localhost:9081/HelloWorldWSProject/DemoWebServiceService .
Мы импортируем DemoWebServiceService_schema1.xsd из DemoWebServiceService.wsdl. Рассмотрим файл DemoWebServiceService_schema1.xsd. Он написан на языке определения XML Schema для описания структуры и ограничений содержимого XML-документов. У нас есть 2 элемента: hello и helloResponse. Каждый элемент имеет тип. Тип hello имеет элемент "arg0", являющийся строкой. Элемент "arg0" является необязательным, поскольку значение атрибута minOccurs в его объявлении равно 0. Если для атрибута minOccurs задано значение 1 или больше, элемент необходимо указывать. То же касается элемента "return" в типе helloResponse.
Итак, мы рассмотрели WSDL и схему. Давайте запустим сервер Web-сервисов, чтобы можно было активизировать Web-сервис из программы Web Services Validation Tool for WSDL and SOAP.
Для запуска программы Web Services Validation Tool for WSDL and SOAP необходима среда времени исполнения Java 6 (или выше) и API цифрового кодирования и декодирования XML, соответствующие спецификациям консорциума World Wide Web Consortium "XML Encryption Syntax and processing" (http://www.w3.org/TR/xmlenc-core/).
IBM Java 6 предоставляет реализацию JSR 106: XML Digital Encryption APIs. Если у вас установлена система IBM Java 6, значит, все готово для работы и устанавливать больше ничего не нужно.
Если в вашей среде времени исполнения Java 6, например, Sun Microsystems™ Java 6, нет XML Digital Encryption APIs, необходимо установить библиотеки, реализующие JSR 106, или пакет Apache™ XML Security version 1.4.3, который можно скачать по адресу http://santuario.apache.org/ . Достаточно просто загрузить двоичный дистрибутив, разархивировать его в каталог и указать инструментальной программе, где находится этот каталог, используя параметры командной строки -vmargs и -DAXS.
На момент написания данной статьи программа Web Services Validation Tool for WSDL and SOAP поддерживала JSR 106 и Apache XML Security version 1.4.3 для XML Digital Encryption and Decryption. Если вы хотите проверять цифровые подписи в SOAP-сообщениях, вам необходимы библиотеки, реализующие JSR 105: XML Digital Signature APIs. К счастью, виртуальные машины Java 6 от Sun Microsystems и IBM предоставляют реализации JSR 105. Именно поэтому Java 6 был выбран в качестве минимального требования к среде времени исполнения Java. Если ваша среда Java 6 не предоставляет библиотек, реализующих JSR 105, вам необходимо их найти.
Программу Web Services Validation Tool for WSDL and SOAP можно скачать по адресу бесплатно. Установка ее очень проста. Разархивируйте пакет в каталог и запустите wsvt.exe. Если ваша виртуальная машина Java по умолчанию не является средой Java 6, поддерживающей цифровые подписи XML и цифровое шифрование и дешифрование, необходимо указать месторасположение Java 6 с параметром -vm, например:
wsvt –vm c:\IBMjava6\bin\java.exe
Опять-таки, если у вас есть IBM Java 6, больше ничего устанавливать не нужно. Все необходимое уже включено в IBM Java 6. При использовании Java 6 от Sun Microsystems необходимо указать программе месторасположение Apache XML Security для дешифрования зашифрованных SOAP-сообщений.
Например, следующая команда запустит программу с Sun Java 6 и Apache XML Security library version 1.4.3, расположенную в каталоге C:\xml-security-1_4_3\libs:
wsvt –vm c:\SUNjava6\bin\java.exe –vmargs –DAXS=C:\xml-security-1_4_3\libs
Ниже приведен список файлов библиотеки Apache XML security, фактически использующихся программой Web Services Validation Tool for WSDL and SOAP, хотя Apache XML security version 1.4.3 поставляется с 9-ю jar-файлами:
commons-logging.jar;
serializer.jar;
xalan.jar;
xmlsec-1.4.3.jar.
В MANIFEST.MF программы Web Services Validation Tool for WSDL and SOAP указана следующая информация:
Bundle-ActivationPolicy:
lazy
Bundle-ClassPath:
.,
external:$AXS$/commons-logging.jar,
external:$AXS$/serializer.jar,
external:$AXS$/xalan.jar,
external:$AXS$/xmlsec-1.4.3.jar
Вот почему было необходимо указывать –vmargs –DAXS=C:\xml-security-1_4_3\libs, чтобы среда Sun Java 6 дешифровала зашифрованные SOAP-сообщения.
Я потратил довольно много времени на устранение конфликтов загрузки классов и несовместимостей среди относящихся к XML классов, находящихся в среде времени выполнения Sun Java, Apache XML Security и некоторых плагинах Eclipse. Настройка среды времени исполнения IBM Java прошла без труда, поскольку эта среда поставляется с реализацией JSR 106 и не требует Apache XML Security.
Теперь, после настройки и запуска инструментальной программы, можно создать новый проект. В проекте могут содержаться WSDL-файл, несколько файлов схемы, ассоциированных с WSDL-файлом, и SOAP-сообщения в XML-файлах. Если в проекте имеется несколько WSDL-файлов, используется только один из них, а другие игнорируются при проверке корректности XML-файла SOAP-сообщения. Для использования другого WSDL-файла необходимо создать отдельный проект. Каждое SOAP-сообщение должно содержаться в файле с расширением.xml, иначе оно не будет рассматриваться как SOAP-сообщение.
Мы создали проект "Test Project". Теперь в него можно импортировать WSDL и XSD.
Теперь у нас есть проект с WSDL и XSD. Можно дважды щелкнуть левой кнопкой мыши на WSDL для просмотра WSDL в режиме Design (проектирование) и Source (исходный код). В режиме Design можно визуализировать Web-сервис с входными и выходными данными.
В режиме Source можно просматривать и редактировать WSDL в текстовом редакторе.
Если XSD-файлы нельзя открыть в XSD-редакторе, их можно открыть в XML-редакторе, выбрав Open With > XML Editor в контекстном меню этого XSD-файла.
Мы открыли DemoWebServiceService_schema1.xsd в XML-редакторе.
Итак, у нас есть WSDL и схема, готовые для проверки корректности SOAP-сообщений. Приступим к тестированию программы Web Services Validation Tool for WSDL and SOAP с SOAP-сообщением. Необходимо включить SOAP-сообщение в проект. SOAP-сообщение должно содержаться в файле с расширением.xml, чтобы можно было проверить его корректность.
Программа автоматически вызывает XML-редактор с новым XML-файлом. В нем нет ничего, кроме строки с версией и кодировкой xml. Хорошо, что у нас есть хоть что-нибудь до начала создания SOAP-сообщения с нуля. Вы знаете, как составлять SOAP-сообщение? Не беспокойтесь. В следующем разделе мы по шагам рассмотрим действия по его созданию.
Для создания SOAP-сообщения можно активизировать "hello" сервиса, используя параметр "parameters" с указанием моего имени - "Jinwoo". Конечно же, вы можете использовать свое собственное имя. Используется пространство имен http://demo/ . Будьте внимательны - оно пишется как http://demo/ , а не http://demo , это существенно.
Вы видите в этом SOAP-сообщении проблемы? Если да, не беспокойтесь. Мы разберемся с этим позже.
Вы готовы отправить сообщение на сервер Web-сервисов?
Если сервер настроен и работает, вы должны получить SOAP-ответ. Если ответ не приходит, проверьте корректность адреса и типа содержимого.
Отлично! Мы приняли SOAP-ответ. Он также сохраняется в проекте. Но подождите. Вы видите, что что-то не так? Мы получили "Hello, buddy!" вместо "Hello, Jinwoo!". Что пошло не так? Не имеете понятия?
К сожалению, сервер Web-сервисов не позволил нам узнать, что было не так. Никаких предупреждений. Ситуация, когда отправляются непредсказуемые SOAP-ответы и сервер Web-сервисов не имеет понятия, что происходит не так, может быть очень опасной. Даже получатели SOAP-ответов могут не заметить проблем в рассматриваемом SOAP-сообщении.
Инструмент Web Services Validation Tool for WSDL and SOAP позволяет определить, что происходит не так.
Программа Web Services Validation Tool for WSDL and SOAP нашла ошибку в SOAP-сообщении.
Invalid SOAP message:cvc-complex-type.2.4.a:Invalid content was found starting with element "parameters". One of "{arg0} is expected.В этот раз, как и ожидалось, приходит правильный ответ.
Что произойдет, если отправить сообщение с неправильным пространством имен?
Вы увидите исключительную ситуацию IOException: Server returned HTTP response code:500 for URI: http://localhost:9081/HelloWorldWSProject/DemoWebServiceService .
Сервер Web-сервисов передал в ответе информацию об исключительной ситуации IOException, но этой информации недостаточно для обнаружения ошибки. Проверьте корректность сообщения при помощи инструментальной программы, если хотите получить более подробные данные для решения проблемы.
Программа сообщает: "Invalid SOAP message:cvc-complex-type.2.4.a:Invalid content was found starting with element ‘ns0:hello". One of "{"http://demo/":hello,"http://demo/":helloResponse}" is expected".
Это сообщение указывает, что ожидается значение http://demo/ . Именно это, а не HTTP-код ответа 500, нам нужно узнать.
Что если ваши SOAP-сообщения зашифрованы? Никаких проблем, если у вас имеются ключи и пароли. Просто выберите SOAP-сообщение и Validate точно так же, как это делается для любых других обычных SOAP-сообщений. Если ваше SOAP-сообщение зашифровано, на экране появится запрос, аналогичный показанному на рисунке 35.
На момент написания данной статьи поддерживается 3 типа хранилищ ключей (keystore):
Необходимо предоставить информацию о вашем хранилище ключей: имя файла, тип файла и пароль. Если информация верна, необходимо выбрать ключ и пароль. Можно также найти информацию о ваших хранилищах ключей и списке ключей и сертификатов в хранилище ключей, например, тип хранилища ключей, имя провайдера, версия провайдера, информация провайдера, тип ключа, дата создания, тип сертификата, алгоритм и формат.
Если вся информация верна, программа сгенерирует дешифрованное SOAP-сообщение и проверит его корректность.
В настоящее время поддерживаются следующие алгоритмы шифрования:
Что если ваше SOAP-сообщение имеет цифровую подпись? Просто выберите SOAP-сообщение, а затем выберите SOAP Message Digital Signature Verification .
Если цифровая подпись корректна, вы увидите следующий экран:
В противном случае программа сообщит об ошибке в подписи. В настоящее время поддерживаются следующие спецификации и алгоритмы цифровых подписей:
Созданный и протестированный нами простой Web-сервис работает нормально. Можно ли использовать данную программу в "реальной" среде? Можно попробовать поработать с реальным Web-сервисом Национального метеобюро США, предоставляемым организацией U.S. National Oceanic and Atmospheric Administration (NOAA).
Национальное метеобюро США предоставляет много разных Web-сервисов. Можно попробовать поработать с сервисом NDFDgenByDay, предоставляющим прогнозы погоды для точки с заданной широтой и долготой.
Для доступа к NDFDgenByDay необходимо предоставить следующую информацию:
Service Name (имя сервиса) | NDFDgenByDay |
---|---|
Endpoint (оконечная точка) | http://www.weather.gov/forecasts/xml/SOAP_server/ndfdXMLserver.php |
SoapAction (SOAP-действие) | http://www.weather.gov/forecasts/xml/DWMLgen/wsdl/ndfdXML.wsdl#NDFDgenByDay |
encodingStyle (стиль кодирования) | http://schemas.xmlsoap.org/soap/encoding/ |
Namespace (пространство имен) | http://www.weather.gov/forecasts/xml/DWMLgen/wsdl/ndfdXML.wsdl |
latitude (широта) | Десятичное число |
longitude (долгота) | Десятичное число |
startDate (начальная дата) | Дата |
numDays (количество дней) | Целое число |
format (формат) | Строка |
В данном примере мы хотим создать SOAP-запрос на получение недельного прогноза для местности с координатами (LAT38.9,LON-77.01), начиная с 2010-07-23 в 24-часовом формате:
Мы не указывали пространство имен, потому что сервис работал без него. Если с пространством имен возникнут какие-либо проблемы, задайте его.
Выберите сообщение и Transmit SOAP Request and Receive SOAP Response в программе Web Services Validation Tool for WSDL and SOAP.
Имя | Значение |
---|---|
Endpoint (оконечная точка) | http://www.weather.gov/forecasts/xml/SOAP_server/ndfdXMLserver.php |
SoapAction (SOAP-действие) | http://www.weather.gov/forecasts/xml/DWMLgen/wsdl/ndfdXML.wsdl#NDFDgenByDay |
Content-type (тип содержимого) | text/xml; charset=utf-8 |
Теперь данные прогноза стало значительно легче читать.
Если этот совет покажется вам не слишком удобным, можете использовать свой собственный метод форматирования HTML. Большинство Web-сервисов предлагает результаты в XML-формате, поэтому вам не придется прибегать к этому приему постоянно.
Мы создали, преобразовали, приняли и проверили корректность SOAP-сообщений, используя программу Web Services Validation Tool for WSDL and SOAP. Эта программа позволяет точно определить проблемы, которые большинство серверов Web-сервисов даже не способно обнаружить, что может привести к серьезным последствиям в реальной жизни. Использование этой программы на этапе разработки позволяет сократить время устранения проблем в ходе эксплуатации.