Definizione delle interfacce di colloquio fra le componenti

Transcript

1 Definizione delle interfacce di colloquio fra le componenti 1

2 DOCUMENTO:. v 1.1 Emesso da: EMISSIONE VERIFICA APPROVAZIONE Nome Luca Menegatti firma Verificato da: Giancarlo Savoia Approvato da: Angelo Marcotulli Area ISIC LISTA DI DISTRIBUZIONE 2

3 DOCUMENTO:. CONVENZIONI UTILIZZATE NEL DOCUMENTO Sezione Contenuto Significato Figure schematiche Identifica l iter seguito dai messaggi di notifica. interoperabilità Figure schematiche Identifica l iter seguito dai messaggi di protocollo. interoperabilità Schemi DTD Identifica un contenitore obbligatorio di altre informazioni Schemi DTD Identifica un contenitore facoltativo di altre informazioni Schemi DTD Schemi DTD Schemi DTD Schemi DTD Schemi DTD Schemi DTD Identifica una informazioni elementare obbligatoria Identifica una informazioni elementare facoltativa Identifica una informazione che può essere ripetuta una o più volte Identifica una informazione che può essere ripetuta nessuna, una o più volte Collega in sequenza un contenitore alle informazioni contenute Collega un contenitore alle informazioni contenute, ed indica che le informazioni sono tra loro alternative 3

4 Indice 1. Introduzione Messaggi per interoperabilità di protocollo Messaggi di trasporto delle registrazioni di protocollo Messaggio protocollato (messaggio originale) Messaggio di conferma di ricezione Messaggio di notifica di eccezione Messaggio di aggiornamento di conferma Messaggio di annullamento protocollazione Messaggi di notifica delle registrazioni di protocollo Messaggio di accettazione Messaggio di non accettazione Messaggio di avvenuta consegna Messaggio di errore di consegna Messaggio di presa in carico Messaggi di trasporto per aggiornamento dell indice delle AOO Messaggi di trasporto per la visura dei dati di protocollo Modalità di colloquio Invio e ricezione - SIL entrambi aderenti al progetto Invio/ricezione di messaggi di protocollo con esito positivo Gestione di messaggi di notifica di fault Invio e ricezione - un SIL aderente al progetto Invio di un messaggio di protocollo ad una AOO esterna al CART Gestione della ricevuta di accettazione dal dominio di posta certificata Gestione messaggio di avvenuta consegna Gestione di messaggi di notifica di fault Ricezione messaggio di protocollo da una AOO esterna al CART Interfacce SIL-Proxy Applicativo Interfaccia per SIL evoluti Invio messaggi di protocollo Ricezione dei messaggi di protocollo Ricezione dei messaggi di notifica Ricezione dei messaggi di aggiornamento dell indice delle AOO Richiesta di visura dei dati di protocollo Interfaccia per SIL non evoluti Invio messaggi di protocollo (post http) Ricezione dei messaggi di protocollo Ricezione messaggi di notifica Ricezione messaggi di aggiornamento dei destinatari AOO Richiesta di visura dei dati di protocollo Invio dati di protocollo per la sincronizzazione della base dati delle visure Funzionalità aggiuntive Elenco messaggi da ricevere Appendice DTD Segnatura informatica

5 5.2. DTD messaggi di notifica protocollo DTD messaggi dell indice regionale delle AOO DTD ACKNOWLEDGEMENT Busta SOAP e.protocollo di trasporto tra Proxy Applicativo e SIL DTD per la visura dei dati di protocollo Campi minimi della segnatura Formato testo messaggi di notifica dei messaggi di protocollo Formato testo messaggi dell indice regionale delle AOO Formato testo messaggi di richiesta visura Definizione sincronizzazione dati per le visure Riferimenti...74 Indice delle figure Figura 1 - Sequence diagram dell invio di un messaggio di protocollo Figura 2 - Invio messaggio di protocollo con esito positivo Figura 3 - Messaggi di notifica di fault per messaggi di protocollo Figura 4 - Invio di un messaggio di protocollo ad una AOO esterna Figura 5 - Ricevuta di accettazione dal dominio di posta certificata Figura 6 - Messaggio di errore di consegna Figura 7 - Messaggio di avvenuta consegna Figura 8 - Messaggi di notifica di fault per messaggi di protocollo ad una AOO Figura 9 - Ricezione messaggio di protocollo da un AOO esterna Figura 10 Schema del DTD Segnatura AggiornamentoConferma Figura 11 Schema del DTD Segnatura - AnullamentoProtocollazione Figura 12 Schema del DTD Segnatura - NotificaEccezione Figura 13 Schema del DTD Segnatura - ConfermaRicezione Figura 14 Schema del DTD Segnatura Segnatura Figura 15 Schema del DTD Notifica Protocollo Figura 16 Schema del DTD Messaggi indice regionale delle AOO - Iscrizione AOO Figura 17 Schema del DTD Messaggi indice regionale delle AOO Aggiornamento IAOO Figura 18 Schema del DTD Messaggi indice regionale delle AOO - Iscrizione IUO Figura 19 Schema del DTD Acknowledgement Figura 20 - Busta SOAP di trasporto per messaggi di protocollo Figura 21 - Busta SOAP di trasporto per messaggi di aggiornamento indice AOO, Notifica, richiesta visure acknowledgement Figura 22 Schema del DTD Richiesta Messaggi

