Specifiche di invocazione del sistema di monitoraggio e controllo servizi CART

Transcript

1 Regione Toscana Specifiche di invocazione del sistema di monitoraggio e controllo servizi CART Stato del documento Definitiva Versione del documento 1.8 Data 29/05/13 Documento Acronimo del documento Specifiche di invocazione del sistema di monitoraggio e controllo servizi CART TOSCART-TEC-SPEC- INVOCAZIONE-PMC

2 REGISTRAZIONE MODIFICHE AL DOCUMENTO versione PARAGRAFO O PAGINA DESCRIZIONE DELLA VARIAZIONE 1.0 Tutto il documento Versione definitiva 1.1 Tutto il documento Revisione generale 1.2 Codici di errore e notifiche di non accettazione 1.3 Paragrafo campi obbligatori 1.4 Codici di errore e notifiche di non accettazione 1.5 Nuova specifica del wsdl 1.6 Web service monitoraggio per utilizzatori esterni. 1.7 Aggiunta di nuovi codici di non accettazione 1.8 Monitoraggio servizi sincroni Introduzione delle notifiche di non accettazione Introduzione campi obbligatori per l invocazione del servizio pmcnal Esempi di notifiche puntuali / aggregate ed errori infrastrutturali Resi obbligatori i campi dataelaborazione, accordoservizio, servizio, tiposervizio, modalita, stato, componente, proxy Descrizione del web service di monitoraggio per utilizzatori esterni Il proxy applicativo può inviare codici di non accettazione relativi ad errori riscontrati durante la fase di elaborazione del messaggio. Aggiunta specifica relativa alle notifiche di monitoraggio inviate dai proxy applicativi nel caso di servizi sincroni.

3 Indice dei Contenuti 1 - SCOPO INTRODUZIONE INTERFACCIA WS PMCNAL ESEMPI DI UTILIZZO Esempio di notifica N Esempio di notifica N Esempio di notifica N Esempio di notifica N CODICI DI ERRORE E NOTIFICHE DI NON ACCETTAZIONE Esempio di notifica di non accettazione puntuale Esempio di notifica di non accettazione aggregata Esempio di notifica di errore in consegna su erogatore MONITORAGGIO SERVIZI SINCRONI WEB SERVICE MONITORAGGIO PER UTILIZZATORI ESTERNI...18

4 1 - SCOPO Scopo del presente documento è quello di definire l interfaccia per l invocazione del sistema di monitoraggio dei servizi in ambito CART che utilizzano proxy applicativi. 2 - INTRODUZIONE Obiettivo del Sistema di Monitoraggio PMC è quello di consentire di monitorare ciò che si ritenga significativo tenere sotto controllo per il servizio sul quale si voglia attivare tale sistema (ad es. in un servizio il cui compito sia l invio di documenti, si vorrà monitorare l effettiva consegna dei documenti stessi). Il sistema di monitoraggio espone un web service locale al NAL (Ws-PMCNal, di cui definiremo l interfaccia in questo documento) per la ricezione di messaggi di monitoraggio inviati dai proxy. Un modulo applicativo locale al NAL (Agent di monitoraggio) si occuperà di inviare, in modalità asincrona, i messaggi di monitoraggio al servizio centrale. Il servizio centrale di monitoraggio riceverà le notifiche e le memorizzerà nel database di monitoraggio. Sul servizio centrale sarà presente un interfaccia web per le operazioni di reportistica, analisi ed impostazione di regole per l attivazione di meccanismi di alert. Gli attori principali del sistema di monitoraggio sono, come detto, il web service di gestione dei messaggi di monitoraggio locale al NAL (PMCNal), il processo di invio notifiche (Agent), il web service centrale per la memorizzazione delle notifiche (PMCCric), un applicazione web per la reportistica e controllo ed un processo di controllo regole e invio alert. Di seguito un possibile scenario di utilizzo:

