Linee guida per lo sviluppo dei servizi applicativi in ambiente CARTe

Transcript

1 Linee guida per lo sviluppo dei servizi applicativi in ambiente CARTe Versione /07/2010

2 1 Introduzione Uso del Componente di Integrazione della Porta di Dominio Modalità d'uso trasparente dei Servizi Uso del Servizio IntegrationManager Invocazione di una porta delegata tramite Integration Manager Accesso ai messaggi ricevuti tramite Integration Manager Contenuti delle Risposte Applicative La gestione degli errori nell'interazione tra Servizio Applicativo e Porta Delegata Aspetti di integrazione nei Profili Asincroni Interscambio di Informazioni tra SIL e PdD Integrazione tramite QUERY_STRING Integrazione tramite l uso dell Header SOAP etoscana uso del meccamismo dei Filtri JMS Impostazione delle proprietà da parte del SIL Pubblicatore Proxy CART Mediatori TSB Il linguaggio di configurazione Alcuni Esempi L'esempio delle Comunicazioni Obbligatorie Utilizzo di Synapse per il TSB...31 Allegato A: Interfaccia WSDL del Servizio di IntegrationManager...44 Allegato B : Header SOAP etoscana Domande Frequenti... 71

3 1 Introduzione Nella specifica SPCoop, un dominio è definito come il confine di responsabilità di un ente o soggetto amministrativo e racchiude al suo interno tutte le applicazioni da esso gestite. Il confine applicativo del Dominio è rappresentato dalla Porta di Dominio (PdD), attraverso la quale devono transitare tutte le comunicazioni da e verso il dominio. Le Porte di Dominio si parlano tra di loro scambiandosi richieste e risposte in un formato parte della specifica SPCoop, denominato busta egov. Tuttavia il formato della busta non è parlato nativamente dalle applicazioni, pertanto la Porta di Dominio deve anche occuparsi di convertire le richieste applicative nel formato busta egov. Facendo riferimento a questa problematica, i compiti della Porta di Dominio vengono solitamente classificati in due componenti: il componente di cooperazione, che riguarda la comunicazione tra le Porte di Dominio e quello di integrazione, che riguarda la comunicazione tra i Servizi Applicativi dell Ente e la Porta di Dominio. Il componente di integrazione si differenzia a sua volta in due diversi moduli: la porta delegata e la porta applicativa. In particolare la porta delegata è utilizzata come proxy per l accesso al servizio destinazione, mentre la porta applicativa deve essere in grado di gestire la consegna dei contenuti delle buste egov ricevute al corrispondente servizio applicativo interno al dominio destinazione. Differentemente da quanto avviene per il componente di cooperazione (busta egov), per il componente di integrazione la specifica SPCoop si limita a presentare un esempio di massima di una sua possibile realizzazione. Al fine di uniformare le interfacce del livello applicativo verso l infrastruttura CARTE, in questo documento vengono quindi presentate le interfacce esposte dalle Porte di Dominio verso i Servizi Applicativi. 2 Uso del Componente di Integrazione della Porta di Dominio Le interazioni tra i servizi applicativi e le porte delegate e applicative delle Porte di Dominio che li ospitano devono avvenire tramite richieste SOAP 1.1. I protocolli supportati sono http ed https. Ogni richiesta del Servizio Applicativo deve essere autenticata dalla Porta di Dominio con l'utilizzo di autenticazione basic in caso di http o di https. E altresì possibile utilzzare certificati X.509, in tal proposito si fa presente che : - RT può produrre il certificato digitale utilizzando un contratto di fornitura dei certificati stipulato con una C.A. - CART accetta anche certificati prodotti da terzi o self signed - CART non fornisce i certificati 3/73

