Meniul
AcasăBios

Testarea serviciilor web. Stăpânirea testării SOAP API. Utilizarea serviciilor SOAP externe

Utilizarea instrumentului de validare a serviciilor web pentru WSDL și SOAP

Se pare că odată cu apariția noilor tehnologii și standarde precum XML și HTTP, serviciile Web și-au asigurat locul în panteonul inovației pe internet. Dar cum a apărut această inovație?

Conceptul de bază al serviciilor Web poate fi urmărit încă de la mijlocul anilor 1960 în Statele Unite. În industria transporturilor, de exemplu, în companiile feroviare și maritime, a fost introdus un nou concept de schimb electronic de date între computere, care s-a dezvoltat în continuare în tehnologia EDI (Electronic Data Interchange). Am auzit prima dată despre EDI de la un profesor de la o școală de afaceri în 1980.

În 1996, Institutul Național de Standarde și Tehnologie din SUA a anunțat un standard pentru EDI în Publicațiile Federale privind Standardele de Procesare a Informației (FIPS PUB 161-2). Conform specificației publicate, EDI este un standard pentru schimbul de mesaje strict formatate între computere. Mesajele primite sunt procesate doar de computer, iar aceste mesaje nu sunt, în general, destinate interpretării umane. Exact asta fac serviciile Web, cu excepția faptului că XML, Internetul și World Wide Web nu existau la mijlocul anilor 1960.

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

Ce sunt serviciile web

Un serviciu web este un sistem software conceput pentru a sprijini interacțiunile de la mașină la mașină între resursele de calcul dintr-o rețea și folosind mesaje SOAP (Simple Object Access Protocol) definite de World Wide Web Consortium.

Simple Object Access Protocol (SOAP) este un protocol simplu, extensibil, care schimbă mesaje structurate și tipizate într-un mediu de rețea descentralizat și distribuit. Mesajele SOAP sunt scrise în Extensible Markup Language (XML), un format text simplu și flexibil derivat din Standard Generalized Markup Language (SGML), care a fost dezvoltat de Organizația Internațională pentru Standardizare (ISO 8879:1986).

Web Services Description Language (WSDL) este un limbaj bazat pe XML care descrie interfața serviciilor Web.

Ce se întâmplă când sunt schimbate mesaje SOAP nevalide? Ce s-ar întâmpla dacă un mesaj SOAP eronat ar fi procesat fără avertisment și chiar folosit pentru a genera informații de luare a deciziilor?

În practică, este imposibil să spunem dacă datele dintr-un mesaj SOAP sunt corecte sau incorecte. Cu toate acestea, puteți verifica dacă un mesaj SOAP este corect uitându-vă la definiția interfeței sau WSDL.

În viața reală, problemele de depanare în mesajele SOAP sunt foarte dificile. Dacă există vreo eroare în mesajul SOAP, de la serverul de servicii Web este primit un cod de răspuns HTTP de 500. Serverele de servicii Web nu oferă informații detaliate despre ce parte a mesajului SOAP are o problemă. Este posibil să întâlniți o situație și mai gravă în care răspunsurile SOAP valide sunt primite de la serverul de servicii web fără mesaje de eroare și nici dvs., nici serverele dvs. de servicii web nu puteți înțelege problemele din cererile și răspunsurile dvs. SOAP. De exemplu, ați dorit să solicitați cotații actuale de acțiuni pentru Compania B, dar ați trimis un mesaj SOAP cu etichete scrise incorect către serverul de servicii web. Serverul de servicii web ar putea ignora etichetele incorecte și poate furniza o valoare implicită în mesajul de răspuns SOAP, cum ar fi prețul acțiunilor companiei A. Dacă acest lucru nu este detectat, consecințele pot fi dezastruoase.

Aceste tipuri de probleme pot fi prevenite în mod proactiv prin utilizarea Instrumentului de validare a serviciilor web pentru WSDL și SOAP. Vă permite să validați mesajele SOAP utilizând limbajul de definire a serviciului web (WSDL) înainte de a implementa aplicații care utilizează serviciul web. Programul analizează sintaxa și corectitudinea mesajelor dvs. SOAP cu WSDL și semnalează problemele raportând erorile și numerele de rând în detaliu. Drept urmare, nu mai primiți mesaje enervante HTTP 500. Mesajele dvs. SOAP sunt criptate? Nici o problemă. Programul le va decripta și va verifica pentru dvs. corectitudinea mesajelor SOAP decriptate.

Acest program a fost creat pentru a ajuta personalul de asistență IBM Web Services să rezolve problemele legate de serviciile Web pe IBM® WebSphere Application Server raportate de clienții din întreaga lume. Programul este conceput pentru a verifica corectitudinea mesajelor SOAP. Dacă mesajul SOAP are o semnătură digitală, programul va verifica și asta. Cu Instrumentul de validare a serviciilor web pentru WSDL și SOAP, puteți chiar să trimiteți mesaje SOAP către serverele de servicii web și să primiți mesaje de răspuns SOAP. Programul a fost creat cu scopul de a elimina problemele din timpul funcționării industriale prin utilizarea lui în stadiile incipiente de dezvoltare, precum și pentru a reduce timpul de rezolvare a problemelor care apar în timpul funcționării.

Vom crea un serviciu web foarte simplu. Mai întâi vom crea o aplicație Java™ simplă. După testarea aplicației Java, vom folosi IBM Rational® Application Developer pentru WebSphere® Software pentru a genera un serviciu Web. În continuare vom face câteva modificări serviciului Web generat. În cele din urmă, folosim Instrumentul de validare a serviciilor web pentru WSDL și SOAP pentru a crea, valida, trimite și primi mesaje SOAP.

Puteți crea un serviciu web simplu utilizând IBM Rational Application Developer for WebSphere Software. Serviciile web pot fi create în două moduri:

  1. Dezvoltarea de sus în jos este dezvoltarea în care clasele Java care implementează servicii Web sunt generate din WSDL.
  2. Dezvoltare de jos în sus, în care un serviciu Web este generat dintr-un bean Java sau dintr-un bean Java enterprise.

În exemplul următor, implementăm un serviciu Web folosind metoda de dezvoltare de jos în sus. Mai întâi vom crea o aplicație Java simplă. În continuare, vom genera un bean de serviciu Web Java dintr-o aplicație Java utilizând IBM Rational Application Developer pentru WebSphere Software.

Crearea unei aplicații Java

Mai întâi vom crea o aplicație Java care emite un salut. Dacă nu este specificat niciun nume, aplicația va returna textul „Bună, amice!” Dacă este furnizat un nume, aplicația va returna textul „Bună ziua”, urmat de acel nume. Mai jos este codul pentru aplicația Java DemoWebService inclusă în pachetul demo. Metoda hello() returnează un șir în funcție de nume.

Lista 1. DemoWebService.java
/* * @author: Jinwoo Hwang * Copyright 2010 IBM Corporation */ package demo; clasă publică DemoWebService ( public String hello(Nume șir) ( dacă (nume == null) returnează „Bună, amice!”; altfel returnează „Bună, „ + nume + „!”; ) )

Testarea unei aplicații Java

Este foarte important să testați o aplicație Java înainte de a crea un serviciu Web din ea. Pentru a rula aplicația, puteți scrie o clasă cu o metodă main(). De asemenea, puteți utiliza funcționalitatea Universal Test Client furnizată de IBM Rational Application Developer v7 pentru a testa rapid fără a scrie cod de testare. Pur și simplu selectați Universal Test Client din meniul contextual al clasei Java pentru a lansa Test Client.

  1. În Universal Test Client, extindeți Obiecte > DemoWebService.
  2. Selectați metoda Buna ziua.
  3. Introduceți un șir sau numele dvs. în câmp Valoareși apăsați butonul Invoca.

De asemenea, puteți rula un test cu un parametru nul și puteți vedea ce se întâmplă. Dacă un parametru nul este transmis metodei hello(), șirul „Hello, buddy!” este returnat, așa cum era de așteptat.


Crearea unui serviciu web

Până acum totul merge bine. Să începem să generăm un serviciu Web dintr-o clasă Java folosind metoda de dezvoltare a serviciului Web de jos în sus.

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

  1. Deoarece am creat o clasă Java, selectați Serviciu web Java bean de jos în susîn lista de tipuri de servicii web. Selectați Porniți clientulși apăsați butonul finalizarea. Dacă am avea o clasă EJB, am putea scrie și un EJB (Java Enterprise bean) pentru a genera un serviciu Web.

Dacă totul a mers bine, veți vedea DemoWebServiceDelegate.java generat în Resurse Java lângă DemoWebService.java.


Când vizualizați DemoWebServiceDelegate.java, puteți găsi adnotarea serviciului Web Java @javax.jws.WebService, care specifică targetNamespace, serviceName și portName în clasa DemoWebServiceDelegate. Este creată o instanță a DemoWebService și o altă metodă hello() este creată din metoda DemoWebService hello(). Dacă doriți să aflați mai multe despre adnotările serviciilor Web Java, consultați Cererea de specificații Java (JSR) 181: Metadatele serviciilor Web pentru platforma Java.