6 1. Introduzione. Il presente documento contiene la definizione delle specifiche per l'utilizzo del sottosistema dedicato all interoperabilità per lo scambio dei messaggi di protocollo fornito dal Sistema di Cooperazione Applicativa della Rete Telematica Regionale Toscana (RTRT). Le specifiche sono riferite sia alle modalità di colloquio tra i componenti del sistema, sia alla definizione dei messaggi scambiati. Le specifiche dell'interoperabilità per lo scambio dei messaggi di protocollo tra i sistemi di protocollo informatico degli enti aderenti al piano di azione e.toscana B2 sono realizzate secondo le specifiche tecnologiche della architettura di Cooperazione Applicativa realizzata da Regione Toscana nell'ambito del progetto e.toscana A3 CART. Le specifiche definiscono le funzionalità rese disponibili per gli enti aderenti al progetto e.toscana B2 sulla componente della architettura CART denominata nodo applicativo locale (NAL). Le specifiche dell'interoperabilità per lo scambio dei messaggi di protocollo tra i sistemi di protocollo informatico descritte dal presente documento devono essere adottate da ciascun ente aderente al progetto e.toscana B2 come le misure amministrative ed organizzative per lo scambio dei messaggi di protocollo mediante interoperabilità. Secondo quanto previsto dall'articolo 14 del DPR 445/2002, il messaggio di protocollo si intende trasmesso se inviato dal mittente dall'indirizzo elettronico dichiarato e si intende consegnato se disponibile al destinatario all'indirizzo elettronico da questi dichiarato (questa formulazione non è quella vigente ma quella prevista nello schema di DPR sulla posta elettronica certificata approvato in via preliminare dal Consiglio dei Ministri nella seduta del 25 marzo 2004 ed ha ricevuto parere favorevole delle Regioni, dell'anci, dellupi e dell'uncem nella seduta della Conferenza Unificata in data 20 maggio 2004). I messaggi di protocollo scambiati secondo le specifiche dell'interoperabilità tra i sistemi di protocollo informatico, sono considerati trasmessi se presi in carico dal sistema di cooperazione applicativa di Regione Toscana (il sistema fornisce al mittente idoneo messaggio di accettazione ) e sono considerati consegnati se recapitati al destinatario dal sistema di cooperazione applicativa di Regione Toscana (il sistema fornisce al mittente idoneo messaggio di avvenuta consegna ). Le specifiche dell'interoperabilità per lo scambio dei messaggi di protocollo tra i sistemi di protocollo informatico descritte dal presente documento descrivono anche i messaggi di notifica del trasporto telematico dei messaggi di protocollo fra l'ente mittente e l'ente destinatario. Questi messaggi di notifica sono analoghi ai messaggi di notifica prodotti dai sistemi di gestione della posta elettronica certificata. La gestione dello scambio di messaggi (di protocollo, di notifica e di servizio) fra i sistemi di protocollo informatico degli enti aderenti al progetto e.toscana B2 (nel seguito anche SIL - Sistemi Informativo Locali di Protocollo Informatico) ed il sistema di cooperazione applicativa di Regione Toscana, avviene mediante un colloquio gestito da una applicazione appositamente realizzata da Regione Toscana (Proxy Applicativo protocollo informatico). Le modalità di scambio sono 6

7 diversificate e dipendenti dalle capacità tecniche di gestione offerte dal Sistema Informativo Locale. La gestione dello scambio di messaggi avviene attraverso acknowledgement o altri sistemi di conferma descritti nel seguito del documento. Presso ogni NAL è presente una unica istanza di Proxy Applicativo protocollo informatico, al quale potranno fare riferimento uno o più SIL, purché collegati alla rete RTRT, mediante connessioni su canali sicuri. Infine il presente documento, al fine di uniformare la modalità di accesso ai documenti ed alle informazioni del sistema da parte delle altre pubbliche amministrazioni aderenti al progetto e.toscana B2 (DPR 445/2000 articolo 60), definisce il formato del messaggio di richiesta di visura dei dati di protocollo ed il messaggio di risposta a richiesta di visura dati di protocollo. 2. Messaggi per interoperabilità di protocollo. Le tipologie di messaggi trattati dal presente documento al fine della definizione delle specifiche dell'interoperabilità per lo scambio dei messaggi tra i sistemi di protocollo informatico degli enti aderenti al progetto e.toscana B2, sono raggruppate in quattro macro categorie: messaggi di protocollo per il trasporto delle informazioni delle registrazioni di protocollo messaggi dedicati alla notifica del trasporto dei messaggi di protocollo messaggi dedicati alla interoperabilità degli indici delle aree organizzative omogenee messaggi per la visura dei dati di protocollo Il contenuto ed il formato dei messaggi di protocollo, dedicati al trasporto delle informazioni delle registrazioni di protocollo, sono definiti nella circolare AIPA CR 28 (vedi [2]). Essi sono: messaggio protocollato ed i seguenti messaggi di ritorno: o messaggio di conferma ricezione o messaggio di notifica eccezione o messaggio di aggiornamento di conferma o messaggio di annullamento protocollazione. Il contenuto ed il formato dei messaggi di protocollo definiti nella circolare AIPA CR 28 (vedi [2]) sono congrui rispetto agli obiettivi del progetto e.toscana B2 e vengono adottati senza modifiche. Varia invece la modalità di composizione delle parti che compongono il messaggio ed il protocollo di trasporto utilizzato che sarà quello fornito dall infrastruttura di cooperazione applicativa del CART. Queste specifiche sono dettagliate nel paragrafo 4. 7

8 I messaggi dedicati al tracciamento del trasporto dei messaggi di protocollo, assolvono la funzione di notifica al sistema informativo locale mittente dell'esito del trasporto del messaggio di protocollo inviato al destinatario. Tali messaggi effettuano il tracciamento del trasporto sul sistema regionale di cooperazione applicativa e si integrano con gli omologhi messaggi dei sistemi di cooperazione applicativa interregionale e con i messaggi dei sistemi di trasporto dei sistemi di posta elettronica certificata. I messaggi dedicati alla interoperabilità degli indici delle aree organizzative omogenee, assolvono la funzione di comunicazione al sistema informativo locale delle variazioni intercorse sull'indice della aree organizzative omogenee (al fine della sincronizzazione dell anagrafe dei corrispondenti del sistema informativo locale). Le variazioni trasmesse sono relative all'indice regionale delle aree organizzative omogenee realizzato nell'ambito del progetto, e sono integrate con gli omologhi messaggi provenienti dai sistemi di cooperazione applicativa interregionale. I messaggi per la visura dei dati di protocollo, assolvono la funzione di comunicazione al sistema informativo locale delle informazioni di registrazione di un proprio documento presso un altro sistema della RTRT. Le informazioni relative alla protocollazione di un documento che potranno essere richieste sono le seguenti: a) numero e data di registrazione di protocollo dei documenti, ottenuti attraverso l indicazione alternativa o congiunta dell oggetto, della data di spedizione, del mittente, del destinatario; b) numero e data di registrazione di protocollo del documento ricevuto, ottenuti attraverso l indicazione della data e del numero di protocollo attribuiti dall amministrazione al documento spedito. Per permettere l attuazione del servizio di visura, il Proxy Applicativo dovrà esporre delle interfacce sia verso il SIL richiedente la visura, che verso il SIL che restituisce i dati relativi alla visura richiesta. Una richiesta di visura sarà effettuata in modalità sincrona, ovvero le informazioni richieste saranno fornite subito al SIL richiedente Messaggi di trasporto delle registrazioni di protocollo. I messaggi di trasporto delle registrazioni di protocollo sono definiti dalla circolare AIPA/CR/28 (vedi [2]). Tali definizioni sono riportate in appendice 5.1 DTD Segnatura informatica. Secondo tale circolare i messaggi di protocollo si possono distinguere in messaggi protocollati in uscita (da SIL mittente verso il sistema di cooperazione regionale) e di ritorno in ingresso (dal sistema di cooperazione regionale al SIL mittente). Ciascun messaggio di ritorno può fare riferimento ad un solo messaggio protocollato. Un messaggio di protocollo è composto dalle seguenti parti: 1. un documento informatico primario (formato MIME/DIME); 2. un numero qualsiasi di documenti informatici allegati (formato MIME/DIME); 3. una segnatura informatica, documento XML definito da un DTD. 8

