Тестування веб сервісів. Освоєння тестування SOAP API. Різні формати XSD-схеми

Використання програми Web Services Validation Tool for WSDL and SOAP

По всій видимості, з приходом нових технологій і стандартів, таких як XML і HTTP, Web-сервіси забезпечили собі місце в пантеоні інтернет-інновацій. Але як виникла ця інновація?

Основну концепцію Web-сервісів можна простежити в США до середини 1960-х років. У транспортній галузі, наприклад, в залізничних і судноплавних компаніях, була представлена \u200b\u200bнова концепція обміну електронними даними між комп'ютерами, що розвинулася далі в технологію 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-сервіси можна створювати двома шляхами:

Розробка "зверху вниз" (top-down) розробка, при якій Java-класи, що реалізують Web-сервіси, генеруються з WSDL.
Розробка "від низу до верху" (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 \u003d\u003d 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.

У Universal Test Client розгорніть Objects\u003e DemoWebService.
Виберіть метод hello.
Введіть рядок або ваше ім'я в поле Value і натисніть кнопку Invoke.

Можна також виконати тест, вказавши параметр , і подивитися, що станеться. Якщо в метод hello () передається параметр , повертається рядок "Hello, buddy!", Як і очікувалося.

Створення Web-сервісу

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

Виберіть Java-додаток DemoWebService і створіть новий Web-сервіс з IBM Rational Application Developer.

Оскільки ми створили 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 \u003d "http: // demo /", serviceName \u003d "DemoWebServiceService", portName \u003d "DemoWebServicePort") public class DemoWebServiceDelegate (demo.DemoWebService _demoWebService \u003d 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. Якщо у вас встановлена \u200b\u200bсистема 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: \u200b\u200b\\ xml-security-1_4_3 \\ libs:

wsvt -vm c: \\ SUNjava6 \\ bin \\ java.exe -vmargs -DAXS \u003d 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 \u003d 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-повідомлення.

Клацніть правою кнопкою миші і виберіть New\u003e Project.

Оберіть Project в General.

Введіть "Test Project" в поле Project name і натисніть кнопку Finish.

Імпорт WSDL і схеми

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

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

Оберіть File System в General.

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

Огляд WSDL і схеми

Тепер у нас є проект з WSDL і XSD. Можна двічі клацнути лівою кнопкою миші на WSDL для перегляду WSDL в режимі Design (проектування) і Source ( вихідний код). У режимі Design можна візуалізувати Web-сервіс з вхідними та вихідними даними.

У режимі Source можна переглядати і редагувати WSDL в текстовому редакторі.

Якщо XSD-файли можна відкрити в XSD-редакторі, їх можна відкрити в XML-редакторі, вибравши Open With\u003e XML Editor в контекстному меню цього XSD-файлу.

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

Створення SOAP-повідомлення

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

Оберіть New\u003e XML для створення SOAP-повідомлення в проекті.

Оберіть 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-сервісів?

Виберіть SOAP-повідомлення та виберіть

У вікні Transmit SOAP Request and Receive SOAP Response можна заповнити Service Address, SOAPAction і Content-Type. В даному додатку нам не потрібно вказувати SOAPAction, оскільки ми використовували порожній рядок "" для атрибута soapAction в розділі зв'язування файлу DemoWebServiceService.wsdl.
Введіть http: // localhost: 9081 / HelloWorldWSProject / DemoWebServiceService в поле Service Address, Якщо сервер працює на локальному комп'ютері на порту localhost: 9081. В іншому випадку необхідно ввести реальну адресу, за якою доступний Web-сервіс.
Оберіть text / html для поля Content-Type.
Натисніть кнопку 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!

Виберіть відповідь 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-повідомлення

Програма скаржиться на значення "parameters". Змініть його на arg0 і збережіть.

Лістинг 7. Змінена SOAP-повідомлення

Jinwoo

Перевірте коректність модифікованого відповідного SOAP-повідомлення. Більше ніяких повідомлень про помилки не виникає.

Тепер ми готові відправити модифіковане відповідь було надіслане на сервер. Виберіть SOAP-повідомлення, а потім виберіть Transmit SOAP Request and Receive SOAP Response.

У вікні Transmit SOAP Request and Receive SOAP Response введіть http: // localhost: 9081 / HelloWorldWSProject / DemoWebServiceService в поле Service Address, Якщо сервер працює на порту localhost: 9081.
Оберіть text / html для поля Content-Type і натисніть кнопку OK.

Цього разу, як і очікувалося, приходить правильну відповідь.

Лістинг 8. SOAP-відповідь

Hello, Jinwoo!

Виявлення неправильного простору імен

Що станеться, якщо відправити повідомлення з неправильним простором імен?

Змініть простір імен на http: // demo2 / і збережіть повідомлення.

Лістинг 9. Зміна простору імен

Jinwoo

Потім можна відправити запит на сервер.

Ви побачите виняткову ситуацію 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):

