Contacte

Testarea serviciilor Web. Testarea API pentru SOAP. Diferite formate XSD -

Folosind programul. Servicii web. Instrumentul de validare pentru WSDL și săpun

Aparent, cu sosirea noilor tehnologii și standarde, cum ar fi XML și HTTP, serviciile Web au oferit locul lor în panteonul inovației pe Internet. Dar cum ar apărea această inovație?

Principalul concept de servicii web poate fi urmărit în Statele Unite până la mijlocul anilor 1960. În industria transporturilor, de exemplu, în companiile feroviare și de transport maritim, a fost prezentat un nou concept pentru schimbul de date electronice între computere, dezvoltat în continuare la tehnologia EDI (intersecția electronică de date - schimb de date electronice). Pentru prima dată am auzit despre EDI de la profesorul unei școli de afaceri în 1980.

În 1996, Institutul Național de Standarde și Tehnologii din Statele Unite a anunțat standardul pentru EDI în publicațiile de standarde federale de procesare a informațiilor (FIPS PUB 161-2). Conform specificațiilor publicate, EDI este standardul de partajare a mesajelor strict formatate între computere. Procesarea mesajelor primite se efectuează numai cu un computer, iar aceste mesaje nu sunt de obicei intenționate să fie interpretate de o persoană. Acesta este exact ceea ce serviciile web sunt angajate, cu excepția faptului că, la mijlocul anilor 1960, nu exista XML, Internetul și World Wide Web.

Pentru cei care nu sunt foarte familiarizați cu serviciile Web, voi lua în considerare pe scurt definițiile și componentele principale ale serviciilor web.

Ce sunt serviciile web

Serviciul Web este sistem software.Conceput pentru a sprijini interacțiunile intercalate între resursele de calcul al rețelei și utilizarea mesajelor SOAP (protocol simplu de acces la obiecte) definite de consorțiul de consorțiu Web Wide Worl.

Protocolul simplu de acces la obiecte (săpun) este un simplu protocol extensibil pentru care mesageria comună și tastată este schimbată într-un mediu descentralizat, distribuit de rețea. Mesajele SOAP sunt înregistrate într-un format de limbă de marcare (XML) extensibil (XML) - Format de text simplu și flexibil care începe de la limbajul standard de marcare generalizat (SGML), care a fost dezvoltat de Organizația Internațională pentru Standardizare (ISO 8879: 1986).

Servicii Web Descriere Limba (WSDL) se bazează pe Limba XML.care descrie interfața serviciilor web.

Ce se întâmplă la schimbul de mesaje de săpun eronate? Ce s-ar întâmpla dacă mesajul de săpun eronat a fost procesat fără avertisment și a fost chiar folosit pentru a genera informații concepute pentru a lua o decizie?

În practică, este imposibil să se spună, corect sau fără date în mesajul Săpun. Cu toate acestea, puteți verifica corect mesajul SOAP, vizualizarea definiției interfeței sau a WSDL.

În viața reală, problemele de depanare în mesajele de săpun sunt foarte dificile. Dacă există o eroare în mesajul SOAP, codul de răspuns HTTP 500 este primit de la serverul de servicii web. Serverele de servicii web nu furnizează informații detaliate despre parte din mesajul de săpun există o problemă. Puteți întâlni chiar și cea mai gravă situație atunci când răspunsurile corecte de săpun sunt acceptate de la serverul de servicii web fără mesaje de eroare și nici dvs., nici serverele dvs. de servicii web nu pot înțelege problemele din interogările și răspunsurile săpunului. De exemplu, ați dorit să solicitați cotațiile curente ale companiei B, dar au trimis un mesaj de săpun către serverul de servicii Web cu etichete incorect scrise. Serverul Web Service poate ignora etichetele greșite și oferă valoarea implicită în mesajul de săpun de răspuns, de exemplu, cotația de acțiuni a companiei. Dacă rămâne neobservată, consecințele pot fi dezastruoase.

Problemele de acest tip pot fi prevenite în avans cu web Tool. Instrumente de validare a serviciilor pentru WSDL și săpun. Vă permite să verificați corectitudinea mesajelor de săpun utilizând limba de limbă de definire a serviciului Web (WSDL), chiar înainte de implementarea aplicațiilor utilizând serviciul Web. Programul analizează sintaxa și corectitudinea mesajelor dvs. de săpun cu WSDL și indică probleme, raportând în detaliu despre erorile și liniile. Ca rezultat, nu veți mai primi mesaje enervante HTTP 500. Mesajele dvs. de săpun sunt criptate? Fără probleme. Programul le decide și va verifica corectitudinea mesajelor de săpun decriptați.

Acest program a fost creat pentru a ajuta angajații IBM Web Services Support, în mod decisiv legat de problemele de serviciu web de pe serverul IBM® WebSphere Application Server, care sunt raportate de clienții din întreaga lume. Programul este conceput pentru a verifica corectitudinea mesajelor de săpun. Dacă mesajul de săpun are o semnătură digitală, programul îl va verifica. Folosind instrumentul de validare a serviciilor Web pentru WSDL și SOAP, puteți chiar să trimiteți mesaje de săpun către serverele de servicii Web și puteți primi mesaje de săpun de răspuns. Programul a fost creat pentru a elimina problemele din operațiunea industrială prin utilizarea sa în stadiile incipiente ale dezvoltării, precum și pentru a reduce timpul pentru rezolvarea problemelor apărute în timpul funcționării.

Vom crea un serviciu web foarte simplu. Mai întâi vom crea un simplu Java ™ Expand. După verificarea aplicației Java, folosim IBM Rational® Application Developer pentru Software WebSphere® va genera un serviciu web. Apoi facem câteva modificări la serviciul web generat. În cele din urmă, folosim instrumentul de validare a serviciilor Web pentru WSDL și săpun pentru a crea, a verifica, a transmite și a primi mesaje de săpun.

Simplu Web Service poate fi creat folosind IBM Rational Application Developer pentru programul WebSphere Software. Serviciile Web pot fi create în două moduri:

  1. Dezvoltarea "de sus în jos" (de sus în jos) în care clasele Java care implementează serviciile web sunt generate de la WSDL.
  2. Dezvoltarea "de jos în sus" (partea de jos în sus), în care serviciul Web este generat de componenta de fasole Java sau Componenta de Bean Corporate Java.

În exemplul următor, implementăm serviciul web folosind metoda de dezvoltare din partea de jos în sus. Mai întâi vom crea o aplicație simplă Java. Apoi vom genera serviciul web al componentelor Java Bean din aplicația Java utilizând IBM Rational Application Developer pentru programul WebSphere Software.

Crearea unei aplicații Java

Mai întâi vom crea o aplicație Java, un salut remarcabil. Dacă numele nu este specificat, aplicația va returna textul "Bună ziua, Buddy!". Dacă numele este specificat, aplicația va returna textul "Bună ziua", urmat de acest nume. Mai jos este codul de aplicație Java al Demowebservice situat în pachetul Demo. Metoda Hello () returnează un șir dependent în numele.

Listarea 1. Demowebservice.java.
/ * * @Author: Jinwoo Hwang * Copyright 2010 IBM Corporation * / pachet demo; Clasa publică Demowebservice (Numele șirului) (dacă (Name \u003d\u003d Null) Return "Bună ziua, Buddy!"; Altceva return "Bună ziua" + Nume + "!";))

Testarea aplicației Java

Este foarte important să testați aplicația Java înainte de a crea un serviciu web de la acesta. Pentru a porni aplicația, puteți scrie o clasă cu metoda principală (). De asemenea, puteți utiliza funcționalitatea clientului de testare universal furnizat de produsul V7 Developer V7 IBM Rational pentru testarea rapidă fără a scrie un cod de testare. Este suficient doar pentru a selecta clientul de testare universal din meniul contextual al clasei Java pentru a începe clientul de testare.

  1. În client universal de testare se extinde Obiecte\u003e Demowebservice..
  2. Selectați metoda buna ziua..
  3. Introduceți un șir sau numele dvs. în câmp Valoare. și faceți clic pe Invoca.

De asemenea, puteți efectua un test prin specificarea parametrului nul și vedeți ce se întâmplă. Dacă parametrul nul este transmis la metoda Hello (), șirul "Bună ziua, Buddy!" Este returnat, așa cum era de așteptat.


Crearea unui serviciu web

În timp ce totul funcționează bine. Vom proceda la generarea unui serviciu web de la clasa Java utilizând metoda dezvoltării serviciilor web de jos în sus.

  1. Selectați aplicația Demowebservice Java și creați un nou serviciu web de la IBM Rational Application Developer.

  1. De când am creat o clasă Java, selectați Bottom Up Service Web Java Bean În lista de tip Web Service. Alege Porniți clientul. și faceți clic pe FINALIZAREA.. Dacă am avea o clasă EJB, am putea scrie și o componentă EJB pentru a genera un serviciu web.

Dacă totul a fost bine, veți vedea în resursele Java lângă demowebservice.java generat de DemowebserviceDelegate.java.


La vizualizarea DemowebserviceDegate.java, puteți găsi serviciul Java Web @ javax.jws.webservice adnotare, care specifică TARGETNAMESPACE, serviciiPaneme și portname în clasa DemowebserviceDelegate. O instanță a demoWebservice este creată și metoda Hello () de Demowebservice este creată de o altă metodă Hello (). Dacă doriți, aflați mai multe despre adnotările serviciilor Java Web Services Consultați documentul de Specificație Java (JSR) 181. Metadate de servicii web pentru platforma Java.