4 In generale le interazioni tra i servizi applicativi e la porta di dominio possono avvenire in due modi: 1. modalità trasparente: prevede che il servizio applicativo utilizzi (in caso di porta delegata) o esponga (in caso di porta applicativa) le interfacce applicative native dei servizi, esattamente come registrate negli accordi di servizio; in tal caso la Porta di Dominio agisce come un proxy trasparente con funzionalità di imbustamento e sbustamento egov dei messaggi applicativi; utilizzando questa modalità, gli applicativi potranno continuare ad operare esattamente come se stessero interagendo direttamente con il servizio applicativo dell'altro Ente; 2. uso del Servizio Integration Manager della PdD: prevede di utilizzare le interfacce di un apposito web service di Integrazione, messo a disposizione dalla Porta di Dominio per la spedizione e/o la ricezione di messaggi applicativi da parte dei servizi applicativi del proprio Dominio di Servizi. 2.1 Modalità d'uso trasparente dei Servizi Questa modalità prevede che il servizio applicativo utilizzi (in caso di porta delegata) o esponga (in caso di porta applicativa) le interfacce applicative native dei servizi, così come registrate negli accordi di servizio; in tal caso la Porta di Dominio agisce come un proxy SOAP trasparente con funzionalità di imbustamento e sbustamento egov dei messaggi applicativi; utilizzando questa modalità, gli applicativi continuano ad operare esattamente come se stessero interagendo direttamente con il servizio applicativo dell'altro Ente. L'invocazione della porta delegata in modalità trasparente può essere realizzata tramite gli strumenti del linguaggio di programmazione nativo del servizio applicativo, utilizzando ad esempio stub creati tramite il proprio ambiente di sviluppo Web Services (ad esempio wsdl2java in Axis), facendo riferimento direttamente al WSDL del servizio da utilizzare, così come registrato nell'accordo di servizio. In questo caso la principale modifica rispetto all'invocazione dell'effettivo servizio destinazione sarà la URL utilizzata per l'invocazione http, che dovrà essere quella corrispondente alla porta delegata del servizio esposta dalla PdD. Il codice che segue mostra un esempio, usando Axis 1.4, di invocazione di una porta delegata usando gli stub del servizio. try { HelloWSServiceLocator locator = new HelloWSServiceLocator(); Locator.setHelloWorldEndpointAddress(" HelloWS port = locator.gethelloworld(); String msg = port.sayhello(); } catch (AxisFault e) { 4/73

5 } Come si può notare, è sufficiente settare l endpoint del servizio alla URL della Porta Delegata da indirizzare, senza ulteriori modifiche al codice applicativo. Ovviamente non è obbligatorio utilizzare degli stub per l invocazione del servizio, ma si può utilizzare qualunque altra modalità supportata dal proprio ambiente di lavoro per la programmazione di web services. 2.2 Uso del Servizio IntegrationManager Prevede di utilizzare le interfacce di un apposito web service di Integrazione, messo a disposizione dalla Porta di Dominio per la spedizione e/o la ricezione di messaggi applicativi da parte dei servizi applicativi del proprio Dominio di Servizi. L'interfaccia WSDL completa dell'integration manager è disponibile in allegato A. A titolo descrittivo si mostra di seguito l'interfaccia esposta dal Web Service, espressa in linguaggio java: interface IntegrationManager { SPCoopMessage invocaportadelegata( String portadelegata, SPCoopMessage msg) SPCoopMessage sendrispostaasincronasimmetrica( String portadelegata,spcoopmessage msg) String[] getallmessagesid() String[] getallmessagesidbyservice( String tiposervizio, String servizio, String azione) 5/73

6 String[] getnextmessagesid(int n) String[] getnextmessagesidbyservice( int n, String tiposervizio, String servizio, String azione) SPCoopMessage getmessage(string idegov) SPCoopMessage getmessagebyreference(string riferimentomsg) void deletemessage(string idegov) void deletemessagebyreference(string riferimentomsg) public void deleteallmessages() } L'oggetto di base su cui lavorano le varie operazioni supportate dall IntegrationManager è l SPCoopMessage, che contiene varie informazioni relative al messaggio e un array di byte corrispondente al messaggio SOAP vero e proprio. La struttura della classe SPCoopMessage è mostrata a titolo descrittivo in linguaggio java nel riquadro seguente. public class SPCoopMessage implements java.io.serializable { public void setmessage(byte [] m) public byte[] getmessage() public boolean getimbustamento() public void setimbustamento(boolean imbustamento) public String getidapplicativo() public void setidapplicativo(string applicativo) 6/73

