Piano di azione e.toscana Progetto B2 Definizione delle interfacce di colloquio fra le componenti. Documentazione delle interfacce SIL - NAL

Transcript

1 Definizione delle interfacce di colloquio fra le componenti Documentazione delle interfacce SIL - NAL

2 DOCUMENTO:. v 2.0 EMISSIONE VERIFICA APPROVAZIONE Emesso da: Nome Luca Menegatti firma Approvato da: Angelo Marcotulli Area ISIC LISTA DI DISTRIBUZIONE AGGIORNAMENTI Versione Data Paragrafi Modificati Motivo Modifica /04/2005 Il presente documento è la fusione di due precedenti documenti: Documento Interfacce v1.5, del 03/09/2004 e Documento Interfacce - Gestione Nuovi messaggi v1.2, del 2/09/2004 Pag. 1 di 105

3 Indice 0 LIVELLO DI REVISIONE PREMESSA SCOPO DEL DOCUMENTO SOMMARIO DELLE MODIFICHE RIFERIMENTI LOCAZIONE DEL DOCUMENTO DISTRIBUZIONE ABBREVIAZIONI E TERMINI TECNICI CONVENZIONI GRAFICHE UTILIZZATE NEL DOCUMENTO INTRODUZIONE TIPOLOGIA DI MESSAGGI SCAMBIATI 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 COMUNICAZIONE NON CONFORME 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 INVIO E RICEZIONE DI MESSAGGI DI COMUNICAZIONE NON CONFORME GESTIONE MESSAGGIO DI ANOMALIA DI TRASPORTO GESTIONE MESSAGGIO DI COMUNICAZIONE DA SOGGETTO NON PUBBLICO ACCREDITATO INVIO MESSAGGIO DI AVVENUTA PROTOCOLLAZIONE A SOGGETTO NON PUBBLICO ACCREDITATO 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 RICEZIONE DEI MESSAGGI DI COMUNICAZIONE NON CONFORME INVIO MESSAGGIO DI AVVENUTA PROTOCOLLAZIONE RICHIESTA DI VISURA DEI DATI DI PROTOCOLLO Pag. 2 di 105

4 4.1.8 COMUNICAZIONE ESITO RICEZIONE MESSAGGIO INTERFACCIA PER SIL NON EVOLUTI INVIO MESSAGGI DI PROTOCOLLO (FORM HTTP) INVIO MESSAGGI DI PROTOCOLLO (POST HTTP) RICEZIONE DEI MESSAGGI DI PROTOCOLLO RICEZIONE MESSAGGI DI NOTIFICA RICEZIONE MESSAGGI DI AGGIORNAMENTO DEI DESTINATARI AOO RICEZIONE DEI MESSAGGI DI COMUNICAZIONE NON CONFORME INVIO MESSAGGIO DI AVVENUTA PROTOCOLLAZIONE RICHIESTA DI VISURA DEI DATI DI PROTOCOLLO INVIO DATI DI PROTOCOLLO PER LA SINCRONIZZAZIONE DELLA BASE DATI DELLE VISURE APPENDICE 1 FORMATO MESSAGGI PER SIL EVOLUTI DTD SEGNATURA INFORMATICA DTD MESSAGGI DI NOTIFICA PROTOCOLLO DTD MESSAGGI DELL INDICE REGIONALE DELLE AOO DTD MESSAGGIO COMUNICAZIONE NON CONFORME DTD ACKNOWLEDGEMENT DTD PER LA VISURA DEI DATI DI PROTOCOLLO APPENDICE 2 BUSTE SOAP BUSTA SOAP DI TRASPORTO PER MESSAGGI DI PROTOCOLLO BUSTA SOAP DI TRASPORTO PER MESSAGGI DI COMUNICAZIONE NON CONFORME BUSTA SOAP DI TRASPORTO PER MESSAGGI DI ALTRO TIPO APPENDICE 3 FORMATO MESSAGGI PER SIL NON EVOLUTI CAMPI MINIMI DELLA SEGNATURA FORMATO TESTO MESSAGGI DI NOTIFICA DEI MESSAGGI DI PROTOCOLLO FORMATO TESTO MESSAGGI DELL INDICE REGIONALE DELLE AOO FORMATO TESTO MESSAGGIO DI COMUNICAZIONE NON CONFORME FORMATO TESTO MESSAGGI DI RICHIESTA VISURA DEFINIZIONE SINCRONIZZAZIONE DATI PER LE VISURE APPENDICE 4 DOCUMENTAZIONE INTERFACCE WSDL WSDL RICHIEDIPROTOCOLLO WSDL RICHIEDINOTIFICA WSDL RICHIEDIAOO WSDL RICHIEDICOMUNICAZIONE WSDL INVIOACK APPENDICE 5 GESTIONE DELLE ANOMALIE DI TRASPORTO DOCUMENTI DI RIFERIMENTO Pag. 3 di 105

5 Indice delle figure Figura 1 - Ricezione messaggi da soggetti esterni al CART Figura 2 - Sequence diagram dell invio di un messaggio di protocollo Figura 3 - Invio messaggio di protocollo con esito positivo Figura 4 - Messaggi di notifica di fault per messaggi di protocollo Figura 5 - Invio di un messaggio di protocollo ad una AOO esterna Figura 6 - Ricevuta di accettazione dal dominio di posta certificata Figura 7 - Messaggio di errore di consegna Figura 8 - Messaggio di avvenuta consegna Figura 9 - Messaggi di notifica di fault per messaggi di protocollo ad una AOO Figura 10 - Ricezione messaggio di protocollo da un AOO esterna Figura 11 - Ricezione messaggio di anomalia di trasporto Figura 12 - Invio messaggio da un soggetto non pubblico accreditato Figura 13 - Restituzione messaggio di avvenuta protocollazione Figura 14 - Schema del DTD Segnatura AggiornamentoConferma Figura 15 - Schema del DTD Segnatura - AnullamentoProtocollazione Figura 16 - Schema del DTD Segnatura - NotificaEccezione Figura 17 - Schema del DTD Segnatura - ConfermaRicezione Figura 18 - Schema del DTD Segnatura Segnatura Figura 19 - Schema del DTD Notifica Protocollo Figura 20 - Schema del DTD Messaggi indice regionale delle AOO - Iscrizione AOO Figura 21 - Schema del DTD Messaggi indice regionale delle AOO Aggiornamento IAOO Figura 22 - Schema del DTD Messaggi indice regionale delle AOO - Aggiornamento IUO Figura 23 - Schema del DTD di comunicazione non conforme Figura 24 - Schema del DTD Acknowledgement Figura 25 - Schema del DTD Richiesta Servizi Figura 26 - Busta SOAP di trasporto per messaggi di protocollo Figura 27 - Busta SOAP di trasporto per messaggi di comunicazione non conforme Figura 28 - Busta SOAP di trasporto per messaggi di aggiornamento indice AOO, Notifica, richiesta visure, acknowledgement Pag. 4 di 105

6 0 LIVELLO DI REVISIONE 0.1 Premessa Il presente capitolo zero ha l'obiettivo di facilitare l'approccio all'intero documento: riporta infatti le informazioni generali necessarie alla corretta interpretazione del suo contenuto ed alla identificazione precisa della sua collocazione fisica. 0.2 Scopo del documento Questo documento nasce dall unificazione di due precedenti documenti tecnici, scritti da Italdata per descrivere le interfacce di colloquio tra SIL e Proxy Applicativo Protocollo Informatico: Documento Interfacce v1.5, del 03/09/2004 ([D1]) Documento Interfacce - Gestione Nuovi messaggi v1.2, del 2/09/2004 ([D2]) La presente Documentazione delle interfacce SIL-NAL, v1.0 viene quindi considerata sostitutiva di entrambi i documenti in quanto li comprende e li aggiorna con alcune modifiche resesi necessarie in fase di realizzazione delle componenti software caratteristiche del progetto. In particolare, il documento approfondisce le tematiche inerenti le modalità di colloquio tra i Sistemi Informativi Locali (SIL) aderenti al progetto e.toscana ed i Proxy Applicativi per il Protocollo Informatico (PAPI) preposti allo scambio di messaggi tra di essi, e trova una sua specifica collocazione nell ambito del Piano di azione e.toscana - Progetto B2. La proposta tecnica fa riferimento all ambiente architetturale ed agli standard di riferimento dell infrastruttura di cooperazione applicativa adottata dalla Regione Toscana (C.A.R.T.). 0.3 Sommario delle modifiche Livello revisione Sezioni modificate Modifiche effettuate Data 1.0 Prima stesura Unificazione dei documenti [D1] e [D2]. 13/04/ Riferimenti Pag. 5 di 105

7 Le informazioni relative al presente documento sono state reperite presso : Regione Toscana Italdata S.p.A C.N.I.P.A. Regione Toscana Dipartimento dell Organizzazione. Servizio I.I.T.R. Area Progetti Roma Sito internet Locazione del documento Hardware Software Server di Italdata S.p.A.: etoscana.server3pr1 Rational ClearCase LT Sever VOB CooperazioneApplicativa.vbs 0.6 Distribuzione Questo documento deve considerarsi solo per uso interno di : Regione Toscana Italdata S.p.A Dipartimento dell Organizzazione. Servizio I.I.T.R. Area Progetti Roma 0.7 Abbreviazioni e termini tecnici Il seguente elenco riporta le abbreviazioni utilizzate all'interno del presente documento. RTRT SIL NAL CRIC NAC Rete Telematica Regione Toscana Sistema Informativo Locale Nodo Applicativo Locale Centro Regionale per l'interoperabilità e la Cooperazione Applicativa Nodo Applicativo Centrale Pag. 6 di 105

8 FCA Framework di Cooperazione Applicativa: componente software presente sul CRIC, sul NAL e sul NAC PAPI Proxy Applicativo Protocollo Informatico - Componente software presente sul NAL per la gestione dei messaggi di protocollo informatico PACPI Proxy Applicativo Centrale Protocollo Informatico - Componente software presente sul NAC per la gestione dei messaggi di protocollo informatico e per altre funzionalità a livello di CRIC. HTTP HTTPS AOO UO IPA Busta e.toscana Busta e.protocollo XML DTD WSDL Hyper Text Transfer Protocol HTTP con supporto della sicurezza Area Organizzativa Omogenea Unità Organizzativa Indice delle Amministrazioni Pubbliche Messaggio SOAP costruito secondo le specifiche definite nel documento "D10.2-DefinizioneBusta e-toscana" Messaggio SOAP di Trasporto utilizzato per lo scambio di informazioni tra SIL e Proxy Applicativo Extensible Markup Language Document Type Dedfinition Web Service Definition Language Pag. 7 di 105

9 0.8 Convenzioni grafiche utilizzate nel documento Si riportano di seguito alcune spiegazioni sul significato di elementi grafici che verranno utilizzati nel seguito del documento per descrivere il formato dei messaggi di scambio dati tra SIL e NAL. Figure schematiche interoperabilità Sezione Contenuto Significato Identifica l iter seguito dai messaggi di notifica. Figure schematiche interoperabilità Schemi DTD Schemi DTD Schemi DTD Schemi DTD Schemi DTD Schemi DTD Schemi DTD Schemi DTD Identifica l iter seguito dai messaggi di protocollo. Identifica un contenitore obbligatorio di altre informazioni Identifica un contenitore facoltativo di altre informazioni 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 Pag. 8 di 105

10 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 diversificate e dipendenti dalle capacità tecniche di gestione offerte Pag. 9 di 105

11 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. Per completezza, nel documento vengono trattate anche le modalità di gestione di quei messaggi inviati da soggetti esterni alla Rete Telematica Regione Toscana ad Enti o Amministrazioni aderenti al progetto e.toscana B2. Nel seguito del documento si farà riferimento a tali messaggi con il termine comunicazioni, per distinguerli dalle altre tipologie di messaggio. 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 Tipologia di messaggi scambiati 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 cinque 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 di comunicazione non conforme 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 [D5]. 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 Pag. 10 di 105