Listarea 2. DemowebserviceDelegate.java.
/ * * @Author: Jinwoo Hwang * Copyright 2010 IBM Corporation * / pachet demo; @ Javax.jws.webservice (TargetnameSpace \u003d "http: // demo /", servicename \u003d "demoWeBserviceService", PortName \u003d "Demowebserviceport") Demo.demowebservice _Demowebservice \u003d New demo.demowebservice (); șir public Bună ziua ( Numele șirului) (return _demowebservice.hello (nume);))

Crearea WSDL.

În proiect programul clientului De asemenea, puteți găsi că fișierele DemowebserviceService.WSDL și DemowebserviceService_Schema1.xsd au fost generate. DemoweBserviceService.WSDL conține informații în limba de definire a serviciului Web Descriere servicii de rețea Pentru aplicația Java creată mai devreme. DemowebserviceService_Schema1.xsd conține o schemă XML care descrie structura de tip de date utilizată în mesajele de săpun.


Când vizualizați fișierul DemowebserviceService.WSDL, puteți vedea că are un set de elemente de definiție (element de definiție). Elementele de definiție au 6 elemente:

  • tipuri (tipuri);
  • mesaj (mesaj);
  • porttype (tip port);
  • legare (legare);
  • serviciu (serviciu);
  • port.

Tipuri. Definește tipurile de date utilizate la schimbul de mesaje. În DemowebserviceService.wsdl, importăm DemowebserviceService_Schema1.xsd în loc de determinarea tipurilor de date din fișierul WSDL.

Mesaj. Definește mesajele, schimbul care are loc. Avem 2 posturi: "Bună ziua" și "Helloresponse". Mesajul Hello are o parte numită "parametri". Această parte are elementul "TNS: Bună ziua". Mesajul Helloresponse are o parte numită "parametri", care este similară cu salutul. Această parte are elementul "TNS: Helloresponse". Elementele Hello și Helloresponse sunt definite în fișierul DemowebserviceService_Schema1.xsd. În curând vom lua în considerare.

Tipul de port - Puncte terminale acceptate. Fiecare operație oferă mesaje de intrare și ieșire. Operațiunea noastră "Hello" constă din mesajul de intrare "TNS: Bună ziua" și ieșirea "TNS: Helloresponse". Aceste operațiuni corespund schimbului de solicitare-răspuns. WSDL oferă 4 schimbări diferite de schimb pentru punctul final:

  • o singură cale (unidirecțională);
  • cere raspuns;
  • solicitarea solicitantă (necesită răspuns);
  • notificare.

Cu schimbul unidirecțional, punctul terminal primește doar un mesaj. Când faceți schimb de "răspuns de interogare", punctul final acceptă mesajul și trimite mesajul corespunzător. Când utilizați schimbul de "răspuns-răspuns", punctul final trimite mesajul și acceptă mesajul corespunzător. Atunci când schimbați punctul terminalului "Notificare" trimite doar un mesaj.

Legare Definește detaliile protocolului și specificația formatului de mesaje pentru operațiuni și mesaje definite de tipul de port. Pentru atributul de stil, folosim valoarea documentului. Atributul de stil oferă 2 stiluri de mesaje diferite: RPC și document. Mesajul stil RPC conține parametri și valori returnate. Mesajele stilului de documente conțin documente. Atributul de transport indică URI pentru transportul de săpun. Valoarea specificată http://shemas.xmlsoap.org/soap/http înseamnă că legarea HTTP va fi utilizată în specificația SOAP. URI Pentru antetul HTTP pentru săparea HTTP pentru săpunul de legare HTTP este specificat în atributul de săpare. Deoarece se utilizează legătura HTTP HTTP, valoarea atributului de soapacție este obligatorie. Pentru atributul de săpare, folosim un șir gol "". SOAP: Elementul corpului determină modul în care sunt compuse părțile mesajului din interiorul elementului de mesaj de săpun al corpului. Atributul Utilizare furnizează 2 opțiuni diferite: literal (literal) și codificat (codificat). Folosim literal. Aceasta înseamnă că am ales definiția unei scheme specifice care utilizează fie atributul sau elementul de tip. Când utilizați versiunea codificată, tipul abstract este utilizat cu regulile de codificare.

Serviciu. Determină setul de porturi utilizate.

Port. Definește drogul terminal al comunicării prin specificarea adresei de rețea pentru obligatoriu.

adresa de rețea pentru legare. În cazul nostru, adresa de săpun Endpoint este http: // localhost: 9081 / helloworldwproject / demowebserviceservice.

Listing 3. DemowebserviceService.wsdl.

Crearea unei scheme

Importam DemowebserviceService_Schema1.xsd de la DemowebserviceService.wsdl. Luați în considerare fișierul DemowebserviceService_Schema1.xsd. Este scrisă în schema XML de definiție pentru a descrie structura și restricțiile conținutului documentelor XML. Avem 2 elemente: Bună ziua și Helloresponse. Fiecare element este tip. Tipul Hello are un element "Arg0", care este un șir. Elementul "Arg0" este opțional, deoarece valoarea atributului minocvers în anunțul său este egală cu 0. Dacă atributul minocvors este setat la 1 sau mai mult, elementul trebuie specificat. Același lucru este valabil și pentru elementul "retur" în tipul Helloresponse.

Listing 4. DemowebserviceService_Schema1.xsd.

Noțiuni de bază cu instrumentul de validare a serviciilor Web pentru programul WSDL și SOAP

Deci, ne-am uitat la WSDL și schema. Să începem serverul de servicii web astfel încât să puteți activa serviciul web de la instrumentul de validare a serviciilor Web pentru WSDL și săpun.

Pentru a porni instrumentul de validare a serviciilor Web pentru WSDL și Săpun, Java 6 (sau mai sus) și API-ul digital și API-ul de decodare XML corespund specificațiilor consorțiului de consorțiu largi la nivel mondial "Sintaxa și prelucrarea criptării XML" (http: / / www sunt necesare. w3.org/tr/xmlenc-core/).

IBM Java 6 oferă implementarea JSR 106: API-ul de criptare digitală XML. Dacă ați instalat sistemul IBM Java 6, înseamnă că totul este pregătit pentru muncă și nu va instala nimic mai mult.

Dacă în timpul de execuție Java 6, de exemplu, Sun Microsystems ™ Java 6, No XML Digital Cription API, trebuie să instalați biblioteci de implementare JSR 106 sau Apache ™ XML Versiunea 1.4.3, care poate fi descărcată la http: / /santuario.apache.org/. Este suficient doar pentru a descărca o distribuție binară, dezarhivați-o în director și specificați programul instrumental unde se află acest director utilizând parametrii liniei de comandă -VMargs și -Daxs.

La momentul scrierii acestui articol, instrumentul de validare a serviciilor Web pentru WSDL și SOAP acceptat JSR 106 și Apache XML Security Versiunea 1.4.3 pentru criptarea și decriptarea digitală XML. Dacă doriți să verificați semnăturile digitale în mesajele de săpun, aveți nevoie de biblioteci de implementare JSR 105: Apis de semnătură digitală XML. Din fericire, mașinile virtuale Java 6 de la Sun Microsystems și IBM oferă implementări ale JSR 105. De aceea a fost aleasă Java 6 ca cerințe minime Prin timpul de execuție Java. Dacă mediul dvs. Java 6 nu oferă biblioteci care implementează JSR 105, trebuie să le găsiți.

Instrumentul de validare a serviciilor Web pentru programul WSDL și SOAP poate fi descărcat gratuit. Instalarea este foarte simplă. Dezarhivați pachetul în director și rulați wsvt.exe. Dacă a ta. mașină virtuală Java implicit nu este un mediu Java 6 care să accepte semnăturile digitale XML și criptarea și decriptarea digitală, trebuie să specificați locația Java 6 cu parametrul -VM, de exemplu:

wSVT -VM C: \\ IBMjava6 \\ bin \\ java.exe

Din nou, dacă aveți IBM Java 6, nu aveți nevoie de altceva. Tot ce aveți nevoie deja activat în IBM Java 6. Când utilizați Java 6 de la Sun Microsystems, trebuie să specificați locația programului Apache XML Security pentru a decripta mesajele de săpun criptate.

De exemplu, următoarea comandă va lansa un program cu Biblioteca Sun Java 6 și Apache XML versiunea 1.4.3, situată în directorul C: \\ XML-Security-1_4_3 \\ Libs:

wSVT -VM C: \\ Sunjava6 \\ bin \\ java.exe -vmargs -daxs \u003d C: \\ xml-Security-1_4_3 \\ libs

Mai jos este o listă a fișierelor Biblioteca de Securitate Apache XML care sunt efectiv utilizate de Instrumentul de validare a serviciilor Web pentru WSDL și săpun, deși Apache XML Security versiunea 1.4.3 vine cu 9 fișiere JAR:
Commons-logging.jar;
serializer.jar;
xalan.jar;
XMLSEC-1.4.3.jar.

În Manifest.mf Instrumentul de validare a serviciilor Web pentru programele WSDL și SOAP sunt următoarele:
Bundle-activationPolicy: Leneş.
Bundle-ClassPath: .,
Externe: $ AXS $ / Commons-logging.jar,
Extern: $ AXS $ / serializer.jar,
Extern: $ AXS $ / xalan.jar,
Externe: $ AXS $ / XMLSEC-1.4.3.Jar