Java Key Store (JKS).
Java Cryptography Extension Key Store (JCEKS).
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).

Створіть проект.

Створіть 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 \u003d utf-8

Тепер дані прогнозу стало значно легше читати.

Якщо ця рада здасться вам не дуже зручним, можете використовувати свій власний метод форматування HTML. Більшість Web-сервісів пропонує результати в XML-форматі, тому вам не доведеться вдаватися до цього прийому постійно.

висновок

Ми створили, перетворили, взяли і перевірили правильність SOAP-повідомлень, використовуючи програму Web Services Validation Tool for WSDL and SOAP. Ця програма дозволяє точно визначити проблеми, які більшість серверів Web-сервісів навіть не здатне виявити, що може привести до серйозних наслідків в реальному житті. Використання цієї програми на етапі розробки дозволяє скоротити час усунення проблем в ході експлуатації.

Вітаю!

У кількох статтях я розповім про можливості протестувати за допомогою 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) // датаНачала \u003d началоДня (date); датаКонца \u003d конецДня (date); виборкаДокументов \u003d документи.Расходная.Вибрать (датаНачала, датаКонца); номера \u003d ""; поки виборкаДокументов.Следующій () цикл номера \u003d номера + "№" + виборкаДокументов.Номер + ";"; конеццікла; повернення номера; КонецФункціі

Тепер в 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) НомерДок \u003d incomingXML.number; ДатаДок \u003d incomingXML.date; запит \u003d новий запит; запрос.Текст \u003d "ВИБРАТИ | РасходнаяТовари.Номенклатура.Наіменованіе як name, | РасходнаяТовари.Цена як price, | РасходнаяТовари.Колічество як quantity, | РасходнаяТовари.Сумма як sum, | РасходнаяТовари.Ссилка | З | Документ.Расходная.Товари ЯК РасходнаяТовари | ДЕ | РасходнаяТовари.Ссилка.Номер \u003d & Номер | І РасходнаяТовари.Ссилка.Дата \u003d & ДатаДок "; запрос.УстановітьПараметр ( "Номер", номерДок); запрос.УстановітьПараметр ( "ДатаДок", ДатаДок); вибірка \u003d запрос.Виполніть (). Вибрати (); якщо виборка.Колічество () \u003d 0 тоді // повернемо помилку ТіпДокумента \u003d ФабрікаXDTO.Тіп ( "packet1_ns", "SaleDoc"); ПакетДокумента \u003d ФабрікаXDTO.Создать (ТіпДокумента); ПакетДокумента.number \u003d "Документів не знайдено!"; Повернення ПакетДокумента; інакше // створюємо типи ТіпДокумента \u003d ФабрікаXDTO.Тіп ( "packet1_ns", "SaleDoc"); ТіпТаблічнойЧасті \u003d ФабрікаXDTO.Тіп ( "packet1_ns", "SaleItem"); ПакетДокумента \u003d ФабрікаXDTO.Создать (ТіпДокумента); // вибираємо з табличній частині рах \u003d 0; поки виборка.Следующій () цикл якщо рах \u003d 0 тоді // заповнимо реквізити документа док \u003d виборка.ссилка; ПакетДокумента.number \u003d док.Номер; ПакетДокумента.date \u003d док.Дата; ПакетДокумента.partnerName \u003d рядок (док.Контрагент); КонецЕсли; // заповнюємо табличну частину ПакетТаблічнойЧасті \u003d ФабрікаXDTO.Создать (ТіпТаблічнойЧасті); ЗаполнітьЗначеніяСвойств (ПакетТаблічнойЧасті, вибірка); // додаємо її в документ ПакетДокумента.SaleItems.Добавіть (ПакетТаблічнойЧасті); рах \u003d рах + 1; конеццікла; Повернення ПакетДокумента; КонецЕсли; КонецФункціі