Lista 2. DemoWebServiceDelegate.java
/* * @author: Jinwoo Hwang * Copyright 2010 IBM Corporation */ package demo; @javax.jws.WebService(targetNamespace = "http://demo/", serviceName = "DemoWebServiceService", portName = "DemoWebServicePort") clasă publică DemoWebServiceDelegate ( demo.DemoWebService _demoWebService = new demo.DemoWebService(); public String salut( Nume șir) ( return _demoWebService.hello (nume); ) )

Se creează WSDL

În proiectul programului client, puteți observa și că fișierele DemoWebServiceService.wsdl și DemoWebServiceService_schema1.xsd au fost generate. DemoWebServiceService.wsdl conține informații în limbajul de definire a serviciului web care descrie serviciile de rețea pentru aplicația Java creată mai devreme. DemoWebServiceService_schema1.xsd conține o schemă XML care descrie structura tipurilor de date utilizate în mesajele SOAP.


Când vă uitați la fișierul DemoWebServiceService.wsdl, puteți vedea că are un set de elemente de definiții la rădăcină. Elementul de definiții are 6 elemente:

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

Tipuri definește tipurile de date utilizate în schimbul de mesaje. În DemoWebServiceService.wsdl importăm DemoWebServiceService_schema1.xsd în loc să definim tipurile de date din fișierul WSDL.

Mesaj definește mesajele care sunt schimbate. Avem 2 mesaje: „hello” și „helloResponse”. Mesajul de salut are o parte numită „parametri”. Această parte are un element „tns:hello”. Mesajul helloResponse are o parte numită „parametri” care este similară cu hello. Această parte are un element „tns:helloResponse”. Elementele hello și helloResponse sunt definite în fișierul DemoWebServiceService_schema1.xsd. Ne vom uita la ele în scurt timp.

Tip port– operațiuni suportate de puncte finale. Fiecare operație oferă un mesaj de intrare și un mesaj de ieșire. Operația noastră „hello” constă dintr-un mesaj de intrare „tns:hello” și un mesaj de ieșire „tns:helloResponse”. Aceste operațiuni corespund unui schimb cerere-răspuns. WSDL oferă 4 primitive de schimb diferite pentru un punct final:

  • unidirecțional (unidirecțional);
  • cerere-răspuns (cerere-răspuns);
  • solicitare-răspuns (cerere-răspuns);
  • notificare.

Într-un schimb unidirecțional, punctul final primește doar mesajul. Într-un schimb cerere-răspuns, punctul final primește mesajul și trimite un mesaj corespunzător. Într-un schimb cerere-răspuns, un punct final trimite un mesaj și primește un mesaj corespunzător. Într-un schimb de „notificare”, punctul final trimite doar mesajul.

Legare definește detaliile protocolului și specificațiile formatului mesajului pentru operațiuni și mesaje specifice tipului de port. Pentru atributul de stil folosim valoarea documentului. Atributul style oferă 2 stiluri diferite de mesaje: rpc și document. În stilul rpc, mesajele conțin parametri și valori returnate. În stilul documentului, mesajele conțin documente. Atributul transport specifică URI-ul pentru transportul SOAP. Valoarea specificată http://schemas.xmlsoap.org/soap/http înseamnă că specificația SOAP va folosi legarea HTTP. URI-ul pentru antetul HTTP SOAPAction pentru legarea HTTP SOAP este specificat în atributul soapAction. Deoarece se utilizează legarea SOAP HTTP, este necesară valoarea atributului soapAction. Pentru atributul soapAction folosim șirul gol „”. Elementul soap:body definește modul în care părțile mesajului sunt aranjate în elementul body al unui mesaj SOAP. Atributul use oferă 2 opțiuni diferite: literal și codificat. Folosim literal. Aceasta înseamnă că am ales să definim o anumită schemă folosind fie atributul tip, fie elementul. Când utilizați opțiunea codificată, este utilizat un tip abstract cu reguli de codificare.

Serviciu definește setul de porturi de utilizat.

Port definește punctul final de comunicare prin specificarea adresei de rețea pentru legare.

adresa de rețea pentru legare. În cazul nostru, adresa punctului final SOAP este http://localhost:9081/HelloWorldWSProject/DemoWebServiceService.

Lista 3. DemoWebServiceService.wsdl

Creați o schemă

Importăm DemoWebServiceService_schema1.xsd din DemoWebServiceService.wsdl. Să ne uităm la fișierul DemoWebServiceService_schema1.xsd. Este scris în limbajul de definire XML Schema pentru a descrie structura și constrângerile de conținut ale documentelor XML. Avem 2 elemente: salut și helloResponse. Fiecare element are un tip. Tipul hello are un element „arg0” care este un șir. Elementul „arg0” este opțional deoarece valoarea atributului minOccurs din declarația sa este 0. Dacă atributul minOccurs este setat la 1 sau mai mare, trebuie specificat elementul. Același lucru este valabil și pentru elementul „return” din tipul helloResponse.

Lista 4. DemoWebServiceService_schema1.xsd

Noțiuni introductive cu Instrumentul de validare a serviciilor web pentru WSDL și SOAP

Până acum ne-am uitat la WSDL și la schema. Să pornim serverul de servicii Web, astfel încât să putem activa serviciul Web din Instrumentul de validare a serviciilor Web pentru WSDL și SOAP.