12 o messaggio di annullamento protocollazione. Il contenuto ed il formato dei messaggi di protocollo definiti nella circolare AIPA CR 28 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 capitolo 4: Interfacce SIL-Proxy Applicativo. 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 di comunicazione non conforme riguardano comunicazioni da parte di soggetti esterni al CART. Una prima distinzione va fatta, prima di tutto, per individuare le differenze tra soggetti non pubblici accreditati e soggetti esterni. Soggetti non pubblici accreditati sono cittadini o imprese non dotati di un servizio di posta certificata ma in possesso di un certificato (di accesso) rilasciato da una autorità di certificazione riconosciuta ed interoperante con la CA di Rete Telematica Regionale Toscana. Soggetto esterno è un soggetto che rientra in una delle seguenti tipologie: o soggetto non pubblico provvisto di firma digitale o soggetto non pubblico che invia comunicazioni attraverso un generico provider di posta certificata o soggetto non pubblico non provvisto di firma digitale Altri possibili soggetti che potrebbero inviare messaggi ad un SIL sono i seguenti: Pubblica Amministrazione che invia messaggi non conformi alla circolare AIPA/CR/28 Pubblica Amministrazione che non utilizza sistemi sicuri di trasporto quali la posta elettronica certificata In entrambi i casi, i messaggi verranno riconosciuti dal punto di ricezione del dominio di posta elettronica certificata di RTRT come anomalie di trasporto (nel primo caso perché non è presente o non è valida la segnatura e nell altro caso perché il messaggio proviene da un Pag. 11 di 105

13 provider di posta non certificata) e quindi possono essere considerati allo stesso modo dei soggetti esterni. 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. 2.1 Messaggi di trasporto delle registrazioni di protocollo I messaggi di trasporto delle registrazioni di protocollo sono definiti dalla circolare AIPA/CR/28 [D5]. 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. 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 5.1 DTD Segnatura informatica Messaggio protocollato (messaggio originale) Un messaggio protocollato è codificato come una struttura le cui attachment part corrispondono alle componenti del messaggio. La segnatura informatica è contenuta in una attachment part avente nome Segnatura.xml. Pag. 12 di 105

14 Tale attachment 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 un allegato è 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 attachment 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 Pag. 13 di 105

15 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 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 Annullamento.xml. Tale attachment part contiene un documento XML strutturato nel modo previsto dalla DTD, ed avente un root element di tipo <AnnullamentoProtocollazione>. Il nome Annullamento.xml è considerato riservato nello stesso modo previsto per la segnatura informatica. Nel capitolo 4 Interfacce SIL-Proxy Applicativo, è 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. 2.2 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 5.2 DTD messaggi di notifica protocollo 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, Pag. 14 di 105

16 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. 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 Pag. 15 di 105

17 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. Nel capitolo 4 Interfacce SIL-Proxy Applicativo, è 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. 2.3 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 6.3 Busta SOAP di trasporto per messaggi di altro tipo), nella cui body part è contenuto l XML dei dati. Il formato XML dei dati scambiati è descritto nei DTD riportati in appendice 5.3 DTD messaggi dell indice regionale delle AOO. 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. Pag. 16 di 105

18 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 nei paragrafi e 4.2.5, ed è legato alle capacità tecnologiche del SIL stesso. 2.4 Messaggi di Comunicazione non conforme Vengono descritte di seguito le varie modalità di gestione dei messaggi inviati ad un SIL da parte di un soggetto esterno al CART. Per una maggiore comprensione dello scenario descritto nei paragrafi seguenti, si faccia riferimento alla Figura 1: Soggetto non pubblico accreditato Casella di posta certificata Soggetto esterno AOO esterna al CART CRIC Web Application Gateway Proxy Applicativo Comunicazione non conforme Anomalia di trasporto Messaggio di trasporto delle registrazioni di Protocollo Coda Comunicazione_NomeSIL Coda Protocollo_NomeSIL Figura 1 - Ricezione messaggi da soggetti esterni al CART Quando il gateway di posta certificata va ad interrogare la casella di posta elettronica certificata di una determinata AOO può trovarsi di fronte a diversi tipi di messaggio provenienti sia da soggetti esterni che da AOO esterne al CART. Comunque tutte le tipologie possono essere ricondotte alle seguenti: 1. Messaggi di trasporto delle registrazioni di Protocollo. 2. Messaggi di Anomalia di Trasporto riconosciuti dal punto di ricezione del dominio di posta certificata. Nel primo caso ci si trova di fronte ad una tipologia di messaggio già trattata nel documento al paragrafo 2.1 Messaggi di trasporto delle registrazioni di protocollo: il Pag. 17 di 105

19 messaggio viene imbustato e.toscana ed inviato al FrameworkCA per la pubblicazione sulla coda Protocollo_NomeSIL. I messaggi del secondo tipo vengono considerati Comunicazioni non conformi e dopo essere stati imbustati e.toscana, vengono inviati al FrameworkCA per la pubblicazione sulla coda Comunicazione_NomeSIL. L ultima tipologia che deve essere trattata riguarda i messaggi provenienti da soggetti non pubblici accreditati, per i quali si è scelto di uniformare la struttura del messaggio da consegnare al SIL al fine di presentare un unica struttura di busta di trasporto indicata nel seguito del documento col termine comunicazione non conforme allo standard e.toscana. Queste comunicazioni vengono inviate dal Proxy Applicativo presente sul CRIC (dal PACPI) al FrameworkCA per la pubblicazione sulla coda Comunicazione_NomeSIL. Criteri utilizzati dal Gateway per distinguere un tipo di messaggio dall altro. Per eseguire dei controlli preliminari senza bisogno di sbustare il messaggio, il gateway potrà utilizzare il subject del messaggio stesso. I testi standard che è possibile trovare come prefissi aggiunti dal sistema di posta certificata al subject del messaggio originario sono indicati nel documento [D4]. - Se il subject contiene il testo POSTA CERTIFICATA è probabile che il messaggio sia del primo tipo; la certezza sarà data dalla presenza del file segnatura.xml all interno del messaggio stesso. Se non è presente la segnatura il messaggio sarà classificato del secondo tipo. - Se il subject contiene il testo ANOMALIA MESSAGGIO allora verrà identificato come messaggio del secondo tipo. Tutti gli altri casi verranno riconosciuti come messaggi del primo tipo (subject contenente il testo CONSEGNA oppure ACCETTAZIONE). 2.5 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 6.3 Busta SOAP di trasporto per messaggi di altro tipo), nella cui body part è contenuto l XML dei dati. Il formato XML dei dati di risposta è descritto nei DTD riportati in appendice 5.6 DTD per la visura dei dati di protocollo. Pag. 18 di 105

20 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 2, 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 2 - Sequence diagram dell invio di un messaggio di protocollo Pag. 19 di 105

21 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. 3.1 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 3 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. Pag. 20 di 105

22 Figura 3 - 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 4) e lo rende disponibile al SIL. Figura 4 - 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. Pag. 21 di 105

23 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 5 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 5 - Invio di un messaggio di protocollo ad una AOO esterna 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 (Figura 6-4a). In conformità con quando descritto nell allegato tecnico [D6] 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. Pag. 22 di 105

24 Figura 6 - 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 7). Figura 7 - Messaggio di errore di consegna Pag. 23 di 105

25 3.2.3 Gestione messaggio di avvenuta consegna Quando il messaggio di posta arriva al punto di consegna, quest ultimo invia la Ricevuta di avvenuta consegna (Figura 8-6a) al gateway che la elabora e la invia sul Framework CA per il SIL mittente (6b). Figura 8 - Messaggio di avvenuta consegna Pag. 24 di 105

26 3.2.4 Gestione di messaggi di notifica di fault Nel caso in cui il punto di consegna fosse impossibilitato a recapitare il messaggio (vedi Figura 9) 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). Figura 9 - Messaggi di notifica di fault per messaggi di protocollo ad una AOO Pag. 25 di 105

27 3.2.5 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 10), 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 10 - 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. Pag. 26 di 105

28 3.3 Invio e ricezione di messaggi di comunicazione non conforme Il messaggio di comunicazione non conforme rappresenta due tipologie di messaggi: Messaggio di anomalia di trasporto recapitato nella casella di posta elettronica certificata Comunicazione da soggetto non pubblico accreditato inserita tramite web application attestata sul CRIC A seguire si descrivono in dettaglio i due tipi di messaggio Gestione messaggio di Anomalia di trasporto Il messaggio è l elaborazione del messaggio di Anomalia di trasporto prodotto dal sistema di posta certificata del destinatario a fronte di una comunicazione inviata da un soggetto esterno. Le fasi da 1 a 3 della sono descritte nell Appendice 5 Gestione delle anomalie di trasporto del presente documento. CRIC Gateway 4 Messaggio di anomalia di trasporto 3 Dominio di posta certificata Punto di consegna Framework CA Messaggio di anomalia di trasporto 2 NAL 5 Punto di ricezione 1 SIL Messaggio di posta non certificata Figura 11 - Ricezione messaggio di anomalia di trasporto Pag. 27 di 105

29 Il gateway verifica, nelle singole caselle di posta certificata dei destinatari dei messaggi, la presenza di messaggi di anomalia di trasporto prodotti dal sistema di posta elettronica certificata. I messaggi presenti nella casella sono letti dal gateway, che apre la busta di anomalia di trasporto, compone la busta e.toscana allegando il messaggio originale e la pubblica mediante il Framework CA sulla coda del SIL di destinazione (4-5). La costruzione della busta e.toscana viene completata con l aggiunta di un allegato riportante tutte le informazioni di spedizione incluse negli header del messaggio di anomalia di trasporto (riferimento DTD in appendice ). Il Framework CA ha le caratteristiche di sicurezza sufficienti a garantire l avvenuta consegna del messaggio al SIL destinatario. Il Proxy Applicativo attestato sul NAL non deve produrre messaggi di notifica in quanto questa è gestita dal dominio di posta elettronica certificata al momento della ricezione Gestione messaggio di Comunicazione da soggetto non pubblico accreditato In questo scenario il messaggio è utilizzato per comunicare alle Amministrazioni Pubbliche / Enti aderenti al progetto e.toscana B2, le comunicazioni inviate da parte di soggetti non pubblici accreditati (cittadini, imprese) non dotati di un servizio di posta certificata ma in possesso di un certificato (di accesso) rilasciato da una autorità di certificazione riconosciuta ed interoperante con la CA di Rete Telematica Regionale Toscana. Per l invio delle comunicazioni i soggetti non pubblici accreditati utilizzano una interfaccia web posizionata nel CART, che autentica il soggetto e consente l invio ad una delle AOO presenti sull indice regionale per mezzo di un proxy applicativo che si interfaccia con il CRIC. Dalla stessa interfaccia il soggetto non pubblico accreditato potrà interrogare il sistema per acquisire i messaggi di servizio relativi alla comunicazione inviata (messaggio di accettazione, messaggio di non accettazione, messaggio di avvenuta consegna, messaggio di avvenuta protocollazione). Per la realizzazione di questa funzione è prevista la realizzazione di una interfaccia web dalla quale sarà possibile indicare la/le Amministrazioni destinatarie delle comunicazione, inserire il testo esplicativo della comunicazione stessa, ed allegare a quest ultima eventuali documenti digitali firmati. Per uniformare la modalità di trasporto di questi messaggi al SIL destinatario, si è scelto di utilizzare lo stesso formato dei messaggi di comunicazione non conformi. Il messaggio che il proxy applicativo sul CRIC invia mediante il framework CA sulla coda del SIL di destinazione, è costituito da una busta e.toscana contenente un file conforme al DTD riportato al paragrafo 5.4 DTD messaggio comunicazione non conforme con il messaggio originario inserito tramite l interfaccia web e con eventuali documenti firmati allegati. A livello funzionale (vedi Figura 12), il soggetto non pubblico accreditato, dopo essersi opportunamente autenticato con il certificato di accesso rilasciato dalla autorità di Pag. 28 di 105

30 certificazione riconosciuta ed interoperante con la CA di RTRT, invia la comunicazione alla Amministrazione Pubblica / Ente aderente al progetto e.toscana B2 compilando la relativa form offerta dalla web application (1). A seguito della richiesta sarà immediatamente generato il message ID che potrà poi permettere di seguire l iter del messaggio fino alla sua consegna. Il message ID sarà legato al soggetto non pubblico accreditato per mezzo del codice fiscale / partita IVA estratto dal Common Name (CN) contenuto nel certificato X.509 rilasciato da Regione Toscana ed utilizzato per accreditarsi alla web application. La web application, alla ricezione della comunicazione, la spedisce tramite interfaccia al Proxy Applicativo (2a), il quale dopo i controlli formali compone la busta e.toscana contenente come allegati il messaggio di comunicazione non conforme e il file contenente i dati riepilogativi della comunicazione. Successivamente invia la busta e.toscana tramite CART (3) e produce un messaggio di accettazione (2b). La notifica di errori in fase di costruzione della busta e.toscana da parte del Proxy Applicativo, viene notificata per mezzo di un messaggio di non accettazione (2b). 1 6 Soggetto non pubblico accreditato 4a CRIC 4a Web Application 2a Proxy Applicativo 2b Messaggio di accettazione / Messaggio di non accettazione 3 Framework CA 4a 4 Messaggio di avvenuta consegna NAL 5 SIL Figura 12 - Invio messaggio da un soggetto non pubblico accreditato Il messaggio di accettazione ed il messaggio di non accettazione vengono inviati, tramite il framework CA, sulla coda predisposta per i soggetti non pubblici accreditati. Sarà compito del proxy applicativo attestato sul CRIC andare a leggere tali messaggi, unitamente agli eventuali messaggi di avvenuta consegna ed avvenuta protocollazione di seguito descritti, e renderli disponibili per future interrogazioni da parte del soggetto non pubblico accreditato. Pag. 29 di 105

