Тестирование web сервисов. Что такое Web-сервисы

Веб-сервисы в 1С

В данной статье будет рассмотрены вопросы интеграции 1С с уже существующими веб-сервисами и использование самой 1С как веб-сервиса.

При этом под веб-сервисами будет пониматься системы, работающие в интернете и обеспечивающие взаимодействие с ними не только по SOAP (что является именно веб-сервисом), но и другими способами, включая обычные HTTP(S)-запросы.

Риски использования веб-сервисов 1С

В платформе 1С81 появилась реализация веб-сервисов.

Но их использование чревато рисками:

1. 1С8 плохо работает через HTTPS, средства диагностики отсутствуют, поэтому понять, почему при наличии сертификата сервис не хочет работать через HTTPS порой невозможно. Выход - реализация веб-сервисов через CURL или поднятие HTTPS-туннеля.
2. 1С8 придерживается своих правил валидации WSDL-схем. Порой по необъяснимым причинам WSDL-схема не хочет загружаться в WS-ссылку. Узнать причину можно только на партнерском форуме у одного специалиста. Средства диагностики WSDL-схемы отсутствуют, не указывается даже причина или строка, на которой прерывается загрузка схемы.

Правила построения сервисов по продаже

Клиенту выдается документ о продаже (чек) только в том случае, если транзакция по сервису прошла успешно. Иначе возможна ситуация, когда клиент получит чек и будет пребывать в уверенности, что получил услугу, а на самом деле это не так.

Использование внешних SOAP-сервисов

Веб-сервисы SOAP используют WSDL схемы и объекты XDTO для представления данных.

Загрузка WSDL

Для того, чтобы использовать внешний сервис, нужно загрузить его WSDL-схему.

Проверка валидности WSDL-схемы

Иногда WSDL-схема не загружается в 1С. Проверить валидность (правильность) схемы можно любым валидатором WSDL-схем, например http://www.validwsdl.com/ .

Нужно загрузить схему на какой-нибудь http-сайт (можно по ftp) и указать адрес файла, в который загружена схема:

Особенности загрузки WSDL в 1С

Особенность загрузки WSDL в 1С в том, что валидные схемы могут не загружаться. Никакого встроенного валидатора нет, поэтому приходится искать ошибку методом деструктивного анализа, последовательно уменьшая количество элементов в схеме. Можно, например, удалить описание веб-сервиса.

Обработка для тестирования работающего внешнего веб-сервиса

Для тестирования работающего внешнего веб-сервиса используйте обработку «ТестПроизвольногоВебСервиса.epf» из пакета к этой статье.