Rularea Instrumentului de validare a serviciilor web pentru WSDL și SOAP necesită un timp de execuție Java 6 (sau o versiune ulterioară) și un API de codificare și decodare digitală XML care se conformează specificațiilor „Sintaxă și procesare de criptare XML” a World Wide Web Consortium (http://www. w3.org/TR/xmlenc-core/).

IBM Java 6 oferă o implementare a API-urilor JSR 106: XML Digital Encryption. Dacă aveți IBM Java 6 instalat, atunci totul este gata de funcționare și nu trebuie să instalați nimic altceva.

Dacă mediul dumneavoastră de rulare Java 6, cum ar fi Sun Microsystems™ Java 6, nu are API-uri XML Digital Encryption, trebuie să instalați biblioteci care implementează JSR 106 sau pachetul Apache™ XML Security versiunea 1.4.3, care poate fi descărcat de la http: / /santuario.apache.org/. Pur și simplu descărcați distribuția binară, dezarhivați-o într-un director și spuneți programului de instrumente unde se află acel director folosind opțiunile de linie de comandă -vmargs și -DAXS.

În momentul scrierii acestui articol, Instrumentul de validare a serviciilor web pentru WSDL și SOAP acceptă JSR 106 și Apache XML Security versiunea 1.4.3 pentru criptare și decriptare digitală XML. Dacă doriți să verificați semnăturile digitale în mesajele SOAP, aveți nevoie de biblioteci care implementează API-urile JSR 105: XML Digital Signature. Din fericire, mașinile virtuale Java 6 de la Sun Microsystems și IBM oferă implementări ale JSR 105. Acesta este motivul pentru care Java 6 a fost ales ca cerință minimă pentru mediul de rulare Java. Dacă mediul dvs. Java 6 nu oferă biblioteci care implementează JSR 105, va trebui să le găsiți.

Instrumentul de validare a serviciilor web pentru WSDL și SOAP poate fi descărcat gratuit aici. Instalarea sa este foarte simplă. Dezarhivați pachetul într-un director și rulați wsvt.exe. Dacă mașina virtuală Java implicită nu este un mediu Java 6 care acceptă semnături digitale XML și criptare și decriptare digitale, trebuie să specificați locația Java 6 cu opțiunea -vm, de exemplu:

wsvt –vm c:\IBMjava6\bin\java.exe

Din nou, dacă aveți IBM Java 6, nu trebuie să instalați nimic altceva. Tot ceea ce aveți nevoie este deja inclus în IBM Java 6. Dacă utilizați Java 6 de la Sun Microsystems, trebuie să direcționați programul către locația Apache XML Security pentru a decripta mesajele SOAP criptate.

De exemplu, următoarea comandă va rula un program cu Sun Java 6 și biblioteca Apache XML Security versiunea 1.4.3 situată în directorul C:\xml-security-1_4_3\libs:

wsvt –vm c:\SUNjava6\bin\java.exe –vmargs –DAXS=C:\xml-security-1_4_3\libs

Mai jos este o listă a fișierelor bibliotecii de securitate Apache XML utilizate efectiv de Instrumentul de validare a serviciilor web pentru WSDL și SOAP, deși versiunea de securitate Apache XML 1.4.3 este livrat cu 9 fișiere jar:
commons-logging.jar;
serializer.jar;
xalan.jar;
xmlsec-1.4.3.jar.

Instrumentul de validare a serviciilor web pentru programul WSDL și SOAP MANIFEST.MF conține următoarele informații:
Politica de activare a pachetului: leneş
Bundle-ClassPath: .,
extern:$AXS$/commons-logging.jar,
extern:$AXS$/serializer.jar,
extern:$AXS$/xalan.jar,
extern:$AXS$/xmlsec-1.4.3.jar

Acesta este motivul pentru care a fost necesar să se specifice –vmargs –DAXS=C:\xml-security-1_4_3\libs pentru ca Sun Java 6 să decripteze mesajele SOAP criptate.

Am petrecut destul de mult timp depanând conflictele de încărcare a claselor și incompatibilitățile dintre clasele legate de XML găsite în runtime Sun Java, Apache XML Security și unele plugin-uri Eclipse. Configurarea IBM Java runtime a fost ușoară, deoarece runtime-ul vine cu o implementare JSR 106 și nu necesită Apache XML Security.

Crearea unui proiect

Acum, după configurarea și rularea programului instrument, puteți crea un nou proiect. Un proiect poate conține un fișier WSDL, mai multe fișiere de schemă asociate fișierului WSDL și mesaje SOAP în fișiere XML. Dacă există mai multe fișiere WSDL într-un proiect, doar unul dintre ele este utilizat, iar celelalte sunt ignorate la validarea fișierului XML al mesajului SOAP. Pentru a utiliza un alt fișier WSDL, trebuie să creați un proiect separat. Fiecare mesaj SOAP trebuie să fie conținut într-un fișier cu extensia .xml, altfel nu va fi considerat un mesaj SOAP.

  1. Faceți clic dreapta și selectați Nou > Proiect.

  1. Selectați Proiect V General.

  1. Introduceți „Proiect de testare” în câmp Denumirea proiectuluiși apăsați butonul finalizarea.

Importați WSDL și Schema

Am creat „Proiectul de testare”. Acum puteți importa WSDL și XSD în el.

  1. Selectați proiectul și apoi selectați din meniul contextual Import.

  1. Selectați Sistemul de fișiere V General.

  1. Selectați directorul în care sunt stocate WSDL și XSD.
  2. Selectați 2 fișiere (DemoWebServiceService.wsdl și DemoWebServiceService_schema1.xsd) și faceți clic pe butonul finalizarea.

Prezentare generală WSDL și schema

Acum avem un proiect cu WSDL și XSD. Puteți face dublu clic pe butonul stâng al mouse-ului pe WSDL pentru a vizualiza WSDL în modul Design și Sursă. În modul Design, puteți vizualiza un serviciu Web cu date de intrare și de 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, ele pot fi deschise în editorul XML selectând Deschideți Cu > Editor XMLîn meniul contextual al acestui fișier XSD.


Am deschis DemoWebServiceService_schema1.xsd într-un editor XML.


Crearea unui mesaj SOAP

Deci acum avem WSDL și schema pregătite pentru a valida mesajele SOAP. Să începem să testăm Instrumentul de validare a serviciilor web pentru programul WSDL și SOAP cu un mesaj SOAP. Trebuie să includeți un mesaj SOAP în proiectul dvs. Mesajul SOAP trebuie să fie conținut într-un fișier cu extensia .xml, pentru a putea fi verificată corectitudinea acestuia.

  1. Selectați Nou > XML pentru a crea un mesaj SOAP într-un proiect.

  1. Selectați Proiect de testare pentru folderul părinte al noului mesaj SOAP. Dacă fișierul nu este deja selectat, introduceți „DemoSOAPMessage.xml” în câmp Nume de fișierși apăsați butonul finalizarea.

Programul apelează automat editorul XML cu un nou fișier XML. Nu există nimic în el, cu excepția unei linii cu versiunea și codificarea xml. E bine că avem măcar ceva înainte de a începe să creăm un mesaj SOAP de la zero. Știi cum să compui un mesaj SOAP? Nu vă faceți griji. În secțiunea următoare, vom parcurge pașii pentru a-l crea pas cu pas.


Pentru a crea un mesaj SOAP, puteți activa „hello” al serviciului folosind parametrul „parametri” cu numele meu – „Jinwoo”. Desigur, poți folosi propriul tău nume. Spațiul de nume utilizat este http://demo/. Fiți atenți - este scris ca http://demo/, nu http://demo, acest lucru este important.

Lista 5. HelloWorldSOAPmessage.xml
Jinwoo

Vedeți probleme cu acest mesaj SOAP? Dacă da, nu vă faceți griji. Ne vom ocupa de asta mai târziu.


Trimiterea unui mesaj SOAP

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

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

  1. În fereastra Transmiteți cererea SOAP și primiți răspunsul SOAP, puteți completa Adresa serviciului, SAAPUNActiuneȘi Tipul de conținut. În această aplicație, nu trebuie să specificăm SOAPAction deoarece am folosit șirul gol „” pentru atributul soapAction din secțiunea de legare a fișierului DemoWebServiceService.wsdl.
  2. Introduceți http://localhost:9081/HelloWorldWSProject/DemoWebServiceService în câmp Adresa serviciului, dacă serverul rulează pe un computer local pe portul localhost:9081. În caz contrar, trebuie să introduceți adresa reală la care este disponibil serviciul Web.
  3. Selectați text/html pentru câmp Tipul de conținut.
  4. Faceți clic pe butonul Bine pentru a trimite un mesaj SOAP către server.

Primirea unui mesaj SOAP

Dacă serverul este în funcțiune, ar trebui să primiți un răspuns SOAP. Dacă nu primiți un răspuns, verificați dacă adresa și tipul de conținut sunt corecte.


Validarea unui mesaj SOAP

Grozav! Am acceptat răspunsul SOAP. De asemenea, este salvat în proiect. Dar asteapta. Vedeți că ceva nu este în regulă? Avem „Bună, amice!” în loc de „Bună ziua, Jinwoo!” Ceva n-a mers bine? Nu ai habar?

Din păcate, serverul de servicii web nu ne-a anunțat ce a fost în neregulă. Fără avertismente. O situație în care sunt trimise răspunsuri SOAP imprevizibile și serverul de servicii web habar nu are ce nu merge bine poate fi foarte periculoasă. Chiar și destinatarii răspunsurilor SOAP pot să nu observe probleme în mesajul SOAP în cauză.

Instrumentul de validare a serviciilor web pentru WSDL și SOAP vă ajută să determinați ce nu merge bine.

Lista 6. Răspuns
Buna prietene!
  1. Selectați mesajul de răspuns SOAP și faceți clic pe butonul Valida.

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

Mesaj SOAP nevalid:cvc-complex-type.2.4.a:A fost găsit conținut nevalid, începând cu elementul „parametri”. Se așteaptă unul dintre „(arg0).

Editarea unui mesaj SOAP

  1. Programul se plânge de valoarea „parametrilor”. Schimbați-l în arg0 și salvați.
Lista 7. Mesaj SOAP modificat
Jinwoo
  1. Verificați dacă mesajul de răspuns SOAP modificat este corect. Nu mai apar mesaje de eroare.

  1. Acum suntem gata să trimitem mesajul de răspuns modificat către server. Selectați mesaj SOAP și apoi selectați Transmiteți cererea SOAP și primiți răspunsul SOAP.

  1. În fereastra Transmitere cerere SOAP și primire răspuns SOAP, introduceți http://localhost:9081/HelloWorldWSProject/DemoWebServiceService în Adresa serviciului, dacă serverul rulează pe portul localhost:9081.
  2. Selectați text/html pentru câmp Tipul de conținutși apăsați butonul Bine.

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


Lista 8. Răspuns SOAP
Bună Jinwoo!

Detectare nevalidă a spațiului de nume

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

  1. Schimbați spațiul de nume în http://demo2/ și salvați mesajul.

Listarea 9. Modificarea spațiului de nume
Jinwoo
  1. Apoi puteți trimite o cerere către server.

Veți vedea o IOException: Serverul a returnat codul de răspuns HTTP:500 pentru URI: http://localhost:9081/HelloWorldWSProject/DemoWebServiceService.


Serverul de servicii Web a trimis informații despre excepția IOException în răspuns, dar aceste informații nu sunt suficiente pentru a detecta eroarea. Verificați corectitudinea mesajului folosind instrumentul dacă doriți informații mai detaliate pentru a rezolva problema.


Programul raportează: „Mesaj SOAP invalid:cvc-complex-type.2.4.a:A fost găsit conținut invalid începând cu elementul „ns0:hello”. Se așteaptă unul dintre „(”http://demo/”:hello,”http://demo/”:helloResponse)”.

Acest mesaj indică faptul că valoarea http://demo/ este așteptată. Acesta este, nu codul de răspuns HTTP 500, ceea ce trebuie să știm.


Validarea mesajelor SOAP criptate

Ce se întâmplă dacă mesajele dvs. SOAP sunt criptate? Nicio problemă dacă ai chei și parole. Doar selectați mesajul SOAP și Valida la fel ca pentru orice alt mesaj SOAP obișnuit. Dacă mesajul dvs. SOAP este criptat, veți vedea un prompt similar cu cel prezentat în Figura 35.


La momentul scrierii acestui articol, sunt acceptate 3 tipuri de depozite de chei:

  1. Magazin de chei Java (JKS).
  2. Magazinul de chei de extensie Java Criptography (JCEKS).
  3. Standard de sintaxă pentru schimbul de informații cu caracter personal (Standarde de criptare cu chei publice #12).

Trebuie să furnizați informații despre depozitul de chei: numele fișierului, tipul fișierului și parola. Dacă informațiile sunt corecte, trebuie să selectați o cheie și o parolă. De asemenea, puteți găsi informații despre depozitele dvs. de chei și lista de chei și certificate din depozitul de chei, cum ar fi tipul depozitului de chei, numele furnizorului, versiunea furnizorului, informațiile furnizorului, tipul cheii, data creării, tipul certificatului, algoritmul și formatul.


Dacă toate informațiile sunt corecte, programul va genera un mesaj SOAP decriptat și va verifica corectitudinea acestuia.


În prezent sunt acceptați următorii algoritmi de criptare:

  • Advanced Encryption Standard (AES) în modul Cipher Block Chaining (CBC) cu vector de inițializare (128/192/256 biți).
  • Advanced Encryption Standard (AES) Criptare cheie (128/192/256 biți).
  • Algoritm de criptare triplă a datelor Moduri de operare (triplu-DES) Criptare cheie.
  • Triple Data Encryption Algorithm Modes of Operation (triplu-DES) Criptare cheie în modul Cipher Block Chaining (CBC).
  • Specificații RSA Criptografie Versiunea 1.5.
  • RSA Optimal Asymmetric Encryption Padding (OAEP) este o metodă cu o funcție de generare a măștilor.

Validarea mesajelor SOAP semnate digital

Ce se întâmplă dacă mesajul tău SOAP este semnat digital? Doar selectați mesajul SOAP și apoi selectați Verificarea semnăturii digitale a mesajelor SOAP.


Dacă semnătura digitală este corectă, veți vedea următorul ecran:


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

  • Secure Hash Algorithm 1 (SHA-1)
  • Cod de autentificare a mesajelor hash (HMAC)
  • Algoritmul de semnătură digitală (DSA)
  • Standarde de criptare cu cheie publică (PKCS #1)
  • Algoritm de criptare RSA cu algoritm de hash securizat (SHA-1)
  • Canonical XML Versiunile 1.0 și 1.1
  • Transformări XSL (XSLT) Versiunea 1.0
  • XML Path Language (XPath) Versiunea 1.0
  • Baza 64

Accesarea serviciului US National Weather Bureau folosind un mesaj SOAP

Serviciul web simplu pe care l-am creat și testat funcționează bine. Poate fi folosit acest program într-un mediu „real”? Puteți încerca să lucrați cu un serviciu web real al Biroului Meteorologic al SUA oferit de S.U.A. Administrația Națională Oceanică și Atmosferică (NOAA).

  1. Creați un proiect.

  1. Creați mesajul SOAP XML.


Biroul Național Meteorologic 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 serviciuluiNDFDgenByDay
Punct finalhttp://www.weather.gov/forecasts/xml/SOAP_server/ndfdXMLserver.php
SoapAction (acțiune SOAP)http://www.weather.gov/forecasts/xml/DWMLgen/wsdl/ndfdXML.wsdl#NDFDgenByDay
encodingStyle (stil de codificare)http://schemas.xmlsoap.org/soap/encoding/
Spațiu de numehttp://www.weather.gov/forecasts/xml/DWMLgen/wsdl/ndfdXML.wsdl
latitudine (latitudine)Numar decimal
longitudine (longitudine)Numar decimal
startDate (data de începere)Data
numDays (număr de zile)Întreg
formatLinia

În acest exemplu, dorim să creăm o solicitare SOAP pentru a obține o prognoză săptămânală pentru o zonă cu coordonate (LAT38.9,LON-77.01), începând din 2010-07-23 în format de 24 de ore:

Lista 10. Cerere SOAP
38.99 -77.01 2010-07-23 7 24 de ore

Nu am specificat un spațiu de nume deoarece serviciul a funcționat fără el. Dacă aveți probleme cu spațiul de nume, întrebați-l.


Selectați un mesaj și Transmiteți cererea SOAP și primiți răspunsul SOAPîn Instrumentul de validare a serviciilor web pentru WSDL și SOAP.

Tabelul 2. Cerere de informații
NumeSens
Punct finalhttp://www.weather.gov/forecasts/xml/SOAP_server/ndfdXMLserver.php
SoapAction (acțiune SOAP)http://www.weather.gov/forecasts/xml/DWMLgen/wsdl/ndfdXML.wsdl#NDFDgenByDay
Tipul de conținuttext/xml; set de caractere=utf-8

Acum datele de prognoză au devenit mult mai ușor de citit.


Dacă acest sfat nu vi se pare foarte convenabil, puteți utiliza propria metodă de formatare HTML. Majoritatea serviciilor Web oferă rezultate în format XML, așa că nu va trebui să recurgeți la această tehnică tot timpul.

Concluzie

Am creat, transformat, acceptat și validat mesaje SOAP utilizând Instrumentul de validare a serviciilor web pentru WSDL și SOAP. Acest program vă permite să identificați problemele pe care majoritatea serverelor de servicii web nici măcar nu sunt capabile să le detecteze, ceea ce poate duce la consecințe grave în viața reală. Utilizarea acestui program în etapa de dezvoltare vă permite să reduceți timpul necesar pentru depanarea problemelor în timpul funcționării.

SOAP (Protocol de acces simplu la obiect) este un protocol standardizat pentru transmiterea mesajelor între un client și un server. Este folosit de obicei împreună cu HTTP(S), dar poate funcționa și cu alte protocoale de nivel de aplicație (cum ar fi SMTP și FTP).
Testarea SOAP din punctul de vedere al tehnicilor de testare nu este fundamental diferită de lucrul cu alte API-uri, dar necesită pregătire preliminară (din punct de vedere al teoriei protocolului) și instrumente speciale de testare. În acest articol, aș dori să formulez o mică listă de verificare a cunoștințelor și abilităților necesare, care va fi la fel de utilă atât unui tester SOAP (care de multe ori nu are idee de ce să se apuce după ce a stabilit sarcina), cât și unui manager care este forțat să evalueze cunoștințele testatorilor și să elaboreze planuri de formare.

Baza teoretica

Faptul că SOAP este un protocol are multe implicații pentru testare: trebuie să studiezi protocolul în sine, standardele și protocoalele „primare” pe care se bazează și (după caz) extensiile existente.

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



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

Puteți afla mai multe despre XML la w3schools sau codenet (în rusă). Asigurați-vă că acordați atenție descrierii spațiilor de nume (o metodă de rezolvare a conflictelor atunci când descrieți elemente în XML) - utilizarea lor este necesară în SOAP.

XSD
Când lucrați, este întotdeauna convenabil să aveți o descriere standardizată a posibilelor documente XML și să le verificați pentru completarea corectă. Există o definiție de schemă XML (sau XSD pe scurt) în acest scop. Cele două caracteristici principale ale XSD pentru un tester sunt descrierea tipurilor de date și impunerea de restricții asupra valorilor posibile. De exemplu, elementul din exemplul anterior poate fi opțional și limitat la 255 de caractere folosind XSD:

...







...

Extensii SOAP
În munca dvs., puteți întâlni, de asemenea, diverse „extensii” de SOAP - standarde precum WS-*. Una dintre cele mai comune este WS-Security, care vă permite să lucrați cu criptare și semnături electronice. Adesea, WS-Policy este folosită împreună cu aceasta, cu care puteți gestiona drepturile de utilizare a serviciului dumneavoastră.

Exemplu de utilizare a WS-Security:


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

Toate aceste extensii sunt structuri destul de complexe care nu sunt folosite în fiecare serviciu SOAP; Studiul lor detaliat la etapa inițială de stăpânire a testării SOAP este puțin probabil să fie relevant.

Instrumente

După cum înțelegeți deja, SOAP este o problemă serioasă; pentru a lucra cu el trebuie să cunoașteți teoria și numeroasele standarde. În practică, o astfel de complexitate ar duce la costuri foarte semnificative ale forței de muncă (de exemplu, ar trebui să te uiți de fiecare dată la diagrama într-un caiet și să trimiți cereri cu curl). Prin urmare, au fost create instrumente pentru a face lucrul cu SOAP mai ușor.

Editore XML/XSD
Un tester bun începe testarea în etapa de scriere a documentației, așa că este convenabil să folosiți editori speciali pentru a testa circuitele. Cele mai faimoase două sunt Oxygen (cross-platform) și Altova (doar Windows); amandoi sunt platiti. Acestea sunt programe foarte puternice pe care analiștii le folosesc în mod activ atunci când descriu serviciile.

În practica mea, trei caracteristici ale editorului s-au dovedit a fi utile: vizualizarea XSD, generarea XML bazată pe XSD și validarea XML bazată pe XSD.

1. Vizualizare XSD necesare pentru o reprezentare vizuală a diagramei, permițându-vă să identificați rapid elementele și atributele necesare, precum și restricțiile existente. De exemplu, pentru un CheckTextRequest, elementul text este obligatoriu și toate cele trei atribute sunt opționale (cu atributul opțiuni având o valoare implicită zero).

Vizualizarea este necesară atunci când există multe tipuri și restricții în diagramă. Dacă aveți nevoie doar de acest lucru și nu doriți să plătiți pentru editori speciali, atunci puteți lua în considerare alternative gratuite (de exemplu, JDeveloper).

2. Generare XML bazată pe XSD util atunci când doriți să vedeți un exemplu valid de mesaj. Îl folosesc pentru a experimenta rapid posibilele completări ale mesajelor și pentru a testa nuanțele modului în care funcționează restricțiile.

3. După utilizarea caracteristicii de la punctul 2, este util să se efectueze Validare XML față de XSD– adică verificați corectitudinea mesajului. Împreună, caracteristicile 2 și 3 vă permit să detectați defecte dificile în XSD chiar și atunci când serviciul în sine este în curs de dezvoltare.

Instrument de testare – SoapUI

Testarea SOAP implică aproape întotdeauna utilizarea SoapUI. Puteți citi despre utilizarea acestui instrument în diverse surse (,), dar va fi cel mai eficient să citiți documentația oficială. Identific 8 niveluri condiționate de competență SoapUI:

Nivelul 1 – Pot trimite cereri
Învață să creezi un proiect bazat pe WSDL. SoapUI vă poate genera toate interogările necesare; Tot ce trebuie să faceți este să verificați dacă sunt completate corect și să faceți clic pe butonul „Trimite”. Odată ce ați dezvoltat abilitățile de a crea interogări valide, trebuie să stăpâniți arta de a crea interogări incorecte care cauzează erori.

Nivelul 2 – Pot face suite de testare și cazuri de testare
Începeți să faceți mini-autotestări. Kiturile de testare și cazurile de testare vă permit să creați scripturi de testare API, să pregătiți date pentru solicitări și să verificați automat răspunsul primit pentru a vă asigura că se potrivește cu ceea ce este așteptat. La început, ele pot fi folosite pur și simplu ca colecții de interogări. De exemplu, dacă ați creat un defect și doriți să îl verificați rapid după remedierea acestuia, puteți aloca un kit de testare separat special pentru cererile de defecțiuni.

Nivelul 3 – Pot scrie Aserțiuni
După stăpânirea cazurilor de testare, vă va fi util să învățați cum să le faceți verificabile automat. După aceasta, nu va mai fi nevoie să cauți cu ochii informații despre răspuns: dacă există o verificare automată, cazurile vor fi marcate cu verde (dacă cecul este trecut) sau roșu (dacă nu este trecut). SoapUI oferă un set mare de afirmații posibile, dar cele mai convenabile și simple sunt Conține și Nu Conține. Cu ajutorul lor, puteți verifica prezența unui text specific în răspunsul primit. Aceste verificări acceptă, de asemenea, căutări cu expresii regulate.

Nivelul 4 – utilizați XPath și/sau XQuery în aserțiuni
Pentru cei care sunt puțin familiarizați cu UI care utilizează Selenium, limbajul XPath este un lucru familiar. În linii mari, XPath vă permite să căutați elemente într-un document XML. XQuery este o tehnologie similară care poate folosi XPath intern; acest limbaj este mult mai puternic, seamănă cu SQL. Ambele limbi pot fi folosite în Aserțiuni. Controalele cu ajutorul lor sunt mai precise și mai stabile, astfel încât cazurile dumneavoastră se vor bucura de mai multă încredere.

Nivelul 5 – Pot scrie teste complexe folosind pași speciali

Cazurile de testare pot conține nu doar o cerere, ci și mai multe (de exemplu, când doriți să emulați scenariul standard de utilizator „creare entitate” → „entitate de export”). Pot exista și alți pași speciali între solicitări, de exemplu:

  • Proprietăți și transfer de proprietate (ajută la reutilizarea datelor și transferul acestora între cereri);
  • JDBC Request (utilizat pentru a prelua date din baza de date);
  • Condițional Goto (vă permite să faceți ramuri sau bucle în cazul de testare);
  • Rulați TestCase (ajută să plasați unele interogări tipice în cazuri de testare separate și să le apelați acolo unde este necesar).

Nivelul 6 – folosind scripturi Groovy

SoapUI vă permite să scrieți scripturi Groovy într-o varietate de locuri. Cel mai simplu caz este acela de a genera date în interogarea în sine folosind inserții $(=). Folosesc aceste inserții tot timpul:

  • $(=data noua().format(„aaaa-LL-zz’T’HH:mm:ss”))– pentru a introduce data și ora curentă în formatul necesar;
  • $(=java.util.UUID.randomUUID())– pentru a introduce un GUID aleator format corect.

Scripturile cu drepturi depline pot fi folosite ca pași în cazuri și verificări. La un moment dat, vei descoperi că mai mulți pași speciali de la al cincilea nivel pot fi înlocuiți cu un singur script.

Nivelul 7 – folosind MockServices
SoapUI bazat pe WSDL poate genera obiecte simulate. Un obiect simulat este cea mai simplă simulare a unui serviciu. Cu ajutorul „mock-urilor” puteți începe să scrieți și să depanați cazuri de testare chiar înainte ca serviciul să fie efectiv disponibil pentru testare. Ele pot fi, de asemenea, folosite ca „stubs” pentru servicii temporar indisponibile.

Nivelul 8 – SoapUI Dumnezeu
Știți diferența dintre versiunile plătite și cele gratuite ale SoapUI și utilizați API-ul SoapUI în codul dvs. Folosiți pluginuri și rulați cazuri prin linia de comandă și/sau CI. Cazurile dvs. de testare sunt simple și ușor de întreținut. În general, ai „mâncat câinele” pe acest instrument. Mi-ar plăcea să vorbesc cu cineva care a stăpânit SoapUI la acest nivel. Dacă ești unul, înscrie-te în comentarii!

Testare cu limbaje de programare

Iată un exemplu despre cum arată o solicitare către API-ul YandexSpeller, făcută folosind groovy-wslite:

import wslite.soap.*
client def = nou SOAPClient ("http://speller.yandex.net/services/spellservice?WSDL")
răspuns def = client.send(SOAPAction: "http://speller.yandex.net/services/spellservice/checkText") (
corp(
CheckTextRequest("lang": "ru", "xmlns":"http://speller.yandex.net/services/spellservice") (
text(„eroare”)
}
}
}
afirmă „eroare” == response.CheckTextResponse.SpellResult.error.s.text()
afirmă „1” == [email protected]()

Din câte știu, nu există încă cadre de nivel înalt (cum ar fi Rest-assured) pentru testarea SOAP, dar recent a apărut un instrument interesant - karate. Cu ajutorul acestuia, puteți descrie cazuri de testare a SOAP și REST sub formă de scripturi precum Cucumber / Gherkin. Pentru mulți testeri, apelarea la karate va fi o soluție ideală, deoarece astfel de scenarii, în ceea ce privește complexitatea scrierii și a cazurilor de susținere, se vor situa undeva la mijloc între utilizarea SoapUI și scrierea propriului framework pentru testarea SOAP.

Concluzie

Este puțin probabil că veți dori vreodată să testați SOAP doar pentru dvs. (cum ați putea face cu REST). Acesta este un protocol greu care este utilizat în soluții serioase pentru întreprinderi. Dar greutatea sa este, în același timp, un cadou pentru tester: toate tehnologiile utilizate sunt standardizate și există instrumente de înaltă calitate pentru lucru. Tot ceea ce este necesar de la testator este dorința de a le învăța și de a le folosi.

Să alcătuim aceeași listă de verificare a abilităților necesare pentru un tester. Deci, dacă abia începeți să testați serviciile SOAP, trebuie să știți și să puteți utiliza:

  • WSDL.
  • SĂPUN.
  • Editore XML/XSD (la nivel de vizualizare XSD).
  • SoapUI la nivelul 1.

După cum puteți vedea, accentul principal este pe învățarea standardelor; în SoapUI este suficient doar pentru a putea executa interogări. Pe măsură ce vă scufundați în testarea SOAP, veți întâlni sarcini care vor necesita abilități și cunoștințe mai serioase, dar nu ar trebui să încercați să învățați totul deodată. Consecvența în creșterea nivelului de complexitate a sarcinilor efectuate este mult mai importantă. Urmând această recomandare, într-o zi îți vei da seama că ai devenit un bun specialist în acest domeniu!

În zilele noastre, este rar ca o aplicație modernă să funcționeze fără un API. Acest lucru este valabil atât pentru un site web simplu, cât și pentru sistemele distribuite foarte încărcate. Testarea API este una dintre sarcinile principale în procesul de asigurare a calității. Nu este surprinzător faptul că cererea de testeri care știu să testeze API-urile crește pe zi ce trece. În acest curs, veți dobândi o înțelegere a metodelor, instrumentelor și abordărilor în testarea API și veți dobândi cunoștințele necesare, ceea ce va avea, fără îndoială, un efect pozitiv asupra valorii dvs. de specialist în testare.

Acest curs va fi util pentru studenții familiarizați cu elementele de bază ale testării software-ului care doresc să se dezvolte în continuare și să-și îmbunătățească abilitățile.

Programul cursului:

Lectia 1. Introductiv. Protocolul SOAP

  • Pe scurt despre lector;
  • Obiectivele cursului;
  • Ce este API, WS și de ce sunt necesare;
  • Rolul testării API în procesul de asigurare a calității;
  • Revizuirea instrumentelor de testare WS;
  • Metode utilizate în testarea WS;
  • Istoria SOAP;
  • Terminologie și concepte principale (XML, XSD, Endpoint, WSDL).

Lecția 2: Protocolul SOAP. Arhitectura REST

  • Terminologie și concepte principale (UDDI, XSLT, XPath, XQuery, metode HTTP, stări HTTP);
  • Structura și componentele principale ale SOAP;
  • Scopul aplicatiei;
  • Caracteristicile muncii;
  • Avantaje și dezavantaje;
  • Caracteristici ale arhitecturii REST;
  • Terminologie și concepte principale (WADL, RESTful, JSON, JSONPath);
  • principiile REST;
  • Cod de stare și stări principale;
  • verbe CRUD;
  • Avantaje și dezavantaje.

Lecția 3. Prezentarea SoapUI. Lucrul cu un proiect REST

  • instalare Java;
  • Instalarea SoapUI;
  • Prezentare generală a principalelor elemente ale interfeței;
  • Conectarea unui proiect educațional;
  • Revizuirea metodelor de proiect;
  • Trimiterea unei cereri și analizarea răspunsului primit;
  • Studierea serviciilor web disponibile ale proiectului;
  • Întocmirea unui plan de testare;
  • Scrierea cazurilor de testare;
  • Elementele „TestSuite”, „TestCase”, „TestSteps”.

Lecția 4. Lucrul cu proiectul REST (XML)

  • Blocul „Aserțiuni”;
  • Realizarea de teste la diferite niveluri;
  • Elementul „Proprietăți”, capabilități principale;
  • Lucrul cu proprietăți;
  • Elementul „Transfer proprietate”;
  • Lucrul cu Aserțiuni.

Lecția 5. Lucrul cu proiectul REST (JSON)

  • Condiții și ramuri;
  • Lucrul cu aserțiuni;
  • TestRunner, caracteristici de lucru;
  • Lansați TS, TC din linia de comandă;
  • Lucrul cu Test runner;
  • Lucrul cu scripturi Groovy.

Lecția 6. Lucrul cu scripturi Groovy

  • Lucrul cu date statice și dinamice;
  • Generarea datelor de testare;
  • Obținem date de la „Proprietăți”;
  • Înregistrarea și transferul datelor;
  • Condiții și ramuri;
  • Afirmația scriptului.

Lecția 7. Caracteristici suplimentare

  • Conectarea bibliotecilor externe și claselor personalizate;
  • Servicii simulate;
  • De ce avem nevoie de servicii Mock?
  • Un exemplu de lucru cu un serviciu simulat;
  • Dar CI?
  • Instalați Jenkins;
  • Lansarea unui proiect pe Jenkins.

Buna ziua!

În mai multe articole voi vorbi despre posibilitățile de testare a modului în care funcționează serviciile web 1C folosind SoapUI. De asemenea, voi da exemple de returnare a documentelor în format PDF și fișiere xml complexe din 1C. Unele lucruri sunt similare cu cele de aici, totuși voi analiza exemple mai complexe de lucru cu servicii web. Dar, mai întâi, voi arunca o privire pas cu pas asupra procesului de lansare a serviciilor web și de lucru cu SoapUI pentru a facilita înțelegerea funcționării acestora de la zero.

1. Serviciu web simplu

Mai întâi, să luăm o configurație wireframe fără servicii web și să trecem prin procesul pas cu pas de a le crea.

Să adăugăm un nou serviciu web denumit test1 și să creăm o operațiune hello în el cu un șir de tip returnat. Este mai bine să specificați întotdeauna numele serviciilor și operațiunilor web în latină.

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

Când dați clic pe lupă din câmpul „Nume procedură”, se va deschide modulul serviciului web și puteți implementa funcția hello.

Funcția hello() returnează „șir din serviciul web 1c”; EndFunction

2. Publicarea unui serviciu web.

Acum, pentru ca funcția rezultată să fie disponibilă prin http, trebuie să ne publicăm serviciul pe un server web. Apache 2.2 este potrivit pentru asta. Am citit articole despre cum să configurați lucrul cu IIS și mi s-a părut mult mai complicat. După instalarea și rularea Apache 2.2, trebuie să mergeți la meniul Administrare - Publicare pe un server web. Câmpul director trebuie completat și să conțină directorul de instalare Apache. Amintiți-vă câmpurile „nume” și „adresă” ale serviciului web, acestea ne vor fi utile în pasul următor.

3. Testarea cu SoapUI

Pentru testare, vom crea un utilizator separat WsUser, cu o parolă simplă și îi vom acorda drepturi depline.

După aceea, instalați și lansați SoapUI. Acest program este foarte convenabil pentru testarea serviciilor web; poate primi descrierea acestora și poate face solicitări de postare către servicii.

Accesați meniul Fișier - Proiect nou SOAP, setați numele proiectului hellotest și în câmpul WSDL inițial scrieți următorul link:

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

În ea, partea „test_ws” a fost specificată în etapa anterioară în câmpul „name” și test1.1cws în câmpul „address”.

Faceți clic pe OK și în această etapă va trebui să vă conectați conectându-vă sub utilizatorul de testare WsUser. Se vor crea un proiect și două elemente obligatorii.

Soap12Binding este diferit prin faptul că funcționează conform noii versiuni a standardului SOAP 1.2. Să deschidem elementul Request1 în test1Soap12Binding și să vedem asta:

SoapUI arată ce xml va fi transmis funcției noastre. Mai există o nuanță înainte de a rula testul; în mod implicit, SoapUI va necesita autorizare pentru fiecare element de solicitare individual. Prin urmare, pentru a nu-l seta de fiecare dată, trebuie să faceți clic dreapta pe testSoap12Binding, selectați Afișare vizualizare interfață și în fereastra care se deschide, în fila „Service Endpoint”, setați numele de utilizator și parola pentru serviciile web:

Dacă acest lucru nu se face, atunci pentru fiecare Cerere va trebui să setați autorizarea folosind butonul Auth din panoul de jos.

Acum puteți, în sfârșit, să faceți o cerere către funcția de salut și să vedeți răspunsul:

Super, totul a funcționat!

4. Transmiterea unor parametri simpli unei funcții.

Acum vom face o nouă funcție cu parametri, de exemplu, vom verifica lucrul cu date, vom face funcția getSaleDocNumbersByDate, care va accepta data documentului (factura) și va returna numerele documentului pentru această dată sub formă de șir. . Să adăugăm un parametru de dată la operațiune cu tipul dateTime:

codul este cam asa:

Funcția getSaleDocNumbersByDate(data) // Data începerii = startDay(data); EndDate = endDay(data); selectionDocuments = documents.Consumable.Select(data de inceput, data de terminare); numere=""; în timp ce selectarea Documentelor.Next() ciclu numărul = numere+" №"+selectare Documente. Număr+";"; sfârşitul ciclului; returnarea numărului; EndFunction

Acum, în SoapUI, faceți clic dreapta pe elementul testSoap12Binding și selectați Actualizare definiție. După aceasta, în proiect vor apărea funcția getSaleDocNumbersByDate și o solicitare gata făcută pentru aceasta. Pentru a completa data, trebuie să utilizați formatul „AAAA-LL-DDThh:mm:ss” (puteți să vă uitați la w3schools și vă recomand FOARTE să folosiți acest site pentru a înțelege cum să lucrați cu xml)

Apoi veți primi următoarea cerere și răspuns:

5. Pachete XDTO

Dacă trebuie să transmitem parametri mai complecși la funcții (de exemplu, xml cu mai multe câmpuri) sau să primim xml cu o structură complexă ca răspuns, atunci nu ne putem lipsi de pachetele XDTO.

Lucrul cu XDTO este discutat în detaliu într-o serie de articole. În esență, pachetul definește structura și tipul de câmpuri ale fișierelor xml utilizate.

Mă voi uita la un exemplu de trimitere și primire a unui fișier xml, al cărui tip este definit în pachet

Mă voi uita și la exemple în următoarele articole:

  • transferarea în 1c a unui fișier xml nedescris în pachet, în format base64
  • primirea unui document pdf în format base64 de la 1c și decodificarea acestuia
  • obtinerea din 1C a unui fisier xml cu o structura imbricata de elemente si determinarea numarului acestora

6. Transferați la 1c într-un parametru de fișier xml, al cărui tip este definit în pachet.

Sarcina va fi aceasta: găsiți documentul de factură folosind numărul și data specificate în xml-ul primit și returnați documentul găsit. De asemenea, trebuie returnat în format xml cu numărul, data, contrapartea și codul acesteia și partea tabelară a mărfurilor.

Să creăm un pachet packet1 cu spațiul de nume packet1_ns. Pentru fișierul xml de intrare, vom defini un obiect de tip InDocSaleQuery cu un câmp de număr de tip șir și un câmp de dată de tip dateTime. Pentru fișierul de ieșire, definim mai întâi tipul pentru un rând al părții tabulare a produselor: SaleItem cu câmpurile nume de tip șir, preț suma, cantitate de tip zecimal. Și documentul SaleDoc în sine va fi de tip compus: câmpurile număr, dată, partenerName și câmpul SaleItems, care va avea un tip SaleItem și o cantitate maximă de -1. Acest câmp înseamnă că poate conține o serie de mai multe elemente. Iată cum arată totul în configurator:

Mai întâi voi demonstra codul funcției, apoi voi explica ce se întâmplă.

Cod:

Funcția getSaleDoc(incomingXML)DocNumber = incomingXML.number; DateDoc = incomingXML.date; cerere = cerere nouă; request.Text = "SELECT | ConsumableProducts.Nomenclature.Name ca nume, | ConsumableProducts.Price ca preț, | ConsumableProducts.Quantity ca cantitate, | ConsumableProducts.Amount ca sumă, | ConsumableProducts.Link |FROM | Document.Consumable.Products AS ConsumableProducts |WHERE |ConsumableProducts.Link.Number = &Număr |Și ConsumableProducts.Link.Date = &DataDoc"; request.SetParameter("Număr", număr document); request.SetParameter("DataDoc",DataDoc); fetch = request.Run().Select(); if selection.Quantity()=0 then //return o eroare Document Type = FactoryXDTO.Type("packet1_ns", "SaleDoc"); DocumentBatch = FactoryXDTO.Create(DocumentType); DocumentPack.number = „Nu s-au găsit documente!”; Pachet document de returnare; altfel //creează tipuriDocumentType = FactoryXDTO.Type("packet1_ns", "SaleDoc"); TablePartType = FactoryXDTO.Type("packet1_ns", "SaleItem"); DocumentBatch = FactoryXDTO.Create(DocumentType); //selectați din partea tabulară сч=0; while selection.Next() loop if count=0 then //completeaza detaliile documentului doc = selection.link; DocumentBatch.number = doc.Number; DocumentBatch.date = doc.Date; DocumentPackage.partnerName = string(doc.Party); endif; //completează partea tabelului PackageTablePart = FactoryXDTO.Create(TablePartType); FillPropertyValues(TablePartPackage, selecție); //adăugați-l în documentul Document Package.SaleItems.Add(TablePart Package); sch=sch+1; sfârşitul ciclului; Pachet document de returnare; endif; EndFunction

Există două nuanțe principale aici. În primul rând: deoarece tipul parametrului de intrare a fost specificat incomingXML și acest tip a fost descris în pachet, este imediat posibil să accesați câmpurile acestui xml primit. În al doilea rând: lucrul cu fabrica XDTO. Din acesta s-a obținut tipul parametrilor de ieșire rezultați și a fost creată o Valoare XDTO de acest tip, cu câmpurile necesare completate. De asemenea, este de remarcat faptul că în tipul SaleDoc ar trebui să introduceți un câmp separat pentru eroare, dar în scopuri de testare erorile vor fi înregistrate în câmpul de număr.

Iată cum arată rezultatul acestei interogări în SoapUI:

După cum puteți vedea, totul funcționează, dar mai este loc de îmbunătățire - de exemplu, aș dori să știu câte elemente SaleItems avem în documentul nostru.

Voi vorbi despre acest lucru și despre exemple mai complexe în articolul următor.

Arhiva atașată conține descărcarea bazei de informații și a proiectului SoapUI.

Servicii web în 1C

Acest articol va discuta despre integrarea 1C cu serviciile web existente și despre utilizarea 1C în sine ca serviciu web.

În acest caz, serviciile web vor fi înțelese ca sisteme care funcționează pe Internet și oferă interacțiune cu acestea nu numai prin SOAP (care este tocmai un serviciu web), ci și în alte moduri, inclusiv solicitări HTTP(S) obișnuite.


Riscurile utilizării serviciilor web 1C

Platforma 1C81 a introdus implementarea serviciilor web.

Dar utilizarea lor este plină de riscuri:

  1. 1C8 nu funcționează bine peste HTTPS, nu există instrumente de diagnosticare, așa că uneori este imposibil de înțeles de ce, chiar dacă există un certificat, serviciul nu dorește să funcționeze peste HTTPS. Soluția este implementarea serviciilor web prin CURL sau ridicarea unui tunel HTTPS.
  2. 1C8 aderă la regulile sale pentru validarea schemelor WSDL. Uneori, din motive inexplicabile, schema WSDL nu dorește să fie încărcată în legătura WS. Puteți afla motivul doar pe forumul partenerului de la un specialist. Nu există instrumente de diagnosticare a schemei WSDL, nici măcar nu este indicat motivul sau linia la care este întreruptă încărcarea schemei.

Reguli pentru construirea de servicii de vânzare

Clientului i se eliberează un document de vânzare (chitanță) numai dacă tranzacția de servicii are succes. Altfel, este posibilă o situație când clientul primește un cec și are încredere că a primit un serviciu, dar de fapt nu a primit-o.

Utilizarea serviciilor SOAP externe

Serviciile web SOAP folosesc scheme WSDL și obiecte XDTO pentru a reprezenta datele.

Se încarcă WSDL

Pentru a utiliza un serviciu extern, trebuie să descărcați schema WSDL a acestuia.

Verificarea validității schemei WSDL

Uneori, schema WSDL nu se încarcă în 1C. Puteți verifica validitatea (corectitudinea) schemei folosind orice validator de schemă WSDL, de exemplu http://www.validwsdl.com/.

Trebuie să încărcați schema pe un site http (puteți folosi ftp) și să indicați adresa fișierului în care este încărcată schema:

Caracteristici de încărcare a WSDL în 1C

Particularitatea încărcării WSDL în 1C este că este posibil ca schemele valide să nu fie încărcate. Nu există un validator încorporat, așa că trebuie să căutați o eroare folosind analiza distructivă, reducând succesiv numărul de elemente din circuit. Puteți, de exemplu, să ștergeți descrierea serviciului web.

Procesare pentru testarea unui serviciu web extern care rulează

Pentru a testa un serviciu web extern funcțional, utilizați procesarea „Test ArbitraryWebService.epf” din pachetul pentru acest articol.

Testarea poate fi folosită folosind exemplul serviciului Morpher, care refuză numele (adresa serviciului http://www.morpher.ru/WebServices/Morpher.asmx?WSDL):

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

În timpul procesării, puteți specifica, de asemenea, datele de conectare și parola care sunt necesare pentru a autoriza accesul la serviciul web.

Instrumente standard pentru serviciile de depanare

Pentru depanare, puteți utiliza programul SoapUI, care poate trimite o solicitare arbitrară unui serviciu web și poate primi un răspuns de la acesta.

SOAP și HTTPS

Din păcate, SOAP în 1C se comportă destul de capricios atunci când lucrează prin protocolul HTTPS; practica arată că este imposibil să se realizeze o conexiune HTTPS, deși posibilitatea este declarată în platformă. Lipsa instrumentelor de diagnosticare și depanare pentru a afla motivele pentru care conexiunea nu este stabilită își face taxă. Prin urmare, este convenabil să utilizați SOAP prin CURL.

Mecanismul încorporat pentru utilizarea HTTPS implică faptul că toate certificatele trebuie publicate într-un fișier comun pem în directorul programului 1C.

Folosind 1C ca serviciu

Reguli pentru dezvoltarea unui serviciu bazat pe 1C

Operațiunea Salut

Regula bunei forme este de a crea o operațiune în serviciu care să informeze că serviciul este disponibil. Acest lucru ușurează viața integratorilor; le va fi mai ușor să verifice dacă comunicarea cu serviciul este stabilită.

De exemplu, puteți utiliza operația Hello fără parametri, care pur și simplu returnează valoarea booleană True.

Publicarea unui serviciu web

Procedura este bine descrisă în documentație: file:///C:/Program%20Files/1cv81/AddDoc/RU/V8AddDoc81.htm#_Toc176167634:

Sarcina publicării serviciilor Web se rezumă la plasarea fișierelor de configurare *.1cws ale serviciilor Web în directorul corespunzător al serverului web cu setările corespunzătoare pentru serverul web. Pentru a publica servicii Web, trebuie să executați comanda de meniu „Administrare | Publicarea serviciilor web.”

Ca urmare a executării acestei comenzi, se va deschide fereastra de publicare a serviciilor Web.

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

  • „Servicii web” - lista serviciilor web de configurare;
  • „Publicare” - o listă de servicii web publicate pe serverul web specificat.

Folosind butonul „Conexiune...”, ar trebui să specificați serverul web pe care doriți să publicați serviciile web.

Fereastra de selectare a căii serverului web vă permite să specificați calea în două moduri:

  • pe fila „Fișiere” - această metodă este utilizată atunci când publicarea este efectuată pe același computer pe care este instalat serverul web. Calea este un director local corespunzător paginii de Internet din care va fi apelat serverul Web publicat;
  • pe fila „Site FTP” - această metodă este utilizată atunci când trebuie să publicați un serviciu web pe un computer la distanță. Pentru a publica, trebuie să specificați parametrii conexiunii FTP la computerul de la distanță și directorul în care va fi publicat serviciul Web.

Serviciul Web selectat este publicat folosind butonul „Publicare”.

Pentru a anula publicarea unui serviciu Web, utilizați butonul „Șterge”.

Puteți publica într-un director local sau prin FTP. De asemenea, puteți publica pe un server la distanță printr-o cale UNC dacă serverul la distanță face parte din rețeaua locală.

După publicare, serviciul web este disponibil la adresa „http://localhost/test.1cws” sau „http://xxx.ru/test.1cws”, unde xxx.ru este adresa serverului de la distanță și localhost. este adresa tipică a serverului local.

Autorizare la serviciul web 1C

Pentru a accesa serviciul trebuie să treceți autentificarea.

Problemele de autorizare sunt bine abordate aici: http://www.forum.mista.ru/topic.php?id=341168 și în fișierul de documentație:///c:/Program%20Files/1cv81/AddDoc/RU/V8AddDoc81. htm

De obicei, un serviciu web rulează sub un anumit utilizator (de obicei unul creat special). Puteți „atașa” un utilizator 1C folosind autentificarea Windows utilizatorului Windows IUSR_ (dezactivați autorizarea 1C pentru utilizator). Alternativ, puteți șterge lista de utilizatori 1C, apoi nu este necesară autorizarea.

Dacă sunt necesari mai mulți utilizatori, puteți crea mai multe autentificări pentru serverul web, puteți atribui un utilizator Windows fiecăruia dintre ei și, în consecință, să înregistrați accesul utilizatorilor Windows în 1C.

În proprietățile Utilizator și Parolă ale obiectului WSProxy, nu este folosită autentificarea 1C, ci autentificarea utilizatorului serverului web.

Testarea serviciului web 1C

Pentru a testa 1C ca serviciu web, utilizați procesarea „Test ArbitraryWebService.epf”, așa cum este descris în secțiunea „Testarea unui serviciu web extern care rulează”.

Fișierul 1cws este o descriere WSDL a serviciului web 1C.

Utilizarea serviciilor în retail

În mod obișnuit, serviciile de retail sunt folosite pentru a oferi diverse servicii populației - acceptarea plăților, rambursarea împrumuturilor, transferurile de bani, achiziționarea de software etc.

În acest caz, se generează o chitanță în 1C pentru serviciul furnizat, în care sunt salvați parametrii tranzacției. După care această chitanță este tipărită clientului cu informații detaliate despre serviciul prestat. Este posibil să imprimați o verificare preliminară, astfel încât clientul să confirme datele introduse din cuvintele sale cu semnătura sa.

Serviciul poate fi integrat în diferite moduri într-un program de retail scris în limbajul 1C (UT, Retail și altele):

  1. Procesarea sau codul poate fi scris în limbajul 1C, care realizează toată munca cu serviciul.
  2. Se poate folosi un program care funcționează cu serviciul, iar în 1C transmite doar informații pentru verificări.

Organizarea datelor de serviciu în 1C

Pentru a stoca informații despre o tranzacție într-o chitanță, trebuie să creați o parte tabelară suplimentară „Vânzări complexe” cu detaliile:

  • Nomenclatură - link către nomenclatura cecului.
  • Parametru - link către cartea de referință „Vânzări complexe: Parametri”.
  • Valoare - valoarea parametrului, de tip complex. Reprezentarea șirului trebuie să fie destul de lungă (1024 de caractere) pentru a se potrivi cu textul de verificare.

Directorul „Vânzări complexe: parametri” conține o listă de parametri ai tranzacției.

Este mai profitabil să folosești partea tabulară decât un set de detalii, deoarece o tranzacție poate avea multe dintre ele, iar în alte verificări care nu au legătură cu serviciul, aceste detalii nu vor fi folosite și vor ocupa spațiu suplimentar. În plus, o astfel de soluție este universală pentru orice serviciu și nu necesită restructurare a datelor după implementarea unui nou serviciu.

Vânzătorului i se oferă un marcaj separat (sau un formular tipărit, pentru a nu modifica configurația), în care poate vizualiza plăcuța cu detaliile tranzacției pentru cec.

Utilizarea procesării în limbajul 1C

Să ne uităm la exemplul serviciului condiționat Paym pentru configurația „Retail”.

  1. Să creăm un element predefinit al directorului de nomenclatură „Paym” în 1C. În modul 1C:Enterprise, după actualizarea configurației, trebuie să i se atribuie tipul de produs „Service”.
  2. În procedura „Adăugați element la tabel. parte" din modulul de formular "Înregistrare vânzări", numim procesare a lucrului cu serviciul, scris în limbajul 1C. Dacă plata are succes, înregistrăm și postăm cecul:
Dacă (Nomenclatură = Directoare.Nomenclatură.Plată) ȘI (Tip de tranzacție de transfer. Tipuri de operațiuni Verificați KKM. Retur) Atunci Procesare plăți = Funcții. Dă procesare externă ("Plată"); PaymentForm = PaymentProcessing.GetForm(); Rezultat = PaymentForm.OpenModal(); Dacă rezultat = nedefinit, atunci returnează; endIf; ThisObject.Write(DocumentWriteMode.Post); endIf;
  1. Procesarea trebuie să imprime chitanța preliminară (dacă este necesar), să completeze partea tabelară a vânzărilor complexe și să pregătească textul de tipărire a cecului în atributul „PaymCheckText” predefinit.
  2. În procedura „Postați și tipăriți o chitanță” a modulului de chitanță înlocuim denumirea produsului cu cea salvată în detaliile pentru chitanță. Textul este înlocuit doar pentru vânzări; pentru retururi, pur și simplu este tipărit numele serviciului, ca de obicei.
OtherwiseIf Tip de tranzacție de transfer.Tipuri de operațiuniVerificați KKM.Retur și selecție.NomenclatureLink = Directories.Nomenclature.Paym Apoi //Osipov PaymMaster ComplexSales Line = ComplexSales.Find(Directories.ComplexSalesParameters.PaymReceiptText, "Properties"); Dacă linia complexă de vânzări este nedefinită, atunci Product.Name = abreviat LP(Complex Sales Line. Value); endIf;

O întrebare separată este cum să se asigure finalizarea tranzacției. Acestea. dacă tranzacția a avut loc în serviciu, cum să vă asigurați că nu se pierde în 1C. Cea mai optimă modalitate este reconcilierea registrelor. Dar acesta este un subiect care trebuie luat în considerare separat.

Folosind programe care se integrează cu 1C

XDTO

XDTO este adesea folosit în serviciile web. Iată cele mai importante sfaturi și rețete pentru utilizarea XDTO în 1C.

XDTO în platforma 1C

Pachetele XDTO, descrise în ramura „Obiecte XDTO” a configurației, sunt disponibile pentru crearea de tipuri și obiecte în fabrica globală XDTO Factory. Acest lucru nu este imediat evident.

Unele tipuri din schemă nu au un nume; pentru a le obține, trebuie să parcurgeți ierarhia tipurilor.

Exemplul descrie o listă de sistem care conține structuri XDTO. Pentru a crea structura în sine, a trebuit să obțineți tipul acesteia astfel:

Tip = Factory.Type("urn:my.ru:MasterData:Business", "Business").Properties.Get("System").Type;

Probleme frecvente cu XDTO

Diferite formate de schemă XSD

În unele formate, etichetele se numesc xs:, în unele xsd:, dar 1C înțelege în siguranță ambele formate. Odată a existat o situație în care XSD a fost importat în 1C în mod normal, fără erori, dar nu a creat un singur pachet. Motivul a fost absența unui atribut targetNamspace la etichetă, în consecință, 1C nu știa în ce pachet să plaseze diagrama, dar nu a generat erori.

Asistență de service

Având în vedere că serviciul este o combinație de două sisteme - 1C și extern, pot apărea erori în ambele sisteme, ceea ce reduce fiabilitatea globală a funcționării.

Pentru a facilita înțelegerea cauzelor defecțiunilor serviciului, se recomandă utilizarea unui set de măsuri.

Cereri de înregistrare

Legături

  • XDTO
    • Descriere bună a XDTO http://pro1c.org.ua/index.php?showtopic=214
  • Servicii web interesante gratuite:
    • Aeroflot - informații despre orarele de zbor
    • Morpher - declinarea numelor http://www.morpher.ru/WebServices/Morpher.aspx
  • Dezasamblat:
    • Instalarea și utilizarea serviciilor Web
      • v8: cum se schimbă fișierul de configurare apache?
      • v8: continuarea subiectului cu serviciile web - nu pot conecta serviciul web
      • v8: continui să accesez cu crawlere prin serviciile web - nu pot crea un proxy...
      • Knowledge Book: v8: Utilizarea serviciilor web externe în 1C:Enterprise 8;