31 Al termine dell invio della comunicazione sarà restituito al soggetto non pubblico accreditato il messaggi ID prodotto, per mezzo del quale potrà successivamente visualizzare l iter della comunicazione, tramite una apposita funzione predisposta sulla web application. La busta e.toscana viene consegnata al Proxy Applicativo ricevente a cui afferisce il SIL destinatario mediante specifica coda (4). Il Proxy Applicativo la sbusta e mette a disposizione il messaggio di comunicazione al SIL destinatario (5). Quando il Proxy Applicativo acquisisce i messaggi di comunicazione dalla coda, invia il Messaggio di avvenuta consegna sulla coda predisposta per i soggetti non pubblici accreditati Invio messaggio di avvenuta protocollazione a soggetto non pubblico accreditato A seguito della ricezione di un messaggio di Comunicazione da soggetto non pubblico accreditato, se richiesto, il SIL destinatario potrà inviare un messaggio notifica di avvenuta protocollazione. Per uniformare il "messaggio di avvenuta protocollazione" in risposta a comunicazioni non conformi provenienti da soggetti non pubblici accreditati con quello previsto in risposta a messaggi di protocollo, si è scelto di utilizzare lo stesso formato del messaggio di conferma ricezione descritto al paragrafo Per dettagli sulla struttura di tale messaggio fare riferimento a quanto descritto nel successivo paragrafo Quindi il SIL (vedi Figura 13) invia il messaggio di avvenuta protocollazione al Proxy Applicativo attestato sul NAL di riferimento (1a). Il proxy applicativo esegue i controlli formali, a seguito dei quali, se verifica anomalie (XML non valido,...) compone il messaggio di non accettazione (1b) e lo rende disponibile al SIL mittente. Se invece il proxy applicativo non verifica anomalie, compone la busta e.toscana contenente il messaggio di avvenuta protocollazione e lo invia tramite CART (2) producendo un messaggio di accettazione (1b). Il proxy applicativo potrà distinguere i messaggi di avvenuta protocollazione per soggetti non pubblici accreditati dagli altri per mezzo della valorizzazione dei tag relativi a CodiceAmministrazione e CodiceAOO: se i tag sono valorizzati con il testo COMUNICAZIONE allora il Proxy Applicativo richiederà al framework CA di pubblicarli sulla coda dei soggetti non pubblici accreditati. Il Proxy Applicativo attestato sul CRIC andrà a leggere in tale coda, sbusterà i messaggi (nella coda sono in formato e.toscana), aggiornerà lo stato della richiesta (3b) nello storage ed invierà il Messaggio di avvenuta consegna sulla coda del SIL mittente (3b). Pag. 30 di 105

32 4 Soggetto non pubblico accreditato Messaggio di Avvenuta Consegna 3b CRIC Web Application 4 Proxy Applicativo 3a Framework CA 2 Messaggio di Avvenuta consegna 3b NAL Messaggio di avvenuta 1a protocollazione Messaggio di Accettazione / Messaggio di non Accettazione 1b SIL Figura 13 - Restituzione messaggio di avvenuta protocollazione In qualsiasi momento, utilizzando il message ID, il soggetto non pubblico accreditato potrà verificare lo stato del messaggio inviato tramite apposita interfaccia web descritta in precedenza (4). Pag. 31 di 105

33 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. 4.1 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 [D8]. 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. Pag. 32 di 105

34 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. 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 DTD Segnatura informatica, 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 (vedi 8.1 WSDL RichiediProtocollo). 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 Messaggi di trasporto delle registrazioni di protocollo e definito in appendice 6.1 Busta SOAP di trasporto per messaggi di protocollo (vedi Figura 26). 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. Pag. 33 di 105

35 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.5 DTD Acknowledgement, che conferma o meno il buon esito dell invio del messaggio (vedi paragrafo 6.3, Figura 28) Ricezione dei messaggi di protocollo Il SIL potrà ricevere un messaggio di protocollo interrogando un apposito webservice attestato sul Proxy Applicativo (vedi 8.1 WSDL RichiediProtocollo). 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. 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 PROTOCOLLO>?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 6.1 ( vedi Figura 26). Al termine della comunicazione, il client del SIL comunicherà al Proxy Applicativo l esito, sia nel caso positivo che negativo nella modalità indicata al paragrafo Ricezione dei messaggi di notifica Il SIL potrà ricevere un messaggio di notifica interrogando, tramite un client SOAP, un webservice attestato sul Proxy Applicativo (vedi 8.2 WSDL RichiediNotifica), il quale restituirà una busta SOAP nel formato riportato in appendice (vedi par. 6.3, Figura 28). Pag. 34 di 105

36 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 notifica 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à: Se il messaggio di richiesta è costruito correttamente e con parametri congruenti, il messaggio nel formato descritto nel paragrafo 2.2 e in appendice 6.3 (vedi Figura 28), ovvero una busta SOAP nella cui body part sarà incluso un documento XML definito dal DTD in appendice 5.2 DTD messaggi di notifica protocollo. Se il messaggio di richiesta non è costruito correttamente o non ha parametri congruenti (nome SIL errato o mancante, nome evento errato o mancante), il messaggio nel formato descritto in appendice 6.3 (vedi Figura 28), ovvero una busta SOAP nella cui body part sarà incluso un documento XML definito dal DTD in appendice 5.5 DTD Acknowledgement. Al termine della comunicazione, il client del SIL comunicherà al Proxy Applicativo l esito, sia nel caso positivo che negativo nella modalità indicata al paragrafo 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 (vedi 8.3 WSDL RichiediAOO), il quale restituirà una busta SOAP nel formato riportato in appendice (paragrafo 6.3 Figura 28). 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: Pag. 35 di 105

37 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à: Se il messaggio di richiesta è costruito correttamente e con parametri congruenti, il messaggio nel formato descritto nel paragrafo 2.3 e in appendice 6.3 (vedi Figura 28), cioè una busta SOAP nella cui body part sarà incluso un documento XML definito dal DTD in appendice 5.3 DTD messaggi dell indice regionale delle AOO. Se il messaggio di richiesta non è costruito correttamente o non ha parametri congruenti (nome SIL errato o mancante, nome evento errato o mancante), il messaggio nel formato descritto in appendice 6.3 (vedi Figura 28), ovvero una busta SOAP nella cui body part sarà incluso un documento XML definito dal DTD in appendice 5.5 DTD Acknowledgement. Al termine della comunicazione, il client del SIL comunicherà al Proxy Applicativo l esito, sia nel caso positivo che negativo nella modalità indicata al paragrafo Ricezione dei messaggi di comunicazione non conforme Il SIL potrà ricevere un messaggio di comunicazione non conforme interrogando un apposito webservice attestato sul Proxy Applicativo (vedi 8.4 WSDL RichiediComunicazione). 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 comunicazione non conforme 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 MESSAGGIO NON CONFORME>?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 in appendice 6.2 ( vedi Figura 27). Pag. 36 di 105

38 Al termine della ricezione del messaggio, 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 comporre ed inviare il messaggio di acknowledgement nel formato di busta SOAP, nella cui body part sono contenuti i parametri (nome SIL, nomeevento, ack=si/no, descrizione eventuale errore) necessari 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 Invio messaggio di avvenuta protocollazione Se previsto, al termine della ricezione di un messaggio di comunicazione non conforme ed a protocollazione avvenuta, il client del SIL comunicherà al Proxy Applicativo la avvenuta protocollazione. Il SIL evoluto dovrà quindi implementare un client SOAP in grado comporre ed inviare il messaggio di avvenuta protocollazione allo stesso modo descritto nel paragrafo per i messaggi di trasporto delle registrazioni di Protocollo. 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 indicato di seguito: <?xml version="1.0" encoding="utf-8"?> <ConfermaRicezione> <Identificatore> <CodiceAmministrazione> </CodiceAmministrazione> <CodiceAOO> </CodiceAOO> <NumeroRegistrazione> </NumeroRegistrazione> <DataRegistrazione> </DataRegistrazione> </Identificatore> <MessaggioRicevuto> <Identificatore> <CodiceAmministrazione> </CodiceAmministrazione> <CodiceAOO> </CodiceAOO> Pag. 37 di 105

39 <NumeroRegistrazione> </NumeroRegistrazione> <DataRegistrazione> </DataRegistrazione> </Identificatore> </MessaggioRicevuto> </ConfermaRicezione> In particolare, nella sezione <MessaggioRicevuto> verranno riportate le informazioni relative al mittente del messaggio che è stato protocollato che, essendo un soggetto non pubblico accreditato, non sarà legato ad alcuna AOO o amministrazione. Il SIL dovrà, quindi, valorizzare i tag relativi a CodiceAmministrazione e CodiceAOO con il testo COMUNICAZIONE, ed inserire le informazioni relative a NumeroRegistrazione (che valorizzerà con il MessageID) e DataRegistrazione di cui dispone (perchè presenti nel messaggio originario ricevuto). Per la composizione della busta SOAP il client del SIL 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 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 Pag. 38 di 105

40 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à: Se il messaggio di richiesta è costruito correttamente e con parametri congruenti, il messaggio nel formato descritto nel paragrafo 2.5 e in appendice 6.3 (vedi Figura 28), cioè una busta SOAP nella cui body part sarà incluso un documento XML definito dal DTD in appendice 5.6 DTD per la visura dei dati di protocollo. Se il messaggio di richiesta non è costruito correttamente o non ha parametri congruenti (nome SIL richiedente/rispondente errato o mancante, nome evento errato o mancante, numero protocollo mancante, data protocollo errata o non formalmente corretta), il messaggio nel formato descritto in appendice 6.3 (vedi Figura 28), ovvero una busta SOAP nella cui body part sarà incluso un documento XML definito dal DTD in appendice 5.5 DTD Acknowledgement Comunicazione esito ricezione messaggio Al termine della ricezione dei messaggi, 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 comporre ed inviare il messaggio di acknowledgement nel formato di busta SOAP, nella cui body part sono contenuti i parametri necessari (nome SIL, nomeevento, ack=si/no, descrizione eventuale errore) 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 (vedi 8.5 WSDL InvioAck) 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. Pag. 39 di 105

41 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: >&nome_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 (form http) Pag. 40 di 105

42 Per l invio dei messaggi di protocollo, il Proxy Applicativo mette a disposizione dei SIL una form, visualizzabile mediante un qualsiasi web-browser, tramite la quale un operatore potrà inserire le informazioni necessarie per l invio di un messaggio di protocollo. A tal proposito la form sarà composta da: dei campi per i dati minimi della segnatura (vedi appendice 7.1 Campi minimi della segnatura), una box preposta per l upload del documento primario e degli eventuali allegati, una check box per selezionare il tipo di messaggio che si vuole spedire: o messaggio originale o messaggio di conferma di ricezione o messaggio notifica eccezione o messaggio di aggiornamento di conferma o messaggio di annullamento di protocollazione un pulsante per l invio dei dati inseriti nella form al Proxy Applicativo. La form sarà accessibile solo a quei browser che avranno un certificato X.509 riconosciuto dal CART. La sequenza delle operazioni per l invio di un messaggio di protocollo da parte del SIL sarà la seguente: 1. upload del documento primario (attraverso box preposta) 2. upload di eventuali allegati (attraverso box preposta) 3. upload della segnatura in formato testo contenente, tra l altro, i dati minimi inseriti nella form (alla pressione del tasto invio) Alla pressione del tasto invio il proxy costruirà la busta e.toscana e la invierà al CART. Il Proxy Applicativo prevede anche la possibilità di automatizzare quanto descritto in precedenza; la descrizione di questa modalità è riportata nel paragrafo 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, Pag. 41 di 105

43 Realizzare l upload dei documenti allegati nel formato MIME, codificato base64 1. L indirizzo al quale effettuare il post http sarà del tipo: Nel post vengono anche inviati i seguenti parametri: Nome_evento = MessaggioProtocollo 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 7.1 Campi minimi della segnatura. L invio di un messaggio di protocollo da parte del SIL avverrà attraverso le fasi seguenti: 1. upload del documento primario (attraverso box preposta) 2. upload di eventuali allegati (attraverso box preposta) 3. upload della segnatura in formato testo Alla ricezione della segnatura, il proxy costruirà la busta e.toscana e la invierà al CART 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: IL=<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 contenente le 1 Conforme allo standard MIME [RFC2045] Pag. 42 di 105