De aceea, a fost necesar să specificați -VMARGS -DAXS \u003d C: \\ XML-Security-1_4_3 \\ libs, astfel încât Sun Java 6 Mediu este decriptat mesajele de săpun criptate.

Am petrecut destul timp mult timp pentru a elimina clasele și incompatibilitățile de a vă conecta la clasele XML care se află în mediul de timp de execuție Sun Java, Apache XML Security și unele pluginuri eclipse. Configurarea mediului de execuție a IBM Java a trecut fără dificultate, deoarece acest mediu vine cu implementarea JSR 106 și nu necesită securitate Apache XML.

Crearea de proiect

Acum, după înființarea și executarea program instrumental., Puteți crea un nou proiect. Proiectul poate conține un fișier WSDL, mai multe fișiere de schemă asociate fișierului WSDL și mesaje de săpun în fișierele XML. Dacă există mai multe fișiere WSDL în proiect, se utilizează numai unul dintre ele, în timp ce altele sunt ignorate la verificarea corectitudinii mesajului de săpun al fișierului XML. Pentru a utiliza un alt fișier WSDL, trebuie să creați un proiect separat. Fiecare mesaj de săpun trebuie să fie conținut într-un fișier cu extensie.xml, altfel nu va fi considerat un mesaj de săpun.

  1. Faceți clic dreapta și selectați Nou\u003e proiect..

  1. Alege Proiect. în GENERAL..

  1. Introduceți "proiectul de testare" în domeniu Denumirea proiectului. și faceți clic pe FINALIZAREA..

Importați WSDL și scheme

Am creat proiectul "Proiectul de testare". Acum puteți importa WSDL și XSD.

  1. Selectați un proiect, apoi din meniul contextual, selectați Import.

  1. Alege Sistemul de fișiere în GENERAL..

  1. Selectați un director în care sunt stocate WSDL și XSD.
  2. Selectați 2 fișiere (DemowebserviceService.wsdl și DemowebserviceService_Schema1.xsd) și faceți clic pe FINALIZAREA..

Privire de ansamblu și scheme WSDL

Acum avem un proiect cu WSDL și XSD. Puteți să faceți dublu clic pe WSDL din stânga WSDL pentru a vizualiza WSDL în modul de proiectare și sursa ( sursă). În modul de proiectare, puteți vizualiza serviciul Web cu date de intrare și ieșire.


În modul sursă, puteți vizualiza și edita WSDL într-un editor de text.


Dacă fișierele XSD nu pot fi deschise în editorul XSD, le puteți deschide în editorul XML selectând Deschideți cu \u003cXML Editor În meniul contextual al acestui fișier XSD.


Am deschis DemowebserviceService_Schema1.xsd în editorul XML.


Crearea unui mesaj de săpun

Deci, avem un WSDL și o schemă gata să verifice corectitudinea mesajelor de săpun. Vom proceda la testarea instrumentului de validare a serviciilor Web pentru programul WSDL și SOAP cu un mesaj de săpun. Trebuie să activați mesajul săpun al proiectului. Mesajul SOAP trebuie să fie conținut în fișier cu extensie .xml astfel încât să poată fi verificat corect.

  1. Alege Nou\u003e XML. Pentru a crea mesaje de săpun în proiect.

  1. Alege Proiectul de testare. Pentru dosarul părinte al noului mesaj de săpun. Dacă fișierul nu este încă selectat, introduceți "Demosoapmessage.xml" în câmp Nume de fișier. și faceți clic pe FINALIZAREA..

Programul numește automat un editor XML cu un nou fișier XML. Nu are decât un șir cu o versiune și o codificare XML. Este bine că avem cel puțin ceva înainte de crearea mesajului de săpun de la zero. Știți cum să faceți un mesaj de săpun? Nu iti face griji. În secțiunea următoare, vom lua în considerare acțiunea de ao crea în pași.


Pentru a crea un mesaj de săpun, puteți activa serviciul "Hello" utilizând parametrul "Parametrii" cu indicarea numelui meu - "Jinwoo". Desigur, puteți folosi propriul nume. A folosit spații de nume http: // demo /. Aveți grijă - este scris ca http: // demo /, nu http: // demo, este esențial.

Listing 5. Helloworldsoapmessage.xml.
Jinwoo.

Vedeți această problemă de mesaj de săpun? Dacă da, nu vă faceți griji. Vom face acest lucru mai târziu.


Mesaje de săpun

Sunteți gata să trimiteți un mesaj către serverul de servicii Web?

  1. Selectați Mesaj SOAP și selectați

  1. În cererea de săpun de transmisie și primiți solicitarea de săpun și primiți fereastra de răspuns la SOAP, puteți completa Adresa de serviciu, Soapacțiune și Tipul de conținut.. În această aplicație, nu trebuie să specificăm săparea, deoarece am folosit un șir gol "" pentru atributul de săpare din secțiunea fișierului DemowebserviceService.wsdl.
  2. Introduceți http: // localhost: 9081 / helloworldwsproject / demowebserviceservice în domeniu Adresa de serviciuDacă serverul rulează pe computerul local din portul localhost: 9081. În caz contrar, trebuie să introduceți adresa reală la care este disponibil serviciul Web.
  3. Alege text / html. Pentru câmp Tipul de conținut..
  4. apasa butonul O.K. Pentru a trimite mesaje de săpun pe server.

Primiți mesaje de săpun

Dacă serverul este configurat și rulează, trebuie să obțineți un răspuns la SOAP. Dacă răspunsul nu vine, verificați corectitudinea adresei și tipului de conținut.


Verificarea corectitudinii mesajului de săpun

Excelent! Am acceptat un răspuns la săpun. De asemenea, persistă în proiect. Dar asteapta. Vedeți ceva greșit? Avem "Bună ziua, amice!" În loc de "Bună ziua, Jinwoo!". Ceva n-a mers bine? Nu aveți un concept?

Din păcate, serverul de servicii web nu ne-a permis să știm ce sa întâmplat. Nu există avertismente. Situația în care sunt trimise răspunsuri de săpun imprevizibile, iar serverul de servicii Web nu are conceptul că nu se întâmplă, poate fi foarte periculos. Chiar și beneficiarii răspunsurilor săpunului nu pot observa probleme în mesajul de săpun în cauză.

Instrumentul de validare a serviciilor Web pentru instrumentul WSDL și SOAP vă permite să determinați ce se întâmplă nu este așa.

Listarea 6. Răspuns
Salut amice!
  1. Selectați un mesaj SOAP de răspuns și faceți clic pe Valida..

Instrumentul de validare a serviciilor Web pentru WSDL și SOAP a găsit o eroare în mesajul SOAP.

SOAP nevalid Mesaj: CVC-complex-tip.2.4.a: Conținutul nevalid a fost găsit începând cu elementul "Parametrii". Unul dintre "(Arg0) este expediat.

Editarea mesajelor de săpun

  1. Programul se plânge de valoarea "Parametrii". Schimbați-l la Arg0 și salvați.
Listarea 7. Schimbarea mesajului de săpun
Jinwoo.
  1. Verificați corectitudinea mesajului de săpun al răspunsului modificat. Nu apar mai multe mesaje de eroare.

  1. Acum suntem gata să trimitem un răspuns modificat la server. Selectați mesajul săpun și apoi selectați Transmiteți solicitarea de săpun și primiți răspunsul la săpun.

  1. În cererea de săpun Transmitere și primiți fereastra de răspuns la SOAP, introduceți http: // localhost: 9081 / helloworldwsproject / demowebserviceservice în domeniu Adresa de serviciuDacă serverul rulează pe portul localhost: 9081.
  2. Alege text / html. Pentru câmp Tipul de conținut. și faceți clic pe O.K..

De data aceasta, după cum era de așteptat, vine răspunsul corect.


Listarea 8. Răspunsul la săpun
Bună ziua, Jinwoo!

Detectarea spațiului de nume necorespunzător

Ce se întâmplă dacă trimiteți un mesaj cu spațiu de nume incorect?

  1. Schimbați spațiul de nume pe http: // demo2 / salvați mesajul.

Listarea 9. Schimbați spațiul de nume
Jinwoo.
  1. Apoi puteți trimite o solicitare către server.

Veți vedea o situație excepțională IOException: Serverul a returnat codul de răspuns HTTP: 500 pentru URI: http: // localhost: 9081 / helloworldwproject / demowebserviceservice.


Serverul de servicii web a trecut prin informații despre răspuns despre situația excepțională IOException, dar aceste informații nu sunt suficiente pentru a detecta o eroare. Verificați corectitudinea mesajului utilizând programul de instrumente dacă doriți să obțineți date mai detaliate pentru a rezolva problema.


Rapoartele programului: "Mesaj de săpun nevalid: CVC-complex-tip.2.4.a: Conținutul nevalid a fost găsit începând cu elementul" NS0: Bună ziua ". Unul dintre "(" http: // demo / ": Hello," http: // demo / ": helloresponse)" este de așteptat ".

Acest mesaj indică faptul că valoarea este așteptată http: // demo /. Acesta este acesta, și nu un cod de răspuns HTTP 500, trebuie să știm.


Verificarea corectitudinii mesajelor de săpun criptate