9 La distinzione dei messaggi di ritorno da quelli protocollati viene effettuata tramite il nome degli attachment part come descritto nei seguenti paragrafi. Il formato dei messaggi è riportato in appendice Messaggio protocollato (messaggio originale) Un messaggio protocollato è codificato come una struttura le cui body part corrispondono alle parti dei componenti. La segnatura informatica è contenuta in una body part avente nome Segnatura.xml. Tale body part contiene un documento XML strutturato nel modo previsto dalla Document Type Definition (DTD), ed avente un root element di tipo <Segnatura>. L uso del nome Segnatura.xml per una body part è riservato a questo unico scopo Messaggio di conferma di ricezione Tramite il messaggio di conferma di ricezione, il SIL destinatario di un messaggio di protocollo comunica al SIL mittente l avvenuta protocollazione (in ingresso) del messaggio ricevuto. Il messaggio riporta anche alcune informazioni archivistiche aggiuntive, quali l identificatore della registrazione di protocollo dei documenti ricevuti, come effettuata dal SIL ricevente. Il messaggio di conferma di ricezione è inviato soltanto su esplicita richiesta del SIL mittente. Una conferma di ricezione è codificata come una struttura che contiene almeno una attachment part avente nome Conferma.xml. Tale attachment part contiene un documento XML strutturato nel modo previsto dalla DTD ed avente un root element di tipo <ConfermaRicezione>. Il nome Conferma.xml è riservato a questa finalità, analogamente a quanto previsto per la segnatura informatica Messaggio di notifica di eccezione Il messaggio di notifica di eccezione ha lo scopo di comunicare al SIL mittente le anomalie che presenta il messaggio protocollato ricevuto. Un messaggio di notifica di eccezione è codificato come una struttura che contiene una body part avente nome Eccezione.xml. Tale attachment part contiene un documento XML strutturato nel modo previsto dalla DTD, ed avente un root element di tipo <NotificaEccezione>. Il nome Eccezione.xml è considerato riservato nello stesso modo previsto per la segnatura informatica Messaggio di aggiornamento di conferma Un messaggio di aggiornamento di conferma ha lo scopo di comunicare al SIL mittente il verificarsi, presso il SIL ricevente, di un evento rilevante, successivo alla protocollazione in ingresso. L invio dei messaggi di aggiornamento di conferma avviene soltanto su esplicita richiesta del SIL mittente. Un aggiornamento di conferma è codificato come una struttura che contiene almeno una attachment part avente nome Aggiornamento.xml. Tale attachment part contiene un documento XML strutturato nel modo previsto dalla DTD, ed avente un root element di tipo <AggiornamentoConferma>. Il nome Aggiornamento.xml è considerato riservato nello stesso modo previsto per la segnatura informatica Messaggio di annullamento protocollazione Un messaggio di annullamento protocollazione ha lo scopo di comunicare al SIL mittente l annullamento di una registrazione di protocollo in ingresso effettuata dal SIL ricevente. In questo caso, l invio di un messaggio di annullamento da parte della AOO ricevente è obbligatorio, anche 9

10 qualora il SIL mittente non abbia richiesto la conferma di ricezione. Un annullamento di protocollazione è codificato come una struttura che contiene almeno una attachment part avente nome Anullamento.xml. Tale attachment part contiene un documento XML strutturato nel modo previsto dalla DTD, ed avente un root element di tipo <AnullamentoProtocollazione>. Il nome Anullamento.xml è considerato riservato nello stesso modo previsto per la segnatura informatica. Nel paragrafo 4 è trattata la modalità con la quale avviene il colloquio per lo scambio dei messaggi di trasporto delle informazioni di protocollo fra SIL e Proxy Applicativo protocollo informatico in funzione delle diverse capacità tecniche di gestione offerte dal Sistema Informativo Locale Messaggi di notifica delle registrazioni di protocollo. I messaggi di notifica hanno il compito di dare evidenza al sistema informativo locale mittente dell esito del trasporto dei messaggi di protocollo fino al destinatario; i messaggi di notifica saranno firmati con firma digitale dal sistema di gestione della infrastruttura di cooperazione applicativa per garantire la non modificabilità e non ripudiabilità degli stessi. I messaggi di notifica sono resi disponibili ai SIL e possono essere ricondotti al messaggio protocollato cui si riferiscono tramite il messageid contenuto nel file XML allegato alla busta di trasporto. I messaggi di notifica generati da componenti del sistema di gestione dell'infrastruttura di interoperabilità di protocollo diversi dal NAL dell'ente mittente sono trasmessi al destinatario mediante l'infrastruttura di cooperazione applicativa CART. Il formato dei messaggi è descritto in appendice Messaggio di accettazione Il messaggio di accettazione è un messaggio che notifica al SIL l avvenuta presa in carico del messaggio di protocollo da parte del sistema di cooperazione applicativa. Alla ricezione di un messaggio di protocollo dal SIL, il Proxy Applicativo esegue le azioni seguenti: compie i controlli formali sul documento, verifica la correttezza degli indirizzi dei destinatari mediante apposita interrogazione al server LDAP residente sul CRIC, utilizza i metodi del Framework di Cooperazione Applicativa per la predisposizione della busta e.toscana all interno della quale racchiude il messaggio di protocollo, per ogni destinatario, invia una busta e.toscana al sistema di cooperazione applicativa, utilizzando i metodi messi a disposizione dal Framework di Cooperazione Applicativa, per ogni busta e.toscana spedita, riceve un acknowledgement dal Framework di Cooperazione Applicativa. 10