5 Il tracciamento della comunicazione fra un SIL mittente ed un SIL destinatario avviene, in uno scenario di tipo asincrono, nel seguente modo: sul NAL mittente il proxy applicativo invocato dal SIL (1) invia al web service di monitoraggio locale Ws PMCNal un messaggio (2), notificando la ricezione di un messaggio applicativo da parte del SIL (Notifica N1). Successivamente il proxy invoca la porta di dominio (3) e, dopo aver ricevuto un ACK positivo di presa in carico, invoca nuovamente il Ws PMCNal notificando l'avvenuta presa in carico (4) (Notifica N2). Sul NAL destinatario avverrà l inverso, ossia il proxy applicativo alla ricezione di un messaggio applicativo dalla porta di dominio (5) invocherà il Ws PMCNal locale notificando la richiesta di servizio applicativo (6) (Notifica N3). Successivamente, il proxy inoltra la richiesta al servizio erogatore locale (7) e, dopo aver ottenuto un ACK positivo di presa in carico, invoca di nuovo il Ws PMCNal notificando il completamento delle operazioni di gestione del messaggio sul CART (8) (Notifica N4) che quindi risulta consegnato. 3 - INTERFACCIA WS PMCNAL Il web service Ws PMCNal è conforme alla seguente definizione (WSDL): <?xml version="1.0" encoding="utf-8"?> <wsdl:definitions targetnamespace=" xmlns:apachesoap=" xmlns:tns=" xmlns:wsdl=" xmlns:wsdlsoap=" xmlns:xsd=" <wsdl:types> <schema targetnamespace=" xmlns=" <include schemalocation="notificationmessage.xsd"/> <include schemalocation="notificationresponse.xsd"/> </schema> </wsdl:types> <wsdl:message name="invianotificarequest"> <wsdl:part name="in0" type="tns:notificationmessage"/> </wsdl:message> <wsdl:message name="invianotificaresponse"> <wsdl:part name="invianotificareturn" type="tns:notificationresponse"/> </wsdl:message> <wsdl:porttype name="pmcnal"> <wsdl:operation name="invianotifica" parameterorder="in0"> <wsdl:input message="tns:invianotificarequest" name="invianotificarequest"/> <wsdl:output message="tns:invianotificaresponse" name="invianotificaresponse"/> </wsdl:operation> </wsdl:porttype> <wsdl:binding name="pmcnalsoapbinding" type="tns:pmcnal"> <wsdlsoap:binding style="rpc" transport=" <wsdl:operation name="invianotifica"> <wsdlsoap:operation soapaction=""/>

6 <wsdl:input name="invianotificarequest"> <wsdlsoap:body namespace=" use="literal"/> </wsdl:input> <wsdl:output name="invianotificaresponse"> <wsdlsoap:body namespace=" use="literal"/> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="pmcnalservice"> <wsdl:port binding="tns:pmcnalsoapbinding" name="pmcnal"> <wsdlsoap:address location=" </wsdl:port> </wsdl:service> </wsdl:definitions> Dove NotificationMessage.xsd è la specifica del messaggio di notifica con cui il proxy invoca il web service WsPMCNal attraverso il metodo invianotifica. NotificationMessage.xsd ha la seguente struttura: <?xml version="1.0"?> <xs:schema targetnamespace=" xmlns=" xmlns:xs=" elementformdefault="qualified"> <xs:complextype name="notificationmessage"> <xs:sequence> <xs:element ref="idcorrelazioneapp" nillable="true" minoccurs="0"/> <xs:element ref="idegov" nillable="true" minoccurs="0"/> <xs:element ref="mittente" nillable="true" minoccurs="0"/> <xs:element ref="tipomittente" nillable="true" minoccurs="0"/> <xs:element ref="destinatario" nillable="true" minoccurs="0"/> <xs:element ref="tipodestinatario" nillable="true" minoccurs="0"/> <xs:element ref="dataelaborazione"/> <xs:element ref="numerorfc" nillable="true" minoccurs="0"/> <xs:element ref="accordoservizio"/> <xs:element ref="servizio"/> <xs:element ref="tiposervizio"/> <xs:element ref="azione" nillable="true" minoccurs="0"/> <xs:element ref="modalita"/> <xs:element ref="stato"/> <xs:element ref="errore" nillable="true" minoccurs="0"/> <xs:element ref="messaggiaggregati" nillable="true" minoccurs="0"/> <xs:element ref="componente"/> <xs:element ref="proxy"/> <xs:element ref="idproxy" nillable="true" minoccurs="0"/> <xs:element ref="nal" nillable="true" minoccurs="0"/> <xs:element ref="note" nillable="true" minoccurs="0"/> </xs:sequence> </xs:complextype> <xs:element name="idcorrelazioneapp" type="xs:string">

7 Identificativo di correlazione applicativa <xs:element name="idegov" type="xs:string"> Identificativo della busta egov <xs:element name="mittente" type="xs:string"> Riferimenti del mittente del messaggio <xs:element name="tipomittente" type="soggtype"> Tipo mittente <xs:element name="destinatario" type="xs:string"> Riferimenti del destinatario del messaggio <xs:element name="tipodestinatario" type="soggtype"> Tipo destinatario <xs:element name="dataelaborazione" type="xs:datetime"> Data di elaborazione del messaggio nel formato (yyyy-mm-ddthh:mm:ss) <xs:element name="numerorfc" type="xs:string"> Numero di RFC