7 public String getservizioapplicativo() public void setservizioapplicativo(string servizioapplicativo) public String getservizioapplicativodestinatario() public void setservizioapplicativodestinatario(string servizioapplicativodestinatario) } public SPCoopHeaderInfo getspcoopheaderinfo() public void setspcoopheaderinfo(spcoopheaderinfo spcoopheaderinfo) Come risulta dalla struttura della classe mostrata nel riquadro precedente, l oggetto SPCoopMessage riferisce un ulteriore oggetto di tipo SPCoopHeaderInfo che raccoglie tutte le informazioni relative all header SPCoop della busta egov accessibili dai servizi applicativi. La struttura della classe SPCoopHeaderInfo è mostrata a titolo descrittivo in linguaggio java nel riquadro seguente. public class SPCoopHeaderInfo implements java.io.serializable { public String gettipomittente() public void settipomittente(string type ) public String getmittente() public void setmittente(string m ) public String gettipodestinatario() public void settipodestinatario(string type ) public String getdestinatario() 7/73

8 public void setdestinatario(string s ) public String getservizio() public void setservizio(string s ) public String gettiposervizio() public void settiposervizio(string type ) public String getazione() public void setazione(string a ) public String getid() public void setid(string id ) public String getriferimentomessaggio() public void setriferimentomessaggio(string rif ) public String getidcollaborazione() public void setidcollaborazione(string idcollaborazione) } Invocazione di una porta delegata tramite Integration Manager Il codice che segue mostra un esempio, in Axis 1.4, di invocazione di una porta delegata usando il servizio di IntegrationManager. IntegrationManagerServiceLocator locator = 8/73

9 new IntegrationManagerServiceLocator(); locator.setintegrationmanagerendpointaddress(imurl); port = locator.getintegrationmanager(username,password); // Costruzione Messaggio SPCoop msg = new SPCoopMessage(); // soapmessagetosend è il messaggio SOAP da spedire // espresso come array di byte msg.setmessage(soapmessagetosend); try { SPCoopMessage msgresponse = port.invocaportadelegata(locationpd,msg); } catch(exception e){ } System.out.println("ClientError: "+e.getmessage()); Accesso ai messaggi ricevuti tramite Integration Manager Il codice che segue mostra un esempio, in axis 1.4, di accesso ai messaggi ricevuti su una porta applicativa usando il servizio di IntegrationManager. IntegrationManagerServiceLocator locator = new IntegrationManagerServiceLocator(); locator.setintegrationmanagerendpointaddress(integrationmanagerurl); 9/73