11 Se l invio della busta e.toscana ha esito positivo per tutti i destinatari, il Proxy Applicativo predispone il messaggio di accettazione e lo mette a disposizione del SIL mittente. Il messaggio di accettazione è analogo per formato e significato alla ricevuta di accettazione prodotta dal punto di accesso dei sistemi di gestione di posta elettronica certificata, ed è unico a prescindere dal numero di destinatari al quale è stato inviato Messaggio di non accettazione Il messaggio di non accettazione è un messaggio che notifica al SIL il rifiuto della presa in carico del messaggio di protocollo da parte del sistema di cooperazione applicativa, mettendone in evidenza le motivazioni (ad esempio: errore in fase di validazione del DTD, errore di non accettazione da parte del Framework CA). Relativamente all invio a destinatari multipli, il Proxy Applicativo restituisce il messaggio di non accettazione se per almeno uno dei destinatari non è stata ricevuta l'accettazione da parte del Framework CA, riportandone l elenco. In dipendenza della configurazione prevista per il singolo SIL, il Proxy Applicativo decide se inviare o meno il messaggio agli altri destinatari. Il messaggio di non accettazione è unico a prescindere dal numero di destinatari ai quali è stato inviato Messaggio di avvenuta consegna Il messaggio di avvenuta consegna è un messaggio che notifica al SIL mittente l avvenuta messa a disposizione del messaggio di protocollo all'indirizzo elettronico del destinatario. Il messaggio viene utilizzato sia quando il destinatario è un Ente che utilizza l'infrastruttura per lo scambio dei messaggi di protocollo fornita dal progetto e.toscana B2, sia quando il destinatario utilizza un altro indirizzo elettronico, ad esempio la casella di posta elettronica certificata del ricevente. Nel secondo caso il messaggio di conferma avvenuta consegna corrisponde alla rielaborazione della "ricevuta di avvenuta consegna" prodotta dal punto di consegna dei sistemi di gestione di posta elettronica certificata. Al SIL mittente sarà notificato un messaggio di avvenuta consegna per ognuno dei destinatari del messaggio di protocollo Messaggio di errore di consegna Il messaggio di errore di consegna è un messaggio che notifica al SIL mittente l impossibilità di consegnare il messaggio di protocollo all'indirizzo elettronico dichiarato dal destinatario. Il messaggio di errore di consegna è analogo per formato e significato alla " ricevuta di errore di consegna" prodotto dai sistemi di gestione di posta elettronica certificata. Il messaggio può essere generato solo se il destinatario non è un Ente che utilizza l'infrastruttura per lo scambio dei messaggi di protocollo fornita dal progetto e.toscana B2 e quindi solo se il destinatario utilizza un altro indirizzo elettronico ad esempio un indirizzo di posta certificata Messaggio di presa in carico Il messaggio di presa in carico non è contemplato visto che il messaggio di accettazione è prodotto dopo l ACKNOWLEDGEMENT del Framework CA e quindi si rende inutile la ricevuta di presa in carico vista la consegna garantita del messaggio. 11

12 Nel paragrafo 4 è trattata la modalità con la quale avviene il colloquio per l'acquisizione da parte del SIL dei messaggi di notifica delle registrazioni di protocollo in funzione delle diverse capacità tecniche di gestione offerte dal Sistema Informativo Locale Messaggi di trasporto per aggiornamento dell indice delle AOO. I messaggi di trasporto relativi all aggiornamento degli indici delle AOO vengono instradati tramite l'infrastruttura di Cooperazione Applicativa CART verso il SIL sottoscrittore secondo le modalità definite dal presente documento. Un messaggio di trasporto per aggiornamento dell indice delle AOO è composto esclusivamente da un messaggio SOAP (vedi paragrafo 5.5), nella cui body part è contenuto l XML dei dati. Il formato XML dei dati scambiati è descritto nei DTD riportati in appendice 5.3. I messaggi sono relativi alle seguenti funzioni: iscrizione di una AOO: la funzione è relativa all inserimento di una nuova Area Organizzativa Omogenea nell indice regionale delle AOO. aggiornamento IAOO: la funzione è relativa alla modifica dell Indice Area Organizzativa Omogenea. aggiornamento IUO: la funzione è relativa alla modifica dell Indice Unità Organizzativa. cancellazione AOO: la funzione è relativa alla eliminazione di una Area Organizzativa Omogenea dall indice regionale delle AOO. La modalità di colloquio con la quale il SIL acquisisce i messaggi di aggiornamento delle AOO, come possibili destinatari dei propri messaggi di protocollo in uscita, è descritto al capitolo 4.2.4, ed è legato alle capacità tecnologiche del SIL stesso. 12

13 2.4. Messaggi di trasporto per la visura dei dati di protocollo. I messaggi di trasporto relativi alla visura di protocollo vengono instradati tramite l'infrastruttura di Cooperazione Applicativa CART al SIL depositario delle informazioni richieste. Un messaggio di trasporto per la visura dei dati di protocollo è composto esclusivamente da un messaggio SOAP (vedi paragrafo 5.5), nella cui body part è contenuto l XML dei dati. Il formato XML dei dati di risposta è descritto nei DTD riportati in appendice