8 <xs:element name="accordoservizio" type="xs:string"> Nome dell'accordo di servizio <xs:element name="servizio" type="xs:string"> Identificativo del servizio applicativo <xs:element name="tiposervizio" type="servicetype"> Tipo servizio <xs:element name="azione" type="xs:string"> Identificativo dell'azione associata al servizio <xs:element name="stato" type="xs:int"> stato del messaggio 0 = OK -102 Errore di validazione del messaggio (associato solo alla prima notifica); -103 Errore di anonimizzazione anagrafe locale (associato solo alla prima notifica); -104 Errore di anonimizzazione anagrafe centrale (associato solo alla prima notifica); -300 Errore generico proxy applicativo; -400 Errore invocazione PdD mittente (associato solo alla seconda notifica); -500 Errore generico in consegna su erogatore (associato solo all'ultima notifica). <xs:element name="messaggiaggregati" type="xs:int"> numero di messaggi che sono risultati in errore in caso di notifica di non accettazione dal SIL fruitore

9 <xs:element name="errore" type="xs:string"> Descrizione estesa dell'errore di elaborazione del messaggio <xs:element name="modalita" type="modtype"> Modalita' che il componente effettua sul messaggio I= Invio R=ricezione Da utilizzare insieme al componente per identificare in quale punto dell'infrastruttura si trova il messaggio applicativo. Si veda descrizione del componente. <xs:element name="componente" type="comptype"> Definizione della tipologia del componente che interagisce con il proxy (CART,SIL) Da utilizzare insieme alla modalita' per specificare in quale punto dell'infrastruttura si trova il messaggio applicativo. Di seguito le possibili combinazioni [modalita,componente]: [R,SIL] = Ricezione da SIL (prima notifica) [I,CART] = Invio alla PDD - CART (seconda notifica) [R,CART] = Ricezione da PDD - CART (terza notifica) [I,SIL] = Invio a SIL (quarta notifica) <xs:element name="proxy" type="xs:string"> nome del proxy <xs:element name="idproxy" type="xs:string"> <xs:element name="nal" type="xs:string"> identifica il nal su cui si trova il proxy <xs:element name="note" type="xs:string">

10 annotazione generica <xs:simpletype name="servicetype"> <xs:restriction base="xs:string"> <xs:enumeration value="spc"/> <xs:enumeration value="aoo"/> <xs:enumeration value="test"/> <xs:enumeration value="uddi"/> </xs:restriction> </xs:simpletype> <xs:simpletype name="comptype"> <xs:restriction base="xs:string"> <xs:enumeration value="sil"/> <xs:enumeration value="cart"/> </xs:restriction> </xs:simpletype> <xs:simpletype name="soggtype"> <xs:restriction base="xs:string"> <xs:enumeration value="spc"/> <xs:enumeration value="aoo"/> <xs:enumeration value="test"/> <xs:enumeration value="uddi"/> </xs:restriction> </xs:simpletype> <xs:simpletype name="modtype"> <xs:restriction base="xs:string"> <xs:enumeration value="i"/> <xs:enumeration value="r"/> </xs:restriction> </xs:simpletype> </xs:schema> IMPORTANTE: Affinché il sistema riesca a collegare le 4 notifiche generate nel percorso del messaggio dal SIL fruitore al SIL erogatore e quindi riesca a calcolare tempi e modalità di invio/ricezione del messaggio, è necessario che nel tag idcorrelazioneapp esista un ugual valore (non nullo) in tutte e quattro le notifiche. Il servizio Ws PMCNal risponde con un xml definito dallo schema NotificationResponse.xsd La definizione di NotificationResponse.xsd è la seguente: <?xml version="1.0"?> <xs:schema targetnamespace=" xmlns=" xmlns:xs=" elementformdefault="qualified"> <xs:complextype name="notificationresponse"> <xs:sequence> <xs:element ref="codice" minoccurs="1"/> <xs:element ref="description" minoccurs="0"/>

11 <xs:element ref="esito" minoccurs="1"/> </xs:sequence> </xs:complextype> <xs:element name="codice" type="xs:int"> codice di ritorno 0: ok -101: errore <xs:element name="description" type="xs:string"> descrizione errore <xs:element name="esito" type="xs:boolean"> esito invio notifica: true/false </xs:schema> 4 - ESEMPI DI UTILIZZO Come detto NotificationMessage.xsd definisce il messaggio di notifica con cui il proxy invoca il web service WsPMCNal attraverso il metodo invianotifica. Un esempio di codice per l invocazione del web service è la seguente: public void testpmcnalinvianotifica() throws Exception { it.toscana.regione.cart.pmcnal.pmcnalsoapbindingstub binding; try { binding = (it.toscana.regione.cart.pmcnal.pmcnalsoapbindingstub) new it.toscana.regione.cart.pmcnal.pmcnalservicelocator().getpmcnal(); } catch (javax.xml.rpc.serviceexception jre) { throw new Exception("JAX-RPC ServiceException caught: " + jre); } // Test operation it.toscana.regione.cart.pmcnal.notificationresponse value = null; it.toscana.regione.cart.pmcnal.notificationmessage notificationmessage =

12 } new it.toscana.regione.cart.pmcnal.notificationmessage(); //setting notificationmessage properties //notificationmessage.setidegov( ) value = binding.invianotifica(notificationmessage); //validate results. 4.1 ESEMPIO DI NOTIFICA N1 Un esempio di documento conforme allo schema NotificationMessage.xsd è il seguente: <?xml version="1.0" encoding="utf-8"?> <pmc:monitoraggioproxy xmlns:pmc=" <pmc:idcorrelazioneapp>1000</pmc:idcorrelazioneapp> <pmc:idegov></pmc:idegov> <pmc:mittente>asl11empoli</pmc:mittente> <pmc:tipomittente>spc</pmc:tipomittente> <pmc:destinatario>asl3pistoia</pmc:destinatario> <pmc:tipodestinatario>spc</pmc:tipodestinatario> <pmc:dataelaborazione> t13:10:12.681z</pmc:dataelaborazione> <pmc:numerorfc>98</pmc:numerorfc> <pmc:accordoservizio>notificaeventoclinico</pmc:accordoservizio> <pmc:servizio>notificaeventoclinico</pmc:servizio> <pmc:tiposervizio>spc</pmc:tiposervizio> <pmc:azione></pmc:azione> <pmc:modalita>r</pmc:modalita> <pmc:stato>0</pmc:stato> <pmc:errore></pmc:errore> <pmc:componente>sil</pmc:componente> <pmc:proxy>proxy-asl11empoli</pmc:proxy> <pmc:idproxy></pmc:idproxy> <pmc:nal>nal-asl11empoli</pmc:nal> <pmc:note></pmc:note> </pmc:monitoraggioproxy> Nel caso dell esempio, si tratta di una notifica con cui il proxy Proxy-ASL11empoli che si trova sul nal NAL-ASL11empoli notifica l avvenuta ricezione di un messaggio dal SIL mittente ASL11empoli al SIL destinatario ASL3pistoia riguardante il servizio NotificaEventoClinico.

13 4.2 ESEMPIO DI NOTIFICA N2 Quando il proxy invoca la porta di dominio del CART e riceve un ack può invocare nuovamente il web service WsPMCNal notificando l avvenuta presa in carico da parte della PDD utilizzando il seguente messaggio: <?xml version="1.0" encoding="utf-8"?> <pmc:monitoraggioproxy xmlns:pmc=" <pmc:idcorrelazioneapp>1000</pmc:idcorrelazioneapp> <pmc:idegov>asl8staging_asl8stagingspcoopit_ _ _12:38</pmc:idegov> <pmc:mittente>asl11empoli</pmc:mittente> <pmc:tipomittente>spc</pmc:tipomittente> <pmc:destinatario>asl3pistoia</pmc:destinatario> <pmc:tipodestinatario>spc</pmc:tipodestinatario> <pmc:dataelaborazione> t13:11:12.158z</pmc:dataelaborazione> <pmc:numerorfc>98</pmc:numerorfc> <pmc:accordoservizio>notificaeventoclinico</pmc:accordoservizio> <pmc:servizio>notificaeventoclinico</pmc:servizio> <pmc:tiposervizio>spc</pmc:tiposervizio> <pmc:azione></pmc:azione> <pmc:modalita>i</pmc:modalita> <pmc:stato>0</pmc:stato> <pmc:errore></pmc:errore> <pmc:componente>cart</pmc:componente> <pmc:proxy>proxy-asl11empoli</pmc:proxy> <pmc:idproxy></pmc:idproxy> <pmc:nal>nal-asl11empoli</pmc:nal> <pmc:note></pmc:note> </pmc:monitoraggioproxy> 4.3 ESEMPIO DI NOTIFICA N3 Sul nal destinatario NAL-ASL3pistoia, il proxy Proxy-ASL3pistoia, una volta ricevuto il messaggio dalla PDD invocherà il WsPMCNal utilizzando il seguente messaggio: <?xml version="1.0" encoding="utf-8"?> <pmc:monitoraggioproxy xmlns:pmc=" <pmc:idcorrelazioneapp>1000</pmc:idcorrelazioneapp> <pmc:idegov>asl8staging_asl8stagingspcoopit_ _ _12:38</pmc:idegov> <pmc:mittente>asl11empoli</pmc:mittente> <pmc:tipomittente>spc</pmc:tipomittente> <pmc:destinatario>asl3pistoia</pmc:destinatario> <pmc:tipodestinatario>spc</pmc:tipodestinatario> <pmc:dataelaborazione> t13:12:12.681z</pmc:dataelaborazione> <pmc:numerorfc>98</pmc:numerorfc> <pmc:accordoservizio>notificaeventoclinico</pmc:accordoservizio> <pmc:servizio>notificaeventoclinico</pmc:servizio> <pmc:tiposervizio>spc</pmc:tiposervizio> <pmc:azione></pmc:azione> <pmc:modalita>r</pmc:modalita> <pmc:stato>0</pmc:stato>

14 <pmc:errore></pmc:errore> <pmc:componente>cart</pmc:componente> <pmc:proxy>proxy-asl3pistoia</pmc:proxy> <pmc:idproxy></pmc:idproxy> <pmc:nal>nal- ASL3pistoia</pmc:nal> <pmc:note></pmc:note> </pmc:monitoraggioproxy> 4.4 ESEMPIO DI NOTIFICA N4 Il proxy Proxy-ASL3pistoia ricevuto l ack dal SIL ASL3pistoia invierà a WsPMCNal il seguente messaggio di notifica: <?xml version="1.0" encoding="utf-8"?> <pmc:monitoraggioproxy xmlns:pmc=" <pmc:idcorrelazioneapp>1000</pmc:idcorrelazioneapp> <pmc:idegov>asl8staging_asl8stagingspcoopit_ _ _12:38</pmc:idegov> <pmc:mittente>asl11empoli</pmc:mittente> <pmc:tipomittente>spc</pmc:tipomittente> <pmc:destinatario>asl3pistoia</pmc:destinatario> <pmc:tipodestinatario>spc</pmc:tipodestinatario> <pmc:dataelaborazione> t13:12:25.681z</pmc:dataelaborazione> <pmc:numerorfc>98</pmc:numerorfc> <pmc:accordoservizio>notificaeventoclinico</pmc:accordoservizio> <pmc:servizio>notificaeventoclinico</pmc:servizio> <pmc:tiposervizio>spc</pmc:tiposervizio> <pmc:azione></pmc:azione> <pmc:modalita>i</pmc:modalita> <pmc:stato>0</pmc:stato> <pmc:errore></pmc:errore> <pmc:componente>sil</pmc:componente> <pmc:proxy>proxy-asl3pistoia</pmc:proxy> <pmc:idproxy></pmc:idproxy> <pmc:nal>nal- ASL3pistoia</pmc:nal> <pmc:note></pmc:note> </pmc:monitoraggioproxy> Un esempio di risposta conforme allo schema NotificationResponse.xsd e' la seguente: <?xml version="1.0" encoding="utf-8"?> <pmc:notificationresponse xmlns:pmc=" <pmc:codice>0</pmc:codice> <pmc:description>ok</pmc:description> <pmc:esito>true</pmc:esito> </pmc:notificationresponse> </xs:schema>

15 5 - CODICI DI ERRORE E NOTIFICHE DI NON ACCETTAZIONE I proxy, alla ricezione di un messaggio, hanno la possibilità di notificare al sistema di monitoraggio situazioni di errore, tipicamente errori di validazione e/o anonimizzazione (proxy fruitore) oppure errori in fase di consegna al SIL erogatore (proxy erogatore), impostando un opportuno codice di non accettazione relativo alla tipologia di errore riscontrata durante l'elaborazione del messaggio. Attualmente sono disponibili i seguenti codici di non accettazione: -102 Errore di validazione del messaggio (associato solo alla prima notifica); -103 Errore di anonimizzazione anagrafe locale (associato solo alla prima notifica); -104 Errore di anonimizzazione anagrafe centrale (associato solo alla prima notifica); -300 Errore generico proxy applicativo; -400 Errore invocazione PdD mittente (associato solo alla seconda notifica); -500 Errore generico in consegna su erogatore (associato solo all'ultima notifica). Per ognuno di questi codici è possibile specializzare nel tag errore il tipo di anomalia riscontrata. Le notifiche possono essere puntuali o aggregate. Nel caso di notifiche di non accettazione aggregate, oltre a quanto indicato precedentemente, il proxy deve impostare il tag messaggi Aggregati nel quale inserisce il numero di messaggi per i quali si è riscontrato un errore. L'utilizzo della notifica aggregata, quindi, può essere visto nell'ottica di minimizzare il numero di notifiche relative a messaggi applicativi non validi (quindi nel caso di codici -10X). Ogni altro codice di errore non compreso nella lista sopra descritta verrà gestito come codice non riconosciuto. IMPORTANTE: Le notifiche di non accettazione relative ai codici -10X non saranno prese in considerazione per la generazione di mail di allarme ma solo a fini di reportistica. 5.1 ESEMPIO DI NOTIFICA DI NON ACCETTAZIONE PUNTUALE Di seguito viene mostrato un esempio di notifica di non accettazione puntuale: <?xml version="1.0" encoding="utf-8"?> <pmc:monitoraggioproxy xmlns:pmc=" <pmc:idcorrelazioneapp>1000</pmc:idcorrelazioneapp> <pmc:idegov></pmc:idegov> <pmc:mittente>asl11empoli</pmc:mittente> <pmc:tipomittente>spc</pmc:tipomittente> <pmc:destinatario>asl3pistoia</pmc:destinatario> <pmc:tipodestinatario>spc</pmc:tipodestinatario> <pmc:dataelaborazione> t13:10:12.681z</pmc:dataelaborazione> <pmc:numerorfc>98</pmc:numerorfc> <pmc:accordoservizio>notificaeventoclinico</pmc:accordoservizio> <pmc:servizio>notificaeventoclinico</pmc:servizio> <pmc:tiposervizio>spc</pmc:tiposervizio>

