Torna a Webservices

SoapUI

Spread the love

SoapUI è un software per effettuare test di servizi esposti su http (web services).

E’ scaricabile in versione free software (GNU Lesser Public License 2.1) e installabile in varie piattaforme (Win / Mac / Linux/Unix).

Qui di seguito mi sono scritto qualche howto riguardante specifiche operazioni che ho dovuto fare.

Indice

soapUI

SoapUI è un ambiente per test funzionali per SOA (Simple Object Access) e per testare web services. Con la sua semplice interfaccia grafica e le funzionalità di classe enterprise, soapUI permette di creare facilmente e rapidamente ed eseguire test funzionali automatici, regressione e prove di carico. In un unico ambiente di test, soapUI fornisce una copertura completa di test – da SOAP e servizi REST basati su Web, a strati di messaggistica JMS enterprise, database, applicazioni Rich Internet, e molto altro ancora.

Si può usare soapUI per costruire messaggi SOAP da includere nei messaggi HTTP di Mirth. Oppure si può usare per invocare i listener costruiti con Mirth (per testare i webservice).

Come installare SoapUI

Come prima cosa installare un interprete Java: io ho installato la SunJDK e anche OpenJDK. Senza la prima non posso fare funzionare Mirth; senza la seconda non parte soapUI. Poi la cosa più comoda è scaricare il binario da [1]. Si scompatta lo zip e si esegue lo script di installazione.

Poi si lancia.

Come lanciare SoapUI

  marcob@jsbach:~/Scaricati/soapui-4.5.0/bin/soapui.sh [INVIO]

Ottenere un template SOAP dichiarando il WDSL

  • Tasto desto sul progetto (esempio certificati_inps) > Add WDSL
  • Scrivere nel dialog l’URL del servizio
 es: https://servizioweb.sito.it/TrasmissioneCertificati/services/Rettifica
  • soapUI crea un test case, per visualizzare il formato della request:
 certificati > RettificaCertificatoBinding > rettificaCertificato > Request 1
 <soapenv:Envelope
   xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
   xmlns:int="http://...">
  <soapenv:Header/>
  <soapenv:Body>
     <int:InterrogazioneLavoratore>
        <int:pincodeMedico>?</int:pincodeMedico>
        <int:codiceFiscale>?</int:codiceFiscale>
     </int:InterrogazioneLavoratore>
  </soapenv:Body>
 </soapenv:Envelope>

Copia / incolla questo frammento dentro a Mirth (nel VALUE)

 Channels > InterrogaLavoratore > Destinations > Chiama WS > Request Variables
 >  $payload

Ottenere un XML di risposta da una invocazione

RequestTasto destro sopra interrogazioneLavoratore per creare una nuova Request (se serve).

In basso scegliere la Scheda Aut (vedi figura seguente)

Auth

Controlli per autenticarsi sull’endpoint

 

Inserire Username, Password e dominio come in figura. Il servizio che si invocherà è in alto sulla barra https… ecc. Se non è corretto, cliccando sulla freccetta compare in elenco [edit current]: modificare a dovere.

Poi cliccare sul pulsantino verde a sinistra in alto, si ottiene la response:

 <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
   xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soapenv:Header/>
  <soapenv:Body>
     <p600:RicevutaLavoratore xmlns:p600="http://interrogazionelavoratoreresponse.xsd.cert.....it">
        <p600:ricevutaNonOk>
           <p706:errore xmlns:p706="http://tipicert.xsd.cert......it">
              <p706:tipoErrore>111</p706:tipoErrore>
              <p706:sezioneErrata>S111</p706:sezioneErrata>
              <p706:descrizione>Pincode assente o errato</p706:descrizione>
           </p706:errore>
        </p600:ricevutaNonOk>
     </p600:RicevutaLavoratore>
  </soapenv:Body>
 </soapenv:Envelope>

Come creare una nuova TestCase

E’ una funzionalità che aiuta nei test dei webservices. Nel mio caso la cosa è parecchio complicata: il webservice di Mirth non è accessibile direttamente ma è dietro un proxy e protetto da password.

Sopaui_wscall

Creare un nuovo progetto

Come prima cosa creo un nuovo progetto SOAP ConvenzionatiReverseProxy2, in cui l’indirizzo è

  https://servizio.web.it/nomeservizio

username=mirth001, password=password (questi vanno inseriti nella maschera di autenticazione da precompilare)

Dichiaro poi il WSDL immettendo questo indirizzo

 https://servizio.web.it/nomeservizio?wsdl

Se tento di chiamare il web service esso risponde, ma l’url che vedo non è quello del proxy ma quello di Mirth diretto (controprova: se metto Wireshark in ascolto sulla porta ethernet e catturo i pacchetti destinati al proxy non catturo nulla).

Ho bisogno di vedere che succede da locale a proxy!!!

Creare una nuova TestSuite

Allora aggiungo una TestSuite.

SOAP_testSuite

Come si vede, all’inizio è la TestSuite è vuota; una TestSuite è un inseme di casi di test (TestCase):

Aggiungere un nuovo TestCase

In questo caso è un Web TestCase:

SOAP_addWebTestCase

Nel campo Web Address scrivo l’endpoint corrispondente al mio reverse proxy https://servizio.web.it/nomeservizio

Un TestCase è a sua volta strutturato in operazioni semplici (step): all’interno della TestCase aggiungo un nuovo step:

Aggiungere uno step al TestCase

SOAP_newTestStep

In corrispondenza al campo Endpoint ripeto l’indirizzo del proxy:  https://servizio.web.it/nomeservizio

L’ultimo passaggio è la personalizzazione della chiamata dell’end point che

  • per funzionare deve essere fatta in modalità POST e
  • nella cui intestazione deve essere presente il campo SOAPAction con valore “” (stringa vuota); questo scopo si raggiunge editando il servizio come mostrato qui di seguito (nota il Method e l’Header, entrambi nel lato sinistro della schermata):

SOAPParametri

Si noti, nel lato sinistro della figura, la presenza del controllo Headers… che permette di aggiungere la direttiva SOAPAction e, sulla destra, del controllo Authentication… (purtroppo nello screen shot si vede solo A… in ogni caso se si clicca lì compaiono i controlli per immettere username e password)

Lascia un commento

Your email address will not be published.