14 3. Modalità di colloquio All interno della struttura di cooperazione applicativa CART, è possibile individuare i seguenti mittenti/destinatari di comunicazioni: ente (Sistema Informativo Locale) casella di posta elettronica certificata Il SIL mittente, aderente al progetto e.toscana B2, potrà utilizzare le stesse modalità di colloquio indipendentemente dalla tecnologia utilizzata dal destinatario. Stessa indipendenza vale viceversa per le comunicazioni tra un soggetto mittente, indipendentemente dalla tecnologia utilizzata, ed il SIL destinatario aderente al progetto e.toscana B2. Il sequence diagram riportato in figura 1, schematizza le diverse fasi che intercorrono tra l invio di un messaggio di un sistema mittente e la ricezione dello stesso da parte di un sistema destinatario. : Sistema Mittente C.A.R.T. : Sistema Destinatario 1 invio messaggio elaborazione / pubblicazione accettazione/non accettazione 2 3 preparazione messaggio avvenuta consegna 4 5 ricezione messaggio 6 Figura 1 - Sequence diagram dell invio di un messaggio di protocollo 14

15 Gli step di invio di un messaggio sono: 1. Il messaggio viene inviato dal sistema mittente, che può essere un SIL appartenente o non appartenente alla RTRT. 2. Il CART elabora il messaggio, esegue i controlli formali sul documento e provvede all'invio a tutti i destinatari mediante il Framework di Cooperazione Applicativa. 3. Il CART comunica al mittente l accettazione o meno del messaggio inviato, indicando eventualmente i destinatari per i quali il messaggio non è stato accettato per invio multiplo. Gli step di ricezione di un messaggio sono: 1. Il CART, tramite il Framework di Cooperazione Applicativa, elabora il messaggio e lo mette a disposizione dei sistemi destinatari. 2. Il CART comunica al mittente l avvenuta o meno consegna del messaggio inviato relativamente ad ognuno dei destinatari. 3. I sistemi destinatari ricevono il messaggio. Per evidenziare i diversi ruoli dei vari sistemi, nei seguenti paragrafi sono descritti, in dettaglio, tutti i casi di colloquio riconducibili comunque agli step descritti precedentemente Invio e ricezione - SIL entrambi aderenti al progetto Invio/ricezione di messaggi di protocollo con esito positivo Il SIL mittente spedisce tramite interfaccia il messaggio di protocollo al Proxy Applicativo (figura 2 1a), il Proxy Applicativo dopo i controlli formali compone la busta e.toscana contenente il messaggio di protocollo, lo invia tramite CART e produce un messaggio di accettazione (1b). La busta e.toscana viene consegnata al Proxy Applicativo ricevente a cui afferisce il SIL destinatario mediante specifica coda. Il Proxy Applicativo la sbusta e mette a disposizione il messaggio di protocollo al SIL destinatario (2a). Quando il Proxy Applicativo acquisisce i messaggi di protocollo dalla coda, invia il Messaggio di avvenuta consegna sulla coda del SIL mittente (2b). La consegna del messaggio dal Proxy Applicativo ricevente al SIL avviene in ogni caso: eventuali anomalie nella fase di consegna non precludono l invio del messaggio di avvenuta consegna al SIL mittente. 15

16 Figura 2 - Invio messaggio di protocollo con esito positivo Gestione di messaggi di notifica di fault Il messaggio di fault riguarda la notifica di errori in fase di invio del messaggio di protocollo dal Proxy Applicativo al SIL mittente, ad esempio a seguito di esito negativo dei controlli formali (AOO errata, XML non valido). In questo caso il Proxy Applicativo compone il messaggio di non accettazione (vedi Figura 3) e lo rende disponibile al SIL. Figura 3 - Messaggi di notifica di fault per messaggi di protocollo Il messaggio di errore di consegna non è gestito perché l accettazione del messaggio è garantita dal Framework CA. 16

17 3.2. Invio e ricezione - un SIL aderente al progetto Invio di un messaggio di protocollo ad una AOO esterna al CART Anche in questo caso l invio di un messaggio di protocollo (figura 4 1a) è seguito dall invio di messaggi di notifica (1b). Il gateway, che a tutti gli effetti è un Proxy Applicativo per la gestione della posta certificata, riceve la busta di e.toscana dal sistema regionale di cooperazione applicativa (3), la apre ed invia il messaggio di protocollo al punto d accesso del dominio della posta certificata mittente.. Figura 4 - Invio di un messaggio di protocollo ad una AOO esterna 17

18 Gestione della ricevuta di accettazione dal dominio di posta certificata Il gateway, una volta ricevuto il messaggio dal Framework CA, forma un messaggio di posta e lo invia al punto di accesso del dominio di posta certificata della AOO (4a). In conformità con quando descritto nell allegato tecnico [6] il punto di accesso invia la ricevuta di accettazione all utente, quindi il gateway, che si può considerare un utente automatico, legge il messaggio e lo scrive sul proprio log per le operazioni di monitoraggio. Figura 5 - Ricevuta di accettazione dal dominio di posta certificata Quando il punto di accesso non è raggiungibile, il gateway attiva un timeout alla scadenza del quale prova ad inviare di nuovo il messaggio. Se il problema persiste, inizializza di nuovo il timeout e riprova; i tentativi di invio saranno ripetuti per un numero di volte configurabile. Se l errore persiste al termine dei tentativi previsti, il gateway produce una traccia sul log, con contestuale attivazione dei meccanismi di alert verso il sistema di monitoraggio attivo, e notifica l anomalia al SIL mittente con un messaggio di errore di consegna (vedi Figura 6). 18

19 Figura 6 - Messaggio di errore di consegna 19

20 Gestione messaggio di avvenuta consegna Quando il messaggio di posta arriva al punto di consegna, quest ultimo invia la Ricevuta di avvenuta consegna (6a) al gateway che la elabora e la invia sul Framework CA per il SIL mittente (6b). Figura 7 - Messaggio di avvenuta consegna Gestione di messaggi di notifica di fault Nel caso in cui il punto di consegna fosse impossibilitato a recapitare il messaggio (vedi Figura 8) nella casella di posta certificata del gateway o al verificarsi di altre anomalie, il punto di consegna spedisce una Ricevuta di errore di consegna (6a), quindi il gateway, elaborando tale notifica, si preoccupa di inviare sul Framework CA l evento in modo da renderlo disponibile al SIL mittente (6b). 20

21 Figura 8 - Messaggi di notifica di fault per messaggi di protocollo ad una AOO 21