16 <pmc:azione></pmc:azione> <pmc:modalita>r</pmc:modalita> <pmc:stato>-102</pmc:stato> <pmc:messaggiaggregati></pmc:messaggiaggregati> <pmc:errore>errore di validazione del messaggio applicativo</pmc:errore> <pmc:componente>sil</pmc:componente> <pmc:proxy>proxy-asl11empoli</pmc:proxy> <pmc:idproxy></pmc:idproxy> <pmc:nal>nal-asl11empoli</pmc:nal> <pmc:note></pmc:note> </pmc:monitoraggioproxy> La notifica sopra descritta indica al sistema di monitoraggio l'avvenuta ricezione (da parte del proxy fruitore) di un messaggio applicativo che però è stato scartato (e quindi non inviato sull'infrastruttura CART) poiché non ha superato i controlli di validazione. 5.2 ESEMPIO DI NOTIFICA DI NON ACCETTAZIONE AGGREGATA Di seguito viene mostrato un esempio di notifica di non accettazione aggregata: <?xml version="1.0" encoding="utf-8"?> <pmc:monitoraggioproxy xmlns:pmc=" <pmc:idcorrelazioneapp>1000</pmc:idcorrelazioneapp> <pmc:idegov></pmc:idegov> <pmc:mittente>asl11empoli</pmc:mittente> <pmc:tipomittente>spc</pmc:tipomittente> <pmc:destinatario>asl3pistoia</pmc:destinatario> <pmc:tipodestinatario>spc</pmc:tipodestinatario> <pmc:dataelaborazione> t13:10:12.681z</pmc:dataelaborazione> <pmc:numerorfc>98</pmc:numerorfc> <pmc:accordoservizio>notificaeventoclinico</pmc:accordoservizio> <pmc:servizio>notificaeventoclinico</pmc:servizio> <pmc:tiposervizio>spc</pmc:tiposervizio> <pmc:azione></pmc:azione> <pmc:modalita>r</pmc:modalita> <pmc:stato>-102</pmc:stato> <pmc:messaggiaggregati>20</pmc:messaggiaggregati> <pmc:errore>errore di validazione del messaggio applicativo</pmc:errore> <pmc:componente>sil</pmc:componente> <pmc:proxy>proxy-asl11empoli</pmc:proxy> <pmc:idproxy></pmc:idproxy> <pmc:nal>nal-asl11empoli</pmc:nal> <pmc:note></pmc:note> </pmc:monitoraggioproxy>