Тут два основних аспекти. Перший: так як було поставлено тип вхідного параметра incomingXML і він був описаний цей тип в пакеті, то відразу можливо звертатися до полів цього входить xml. Другий: робота з фабрикою XDTO. З неї було отримано тип для результуючих вихідних параметрів і створено ЗначеніеXDTO цього типу, у якого були заповнені необхідні поля. Також варто зауважити, що в типі SaleDoc слід ввести окреме поле для помилки, але для тестових цілей помилки будуть записані в поле number.

Ось як виглядає результат цього запиту в SoapUI:

Як видно, все працює, але ще є що поліпшити - наприклад, хотілося б знати скільки елементів SaleItems у нас в документі.

Про це та про більш складних прикладах я розповім вже в наступній статті.

У доданому архіві - вивантаження інформаційної бази і проект SoapUI.

SOAP (Simple Object Access Protocol) є стандартизованим протоколом передачі повідомлень між клієнтом і сервером. Зазвичай він використовується спільно з HTTP (S), але може працювати і з іншими протоколами прикладного рівня (наприклад, SMTP і FTP).
Тестування SOAP з точки зору технік тестування нічим принципово не відрізняється від роботи з іншими API, але для його проведення потрібні попередня підготовка (в плані теорії протоколу) і спеціальні інструменти для тестування. У даній статті я хотіла б сформулювати невеликий чек-лист необхідних знань і навичок, який буде однаково корисний як тестувальників SOAP (часто не представляє, «за що хапатися» після постановки задачі), так і менеджеру, вимушеного оцінювати знання тестувальників і розробляти плани по навчання.

теоретична база

Той факт, що SOAP є протоколом, має велике значення для тестування: потрібно вивчити сам протокол, «первинні» стандарти і протоколи, на яких він базується, а також (у міру необхідності) існуючі розширення.

XML
XML - мова розмітки, схожий з HTML. Будь-яке повідомлення, що відправляється / отримується через SOAP, - це XML-документ, в якому дані зручно структуровані і легко читані, наприклад:

Юля
Наташа
нагадування
Не забудь написати статтю!

Більш докладно про XML можна дізнатися на w3schools або codenet (по-російськи). Обов'язково зверніть увагу на опис namespaces (метод вирішення конфліктів при описі елементів в XML) - в SOAP їх використання необхідно.

XSD
При роботі завжди зручно мати стандартизований опис можливих XML-документів і перевіряти їх на коректність заповнення. Для цього існує XML Schema Definition (або скорочено XSD). Дві головні фичи XSD для тестувальника - це опис типів даних і накладення обмежень на можливі значення. Наприклад, елемент з попереднього прикладу можна зробити необов'язковим для заповнення та обмежити його розмір 255 символами за допомогою XSD:

...

...

розширення SOAP
У роботі вам також можуть зустрітися різні «розширення» SOAP - стандарти типу WS- *. Одним з найпоширеніших є WS-Security дозволяє працювати з шифруванням і електронними підписами. Нерідко разом з ним застосовується WS-Policy, за допомогою якого можна керувати правами на використання вашого сервісу.

Приклад використання WS-Security:

Alice
6S3P2EWNP3lQf + 9VC3emNoT57oQ \u003d
YF6j8V / CAqi + 1nRsGLRbuZhi
2008-04-28T10: 02: 11Z

Всі ці розширення - досить складні конструкції, які використовуються далеко не в кожному SOAP-сервісі; їх докладне вивчення на початковому етапі освоєння тестування SOAP навряд чи буде актуально.

Інструменти

Як ви вже зрозуміли, SOAP - справа серйозна, для роботи з ним потрібно знати теорію і численні стандарти. На практиці така складність привела б до вельми відчутним трудовитрат (наприклад, потрібно було б кожен раз дивитися схему в блокнотику і слати запити curl-му). Тому були створені інструменти, що полегшують роботу з SOAP.