Тестирование можно использовать на примере сервиса Morpher , склоняющего имена (адрес сервиса http://www.morpher.ru/WebServices/Morpher.asmx?WSDL):

Таким способом можно протестировать любой сервис, который имеет простые точки входа, содержащие параметры простых типов: число, дата, строка.

В обработке можно указать также логин и пароль, которые требуются для авторизации доступа к веб-сервису.

Стандартные средства отладки сервисов

Для отладки можно использовать программу SoapUI, который может передать произвольный запрос веб-сервису и получить от него ответ.

SOAP и HTTPS

К сожалению, SOAP в 1С достаточно капризно ведет себя при работе через протокол HTTPS, практика показывает, что добиться HTTPS соединения невозможно, хотя возможность и продекларирована в платформе. Сказывается отсутствие средств диагностики и отладки для выяснения причин, из-за которых не устанавливается соединение. Поэтому удобно использовать SOAP через CURL.

Встроенный механизм использования HTTPS подразумевает, что все сертификаты должны быть опубликованы в общем файле pem в каталоге программы 1С.

Использование 1С как сервиса

Правила разработки сервиса на базе 1С

Операция «Hello»

Правилом хорошего тона является создание в сервисе операцию, которая информирует о том, что сервис доступен. Это облегчает жизнь интеграторов, им будет проще проверять, налажена ли связь с сервисом.

Например, можно использовать операцию Hello без параметров, которая просто возвращает булево значение Истина.

Публикация веб-сервиса

Процедура хорошо описана в документации: file:///C:/Program%20Files/1cv81/AddDoc/RU/V8AddDoc81.htm#_Toc176167634 :

Задача публикации Web-сервисов сводится к размещению конфигурационных файлов *.1cws Web-сервисов в соответствующем каталоге веб-сервера с соответствующими настройками для веб сервера. Для того, чтобы выполнить публикацию Web-сервисов, следует выполнить команду меню «Администрирование | Публикация Web-сервисов».

В результате выполнения этой команды будет открыто окно публикации Web-сервисов.

Окно публикации Web-сервисов содержит путь к веб-серверу и два списка:

• «Web-сервисы» - список Web-сервисов конфигурации;
• «Публикация» - список Web-сервисов, опубликованных на указанном веб-сервере.

С помощью кнопки «Соединение…» следует указать веб-сервер, на котором требуется опубликовать Web-сервисы.

Окно выбора пути к веб-серверу позволяет указать путь двумя способами:

• на закладке «Файлы» - этот способ используется в том случае, когда публикация выполняется на том же компьютере, на котором установлен веб-сервер. В качестве пути указывается локальный каталог, соответствующий интернет-странице, с которой будет выполняться вызов публикуемого Web-сервера;
• на закладке «FTP сайт» - этот способ используется в том случае, когда требуется опубликовать Web-сервис на удаленном компьютере. Для выполнения публикации необходимо указать параметры FTP-соединения с удаленным компьютером и каталог, в котором будет опубликован Web-сервис.

Публикация выбранного Web-сервиса осуществляется с помощью кнопки «Опубликовать»

Для отмены публикации Web-сервиса используется кнопка «Удалить».

Публиковать можно в локальном каталоге или по FTP. Можно публиковать и на удаленный сервер по UNC-пути, если удаленный сервер входит в локальную сеть.

После публикации веб-сервис доступен по адресу «http://localhost/test.1cws» или «http://xxx.ru/test.1cws», где xxx.ru - адрес удаленного сервера а localhost - типовой адрес локального сервера.

Авторизация к веб-сервису 1С

Для доступа к сервису нужно пройти аутентификацию.

Вопросы авторизации хорошо рассмотрены тут: 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С

Для тестирования 1С как веб-сервиса используйте обработку «ТестПроизвольногоВебСервиса.epf», как описано в разделе «Тестирование работающего внешнего веб-сервиса».

Файл 1cws и является WSDL-описанием веб-сервиса 1С.

Использование сервисов в Рознице

Обычно в рознице сервисы используются для оказания различных услуг населению - прием платежей, погашение кредитов, денежные переводы, покупка программного обеспечения и т.п.

При этом по оказанной услуге в 1С формируется чек, в котором сохраняются параметры транзакции. После чего этот чек распечатывается клиенту с подробной информацией об оказанной услуге. Возможна печать предварительного чека, для того, чтобы клиент подтвердил введенные с его слов данные своей подписью.

Сервис может быть по-разному интегрирован в розничную программу, написанную на языке 1С (УТ, Розница и другие):

1. Может быть написана обработка или код на языке 1С, который выполняет всю работу с сервисом.
2. Может использоваться программа, которая работает с сервисом, а в 1С передает только информацию для пробития чеков.

Организация служебных данных в 1С

Для хранения информации о транзакции в чеке необходимо создать дополнительную табличную часть «Сложные продажи» с реквизитами:

• Номенклатура - привязка к номенклатуре чека.
• Параметр - ссылка на справочник «Сложные продажи: Параметры».
• Значение - значение параметра, составного типа. Строковое представление должно быть довольно длинным (1024 символа), чтобы помещался текст чека.

Справочник «Сложные продажи: Параметры» содержит перечень параметров транзакции.

Табличную часть выгоднее использовать, чем набор реквизитов, т.к. у транзакции их может быть очень много, а в других чеках, не связанных с сервисом, эти реквизиты не будут использоваться, и будут занимать лишнее место. Кроме того, такое решение универсально для любого сервиса и не требует реструктуризации данных после внедрения нового сервиса.

Продавцу делается отдельная закладка (или печатная форма, чтобы не менять конфигурацию), в которой он может посмотреть табличку реквизитов транзакции для чека.

Использование обработок на языке 1С

Рассмотрим на примере условной услуги Paym для конфигурации «Розница».

1. Заведем в 1С предопределенный элемент справочника номенклатуры «Paym». В режиме 1С:Предприятия после обновления конфигурации ему нужно назначить вид товара «Услуга».
2. В процедуре «Добавить номенклатуру в таб. часть» модуля формы «Регистрация продаж» вызываем обработку работы с сервисом, написанную на языке 1С. В случае успешного осуществления платежа записываем и проводим чек:

Если (Номенклатура = Справочники.Номенклатура.Paym) И (ВидОперации Перечисления.ВидыОперацийЧекККМ.Возврат) Тогда ОбработкаПлатежа = Функции.ДатьВнешнююОбработку("Paym"); ФормаПлатежа = ОбработкаПлатежа.ПолучитьФорму(); Результат = ФормаПлатежа.ОткрытьМодально(); Если Результат = Неопределено Тогда Возврат; КонецЕсли; ЭтотОбъект.Записать(РежимЗаписиДокумента.Проведение); КонецЕсли;

1. Обработка должна напечатать предчек (если требуется), заполнить табличную часть сложных продаж и подготовить текст печати чека в предопределенном реквизите «PaymТекстЧека».
2. В процедуре «Провести и распечатать чек» модуля чека подменяем наименование товара на сохраненное в реквизите для чека. Текст подменяется только для продажи, для возврата печатается просто название услуги, как обычно.

ИначеЕсли ВидОперации Перечисления.ВидыОперацийЧекККМ.Возврат И Выборка.НомеклатураСсылка = Справочники.Номенклатура.Paym Тогда //Осипов PaymMaster СтрокаСложныхПродаж = СложныеПродажи.Найти(Справочники.СложныеПродажиПараметры.PaymТекстЧека, "Реквизит"); Если СтрокаСложныхПродаж Неопределено Тогда Товар.Наименование = СокрЛП(СтрокаСложныхПродаж.Значение); КонецЕсли;

Отдельный вопрос - как обеспечить завершенность транзакции. Т.е. если транзакция прошла в сервисе, как сделать, чтобы она не потерялась в 1С. Наиболее оптимальный путь - сверка реестров. Но это предмет отдельного рассмотрения.

Использование программ, интегрируемых с 1С

XDTO

Часто в веб-сервисах используется XDTO. Приведем наиболее важные советы и рецепты по использованию XDTO в 1С.

XDTO в платформе 1С

XDTO-пакеты, описанные в ветке «XDTO-объекты» конфигурации, доступны для создания типов и объектов в глобальной фабрике Фабрика XDTO. Это не сразу становится очевидным.

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

В примере был описан список System, содержавший структуры XDTO. Чтобы создать саму структуру, нужно было получить ее тип таки вот образом:

Тип = Фабрика.Тип("urn:my.ru:MasterData:Business", "Business").Свойства.Получить("System").Тип;

Частые проблемы с XDTO

Разные форматы XSD-схем

В некоторых форматах теги называются xs:, в некоторых xsd:, но 1С благополучно понимает оба формата. Однажды была ситуация, что XSD нормально без ошибок импортировалась в 1С, но не создавала ни одного пакета. Причина была в отсутствии атрибута targetNamespace у тега, соответственно 1С не знала, в какой пакет помещать схему, но ошибок не выдавала.

Сопровождение сервисов

Учитывая, что сервис - это совокупность двух систем - 1С и внешней, ошибки могут быть в обоих системах, что снижает общую надежность работы.

Для того, чтобы проще было разбираться в причинах отказов в работе сервисов, рекомендуется использовать комплекс мер.

Протоколирование запросов

Ссылки

• XDTO
  • Хорошее описание XDTO http://pro1c.org.ua/index.php?showtopic=214
• Бесплатные интересные веб-сервисы:
  • Аэрофлот - информация о расписании самолетов
  • Морфер - склонение имен http://www.morpher.ru/WebServices/Morpher.aspx
• Неразобранные:
  • Установка и использование Веб-сервисов
    • v8: как изменить конфигурационный файл апача?
    • v8: продолжение темы с web-сервисами - не могу подключить web-сервис
    • v8: дальше ползу по веб-сервисам - не могу создать прокси...
    • Книга знаний: v8: Использование внешних web-сервисов в 1С:Предприятие 8 ;

Использование программы 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-сервисы

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-сервисы можно создавать двумя путями:

1. Разработка "сверху вниз" (top-down) разработка, при которой Java-классы, реализующие Web-сервисы, генерируются из WSDL.
2. Разработка "снизу вверх" (bottom-up), при которой Web-сервис генерируется из Java bean-компонента или корпоративного Java bean-компонента.

В следующем примере мы реализуем Web-сервис, используя метод разработки снизу вверх. Сначала мы создадим простое Java-приложение. Затем мы сгенерируем Web-сервис Java bean-компонента из Java-приложения, используя программу IBM Rational Application Developer for WebSphere Software.

Создание Java-приложения

Сначала мы создадим Java-приложение, выдающее приветствие. Если имя не указано, приложение возвратит текст "Hello, buddy!". Если имя указано, приложение возвратит текст "Hello,", за которым следует это имя. Ниже приведен код Java-приложения DemoWebService, находящегося в демонстрационном пакете. Метод hello() возвращает строку, зависящую от имени.

Листинг 1. DemoWebService.java

/* * @author: Jinwoo Hwang * Copyright 2010 IBM Corporation */ package demo; public class DemoWebService { public String hello(String name) { if (name == null) return "Hello, buddy!"; else return "Hello, " + name + "!"; } }

Тестирование Java-приложения

Очень важно протестировать Java-приложение перед созданием из него Web-сервиса. Для запуска приложения можно написать класс с методом main(). Можно также использовать функциональность Universal Test Client, предоставляемую продуктом IBM Rational Application Developer v7, для быстрого тестирования без написания тестового кода. Достаточно просто выбрать Universal Test Client из контекстного меню Java-класса для запуска Test Client.

1. В Universal Test Client разверните Objects > DemoWebService .
2. Выберите метод hello .
3. Введите строку или ваше имя в поле Value и нажмите кнопку Invoke .

Можно также выполнить тест, указав параметр null, и посмотреть, что произойдет. Если в метод hello() передается параметр null, возвращается строка "Hello, buddy!", как и ожидалось.

Создание Web-сервиса

Пока все работает хорошо. Приступим к генерированию Web-сервиса из Java-класса, используя метод разработки Web-сервисов снизу вверх.

1. Выберите Java-приложение DemoWebService и создайте новый Web-сервис из IBM Rational Application Developer.

1. Поскольку мы создали Java-класс, выберите Bottom up Java bean Web service в списке Web service type. Выберите Start client и нажмите кнопку Finish . Если бы у нас был EJB-класс, мы могли бы также написать EJB-компонент (Java Enterprise bean) для генерирования 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.

Листинг 2. DemoWebServiceDelegate.java

/* * @author: Jinwoo Hwang * Copyright 2010 IBM Corporation */ package demo; @javax.jws.WebService(targetNamespace = "http://demo/", serviceName = "DemoWebServiceService", portName = "DemoWebServicePort") public class DemoWebServiceDelegate { demo.DemoWebService _demoWebService = new demo.DemoWebService(); public String hello(String name) { return _demoWebService.hello(name); } }

Создание WSDL

В проекте клиентской программы можно также обнаружить, что были сгенерированы файлы DemoWebServiceService.wsdl и DemoWebServiceService_schema1.xsd. DemoWebServiceService.wsdl содержит информацию на языке Web Service Definition Language, описывающую сетевые сервисы для созданного ранее Java-приложения. DemoWebServiceService_schema1.xsd содержит XML-схему, описывающую структуру типов данных, использующихся в SOAP-сообщениях.

При просмотре файла DemoWebServiceService.wsdl можно увидеть, что он имеет в корне набор элементов определений (definitions element). В элементе определений имеются 6 элементов:

• types (типы);
• message (сообщение);
• portType (тип порта);
• binding (связывание);
• service (сервис);
• port (порт).

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 различных примитива обмена для оконечной точки:

• one-way (однонаправленный);
• request-response (запрос-ответ);
• solicit-response (требование-ответ);
• notification (уведомление).

При однонаправленном обмене оконечная точка только принимает сообщение. При обмене "запрос-ответ" оконечная точка принимает сообщение и отправляет соответствующее сообщение. При обмене «требование-ответ» оконечная точка отправляет сообщение и принимает соответствующее сообщение. При обмене "уведомление" оконечная точка только отправляет сообщение.

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 .

Листинг 3. DemoWebServiceService.wsdl

Создание схемы

Мы импортируем DemoWebServiceService_schema1.xsd из DemoWebServiceService.wsdl. Рассмотрим файл DemoWebServiceService_schema1.xsd. Он написан на языке определения XML Schema для описания структуры и ограничений содержимого XML-документов. У нас есть 2 элемента: hello и helloResponse. Каждый элемент имеет тип. Тип hello имеет элемент "arg0", являющийся строкой. Элемент "arg0" является необязательным, поскольку значение атрибута minOccurs в его объявлении равно 0. Если для атрибута minOccurs задано значение 1 или больше, элемент необходимо указывать. То же касается элемента "return" в типе helloResponse.

Листинг 4. DemoWebServiceService_schema1.xsd

Начало работы с программой Web Services Validation Tool for WSDL and SOAP

Итак, мы рассмотрели 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-сообщение.

1. Щелкните правой кнопкой мыши и выберите New > Project .

1. Выберите Project в General .

1. Введите "Test Project" в поле Project name и нажмите кнопку Finish .

Импорт WSDL и схемы

Мы создали проект "Test Project". Теперь в него можно импортировать WSDL и XSD.

1. Выберите проект, а затем из контекстного меню выберите Import .

1. Выберите File System в General .

1. Выберите каталог, в котором хранятся WSDL и XSD.
2. Выберите 2 файла (DemoWebServiceService.wsdl и DemoWebServiceService_schema1.xsd) и нажмите кнопку Finish .

Обзор WSDL и схемы

Теперь у нас есть проект с WSDL и XSD. Можно дважды щелкнуть левой кнопкой мыши на WSDL для просмотра WSDL в режиме Design (проектирование) и Source (исходный код). В режиме Design можно визуализировать Web-сервис с входными и выходными данными.

В режиме Source можно просматривать и редактировать WSDL в текстовом редакторе.

Если XSD-файлы нельзя открыть в XSD-редакторе, их можно открыть в XML-редакторе, выбрав Open With > XML Editor в контекстном меню этого XSD-файла.

Мы открыли DemoWebServiceService_schema1.xsd в XML-редакторе.

Создание SOAP-сообщения

Итак, у нас есть WSDL и схема, готовые для проверки корректности SOAP-сообщений. Приступим к тестированию программы Web Services Validation Tool for WSDL and SOAP с SOAP-сообщением. Необходимо включить SOAP-сообщение в проект. SOAP-сообщение должно содержаться в файле с расширением.xml, чтобы можно было проверить его корректность.

1. Выберите New > XML для создания SOAP-сообщения в проекте.

1. Выберите Test Project для родительской папки нового SOAP-сообщения. Если файл еще не выбран, введите "DemoSOAPMessage.xml" в поле File name и нажмите кнопку Finish .

Программа автоматически вызывает XML-редактор с новым XML-файлом. В нем нет ничего, кроме строки с версией и кодировкой xml. Хорошо, что у нас есть хоть что-нибудь до начала создания SOAP-сообщения с нуля. Вы знаете, как составлять SOAP-сообщение? Не беспокойтесь. В следующем разделе мы по шагам рассмотрим действия по его созданию.

Для создания SOAP-сообщения можно активизировать "hello" сервиса, используя параметр "parameters" с указанием моего имени - "Jinwoo". Конечно же, вы можете использовать свое собственное имя. Используется пространство имен http://demo/ . Будьте внимательны - оно пишется как http://demo/ , а не http://demo , это существенно.

Листинг 5. HelloWorldSOAPmessage.xml

Jinwoo

Вы видите в этом SOAP-сообщении проблемы? Если да, не беспокойтесь. Мы разберемся с этим позже.

Передача SOAP-сообщения

Вы готовы отправить сообщение на сервер Web-сервисов?

1. Выберите SOAP-сообщение и выберите

1. В окне Transmit SOAP Request and Receive SOAP Response можно заполнить Service Address , SOAPAction и Content-Type . В данном приложении нам не нужно указывать SOAPAction, поскольку мы использовали пустую строку "" для атрибута soapAction в разделе связывания файла DemoWebServiceService.wsdl.
2. Введите http://localhost:9081/HelloWorldWSProject/DemoWebServiceService в поле Service Address , если сервер работает на локальном компьютере на порту localhost:9081. В противном случае необходимо ввести реальный адрес, по которому доступен Web-сервис.
3. Выберите text/html для поля Content-Type .
4. Нажмите кнопку OK для отправки SOAP-сообщения на сервер.

Прием SOAP-сообщения

Если сервер настроен и работает, вы должны получить SOAP-ответ. Если ответ не приходит, проверьте корректность адреса и типа содержимого.

Проверка корректности SOAP-сообщения

Отлично! Мы приняли SOAP-ответ. Он также сохраняется в проекте. Но подождите. Вы видите, что что-то не так? Мы получили "Hello, buddy!" вместо "Hello, Jinwoo!". Что пошло не так? Не имеете понятия?

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

Инструмент Web Services Validation Tool for WSDL and SOAP позволяет определить, что происходит не так.

Листинг 6. Ответ

Hello, buddy!

1. Выберите ответное SOAP-сообщение и нажмите кнопку Validate .

Программа 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.

Редактирование SOAP-сообщения

1. Программа жалуется на значение "parameters". Измените его на arg0 и сохраните.

Листинг 7. Измененное SOAP-сообщение

Jinwoo

1. Проверьте корректность модифицированного ответного SOAP-сообщения. Больше никаких сообщений об ошибках не появляется.

1. Теперь мы готовы отправить модифицированное ответное сообщение на сервер. Выберите SOAP-сообщение, а затем выберите Transmit SOAP Request and Receive SOAP Response .

1. В окне Transmit SOAP Request and Receive SOAP Response введите http://localhost:9081/HelloWorldWSProject/DemoWebServiceService в поле Service Address , если сервер работает на порту localhost:9081.
2. Выберите text/html для поля Content-Type и нажмите кнопку OK .

В этот раз, как и ожидалось, приходит правильный ответ.

Листинг 8. SOAP-ответ

Hello, Jinwoo!

Обнаружение неправильного пространства имен

Что произойдет, если отправить сообщение с неправильным пространством имен?

1. Измените пространство имен на http://demo2/ и сохраните сообщение.

Листинг 9. Изменение пространства имен

Jinwoo

1. Затем можно отправить запрос на сервер.

Вы увидите исключительную ситуацию 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-сообщения зашифрованы? Никаких проблем, если у вас имеются ключи и пароли. Просто выберите SOAP-сообщение и Validate точно так же, как это делается для любых других обычных SOAP-сообщений. Если ваше SOAP-сообщение зашифровано, на экране появится запрос, аналогичный показанному на рисунке 35.

На момент написания данной статьи поддерживается 3 типа хранилищ ключей (keystore):

1. Java Key Store (JKS).
2. Java Cryptography Extension Key Store (JCEKS).
3. Personal Information Exchange Syntax Standard (Public Key Cryptography Standards #12).

Необходимо предоставить информацию о вашем хранилище ключей: имя файла, тип файла и пароль. Если информация верна, необходимо выбрать ключ и пароль. Можно также найти информацию о ваших хранилищах ключей и списке ключей и сертификатов в хранилище ключей, например, тип хранилища ключей, имя провайдера, версия провайдера, информация провайдера, тип ключа, дата создания, тип сертификата, алгоритм и формат.

Если вся информация верна, программа сгенерирует дешифрованное SOAP-сообщение и проверит его корректность.

В настоящее время поддерживаются следующие алгоритмы шифрования:

• Advanced Encryption Standard (AES) в режиме Cipher Block Chaining (CBC) с вектором инициализации (128/192/256 битов).
• Advanced Encryption Standard (AES) Key Encryption (128/192/256 битов).
• Triple Data Encryption Algorithm Modes of Operation (triple-DES) Key Encryption.
• Triple Data Encryption Algorithm Modes of Operation (triple-DES) Key Encryption в режиме Cipher Block Chaining (CBC).
• RSA Cryptography Specifications Version 1.5.
• RSA Optimal Asymmetric Encryption Padding (OAEP) – метод с функцией генерирования маски.

Проверка корректности SOAP-сообщений с цифровой подписью

Что если ваше SOAP-сообщение имеет цифровую подпись? Просто выберите SOAP-сообщение, а затем выберите SOAP Message Digital Signature Verification .

Если цифровая подпись корректна, вы увидите следующий экран:

В противном случае программа сообщит об ошибке в подписи. В настоящее время поддерживаются следующие спецификации и алгоритмы цифровых подписей:

• Secure Hash Algorithm 1 (SHA-1)
• Hash Message Authentication Code (HMAC)
• Digital Signature Algorithm (DSA)
• Public-Key Cryptography Standards (PKCS #1)
• RSA Encryption Algorithm with Secure Hash Algorithm (SHA-1)
• Canonical XML Version 1.0 and 1.1
• XSL Transformations (XSLT) Version 1.0
• XML Path Language (XPath) Version 1.0
• Base64

Доступ к сервису Национального метеобюро США с использованием SOAP-сообщения

Созданный и протестированный нами простой Web-сервис работает нормально. Можно ли использовать данную программу в "реальной" среде? Можно попробовать поработать с реальным Web-сервисом Национального метеобюро США, предоставляемым организацией U.S. National Oceanic and Atmospheric Administration (NOAA).

1. Создайте проект.

1. Создайте XML-код SOAP-сообщения.

Национальное метеобюро США предоставляет много разных Web-сервисов. Можно попробовать поработать с сервисом NDFDgenByDay, предоставляющим прогнозы погоды для точки с заданной широтой и долготой.

Для доступа к NDFDgenByDay необходимо предоставить следующую информацию:

Таблица 1. 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-часовом формате:

Листинг 10. SOAP-запрос

38.99 -77.01 2010-07-23 7 24 hourly

Мы не указывали пространство имен, потому что сервис работал без него. Если с пространством имен возникнут какие-либо проблемы, задайте его.

Выберите сообщение и Transmit SOAP Request and Receive SOAP Response в программе Web Services Validation Tool for WSDL and SOAP.

Таблица 2. Запрос информации

Имя	Значение
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-сервисов даже не способно обнаружить, что может привести к серьезным последствиям в реальной жизни. Использование этой программы на этапе разработки позволяет сократить время устранения проблем в ходе эксплуатации.

В последние годы увеличилось использование API и зависимость от веб-сервисов. Вот список из 12 инструментов тестирования веб-сервисов, которые значительно помогут вам.

За последние несколько лет популярность и использование веб-сервисов или API повысились. Веб-сервис или API – это набор процедур или программных компонентов, которые помогают приложению взаимодействовать или выполнять какой-либо процесс / транзакцию, формируя соединение между другим приложением или сервером. В основном существуют два типа веб-сервиса: REST и SOAP для передачи данных и информации через интернет-протокол.

Поскольку эти веб-службы доступны в Интернете и распространяются по разным сетям, они уязвимы для вирусов и угроз безопасности, которые влияют на процессы, основанные на них. Следовательно, тестирование веб-служб или API-интерфейсов становится необходимым для обеспечения правильной работы и корректного ответа на запросы. Тестирование ПО является перспективным направлением в сфере IT, получить необходимые знания Вы можете на

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

Здесь вы найдете 12 отличных инструментов тестирования веб-сервисов, на счет которых вам следует подумать для вашего API или требований тестирования веб-сервисов:

SoapUI

SoapUI – это инструмент для кросс-платформенного тестирования с открытым исходным кодом. Он может автоматизировать функциональные, регрессионные, согласованные и нагрузочные тесты как SOAP, так и REST-сервисов. Он прост в использовании и поддерживает передовые технологии и стандарты для моделирования и стимулирования поведения веб-сервисов.

Ключевые особенности:

• Предоставляет отчеты для печати, экспорта и HTML на уровне Project, TestSuite, TestCase или LoadTest.
• Возможность взаимодейсвтия с Hudson, Bamboo, Maven, ANT и JUnit.
• Позволяет разрабатывать собственный набор функций в виде плагинов SoapUI.
• Записывает, контролирует и отображает все данные.
• Поддерживает WS-Security и SSL-расшифровки.

TestingWhiz

TestingWhiz это “codeless” инструмент автоматизации тестирования который совместим с API/веб сервисами. Он позволяет проводить функциональное, тестирование совместимости и нагрузочное тестирование и работать с веб-службами REST и SOAP через WSDL-интерфейс через HTTP и FTP.

Ключевые особенности:

• Поддерживает сравнение строк для проверки ответа API.
• Помогает в поиске API-дефектов с помощью интегрированных инструментов отслеживания ошибок, таких как JIRA, Mantis и Fogbugz.
• Создает визуальные журналы и отчеты о проведении теста с помощью электронной почты.
• Обеспечивает непрерывную интеграцию с Jenkins, Bamboo & Hudson.
• Поддерживает тестирование, основанное на данных и ключевых словах.

SOAPSonar

SOAPSonar обеспечивает комплексное тестирование веб-сервисов для HTML, XML, SOAP, REST и JSON. Он обеспечивает функциональное тестирование, тестирование производительности, совместимости и тестирование безопасности с помощью стандартов OASIS и W3C.

Ключевые особенности:

• Поддерживает тестирование уязвимостей с XSD-мутацией.
• Обеспечивает всесторонний анализ WSDL и Schema.
• Выполняет нагрузочное тестирование с моделированием поведения и несколькими одновременными процессами загрузки.
• Предоставляет отчеты в форматах XML, DOC, XLS, PDF, RTF и RPT.
• Взаимодействует с Центром качества HP.

SOAtest

SOAtest – это инструмент для тестирования и проверки API-интерфейсов и приложений, управляемых API. Он обеспечивает надежную поддержку функционального блока, интеграцию, безопасность, симуляцию, проведение нагрузочного тестирования при помощи таких технологий, как REST, JSON, MQ, JMS, TIBCO, HTTP и XML.

Ключевые особенности:

• Обеспечивает End-to-End тестирование
• Поддерживает 120+ протоколов / типов сообщений.
• Поставляется с простым в использовании интерфейсом.
• Помогает создавать сложные, расширяемые и многоразовые тесты без кодирования.
• Поддерживает непрерывное интеграционное тестирование

TestMaker

TestMaker – это инструмент с открытым исходным кодом для тестирования и мониторинга производительности веб-сервисов и приложений SOA с помощью PushtoTest. Он работает на Jython (Python написанный на Java). TestMaker может перепрофилировать тесты Selenium, тесты SoapUI, тесты Sahi или любые тесты, написанные в Groovy, Java, Python, PHP, Ruby и Perl, в функциональные, нагрузочные тесты.

Ключевые особенности:

• Использует запрос командной строки для тестирования функциональности, нагрузки и производительности.
• Интуитивно понятный внешний вид со стандартной многооконной IDE.
• Предоставляет контрольную панель для запуска тестов и отображения результатов в реальном времени.
• Позволяет получать доступ ко всем Java-библиотекам и классам языка Jython.

Postman

Postman – еще один инструмент тестирования API / веб-сервисов, который имеет мощную поддержку HTTP-клиента. Он имеет простой в использовании конструктор запросов, который позволяет писать тест-кейсы и управлять данными ответов и временем отклика для эффективного тестирования и управления тест-кейсами API.

Ключевые особенности:

• Позволяет организовывать API в функции, называемые сборками Postman.
• Облегчает совместную работу и совместное использование данных API и средств контроля.
• Позволяет записывать логические тесты в Postman Interface.

vRest

VRest – это инструмент, предназначенный для тестирования, тестирования REST APIS и веб-сервисов. Он также поддерживает тестирование веб-приложений, мобильных и настольных приложений, которые взаимодействуют со сторонними API-интерфейсами или службами HTTP.

Ключевые особенности:

• Имеет функциональность макетного сервера для создания макета API за считанные минуты.
• Существует расширение Chrome для записи и воспроизведения тест-кейсов.
• Поддерживает интеграцию с Jenkins для непрерывной работы серверов и Jira для отслеживания ошибок.
• Облегчает управление разрешениями.
• Позволяет экспортировать и импортировать тест-кейсы и отчеты из внешних инструментов, таких как Postman Collections, Swagger 2.

HttpMaster

HttpMaster – еще один эксклюзивный инструмент для тестирования веб-сервисов REST. Это помогает тестировщикам тестировать поведение API REST и проверять выходные данные в таких форматах, как XML, JSON и HTML. Благодаря универсальному HTTP-инструменту HttpMaster также помогает разработчику моделировать активность клиента и поведение ответа приложения API.

Ключевые особенности:

• Имеет простой в использовании и элегантный пользовательский интерфейс, который не требует передовых технических навыков.
• Использует HTTP-методы, такие как GET, POST, DELETE и т. Д.
• Предоставляет различные типы и выражения для проверки для облегчения тестирования.
• Использует интерфейс командной строки для создания и выполнения теста.
• Позволяет хранить всю информацию – вызовы API и данные проекта в одном месте.

Runscope

Runscope – простой инструмент для проверки и мониторинга производительности API. Runscope также поддерживает тестирование API-интерфейсов и бэкэнд мобильных приложений.

Ключевые особенности:

• Позволяет создавать тесты с динамическими данными даже для сложных случаев.
• Отображает показатели и аналитику для выявления проблем.
• Работает с такими инструментами, как HipChat, Webhooks, Slack и PagerDuty для уведомления о сбое API.
• Позволяет повторно использовать и выполнять тесты в нескольких местах.
• Облегчает централизованное управление тестированием для улучшения совместной работы.

Rapise

Rapise – это надежный инструмент автоматизации с мощными и расширяемыми функциями. Он основан на открытой и гибкой архитектуре для быстрого функционального тестирования веб-сервисов REST / SOAP. Rapise также обеспечивает поддержку тестирования веб-приложений, встроенных в Java, .NET, Ajax, Silverlight и Flash.

Ключевые особенности:

• Использует стандартные методы HTTP, такие как POST, GET, PUT и DELETE.
• Позволяет хранить прототипированные запросы в отношении определенной веб-службы.
• Содержит встроенный конструктор определений REST и библиотеку объектов.
• Имеет мощные возможности отчетности.
• Поддерживает кросс-браузерное тестирование и параллельное выполнение.

WebInject

WebInject – это бесплатный инструмент для автоматизированного функционального, приемного и регрессионного тестирования веб-сервисов. Это инструмент командной строки и основан на Perl, что упрощает выполнение тестов, поскольку не требуется тратить время на командную строку. Кроме того, у него нет IDE-интерфейса, который означает, что тесты записываются вне пользовательского интерфейса WebInject. Он может работать на платформах с интерпретатором Perl.

Ключевые особенности:

• Обеспечивает отображение результатов в режиме реального времени.
• Контролирует время отклика системы.
• Поддерживает различное использование – как полноценную тестовую платформу, так и автономный тестировщик.
• Создает отчеты в форматах HTML и XML.
• Позволяет интегрировать с другой системой в качестве плагина для внешнего мониторинга.

Storm

Наконец, Storm – еще один инструмент с открытым исходным кодом от CodePlex для тестирования веб-сервисов, написанных на Java или.NET. В настоящее время он поддерживает только веб-сервис SOAP.

Ключевые особенности:

• Позволяет тестировать несколько веб-сервисов из единого пользовательского интерфейса.
• Помогает редактировать необработанные запросы SOAP.
• Позволяет ссылаться на методы веб-службы, содержащие сложные типы данных.
• Поддерживает тестирование приложений WCF.

Конечно, список здесь не заканчивается, так как для тестирования веб-сервисов существует огромное множество инструментов.

Запишитесь прямо сейчас или закажите звонок с бесплатной консультацией!

Здравствуйте!

В нескольких статьях я расскажу о возможностях протестировать с помощью SoapUI, как работают веб-сервисы 1С. Также приведу примеры возврата из 1С документов в формате PDF и сложных xml-файлов. Некоторые вещи сходны с вот , однако я рассмотрю более сложные примеры работы с веб-сервисами. Но для начала я по шагам рассмотрю процесс запуска веб-сервисов и работы с SoapUI, чтобы легче было разобраться в их функционировании с нуля.

1. Простой веб-сервис

Для начала возьмем каркасную конфигурацию без веб-сервисов и пройдем по шагам процесс их создания.

Добавим новый веб-сервис с именем test1 и создадим в нем операцию hello с возвращаемым типом string. Имена веб-сервисов и операций лучше всегда задавать на латинице.

Также нужно задать URI пространства имен и имя файла публикации:

При нажатии на лупу в поле "Имя процедуры" будет открыт модуль веб-сервиса и можно будет реализовать функцию hello.

Функция hello() возврат "строка из веб-сервиса 1с"; КонецФункции

2. Публикация веб-сервиса.

Теперь, чтобы получившаяся функция была доступна по http, нужно опубликовать наш сервис на веб-сервере. Для этого подойдет Apache 2.2. Я почитал статьи о том, как можно настроить работу с IIS и мне это показалось гораздо сложнее. После установки и запуска Apache 2.2 нужно зайти в меню Администрирование - Публикация на веб-сервере. Поле "каталог" должно быть заполнено и содержать каталог установки Apache. Запомните поля "имя" и "адрес" веб-сервиса, они нам пригодятся на следующем шаге.

3. Тестирование с помощью SoapUI

Для тестирования создадим отдельного пользователя 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 и посмотреть ответ:

Отлично, все заработало!

4. Передача простых параметров в функцию.

Теперь сделаем новую функцию с параметрами, например проверим работу с датами, сделаем функцию getSaleDocNumbersByDate, которая будет принимать дату документа (расходной накладной) и возвращать номера документов за эту дату строкой. Добавим к операции параметр date с типом dateTime:

код такой:

Функция getSaleDocNumbersByDate(date) // датаНачала = началоДня(date); датаКонца = конецДня(date); выборкаДокументов = документы.Расходная.Выбрать(датаНачала, датаКонца); номера=""; пока выборкаДокументов.Следующий() цикл номера = номера+" №"+выборкаДокументов.Номер+";"; конеццикла; возврат номера; КонецФункции

Теперь в SoapUI правой кнопкой мыши нужно кликнуть на элемент testSoap12Binding и выбрать пункт Update Definition. После этого в проекте появится функция getSaleDocNumbersByDate и готовый Request к ней. Для заполнения даты нужно использовать формат "YYYY-MM-DDThh:mm:ss" (можно посмотреть на w3schools и ОЧЕНЬ рекомендую пользоваться этим сайтом для понимания работы с xml)

Тогда получатся вот такие запрос и ответ:

5. Пакеты XDTO

Если необходимо передавать в функции более сложные параметры (например, xml с несколькими полями), или получать в ответ сложные по структуре xml, то нам не обойтись без пакетов XDTO.

Очень подробно работа с XDTO рассмотрена в цикле статей . По сути, пакет определяет структуру и тип полей используемых xml-файлов.

Я рассмотрю пример передачи и получение xml-файла, тип которого определен в пакете

А также в следующих статьях я рассмотрю примеры:

• передача в 1с xml-файла, не описанного в пакете, в формате base64
• получение из 1с документа pdf в формате base64 и его декодирование
• получение из 1с xml-файла со вложенной структурой элементов и определение их количества

6. Передача в 1с в параметре 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. Это справедливо как для простого сайта так и для высоконагруженных распределенных систем. Тестирование API — является одной из главных задач в процессе обеспечения качества. Неудивительно, что спрос на тестировщиков, которые умеют тестировать API повышается изо дня в день. На данном курсе вы получите понимание о методах, инструментах и подходах в тестировании API, приобретете необходимые знания, что несомненно благоприятно отразится на Вашей стоимости как специалиста в тестировании.

Данный курс будет полезен слушателям знакомым с основами тестирования ПО, которые хотят расти дальше и повышать свои навыки.

Программа курса:

Занятие 1. Вводная. Протокол SOAP

• Коротко о лекторе;
• Цели курса;
• Что такое API, WS и зачем они нужны;
• Роль тестирования API в процессе обеспечения качества;
• Обзор инструментария для тестирования WS;
• Методики применяемые в тестировании WS;
• История возникновения SOAP;
• Терминология и главные понятия (XML, XSD, Endpoint, WSDL).

Занятие 2: Протокол SOAP. Архитектура REST

• Терминология и главные понятия (UDDI, XSLT, XPath, XQuery, HTTP methods, HTTP statuses);
• Структура и главные компоненты SOAP;
• Сфера применения;
• Особенности работы;
• Преимущества и недостатки;
• Особенности REST архитектуры;
• Терминология и главные понятия (WADL, RESTful, JSON, JSONPath);
• Принципы REST;
• Статус код и основные статусы;
• CRUD глаголы;
• Преимущества и недостатки.

Занятие 3. Знакомство с SoapUI. Работа с REST проектом

• Установка Java;
• Установка SoapUI;
• Обзор основных элементов интерфейса;
• Подключение учебного проекта;
• Обзор методов проекта;
• Отправка запроса и анализ полученного ответа;
• Изучение доступных веб-сервисов проекта;
• Составление плана тестирования;
• Написание тест-кейсов;
• Элементы “TestSuite», “TestCase”, “TestSteps”.

Занятие 4. Работа с REST проектом (XML)

• Блок “Assertions”;
• Запуск тестов на различных уровнях;
• Элемент “Properties”, основные возможности;
• Работа с Properties;
• Элемент “Property Transfer”;
• Работа с Assertions.

Занятие 5. Работа с REST проектом (JSON)

• Условия и ветвления;
• Работа с Assertions;
• TestRunner, особенности работы;
• Запуск TS, TC из командной строки;
• Работа с Test runner;
• Работа с Groovy скриптами.

Занятие 6. Работа с Groovy скриптами

• Работа со статическими и динамическими данными;
• Генерируем тестовые данные;
• Получаем данные из “Properties”;
• Запись и трансфер данных;
• Условия и ветвления;
• Script Assertion.

Занятие 7. Дополнительные возможности

• Подключение внешних библиотек и кастомных классов;
• Mock-сервисы;
• Зачем нужны Mock-сервисы;
• Пример работы с Mock-сервисом;
• А как же CI?
• Устанавливаем Jenkins;
• Запуск проекта на Jenkins.