Specifiche di invocazione del sistema di monitoraggio e controllo servizi CART



Documenti analoghi
ZTL Firenze Inserimento Automatico

PROGETTO TESSERA SANITARIA SERVIZI DI COMUNICAZIONE ATTIVAZIONE E REVOCA DELLE TS-CNS

PROGETTO TESSERA SANITARIA

PROGETTO TESSERA SANITARIA

RILEVAZIONE PRESENZE SPECIFICHE TECNICHE COLLOQUIO

INF-1: Specifiche Tecniche di Interfaccia

PROGETTO TESSERA SANITARIA WSDL E SCHEMI XSD PER L UTILIZZO DEI SERVIZI WEB- SERVICE

WEB SERVICES SERVIZI PER RICEZIONE ED ELABORAZIONE MESSAGGI AMBIENTE REALE

Progetto SIRPE De-materializzazione delle prescrizioni. Servizi personalizzati della CIL

A2A Specifiche Web Services

WEB SERVICES SERVIZI PER RICEZIONE ED ELABORAZIONE MESSAGGI AMBIENTE PROVA

QUALIFICAZIONE DELLA PORTA DI DOMINIO

1. Accordo di servizio Richiesta Indirizzi PEC CAD Art6 [concessionario del servizio di posta certificata al cittadino]

PROGETTO TESSERA SANITARIA WEB SERVICE CMS ATTIVAZIONE E REVOCA TS-CNS IN INTEROPERABILITA FRA CARD MANAGEMENT SYSTEM

Manuale d uso Servizi di accoglienza prescrizioni regionali

SERVICE BROWSER. Versione 1.0

Consolidamento e sviluppo CART

EDIZIONE FEBBRAIO 2012

SDK-CART. Versione 1.1

Manuale Utente. STARTUP Servizio Dettaglio Vetrina Release 1.0. Versione: 1.0 Data Versione: 7 / 11 / Descr. modifiche: Motivazioni :

Il Gestore Eventi di OpenSPCoop i. Il Gestore Eventi di OpenSPCoop

Tutorial di configurazione e programmazione di OpenSPCoop. Tutorial di configurazione e programmazione di OpenSPCoop

Web Service per il controllo e la trasmissione telematica delle pratiche di Comunicazione Unica

Manuale Utente Delibera 99/11 li/

Manuale gestione Porta di Dominio OpenSPCoop 1.1

Specifiche tecniche per il controllo e la trasmissione telematica delle pratiche di Comunicazione Unica

Specifiche struttura del file dei rilievi Descrizione e XML Schema

Specifiche tecniche di trasmissione per i Comuni

PAG. 1 DI LUGLIO 2010 PROGETTO TESSERA SANITARIA WEB SERVICES PER LA TRASMISSIONE DEI CERTIFICATI DI MALATTIA ALL INPS VER 1.

Progetto interregionale ICAR Interoperabilità e Cooperazione Applicativa tra le Regioni. <Task AP3>

Sistema DE.PRO.EM. Istruzioni per il caricamento delle informazioni relative ai prodotti tramite file XML. Versione 1.0

Tutorial di configurazione e programmazione di OpenSPCoop. Tutorial di configurazione e programmazione di OpenSPCoop

OSSERVATORIO RIFIUTI SOVRAREGIONALE ~ ~ ~ IMPORTAZIONE AUTOMATICA DELLE IMFORMAZIONI SUI RIFIUTI RITIRATI E PRODOTTI DAGLI IMPIANTI.

Autorità Nazionale Anticorruzione e per la valutazione e la trasparenza delle amministrazioni pubbliche

Indagini sul personale dipendente Applicazione web per la raccolta dei dati Guida tecnica

PROGETTO TESSERA SANITARIA

Light CRM. Documento Tecnico. Descrizione delle funzionalità del servizio

PROGETTO TESSERA SANITARIA SERVIZI DI COMUNICAZIONE ATTIVAZIONE E REVOCA DELLE TS-CNS

Allegato 2 XML-Schema per l alimentazione del ReGIndE TipiBaseReGIndE.xsd

Web Service SOAP e WSDL. Tito Flagella tito@link.it Lorenzo Nardi nardi80@gmail.com

MANUALE UTENTE Profilo Azienda Partecipata. APPLICATIVO CAFWeb

WebCare. Specifiche Tecniche recupero dati per tariffazione. Redatto da: STUDIOFARMA 28 MAGGIO 2009 Verificato da: Approvato da:

Portale regionale della Salute. Servizi di prenotazione prestazione e pagamento ticket.

Allegato) all art.4 punto 5 Informatizzazione del Magazzino

CP Customer Portal. Sistema di gestione ticket unificato

ISTRUZIONI PER IL SERVIZIO SPCOOP - RICEZIONE

Hub-PA Versione Manuale utente

FATTURA ELETTRONICA {

ISTRUZIONI PER IL SERVIZIO SDICOOP - TRASMISSIONE. Pag. 1 di 18 VERSIONE 1.1

Guida Utente della PddConsole. Guida Utente della PddConsole

Manuale d uso. Fatturazione elettronica attiva

Manuale Gestione di OpenSPCoop 1.4 i. Manuale Gestione di OpenSPCoop 1.4

Client e Server comunicano tramite il protocollo SOAP.

MODALITÀ DI QUALIFICAZIONE DELLA PORTA DI DOMINIO

Integrazione del progetto CART regione Toscana nel software di CCE K2

Versione 1. (marzo 2010)

Manuale Utente. Gestione Richieste supporto Data Warehouse. Della Ragioneria Generale dello Stato. Versione 1.0. Roma, Ottobre 2015

Progetto NoiPA per la gestione giuridicoeconomica del personale delle Aziende e degli Enti del Servizio Sanitario della Regione Lazio

Manuale Utente TebeniService 5.0.0

ScanDoc presentazione ed uso

Gestione ex Inpdap SISTEMA INFORMATIVO DOMANDE DI PRESTAZIONI PENSIONISTICHE E NON PENSIONISTICHE

Sistema Accordo Pagamenti

Manuale Amministratore Legalmail Enterprise. Manuale ad uso degli Amministratori del Servizio Legalmail Enterprise

Sgravi Contrattazione di Secondo Livello: dettaglio dei Controlli, dei Formati e dei messaggi di errore.

Protocollo Informatico (D.p.r. 445/2000)

Manuale Utente. Gestione Richieste supporto BDAP. Versione 1.0

MODALITÀ DI QUALIFICAZIONE DELLA PORTA DI DOMINIO

TRASMISSIONE REPORTISTICA MENSILE. WEB SERVICE Descrizione procedura

MANUALE UTENTE Fiscali Free

Gestione Turni. Introduzione

Guida all accesso al portale e ai servizi self service

Manuale Tecnico. per l utente del servizio di Posta Elettronica Certificata v.4.4.

Effettuare gli audit interni

IMPLEMENTAZIONE PER CHIAMATA AL MIP2FE

Manuale di riferimento per l utilizzo delle funzioni di monitoraggio dei documenti del Nodo telematico di Interscambio (NoTI-ER)

Definizione delle interfacce di colloquio fra le componenti

Scheda di collaudo Integrazione NoTIER

INPS Direzione Centrale Sistemi Informativi e Tecnologici. Area CRM & Contact Center

POSTA ELETTRONICA CERTIFICATA

PROGETTO DOMINIO ESTERNO WEB SERVICES PER RICEZIONE ED ELABORAZIONE MESSAGGI

ACCESSO AL SISTEMA HELIOS...

SOMMARIO... 3 INTRODUZIONE...

Servizi Integrati Circolarità. Anagrafica INA-SAIA

Sostituto abilitato Entratel con più sedi: ricezione diretta e incarico ad intermediario abilitato

Sistema Banca dati e Repertorio dei dispositivi medici Notifiche multiple di DM simili

Amministrazione Trasparente

SIRTEL. Sistema Informativo per la Rendicontazione Telematica degli Enti Locali. Schema di funzionamento del processo per l Ente Locale

Protocollo Informatico (D.p.r. 445/2000)

Gestione Accoglienza Flussi

ISTRUZIONI PER LA GESTIONE BUDGET

Il presente documento illustrerà il. funzionamento del modulo di comunicazione. tra Utenti della Distribuzione e Società di

LOG VIEWER. Versione 1.0

SMS API. Documentazione Tecnica YouSMS HTTP API. YouSMS Evet Limited

Registratori di Cassa

Ministero del Lavoro e delle Politiche Sociali

MODELLI DEI PACCHETTI DI ARCHIVIAZIONE (AIP)

GESTIONE CONTRATTI. Contratti clienti e contratti fornitori

MOBS Flussi informativi sanitari regionali

Servizi medra Report e HTTPCallback

MiFID - TREM v2.0 per interfaccia locale. 1. Invio di transazioni su strumenti finanziari identificati dal codice alternativo di identificazione (AII)

Transcript:

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

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.

Indice dei Contenuti 1 - SCOPO...4 2 - INTRODUZIONE...4 3 - INTERFACCIA WS PMCNAL...5 4 - ESEMPI DI UTILIZZO...11 4.1 Esempio di notifica N1...12 4.2 Esempio di notifica N2...13 4.3 Esempio di notifica N3...13 4.4 Esempio di notifica N4...14 5 - CODICI DI ERRORE E NOTIFICHE DI NON ACCETTAZIONE...15 5.1 Esempio di notifica di non accettazione puntuale...15 5.2 Esempio di notifica di non accettazione aggregata...16 5.3 Esempio di notifica di errore in consegna su erogatore...17 6 - MONITORAGGIO SERVIZI SINCRONI...17 7 - WEB SERVICE MONITORAGGIO PER UTILIZZATORI ESTERNI...18

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:

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="http://cart.rete.toscana.it/pmc" xmlns:apachesoap="http://xml.apache.org/xml-soap" xmlns:tns="http://cart.rete.toscana.it/pmc" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/xmlschema"> <wsdl:types> <schema targetnamespace="http://cart.rete.toscana.it/pmc" xmlns="http://www.w3.org/2001/xmlschema"> <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="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="invianotifica"> <wsdlsoap:operation soapaction=""/>

<wsdl:input name="invianotificarequest"> <wsdlsoap:body namespace="http://cart.rete.toscana.it/pmc" use="literal"/> </wsdl:input> <wsdl:output name="invianotificaresponse"> <wsdlsoap:body namespace="http://cart.rete.toscana.it/pmc" use="literal"/> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="pmcnalservice"> <wsdl:port binding="tns:pmcnalsoapbinding" name="pmcnal"> <wsdlsoap:address location="http://localhost:8380/pmcnal/services/pmcnal"/> </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="http://cart.rete.toscana.it/pmc" xmlns="http://cart.rete.toscana.it/pmc" xmlns:xs="http://www.w3.org/2001/xmlschema" 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">

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

<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

<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">

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="http://cart.rete.toscana.it/pmc" xmlns="http://cart.rete.toscana.it/pmc" xmlns:xs="http://www.w3.org/2001/xmlschema" elementformdefault="qualified"> <xs:complextype name="notificationresponse"> <xs:sequence> <xs:element ref="codice" minoccurs="1"/> <xs:element ref="description" minoccurs="0"/>

<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 =

} 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="http://cart.rete.toscana.it/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>2009-07-23t13: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.

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="http://cart.rete.toscana.it/pmc"> <pmc:idcorrelazioneapp>1000</pmc:idcorrelazioneapp> <pmc:idegov>asl8staging_asl8stagingspcoopit_0004661_2009-06-29_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>2009-07-23t13: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="http://cart.rete.toscana.it/pmc"> <pmc:idcorrelazioneapp>1000</pmc:idcorrelazioneapp> <pmc:idegov>asl8staging_asl8stagingspcoopit_0004661_2009-06-29_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>2009-07-23t13: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>