Редактори XML / XSD
Хороший тестувальник починає тестування ще на стадії написання документації, тому для перевірки схем зручно використовувати спеціальні редактори. Два найвідоміших - Oxygen (багатоплатформовий) і Altova (тільки для Windows); обидва вони є платними. Це дуже потужні програми, якими активно користуються аналітики при описі сервісів.

У моїй практиці корисними виявилися три фичи редакторів: візуалізація XSD, генерація XML на основі XSD і валідація XML по XSD.

1. Візуалізація XSD потрібна для наочного уявлення схеми, що дозволяє швидко виокремити обов'язкові елементи і атрибути, а також існуючі обмеження. Наприклад, для запиту CheckTextRequest обов'язковим є елемент text, а необов'язковими - все три атрибута (при цьому у атрибута options встановлено значення за замовчуванням - нуль).

Візуалізація необхідна в тому випадку, коли типів і обмежень в схемі багато. Якщо вам потрібна тільки вона, і ви не хочете платити за спеціальні редактори, то можна розглянути безкоштовні альтернативи (наприклад, JDeveloper).

2. Генерація XML на основі XSD корисна тоді, коли ви хочете побачити коректний приклад повідомлення. Я користуюся їй для того, щоб швидко поекспериментувати з можливим заповненням повідомлення і перевірити нюанси роботи обмежень.

3. Після використання фичи з пункту 2 корисно провести валідацію XML по XSD - тобто перевірити повідомлення на коректність. Разом фичи 2 і 3 дозволяють відловлювати хитрі дефекти в XSD ще тоді, коли сам сервіс знаходиться в розробці.

Інструмент тестування - SoapUI

Тестування SOAP практично завжди має на увазі використання SoapUI. Прочитати про використання цього інструменту можна в різних джерелах (,), але найефективніше буде ознайомитися з офіційною документацією. Я виділяю 8 умовних рівнів володіння SoapUI:

Рівень 1 - вмію відправляти запити
Навчіться створювати проект на основі WSDL. SoapUI може згенерувати всі необхідні запити для вас; вам залишиться лише перевірити правильність їх заповнення і натиснути кнопочку «Send». Після вироблення навичок створення коректних запитів ви повинні оволодіти мистецтвом формування некоректних запитів, що викликають появу помилок.

Рівень 2 - вмію робити Test Suites і Test Cases
Почніть робити міні-Автотест. Тест-комплекти і тест-кейси дозволяють створювати сценарії тестування API, готувати дані для запитів і автоматично перевіряти отриману відповідь на відповідність очікуваному. На перших порах їх можна використовувати просто як колекції запитів. Наприклад, якщо ви завели дефект і хочете швидко перевірити його після фікса, можна виділити окремий тест-комплект конкретно під запити-дефекти.

Рівень 3 - вмію писати Assertions
Після освоєння тест-кейсів вам буде корисно навчитися робити їх автоматично перевіряються. Після цього вам вже не потрібно буде шукати «очима» інформацію про відповідь: при наявності автоматичної перевірки кейси будуть позначатися зеленим (якщо перевірка пройдена) або червоним (якщо не пройдена). SoapUI надає великий набір можливих перевірок (assertions), але найзручніші і прості - це Contains і Not Contains. З їх допомогою можна перевірити факт наявності конкретного тексту в отриманій відповіді. Ці перевірки також підтримують пошук за допомогою регулярних виразів.

Рівень 4 - використовую XPath і / або XQuery в Assertions
Для тих, хто трохи знайомий з UI за допомогою Selenium, мова XPath - знайома річ. Грубо кажучи, XPath дозволяє шукати елементи в XML-документі. XQuery - схожа технологія, яка може використовувати XPath всередині себе; ця мова набагато могутніше, він нагадує SQL. Обидва ці мови можна використовувати в Assertions. Перевірки з їх допомогою виходять більш прицільними і стабільними, тому ваші кейси будуть користуватися великою довірою.

Рівень 5 - вмію писати складні тести з допомогою спеціальних кроків