17 La notifica sopra descritta indica al sistema di monitoraggio l'avvenuta ricezione (da parte del proxy fruitore) di 20 messaggi applicativi scartati (e quindi non inviati sull'infrastruttura CART) poiché non hanno superato i controlli di validazione. In questo caso, i 20 messaggi applicativi che non hanno superato la validazione sono stati aggregati in un' unica notifica di non accettazione (invece di inviare 20 notifiche puntuali di non accettazione). 5.3 ESEMPIO DI NOTIFICA DI ERRORE IN CONSEGNA SU EROGATORE Nel caso in cui il proxy applicativo erogatore voglia notificare una situazione di errore relativa alla consegna di un messaggio sul SIL erogatore, dovrà inserire nel tag stato il valore -500 e nel tag errore una descrizione dell anomalia riscontrata come mostrato nell'esempio seguente: <?xml version="1.0" encoding="utf-8"?> <pmc:monitoraggioproxy xmlns:pmc=" <pmc:idcorrelazioneapp>1000</pmc:idcorrelazioneapp> <pmc:idegov></pmc:idegov> <pmc:mittente>asl11empoli</pmc:mittente> <pmc:tipomittente>spc</pmc:tipomittente> <pmc:destinatario>asl3pistoia</pmc:destinatario> <pmc:tipodestinatario>spc</pmc:tipodestinatario> <pmc:dataelaborazione> t13:10:12.681z</pmc:dataelaborazione> <pmc:numerorfc>98</pmc:numerorfc> <pmc:accordoservizio>notificaeventoclinico</pmc:accordoservizio> <pmc:servizio>notificaeventoclinico</pmc:servizio> <pmc:tiposervizio>spc</pmc:tiposervizio> <pmc:azione></pmc:azione> <pmc:modalita>i</pmc:modalita> <pmc:stato>-500</pmc:stato> <pmc:messaggiaggregati></pmc:messaggiaggregati> <pmc:errore>errore : Servizio applicativo erogatore non disponibile</pmc:errore> <pmc:componente>sil</pmc:componente> <pmc:proxy>proxy-asl11empoli</pmc:proxy> <pmc:idproxy></pmc:idproxy> <pmc:nal>nal-asl11empoli</pmc:nal> <pmc:note></pmc:note> </pmc:monitoraggioproxy> 6 - MONITORAGGIO SERVIZI SINCRONI Come descritto nell'introduzione di questo documento, il flusso di invio delle notifiche di monitoraggio al sistema PMC, nel caso di scenari di tipo asincrono, avviene nel seguente modo: Proxy fruitore: invia la notifica N1 alla ricezione di un messaggio applicativo da parte del SIL mittente;