10 port = locator.getintegrationmanager(username,password); String []ids = port.getallmessagesid(); for (int i=0; i<ids.length; i++ ) { SPCoopMessage msg = port.getmessage(ids[i]); // processa il messaggio ricevuto come byte array... processmessage(msg.getmessage()); } deletemessage(ids[i]); Nell esempio precedente viene prima utilizzata l operazione getallmessagesid per accedere all elenco dei messaggi ricevuti e quindi l operazione di getmessage per prelevare i singoli messaggi. Dopo il processamento di un messaggio, si procede alla sua rimozione. Oltre a questi due metodi di base, il servizio di IntegrationManager fornisce ulteriori interfacce per gestire in vario modo i messaggi in arrivo per un SIL. Nel riquadro successivo vengono elencate le varie interfacce utili per l accesso ai messaggi. String[] getallmessagesid() // restituisce gli identificatori di tutti i messaggi disponibili // in coda per il SIL richiedente String[] getallmessagesidbyservice( String tiposervizio, String servizio, String azione) // restituisce gli identificatori di tutti i messaggi disponibili in // coda per il SIL corrispondente al servizio ed all azione // indicati in input 10/73

11 String[] getnextmessagesid(int n) // restituisce i primi n identificatori di messaggi disponibili // in coda per il SIL String[] getnextmessagesidbyservice( int n, String tiposervizio, String servizio, String azione) // restituisce i primi n identificatori di messaggi disponibili // in coda per il SIL corrispondenti al servizio ed all azione // indicati in input SPCoopMessage getmessage(string idegov) // restituisce il messaggio identificato dall identificatore in input SPCoopMessage getmessagebyreference(string riferimentomsg) // restituisce il messaggio identificato dall identificatore // di riferimentomessaggio in input void deletemessage(string idegov) // cancella il messaggio identificato dall id in input void deletemessagebyreference(string riferimentomsg) // cancella il messaggio identificato dall id di riferimentomessaggio // in input 11/73

12 public void deleteallmessages() // cancella tutti i messaggi in coda per il SIL richiedente 3 Contenuti delle Risposte Applicative Nel caso del profilo Sincrono, le risposte (ricevute dalla PdD nel caso di invocazioni della porta delegata o inviate dalla PdD nel caso di invocazioni dei Servizi Applicativi abbinati alle Porte Applicative), sono direttamente generate dai Servizi Applicativi erogatori e trasparentemente restituiti dalla PdD ai servizi fruitori. La stessa cosa succede per i profili Asincroni Simmetrico e Asimmetrico, che corrispondono concettualmente ad una coppia di interazioni sincrone correlate tra loro. Per questo motivo, l Integration Manager non può essere usato per l accesso ai messaggi ricevuti dai servizi applicativi con profili Sincroni ed Asincroni. Infatti questi messaggi non possono essere tenuti dalla Porta di Dominio in attesa di una successiva richiesta del SIL, ma devono essere immediatamente girati al servizio applicativo per poter ottenere la risposta da girare al richiedente. Nel caso del profilo Oneway, invece, la PdD mittente restituisce la risposta al servizio fruitore immediatamente, senza attendere di ricevere una risposta dal servizio applicativo erogatore del servizio. In questo caso il servizio fruitore riceverà quindi una risposta creata dalla PdD con SOAP body vuoto. 4 La gestione degli errori nell'interazione tra Servizio Applicativo e Porta Delegata In funzione del fatto che si usi la modalità di invocazione trasparente o i servizi dell'integrationmanager per l invocazione di una porta delegata della Porta di Dominio, cambia il modo in cui le condizioni di errore vengono gestite dal servizio applicativo. Nel caso in cui si usino i servizi dell'integrationmanager eventuali condizioni di errore generate dalla Porta di Dominio saranno restituite all'interno di un eccezione gestita dal servizio IntegrationManager, il cui formato è rappresentato di seguito in linguaggio java. public class SPCoopException { public java.lang.string getcodiceeccezione(); public void setcodiceeccezione(java.lang.string codiceeccezione); 12/73

13 public java.lang.string getdescrizioneeccezione(); public void setdescrizioneeccezione(java.lang.string descrizioneeccezione); public java.lang.string getidentificativofunzione(); public void setidentificativofunzione(java.lang.string identificativofunzione); public java.lang.string getidentificativoporta(); public void setidentificativoporta(java.lang.string identificativoporta); public java.lang.string getoraregistrazione(); public void setoraregistrazione(java.lang.string oraregistrazione); public java.lang.string gettipoeccezione(); public void settipoeccezione(java.lang.string tipoeccezione); } Le eventuali eccezioni generate dal Servizio Applicativo originale saranno invece trasportate come SOAPFault all interno del campo messaggio dell oggetto SPCoopMessage. Nel caso in cui si utilizzi la modalità trasparente, sarà invece possibile, in caso di eccezione SOAPFault, testare il campo FaultActor per riconoscere e gestire i casi di errore dovuti all'interazione con la porta di dominio (valore "it.toscana.regione.cart.pdd") da quelli puramente applicativi. Nel frammento di codice seguente vediamo, a titolo di esempio, come gestire questa situazione nel caso specifico del linguaggio java usando Axis 1.4 come web-services engine. try { HelloWSServiceLocator locator = new HelloWSServiceLocator(); 13/73