<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="http://cart.rete.toscana.it/pmc"> <pmc:idcorrelazioneapp>1000</pmc:idcorrelazioneapp> <pmc:idegov>asl8staging_asl8stagingspcoopit_0004661_2009-06-29_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>2009-07-23t13: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="http://cart.rete.toscana.it/pmc"> <pmc:codice>0</pmc:codice> <pmc:description>ok</pmc:description> <pmc:esito>true</pmc:esito> </pmc:notificationresponse> </xs:schema>

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="http://cart.rete.toscana.it/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>2009-07-23t13: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></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="http://cart.rete.toscana.it/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>2009-07-23t13: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>

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="http://cart.rete.toscana.it/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>2009-07-23t13: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;

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

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="http://pmc.cart.rete.toscana.it/monitorsil" xmlns:apachesoap="http://xml.apache.org/xml-soap" xmlns:impl="http://pmc.cart.rete.toscana.it/monitorsil" xmlns:intf="http://pmc.cart.rete.toscana.it/monitorsil" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/xmlschema"> <wsdl:types> <schema elementformdefault="qualified" targetnamespace="http://pmc.cart.rete.toscana.it/monitorsil" xmlns="http://www.w3.org/2001/xmlschema"> <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"/>

<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="http://schemas.xmlsoap.org/soap/http"/> <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="http://localhost:8180/monitorsil/services/monitorsilservice"/> </wsdl:port>

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