У тест-кейсах може міститися не тільки один запит, а й кілька (наприклад, коли ви хочете емулювати стандартний сценарій роботи користувача «створити сутність» → «експортувати сутність»). Між запитами можуть перебувати інші спеціальні кроки, наприклад:

Properties і Property Transfer (допомагають перевикористати дані і передавати їх між запитами);
JDBC Request (використовується для отримання даних з бази даних);
Conditional Goto (дозволяє зробити розгалуження або цикли в тест-кейсі);
Run TestCase (допомагає винести якісь типові запити в окремі тест-кейси і викликати їх там, де потрібно).

Рівень 6 - використовую скрипти на Groovy

SoapUI дозволяє писати скрипти на Groovy в різних місцях. Найпростіший випадок - це генерація даних в самому запиті за допомогою вставок $ (\u003d). Я постійно користуюся такими вставками:

$ (\u003d New Date (). Format ( «yyyy-MM-dd'T'HH: mm: ss»)) - для вставки поточної дати і часу в необхідному форматі;
$ (\u003d Java.util.UUID.randomUUID ()) - для вставки коректно сформованого випадкового GUID.

Повноцінні скрипти можна використовувати в якості кроків в кейсах і перевірках. У якийсь момент ви виявите, що відразу кілька спеціальних кроків з п'ятого рівня можна замінити одним скриптом.

Рівень 7 - використовую MockServices
SoapUI на основі WSDL може генерувати Mock-об'єкти. Mock-об'єкт - це найпростіша симуляція сервісу. За допомогою «моков» можна почати писати і налагоджувати тест-кейси ще до того, як сервіс реально буде доступний для тестування. Також їх можна використовувати в якості «заглушок» для тимчасово недоступних сервісів.

Рівень 8 - бог SoapUI
Ви знаєте різницю між платною і безкоштовною версіями SoapUI і використовуєте SoapUI API в коді. Ви використовуєте плагіни і запускаєте виконання кейсів через командний рядок і / або CI. Ваші тест-кейси прості і легко підтримуються. Загалом, ви «з'їли собаку» на цьому інструменті. Я б з радістю поспілкувалася з тим, хто освоїв SoapUI на такому рівні. Якщо ви є таким - відпишіться в коментарях!

Тестування за допомогою мов програмування

Наведу приклад того, як виглядає запит до YandexSpeller API, виконаний за допомогою groovy-wslite:

import wslite.soap. *
def client \u003d new SOAPClient ( "http://speller.yandex.net/services/spellservice?WSDL")
def response \u003d client.send (SOAPAction: "http://speller.yandex.net/services/spellservice/checkText") (
body (
CheckTextRequest ( "lang": "ru", "xmlns": "http://speller.yandex.net/services/spellservice") (
text ( "ошіпка")
}
}
}
assert "помилка" \u003d\u003d response.CheckTextResponse.SpellResult.error.s.text ()
assert "1" \u003d\u003d [Email protected]()

Наскільки я знаю, високорівневих фреймворків (по типу Rest-assured) для тестування SOAP поки не існує, але недавно з'явився цікавий інструмент - karate. З його допомогою можна описувати кейси для тестування SOAP і REST у вигляді сценаріїв на кшталт Cucumber / Gherkin. Для багатьох тестувальників звернення до karate буде ідеальним рішенням, адже такі сценарії за складністю написання і підтримки кейсів будуть лежати десь посередині між використанням SoapUI і написанням власного фреймворка для тестування SOAP.

висновок

Навряд чи вам коли-небудь захочеться тестувати SOAP просто так, для себе (як могло б вийти з REST-му). Це великоваговий протокол, який використовується в серйозних корпоративних рішеннях. Але його ваговитість одночасно є подарунком тестувальників: всі використовувані технології стандартизовані, є якісні інструменти для роботи. Від тестувальника потрібно лише бажання їх вивчити і використовувати.

Давайте зберемо воєдино той самий чек-лист необхідних навичок для тестувальника. Отже, якщо ви тільки починаєте тестувати SOAP сервіси, вам потрібно знати і вміти використовувати:

WSDL.
SOAP.
Редактори XML / XSD (на рівні візуалізації XSD).
SoapUI на рівні 1.