22 Ricezione messaggio di protocollo da una AOO esterna al CART Per la realizzazione di questa funzione è previsto che sul sistema di gestione della posta elettronica certificata fornito dal progetto e.toscana B2 vengano predisposte caselle di posta certificata distinte per ogni AOO. A livello funzionale (vedi figura 9), il gateway verifica, nelle singole caselle di posta certificata, la presenza di messaggi di protocollo inviati dalle AOO esterne o di messaggi di notifica prodotti dal sistema di posta elettronica certificata. I messaggi presenti nella casella sono letti dal gateway (1), che apre la busta di trasporto, compone la busta e.toscana con il messaggio di protocollo ovvero con il messaggio di notifica e lo pubblica mediante il Framework CA sulla coda del SIL di destinazione (2). Il Framework CA ha caratteristiche di sicurezza sufficienti a garantire l avvenuta consegna del messaggio al SIL destinatario. Il questo caso il Proxy Applicativo attestato sul NAL dell ente locale destinatario non deve produrre il messaggio di avvenuta consegna né il messaggio di errore di consegna in quanto tale notifica al mittente è stata gestita dal dominio di posta elettronica certificata al momento della ricezione. Figura 9 - Ricezione messaggio di protocollo da un AOO esterna Quando il gateway non è in grado di riconoscere la segnatura nel messaggio ricevuto, o se quest ultimo non la contiene o al verificarsi di qualsiasi altro caso che non permette l identificazione della AOO destinataria, è prodotta una traccia sul log con contestuale attivazione dei meccanismi di alert verso il sistema di monitoraggio attivo. 22

23 4. Interfacce SIL-Proxy Applicativo In questo paragrafo viene approfondito il modo in cui il Proxy Applicativo comunica con i vari tipi di SIL. La comunicazione tra i due soggetti, infatti, avviene in modalità differente a seconda della tecnologia a disposizione del SIL: in particolare si possono distinguere i SIL evoluti dai SIL non evoluti, ovvero quei sistemi informativi locali che sono in grado di comporre buste SOAP con contenuti conformi alle body part definite dalla circolare AIPA/CR/28 da quelli che non sono in grado. Il Proxy Applicativo per il protocollo informatico esporrà ai SIL diversi tipi di interfacce di comunicazione, descritti nel seguito del paragrafo, tramite le quali i SIL potranno inviare e ricevere messaggi. Nonostante a livello di CART venga fatta una distinzione nella gestione dei messaggi di trasporto per l interoperabilità del protocollo (comunicazione point to point) e quelli per l aggiornamento degli indici delle AOO (publish & subscribe), il Proxy Applicativo offrirà ai SIL una modalità di colloquio omogenea per il trattamento e lo smistamento dei dati Interfaccia per SIL evoluti Un messaggio protocollato scambiato tra SIL e Proxy Applicativo è una struttura composita, che aggrega tre diverse parti: a) un documento informatico primario; b) un numero qualsiasi di documenti informatici allegati; c) una segnatura informatica. Il documento informatico primario deve essere sottoscritto secondo le norme riportate nel D.P.R. n. 445/2000. Nella segnatura informatica sono contenute informazioni archivistiche, informazioni sulla struttura del messaggio protocollato tra le quali la distinzione tra documento primario ed allegati ed informazioni utilizzabili dalle AOO riceventi per il trattamento dei documenti. Ciascuna parte di un messaggio è codificata come una attachment part, univocamente identificata nella struttura SOAP che codifica il messaggio. Si definisce come nome di una attachment part il primo dei valori effettivamente specificati nell ordine di precedenza descritto dalla seguente lista: a) il valore del parametro filename dell attributo Content-Disposition della attachment part SOAP; b) il valore del parametro name dell attributo Content-Type della attachment part SOAP. Il nome di ciascuna attachment part rappresenta l elemento di collegamento indispensabile tra la segnatura informatica e l insieme dei documenti informatici aggregati nella struttura SOAP. L uso dei nomi ha anche lo scopo di rendere irrilevante l ordinamento delle attachment part all interno della struttura SOAP. Un messaggio protocollato è codificato come una struttura SOAP, le cui attachment part corrispondono alle parti componenti. 23

24 La segnatura informatica è contenuta in una attachment part avente nome Segnatura.xml. Tale attachment part contiene un documento XML strutturato nel modo descritto nell appendice 5.1, ed avente un root element di tipo <Segnatura>. L uso del nome Segnatura.xml per una attachment part è riservato a questo unico scopo. Ogni variazione, in termini di caratteri maiuscoli e minuscoli, del nome di una attachment part deve essere evitata. In generale, tutte le attachment part di un messaggio protocollato devono avere un nome univoco, che viene utilizzato nella segnatura informatica per descrivere l organizzazione del messaggio (per esempio per distinguere il documento primario dagli eventuali allegati). È tuttavia possibile che un messaggio protocollato contenga una attachment part priva di nome. Tale attachment part viene interpretata come il testo del messaggio e, nel caso di comunicazioni tra AOO della stessa amministrazione, può rappresentare il documento primario del messaggio stesso qualora la segnatura informatica contenga un esplicita indicazione in questo senso. Dal punto di vista amministrativo, la descrizione del significato di ciascuna attachment part del messaggio protocollato è contenuta nella segnatura informatica. Più precisamente, la segnatura informatica contiene l elenco di tutti i documenti contenuti nel messaggio protocollato che hanno una rilevanza formale Invio messaggi di protocollo Il Proxy Applicativo mette a disposizione dei SIL un webservice SOAP (su HTTP), che espleta la funzione di ricezione di messaggi di protocollo. Ogni SIL evoluto dovrà quindi implementare un client SOAP in grado di comporre ed inviare un messaggio di protocollo nel formato di busta SOAP descritto nel paragrafo 2.1 e definito in appendice 5.5 (vedi Figura 20). Per la composizione della busta il client si potrà anche avvalere della elaborazione della descrizione WSDL presente sul Proxy Applicativo all indirizzo: WEB SERVICE PER INVIO>?wsdl invocando semplicemente il metodo relativo all invio dei messaggi. Il client, quindi, invia la busta SOAP, comprensiva dei parametri necessari per l interrogazione del webservice sul Proxy Applicativo (nome SIL, nome evento e messageid) e di eventuali allegati. La risposta del webservice, attestato sul Proxy Applicativo, è una ulteriore busta contenente nella body part un file XML, definito dal DTD in appendice 5.4, che conferma o meno il buon esito dell invio del messaggio (vedi paragrafo 5.5 Figura 21) Ricezione dei messaggi di protocollo Il SIL potrà ricevere un messaggio di protocollo interrogando un apposito webservice attestato sul Proxy Applicativo. Ogni SIL evoluto dovrà quindi implementare un client SOAP in grado di comporre ed inviare un messaggio nel formato di busta SOAP, nella cui body part saranno contenuti i parametri necessari (nome SIL, nome evento) a ricevere i messaggi di protocollo relativi al singolo SIL. 24