18 invia la notifica N2 dopo aver ricevuto l'ack di presa in carico da parte della PdD mittente. Proxy erogatore: invia la notifica N3 alla ricezione di un messaggio applicativo da parte della PdD destinataria; invia la notifica N4 dopo aver invocato correttamente il SIL erogatore. Questa scelta discende dall esigenza di identificare e monitorare i messaggi non consegnati sui servizi asincroni per i quali sono previsti i meccanismi di riconsegna dell'infrastruttura CART. Nel caso di servizi di tipo sincrono, invece, non è prevista la riconsegna dal momento che, l'eventuale errore in fase di consegna, viene restituito direttamente al client che può, quindi, inviare nuovamente un messaggio. Per poter monitorare il tempo necessario affinché il fruitore riceva il messaggio di risposta da parte del soggetto erogatore, è necessario che la notifica N4, solo nel caso di servizi sincroni, venga generata dal proxy fruitore alla ricezione della risposta applicativa dell'erogatore e non più dal proxy erogatore come avviene normalmente per i servizi asincroni. Il flusso di invio delle notifiche di monitoraggio al sistema PMC, nel caso di scenari di tipo sincrono, quindi, viene modificato nel seguente modo: Proxy fruitore: invia la notifica N1 alla ricezione di un messaggio applicativo da parte del SIL mittente; invia la notifica N2 in fase di invocazione della PdD mittente. Proxy erogatore: invia la notifica N3 alla ricezione di un messaggio applicativo da parte della PdD destinataria; Proxy fruitore: invia la notifica N4 dopo aver restituito il messaggio di risposta al SIL fruitore. 7 - WEB SERVICE MONITORAGGIO PER UTILIZZATORI ESTERNI Esiste un servizio rivolto ad utilizzatori esterni ed implementato mediante web service per consentire di ottenere informazioni di monitoraggio. In questo modo sarà possibile ottenere informazioni di monitoraggio sui servizi. Ad esempio un servizio applicativo potrebbe ottenere informazioni di monitoraggio che consentano di monitorare il proprio servizio. Il web service riceve in input i seguenti parametri di ricerca: numero di RFC (obbligatorio) nome accordo di servizio (obbligatorio) tipo e nome del servizio (obbligatorio) data inizio ricerca (obbligatorio) data fine ricerca (obbligatorio) tipo e nome del soggetto fruitore tipo e nome del soggetto erogatore numero di elementi per pagina numero di pagina