Як бачите, основний упор припадає на вивчення стандартів, в SoapUI досить просто вміти виконувати запити. У міру занурення в тестування SOAP перед вам будуть виникати завдання, які зажадають вже більш серйозних навичок і знань, але не варто намагатися вивчити все і відразу. Набагато важливіше послідовність в підвищенні рівня складності виконуваних завдань. Дотримуючись цієї рекомендації, в один прекрасний момент ви зрозумієте, що стали хорошим фахівцем в цій галузі!

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

У даній статті буде розглянуто питання інтеграції 1С з уже існуючими веб-сервісами та використання самої 1С як веб-сервісу.

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

Ризики використання веб-сервісів 1С

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

Але їх використання може призвести до ризиками:

1С8 погано працює через HTTPS, засоби діагностики відсутні, тому зрозуміти, чому при наявності сертифіката сервіс не хоче працювати через HTTPS часом неможливо. Вихід - реалізація веб-сервісів через CURL або підняття HTTPS-тунелю.
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\u003d341168 і в документації 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С передає тільки інформацію для пробиття чеків.

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

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

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

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

Табличну частину вигідніше використовувати, ніж набір реквізитів, тому що у транзакції їх може бути дуже багато, а в інших чеках, не пов'язаних з сервісом, ці реквізити не використовуватимуться, і будуть займати зайве місце. Крім того, таке рішення універсально для будь-якого сервісу і не вимагає реструктуризації даних після впровадження нового сервісу.

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

Використання обробок на мові 1С

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

Заведемо в 1С зумовлений елемент довідника номенклатури «Paym». У режимі 1С: Підприємства після поновлення конфігурації йому потрібно призначити вид товару «Послуга».
У процедурі «Додати номенклатуру в таб. частина »модуля форми« Реєстрація продажів »викликаємо обробку роботи з сервісом, написану на мові 1С. У разі успішного здійснення платежу записуємо і проводимо чек:

Якщо (Номенклатура \u003d Справочнікі.Номенклатура.Paym) І (ВідОпераціі Перечісленія.ВідиОпераційЧекККМ.Возврат) Тоді ОбработкаПлатежа \u003d Функціі.ДатьВнешнююОбработку ( "Paym"); ФормаПлатежа \u003d ОбработкаПлатежа.ПолучітьФорму (); Результат \u003d ФормаПлатежа.ОткритьМодально (); Якщо Результат \u003d Не визначено Тоді Повернення; КонецЕсли; ЕтотОб'ект.Запісать (РежімЗапісіДокумента.Проведеніе); КонецЕсли;

Обробка повинна надрукувати предчек (якщо потрібно), заповнити табличну частину складних продажів і підготувати текст друку чека в зумовленому реквізиті «PaymТекстЧека».
У процедурі «Провести і роздрукувати чек» модуля чека підміняємо найменування товару на збережене в реквізиті для чека. Текст підміняється тільки для продажу, для повернення друкується просто назва послуги, як зазвичай.

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

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

Використання програм, інтегрованих з 1С

XDTO

Часто в веб-сервісах використовується XDTO. Наведемо найбільш важливі поради та рецепти по використанню XDTO в 1С.

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

XDTO-пакети, описані в гілці «XDTO-об'єкти» конфігурації, доступні для створення типів і об'єктів в глобальній фабриці Фабрика XDTO. Це не відразу стає очевидним.

Деякі типи в схемі не мають імені, щоб їх отримати, треба пройтися по ієрархії типів.

У прикладі був описаний список System, що мав структури XDTO. Щоб створити саму структуру, потрібно було отримати її тип таки ось чином:

Тип \u003d Фабріка.Тіп ( "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\u003d214
Безкоштовні цікаві веб-сервіси:
- Аерофлот - інформація про розклад літаків
- Морфер - схиляння імен http://www.morpher.ru/WebServices/Morpher.aspx
нерозібрані:
- Установка і використання Веб-сервісів
  - v8: як змінити конфігураційний файл апача?
  - v8: продовження теми з web-сервісами - не можу підключити web-сервіс
  - v8: далі повзу по веб-сервісів - не можу створити проксі ...
  - Книга знань: v8: Використання зовнішніх web-сервісів в 1С: Підприємство 8;

У наш час рідко сучасне додаток обходиться без 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 проектом