Ce se întâmplă dacă mesajele dvs. săpun sunt criptate? Nici o problemă dacă aveți cheile și parolele. Doar selectați mesajul săpun și Valida. Așa cum se face acest lucru pentru orice alte mesaje de săpun obișnuite. Dacă mesajul dvs. SOAP este criptat, pe ecran apare o solicitare similară cu cea prezentată în Figura 35.


La momentul acestei scrieri, sunt acceptate 3 tipuri de magazine cheie:

  1. Magazinul Key Java (JKS).
  2. Java Cryptografie Extensie Magazin de cheie (Jeks).
  3. Standardul de sintaxă a schimbului de informații personale (standarde de criptografie cheie cheie # 12).

Trebuie să furnizați informații despre magazinul dvs. cheie: numele fișierului, tipul fișierului și parola. Dacă informațiile sunt corecte, trebuie să selectați tasta și parola. De asemenea, puteți găsi informații despre lista dvs. de stocare și cheie și certificatele din magazinul cheie, de exemplu, tipul de stocare cheie, numele furnizorului, versiunea furnizorului, informațiile furnizorului, tipul de cheie, tipul de creație, tipul de certificat, algoritmul și formatul.


Dacă toate informațiile sunt corecte, programul va genera un mesaj de săpun decriptat și va verifica corectitudinea sa.


Următorii algoritmi de criptare sunt în prezent acceptați:

  • Standardul avansat de criptare (AES) în modul de înlănțuire a blocului (CBC) cu vector de inițializare (128/192/256 biți).
  • Criptare cheie standard de criptare (AES) (128/192/256 biți).
  • Triple Data Criptare Algoritm Moduri de operare (triple-des) Criptare cheie.
  • Triple Data Criptare Algoritm Moduri de operare (TRIPLE-DES) Criptare cheie în modul de înlănțuire a blocului (CBC).
  • RSA Cryptografie Specificații versiunea 1.5.
  • RSA OPTIMAL Criptare asimetrică (OAEEP) este o metodă cu o funcție de generare a măștii.

Verificarea corectitudinii mesajelor de săpun cu o semnătură digitală

Ce se întâmplă dacă mesajul dvs. de săpun are o semnătură digitală? Doar selectați mesajul SOAP și apoi selectați SOAP Mesaj de verificare a semnăturii digitale.


În cazul în care un semnatura digitala Corect, veți vedea următorul ecran:


În caz contrar, programul va raporta o eroare în semnătură. Următoarele specificații și algoritmi de semnătură digitală sunt în prezent acceptate:

  • Algoritmul hash securizat 1 (SHA-1)
  • Codul de autentificare a mesajelor hash (HMAC)
  • Algoritmul semnăturii digitale (DSA)
  • Standardele de criptografie generale-cheie (PKCS # 1)
  • Algoritmul de criptare RSA cu algoritm de hash securizat (SHA-1)
  • Canonic XML versiunea 1.0 și 1.1
  • Transformări XSL (XSLT) Versiunea 1.0
  • Limba de cale XML (XPATH) Versiunea 1.0
  • Base64.

Accesul la serviciul Național de Catering Național al SUA utilizând mesaje de săpun

Creat și testat de către US Simple Web Service funcționează bine. Poate fi folosit acest program În mediul "real"? Puteți încerca să lucrați cu serviciul web național din SUA furnizat de U.S. Administrația Națională Oceanică și Atmosferică (NOAA).

  1. Creați un proiect.

  1. Creați un cod de mesaj de săpun XML.


Mesajul Mete Național al SUA oferă multe servicii web diferite. Puteți încerca să lucrați cu serviciul NDFDGENBYDAY, care oferă prognoze meteo pentru un punct cu o anumită latitudine și longitudine.

Pentru a accesa NDFDGENBYDAY, trebuie să furnizați următoarele informații:

Tabelul 1. Ndfdgenbyday.
Numele serviciului (numele serviciului)Ndfdgenbyday
Punct final (terminal)http://www.weather.gov/forecasts/xml/soap_server/ndfdxmlserver.php.
Soapacție (acțiunea de săpun)http://www.weather.gov/forecasts/xml/dwmlgen/wsdl/dfdxml.wsdl#ndfdgenbyday
encodingStyle (stil de codare)http://schemas.xmlsoap.org/soap/encoding/
Spațiul namelor (spațiul de nume)http://www.weather.gov/forecasts/xml/dwmlgen/wsdl/ndfdxml.wsdl.
latitudine (latitudine)Numar decimal
longitudine (longitudine)Numar decimal
startdate (data inițială)Data
numele (numărul de zile)Întreg
format (format)Linia

În acest exemplu, dorim să creăm o cerere de săpun pentru a primi o prognoză săptămânală pentru localitatea cu coordonate (LAT38,9, LON-77.01), începând cu anul 2010-07-23 în format 24 de ore:

Listarea 10. Cerere de săpun
38.99 -77.01 2010-07-23 7 24 pe oră.

Nu am indicat spațiul de nume, deoarece serviciul a lucrat fără ea. Dacă apar probleme cu spațiul de nume, setați-l.


Selectați mesajul I. Transmiteți solicitarea de săpun și primiți răspunsul la săpun În instrumentul de validare a serviciilor Web pentru WSDL și săpun.

Tabelul 2. Cererea de informații
NumeValoare
Punct final (terminal) http://www.weather.gov/forecasts/xml/soap_server/ndfdxmlserver.php.
Soapacție (acțiunea de săpun) http://www.weather.gov/forecasts/xml/dwmlgen/wsdl/dfdxml.wsdl#ndfdgenbyday
Tip de conținut (tip de conținut)text / xml; Charset \u003d utf-8

Acum, datele de proiecție au devenit mult mai ușor de citit.


Dacă acest sfat nu va părea prea convenabil pentru dvs., puteți utiliza propria metodă de formatare HTML. Majoritatea serviciilor web oferă rezultate într-un format XML, deci nu trebuie să recurgeți în mod constant acest tehnician.

Concluzie

Am creat, transformat, acceptat și verifică corectitudinea mesajelor de săpun utilizând instrumentul de validare a serviciilor Web pentru WSDL și săpun. Acest program vă permite să identificați cu exactitate problemele pe care majoritatea serverelor de servicii web nu sunt chiar în măsură să detecteze că poate duce la consecințe grave în viața reală. Utilizarea acestui program la etapa de dezvoltare face posibilă reducerea timpului de depanare în timpul funcționării.

Buna!

În mai multe articole, voi vorbi despre posibilitățile de a testa cu SOAPUI, ca lucrări de servicii web 1C. Voi da, de asemenea, exemple de întoarcere de la documentele 1c în formatul PDF. și fișiere complexe XML. Unele lucruri sunt similare cu cele, totuși, voi lua în considerare exemple mai complexe de a lucra cu serviciile web. Dar mai întâi pentru a începe, voi lua în considerare procesul de desfășurare a serviciilor web și de a lucra cu SOAPUI pentru a facilita înțelegerea funcționării lor de la zero.

1. Serviciu web simplu

Pentru a începe, luați o configurație cadru fără servicii web și treceți prin pașii pentru a le crea.

Adăugați un nou serviciu web numit Test1 și creați o operație Hello în el cu un tip de șir returnat. Numele și operațiile de servicii web sunt mai bune pentru a seta întotdeauna în limba latină.

De asemenea, trebuie să specificați spațiul de nume URI și numele fișierului de publicare:

Când apăsați Magnifierul în câmpul "Câmpul de procedură", modulul de service Web va fi deschis și puteți implementa funcția Hello.

Hello () Returnarea funcției "rând de la serviciul web 1c"; Endfunction

2. Publicarea serviciului Web.

Acum că funcția rezultată este disponibilă pe HTTP, trebuie să publicați serviciul pe serverul Web. Apache 2.2 este potrivit pentru aceasta. Am citit articolul despre cum să configurez lucrarea cu IIS și mi-a părut mult mai dificil. După instalarea și executarea Apache 2.2, trebuie să mergeți la meniul de administrare - publicați pe un server web. Câmpul "Catalog" trebuie să fie umplut și să conțină setarea Apache. Amintiți-vă "numele" și "adresa" serviciului Web, acestea vor fi utile pentru noi în pasul următor.

3. Testarea cu SOAPUI

Pentru a testa, creați un utilizator separat WSUSER, cu o parolă simplă și oferă drepturi depline.

După aceea, instalați și executați soapui. Acest program este foarte convenabil pentru testarea serviciilor web, poate primi descrierea lor și a face post-cereri către servicii.

Accesați fișierul - noul meniu proiect SOAP, întreabă numele proiectului Hellost și în câmpul WSDL inițial, scriem acest link:

http: //localhost/test_ws/ws/test1.1cws? WSDL

În ea, partea "test_ws" a fost stabilită în ultima etapă a câmpului "Nume" și teste1.1Cws în câmpul "Adresa".

Faceți clic pe OK și în acest stadiu va trebui să fiți conectat prin introducerea utilizatorului de testare al WSUser. Un proiect și două elemente de legare vor fi create.

Săpun12binding se caracterizează prin lucrul la versiune noua SOAP 1.2 Standard. Să deschidem elementul solicită1 în testul12binding și să vedem acest lucru:

Soapi arată care XML va fi transmis la funcția noastră. Înainte de a începe testul, există o altă nuanță, SOAPI implicit va necesita autorizarea fiecărui element de solicitare separat. Prin urmare, pentru a nu specifica acest lucru de fiecare dată când trebuie să faceți clic pe butonul din dreapta al mouse-ului de pe testare12binding, selectați Afișați vizualizarea interfeței și în fereastra care se deschide în fila "Service final" a numelui serviciului Web și a parolei:

Dacă acest lucru nu este făcut, atunci pentru fiecare solicitare va trebui să setați autorizarea, în panoul de jos prin butonul Auth.

Acum puteți efectua în cele din urmă cererea la funcția Hello și vedeți răspunsul:

Mare, totul a funcționat!

4. Transferați parametrii simpli la funcția.

Acum do. optiune noua Cu parametrii, de exemplu, verificați lucrarea cu datele, vom face funcția GetSeedoCumbersByDate, care va primi o dată de documente (factură de cheltuieli) și numere de documente de returnare pentru acest șir de date. Adăugați un parametru de dată pentru a funcționa cu tipul de date:

codul este:

Funcția GetSauedoCnumbersbyDate (data) // DataNent \u003d Start (data); Dateonton (data); Evaluări \u003d documente. Plecare. Ștergeți (punct de date, datchetone); numere \u003d ""; În timp ce sedocumentele. Următorul () Ciclul de numere \u003d numere + "Nr." + Curs de precizie. Maker + "; Endcycle; Numărul de retur; Endfunction

Acum, în SOAPI, faceți clic dreapta, trebuie să faceți clic pe elementul TestsoSOAP12 și să selectați Definiție Actualizare. După aceasta, proiectul va apărea funcția GetSauedocNumbyDate și cererea gata făcută. Pentru a umple data, trebuie să utilizați formatul "YYYY-MM-DDHH: MM: SS" (puteți vedea pe W3SCHOOLS și recomandăm cu siguranță utilizarea acestui site pentru a înțelege lucrarea cu XML)

Apoi, va face o astfel de solicitare și va răspunde:

5. Pachete XDTO.

Dacă aveți nevoie să transmiteți parametri mai complexi funcției (de exemplu, XML cu mai multe câmpuri) sau pentru a primi XML complex ca răspuns, atunci nu putem face fără pachete XDTO.

Lucrul cu XDTO este luat în considerare în ciclul articolelor. De fapt, pachetul determină structura și tipul câmpurilor utilizate de fișierele XML.

Voi lua în considerare un exemplu de transfer și de primire a unui fișier XML, tipul care este definit în pachet

Pe lângă următoarele articole, voi considera exemple:

  • transferați la fișierul 1C XML nu este descris în pachet în format Base64
  • ieșirea 1c. document PDF. În formatul Base64 și decodificarea acesteia
  • obținerea de la fișierul 1C XML cu o structură încorporată a elementelor și determinarea cantității acestora

6. Transmisie la 1C în parametrul fișierului XML, tipul care este definit în pachet.

Sarcina va fi aceasta: să găsească un document al facturii de cheltuieli pentru numărul specificat în XML de intrare și data și returnarea documentului găsit. De asemenea, trebuie să vă întoarceți sub formă de XML cu un număr, o dată, contrapartidă și codul său și partea tabară bunuri.

Creați pachetul de pachete cu spațiul de nume Packet1_ns. Pentru un fișier XML primit, definim tipul de obiect IndocsaleQuery cu câmpul numar al tipului de șir și a câmpului Data de tip DataTime. Pentru fișierul de ieșire, vom defini mai întâi tipul pentru o singură linie a tabelului Parte a mărfurilor: SărbătoareM cu numele câmpului de tip, suma de preț, cantitate de zecimale de tip. Iar documentul Saledoc în sine va avea un tip integrat: numărul, data, câmpurile de parteneriere și câmpul Saleitems, care va avea tipul de Sărbăciune și numărul maxim --1. Este un astfel de câmp indică faptul că o serie de elemente pot fi prezente în ea. Așa că se pare că în configurator:

Afișați mai întâi codul funcției și apoi voi explica ce se întâmplă

Codul:

Funcția de obținere a unui metru \u003d incomodxml.number; Datades \u003d incomodxml.date; solicitare \u003d cerere nouă; Solicitare.text \u003d "Selectați | Expendables. NumeronClatură. Nume ca nume, consumabile. Preț, ca preț, | Epentables Produse de cheltuieli. Link. Maker \u003d & Număr | și cheltuieli. Link. Date \u003d & Datersy "; Solicitare. Parametru de instalare ("număr", de unică folosință); Solicitare. Instalarea parametrului ("Datades", Datades); Eșantionare \u003d interogare. Umpleți (). Selectați (); Dacă eșantionul. Racing () \u003d 0 apoi // Returnarea erorii fluxului de mare \u003d Factoryxdto. Tip ("Packet1_ns", "saladoc"); Pachet de documentație \u003d Factoryxdto. Creați (margine); Fluxul ambalat .Number \u003d "Documentele nu au fost găsite!"; Restituire; În caz contrar, creăm tipurile de tirioculare \u003d Factoryxdto. Tip ("Packet1_ns", "saladoc"); Tipbabbing \u003d FactoryXdto. Tip ("Packet1_ns", "SaleITEM"); Pachet de documentație \u003d Factoryxdto. Creați (margine); // selectați din partea de masă SCH \u003d 0; În timp ce eșantionul. Următorul () Ciclul în cazul în care SCH \u003d 0 apoi // Completați detaliile documentului Dock \u003d eșantion. Link; Documentație de pachete .Number \u003d dock. Documentație pachet.Date \u003d dock; Documentație de pachete .partnername \u003d linie (dock. Kontragent); încheiat; // Completati partea de masă Ambalare \u003d FactoryXdto. Creați (plăcut); Completarea (negocierea, eșantionul); // adăugați-l la documentul documentului de pachete .sale.saleitems. Addly (negociere); SCH \u003d SCH + 1; Endcycle; Restituire; încheiat; Endfunction

Iată două nuanțe principale. Primul: Deoarece a fost specificat tipul de parametru incomodxml primit și a fost descris acest tip în pachet, este imediat posibil să contactați câmpurile din acest XML primit. În al doilea rând: lucrați cu Fabrica XDTO. Din acesta, a fost obținut un tip pentru parametrii de ieșire rezultat și a creat valoarea acestui tip, care a fost umplută cu câmpurile necesare. De asemenea, merită remarcat faptul că în tipul Sayoc ar trebui să introduceți un câmp de eroare separat, dar pentru testul de eroare, obiectele vor fi înregistrate în câmpul Număr.

Iată cum arată rezultatul acestei cereri în SOAPI:

După cum puteți vedea, totul funcționează, dar totuși există ceva de îmbunătățit - de exemplu, aș dori să știu câte elemente SaleIntems în documentul nostru.

Despre acest lucru și despre exemple mai complexe, vă voi spune în următorul articol.

În arhiva atașată - descărcare baza de informare Și proiectul soapui.

Săpun (Protocol simplu de acces la obiecte) Este un protocol standard de mesagerie între client și server. Acesta este utilizat, de obicei, împreună cu HTTP (S), dar poate funcționa și cu alte protocoale la nivel de aplicație (de exemplu, SMTP și FTP).
Testarea săpunului din punctul de vedere al tehnicilor de testare nu este fundamental diferită de a lucra cu alte API, dar necesită pregătire preliminară (în ceea ce privește teoria protocolului) și instrumentele speciale de testare. În acest articol, aș dori să formulez o listă mică de verificare a cunoștințelor și abilităților necesare, care va fi la fel de util ca un tester de săpun (adesea nu reprezentând "pentru ceea ce este suficient" după setarea sarcinii) și managerul forțată să evalueze cunoștințele testerelor și să dezvolte planuri de învățare.

Baza teoretică

Faptul că săpunul este un protocol are o mare importanță pentru testarea: trebuie să explorați protocolul în sine, standardele "primare" și protocoalele pe care se bazează, precum și (după caz) extensiile existente.

XML.
XML este un limbaj de marcare similar cu HTML. Orice mesaj trimis / primit prin săpun este un document XML în care datele sunt convenabil structurate și ușor de citit, de exemplu:



Julia.
Natasha.
Aducere aminte
Nu uitați să scrieți un articol!


În detaliu despre XML, puteți afla pe W3SCHOOLS sau CODENET (în limba rusă). Asigurați-vă că acordați atenție descrierii spațiilor de nume (metoda de rezolvare a conflictelor atunci când descrieți elementele din XML) - în săpun, utilizarea lor este necesară.

XSD.
Când lucrul este întotdeauna convenabil să aveți o descriere standardizată a posibilelor documente XML și verificați-le pe corectitudinea umplerii. Pentru a face acest lucru, există o definiție a schemei XML (sau XSD abreviat). Cele două caracteristici principale ale XSD pentru un tester sunt o descriere a tipurilor de date și impunerea de restricții privind posibilele valori. De exemplu, un element din exemplul anterior se poate face opțional pentru a umple și limita dimensiunea 255 de caractere utilizând XSD:

...







...

Săpun de expansiune.
În munca dvs., puteți întâlni, de asemenea, diferite standarde de săpun "extensii" - WS- *. Una dintre cele mai frecvente este WS-Security vă permite să lucrați cu criptare și semnături electronice. Adesea, politica WS este folosită cu aceasta, cu care puteți gestiona drepturile de a utiliza serviciul dvs.

Exemplu de utilizare a securității WS:


Alice.
6S3P2EWNP3LQF + 9VC3EmNot57OQ \u003d
Yf6j8v / caqi + 1nrsglrbuzhi
2008-04-28T10: 02: 11z

Toate aceste extensii sunt modele complexe utilizate departe de fiecare serviciu de săpun; Studiul lor detaliat la etapa inițială de explorare a testelor de săpun este puțin probabil să fie relevantă.

Instrumente

După cum ați înțeles deja, săpunul este un lucru serios, să lucrați cu el, trebuie să cunoașteți teoria și numeroasele standarde. În practică, o astfel de complexitate ar duce la costuri foarte tangibile ale forței de muncă (de exemplu, ar fi necesar să se urmărească schema în notebook de fiecare dată și să trimită cererile curbei). Prin urmare, au fost create instrumente care facilitează lucrarea cu săpun.

Editori XML / XSD
Un tester bun începe să testeze în stadiul documentației de scriere, deci este convenabil să utilizați editori speciali pentru a verifica schemele. Două cele mai renumite - oxigen (cross-platform) și Altova (numai pentru Windows); Ambele sunt plătite. Acestea sunt programe foarte puternice care utilizează în mod activ analiștii atunci când descrie serviciile.

Trei caracteristici au fost utile în practica mea: vizualizarea XSD, generarea XSD bazată pe XSD și validarea XML prin XSD.

1. Vizualizare XSD. Avem nevoie de o prezentare vizuală a schemei care vă permite să identificați rapid elementele și atributele obligatorii, precum și limitările existente. De exemplu, elementul de text este necesar pentru a solicita verificareaTextRequest și opțional - toate cele trei atribute (în același timp, atributul de opțiuni stabilește valoarea implicită - zero).

Vizualizarea este necesară atunci când tipurile și restricțiile din sistem sunt multe. Dacă aveți nevoie doar de ea, și nu doriți să plătiți pentru editori speciali, puteți lua în considerare alternative gratuite (de exemplu, JDeveloper).

2. Generația XML bazată pe XSD Utile când doriți să vedeți exemplul corect al mesajului. Eu o folosesc pentru a experimenta rapid cu posibilitatea de completare a mesajului și pentru a verifica nuanțele restricțiilor.

3. După utilizarea funcțiilor de la paragraful 2, este util să țineți cont validarea XML prin XSD - Asta este, verificați mesajul la corectitudine. Împreună, caracteristicile 2 și 3 fac posibilă prinderea defectelor vicleanilor în XSD chiar și atunci când serviciul însuși este în curs de dezvoltare.

Instrumentul de testare - SOAPIU

Testarea săpunului implică aproape întotdeauna utilizarea de soapiu. Puteți citi despre utilizarea acestui instrument în diferite surse (), dar va fi mai eficient să se familiarizeze cu documentația oficială. Am evidențiat 8 nivele condiționate de SOAPI:

Nivelul 1 - Pot trimite cereri
Învață să creați un proiect bazat pe WSDL. Soapui poate genera toate cererile necesare pentru dvs .; Va trebui doar să verificați corectitudinea umplerii acestora și apăsați butonul "Trimitere". După ce a lucrat abilitățile de a crea cereri corecte, trebuie să stăpânești arta de a formaliza solicitări incorecte care cauzează erori.

Nivelul 2 - Pot face suite de testare și cazuri de testare
Începeți să faceți mini-carotite. Kiturile de testare și cazurile de testare vă permit să creați scenarii de testare API, să pregătiți date pentru interogări și să verificați automat răspunsul rezultat la așteptat. La început, ele pot fi folosite pur și simplu ca o colecție de solicitări. De exemplu, dacă ați început un defect și doriți să îl verificați rapid după fixare, puteți selecta un set de testare separat special pentru defectele solicitare.

Nivelul 3 - Pot scrie afirmații
După caz \u200b\u200bde testare, veți fi utile pentru a afla cum să le verificați automat. După aceea, nu veți mai fi nevoie să căutați informații despre răspunsul: Dacă aveți un control automat, cazurile vor fi marcate cu verde (dacă este trecut cecul) sau roșu (dacă nu este trecut). SOAPUI oferă un set mare de controale posibile (afirmații), dar cele mai convenabile și simple sunt conțin și nu conțin. Cu ajutorul lor, puteți verifica disponibilitatea unui text specific în răspunsul primit. Aceste verificări acceptă, de asemenea, căutarea cu expresii regulate.

Nivelul 4 - Folosesc xpath și / sau xquery în afirmații
Pentru cei care sunt puțin familiarizați cu UI cu Selenium, limba XPATH este un lucru familiar. Aproximativ, XPath vă permite să căutați elemente într-un document XML. XQuery - tehnologie similară care poate utiliza XPATH în interiorul în sine; Această limbă este mult mai puternică, seamănă cu SQL. Ambele limbi pot fi utilizate în afirmații. Controalele cu ajutorul lor sunt mai vizate și mai stabile, astfel încât cazurile dvs. se vor bucura de mare încredere.

Nivelul 5 - Pot să scriu teste complexe cu pași speciali

În cazurile de testare, nu numai o singură cerere nu poate fi cuprinsă, ci și mai multe (de exemplu, atunci când doriți să emandați scenariul standard al lucrării utilizatorului "Creați esența" → "Exportați entitatea"). Pot exista și alte pași speciali între cereri, de exemplu:

  • Proprietăți și transfer de proprietăți (Ajutați la reutilizarea datelor și transmiterea acestora între solicitări);
  • Solicitarea JDBC (utilizată pentru a primi date din baza de date);
  • Condițional Goto (vă permite să faceți ramificații sau cicluri în cazul de testare);
  • Rulați testul (ajută la realizarea unor interogări tipice în cazuri de testare separate și la determinarea acestora acolo unde este necesar).

Nivelul 6 - Folosesc script-uri pe groovy

SOAPUI vă permite să scrieți scripturi pe Groovy în diverse locuri. Cel mai simplu caz este generarea de date la cererea însăși utilizând inserțiile $ (\u003d). Folosesc în mod constant astfel de inserții:

  • $ (\u003d Data nouă (). Format ("yyyy-mm-dd'hhhhh: mm: ss")) - pentru inserare data curenta și timpul în formatul necesar;
  • $ (\u003d java.util.uid.randomuid ()) - Pentru a insera codul alatoriu format corect.

Scripturile cu drepturi depline pot fi utilizate ca pași în cazuri și verificări. La un moment dat, veți găsi că mai mulți pași speciali de la nivelul al cincilea pot fi înlocuiți cu un script.

Nivelul 7 - Folosesc mockervicii
SOAPUI bazat pe WSDL poate genera obiecte false. Mock-Object este cea mai simplă simulare a serviciului. Cu ajutorul "MOK" puteți începe scrierea și depanarea cazurilor de testare chiar înainte ca serviciul să fie disponibil pentru testare. De asemenea, le puteți utiliza ca "prize" pentru servicii temporar inaccesibile.

Nivelul 8 - Dumnezeu Soapui
Știți diferența dintre versiunile plătite și gratuite ale SOAPI și utilizați API-ul SOAPI în cod. Utilizați plugin-uri și executați execuția cazurilor prin linia de comandă și / sau CI. Cazurile dvs. de testare sunt simple și ușor acceptate. În general, ați "mâncat un câine" pe acest instrument. V-aș vorbi cu plăcere cu cei care au stăpânit SOAPI la un astfel de nivel. Dacă sunteți astfel - scrieți în comentarii!

Testarea utilizării limbajelor de programare

Voi da un exemplu despre cum arată cererea la API-ul Yandexspeller, făcută folosind groovy-wslite:

import WSLITE.SAP. *
Def Client \u003d New Soapcient ("http://speller.yandex.net/services/spellService?wsdl")
Def Response \u003d Client.Send (Soapaction: "http://speller.yandex.net/services/spellservice/Checketxt") (
Corp (
VerificareTextRequest ("Lang": "RU", "Xmlns": "http://speller.yandex.net/services/spelservice") (
Text ("Oshka")
}
}
}
Afirmă "eroare" \u003d\u003d răspuns.Checktextresponse.spellresult.error.s.Text ()
Afirmă "1" \u003d\u003d [E-mail protejat]()

Din câte știu, cadrele la nivel înalt (de tipul de restul) pentru săpun de testare nu există, dar instrumentul interesant a apărut recent - karate. Cu aceasta, puteți descrie cazuri de testare a săpunului și puteți odihni sub formă de scenarii de scumpare / gherkin. Pentru mulți testeri, recursul karate va fi soluția perfectă, deoarece astfel de scenarii pentru complexitatea scrisului și a cazurilor de susținere vor sta undeva în mijloc între utilizarea SOAPI și scrierea propriului cadru pentru testarea săpunului.

Concluzie

Este puțin probabil ca vreodată să doriți să încercați săpun pur și simplu pentru tine (așa cum s-ar putea întâmpla cu restul-ohm). Acesta este un protocol serios care este utilizat în soluții serioase corporative. Dar greutatea sa este simultan un tester de cadouri: toate tehnologiile utilizate sunt standardizate, există instrumente de înaltă calitate pentru muncă. Din tester necesită doar dorința de a le studia și de a le folosi.

Să aducem împreună aceeași listă de verificare a abilităților necesare pentru tester. Deci, dacă începeți să testați serviciile de săpun, trebuie să știți și să puteți utiliza:

  • WSDL.
  • SĂPUN.
  • Editori XML / XSD (la nivel de vizualizare XSD).
  • SOAPI LA NIVELUL 1.

După cum puteți vedea, accentul principal este de a studia standardele, în SOAPI este suficient doar pentru a putea efectua cereri. Pe măsură ce mă scufund în săpun de testare, veți avea sarcini care vor necesita mai multe abilități și cunoștințe grave, dar nu încercați să studiați totul și imediat. Este mult mai important decât secvența în creșterea nivelului de complexitate a sarcinilor. În urma acestei recomandări, la un moment dat, veți înțelege că au devenit un specialist bun în acest domeniu!

Servicii web în 1c

Acest articol va lua în considerare problemele de integrare a 1c cu serviciile web deja existente și utilizarea 1C în sine ca serviciu web.

În același timp, în cadrul serviciilor web vor fi înțelese că este un sistem care rulează pe Internet și să asigure interacțiunea cu ei nu numai de săpun (care este tocmai serviciul web), ci și în alte moduri, inclusiv HTTP obișnuite - -înregistrări.


Riscurile utilizării serviciilor web 1c

Platforma 1C81 a apărut implementarea serviciilor Web.

Dar utilizarea lor este plină de riscuri:

  1. 1C8 nu funcționează bine prin HTTPS, nu există instrumente de diagnosticare, deci este imposibil să înțelegeți dacă serviciul nu dorește să lucreze prin HTTPS uneori este imposibil. Ieșire - Implementarea serviciilor Web prin Curl sau HTTPS Ridicarea tunelului.
  2. 1C8 aderă la regulile sale de validare a sistemului WSDL. Uneori, pentru motivele inexplicabile, schema WSDL nu dorește să fie încărcată în linkul WS. Puteți învăța numai cauza unui forum partener de la un specialist. Nu există instrumente de diagnosticare WSDL, chiar și cauza sau șirul nu este specificată pe care se întrerupe sarcina diagramei.

Reguli pentru construirea serviciilor de vânzare

Clientul este emis o lucrare la vânzare (verificare) numai dacă tranzacția pentru serviciu a avut succes. În caz contrar, situația este posibilă atunci când clientul primește un cec și va fi încrezător că a primit un serviciu și, de fapt, nu este.

Utilizarea serviciilor de săpun externe

Serviciile Web SOAP utilizează schemele WSDL și obiectele XDTO pentru a reprezenta date.

Descărcați WSDL.

Pentru a utiliza serviciul extern, trebuie să descărcați schema WSDL.

Verificarea valabilității sistemului WSDL

Uneori schema WSDL nu este încărcată în 1c. Puteți verifica validitatea (corectitudinea) circuitului cu orice validator WSDL, de exemplu http://www.validwsdl.com/.

Trebuie să descărcați o schemă la orice site HTTP (puteți prin FTP) și să specificați adresa fișierului în care schema este încărcată:

Caracteristici de descărcare WSDL în 1c

Funcția de încărcare WSDL din 1c este că schemele valide nu pot fi încărcate. Nu există validator încorporat, deci trebuie să căutați o eroare prin analiză distructivă, reducând secvențial numărul de elemente din schemă. Puteți, de exemplu, să ștergeți o descriere a serviciului web.

Prelucrarea pentru testarea unui serviciu web extern de lucru

Pentru a testa serviciul Web extern de lucru, utilizați procesarea "testProlnogservice.epf" de la pachet la acest articol.

Testarea poate fi utilizată pe exemplul serviciului Morpher, cu numele înclinat (adresa serviciului http://www.morher.ru/webservices/morPher.asmx?wsdl):

În acest fel, puteți testa orice serviciu care are puncte simple de intrare care conțin parametri de tip simplu: număr, data, șir.

În procesare, puteți specifica, de asemenea, autentificarea și parola care sunt necesare pentru a autoriza accesul la serviciul Web.

Servicii standard de depanare

Puteți utiliza programul SOAPUI pentru a depana, care poate trimite o solicitare de servicii web arbitrare și poate obține un răspuns de la acesta.

Săpun și https.

Din păcate, săpunul în 1s suficient de capricios se comportă atunci când lucrează prin protocolul HTTPS, practica arată că este imposibil să se realizeze conexiuni https, deși posibilitatea și este extinsă în platformă. Aceasta afectează lipsa instrumentelor de diagnosticare și de depanare pentru a determina motivele, datorită cărora conexiunea nu este stabilită. Prin urmare, este convenabil să utilizați săpunul prin curl.

Mecanismul de utilizare HTTPS încorporat implică faptul că toate certificatele trebuie publicate în fișierul partajat PEM din directorul programului 1C.

Utilizați 1C ca serviciu

Termeni de dezvoltare a serviciului bazat pe 1c

Operațiunea "Bună ziua"

Regula de ton bun este crearea unei operațiuni în serviciul care informează că serviciul este disponibil. Acest lucru facilitează viața integratori, acestea vor fi mai ușor să verifice dacă conexiunea a fost stabilită cu serviciul.

De exemplu, puteți utiliza operațiunea Bună ziua fără parametri, care pur și simplu returnează o valoare booleană a adevărului.

Publicarea serviciului Web

Procedura este bine descrisă în documentație: Fișier: /// C: /PROGRAM%20Files/1cv81/adddoc/ru/v8Addoc81.htm#_TOC176167634:

Sarcina publicării serviciilor Web este redusă la găzduirea fișierelor de configurare * .1CWS Web Services în directorul de server Web corespunzător cu setări corespunzătoare pentru serverul Web. Pentru a executa publicarea serviciilor web, trebuie să executați comanda de meniu "Administrație | Publicarea serviciilor web ".

Ca urmare a executării acestei comenzi, fereastra de publicare va fi deschisă.

Fereastra de publicare a serviciilor web conține calea către serverul web și două listă:

  • "Web Services" - o listă de servicii de configurare web;
  • "Publicare" - o listă de servicii web publicate pe serverul web specificat.

Folosind butonul Compus ..., trebuie să specificați serverul web pe care doriți să îl publicați servicii web.

Fereastra de selectare a căii la serverul Web vă permite să specificați calea în două moduri:

  • În fila "Fișiere" - această metodă este utilizată în cazul în care publicația este efectuată pe același computer pe care este instalat serverul Web. Ca o modalitate, directorul local este specificat, care corespunde paginii de Internet cu care va fi apelat serverul web publicat;
  • În fila Site FTP, această metodă este utilizată atunci când doriți să publicați un serviciu web pe un computer la distanță. Pentru a efectua publicația, trebuie să specificați parametrii conexiunii FTP cu computer la distanță și un director în care va fi publicat serviciul web.

Publicarea serviciului web selectat se efectuează utilizând butonul "Publish"

Pentru a anula publicarea serviciului Web, utilizați butonul Ștergere.

Puteți publica în directorul local sau pe FTP. Puteți publica pe serverul de la distanță pe calea UNC dacă serverul de la distanță intră în rețeaua locală.

După publicarea unui serviciu web este disponibil la "http: //localhost/test.1cws" sau "http://xxx.ru/test.1cws", unde xxx.ru - adresa server la distanta Și localhost este adresa standard a serverului local.

Autorizarea serviciului web 1c

Pentru a accesa serviciul de care aveți nevoie pentru a trece autentificarea.

Problemele de autorizare sunt bine revizuite aici: http://www.forum.mista.ru/topic.php?id\u003d341168 și în documentația de fișiere: /////rogram%20Files/1cv81/adddoc/en/v8adddoc81.htm

De obicei, serviciul web funcționează sub un anumit utilizator (mai des - creat special). Puteți utiliza utilizatorul 1c "atașați" la autentificarea Windows la utilizatorul Windows Iusr_ (pentru utilizator să dezactiveze autorizația 1c). Alternativ, puteți șterge lista utilizatorilor 1c, apoi nu este necesară autorizarea.

Dacă sunt necesare mai mulți utilizatori, puteți crea mai multe înregistrări pentru un server web, pentru a lega fiecare dintre ele. utilizator Windows. În consecință, pentru a vă înregistra în accesul la utilizatorii de ferestre.

În proprietăți, utilizatorul și parola obiectului WS sunt utilizate nu autentificați 1c, dar loginul utilizatorului este un server web.

Testarea serviciului Web 1C

Pentru testare 1C ca serviciu web, utilizați procesarea procesului de procesare TestPromPheep, așa cum este descris în secțiunea "Testarea serviciului Web extern".

Fișier 1CWS și este o descriere WSDL a serviciului Web 1c.

Utilizarea serviciilor de vânzare cu amănuntul

De obicei, în serviciile cu amănuntul sunt utilizate pentru a oferi diverse servicii populației - primind plăți, rambursarea împrumuturilor, transferurile de bani, cumpărare software. etc.

În același timp, pentru serviciul furnizat în 1c, se formează o verificare în care sunt salvați parametrii de tranzacție. După aceea, această verificare este tipărită de către client cu informatii detaliate despre serviciul furnizat. Este posibilă o verificare preliminară, astfel încât clientul să confirme datele introduse de la cuvintele sale prin semnătura sa.

Serviciul poate fi integrat diferit într-un program de vânzare cu amănuntul scris în 1c (UT, cu amănuntul și altul):

  1. Procesarea sau codul în limba 1c poate fi scris, care efectuează toate lucrările cu serviciul.
  2. Un program care funcționează cu serviciul poate fi utilizat și în 1c transmite numai informații pentru verificările de perforare.

Organizarea datelor de serviciu în 1c

Pentru a stoca informații despre tranzacție în cec, este necesar să se creeze o parte tabară suplimentară "vânzări sofisticate" cu detalii:

  • Nomenclatura - legată de verificarea nomenclaturii.
  • Parametrul este legătura cu directorul "Vânzare sofisticată: parametri".
  • Valoarea este valoarea parametrului, tipul compozit. Vizualizarea șirului trebuie să fie destul de lungă (1024 de caractere) care trebuie plasată textul cecului.

Manualul "Vânzări sofisticate: parametri" conține o listă de parametri de tranzacție.

Partea de masă Este mai profitabilă să se utilizeze decât un set de detalii, deoarece Pot exista o mulțime de ele la tranzacție, iar în alte verificări care nu sunt legate de serviciu, aceste detalii nu vor fi utilizate și vor avea un loc în exces. În plus, o astfel de decizie este universal pentru orice serviciu și nu necesită restructurarea datelor după introducerea unui nou serviciu.

Vânzătorul se efectuează o filă separată (sau o formă tipărită să nu schimbe configurația) în care poate vedea semnul detaliilor tranzacției pentru cec.

Folosind tratamente în limba 1c

Luați în considerare exemplul serviciului condiționat al PAYM pentru configurația "cu amănuntul".

  1. Începem în un element predefinit 1C al directorului nomenclaturii "Paym". În modul 1C: întreprinderile După actualizarea configurației, trebuie să fie atribuită tipului de "serviciu".
  2. În procedura "Adăugați o nomenclatură la fila. Partea "Modulul" Înregistrarea vânzărilor ", numim prelucrarea lucrărilor cu serviciul scris în limba 1c. În cazul unei plăți reușite, scriem și conducem un cec:
Dacă (Nomenclature \u003d cărți de referință. Substitution.paym) și (enumerarea enumeratelor. Vidaraticschkkm. Invidența), apoi prelucrarea plății \u003d funcții. Circulația dublă ("Paym"); Formamplate \u003d procesare. SODORIN (); Rezultat \u003d formamplage. OpenModally (); Dacă rezultatul \u003d este incert, atunci întoarce-te; Încheiat; Acest cont. Pentru a recruta (înregistrarea); Încheiat;
  1. Procesarea ar trebui să tipări comenzile (dacă este necesar), completați o parte din tabelul de vânzări complexe și să pregătiți textul verificării verificării punctelor predefinite de "PayMText".
  2. În procedura "Conduită și imprimare a unui control", modulul de verificare înlocuiește numele bunurilor către stocat în solicitarea de verificare. Textul este înlocuit numai pentru vânzare, doar numele serviciului este tipărit pentru a reveni, ca de obicei.
Inspecificați vizionarea listei. Vidoyeratovschekkm. Factură și eșantionare. Soluționarea cărților de referință SOLKA \u003d Substrat Dacă sugestia de dimensiune a șirului este pe o perioadă nedeterminată. Renance \u003d Socrlp (vânzări deținător de șnur. Încheiat;

O întrebare separată este modul de a asigura finalizarea tranzacției. Acestea. Dacă tranzacția a trecut în serviciu, cum să o faceți nu este pierdută în 1c. Cea mai optimă cale este reconciliată de registre. Dar acesta este un subiect de examinare separată.

Utilizarea programelor integrante de la 1c

Xdto.

Adesea XDto este utilizat în serviciile Web. Dăm cele mai importante sfaturi și rețete cu privire la utilizarea XDTO în 1c.

Xdto în platforma 1c

Pachetele XDTO descrise în filiala de configurare "XDTO" sunt disponibile pentru a crea tipuri și obiecte în fabrica globală XDTO Factory. Nu devine imediat evident.

Unele tipuri din schemă nu au un nume pentru a le obține, trebuie să treceți prin tipurile de ierarhie.

Exemplul descris lista de sisteme care conține structuri XDTO. Pentru a crea structura în sine, a fost necesar să obțineți tipul astfel de aici:

Type \u003d Factory.type ("Urn: My.r.r.: Masterata: Afaceri", "Afaceri"). Proprietăți. Pour ("sistem"). Tip;

Probleme frecvente cu xDto

Diferite formate de schemă XSD

În unele formate, etichetele sunt numite XS:, în unele XSD:, dar 1c înțelege pe deplin ambele formate. Într-o zi a existat o situație pe care XSD a fost normală fără erori importate în 1c, dar nu a creat un singur pachet. Motivul a fost în absența unui atribut tARGETNAMESPACE. Eticheta, respectiv, nu știa 1c, în care pachetul să pună schema, dar nu a dat greșeli.

Serviciu de asistență

Având în vedere că serviciul este o combinație de două sisteme - 1C și externă, erorile pot fi în ambele sisteme, ceea ce reduce fiabilitatea globală a muncii.

Pentru a mai putea înțelege motivele de eșecuri în funcționarea serviciilor, se recomandă utilizarea unui set de măsuri.

Solicitări de exploatare

Link-uri

  • Xdto.
    • O descriere bună xdto http://pro1c.org.ua/index.php?showtopic\u003d214
  • Servicii web interesante gratuite:
    • Aeroflot - informații despre programul de aeronavă
    • Morfer - Declinarea numelor http://www.morher.ru/webservices/morPher.aspx
  • Deschis:
    • Instalarea și utilizarea serviciilor web
      • v8: Cum să modificați fișierul de configurare a Apaches?
      • v8: Continuarea subiectului cu serviciile Web - Nu pot conecta serviciul Web
      • v8: Cu privire la utilizarea serviciilor web - nu pot crea un proxy ...
      • Cartea de cunoștințe: V8: Utilizarea serviciilor web externe în 1c: întreprindere 8;

În zilele noastre, costurile rareori moderne, fără API. Acest lucru este corect atât pentru un site simplu, cât și pentru sistemele distribuite cu încărcare ridicată. Testarea API - este una dintre principalele sarcini din procesul de asigurare a calității. Nu este surprinzător faptul că cererea de testere care pot testa API-ul se ridică de la o zi la alta. În acest curs, veți primi o înțelegere a metodelor, instrumentelor și abordărilor din testul API, va dobândi cunoștințele necesare, ceea ce va fi, fără îndoială, reflectată în valoarea dvs. ca specialist în testarea.

Acest curs va fi util pentru studenții familiarizați cu elementele de bază ale testului software-ului care doresc să crească și să-și sporească abilitățile.

Program de curs:

Lectia 1. Intrare. Protocolul de săpun

  • Pe scurt despre lector;
  • Obiectivul cursului;
  • Ceea ce este API, WS și de ce sunt necesare;
  • Rolul testelor API în procesul de asigurare a calității;
  • Prezentare generală a instrumentelor de testare WS;
  • Tehnici utilizate în testarea WS;
  • Istoria apariției săpunului;
  • Terminologie și concepte principale (XML, XSD, Endpoint, WSDL).

Lecția 2: protocolul de săpun. Arhitectura odihnă.

  • Terminologie și concepte principale (UDDI, XSLT, XPATH, XQuery, Metode HTTP, STATURI HTTP);
  • Structura și componentele principale ale săpunului;
  • Scopul aplicatiei;
  • Caracteristicile muncii;
  • Avantaje și dezavantaje;
  • Caracteristici arhitectura de odihnă;
  • Terminologia și conceptele principale (Wadl, odihnitor, JSON, JSONPATH);
  • Principiile de odihnă;
  • Codul de stare și statutul major;
  • Verbe crud;
  • Avantaje și dezavantaje.

Lecția 3. Cunoașterea cu SOAPI. Lucrați cu proiectul REST

  • Instalarea Java;
  • Instalarea SOAPI;
  • Prezentare generală a elementelor principale ale interfeței;
  • Conectarea unui proiect de formare;
  • Revizuirea metodelor de proiect;
  • Trimiterea unei cereri și analiza răspunsului primit;
  • Studiul serviciilor web disponibile pentru proiecte;
  • Elaborarea unui plan de testare;
  • Scrierea cazurilor de testare;
  • Elemente "Testsuite", "Testcase", "Teststeps".

Lecția 4. Lucrul cu proiectul de odihnă (XML)

  • Blochează "afirmațiile";
  • Lansați teste la diferite niveluri;
  • Element "proprietăți", principalele caracteristici;
  • Lucrați cu proprietăți;
  • Element "Transfer de proprietate";
  • Lucrul cu afirmații.

Lecția 5. Lucrul cu proiectul de odihnă (JSON)

  • Condiții și ramuri;
  • Lucrul cu afirmații;
  • TestRunner, caracteristici de lucru;
  • Rulați TS, TC din linia de comandă;
  • Lucrați cu runner de testare;
  • Lucrați cu scripturi Groovy.

Lecția 6. Lucrați cu scripturi groovy

  • Lucrați cu date statice și dinamice;
  • Noi generăm date de testare;
  • Primim date din "Proprietăți";
  • Înregistrarea și transferarea datelor;
  • Condiții și ramuri;
  • Afirmația scriptului.

Lecția 7. Caracteristici suplimentare

  • Conectarea bibliotecilor externe și a claselor personalizate;
  • Servicii de machete;
  • De ce au nevoie de serviciile de machete;
  • Exemplu de lucru cu serviciul Mock;
  • Dar ce zici de CI?
  • Instalați Jenkins;
  • Pornirea unui proiect pe Jenkins.


Ți-a plăcut articolul? Împărtășește-l