19 Il ws restituisce in output per ogni data il numero di messaggi presi in carico e consegnati relativamente al servizio di un certo mittente verso un certo destinatario paginando i risultati ottenuti. Per motivi di sicurezza, è stato previsto un meccanismo di basic authentication. Il WS restituisce il numero di elementi trovati, il numero di pagina, il numero di righe per pagina e una lista di oggetti con le seguenti informazioni: Data Tipo fruitore Nome Fruitore Tipo erogatore Nome Erogatore Numero RFC Nome Accordo Tipo Servizio Servizio Numero messaggi in carico Numero messaggi consegnati Il web service è conforme alla seguente definizione (WSDL): <?xml version="1.0" encoding="utf-8"?> <wsdl:definitions targetnamespace=" xmlns:apachesoap=" xmlns:impl=" xmlns:intf=" xmlns:wsdl=" xmlns:wsdlsoap=" xmlns:xsd=" <wsdl:types> <schema elementformdefault="qualified" targetnamespace=" xmlns=" <complextype name="monitorsilrequest"> <sequence> <element name="datafine" nillable="true" type="xsd:string"/> <element name="datainizio" nillable="true" type="xsd:string"/> <element name="erogatore" nillable="true" type="xsd:string"/> <element name="fruitore" nillable="true" type="xsd:string"/> <element name="nomeaccordo" nillable="true" type="xsd:string"/> <element name="numerorfc" nillable="true" type="xsd:int"/> <element name="page" nillable="true" type="xsd:int"/> <element name="rowperpage" nillable="true" type="xsd:int"/> <element name="servizio" nillable="true" type="xsd:string"/> <element name="tipoerogatore" nillable="true" type="xsd:string"/> <element name="tipofruitore" nillable="true" type="xsd:string"/> <element name="tiposervizio" nillable="true" type="xsd:string"/> </sequence> </complextype> <element name="request" type="impl:monitorsilrequest"/> <complextype name="monitorsilvalue"> <sequence> <element name="data" nillable="true" type="xsd:string"/> <element name="erogatore" nillable="true" type="xsd:string"/> <element name="fruitore" nillable="true" type="xsd:string"/> <element name="nomeaccordo" nillable="true" type="xsd:string"/>