25 Per la composizione della busta il client si potrà anche avvalere della elaborazione della descrizione WSDL presente sul Proxy Applicativo all indirizzo: WEB SERVICE PER RICEZIONE>?wsdl invocando semplicemente il metodo relativo alla ricezione dei messaggi. Il client, quindi, invia la busta SOAP, ed a seguito della richiesta, il Proxy Applicativo restituirà il messaggio nel formato descritto nel paragrafo 2.1 e in appendice 5.5 ( vedi Figura 20). Al termine della comunicazione, il client del SIL comunicherà al Proxy Applicativo l esito, sia nel caso positivo che negativo (ad esempio per interruzione sul canale di comunicazione), per mezzo di un acknowledgement. Il SIL evoluto dovrà quindi implementare un ulteriore client SOAP in grado di comporre ed inviare il messaggio di acknowledgement nel formato di busta SOAP, nella cui body part sono contenuti i parametri necessari (nome SIL, messageid, ack=si/no) a comunicare al proxy applicativo l esito della comunicazione. Per la composizione della busta il client si potrà anche avvalere della elaborazione della descrizione WSDL presente sul Proxy Applicativo all indirizzo: WEB SERVICE PER ACK>?wsdl invocando semplicemente il metodo relativo alla comunicazione dell esito della comunicazione. In mancanza della ricezione dell acknowledgement il Proxy Applicativo renderà disponibile al SIL il messaggio che non ha ricevuto correttamente per un numero N di volte, configurabile a livello di singolo SIL Ricezione dei messaggi di notifica Il SIL potrà richiedere un messaggio di notifica interrogando, tramite un client SOAP, un webservice attestato sul Proxy Applicativo, il quale restituirà una busta SOAP nel formato riportato in appendice (vedi par. 5.5 Figura 21). Ogni SIL evoluto dovrà quindi implementare un client SOAP in grado di comporre ed inviare un messaggio nel formato di busta SOAP nella cui body part sono contenuti i parametri necessari (nome SIL, nome evento) a ricevere i messaggi di protocollo relativi al singolo SIL. Per la composizione della busta il client si potrà anche avvalere della elaborazione della descrizione WSDL presente sul Proxy Applicativo all indirizzo: WEB SERVICE PER RICEZIONE NOTIFICA>?wsdl invocando semplicemente il metodo relativo alla ricezione dei messaggi. Il client, quindi, invia la busta SOAP ed a seguito della richiesta il Proxy Applicativo restituirà il messaggio nel formato descritto nel paragrafo 2.2 e in appendice 5.5 (vedi Figura 21), ovvero una 25

26 busta SOAP nella cui body part sarà incluso un documento XML definito dal DTD in appendice Ricezione dei messaggi di aggiornamento dell indice delle AOO Il SIL potrà ricevere un messaggio per l aggiornamento dell indice delle AOO interrogando un webservice attestato sul Proxy Applicativo, il quale restituirà una busta SOAP nel formato riportato in appendice (paragrafo 5.5 Figura 21). Ogni SIL evoluto dovrà quindi implementare un client SOAP in grado di comporre ed inviare un messaggio nel formato di busta SOAP nella cui body part sono contenuti i parametri necessari (nome SIL, nome evento) a ricevere i messaggi di protocollo relativi al singolo SIL. Per la composizione della busta, il client si potrà anche avvalere della elaborazione della descrizione WSDL presente sul Proxy Applicativo all indirizzo: WEB SERVICE PER RICEZIONE AOO>?wsdl invocando semplicemente il metodo relativo alla ricezione dei messaggi. Il client, quindi, invia la busta SOAP ed a seguito della richiesta il Proxy Applicativo restituirà il messaggio nel formato descritto nel paragrafo 2.3 e in appendice 5.5 (vedi Figura 21), cioè una busta SOAP nella cui body part sarà incluso un documento XML definito dal DTD in appendice Richiesta di visura dei dati di protocollo Il SIL potrà effettuare una richiesta sincrona di visura dei dati di protocollo interrogando un webservice attestato sul Proxy Applicativo, che, tramite il framework CA, andrà ad interrogare il fornitore del servizio, che a sua volta restituirà una busta SOAP con i dati relativi alla visura richiesta. Ogni SIL evoluto dovrà quindi implementare un client SOAP in grado di comporre ed inviare un messaggio nel formato di busta SOAP nella cui body part saranno contenuti i parametri necessari (SIL richiedente, SIL rispondente, nome evento, numero protocollo e data protocollo nel formato stringa aaaa-mm-gg ) a ricevere i messaggi di protocollo relativi al singolo SIL. Per la composizione della busta il client si potrà anche avvalere della elaborazione della descrizione WSDL presente sul Proxy Applicativo all indirizzo: WEB SERVICE PER RICEZIONE VISURA>?wsdl invocando semplicemente il metodo relativo alla richiesta della visura. Il client, quindi, invia la busta SOAP ed a seguito della richiesta il Proxy Applicativo restituirà il messaggio nel formato descritto nel paragrafo 2.4 e in appendice 5.5 (vedi Figura 21), cioè una busta SOAP nella cui body part sarà incluso un documento XML definito dal DTD in appendice