44 informazioni sugli N 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. 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: IL=<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 7.1 della segnatura Campi minimi Pag. 43 di 105

45 4.2.4 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: &nome_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. se la richiesta successiva <STEP> = 1 arriva dopo il timeout o non arriva, la notifica del messaggio di protocollo precedentemente inviata si intende non ricevuta correttamente e viene di nuovo resa disponibile per un numero di volte configurabile a livello di singolo SIL. 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=<nome_sil>&ack=no l effetto di questo acknowledgement di errore fa si che il Proxy Applicativo elimini il messaggio di notifica e passi all elaborazione del messaggio successivo. In ogni caso, i messaggi correttamente inviati dal Proxy Applicativo al SIL non verranno più riproposti al SIL. Pag. 44 di 105

46 Le specifiche del formato TXT sono definite in appendice 7.2 Formato testo messaggi di notifica dei messaggi di protocollo Ricezione messaggi di aggiornamento dei destinatari AOO La richiesta di messaggi relativi a questo tipo di servizio avviene allo stesso modo di quelle relative 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 aggiornamento dei destinatari AOO avviene tramite una GET http al seguente indirizzo: me_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, del messaggio di aggiornamento dei destinatari AOO. 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, il messaggio di aggiornamento dei destinatari AOO precedentemente inviato si intende ricevuto correttamente dal SIL. se la richiesta successiva <STEP> = 1 arriva dopo il timeout o non arriva, il messaggio di aggiornamento dei destinatari AOO si intende non ricevuto correttamente e viene di nuovo reso disponibile per un numero di volte configurabile a livello di singolo SIL. 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=<nome_sil>&ack=no Pag. 45 di 105

47 l effetto di questo acknowledgement di errore fa si che il Proxy Applicativo passi all elaborazione del messaggio successivo. La segnalazione di errore produce la cancellazione del messaggio di aggiornamento indice AOO dalla coda dei messaggi relativa a quel SIL; infatti il SIL farà uso dell acknowledgement di errore solo in presenza di anomalie che non gli consentirebbero comunque l aggiornamento del proprio indirizzario delle AOO. In ogni caso, i messaggi correttamente inviati dal Proxy Applicativo al SIL non verranno più riproposti al SIL. Le specifiche del formato TXT del messaggio restituito al SIL sono definite in appendice 7.3 Formato testo messaggi dell indice regionale delle AOO Ricezione dei messaggi di comunicazione non conforme Per la ricezione dei messaggi di comunicazione non conforme 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: e_sil=<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 anomalia di trasporto, il solo file riportante i dati riepilogativi della comunicazione non conforme. Nella richiesta successiva, con parametro <STEP> = 1, il Proxy Applicativo restituirà il messaggio originale. Infine il SIL dovrà inviare un ultima richiesta, valorizzando il parametro <STEP> = 2; 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> (per differenziare la ricezione del file iniziale contenente i dati riepilogativi da quella del messaggio originale). Pag. 46 di 105

48 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 anomalia di trasporto precedentemente inviata si intende ricevuta correttamente dal SIL. se la richiesta successiva arriva dopo il timeout o non arriva, la parte di messaggio di anomalia di trasporto precedentemente inviata si intende non ricevuta correttamente ed il messaggio di anomalia di trasporto 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 anomalia di trasporto con il messaggio originale allegato il Proxy Applicativo, quindi, dovrà ricevere dopo lo <STEP> = 0, altri due <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: e_sil=<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 7.4 Formato testo messaggio di comunicazione non conforme Invio messaggio di avvenuta protocollazione Se previsto, al termine della ricezione di un messaggio di comunicazione non conforme ed a protocollazione avvenuta, il SIL potrà segnalare la avvenuta protocollazione del messaggio allo stesso modo descritto nei precedenti paragrafi e Nel caso di utilizzo della modalità tramite web browser (form http), si dovrà specificare la tipologia messaggio di conferma di ricezione nell apposita list box del web browser utilizzato, nei campi minimi della segnatura specificare il Message ID come numero di registrazione, la data di registrazione, e valorizzando il CodiceAOO ed il CodiceAmministrazione con il testo COMUNICAZIONE. Pag. 47 di 105

49 Nel caso di automatizzazione del procedimento di invio informazioni da SIL a Proxy Applicativo (post http) le informazioni dovranno essere passate in modo analogo a quanto descritto in precedenza Richiesta di visura dei dati di protocollo La richiesta di visura avviene allo stesso modo di quelle relative 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. Per la natura di questo servizio, inoltre, dovranno essere gestiti nella richiesta tre ulteriori parametri: <NUMERO_PROTOCOLLO> <DATA_REGISTRAZIONE> <SIL_RISPONDENTE> rappresenta il numero di protocollo con il quale è stato registrato il documento dal mittente che sta effettuando la misura; è la data di spedizione del messaggio di protocollo nel formato AAAAMMGG. è il riferimento al SIL che espone il servizio di visura che si vuole interrogare. La richiesta di visura avviene tramite una GET http al seguente indirizzo: nome_sil=<nome_sil>&formato=<formato>&step=<step>&numero_protoc ollo=<numero_protocollo>&data=<data_registrazione>&sil_rispo ndente=<sil_rispondente> In questo caso, la richiesta effettuata dal SIL specificando il parametro <STEP> = 0 comporterà l invio, da parte del Proxy Applicativo, del messaggio di risposta a richiesta di visura. 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, il messaggio di risposta a richiesta di visura precedentemente inviato si intende ricevuto correttamente dal SIL. se la richiesta successiva <STEP> = 1 arriva dopo il timeout o non arriva, il messaggio di risposta a richiesta di visura si intende non ricevuto correttamente e Pag. 48 di 105

50 viene di nuovo reso disponibile per un numero di volte configurabile a livello di singolo SIL. 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: ome_sil=<nome_sil>&ack=no La segnalazione di errore produce la cancellazione del messaggio di risposta a richiesta di visura dalla coda dei messaggi relativa a quel SIL; infatti il SIL farà uso dell acknowledgement di errore solo in presenza di anomalie che non gli consentirebbero comunque di interpretare correttamente il messaggio ricevuto. 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 7.5 Formato testo messaggi di richiesta visura Invio dati di protocollo per la sincronizzazione della base dati delle visure Il Proxy Applicativo mette a disposizione un form HTTP per l invio di un file di dati da utilizzare per la sincronizzazione della base dati delle visure attestata sul NAL. L invio dei dati avviene tramite un post http al seguente indirizzo: Nella form, disponibile da un qualsiasi web-browser, è presente un campo necessario per l indicazione del nome del SIL a cui appartengono i dati ed una box per l upload del file. Il file dati è in modalità testo come definito in appendice 7.6 Definizione sincronizzazione dati per le visure. Pag. 49 di 105