20 <element name="numeromsgconsegnati" nillable="true" type="xsd:int"/> <element name="numeromsgincarico" nillable="true" type="xsd:int"/> <element name="numerorfc" nillable="true" type="xsd:int"/> <element name="servizio" nillable="true" type="xsd:string"/> <element name="tipoerogatore" nillable="true" type="xsd:string"/> <element name="tipofruitore" nillable="true" type="xsd:string"/> <element name="tiposervizio" nillable="true" type="xsd:string"/> </sequence> </complextype> <complextype name="arrayofmonitorsilvalue"> <sequence> <element maxoccurs="unbounded" minoccurs="0" name="item" type="impl:monitorsilvalue"/> </sequence> </complextype> <complextype name="monitorsilresponse"> <sequence> <element name="monitorlist" nillable="true" type="impl:arrayofmonitorsilvalue"/> <element name="page" nillable="true" type="xsd:int"/> <element name="rowperpage" nillable="true" type="xsd:int"/> <element name="total" nillable="true" type="xsd:int"/> </sequence> </complextype> <element name="getmonitoraggioserviziapplicativireturn" type="impl:monitorsilresponse"/> </schema> </wsdl:types> <wsdl:message name="getmonitoraggioserviziapplicativirequest"> <wsdl:part element="impl:request" name="request"/> </wsdl:message> <wsdl:message name="getmonitoraggioserviziapplicativiresponse"> <wsdl:part element="impl:getmonitoraggioserviziapplicativireturn" name="getmonitoraggioserviziapplicativireturn"/> </wsdl:message> <wsdl:porttype name="monitorsilservice"> <wsdl:operation name="getmonitoraggioserviziapplicativi" parameterorder="request"> <wsdl:input message="impl:getmonitoraggioserviziapplicativirequest" name="getmonitoraggioserviziapplicativirequest"/> <wsdl:output message="impl:getmonitoraggioserviziapplicativiresponse" name="getmonitoraggioserviziapplicativiresponse"/> </wsdl:operation> </wsdl:porttype> <wsdl:binding name="monitorsilservicesoapbinding" type="impl:monitorsilservice"> <wsdlsoap:binding style="document" transport=" <wsdl:operation name="getmonitoraggioserviziapplicativi"> <wsdlsoap:operation soapaction=""/> <wsdl:input name="getmonitoraggioserviziapplicativirequest"> <wsdlsoap:body use="literal"/> </wsdl:input> <wsdl:output name="getmonitoraggioserviziapplicativiresponse"> <wsdlsoap:body use="literal"/> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="monitorsilservice"> <wsdl:port binding="impl:monitorsilservicesoapbinding" name="monitorsilservice"> <wsdlsoap:address location=" </wsdl:port>

21 </wsdl:service> </wsdl:definitions>