14 locator.sethelloworldendpointaddress(" HelloWS port = locator.gethelloworld(); String msg = port.sayhello(); } catch (AxisFault e) { if("it.toscana.regione.cart.pdd".equals(e.getfaultactor())){ System.out.println("Ricevuto Messaggio di Errore PdD[" + e.getfaultcode() + "]:"); System.out.println(e.getFaultString()); }else{ System.out.println("Ricevuto SOAPFault applicativo"); System.out.println("Actor: "+e.getfaultactor()); System.out.println("Code: "+e.getfaultcode()); System.out.println("String: "+e.getfaultstring()); } } catch (Exception e) { System.out.println("ClientError: "+e.getmessage()); e.printstacktrace(); } Come evidenziato nell'esempio, il particolare codice di eccezione generato dalla Porta di Dominio potrà essere ottenuto tramite il campo FaultCode del messaggio di Fault, la descrizione dell errore nel campo FaultString. Il messaggio applicativo d errore sarà presente nel campo detail del 14/73

15 messaggio di Fault, ottenibile nel caso dell esempio tramite il metodo getfaultdetails della classe AxisFault. Ecco un esempio di messaggio di errore generato nel caso in invocazione di una porta delegata inesistente: <soapenv:envelope xmlns:soapenv=" xmlns:xsd=" xmlns:xsi=" <soapenv:body> <soapenv:fault> <faultcode>soapenv:openspcoop_org_401</faultcode> <faultstring>la porta delegata invocata non esiste </faultstring> Location[HelloWorl] urlinvocazione[helloworl] <faultactor>openspcoop</faultactor> <detail> <egov_it_ecc:messaggiodierroreapplicativo xmlns:egov_it_ecc=" xmlns:xsd=" xmlns:xsi=" <egov_it_ecc:oraregistrazione> t09:48:27.812</egov_it_ecc:oraregistrazione> <egov_it_ecc:identificativoporta>openspcoopspcoopit</egov_it_ecc:identificativoporta > 15/73

16 <egov_it_ecc:identificativofunzione>ricezionecontenutiapplicativiws</egov_it_ecc:ident ificativofunzione> <egov_it_ecc:eccezione> <egov_it_ecc:eccezioneprocessamento codiceeccezione="openspcoop_org_401" descrizioneeccezione="la porta delegata invocata non esiste location[helloworl] urlinvocazione[helloworl]"/> </egov_it_ecc:eccezione> </egov_it_ecc:messaggiodierroreapplicativo> </detail> </soapenv:fault> </soapenv:body> </soapenv:envelope> In entrambi gli approcci, in caso di errore, la Porta di Dominio restituirà gli stessi codici di errore, elencati nella tabella seguente. FaultCode FaultString CART_500 Porta di Dominio Temporaneamente non Disponibile CART_401 Porta Delegata Inesistente CART_402 Autenticazione Fallita CART_403 Pattern Ricerca Porta Delegata Non Valido CART_404 Autorizzazione Fallita CART_405 Servizio SPCoop abbinato alla Porta Delegata Inesistente CART_406 Nessun Messaggio disponibile per il Servizio Applicativo 16/73

17 CART_407 Messaggio Richiesto Inesistente CART_4XX Generico errore client I servizi applicativi sono tenuti a gestire tutti gli errori generati dalla PdD, trattenendo i messaggi che hanno generato errore per una successiva rispedizione. In particolare, in caso di errore CART_500, il servizio applicativo è tenuto a sospendere temporaneamente per un tempo calcolato in maniera random, la spedizione di messaggi, in modo da favorire il decongestionamento dell infrastruttura. 5 Aspetti di integrazione nei Profili Asincroni I profili di collaborazione Asincroni, sia Simmetrici che Asimmetrici, al contrario degli altri profili previsti in SPCoop (Oneway e Sincrono) richiedono due interazioni, una richiesta di servizio ed una risposta del servizio che viene ritornata tramite una nuova interazione. Le buste egov prodotte sono quindi quattro (due per ogni interazione) e vengono correlate tra di loro attraverso l identificativo egov. Pertanto i servizi applicativi devono necessariamente scambiare con la porta di dominio l informazione relativa all'id egov utilizzato per la correlazione tra la richiesta e la successiva risposta. Nel caso si usi il servizio di IntegrationManager della Porta di Dominio è possibile utilizzare le interfacce di questo servizio per lo scambio dell id egov necessario per la correlazione. Nel caso in cui si utilizzi la modalità trasparente per l invocazione dei servizi Asincroni, sarà invece possibile utilizzare header del trasporto http, dovendo l'interfaccia applicativa rimanere quella originale del servizio applicativo invocato. Il codice che segue mostra un esempio di transazione asincrona asimmetrica tramite IntegrationManager. SPCoopMessage msg1 = new SPCoopMessage(); msg1.setmessage(soapmessagerichiesta); // invio richiesta asincrona e prelievo dell id di correlazione SPCoopMessage msg1response = port.invocaportadelegata( portadelegatarichiesta,msg1); idegovrichiesta = msg1response.getid(); 17/73

18 // Costruzione SPCoopHeaderInfo SPCoopHeaderInfo spcoopheaderinfo = new SPCoopHeaderInfo(); spcoopheaderinfo.setriferimentomessaggio(riferimentomessaggio); msg.setidapplicativo(idcorrelazioneapplicativa);... msg.setservizioapplicativo(nomeservizioapplicativo); // settaggio dell id di correlazione ed invio richiesta stato SPCoopMessage msg2 = new SPCoopMessage(); msg2.setmessage(soapmessagerichiestastato); SPCoopHeaderInfo spcoopheaderinfo2 = new SPCoopHeaderInfo(); spcoopheaderinfo2.setriferimentomessaggio(idegovrichiesta); msg2.setspcoopheaderinfo(spcoopheaderinfo2); SPCoopMessage msg2response = port.invocaportadelegata(portadelegatarichiestastato, msg2); Come evidenziato nell esempio, la correlazione della richiesta con la risposta, avviene prelevando l IDEgov della prima richiesta tramite il metodo getid, e settandolo come riferimentomessaggio della seconda richiesta tramite il metodo setriferimentomessaggio. Nel caso in cui si usi la modalità trasparente, le informazioni di correlazione potranno essere gestite tramite le proprietà SPCoopID ed SPCoopRiferimentoMessaggio, accessibili come mostrato nella successiva sezione Interscambio di Informazioni tra SIL e PdD. Il codice che segue mostra un esempio di utilizzo della modalità trasparente usando gli header del protocollo http come modalità di interscambio delle informazioni tra SIL e PdD. URL url = new URL(UrlPortaDelegataRichiesta); HttpURLConnection httpcon1 = (HttpURLConnection)url.openConnection(); 18/73

19 ... OutputStream out = httpcon1.getoutputstream(); out.write(soapmessagerichiesta); out.close();... String idegov = httpcon1.getheaderfields().get("spcoopid");... url = new URL(UrlPortaDelegataRichiestaStato); HttpURLConnection httpcon2 = (HttpURLConnection)url.openConnection();... httpcon2.setrequestproperty("spcoopriferimentomessaggio", idegov); OutputStream out = httpcon2.getoutputstream(); out.write(soapmessagerichiestastato); out.close();... 6 Interscambio di Informazioni tra SIL e PdD Alcune delle informazioni parte dell header SPCoop della busta egov possono essere scambiate tra il SIL e la PdD al momento dell invocazione di una porta delegata o tra la PdD ed il SIL al momento dell invocazione di una porta applicativa. In particolare le informazioni in questione variano in funzione delle specifiche precipuità degli Accordi di Servizio a cui la busta si riferisce e sono identificate tramite le seguenti keyword: SpCoopID SPCoopTipoMittente SPCoopMittente SPCoopTipoDestinatario SPCoopDestinatario 19/73

20 SPCoopTipoServizio SPCoopServizio SPCoopAzione SPCoopRiferimentoMessaggio SPCoopIdCollaborazione SPCoopIDApplicativo SPCoopServizioApplicativo SPCoopServizioApplicativoDestinatario Nel caso di uso dell IntegrationManager, tali informazioni sono accessibili tramite le interfacce di get/set della classe SPCoopHeaderInfo, già mostrata in precedenza. Nel caso di uso della modalità trasparente, tali informazioni sono invece accessibili tramite tre diverse modalità: 1. come header del trasporto http: in questo caso i nomi degli header saranno uguali alle informazioni sopra elencate; 2. come proprietà della QUERY_STRING della URL http invocata: in questo caso il nome della proprietà saranno uguali alle informazioni sopra elencate; 3. come informazioni interne all header SOAP etoscana, appositamente definito per l interscambio di tali informazioni nel CART; in questo caso le informazioni saranno rappresentate in accordo all xsd dell header etoscana riportato in appendice B. Va notato che la PdD del CART accetta in input e produce in output le informazioni necessarie usando contemporaneamente tutti le 3 modalità appena elencate. E quindi possibile, per il programmatore dei servizi applicativi, usare indifferentemente uno qualunque di tali modalità. Abbiamo già mostrato un esempio d uso dell interscambio di informazioni tra SIL e PdD sia tramite l uso dell Integration Manager che tramite l uso di header http nella modalità trasparente, nella precedente sezione 5 Aspetti di integrazione nei Profili Asincroni. Nel seguito vedremo un analogo esempio di codice, utilizzando le modalità alternative di integrazione tramite QUERY_STRING e tramite Header SOAP etoscana. E' importante evidenziare una nuova funzionalità della PdD associata all'utilizzo dell'attributo SPCoopServizioApplicativoDestinatario dell'header etoscana: infatti mediante l'utilizzo di questo attributo è possibile istruire la Porta di Dominio CART in modo tale che sia possibile indirizzare un messaggio ad uno specifico SIL di destinazione associato ad un determinato Ente erogatore. Questo meccanismo consente di poter gestire invii di messaggi verso un Ente destinatario al quale sono associati, per quel servizio, più SIL erogatori, selezionando un solo SIL destinatario fra quelli possibili: la PdD consegnerà il messaggio solo al SIL indicato escludendo dalla consegna i restanti SIL. Infatti tramite l'uso dell'header etoscana, il mittente ha la possibilità di impostare, mediante i meccanismi esposti nel seguito, l'attributo SPCoopServizioApplicativoDestinatario, per far si che 20/73

21 un determinato messaggio per il quale risulta valorizzato tale attributo, venga consegnato esclusivamente al SIL (se esistente e associato all'ente destinatario) indicato nell'attributo. Se il SIL indicato non figura fra i SIL associati al soggetto erogatore, verrà generato dalla PdD un messaggio di errore CART verso la PdD mittente. In generale se l'attributo non risulta valorizzato, la PdD procede alla consegna a tutti i SIL registrati per quella porta applicativa. 6.1 Integrazione tramite QUERY_STRING URL url = new URL(UrlPortaDelegataRichiesta); HttpURLConnection httpcon1 = (HttpURLConnection)url.openConnection();... OutputStream out = httpcon1.getoutputstream(); out.write(soapmessagerichiesta); out.close();... String idegov = httpcon1.getheaderfields().get("spcoopid");... url = new URL( UrlPortaDelegataRichiestaStato + "?SPCoopRiferimentoMessaggio=" + idegov ); HttpURLConnection httpcon2 = (HttpURLConnection)url.openConnection();... OutputStream out = httpcon2.getoutputstream(); 21/73

22 out.write(soapmessagerichiestastato); out.close();... Nel codice appena mostrato si può notare come il parametro SPCoopRiferimentoMessaggio venga passato aggiungendo un parametro della QUERY_STRING alla URL della porta delegata invocata, anziché usando il setting degli header http. 6.2 Integrazione tramite l uso dell Header SOAP etoscana URL url = new URL(UrlPortaDelegataRichiesta); HttpURLConnection httpcon1 = (HttpURLConnection)url.openConnection();... OutputStream out1 = httpcon1.getoutputstream(); out1.write(soapmessagerichiesta); out1.close();... InputStream responsestream = httpcon1.getinputstream(); Message response = new Message(responseStream); responsestream.close();... SOAPHeaderElement headeretoscana = null; java.util.iterator<?> iter = response.getsoapheader().examineallheaderelements(); while( iter.hasnext() ) { SOAPHeaderElement headerelement = (SOAPHeaderElement) iter.next(); //Controllo Actor 22/73

23 if(headerelement.getactor().equals( " ) { headeretoscana = headerelement; break; } } String idegov = headeretoscana.getattribute("id-egov");... // Preparazione dell'header SOAP etoscana Name name = new PrefixedQName( " "etoscana", "cart"); SOAPHeaderElement header = new org.apache.axis.message.soapheaderelement(name); header.setactor(" header.addnamespacedeclaration("soap_env", " // Settaggio riferimentomessaggio per la correlazione asincrona header.setattribute("spcoopriferimentomessaggio", idegov); 23/73

24 // Aggiunta header al messaggio Soap. Si assume che il Messaggio Axis // da spedire sia disponibile nella variabile axismsgrichiestastato axismsgrichiestastato.getsoapenvelope().getheader().addchildelement(header); URL urlconnection = new URL(...todo...); HttpURLConnection httpconn = (HttpURLConnection) urlconnection.openconnection(); OutputStream out = httpconn.getoutputstream(); axismsgrichiestastato.writeto(out); out.close();... L'header etoscana non è un header obbligatorio per le comunicazioni tra SIL e PdD. Nel caso sia presente in un messaggio SOAP ricevuto dal servizio di Porta Delegata, permette la comunicazione dei valori necessari in fase di integrazione, come idendificativo di correlazione nei profili asincroni, id di collaborazione e id di correlazione applicativa. Di seguito viene mostrato un esempio di codice per inserire all'interno di un header etoscana un id di correlazione applicativa: SOAPEnvelope env = msg.getsoapenvelope(); SOAPHeader hdr = (SOAPHeader) env.getheader(); if(hdr==null) { } hdr = (SOAPHeader) env.addheader(); // Creazione header etoscana Name name = new PrefixedQName(" 24/73