27 4.2. Interfaccia per SIL non evoluti Per SIL non evoluto si intende un sistema informativo locale che implementa una versione di Protocollo Informatico non AIPA/CR/28 e quindi non in grado di comporre buste SOAP secondo le modalità descritte nei paragrafi precedenti. Per questa tipologia di SIL, il Proxy Applicativo permette una interazione secondo un formato basato su sintassi XML o testuale (TXT) (a secondo della configurazione del SIL stesso), in grado di contenere un subset di dati minimo ma adeguato, in accordo a quanto descritto nella circolare AIPA/CR/28. Per quanto riguarda la richiesta di un evento da parte di un SIL non evoluto, viene stabilito un formato standard per facilitare il colloquio con il Proxy Applicativo. La richiesta avviene tramite una GET http al seguente indirizzo: me_sil=<nome_sil>&formato=<formato>&step=<step> I parametri utilizzati hanno il significato seguente: <NOME_EVENTO> è il parametro che identifica la tipologia di evento che il SIL vuole ricevere; <NOME_SIL> è il nome del SIL richiedente; <FORMATO> indica il formato XML o TXT in cui il client del SIL preferisce visualizzare il messaggio; di default il formato scelto è XML; <STEP> è il parametro che permette di implementare il meccanismo di acknowledgement per la ricezione dei messaggi secondo l algoritmo descritto nei paragrafi successivi. Nel caso in cui il formato scelto dal SIL fosse XML, il messaggio contenente l evento destinato al SIL e sarà strutturato nel modo seguente: <EVENTO> <! -- Corpo del Messaggio </EVENTO> dove Corpo del Messaggio è il contenuto di un messaggio rappresentante un singolo evento destinato al SIL Invio messaggi di protocollo (post http) Per un invio automatizzato dei messaggi di protocollo, il Proxy Applicativo mette a disposizione un post HTTP tramite il quale: Inviare i dati minimi, Costruire la segnatura, Realizzare l upload dei documenti allegati nel formato MIME, codificato base64 1 (vedi [9]). 1 Conforme allo standard MIME [RFC2045] 27

28 L indirizzo al quale effettuare il post http sarà del tipo: Nel post vengono anche inviati i seguenti parametri: Nome_evento = MessaggioProtocollo, MessaggioNotifica. Nome_SIL = Il nome del SIL. messageid = Identificatore unico valido solo per l evento MessaggioProtocollo (es: numero protocollo + nome del SIL), non necessario negli altri eventi. Allegato = SI/NO identifica che il post riguarda un allegato del messaggio di protocollo, non necessario negli altri eventi. Il post che riguarda la segnatura è di tipo testo con il formato conforme a quanto riportato in appendice Ricezione dei messaggi di protocollo Per la ricezione dei messaggi di protocollo il Proxy Applicativo offre una interfaccia HTTP che permette al Sistema Informativo Locale di prelevare i messaggi ad esso destinati. Il formato dei messaggi restituiti al SIL potrà essere XML o TXT (configurabile tramite l apposito parametro <FORMATO> in fase di richiesta messaggi). La richiesta dei messaggi avviene tramite una o più GET http al seguente indirizzo: NOME_SIL>&formato=<FORMATO>&step=<STEP> La prima richiesta effettuata dal SIL dovrà prevedere il parametro <STEP> = 0. Il Proxy Applicativo risponderà inviando, del messaggio di protocollo, la sola segnatura e l informazione sul numero N di eventuali allegati previsti. Le richieste successive da parte del SIL avverranno valorizzando il parametro <STEP> con valori da 1 a N+1 ed il Proxy Applicativo risponderà inviando gli N allegati previsti (codificati in base64). Il generico <STEP> = M+1 (con 1<M<N) verrà interpretato dal Proxy Applicativo come acknowledgement di conferma ricezione dell allegato M-esimo. Lo <STEP> = N+1 verrà interpretato dal Proxy Applicativo come acknowledgement di conferma ricezione dell intero messaggio di protocollo. Ogni GET attiva un timeout, configurabile su ogni Proxy Applicativo in base al di tipo di <STEP> (per differenziare la ricezione della segnatura da quella degli allegati). La prima richiesta da parte del SIL attiverà il primo timeout, dopo di che: se la richiesta successiva arriva entro il termine del timeout, la parte di messaggio di protocollo precedentemente inviata si intende ricevuta correttamente dal SIL. 28

29 se la richiesta successiva arriva dopo il timeout o non arriva, la parte di messaggio di protocollo precedentemente inviata si intende non ricevuta correttamente ed il messaggio di protocollo viene di nuovo reso disponibile per un numero di volte configurabile a livello di singolo SIL. Per avere la certezza che il SIL abbia ricevuto correttamente il messaggio di protocollo con tutti i suoi N allegati il Proxy Applicativo, quindi, dovrà ricevere dopo lo <STEP> = 0, N+1 <STEP> di richiesta messaggi entro i timeout previsti. Nel caso si verifichi un errore di natura qualsiasi in fase di ricezione, il SIL potrà segnalare un acknowledgement di errore tramite una GET al seguente indirizzo: NOME_SIL>&ack=no l effetto di questo acknowledgement di errore fa si che il Proxy Applicativo passi all elaborazione del messaggio successivo. In ogni caso, i messaggi correttamente inviati dal Proxy Applicativo al SIL non verranno più riproposti al SIL. Le specifiche del formato TXT sono definite in appendice Ricezione messaggi di notifica La richiesta di questo tipo di messaggi avviene allo stesso modo di quella relativa ai messaggi di protocollo descritti nel paragrafo Naturalmente cambierà il valore del parametro <NOME_EVENTO>, ed il parametro <STEP> verrà utilizzato con un numero minore di iterazioni. La richiesta di messaggi di notifica dei messaggi di protocollo avviene tramite una GET http al seguente indirizzo: _SIL=<NOME_SIL>&formato=<FORMATO>&step=<STEP> In questo caso, la richiesta effettuata dal SIL specificando il parametro <STEP> = 0 comporterà l invio, da parte del Proxy Applicativo, della notifica dei messaggi di protocollo. La richiesta successiva da parte del SIL dovrà valorizzare il parametro <STEP> = 1; tale richiesta verrà interpretata dal Proxy Applicativo come acknowledgement di conferma ricezione del messaggio inviato. Ogni GET attiva un timeout, configurabile su ogni Proxy Applicativo in base al di tipo di <STEP>. La prima richiesta <STEP> = 0 da parte del SIL attiverà il primo timeout, dopo di che: se la richiesta successiva <STEP> = 1 arriva entro il termine del timeout, la notifica del messaggio di protocollo precedentemente inviata si intende ricevuta correttamente dal SIL. 29