51 5. Appendice 1 Formato messaggi per SIL evoluti Non tutti gli schemi dei DTD riportati a seguire sono esplosi fino all ultimo livello. Per il dettaglio completo fare comunque riferimento alla definizione del DTD. Tutti i campi data definiti nei seguenti DTD, sono da intendersi in formato ISO 8601 esteso (i.e. aaaa-mm-gg), mentre i campi ora devono essere in formato ISO 8601 esteso (i.e. hh:mm:ss[,ddd] - ad esempio 16:09:19,710; si noti che l'indicazione dei millisecondi è opzionale). 5.1 DTD Segnatura informatica Figura 14 - Schema del DTD Segnatura AggiornamentoConferma Pag. 50 di 105

52 Figura 15 - Schema del DTD Segnatura - AnullamentoProtocollazione Figura 16 - Schema del DTD Segnatura - NotificaEccezione Pag. 51 di 105

53 Figura 17 - Schema del DTD Segnatura - ConfermaRicezione Pag. 52 di 105

54 Figura 18 - Schema del DTD Segnatura Segnatura Pag. 53 di 105

55 <?xml version="1.0" encoding="iso "?> <!-- Autorita` per l'informatica nella Pubblica Amministrazione Segnatura.dtd Allegato B alla Circolare 7 maggio 2001, n. AIPA/CR/28 "Formato e definizioni dei tipi di informazioni minime ed accessorie comunemente scambiate tra le pubbliche amministrazioni e associate ai documenti protocollati" versione del 7 maggio 2001 <!-- Data di pubblicazione della DTD <!ENTITY % datapubblicazione " "> <!-- ROOT ELEMENT La DTD prevede cinque possibili "ROOT ELEMENT": - Segnatura - ConfermaRicezione - AggiornamentoConferma - NotificaEccezione - AnnullamentoProtocollazione <!-- Segnatura Si compone di tre sezioni, di cui due obbligatorie (Intestazione e Descrizione) ed una opzionale (Riferimenti): - la sezione Intestazione contiene i dati identificativi e le informazioni fondamentali del messaggio; - la sezione Riferimenti contiene le informazioni relative al contesto generale di cui il messaggio fa parte; - la sezione Descrizione contiene le informazioni descrittive riguardanti il contenuto del messaggio. Gli attributi della Segnatura definiscono la versione di riferimento del formato ed il linguaggio usato nella definizione dei valori testuali. In questa versione della DTD l'attributo "versione" ha valore fisso, pari alla data di prima pubblicazione, espressa in formato ISO 8601 esteso (i.e. aaaa-mm-gg). L'attributo standard xml:lang ha come valore fisso il token "it" (codice standard ISO 639) ed indica l'uso della lingua italiana come Pag. 54 di 105

56 default per il contenuto testuale degli elementi XML. <!ELEMENT Segnatura (Intestazione, Riferimenti?, Descrizione)> <!ATTLIST Segnatura versione NMTOKEN #FIXED "%datapubblicazione;" xml:lang NMTOKEN #FIXED "it" > <!-- Intestazione L'elemento Intestazione e` obbligatorio nella Segnatura Informatica e contiene gli elementi essenziali di identificazione e caratterizzazione amministrativa del Messaggio Protocollato. L'elemento Intestazione contiene anche le informazioni relative alla trasmissione del messaggio, sia dal punto di vista telematico che amministrativo. <!ELEMENT Intestazione (Identificatore, PrimaRegistrazione?, OraRegistrazione?, Origine, Destinazione+, PerConoscenza, Risposta?, Riservato?, InterventoOperatore?, RiferimentoDocumentiCartacei?, RiferimentiTelematici?, Oggetto, Classifica, Note?)> <!-- Identificatore Un elemento Identificatore contiene le informazioni identificative minime di protocollo, ai sensi del d.p.r. 445/2000. L'elemento Identificatore inserito al primo livello nell'intestazione riporta i dati dell'identificatore di Registrazione del Messaggio Protocollato. Nelle altre posizioni in cui viene utilizzato nella DTD esso riporta i dati di un generico Identificatore di Protocollo il cui significato e` desumibile dal contesto. Regole aggiuntive - un CodiceAmministrazione e` codificato mediante i caratteri previsti dalla specifica ISO 646 (US-ASCII a 7 bit) ed e` composto di lettere maiuscole ([A-Z]), lettere minuscole ([a-z]), cifre decimali ([0-9]) e dal carattere '-'; - un CodiceAmministrazione deve avere una lunghezza non superiore a 8 caratteri. - un CodiceAOO e` codificato mediante i caratteri previsti dalla specifica ISO 646 (US-ASCII a 7 bit) ed e` composto da una sequenza di lettere maiuscole ([A-Z]), lettere minuscole ([a-z]), cifre decimali ([0-9]) e dal carattere '-'; - un CodiceAOO deve avere una lunghezza non superiore a 8 caratteri. - il NumeroRegistrazione deve essere sempre formato da sette cifre decimali, con giustificazione mediante zeri (e.g. il numero 1 deve essere codificato come ); - la DataRegistrazione deve essere in formato ISO 8601 esteso (i.e. aaaa-mm-gg). Pag. 55 di 105

57 Regole di corrispondenza - il CodiceAmministrazione deve essere un codice valido ai sensi del d.p.r. 445/2000 e del d.p.c.m 31/10/2000; - il CodiceAOO deve corrispondere ad un codice valido attribuito dalla amministrazione di cui la AOO fa parte (come previsto dal d.p.r. 445/2000 e dal d.p.c.m 31/10/2000). <!ELEMENT Identificatore (CodiceAmministrazione, CodiceAOO, NumeroRegistrazione, DataRegistrazione)> <!ELEMENT CodiceAmministrazione (#PCDATA)> <!ELEMENT CodiceAOO (#PCDATA)> <!ELEMENT NumeroRegistrazione (#PCDATA)> <!ELEMENT DataRegistrazione (#PCDATA)> <!-- PrimaRegistrazione La PrimaRegistrazione si riferisce all'identificatore di Registrazione primario, cioe` attribuito per primo ad un Documento Protocollato che viene ritrasmesso piu` volte. Regole di corrispondenza - la PrimaRegistrazione deve essere specificata solo se non coincide con l'identificatore del Messaggio Protocollato. <!ELEMENT PrimaRegistrazione (Identificatore)> <!-- OraRegistrazione L'elemento OraRegistrazione riporta l'ora di creazione della Registrazione di Protocollo del Messaggio Protocollato. L'attributo tempo descrive il tipo di misurazione temporale utilizzata. Il token "locale" indica il tempo locale non sincronizzato del sistema dove la Registrazione di Protocollo e` stata creata. Il token "rupa" indica il tempo sincronizzato di RUPA. Regole aggiuntive - l'oraregistrazione deve essere in formato ISO 8601 esteso (i.e. hh:mm:ss[,ddd] - ad esempio 16:09:19,710; si noti che l'indicazione dei millisecondi e` opzionale). <!ELEMENT OraRegistrazione (#PCDATA)> <!ATTLIST OraRegistrazione tempo (locale rupa NMTOKEN) "locale" > <!-- Origine L'elemento Origine riporta i dati telematici ed amministrativi del mittente del Messaggio Protocollato. Pag. 56 di 105

58 Regole di corrispondenza - la descrizione dell'origine deve essere specificata nel modo piu` completo possibile. <!ELEMENT Origine (IndirizzoTelematico, Mittente)> <!-- Destinazione Ciascun elemento Destinazione contiene i dati telematici ed amministrativi di un singolo destinatario del Messaggio Protocollato. L'attributo confermaricezione indica la richiesta di invio di una Conferma di Ricezione da parte del destinatario. Regole di corrispondenza - se la Destinazione del Messaggio Protocollato e` una pubblica amministrazione l'indirizzotelematico indicato deve corrispondere a quello della casella istituzionale della AOO destinataria, ai sensi dell'art. 15 comma 3 del d.p.c.m. 31/10/00. <!ELEMENT Destinazione (IndirizzoTelematico, Destinatario)> <!ATTLIST Destinazione confermaricezione (si no) "no" > <!-- PerConoscenza Ciascun elemento PerConoscenza contiene i dati telematici ed amministrativi di un destinatario per conoscenza del Messaggio Protocollato. L'attributo confermaricezione indica la richiesta di invio di una Conferma di Ricezione da parte del destinatario per conoscenza. Regole di corrispondenza - se la destinazione PerConoscenza del Messaggio Protocollato e` una pubblica amministrazione l'indirizzotelematico indicato deve corrispondere a quello della casella istituzionale della AOO destinataria. <!ELEMENT PerConoscenza (IndirizzoTelematico, Destinatario)> <!ATTLIST PerConoscenza confermaricezione (si no) "no" > <!-- Risposta L'elemento Risposta indica un indirizzo telematico da utilizzarsi per le risposte automatiche (i.e. ConfermaRicezione, NotificaEccezione, Pag. 57 di 105

59 AggiornamentoConferma, AnnullamentoProtocollazione). Tale indirizzo viene specificato solo se non coincidente con l'indirizzo telematico indicato nell'elemento Origine. Regole di corrispondenza - dato che Conferme di Ricezione, Messaggi di Notifica di Eccezione, Aggiornamenti di Conferma, Annullamenti di Protocollazione non sono soggetti a protocollazione, l'indirizzotelematico indicato nell'elemento Risposta puo` essere diverso da quello di una casella istituzionale. <!ELEMENT Risposta (IndirizzoTelematico)> <!-- IndirizzoTelematico Un IndirizzoTelematico contiene un indirizzo, ad esempio di posta elettronica, utilizzato per la trasmissione telematica. L'attributo tipo di indirizzo telematico specificato. Il token "smtp" indica un indirizzo SMTP, il token "uri" indica la specifica di un indirizzo telematico tramite la sintassi delle URI. Il formato libero (NMTOKEN) e` da utilizzarsi per l'indicazione di tipo di sistemi di messaging diversi da quelli utilizzati su internet (e.g. sistemi proprietari). Regole aggiuntive - il contenuto dell'elemento IndirizzoTelematico di tipo "smtp" deve essere sintatticamente conforme a quanto previsto dalla specifica pubblica RFC 822; - il contenuto dell'elemento IndirizzoTelematico di tipo "uri" deve essere sintatticamente conforme a quanto previsto dalla specifica pubblica RFC Regole di corrispondenza - non e` ammesso l'uso del tipo "uri" per l'indicazione di un indirizzo SMTP (i.e. tramite una URI "mailto:"); - qualunque sia il tipo di protocollo di trasporto telematico adottato, la specifica di un IndirizzoTelematico deve essere completa e non ambigua. <!ELEMENT IndirizzoTelematico (#PCDATA)> <!ATTLIST IndirizzoTelematico tipo (smtp uri NMTOKEN) "smtp" note CDATA #IMPLIED > <!-- InterventoOperatore L'elemento InterventoOperatore esprime la richiesta di intervento di un Operatore ai fini della protocollazione e/o smistamento del Pag. 58 di 105

60 Messaggio Protocollato (invece di una protocollazione e/o smistamento che potrebbe essere automatica). Puo` contenere un testo che descrive i motivi della richiesta. <!ELEMENT InterventoOperatore (#PCDATA)> <!-- Riservato L'elemento Riservato esprime la richiesta di trattamento riservato del Messaggio Protocollato. Puo` contenere un testo che descrive i motivi della richiesta <!ELEMENT Riservato (#PCDATA)> <!-- RiferimentoDocumentiCartacei L'elemento RiferimentoDocumentiCartacei e` indice della presenza nel Messaggio Protocollato di riferimenti esterni a Documenti Cartacei e quindi della necessita` di effettuare una validazione manuale della corrispondenza tra i dati riportati nella Segnatura Informatica sui documenti in questione. <!ELEMENT RiferimentoDocumentiCartacei EMPTY> <!-- RiferimentiTelematici L'elemento RiferimentiTelematici e` indice della presenza nel Messaggio Protocollato di riferimenti esterni a Documenti Informatici dislocati in una posizione remota (e.g. repositorio condiviso). La collocazione effettiva dei Documenti Informatici e` indicata all'interno dell'elemento Documento. <!ELEMENT RiferimentiTelematici EMPTY> <!-- Oggetto L'elemento Oggetto contiene la descrizione testuale dell'oggetto del messaggio. La descrizione testuale contenuta nell'elemento Oggetto dovrebbe essere significativa e dovrebbe avere una lunghezza congrua, Pag. 59 di 105

61 tipicamente almeno 30 caratteri. <!ELEMENT Oggetto (#PCDATA)> <!-- Classifica L'elemento Classifica contiene l'indicazione di una Classifica. Inserito al primo livello nell'intestazione, l'elemento Classifica indica la Classifica del Messaggio Protocollato. Nelle altre posizioni in cui viene utilizzato nella DTD tale elemento indica una Classifica attribuibile all'elemento che ne costituisce il contesto. <!ELEMENT Classifica (CodiceAmministrazione?, CodiceAOO?, Denominazione?, Livello+)> <!ELEMENT Denominazione (#PCDATA)> <!ELEMENT Livello (#PCDATA)> <!ATTLIST Livello nome CDATA #IMPLIED > <!-- Identificativo Un Identificativo e` un codice che consente di identificare univocamente un'entita` dal punto di vista amministrativo La forma dell'identificativo puo` essere stabilita dalla amministrazione che lo attribuisce. Un Identificativo deve essere compatibile con la formazione di un identificativo telematico come URI, cioe` Uniform Resource Identifier (RFC 1738). Regole aggiuntive - un Identificativo e` codificato mediante i caratteri previsti dalla specifica ISO 646 (US-ASCII a 7 bit) ed e` composto da una sequenza di lettere maiuscole ([A-Z]), lettere minuscole ([a-z]), cifre decimali ([0-9]) e dai caratteri '.', '-' e '_'. - un Identificativo deve avere una lunghezza non superiore a 32 caratteri. <!ELEMENT Identificativo (#PCDATA)> <!-- Note Un elemento Note contiene delle note esplicative in formato testuale. All'interno dell'elemento Note non e` consentito l'inserimento di testo altrimenti strutturato, ad esempio un frammento di codice XML. Pag. 60 di 105

62 <!ELEMENT Note (#PCDATA)> <!-- Mittente La descrizione di un mittente o destinatario istituzionale in forma estesa e strutturata si configura come la descrizione di un percorso all'interno di una struttura organizzativa. Il formato di descrizione di tale percorso e` compatibile con lo schema dell'indice delle pubbliche amministrazioni previsto dal d.p.c.m. 31/10/00. E` comunque prevista la possibilita` di descrizioni non strutturate, cioe` interamente testuali, di parte o di tutti gli elementi coinvolti al fine di garantire la compatibilita` con sistemi informatici realizzati che utilizzano dati in forma non strutturata o in una forma strutturata non compatibile con quella descritta. Se utilizzata, la descrizione testuale non deve tuttavia contenere forme di strutturazione surrettizia (e.g. uso di "comma-separated values"). Il ricorso a descrizioni testuali non strutturate andrebbe evitato qualora possibile. L'elemento Mittente descrive il mittente del Messaggio Protocollato. Regole di corrispondenza - la Denominazione della AOO mittente deve corrispondere al CodiceAOO indicato nell'identificatore del Messaggio Protocollato; - la Denominazione della AOO mittente deve corrispondere all'indirizzotelematico della casella istituzionale indicata nel Mittente. <!ELEMENT Mittente (Amministrazione, AOO)> <!-- Destinatario L'elemento Destinatario descrive un destinatario del Messaggio Protocollato. Regole aggiuntive - la descrizione del Destinatario deve includere come minimo la Denominazione della Amministrazione oppure una Denominazione generica oppure il riferimento ad una Persona fisica. Regole di corrispondenza - qualora specificata, la Denominazione della AOO destinataria deve corrispondere all'indirizzotelematico della casella istituzionale indicata nel Mittente. Si noti che la specifica del Destinatario e` opzionale e pertanto l'inserimento di un simile elemento privo di informazioni significative e` inutile. Pag. 61 di 105

63 <!ELEMENT Destinatario (((Amministrazione, AOO?) (Denominazione, Persona) Persona+), IndirizzoTelematico?, Telefono, Fax, IndirizzoPostale?)> <!-- Amministrazione Un elemento Amministrazione rappresenta l'elemento radice della descrizione estesa e strutturata di un mittente o destinatario istituzionale, inteso come percorso all'interno di una struttura organizzativa. Regole aggiuntive - il CodiceAmministrazione dovrebbe essere incluso solo quando l'elemento Amministrazione compare nel contesto di un elemento Destinatario. <!ELEMENT Amministrazione (Denominazione, CodiceAmministrazione?, (UnitaOrganizzativa ((Ruolo Persona), IndirizzoPostale, IndirizzoTelematico, Telefono, Fax)))> <!-- UnitaOrganizzativa Un elemento UnitaOrganizzativa rappresenta un elemento nel percorso che costituisce della descrizione di un indirizzo. L'attributo tipo descrive il tipo di unita` organizzativa. Un'unita` organizzativa temporanea potrebbe essere infatti istituita in una amministrazione a fronte di eventi speciali o per emergenza. <!ELEMENT UnitaOrganizzativa (Denominazione, Identificativo?, (UnitaOrganizzativa ((Ruolo Persona), IndirizzoPostale, IndirizzoTelematico, Telefono, Fax)))> <!ATTLIST UnitaOrganizzativa tipo (permanente temporanea) "permanente" > <!-- AOO Un elemento AOO specifica la Denominazione ed eventualmente il CodiceAOO. Non e` necessario che tale specifica contenga altre informazioni dato il contesto in cui questo elemento puo` essere inserito. Regole aggiuntive - il CodiceAOO dovrebbe essere incluso solo quando l'elemento AOO compare nel contesto di un elemento Destinatario. Pag. 62 di 105

64 <!ELEMENT AOO (Denominazione, CodiceAOO?)> <!-- Ruolo Un elemento Ruolo contiene la specifica del ruolo ricoperto da una persona fisica. <!ELEMENT Ruolo (Denominazione, Identificativo?, Persona?)> <!-- Persona Un elemento Persona contiene la specifica di un riferimento ad una persona fisica. <!ELEMENT Persona ((Denominazione (Nome?, Cognome, Titolo?, CodiceFiscale?)), Identificativo?)> <!ATTLIST Persona id ID #IMPLIED rife IDREF #IMPLIED > <!ELEMENT Nome (#PCDATA)> <!ELEMENT Cognome (#PCDATA)> <!ELEMENT Titolo (#PCDATA)> <!ELEMENT CodiceFiscale (#PCDATA)> <!-- IndirizzoPostale Un IndirizzoPostale indica tipicamente la sede di un'unita` organizzativa o amministrazione o l'indirizzo di un cittadino o altro ente esterno alla pubblica amministrazione. L'attributo dug (i.e. Denominazione Urbanistica Generica) dell'elemento Toponimo consente di definire informazioni come "Via", "Viale" o "Piazza", mentre il contenuto testuale dell'elemento ne indica il toponimo (e.g. "Verdi", "XX Settembre"). Regole aggiuntive - il valore dell'attributo opzionale codiceistat dell'elemento Comune deve essere formato da sei cifre decimali con giustificazione mediante zeri(e.g. "018190"); - il valore testuale dell'elemento opzionale Nazione indica la codifica internazionale della nazione specificata nell'indirizzo in formato standard ISO Alpha-2. Qualora l'elemento non sia presente o il suo valore non specificato la nazione va interpretata come Italia identificata dal codice "IT"; la lunghezza per questo elemento e' pari a 2 caratteri; - il valore testuale dell'elemento Provincia deve essere formato da due lettere maiuscole (e.g. "RM" per Roma, "PA" per Palermo, etc.); Pag. 63 di 105

65 - il valore testuale dell'elemento Civico qualora si riferisca ad un indirizzo privo del numero civico deve contenere l'espressione "snc". <!ELEMENT IndirizzoPostale (Denominazione (Toponimo, Civico, CAP, Comune, Provincia, Nazione?))> <!ELEMENT Toponimo (#PCDATA)> <!ATTLIST Toponimo dug CDATA #IMPLIED > <!ELEMENT Civico (#PCDATA)> <!ELEMENT CAP (#PCDATA)> <!ELEMENT Comune (#PCDATA)> <!ATTLIST Comune codiceistat CDATA #IMPLIED > <!ELEMENT Provincia (#PCDATA)> <!ELEMENT Nazione (#PCDATA)> <!ELEMENT Telefono (#PCDATA)> <!ATTLIST Telefono note CDATA #IMPLIED > <!ELEMENT Fax (#PCDATA)> <!ATTLIST Fax note CDATA #IMPLIED > <!-- Riferimenti L'elemento opzionale Riferimenti contiene i riferimenti ad altri Messaggi Protocollati e/o Contesti Procedurali (o in particolare a Procedimenti). <!ELEMENT Riferimenti (Messaggio ContestoProcedurale Procedimento)+> <!-- Messaggio Un elemento Messaggio indica un riferimento ad un Messaggio. Regole di corrispondenza - nella indicazione di un riferimento ad un Messaggio Protocollato deve essere usato l'identificatore attribuito dalla AOO mittente; - deve anche essere specificato l'identificatore di prima registrazione, come definito precedentemente, se e solo se esso non coincide con il precedente. <!ELEMENT Messaggio ((Identificatore DescrizioneMessaggio), PrimaRegistrazione?)> <!-- Pag. 64 di 105

66 DescrizioneMessaggio Un elemento DescrizioneMessaggio descrive un riferimento ad un Messaggio non protocollato. Regole di corrispondenza - l'elemento DescrizioneMessaggio deve essere utilizzato solo per i riferimenti a Messaggi non protocollati; - la DescrizioneMessaggio riporta i dati identificativi di trasmissione (e.g. i dati SMTP). <!ELEMENT DescrizioneMessaggio (#PCDATA)> <!-- ContestoProcedurale Un elemento ContestoProcedurale indica un riferimento ad un Contesto Procedurale ovvero lo svolgimento di un generico complesso di attivita` amministrative in qualche modo collegate. Un Contesto procedurale e` pertanto un elemento aggregante di attivita` svolte all'interno di una o piu` Unita` Organizzative associate alla stessa AOO; le azioni svolte nell'ambito di un Contesto Procedurale sono finalizzate alla produzione di un risultato, finale o intermedio, che ha valore anche all'esterno delle Unita` Organizzative coinvolte. Regole aggiuntive - la DataAvvio deve essere in formato ISO 8601 esteso (i.e. aaaa-mm-gg - ad esempio ). Regole di corrispondenza - la forma dell'identificativo puo` essere stabilita dalla AOO che lo attribuisce, tuttavia il contenuto di tale elemento deve essere sufficiente per l'identificazione univoca del corrispondente Contesto Procedurale; - anche il TipoContestoProcedurale puo` essere stabilito dalla AOO che attribuisce l'identificativo; tuttavia non sono ammessi tipi che corrispondono a Procedimenti (ai sensi della l. 241/90), per cui si deve utilizzare un elemento Procedimento. <!ELEMENT ContestoProcedurale (CodiceAmministrazione, CodiceAOO, Identificativo, TipoContestoProcedurale?, Oggetto?, Classifica, DataAvvio?, Note?)> <!ATTLIST ContestoProcedurale id ID #IMPLIED rife IDREF #IMPLIED > <!ELEMENT TipoContestoProcedurale (#PCDATA)> <!ELEMENT DataAvvio (#PCDATA)> <!-- Procedimento Un elemento Procedimento indica un riferimento ad un Procedimento Pag. 65 di 105

67 (ai sensi della l. 241/90) ed e` formalmente identico all'elemento ContestoProcedurale, con l'aggiunta degli elementi Responsabile e DataTermine. Regole aggiuntive - la DataTermine deve essere in formato ISO 8601 esteso (i.e. aaaa-mm-gg). Regole di corrispondenza - la forma dell'identificativo puo` essere stabilita dalla AOO che lo attribuisce, tuttavia il contenuto di tale elemento deve essere sufficiente per l'identificazione univoca del corrispondente Procedimento. <!ELEMENT Procedimento (CodiceAmministrazione, CodiceAOO, Identificativo, TipoProcedimento?, Oggetto?, Classifica, Responsabile?, DataAvvio?, DataTermine?, Note?)> <!ATTLIST Procedimento id ID #IMPLIED rife IDREF #IMPLIED > <!ELEMENT TipoProcedimento (#PCDATA)> <!ELEMENT Responsabile (Persona)> <!ELEMENT DataTermine (#PCDATA)> <!-- Descrizione L'elemento opzionale Descrizione contiene la descrizione strutturata del contenuto del Messaggio Protocollato. L'elemento Documento si riferisce al Documento primario del Messaggio protocollato se questo viene inviato da una AOO di una amministrazione ad una AOO di una diversa amministrazione. In tal caso il Documento deve essere sottoscritto secondo le norme stabilite dal d.p.r. 445/2000. I Documenti primari riguardanti scambi tra AOO della stessa amministrazione possono essere indicati nell'elemento Documento o, in alternativa, nell'elemento TestoDelMessaggio. Se indicati nell' elemento Documento possono eventualmente essere sottoscritti secondo le modalità espresse nell'art. 5 della delibera AIPA 51/2000. Regole aggiuntive - l'elemento Descrizione deve essere presente in una Segnatura Informatica, in quanto permette di interpretare la struttura che rappresenta il Messaggio Protocollato. <!ELEMENT Descrizione ((Documento TestoDelMessaggio), Allegati?, Note?)> <!-- Pag. 66 di 105

68 Documento Un elemento Documento specifica un riferimento ad un Documento che costituisce parte integrante del Messaggio Protocollato. L'indicazione dei riferimento a Documenti rappresenta un aspetto cruciale per l'efficacia delle indicazioni tecniche specifiche qui contenute. Si possono avere tre tipi di riferimenti, definiti dal valore dell'attributo tiporiferimento di Documento: 1) "MIME"/"DIME" riferimento a un Documento Informatico contenuto nella struttura che costituisce il messaggio; 2) "telematico" riferimento esterno a un Documento Informatico comunque reperibile per altra via (e.g. in un repositorio condiviso); 3) "cartaceo" riferimento esterno a un Documento Cartaceo trasmesso per via tradizionale (e.g. spedizione postale o tramite posta interna). Gli attributi id e nome di Documento caratterizzano dal punto vista tecnico il riferimento al Documento effettivo. Il significato degli attributi varia a seconda del tipo di riferimento. In particolare: - Per i riferimenti di tipo "MIME"/"DIME", il valore dell'attributo nome corrisponde al valore del parametro filename dell'attributo Content-Disposition o, in subordine, al valore del parametro name dell'attributo Content-Type specificato per una body part della struttura. L'attributo id puo` essere utilizzato allo scopo di definire un identificatore univoco del riferimento nell'ambito della struttura XML. - Nel caso di un riferimento di tipo "telematico" l'attributo id puo` essere utilizzato allo scopo di definire un identificatore univoco del riferimento nell'ambito della struttura XML. - Nel caso di un riferimento di tipo "cartaceo" il valore dell'attributo id corrisponde al valore dell'identificativo del Documento Cartaceo e deve essere sempre specificato per i Documenti Cartacei non protocollati, che non hanno quindi un Identificatore di Registrazione riportato nell'elemento PrimaRegistrazione. Nel caso di un Documento Cartaceo privo di identificativo, l'attributo id puo` essere specificato al solo scopo di definire un identificatore univoco del riferimento nell'ambito della struttura XML. Viceversa, l'attributo nome non ha alcun significato e non deve quindi essere utilizzato. L'attributo tipomime va utilizzato solo per riferimenti a Documenti Informatici. Regole aggiuntive Pag. 67 di 105

69 - devono essere rispettate le regole sopra descritte per l'uso degli attributi di Documento. Regole di corrispondenza - devono essere rispettate le regole di corrispondenza sopra descritte per il significato dei valori degli attributi di Documento. <!ELEMENT Documento ((CollocazioneTelematica, Impronta?)?, TitoloDocumento?, PrimaRegistrazione?, TipoDocumento?, Oggetto?, Classifica, NumeroPagine?, Note?)> <!ATTLIST Documento id ID #IMPLIED rife IDREF #IMPLIED nome CDATA #IMPLIED tipomime CDATA #IMPLIED tiporiferimento (MIME DIME telematico cartaceo) "MIME" > <!-- TitoloDocumento L'elemento opzionale TitoloDocumento contiene l'indicazione del titolo esteso del documento a scopo amministrativo. <!ELEMENT TitoloDocumento (#PCDATA)> <!-- TipoDocumento L'elemento opzionale TipoDocumento contiene l'indicazione del tipo di documento dal punto di vista amministrativo (e.g. circolare, nota informativa). <!ELEMENT TipoDocumento (#PCDATA)> <!-- NumeroPagine L'elemento opzionale NumeroPagine contiene l'indicazione del numero delle pagine che compongono il documento <!ELEMENT NumeroPagine (#PCDATA)> <!-- CollocazioneTelematica, Impronta Un riferimento esterno di tipo "telematico" comporta la specificazione di un riferimento esterno come URI, cioe` Uniform Pag. 68 di 105

70 Resource Identifier (RFC 1738), all'interno di un elemento di tipo CollocazioneTelematica. Ad un riferimento esterno di questo tipo puo` anche essere associata un'impronta. Regole aggiuntive - un elemento CollocazioneTelematica ed, eventualmente, Impronta deve essere presente in un Documento se e solo se il valore dell'attributo tiporiferimento e` "telematico". - il contenuto dell'elemento CollocazioneTelematica deve essere sintatticamente conforme a quanto previsto dalla specifica pubblica RFC Regole di corrispondenza - l'impronta, se presente, deve corrispondere al Documento Informatico indicato nell'elemento CollocazioneTelematica. Si assume comunque che l'accettazione in ingresso di Messaggi Protocollati che contengono riferimenti esterni a Documenti Informatici costituisca una scelta di gestione da parte dell'aoo ricevente. Pertanto, tale accettazione potrebbe essere limitata ad alcuni mittenti istituzionali o negata del tutto. Di quest'aspetto deve essere contenuta indicazione nel manuale di gestione della AOO. <!ELEMENT CollocazioneTelematica (#PCDATA)> <!ELEMENT Impronta (#PCDATA)> <!ATTLIST Impronta algoritmo CDATA #FIXED "SHA-1" codifica CDATA #FIXED "base64" > <!-- TestoDelMessaggio La presenza dell'elemento TestoDelMessaggio nella Segnatura Informatica indica che il Testo del Messaggio e` da considerarsi dal punto di vista formale come il Documento primario e deve essere considerato nella Registrazione di Protocollo. In assenza di tale indicazione il Testo del Messaggio viene semplicemente ignorato. La possibilità di considerare il Testo del Messaggio come documento primario e` consentita solo per scambi tra AOO di una stessa amministrazione. Nel caso di scambi tra AOO appartenenti ad amministrazioni diverse il Testo del Messaggio viene ignorato ai fini della protocollazione. <!ELEMENT TestoDelMessaggio EMPTY> <!ATTLIST TestoDelMessaggio id CDATA #IMPLIED tipomime CDATA #IMPLIED tiporiferimento NMTOKEN #FIXED "MIME" > <!-- Pag. 69 di 105

71 Allegati L'elemento opzionale Allegati contiene una lista di elementi Documento o Fascicolo. Lo scopo di tale lista e` quello di fornire una descrizione, possibilmente strutturata, dei Documenti allegati al Documento primario. Piu` precisamente, il contenuto dell'elemento Allegati ha due scopi: 1) descrivere l'elenco dei Documenti allegati; 2) descrivere la struttura dal punto di vista amministrativo del Messaggio Protocollato, in termini di organizzazione in Fascicoli dei Documenti inclusi. E` quindi anche possibile che, nella descrizione della struttura, si faccia riferimento piu` volte allo stesso Documento, incluso il Documento primario (e.g. Documenti logicamente appartenenti a piu` di un Fascicolo). Regole di corrispondenza - la citazione multipla di uno stesso Documento nella descrizione strutturale contenuta in Allegati deve essere resa utilizzando il meccanismo XML degli ID/IDREF. In altri termini, il riferimento effettivo al Documento deve essere specificato una sola volta e accompagnato dalla definizione dell'attributo id di Documento; gli altri riferimenti vengono specificati utilizzando l'attributo rife. Si veda in proposito anche la definizione dell'elemento Documento descritta precedentemente. <!ELEMENT Allegati (Documento Fascicolo)+> <!-- Fascicolo Un elemento Fascicolo descrive l'aggregazione di Documenti o altri Fascicoli. <!ELEMENT Fascicolo (CodiceAmministrazione?, CodiceAOO?, Oggetto?, Identificativo?, Classifica, Note?, (Documento Fascicolo)+)> <!ATTLIST Fascicolo id ID #IMPLIED rife IDREF #IMPLIED > <!-- ConfermaRicezione In generale, un Messaggio di Conferma di Ricezione contiene un Documento XML avente una ConfermaRicezione come "ROOT ELEMENT". Un elemento ConfermaRicezione riporta l'identificatore di protocollo attribuito al Messaggio dal ricevente e la descrizione del MessaggioRicevuto. Per gli attributi di ConfermaRicezione valgono le stesse Pag. 70 di 105

72 considerazioni svolte per gli attributi dell'elemento Segnatura. <!ELEMENT ConfermaRicezione (Identificatore, MessaggioRicevuto, Riferimenti?, Descrizione?)> <!ATTLIST ConfermaRicezione versione NMTOKEN #FIXED "%datapubblicazione;" xml:lang NMTOKEN #FIXED "it" > <!-- MessaggioRicevuto L'elemento MessaggioRicevuto contiene la descrizione del messaggio ricevuto. L'identificatore corrisponde alla registrazione di protocollo in uscita da parte del mittente. Regole di corrispondenza - l'elemento DescrizioneMessaggio deve essere utilizzato solo per confermare la ricezione di Messaggi non protocollati. <!ELEMENT MessaggioRicevuto ((Identificatore, PrimaRegistrazione?) DescrizioneMessaggio)> <!-- AggiornamentoConferma In generale, un Messaggio di Aggiornamento di Conferma contiene un Documento XML avente una AggiornamentoConferma come "ROOT ELEMENT". Un elemento AggiornamentoConferma contiene un aggiornamento di una ConfermaRicezione inviata in precedenza. L'Identificatore corrisponde alla registrazione di protocollo in ingresso da parte del ricevente. Per gli attributi di AggioranmentoConferma valgono le stesse considerazioni svolte per gli attributi dell'elemento Segnatura. <!ELEMENT AggiornamentoConferma (Identificatore, MessaggioRicevuto, Riferimenti?, Descrizione?)> <!ATTLIST AggiornamentoConferma versione NMTOKEN #FIXED "%datapubblicazione;" xml:lang NMTOKEN #FIXED "it" > <!-- NotificaEccezione In generale, un Messaggio di Notifica di Eccezione contiene un Documento XML avente un NotificaEccezione come "ROOT ELEMENT". Un elemento NotificaEccezione riporta la descrizione del MessaggioRicevuto e la descrizione testuale del Motivo che ha generato l'eccezione. Per gli attributi di NotificaEccezione valgono le stesse considerazioni svolte per gli attributi dell'elemento Segnatura. Pag. 71 di 105

73 Regole di corrispondenza - l'elemento Identificatore deve contenere l'identificatore di protocollo attribuito al Messaggio dal ricevente; qualora non sia stato possibile protocollare in ingresso il Messaggio Ricevuto l'elemento Identificatore non deve essere incluso; - la descrizione del Motivo deve essere specifica e direttamente associabile alla causa che ha generato l'eccezione. <!ELEMENT NotificaEccezione (Identificatore?, MessaggioRicevuto, Motivo)> <!ATTLIST NotificaEccezione versione NMTOKEN #FIXED "%datapubblicazione;" xml:lang NMTOKEN #FIXED "it" > <!ELEMENT Motivo (#PCDATA)> <!-- AnnullamentoProtocollazione In generale, un Messaggio di Annullamento Protocollazione contiene un Documento XML avente un AnnullamentoProtocollazione come "ROOT ELEMENT". Un elemento AnnullamentoProtocollazione contiene l'identificatore della registrazione annullata e gli estremi del corrispondente provvedimento amministrativo. Per gli attributi di AnnullamentoProtocollazione valgono le stesse considerazioni svolte per gli attributi dell'elemento Segnatura. <!ELEMENT AnnullamentoProtocollazione (Identificatore, Motivo, Provvedimento)> <!ATTLIST AnnullamentoProtocollazione versione NMTOKEN #FIXED "%datapubblicazione;" xml:lang NMTOKEN #FIXED "it" > <!ELEMENT Provvedimento (#PCDATA)> Pag. 72 di 105

74 5.2 DTD messaggi di notifica protocollo Figura 19 - Schema del DTD Notifica Protocollo <?xml version="1.0" encoding="utf-8"?> <!-- L'elemento "cartcert" identifica la radice <!-- Il DTD viene utilizzato per notificare l'esito dell'invio di un messaggio nel colloquio tra Proxy Applicativo applicativi nella interoperabilità fra Sistemi Informativi Locali nell'ambito della rete regionale toscana <!-- L'attributo "tipo" identifica la tipologia del messaggio di notifica, ed in particolare permette di comunicare la accettazione di un messaggio e la avvenuta consegna, Il tipo "errore_di_consegna" è gestito solo per la ricezione di un messaggio da una AOO esterna ed è comumque prodotto dal dominio <!-- L'attributo "errore" codifica tutti i possibile errori che si possono verificare nell'invio di un messaggio: <!-- "nessuno" = nessun errore <!-- "no-dest" (con tipo="errore_di_consegna") = destinatario errato <!-- "no-conforme" (con tipo="errore_di_consegna" o "non_accettazione") = dtd messaggio originale non conforme <!-- "AOO-errata" (con tipo="non_accettazione ) = AOO destinataria errata o non più abilitata <!ELEMENT cartcert (intestazione, dati)> <!ATTLIST cartcert tipo (accettazione non_accettazione avvenuta_consegna errore_di_consegna) #REQUIRED errore (nessuno no_dest no_conforme AOO_errata errore_generico) "nessuno" > <!-- Intestazione del messaggio originale <!ELEMENT intestazione (mittente)> <!-- Identificativo del mittente del messaggio originale Pag. 73 di 105

75 <!ELEMENT mittente (#PCDATA)> <!-- Dati del messaggio di posta certificata <!ELEMENT dati (idmessaggio, data, consegna, errore-esteso?)> <!-- Identificativo interno del messaggio <!ELEMENT idmessaggio (identificativopa, identificativoaoo, numeroprotocollo, Anno)> <!-- Identificativo della PA <!ELEMENT identificativopa (#PCDATA)> <!-- Identificativo della AOO <!ELEMENT identificativoaoo (#PCDATA)> <!-- Numero di registrazione protocollo <!ELEMENT numeroprotocollo (#PCDATA)> <!-- Anno espresso nel formato AAAA <!ELEMENT Anno (#PCDATA)> <!-- Data/ora di elaborazione del messaggio <!ELEMENT data (giorno, ora)> <!-- Giorno nel formato "aaaa-mm-gg " <!ELEMENT giorno (#PCDATA)> <!-- Ora locale in formato "hh:mm:ss" <!ELEMENT ora (#PCDATA)> <!-- Per le ricevute di consegna e di errore di consegna <!-- Destinatario a cui è stata effettuata/tentata la consegna <!ELEMENT consegna (#PCDATA)> <!-- In caso di errore <!-- Descrizione errore <!ELEMENT errore-esteso (destinatario)> <!-- Dati relativi ai destinatari per i quali non è stato possibile consegnare il messaggio <!ELEMENT destinatario (indirizzo, motivazione?)> <!-- Denominazione del destinatario per il quale non è stato possibile pubblicare il messaggio sul Framework CA (non accettazione) o del destinatario al quale non è stato possibile consegnare il messaggio (errore di consegna) <!ELEMENT indirizzo (#PCDATA)> <!-- Descrizione estesa relativa all'errore che ha causata la mancata accettazione/consegna <!ELEMENT motivazione (#PCDATA)> Pag. 74 di 105

76 5.3 DTD messaggi dell indice regionale delle AOO Vengono riportati di seguito alcuni esempi di DTD per la validazione dei file XML utilizzati per la gestione dell indice regionale delle AOO. Figura 20 - Schema del DTD Messaggi indice regionale delle AOO - Iscrizione AOO <?xml version="1.0" encoding="utf-8"?> Pag. 75 di 105

77 <!-- L'elemento "IscrizioneAOO" identifica la radice <!-- Il DTD viene utilizzato per richiedere l'iscrizione di una AOO -> <!ELEMENT IscrizioneAOO (AOO, description, mail, nomesil?, webservicevisura?, nomeresp?, cognomeresp?, mailresp?, telephonenumberresp?, dataistituzione, datasoppressione?, CAurl?, telephonenumber?, facsimiletelephonenumber?, l?, street?, postalcode?, regione?, provincia?, codiceuff, servizio)> <!-- Codice Area Organizzativa Omogenea <!ELEMENT AOO (#PCDATA)> <!-- Nome esteso amministrazione <!ELEMENT description (#PCDATA)> <!-- Indirizzo istituzionale AOO: indirizzo della casella "istituzionale" di posta elettronica associato alla AOO. <!ELEMENT mail (#PCDATA)> <!--Nome del SIL cui afferisce la AOO <!ELEMENT nomesil (#PCDATA)> <!--URL del webservice per le visure <!ELEMENT webservicevisura (#PCDATA)> <!-- Nome referente <!ELEMENT nomeresp (#PCDATA)> <!-- Cognome referente <!ELEMENT cognomeresp (#PCDATA)> <!-- Indirizzo referente <!ELEMENT mailresp (#PCDATA)> <!-- Numero telefono referente <!ELEMENT telephonenumberresp (#PCDATA)> <!-- Data istituzione nel formato AAAA-MM-GG <!ELEMENT dataistituzione (#PCDATA)> <!-- Data soppressione nel formato AAAA-MM-GG <!ELEMENT datasoppressione (#PCDATA)> <!-- URL CA emittente certificato: collegamento alla Certification Authority per la verifica della validità dei certificati da utilizzare per l'accesso ai servizi protetti <!ELEMENT CAurl (#PCDATA)> <!-- Numero di telefono <!ELEMENT telephonenumber (#PCDATA)> <!-- Numero fax <!ELEMENT facsimiletelephonenumber (#PCDATA)> <!-- Denominazione Città sede legale amministrazione <!ELEMENT l (#PCDATA)> <!-- Indirizzo sede legale amministrazione <!ELEMENT street (#PCDATA)> <!-- CAP sede legale amministrazione <!ELEMENT postalcode (#PCDATA)> <!-- Denominazione Regione di appartenenza sede legale <!ELEMENT regione (#PCDATA)> <!-- Denominazione Provincia di appartenenza sede legale <!ELEMENT provincia (#PCDATA)> <!-- Codice Ufficio <!ELEMENT codiceuff (#PCDATA)> <!-- Dati servizio <!ELEMENT servizio (nomes, descriziones, fruibs, serviziotelematico, mails, telephonenumbers)> <!-- Nome servizio <!ELEMENT nomes (#PCDATA)> <!-- Descrizione servizio <!ELEMENT descriziones (#PCDATA)> <!-- Fruibilità da internet del servizio <!ELEMENT fruibs (#PCDATA)> <!-- URL Servizio <!ELEMENT serviziotelematico (#PCDATA)> <!-- Indirizzo servizio <!ELEMENT mails (#PCDATA)> <!-- Numero di telefono servizio <!ELEMENT telephonenumbers (#PCDATA)> Pag. 76 di 105

78 Figura 21 - Schema del DTD Messaggi indice regionale delle AOO Aggiornamento IAOO Pag. 77 di 105

79 <?xml version="1.0" encoding="utf-8"?> <!-- L'elemento "AggiornamentoIAOO" identifica la radice <!-- Il DTD viene utilizzato per richiedere l'iscrizione di una AOO -> <!ELEMENT AggiornamentoIAOO (AOO, description, mail, nomesil?, webservicevisura?, nomeresp?, cognomeresp?, mailresp?, telephonenumberresp?, dataistituzione, datasoppressione?, CAurl?, telephonenumber?, facsimiletelephonenumber?, l?, street?, postalcode?, regione?, provincia?, codiceuff, servizio)> <!-- Codice Area Organizzativa Omogenea <!ELEMENT AOO (#PCDATA)> <!-- Nome esteso amministrazione <!ELEMENT description (#PCDATA)> <!-- Indirizzo istituzionale AOO: indirizzo della casella "istituzionale" di posta elettronica associato alla AOO. <!ELEMENT mail (#PCDATA)> <!--Nome del SIL cui afferisce la AOO <!ELEMENT nomesil (#PCDATA)> <!--URL del webservice per le visure <!ELEMENT webservicevisura (#PCDATA)> <!-- Nome referente <!ELEMENT nomeresp (#PCDATA)> <!-- Cognome referente <!ELEMENT cognomeresp (#PCDATA)> <!-- Indirizzo referente <!ELEMENT mailresp (#PCDATA)> <!-- Numero telefono referente <!ELEMENT telephonenumberresp (#PCDATA)> <!-- Data istituzione nel formato AAAA-MM-GG <!ELEMENT dataistituzione (#PCDATA)> <!-- Data soppressione nel formato AAAA-MM-GG <!ELEMENT datasoppressione (#PCDATA)> <!-- URL CA emittente certificato: collegamento alla Certification Authority per la verifica della validità dei certificati da utilizzare per l'accesso ai servizi protetti <!ELEMENT CAurl (#PCDATA)> <!-- Numero di telefono <!ELEMENT telephonenumber (#PCDATA)> <!-- Numero fax <!ELEMENT facsimiletelephonenumber (#PCDATA)> <!-- Denominazione Città sede legale amministrazione <!ELEMENT l (#PCDATA)> <!-- Indirizzo sede legale amministrazione <!ELEMENT street (#PCDATA)> <!-- CAP sede legale amministrazione <!ELEMENT postalcode (#PCDATA)> <!-- Denominazione Regione di appartenenza sede legale <!ELEMENT regione (#PCDATA)> <!-- Denominazione Provincia di appartenenza sede legale <!ELEMENT provincia (#PCDATA)> <!-- Codice Ufficio <!ELEMENT codiceuff (#PCDATA)> <!-- Dati servizio <!ELEMENT servizio (nomes, descriziones, fruibs, serviziotelematico, mails, telephonenumbers)> <!-- Nome servizio <!ELEMENT nomes (#PCDATA)> <!-- Descrizione servizio <!ELEMENT descriziones (#PCDATA)> <!-- Fruibilità da internet del servizio <!ELEMENT fruibs (#PCDATA)> <!-- URL Servizio <!ELEMENT serviziotelematico (#PCDATA)> <!-- Indirizzo servizio <!ELEMENT mails (#PCDATA)> <!-- Numero di telefono servizio <!ELEMENT telephonenumbers (#PCDATA)> Pag. 78 di 105

80 Figura 22 - Schema del DTD Messaggi indice regionale delle AOO - Aggiornamento IUO Pag. 79 di 105

81 <?xml version="1.0" encoding="utf-8"?> <!-- L'elemento "AggiornamentoIUO" identifica la radice <!-- Il DTD viene utilizzato per richiedere l'aggiornamento dell'indice delle Unità Organizzative <!ELEMENT AggiornamentoIUO (ou, description, dn?, aooref?, mail?, st?, CAurl?, telephonenumber?, facsimiletelephonenumber?, l?, street?, postalcode?, regione?, provincia?, nomeresp?, cognomeresp?, mailresp?, telephonenumberresp?, servizio)> <!-- Codice ufficio <!ELEMENT ou (#PCDATA)> <!-- Nome ufficio <!ELEMENT description (#PCDATA)> <!-- Codice dell'unità Organizzativa (ufficio, divisione, direzione, dipartimento) di appartenenza <!ELEMENT dn (#PCDATA)> <!-- Codice dell'area Organizzativa Omogena a cui l'unità fa riferimento per il protocollo informatico <!ELEMENT aooref (#PCDATA)> <!-- Indirizzo ufficio: se di posta elettronica certificata deve fare riferimento al dominio di posta elettronica certificata dell'amministrazione - -> <!ELEMENT mail (#PCDATA)> <!-- Casella di posta elettronica certificata: indicare "SI" se l'indirizzo specificato nel campo "mail" fa riferimento ad una casella di posta elettronica certificata, "NO" altrimenti; è obbligatorio se il campo "mail" è valorizzato <!ELEMENT st (#PCDATA)> <!-- URL Certification Autority emittente certificato <!ELEMENT CAurl (#PCDATA)> <!-- Numero di telefono <!ELEMENT telephonenumber (#PCDATA)> <!-- Numero di fax <!ELEMENT facsimiletelephonenumber (#PCDATA)> <!-- Denominazione Città <!ELEMENT l (#PCDATA)> <!-- Indirizzo <!ELEMENT street (#PCDATA)> <!-- CAP sede <!ELEMENT postalcode (#PCDATA)> <!-- Denominazione regione <!ELEMENT regione (#PCDATA)> <!-- Denominazione provincia <!ELEMENT provincia (#PCDATA)> <!-- Nome responsabile <!ELEMENT nomeresp (#PCDATA)> <!-- Cognome responsabile <!ELEMENT cognomeresp (#PCDATA)> <!-- Indirizzo del responsabile <!ELEMENT mailresp (#PCDATA)> <!-- Numero di telefono responsabile <!ELEMENT telephonenumberresp (#PCDATA)> <!-- Dati sul servizio <!ELEMENT servizio (nomes, descriziones, fruibs, serviziotelematico, mails, telephonenumbers)> <!-- Nome servizio <!ELEMENT nomes (#PCDATA)> <!-- Descrizione servizio <!ELEMENT descriziones (#PCDATA)> <!-- Fruibilità da internet del servizio <!ELEMENT fruibs (#PCDATA)> <!-- URL Servizio <!ELEMENT serviziotelematico (#PCDATA)> <!-- Indirizzo referente servizio <!ELEMENT mails (#PCDATA)> <!-- Numero di telefono referente servizio <!ELEMENT telephonenumbers (#PCDATA)> Pag. 80 di 105

82 5.4 DTD messaggio comunicazione non conforme Figura 23 - Schema del DTD di comunicazione non conforme <?xml version="1.0" encoding="utf-8"?> <!-- L'elemento "nonconforme" identifica la radice <!-- Il DTD viene utilizzato per notificare i dati riepilogativi del messaggio di comunicazione non conforme, ovvero di: - un messaggio errato o di posta ordinaria inviato a Sistemi Informativi Locali nell'ambito della rete regionale toscana attraverso un sistema di posta certificata - un messaggio di posta elettronica certificata inviata da un soggetto non pubblico accreditato tramite un intermediario certificato - un messaggio di comunicazione inserito da un soggetto non pubblico accreditato in possesso di un certificato di accesso rilasciato da una autorità di certificazione riconosciuta ed interoperante con la CA di Rete Telematica Regionale Toscana <!ELEMENT nonconforme (intestazione, dati)> <!-- Identitica la natura della comunicazione: - "ANOMTRASP": messaggio errato o di posta ordinaria inviato ad Sistemi Informativi Locali nell'ambito della rete regionale toscana attraverso un sistema di posta certificata - "NONPAINT": da soggetto non pubblico accreditato attraverso un sistema intermediario di posta certificata - "NONPAWEB": da soggetto non pubblico accreditato in possesso di un certificato di accesso rilasciato da una autorità di certificazione riconosciuta ed interoperante con la CA di Rete Telematica Regionale Toscana <!ATTLIST nonconforme tipologia (ANOMTRASP NONPAINT NONPAWEB) #REQUIRED> <!-- Intestazione del messaggio di comunicazione non conforme <!ELEMENT intestazione (mittente)> <!-- Identificativo del mittente del messaggio originale <!ELEMENT mittente (#PCDATA)> <!-- Dati del messaggio di posta certificata <!ELEMENT dati (idmessaggio, data, consegna, errore-esteso?)> <!-- Identificativo del messaggio originale <!ELEMENT idmessaggio (#PCDATA)> Pag. 81 di 105

83 <!-- Identitica se inviare o meno il messaggio di avvenuta protocollazione <!ATTLIST idmessaggio avvenutaprotocollazione (noninvio invio) #REQUIRED> <!-- Data/ora di elaborazione del messaggio <!ELEMENT data (giorno, ora)> <!-- Giorno nel formato "aaaa-mm-gg" <!ELEMENT giorno (#PCDATA)> <!-- Ora locale in formato "hh:mm:ss" <!ELEMENT ora (#PCDATA)> <!-- Destinatario al quale era indirizzato il messaggio originale <!ELEMENT consegna (#PCDATA)> <!-- Descrizione errore <!ELEMENT errore-esteso (#PCDATA)> Pag. 82 di 105

84 5.5 DTD Acknowledgement Figura 24 - Schema del DTD Acknowledgement <?xml version="1.0" encoding="utf-8"?> <!-- L'elemento acknowledgement identifica la radice. Il DTD viene utilizzato per comunicare l'esito dell'invio o ricezione di un busta soap tra Proxy Applicativo e SIL evoluto. <!ELEMENT acknowledgement (codice, descrizione?)> <!-- L'elemento codice identifica il numero di codice di errore dell'invio di un busta soap. <!ELEMENT codice (#PCDATA)> <!-- L'attritbuto esito identifica conferma l'invio di un busta soap nel seguente modo: SI = esito positivo, codice 0 NO = esito negativo i codice sono da definire. <!ATTLIST codice esito (SI NO) "SI"> <!-- L'elemento descrizione identifica conferma l'invio di un busta soap. <!ELEMENT descrizione (#PCDATA)> Pag. 83 di 105

85 5.6 DTD per la visura dei dati di protocollo Figura 25 - Schema del DTD Richiesta Servizi <?xml version="1.0" encoding="utf-8"?> <!-- L'elemento "RichiestaServizio" identifica la radice <!-- Il DTD viene utilizzato per comunica al sistema richiedente le informazioni sulla visura (numero di protocollo di registrazione di un documento su altro sistema) <!ELEMENT RichiestaServizio (Richiedente, Rispondente, Documento)> <!-- Denominazione del sistema informatico locale che avanza la richiste di visura <!ELEMENT Richiedente (#PCDATA)> <!-- Denominazione del sistema informatico locale al quale viene avanzata la richiste di visura <!ELEMENT Rispondente (#PCDATA)> <!-- Dati del documento di protocollo per il quale è avanzata la richiesta di visura <!ELEMENT Documento (protocolloc, protocollos)> <!-- Dati con i quali il documento è stato registrato sul sistema richiedente <!ELEMENT protocolloc (numeroc, dataregistrazionec)> <!-- Numero di protocollo con il quale è stato registrato il documento sul sistema richiedente <!ELEMENT numeroc (#PCDATA)> <!-- Data con la quale è stato registrato il documento di protocollo sul sistema richiedente <!ELEMENT dataregistrazionec (#PCDATA)> <!-- Dati con i quali il documento è stato registrato sul sistema al quale viene avanzata la richiesta di visura <!ELEMENT protocollos (numeros, dataregistraziones)> <!-- Numero di protocollo con il quale è stato registrato il documento sul sistema al quale viene avanzata la richiesta <!ELEMENT numeros (#PCDATA)> <!-- Data con la quale è stato registrato il documento di protocollo sul sistema al quale viene avanzata la richiesta <!ELEMENT dataregistraziones (#PCDATA)> Pag. 84 di 105

86 6. Appendice 2 Buste SOAP 6.1 Busta SOAP di trasporto per messaggi di protocollo La busta SOAP di Trasporto utilizzata per l invio e la richiesta di messaggi tra SIL e Proxy, si compone di più parti che contengono informazioni sui parametri e gli eventuali allegati necessari al corretto invio e ricezione dei messaggi di protocollo riferiti alla circolare AIPA/CR/28 [D5]. Figura 26 - Busta SOAP di trasporto per messaggi di protocollo Pag. 85 di 105