ALLEGATO N.1B AL C.S.A. Piano di azione e.toscana (Lotto 2 - Progetto Interoperabilità del protocollo) CAPITOLATO TECNICO

Transcript

1 ALLEGATO N.1B AL C.S.A. Piano di azione e.toscana (Lotto 2 - Progetto Interoperabilità del protocollo) CAPITOLATO TECNICO 1. Premessa 2. Sezione Prima: Descrizione del contesto generale ed architetturale 3. Sezione Seconda: Descrizione dei servizi oggetto dell'appalto 4. Sezione Terza: Elenco dettagliato dei servizi 5. Sezione Quarta - Specifiche tecniche Giugno

2 PREMESSA Il presente documento è organizzato in quattro distinte sezioni. La prima sezione descrive gli standard tecnologici, l'ambiente architetturale entro il quale i beni ed i servizi offerti dovranno trovare una collocazione corretta ed integrata. La seconda sezione descrive gli elementi della fornitura oggetto del presente appalto. La terza sezione elenca i servizi oggetto dell appalto ed i relativi dati di sintesi. La quarta sezione contiene l analisi preliminare del sistema oggetto di fornitura. 2

3 SEZIONE PRIMA DESCRIZIONE DEL CONTESTO GENERALE E ARCHITETTURALE. Tutti i servizi oggetto della presente gara d'appalto devono operare, ed essere integrati, nell'ambito dell'ambiente architetturale e degli standard tecnologici indicati negli Ambienti di sviluppo adottati dalla Regione Toscana nell'ambito degli standard nel settore delle Tecnologie dell'informazione e Comunicazione (allegato 2). In tale documento allegato 2 sono inoltre indicate: l architettura di cooperazione applicativa adottata dalla Regione Toscana; le modalità per il riconoscimento degli utenti e l'attribuzione dei profili. Le soluzioni proposte e progettate devono dunque aderire a quanto previsto da tale allegato. Di conseguenza la ditta aggiudicataria deve garantire tutte le competenze professionali per gli ambienti tecnologici indicati. Il dominio del problema - quadro normativo. Con il Decreto del Presidente della Repubblica 28 dicembre 2000, n. 445 "Testo unico delle disposizioni legislative e regolamentari in materia di documentazione amministrativa" sono definite le norme di riferimento per la formazione, il rilascio, la tenuta e la conservazione, la gestione, la trasmissione di atti e documenti da parte delle Pubbliche Amministrazioni. Il decreto riprende in un testo unico norme precedenti organizzandole in un articolato complessivo. Relativamente al sistema di gestione informatica dei documenti (capo IV) vengono ripresi i contenuti del precedente Decreto del Presidente della Repubblica 20 ottobre 1998, n Le norme transitorie (art. 78 comma f) confermano la validità delle "Regole tecniche per il protocollo informatico di cui al DPR 428/98" emanate con Decreto Presidente del Consiglio dei Ministri 31 ottobre Uno degli scenari tecnologici descritti dall'art. 15 del DPCM 31 ottobre 2000 "Regole tecniche.. " è stato sviluppato dalla Autorità per l'informatica nella Pubblica Amministrazione con propria circolare 7 maggio 2001, n. AIPA/CR/28. Sullo stesso 3

4 argomento il Centro Tecnico per la Rete Unitaria della Pubblica Amministrazione ha recentemente completato il quadro di riferimento con: Centro Tecnico per la Rete Unitaria della Pubblica Amministrazione, Guida ai servizi di indice delle amministrazioni pubbliche e delle aree organizzative omogenee e Posta Certificata, 18 Dicembre 2002 Centro Tecnico per la Rete Unitaria della Pubblica Amministrazione, Allegato Tecnico alle Linee Guida del Servizio di Trasmissione di Documenti Informatici Mediante Posta Elettronica Certificata, 17 Aprile Diversi scenari tecnologici sono comunque applicabili purché siano garantite le condizioni previste dall'art. 15 comma 8 del DPCM 31 ottobre 2000 "Regole tecniche. Il dominio del problema - ambito d'intervento. Il problema che si intende affrontare è la realizzazione di un insieme di sistemi software volti a fornire ad Amministrazioni Locali / Enti della Regione Toscana aderenti ed interconnesse alla Rete Telematica Regionale Toscana (RTRT) funzioni di interoperabilità applicativa, con riferimento al Protocollo Informatico. La realizzazione deve utilizzare l'infrastruttura ed i servizi della cooperazione applicativa di Regione Toscana. Il sistema deve garantire che: i sistemi di protocollo degli Enti Aderenti possano, mediante interfaccia applicativa, ricevere/trasmettere le registrazioni di protocollo destinate alla interoperabilità l'interfaccia applicativa sia standard (unica) per tutti sistemi di protocollo degli Enti aderenti indipendentemente dal fornitore del singolo sistema l'utilizzo della interfaccia applicativa consenta di trattare in modo differenziato i messaggi di servizio o di anomalia distinguendoli opportunamente dai messaggi primari l'utilizzo della interfaccia applicativa consenta di interoperare sia con gli enti aderenti alla rete telematica regionale sia con le altre AOO presenti sull'indice nazionale. A supporto di questa realizzazione sono inoltre previsti moduli complementari sia relativi al supporto degli Enti Pubblici presenti sul territoriale regionale sia finalizzati alla erogazione di servizi ai cittadini ed alle imprese. L analisi preliminare del Sistema che si intende realizzare è riportata nella sezione quarta. In esso sono individuate nel dettaglio le modalità e le componenti che consentono la risoluzione del problema nell'ambito della infrastruttura di cooperazione applicativa di Regione Toscana. 4

5 SEZIONE SECONDA GLI ELEMENTI DELLA FORNITURA Premettiamo alla descrizione dei singoli elementi oggetto della fornitura, la descrizione del set di strumenti per lo sviluppo ed il controllo dei prodotti e dei servizi che si intendono compresi nella fornitura. Strumenti per lo sviluppo ed il controllo dei prodotti e dei servizi Per avere un completo monitoraggio delle attività di sviluppo, della realizzazione delle procedure/applicazioni e del servizio di assistenza e manutenzione, la Ditta/RTI vincitrice dell appalto dovrà, entro la data di stipula del contratto, produrre, disporre e successivamente applicare/utilizzare durante l esecuzione del presente appalto, un documento specifico con la descrizione completa della struttura e degli strumenti utilizzati a supporto dei prodotti e servizi da contrattualizzare e le modalità di attivazione ed utilizzo di tali servizi. Sviluppo e gestione ciclo di vita delle applicazioni: strumenti per l analisi e il disegno UML strumenti per la realizzazione delle componenti software sistemi e modalità interne di monitoraggio e collaudo delle forniture strumenti per effettuare i test funzionali strumenti per effettuare i test di carico uno strumento di Version and Configuration Management (VCM) formale: che sia integrato con gli strumenti Case, che permetta l'interazione via web anche ai responsabili regionali durante lo sviluppo e realizzazione delle applicazioni per integrare e/o visionare la documentazione, i test, gli eventuali prototipi, etc. etc.), che permetta, via web, la consultazione, la fruizione e la stampa della documentazione relativa alla base dati, ai processi elaborativi, all andamento economico dei progetti, ai manuali tecnici e di utente etc. etc.), Sistema di qualità L azienda dovrà utilizzare un sistema di qualità di erogazione servizi che dovrà documentare le modalità di svolgimento dei vari processi, e dove dovranno essere rispettate le regole definite dagli standard ISO 9001 e 9004 Sistema monitoraggio del servizio di assistenza e manutenzione Dovrà essere previsto un sistema di monitoraggio per rendicontare trimestralmente gli interventi effettuati dal servizio di assistenza e manutenzione,con rilascio di rapporti sia di dettaglio, contenenti le informazioni relative alla chiamata, le modalità di intervento, i tempi dell intervento, la descrizione dell intervento effettuato, sia riassuntivi, contenenti i tempi medi di risposta del servizio, il numero di interventi e le percentuali di risoluzione degli inconvenienti. 5

6 Servizi richiesti Servizio di assistenza e manutenzione: La manutenzione dovrà essere ordinaria e correttiva, e coprirà quanto necessario per: a) la diagnosi e la rimozione delle cause e degli effetti, sia sulle interfacce che sulle base dati; b) la diagnosi e la rimozione dei malfunzionamenti delle procedure/applicazioni e dei programmi in esercizio c) L adeguamento delle componenti applicative a seguito di interventi di aggiornamento tecnologico che si rendano necessari sui componenti software dell infrastruttura di servizi per la cooperazione applicativa. d) l'attività di monitoraggio preventivo, che consiste nel controllo periodico dei sistemi al fine di ottimizzarne il funzionamento ed individuare in via preventiva possibili fonti di malfunzionamento (disallineamenti software, utilizzi non appropriati, configurazioni non ben dimensionate rispetto all'uso, ecc..). Il processo dell'erogazione del servizio di assistenza e manutenzione dovrà essere dettagliato in apposito documento. Regione Toscana dispone di una struttura di Call-center a supporto dei servizi telematici erogati. In conformità a questo modello organizzativo l aggiudicatario, per l erogazione del servizio di assistenza, dovrà intervenire su richiesta di tale Call-center. Il servizio di accettazione delle chiamate deve essere previsto tramite segreteria telefonica/posta elettronica/fax oltre a quello presidiato, con orario minimo dalle ore 9 alle ore di ogni giorno feriale dal lunedì al venerdì, e con orario minimo dalle ore 9 alle ore 14 il sabato. Servizio di supporto all utilizzo delle procedure per gli utenti del sistema La società aggiudicataria dovrà fornire assistenza all utilizzo delle procedure realizzate nell ambito dell appalto. Tale assistenza è rivolta agli utenti. Il servizio dovrà essere erogato telefonicamente con orario minimo dalle ore 9 alle ore di ogni giorno feriale dal lunedì al venerdì, e con orario minimo dalle ore 9 alle ore 14 il sabato. Livelli di servizio Per i servizi sopra indicati vengono specificati i Service Level Agreement (SLA), con le percentuali ed i tempi di intervento, che devono essere rispettati dalla Ditta/RTI aggiudicataria. I tempi sono calcolati tutti dal momento della chiamata fino alla risoluzione dell inconveniente. Servizio di Assistenza e Manutenzione punti a) b) Tempo massimo di intervento e di identificazione del problema Tempo di risoluzione dell inconveniente 4 ore lavorative 95% entro 12 ore lavorative 100% entro 24 ore lavorative Il servizio di assistenza e manutenzione punto c) verrà concordato mediante piano di lavoro concordato tra le parti. 6

7 Supporto Utenti per l utilizzo delle procedure/applicazioni Tempo di risposta e soluzione dell inconveniente 85% entro 10 minuti 95% entro 20 minuti DESCRIZIONE DEI SINGOLI ELEMENTI OGGETTO DELL'APPALTO La fornitura richiesta riguarda : WP01 Progettazione Progetto esecutivo definitivo del Sistema Interoperabilità del protocollo a partire dal documento di analisi preliminare del sistema. In tale attività è inclusa una revisione e consolidamento del documento di specifiche proposto come analisi preliminare in termini di consistenza e completezza dei requisiti incluse le interfacce per attuare il colloquio applicativo fra sistema informativo locale e proxy applicativo protocollo informatico e fra l'infrastruttura di cooperazione applicativa regionale toscana ed i sistemi di posta certificata WP02 Realizzazione Realizzazione dei componenti individuati in seguito e dettagliati nella sezione quarta. La realizzazione si intende inclusiva del primo rilascio previsto nel successivo elenco dei prodotti oggetto dell'appalto e del servizio di assistenza e manutenzione ordinario e correttivo precedentemente descritto per tutta la durata del contratto. WP02/a Componenti a livello di Nodo Applicativo Locale (NAL) Proxy Applicativo Protocollo informatico 1. Modulo per la interoperabilità verso l'agente locale 2. Modulo Interno per il trattamento delle informazioni 3. Modulo per la gestione delle Aree Organizzative Omogenee (AOO) 4. Modulo per interfacciamento con Sistemi Informativi Locali (SIL) 5. Modulo di monitoraggio Le componenti 2 e 4 debbono essere realizzare mediante reingegnerizzazione dei moduli software di cui Regione Toscana ha già realizzato un prototipo funzionante. Le classi utilizzate per tale prototipo sono descritte in coda alla sezione quarta. Le componenti 1, 3 e 5 sono da realizzare integralmente. WP02/b Componenti a livello di Centro Regionale per l'interoperabilità e la Cooperazione Applicativa (CRIC) 1. Modulo per la gestione delle AOO La componente è da realizzare integralmente. WP02/c Componenti a livello di Centro Regionale per l'interoperabilità e la Cooperazione Applicativa (CRIC) 1. Modulo per l'interfacciamento verso sistemi di posta certificata 7

8 La componente è da realizzare integralmente. WP02/d Componenti a livello di Centro Regionale per l'interoperabilità e la Cooperazione Applicativa (CRIC) 1. Modulo per l'utilizzo della interoperabilità da parte di soggetti non pubblici accreditati La componente è da realizzare integralmente. WP02/e Componenti a livello di Centro Regionale per l'interoperabilità e la Cooperazione Applicativa (CRIC) 1. Modulo di monitoraggio complessivo della rete dei proxy Applicativi La componente è da realizzare integralmente. Tutti i moduli ed i prodotti menzionati nel WP02 si intendono corredati di adeguata documentazione ; La documentazione deve essere esaustiva e costantemente aggiornata e comprensiva del reporting di problemi già risolti. In relazione al Proxy applicativo, si specifica che esso deve essere fornito in kit per l installazione sui NAL da parte di una società terza. WP03 Attività di installazione Le componenti del sistema oggetto dell appalto destinate al CRIC o ai nodi periferici dovranno essere installate e configurate dalla aggiudicataria sui sistemi messi a disposizione da Regione Toscana e dagli Enti. Si intendono comprese in tale attività : Assistenza applicativa e sistemistica Recupero dati preesistenti Installazione, configurazione ed avviamento sw Tali attività saranno erogate sulla base di un piano di lavoro concordato tra le parti. L installazione /configurazione delle componenti del sistema oggetto dell appalto destinate ai NAL, è affidata ad un soggetto terzo a cui l azienda aggiudicataria dovrà fornire supporto nelle attività di test, verifica e integrazione di sistema. WP04 Supporto tecnologico La società aggiudicataria dovrà fornire supporto tecnologico agli Enti per l adeguamento alla infrastruttura CART dei propri sistemi informativi locali. WP5 Addestramento ed avviamento all utilizzo La società aggiudicataria dovrà fornire attività addestramento all utilizzo delle procedure e servizi realizzati. Dovrà inoltre supportare gli Enti nella fase di avvio. 8

9 Le attività richieste potranno essere finalizzate anche al supporto alla realizzazione di corsi FAD che Regione Toscana realizzerà ed erogherà con proprie risorse o in ambito di altra fornitura. WP6 Manutenzione evolutiva Consiste nelle modifiche da apportare al software in conseguenza di mutamenti organizzativi, necessità del rispetto di nuove leggi e adeguamenti normativi, nuove esigenze degli utenti, ecc. A seguito di significative modificazioni organizzative, normative europee, nazionali regionali, o tecnologiche l'amministrazione potrà richiedere motivatamente e per iscritto, prima del loro collaudo definitivo, modifiche nella realizzazione del software in termini di: funzionalità; piattaforme tecnologiche; formazione e avviamento. 9

10 SEZIONE TERZA Elenco dei Servizi/prodotti oggetto dell appalto Elenco dettagliato dei servizi da fornire e relativi tempi e modalità di forniture: I servizi/prodotti oggetto del presente appalto, la cui descrizione dettagliata è riportata nella seconda sezione del presente documento, possono essere forniti secondo due diverse modalità: "a giorni/uomo", distinguendo i diversi profili necessari, così come individuati nell'allegato n.3 Curricula tipo "a corpo", inteso come fornitura e rilascio del prodotto finito; 1. Si riporta di seguito una tabella riassuntiva, contenente l'elenco dei servizi e prodotti dei quali le ditte dovranno presentare l'offerta e per ciascuno di essi sono riportate le modalità di fornitura associata (G giorni uomo, C a corpo) Codice Servizio Modalità di erogazione /fornitura Tempi massimi di consegna WP01 Progettazione C 2 mesi WP02 Realizzazione C 5 mesi (primo rilascio) WP03 Attività di installazione C 7 mesi (primo rilascio) WP04 Supporto Tecnologico G Non appl. WP05 Addestramento e avviamento G Non appl. all utilizzo WP06 Manutenzione evolutiva G Non appl. I tempi massimi di consegna si intendono in mesi solari e decorrono dalla data di stipula del contratto. Stima del fabbisogno per la durata del contratto : Modalità a corpo : Per tutta la durata del contratto è richiesta la fornitura dei seguenti servizi con la modalità a corpo : WP01 Progettazione WP02 Realizzazione WP03 Attività di installazione 10

11 Modalità a giorni uomo : WP04 WP05 WP06 Supporto Tecnologico Addestramento Manutenzione evolutiva La tabella seguente riporta: l elenco dei servizi la cui modalità di fornitura è a giorni /uomo; i profili che si ritiene necessario coinvolgere per ciascuno dei suddetti servizi, con riferimento all allegato n.3 Curricula tipo il fabbisogno stimato per tutta la durata del contratto, espressi in giorni/uomo, relativo ad ogni profilo associato a ciascun servizio richiesto. Profilo n. (come da allegato n. 3 - Curricula tipo) Supporto tecnologico Addestramento e avviamento all utilizzo Manutenzione evolutiva Totali

12 SEZIONE QUARTA La quarta sezione contiene l'analisi preliminare del sistema oggetto di fornitura. La prima parte contiene lo schema di massima del colloquio applicativo e il dettaglio dei componenti individuati. La seconda parte contiene il dettaglio dei moduli software dei quali è richiesta la reingegnerizzazione. 12

13 Capitolato tecnico Lotto 2 Interoperabilità Protocollo Sezione quarta - Parte prima

14 1. Obiettivi 3 2. Il Sistema Architetturale 3 Sistema della cooperazione applicativa e interoperabilita protocollo 3 Il contesto tecnologico generale. 4 Il contesto tecnologico specifico. 4 Servizi del CRIC e Indice delle AOO 6 Norme e linee guida del sistema nazionale 6 L'indice regionale delle AOO Proxy Applicativo protocollo informatico 8 Funzioni Generali 8 Funzione per Applicazioni protocollo NON std. Aipa 10 Funzioni per Applicazioni protocollo std. Aipa 11 Modulo per la gestione delle Aree Organizzative Omogenee 12 Modulo di monitoraggio Funzioni a livello di CRIC 12 Servizi applicativi centrali per l'interoperabilità di Protocollo 12 Modulo per la gestione indice regionale AOO 13 modulo per l'interfacciamento applicativo verso sistemi di posta certificata 14 Modulo per l'utilizzo della infrastruttura di interoperabilità da parte di soggetti non pubblici accreditati 17 Modulo per il monitoraggio della rete dei proxy applicativi Le Procedure 19 Definizione dei flussi 19 Flusso nr Flusso nr Flusso nr Interfacce standard vs. Applicazione di protocollo locale 23 Interfaccia via HTTPS/SOAP 24 Interfaccia via FORM di upload/download 24 Riferimenti Tecnologie Attività di progetto, deliverables, tempi di rilascio, prerequisiti 28

15 1. OBIETTIVI Il presente documento descrive il contesto tecnologico di riferimento e le specifiche componenti necessarie per la realizzazione di un insieme di sistemi software volti a fornire ad Amministrazioni Locali / Enti della Regione Toscana aderenti ed interconnesse alla Rete Telematica Regionale Toscana (RTRT) funzioni di interoperabilità applicativa, con riferimento al Protocollo Informatico [1]. sono: Le specifiche componenti oggetto di descrizione di dettaglio nel seguito del presente documento Componenti a livello di Nodo Applicativo Locale (NAL) Proxy Applicativo Protocollo informatico 1. Modulo per la interoperabilita verso l'agente locale 2. Modulo Interno per il trattamento delle informazioni 3. Modulo per la gestione delle Aree Organizzative Omogenee (AOO) 4. Modulo per interfacciamento con Sistemi Informativi Locali (SIL) 5. Modulo di monitoraggio Componenti a livello di Centro Regionale per l'interoperabilità e la Cooperazione Applicativa (in seguito CRIC) 6. Modulo per la gestione delle AOO 7. Modulo per l'interfacciamento verso sistemi di posta certificata 8. Modulo per l'utilizzo della interoperabilità da parte di soggetti non pubblici accreditati 9. Modulo di monitoraggio complessivo della rete dei proxy Applicativi 2. IL SISTEMA ARCHITETTURALE Il presente paragrafo descrive il contesto tecnologico di riferimento della realizzazione fornendo sia i necessari rimandi al livello generale del sistema architetturale sia il livello di declinazione nell'ambito specifico di riferimento del protocollo informatico. La trattazione è funzionalmente divisa in due sottoparagrafi, il primo più specificatamente legato alle modalità di interazione fra i sistemi informativi locali e l'infrastruttura di cooperazione applicativa, il secondo più rivolto al servizio di Indice Regionale delle Aree Organizzative Omogenee. Sistema della cooperazione applicativa e interoperabilita protocollo Il presente paragrafo descrive il contesto tecnologico di riferimento dell'interazione fra i sistemi informativi locali e l'infrastuttura di cooperazione applicativa.

16 Il contesto tecnologico generale. Il sistema oggetto della realizzazione trova la sua piena e naturale collocazione nell'ambito della infrastruttura di Cooperazione Applicativa della Regione Toscana [6] Tale sistema architetturale consente di erogare servizi ad alto valore aggiunto che, aderendo sostanzialmente alle norme di legge vigenti, si pongono l obiettivo di: migliorare l efficienza operativa interna della Pubblica amministrazione, consentire la condivisione delle informazioni, automatizzare i processi di cooperazione senza interferenze alle modalità operative del dominio applicativo delle Amministrazioni di Regione Toscana cooperanti, La infrastruttura CART si compone di due macrocomponenti principali, il Centro Regionale per l Interoperabilità e la Cooperazione Applicativa (CRIC) ed i Nodi Applicativi Locali (NAL). I NAL sono appendici del CART all interno delle Amministrazioni Locali / Enti aderenti ed interconnesse alla RTRT. I NAL sono progettati in modo da potersi interfacciare con relativa semplicità e flessibilità ad una molteplicità di Sistemi Informativi Locali (SIL) caratterizzati ciascuno da proprie architetture hardware, software di base e middleware, sistemi di comunicazione e applicazioni. Varie applicazioni che richiedono cooperazione applicativa / interoperabilità tra amministrazioni locali / enti aderenti possono essere state implementate nei SIL corrispondenti con livelli di funzionalità differenziate. L infrastruttura CART prevede di predisporre sui NAL per ciascun sistema applicativo degli enti/amministrazioni locali che si intende far interoperare, opportuni componenti denominati Proxy Applicativi per consentono la interoperabilità utilizzando l'infrastruttura di cooperazione applicativa. A tal fine il sistema architetturale prevede a livello generale che i Proxy Applicativi abbiano varie modalità di interazione con i SIL sia dal punto di vista delle comunicazioni che da quello, meno prevedibile e standardizzabile, delle modalità di rappresentazione dei contenuti. Il contesto tecnologico specifico. Il contesto tecnologico generale consente di realizzare i requisiti specifici della interoperabilità di protocollo informatico. In particolare la realizzazione di un servizio applicativo affinchè: Organizzazioni aderenti ed interconnesse alla Rete Telematica Regionale Toscana (RTRT) dotate di sistemi di Protocollo Informatico possano interoperare attraverso la Infrastruttura di Cooperazione Applicativa della Regione Toscana (CART) [6] indipendentemente dalle

17 modalità attuative e dai livelli di funzionalità con cui sono state realizzate nei SIL in modo conforme alle norme [2] seguendo diverse modalità attuative in riferimento alla circolare AIPA [3] (nel seguito indicata con AIPA/CR/28) e con livelli di funzionalità differenziate; Soggetti esterni possano percepire il sistema di interoperabilità di protocollo come compliant AIPA/CR/28 indipendentemente dalle modalità attuative e dai livelli di funzionalità con cui è realizzata l'infrastruttura di cooperazione applicativa della Rete Telematica Regionale Toscana. Ne consegue che i moduli previsti per la realizzazione del Proxy Applicativo Protocollo Informatico includono varie modalità di interazione con i SIL sia dal punto di vista delle comunicazioni secondo le specifiche del progetto A3 CART [6] sia da quello delle modalità di rappresentazione dei contenuti. Sistemi di protocollo informatico di SIL diversi potranno scambiare con i Proxy Applicativi contenuti non necessariamente allo stesso livello di completezza. Inoltre i formati potranno essere diversi per accomodare esigenze di adattamento ai NAL differenziate da parte delle enti/amministrazioni. Per garantire analoga indipendendenza agli interlocutori esterni al dominio il sistema gestirà mediante uno specifico modulo gateway le interazioni che lo consentano.

18 Si riporta qui di seguito uno schema di massima della struttura dell intero sistema. I macro requisiti per ciascun componente sono descritti nel seguito. Sebbene non riportato in figura, si assume che i moduli del Proxy Applicativo Protocollo Informatico accedano all Indice Regionale almeno secondo le modalità standard previste (LDAP). Figura 1 Servizi del CRIC e Indice delle AOO Il presente paragrafo descrive il sistema dell'indice regionale delle Aree Organizzative Omogenne e lo colloca nell'infrastuttura di cooperazione applicativa. Sono forniti anche i necessari rimandi al livello generale delle norme e dei sistemi nazionali ed i riferimenti con i servizi necessari al proxy applicativo protocollo informatico. Norme e linee guida del sistema nazionale L indice delle Aree Organizzative Omogenee contiene le informazioni indicate dal D.P.C.M. 31 ottobre 2000 [2]. Il Centro Tecnico per la Rete Unitaria della P.A è la struttura preposta alla sua gestione. Il Centro Tecnico ha predisposto la struttura dell IPA - Indice delle Amministrazioni Pubbliche. [4].

19 L'indice regionale delle AOO. L Indice regionale delle Pubbliche Amministrazioni e delle Aree Organizzative Omogenee, regionale, quale supporto all interoperabilità dei sistemi di protocollo informatico, può essere considerato dal punto di vista informatico come l unione di due indici logici distinti: a) l indice delle unità organizzative, b) l indice delle Aree Organizzative Omogenee. Il primo, organizzato per amministrazione e aree, descrive la struttura organizzativa dell Ente accreditato presso l Indice. Il secondo, invece, organizzato per amministrazioni contiene, per ciascuna AOO dell Ente (cioè l insieme delle unità organizzative dell Ente che usufruiscono di un sistema unico di protocollo e gestione documentale) tutte le informazioni relative all accesso telematico ad ogni AOO. L'indice regionale delle Aree Organizzative Omogenee è collocato nella infrastruttura di cooperazione applicativa e contiene le informazioni specifiche utili a favorire la interoperabilità di protocollo nell ambito della Rete Telematica della Regione Toscana nonché il sistema di supporto dell'aggiornamento degli archivi locali dei corrispondenti. L'indice regionale delle Aree Organizzative Omogenee è collocato nella Infrastruttura di Cooperazione Applicativa come un servizio del CRIC ed utilizza il Directory Server LDAP. La struttura realizzata per l'indice regionale delle Aree organizzative Omogenee è compatibile ed integrabile con quella dell IPA - Indice delle Amministrazioni Pubbliche - realizzato dal Centro Tecnico Centro Tecnico per la Rete Unitaria. L'integrazione con l'indice delle Amministrazioni Pubbliche ed in particolare l allineamento tra l indice regionale e quello a livello nazionale viene garantito con apposite funzioni.

20 3. PROXY APPLICATIVO PROTOCOLLO INFORMATICO Funzioni Generali Il compito del proxy applicativo per l interoperabilità di protocollo (PAPI) è quello di fornire i necessari adattatori fra il livello applicativo del Sistema Informativo Locale, rappresentato dalle varie soluzioni di Protocollo informatico delle Amministrazioni locali / Enti, ed il sistema di interoperabilità della infrastruttura di cooperazione applicativa della Regione Toscana. Il PAPI assolve dunque ai compiti propri di scambio verso un sistema omogeneo di trattamento e smistamento dei dati attraverso l uso di interfacce applicative basate su di un opportuno insieme di regole di implementazione. L'omogeneità del trattamento e smistamento dei dati si basa sulla scelta del trasporto delle informazioni per mezzo del sistema di messaggistica, verso il quale tale componente ha il compito di adattare le informazioni provenienti dal livello applicativo del protocollo. In aggiunta il Proxy applicativo renderà disponibili moduli relativi alla gestione delle variazioni delle aree organizzative omogenee, al monitoraggio dell attività applicativa ed alla validazione delle informazioni trasmesse. Sono previsti due tipi di interazione tra PAPI e SIL, in funzione del livello di completezza funzionale/conformità alle norme di Protocollo Informatico e capacità di intervento dell ente/amministrazione per adattarsi all interfaccia PAPI: 1. Il SIL implementa una versione di Protocollo Informatico non AIPA/CR/28. In questo caso l interazione tra PAPI e SIL avviene secondo un formato basato su sintassi XML o testuale (TXT), in grado di contenere un subset minimo ma adeguato, in accordo ad AIPA/CR/ Una versione di Protocollo Informatico AIPA/CR/28. In questo caso l interazione tra PAPI e SIL avviene secondo i formati XML standard indicati in 2.

21 La figura seguente esemplifica alcune interazioni fondamentali del PAPI con gli altri sistemi cui è connesso. Figura2 Il proxy di interoperabilità (PAPI) residente sul NAL è costituito da tre diversi strati applicativi: modulo per l'interoperabilità verso l'agente locale (interfaccia applicativa verso il lato dell'infrastruttura di cooperazione applicativa) modulo interno per il trattamento delle informazioni modulo per l'interfacciamento applicativo verso i sistemi informativi locali Ciascuno di questi componenti dovrà essere in grado di svolgere le seguenti funzioni :

22 a) trasferimento delle informazioni necessarie alla composizione/scomposizione dei vari tipi di messaggi oggetto dell interoperabilità fra i livelli degli strati applicativi; b) conversione delle suddette informazioni dal loro formato originale al meta-formato usato dalla logica applicativa del proxy e viceversa; c) conversione delle informazioni sullo stato dei messaggi ottenute dalla logica applicativa nel formato adatto per l applicazione esterna; Il modulo per l'interoperabilità verso l'agente locale utilizza le funzioni messe a disposizione dalla infrastruttura di cooperazione applicativa. Il modulo interno per il trattamento delle informazioni è delegato ad implementare la logica applicativa vera e propria, comune a tutti i tipi di interfacce definite verso l esterno. I principali compiti di questo modulo riguardano: a) composizione dei messaggi a partire dai dati ottenuti nel meta-formato del proxy; b) generazione UID del messaggio (Unique Idendifier); c) scomposizione dei messaggi provenienti dal Gateway o da altro NAL nel meta-formato del proxy; d) validazione dei messaggi da inviare e ricevuti; e) validazione dei files Segnatura.xml ricevuti e da inviare; f) composizione e scomposizione di Segnatura.xml ; g) elaborazioni interne di Segnatura.xml ; h) elaborazioni relative agli headers della busta di trasporto e-toscana; i) elaborazioni dei documenti dei messaggi, tra cui la codifica/decodifica nei formati MIME base64 j) Struttura core del gateway k) criptazione/decriptazione dei documenti nel loro formato MIME; l) imbustatura/sbustatura PKCS7; m) imbustatura/sbustatura dei messaggi da/per le buste del sistema di cooperazione applicativa; n) indirizzamento dei messaggi ricevuti verso le AOO; Il modulo per l'interoperabilità verso il sistema informativo locale utilizza le modalità di colloquio messe a disposizione dalla infrastruttura di cooperazione applicativa. I servizi ad uso interno del proxy, necessari al funzionamento della logica applicativa, saranno i seguenti : repository delle ricevute di accettazione e di avvenuta consegna Funzione per Applicazioni protocollo in modalità non AIPA/CR/28 Il SIL implementa il Protocollo Informatico in modalità non AIPA/CR/28 o Il PAPI elabora un file di input dal SIL, che corrisponde ad un messaggio protocollato in uscita, contenente dati strutturati in sintassi XML o TXT secondo una versione semplificata della specifica di interfaccia AIPA/CR/28, con puntatori per reperire il Documento Primario e gli Allegati, e i campi previsti dalla Segnatura Informatica.

23 o L elaborazione consiste nella verifica che i campi/valori forniti siano conformi alla specifica di interfaccia e che siamo corretti dal punto di vista del contenuto, ove controllabile. In particolare, il PAPI controlla: la validità formale dei dati forniti; che i codici delle Amministrazioni e delle AOO mittente e destinataria siano esistenti e corrispondenti a AOO registrate nell Indice Regionale ovvero nell'indice nazionale IAOO del CT RUPA se esterne al dominio RTRT, o Se l XML ricevuto risulta conforme alle specifiche di interfaccia, il PAPI codifica il Messaggio Protocollato in uscita, in un insieme di body parts in base allo standard MIME ed in accordo ale norme. o Il PAPI emette messaggi di errore da ritornare localmente al SIL secondo un formato da definire opportunamente. o Il messaggio protocollato, nel formato MIME, è indirizzato sull'interfaccia dell'agente locale del NAL per essere veicolato a destinazione cioè verso il NAL di una AOO attestata alla Infrastruttura di CART oppure verso una AOO esterna, attraverso il Gateway verso gli altri sistemi di trasposto quali la Posta Certificata. o Per ciascun messaggio protocollato in uscita dal NAL, il PAPI gestisce le seguenti tipologie di messaggi in ingresso: messaggio di conferma ricezione (solo se richiesto dal mittente del messaggio protocollato precedentemente inviato); messaggio di notifica di eccezione; messaggio di aggiornamento di conferma (eventualmente più di uno); messaggio di annullamento protocollazione. Il PAPI riceve ciascuno di questi messaggi secondo il formato MIME attraverso il sistema di messaggistica della infrastruttura di cooperazione applicativa. o Il PAPI effettua un controllo di congruenza su questi messaggi. In caso di congruità fornisce alla AOO locale un file per ciascun messaggio contenente l XML o TXT come da specifica. Altrimenti, emette notifiche di errore. Le funzionalità del PAPI in relazione ad un messaggio protocollato inviato da una AOO remota e diretto al SIL locale sono analoghe. Funzioni per Applicazioni protocollo in modalità AIPA/CR/28 Il SIL implementa il Protocollo Informatico in modalità AIPA/CR/28 o Il PAPI elabora un file di input dal SIL, che corrisponde ad un messaggio protocollato in uscita, contenente dati strutturati in sintassi XML in accordo alla definizione di interfaccia AIPA/CR/28. o Il PAPI valida l XML che lo compone (aderenza della segnatura informatica al DTD). o Il messaggio protocollato, nel formato MIME, è indirizzato sull'interfaccia dell'agente locale del NAL per essere veicolato a destinazione cioè verso il NAL di una AOO attestata alla Infrastruttura di CART oppure verso una AOO esterna, attraverso il Gateway di Posta Certificata. o Il PAPI del NAL relativo alla AOO ricevente, verifica le body parts MIME, le trasmette al SIL ricevente secondo il formato XML di interfaccia.

24 Le funzionalità del PAPI in relazione ad un messaggio protocollato inviato da una AOO remota e diretto al SIL locale sono analoghe. Modulo per la gestione delle Aree Organizzative Omogenee I sistemi di protocollo informatico presenti presso i Sistemi Informativi Locali dispongono di una anagrafica dei corrispondenti nella quale i soggetti destinatari delle comunicazioni oggetto di registrazione di protocollo sono codificati secondo una logica propria di ogni SIL e diversa da quella utilizzata per la codifica delle AOO sull'indice regionale o nazionale. L'indice regionale delle Aree Organizzative Omogenee è collocato nella infrastruttura di cooperazione applicativa e contiene le informazioni specifiche utili a favorire la interoperabilità di protocollo nell ambito della Rete Telematica della Regione Toscana e fra queste il sistema di supporto dell'aggiornamento degli archivi locali dei corrispondenti. E' necessario che le variazioni o i nuovi accreditamenti che hanno luogo sull'indice regionale delle AOO producano un messaggio destinato alla sincronizzazione dei Corrispondenti su SIL. Si prevede che il messaggio sia generato a carico del Directory Server. Sul CRIC sarà definita la topic Aggiornamenti Indice Regionale AOO. In fase di installazione del proxy applicativo ciascun SIL potrà configurare o meno la sottoscrizione la topic Aggiornamenti Indice Regionale AOO. Il CRIC pubblica gli eventi di aggiornamento dell indice. Il modulo del Proxy applicativo per la gestione delle variazioni AOO regionale raccoglie gli eventi e li rende disponibili al SIL secondo un formato prestabilito. Tale informazione potrà essere utilizzata dal SIL per aggiornare la rubrica locale dei Corrispondenti. Modulo di monitoraggio Il Proxy applicativo modulo monitoraggio svolge i compiti di monitoraggio applicativo sul Proxy stesso e rende disponibili al sistema centrale di monitoraggio secondo un protocollo da concordare in fase di piano di attività per ogni AOO afferente al Proxy stesso alcune informazioni di interesse dei soggetti preposti al controllo quali: numero di messaggi inviati/ricevuti per ogni AOO afferente, messaggi per giorno, numero di errori di consegna. 4. FUNZIONI A LIVELLO DI CRIC Servizi applicativi centrali per l'interoperabilità di Protocollo I seguenti servizi sono garantiti dalla infrastruttura di cooperazione applicativa e consentono: Il routing dei messaggi tra due AOO attestate alle RTRT.

25 Il routing verso il Gateway di Posta Certificata, nel caso la AOO destinataria non sia attestata alla RTRT. Effettua analogamente il routing dei messaggi provenienti dal Gateway e destinati ad AOO attestate sulla RTRT. La preparazione del messaggio relativo all'evento "aggiornamento indice regionale" e la pubblicazione su topic specifico. Tutti i servizi descritti in questo paragrafo sono internamente realizzati e gestiti nell'ambito del progetto di realizzazione della infrastruttura di cooperazione applicativa di Regione Toscana (CART A3). Modulo per la gestione indice regionale AOO Ogni sistema di protocollo informatico presente come sistema informativo locale di una Amministrazione locale / Ente aderente al progetto deve comunque acquisire, consultare e tenere sincronizzate le informazioni presenti sull'indice regionale delle AOO. L Indice regionale delle Aree Organizzative Omogenee per soddisfare i requisiti di generalità ed integrazione previsti, può essere considerato dal punto di vista informatico come l unione di due indici logici distinti: l indice delle unità organizzative, l indice delle Aree Organizzative Omogenee Il primo, organizzato per amministrazione e aree, descrive la struttura organizzativa dell Ente accreditato presso l Indice. Il secondo, invece, organizzato per amministrazioni contiene, per ciascuna AOO dell Ente (cioè l insieme delle unità organizzative dell Ente che usufruiscono di un sistema unico di protocollo e gestione documentale) tutte le informazioni relative all accesso telematico ad ogni AOO e in particolare la casella di posta istituzionale Questi elementi dell'indice sono realizzati in modo compatibile ed integrabile con quella dell IPA - Indice delle Amministrazioni Pubbliche - realizzato dal Centro Tecnico Centro Tecnico per la Rete Unitaria. Le informazioni finora descritte e desumibili dalle norme e linee guida nazionali debbono essere opportunamente integrate per trattare, sempre come Indice regionale delle AOO: le informazioni necessarie al instradamento dei messaggi mediante l'infrastruttura di cooperazione applicativa L'indice delle informazioni necessarie alla gestione delle modifiche (che debbono essere segnalate ai SIL). Queste integrazioni sono realizzate per fornire al sistema di indirizzamento le informazioni necessarie e sufficenti all'instradamento dei messaggi attraverso il sistema di messaggistica su cui è basata l'infrastruttura di cooperazione applicativa verso il destinatario e per consentire la gestione e la produzione dei mesasggi di notifica delle variazioni intercorse sull'indice stesso. Le informazioni da inserire nell'indice si basano sul D.P.C.M. 31 ottobre 2000; le amministrazioni che intendono accreditarsi presso l indice devono fornire fra l'altro: la denominazione, il codice identificativo e l indirizzo della sede principale dell amministrazione l elenco delle proprie Aree Organizzative Omogenee e per ciascuna di esse: la denominazione, il codice identificativo e la casella istituzionale dell area il nominativo del responsabile del servizio per la tenuta del protocollo informatico la data di istituzione l eventuale data di soppressione l eventuale riferimento al manuale di gestione della AOO reperibile in forma di documento informatico l elenco degli uffici o unità organizzative utente dell AOO.

26 Per l integrazione con l IPA (Indice delle Pubbliche Amministrazioni), le amministrazioni che intendono accreditarsi presso l indice debbono inoltre fornire: la struttura organizzativa dell ente accreditato con l indicazione delle relazioni tra unità organizzative la denominazione, l indirizzo, la casella ufficiale di struttura di ciascuna UO e il collegamento alla AOO di riferimento gli eventuali dati relativi alla sicurezza (es. collegamento alla CA emettente i certificati X.509v3 per la connessione telematica sicura, l autenticazione dei messaggi e/o degli interlocutori). L allineamento tra l indice regionale e quello a livello nazionale dovrà essere garantito con apposite funzioni. La gestione dell indice prevede le seguenti funzionalità: accreditamento di un Ente rimozione dell Ente accreditato inserimento, aggiornamento e cancellazione di una AOO aggiornamento delle Unità Organizzative tracciamento delle modifiche Il modulo per la gestione delle AOO (componente CRIC) prevede per i soggetti preposti alla gestione ed alla consultazione diretta (ad esempio help desk del CRIC e soggetti abilitati alla variazione delle informazioni di propria pertinenza) una apposita interfaccia Web. La presente fornitura include lo svolgimento dell'attività di caricamento delle informazioni sull'indice regionale solo per la quota parte necessaria alla verifica e collaudo delle funzioni del modulo di gestione. L accreditamento di un nuovo Ente dovrà avvenire con lo scambio di documenti informatici firmati, anche digitalmente. Dopo aver acquisito e verificato le informazioni previste per l accreditamento, verrà definito il codice che identifica univocamente l ente e creata nell indice la struttura dati destinata a contenere i dati dell ente e delle AOO da iscrivere nell indice. In un secondo momento si provvederà, quindi, al caricamento massivo dei dati dell ente e alle unità organizzative tenendo conto del legame gerarchico esistente tra le stesse. I codici associati a ciascuna Area Organizzativa Omogenea e a ciascuna unità organizzativa saranno generati ed attribuiti autonomamente dal relativo Ente, mentre il codice che identifica in maniera inequivocabile l Amministrazione verrà attribuito a seguito della richiesta di accreditamento dell ente nell indice. La rimozione di un Ente, nei casi previsti, comporterà la cancellazione dei dati di sua pertinenza presenti sull indice, dopo aver effettuato il loro salvataggio per l archiviazione dei dati. All atto dell iscrizione di una AOO dovranno essere forniti tra l altro i dati del responsabile della AOO e della tenuta del protocollo informatico, il relativo indirizzo della casella di posta istituzionale, il numero e l elenco degli uffici o unità organizzative ad essa afferenti e già caricate. Si provvederà quindi all inserimento dei dati specifici della AOO e delle associazioni con le unità organizzative ad essa collegate. Nel caso di modifica dell elenco delle unità organizzative legate ad una AOO o di soppressione di una AOO dovranno essere comunicate le nuove assegnazioni delle unità organizzative utenti ad altre AOO. Si provvederà pertanto, prima all archiviazione delle informazioni presenti sull indice e solo dopo si riassegneranno le unità organizzative. Il tracciamento delle modifiche sarà reso attraverso un file di log che conterrà la memoria delle modifiche effettuate e, con l archiviazione delle segnature XML, si potranno soddisfare eventuali richieste o necessità di recupero dei dati storici. La struttura dell'indice regionale deve essere realizzate affinché siano presenti funzionalità che consentano di fornire i dati da pubblicare nell indice e le successive modifiche su formato elettronico (nel formato, es: LDIF) secondo la struttura predefinita (anche affinché siano caricabili automaticamente). La consultazione dell indice da parte delle applicazioni locali e degli utenti generici verrà effettuata tramite protocollo LDAP. Sarà inoltre possibile effettuare lo scarico completo dell'indice. modulo per l'interfacciamento applicativo verso sistemi di posta certificata Il modulo per l'interfacciamento applicativo verso sistemi di posta certificata si configura come un gateway e consente che soggetti esterni (cittadini, imprese altre PP.AA.) dotati di un servizio di

27 posta certificata possano percepire il sistema di interoperabilità di protocollo come conforme indipendentemente dalle modalità attuative e dai livelli di funzionalità con cui è realizzata l'infrastruttura di cooperazione applicativa della Rete Telematica Regionale Toscana. Il modulo svolge nei confronti del sistema interno alla RTRT le funzioni di trasformazione fra il sistema di messaggistica interno e i servizi di trasporto in uscita verso l esterno della RTRT. Analogamente viceversa. La sua struttura è basata su di un core che implementa la logica applicativa comune a tutti i trasporti e su una serie estensibile di componenti, una per ogni tipologia di trasporto richiesta. Le componenti previste in prima istanza sono: per l'interno il servizio messaggistica MOM previsto dalla infrastruttura di cooperazione applicativa per l'esterno un servizio di posta certificata realizzato secondo le linee guida [5] Relativamente al canale Posta certificata il gateway garantirà la composizione dei messaggi di servizio per Ricevuta di Accettazione, nel caso di invio di messaggio da parte di un Soggetto esterno. Analogamente il gateway elaborerà i messaggi per ricevuta di accettazione e Ricevuta di avvenuta consegna ottenuti dal sistema esterno come conseguenza dell invio di messaggi. La discriminazione fra messaggi principali ovvero quelli contenenti i documenti o le informazioni relative alle operazioni della interoperabilità e quelli di servizio, relativi alle ricevute di accettazione e avvenuta consegna, sarà eseguita dal gateway analizzando il file XML allegato ai messaggi Il Gateway si interfaccia con il Servizio Applicativo Centrale per l'interoperabilità di Protocollo e ha le funzionalità di client di Posta Elettronica Certificata verso il mondo esterno. In particolare: o Si configura come un qualsiasi proxy applicativo del NAL ed acquisisce dall'agente locale in ingresso i messaggi protocollati da inoltrare verso soggetti esterni alla Rete Telematica Regionale Toscana. o Compone un messaggio adatto alla spedizione SMTP, partendo dalle body parts MIME ricevute, cioè conforme a quanto definito per i messaggi di ingresso ( ). o Accede al sistema di posta certificata fornendo le credenziali di accesso. o Gestisce le ricevute di accettazione relative a messaggi inoltrati mantenendone traccia ( ) o Gestisce le ricevute di avvenuta consegna ( ) e errore di consegna ( ) relative a messaggi inoltrati mantenendone traccia. o Verifica le firme digitali apposte sui messaggi ricevuti (formato S/MIME) dal sistema di posta certificata. o Inoltra i messaggi di ritorno ricevuti dall esterno alla Organizzazione destinataria sulla RTRT. o Gestisce i messaggi di anomalia di trasporto relativi sia a messaggi destinati al gateway che ai messaggi inviati dal gateway ( ). o Il Gateway funziona in modalità unattended e l accesso alle informazioni di sicurezza (chiave privata per la firma, certificati fidati per la verifica delle firme, ecc.) è fornito dal responsabile della sicurezza allo startup del sistema. Il sistema stesso deve essere mantenuto in ambiente protetto per evitare uso improprio/fraudolento delle informazioni di sicurezza. o La correlazione tra i messaggi di posta elettronica certificata e relative ricevute (utilizzati per il trasporto dei messaggi di protocollo informatico e dei relativi messaggi di ritorno) è effettuata in accordo a 5, tramite il codice identificativo univoco del messaggio originale (Message-ID).

28 L'individuazione degli eventuali requisiti aggiuntivi che un generico servizio di Posta Certificata appartenente a quelli certificati AIPA deve offrire per la realizzazione delle necessarie funzionalità sopra elencate è a carico del soggetto realizzatore. La disponibilità agli enti aderenti di un servizio con tali eventuali requisiti aggiuntivi sarà garantito da Rete Telematica Regionale Toscana e non fa parte di questa fornitura.

29 Modulo per l'utilizzo della infrastruttura di interoperabilità da parte di soggetti non pubblici accreditati La Rete Telematica Regionale Toscana fornisce servizi di sicurezza a soggetti accreditati mediante la fornitura di certificati X509 rilasciati da una Autorità di Certificazione. Il modulo per l'utilizzo della infrastruttura di interoperabilità da parte di soggetti non pubblici accreditati consente a soggetti esterni (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 di: Inviare comunicazioni alle Amministrazioni Pubbliche / Enti aderenti al progetto utilizzando l'infrastruttura di cooperazione applicativa della Rete Telematica Regionale Toscana. Interrogare il servizio fornito dal modulo per acquisire i messaggi di servizio relativi alla comunicazione inviata (messaggio di accettazione, messaggio di ripudio, messaggio di anomalia, messaggio di avvenuta protocollazione) Il modulo è residente sul CRIC Il modulo si presenta con una interfaccia web che autentica il soggetto e consente l'invio ad una delle AOO presenti sull'indice regionale delle AOO. Il modulo consente di allegare documenti digitali firmati Il modulo si appoggia su una opportuna struttura di base dati ospitata dal CRIC ove vengono registrati sia il messaggio inviato sia i messaggi di servizio Quando si invia il messaggio viene comunicato all'utente l'id assegnato. Con tale ID si andranno a ricercare i messaggi di servizio relativi.

30 Modulo per il monitoraggio della rete dei proxy applicativi Il modulo per il monitoraggio della rete dei proxy applicativi svolge i compiti di monitoraggio applicativo sull'insieme dei Proxy dedicati alla interoperabilità di protocollo e rende disponibili al sistema centrale di monitoraggio secondo un protocollo da concordare in fase di piano di attività per ogni AOO afferente al Proxy stesso alcune informazioni di interesse dei soggetti preposti al controllo quali: numero di messaggi inviati/ricevuti per ogni AOO afferente, numero di errori di consegna, messaggi ricevuti/destinati all'esterno della infrastruttura CART.

31 5. LE PROCEDURE Definizione dei flussi Necessaria ad una corretta gestione del sistema di interoperabilità è la preliminare definizione dei principali flussi delle attività dei processi di cooperazione che devono evidenziare: i dati trasmessi, il colloquio tra i vari sistemi e le applicazioni, le modalità operative che permetteranno di superare i problemi relativi alla eterogeneità dei sistemi di protocollo utilizzati dagli aderenti al progetto e ai sistemi di trasporto che s intendono utilizzare. Flusso nr. 1 Flusso 1 Protocollazione in uscita (Ente RTRT) 1) L operatore deve protocollare in uscita un documento (con eventuali allegati) 2) L operatore richiede la visualizzazione dell elenco destinatari mediante una tipica funzione del proprio prodotto di protocollo, all interno dei quali vi è il sottoinsieme dei dati relativi alle AOO; 3) Se l operatore seleziona un destinatario presente nell indice delle AOO, alla conferma della operazione di protocollazione il programma del protocollo predispone automaticamente gli elementi e le operazioni necessarie all invio del messaggio, rende disponibili al proxy applicativo i dati e documenti con modi specifici dell interfaccia utilizzata. 4) Il proxy applicativo sul NAL crea il messaggio, crea la busta standard e la rilascia all'agente locale del NAL che cura il trasposto all Ente destinatario. Quindi scrive nel repository locale la traccia dell inizio spedizione (Ricevuta di accettazione). 5) Se il destinatario è esterno al sistema di cooperazione applicativo di Regione Toscana, il modulo con funzioni di gateway riceve e attiva l opportuno plug-in per convertire il messaggio per il trasporto specificato, e quindi lo invia. 6) Se il destinatario è un Ente RTRT si prosegue come Flusso 2 Protocollazione in entrata (Ente RTRT). La schematizzazione di questo flusso è riportata in figura con il formalismo UML dell Activity Diagram.

32 Flusso nr. 2 Flusso 2 Protocollazione in entrata (Ente RTRT) 1) Il proxy applicativo protocollo informatico acquisisce dall'agente locale del NAL il messaggio, apre la busta e verifica il tipo di messaggio, ovvero se principale o di servizio. 2) Se il messaggio è di servizio lo memorizza nella repository locale altrimenti, essendo di tipo principale, scrive un messaggio per Ricevuta di avvenuta consegna e lo colloca sul sistema per l'inoltro al mittente. 3) Il proxy in ragione del tipo di interfaccia con il sistema informativo locale di protocollo, processa il messaggio in modo opportuno. 4) Il sistema di protocollo locale, opportunamente modificato, verifica l esistenza di messaggi e li legge 5) Se l operatore decide di protocollare un messaggio disponibile e questo è strutturato legge le informazioni da Segnatura.xml e se è richiesta la conferma ricezione, le relative informazioni vengono rese disponibile al Proxy attraverso l opportuna interfaccia. Se il

33 messaggio non è strutturato le informazioni devono essere immesse manualmente dall operatore. La schematizzazione di questo flusso è riportata è riportata in figura

34 Flusso nr. 3 Flusso 3 Messaggio da Soggetto esterno 1) Il Gateway legge dal canale specifico del trasporto del Soggetto esterno e verifica il tipo di messaggio, ovvero se principale o di servizio. 2) Il Gateway, se il messaggio è di tipo principale, crea il messaggio per Ricevuta di accettazione, e la invia al Soggetto esterno secondo il formalismo del canale del trasporto. Altrimenti se il messaggio è di tipo Servizio si prosegue al punto successivo. 3) Il Gateway crea un messaggio e lo affida all'agente locale per il trasporto interno. 4) Si prosegue come Flusso 2 Protocollazione in entrata (Ente RTRT). La schematizzazione di questo flusso è riportata è riportata in figura

35 6. INTERFACCE STANDARD VERSO APPLICAZIONE DI PROTOCOLLO LOCALE L interfaccia verso il sistema informatico locale L interazione fra il proxy applicativo protocollo informatico ed i sistemi di Protocollo presenti sul Sistemi Informativi Locali avviene secondo le modalità di colloquio applicativo prescritte dalla infrastruttura di cooperazione applicativa di Regione Toscana. Per la trattazione in questo ambito e rimandando al documento specifico per i necessari approfondimenti, le modalità applicative per lo scambio di informazioni fra il proxy applicativo ed il SIL potrà avvenire secondo le seguenti modalità: Form di download/upload con script CURL installato sul SIL Utilizzo di web services presenti sul NAL e invocabili da SIL Utilizzo di JMS Queue presente sul NAL e accessibile da SIL Compito della realizzazione prevista è quello di analizzare le diverse modalità di colloquio, realizzare i moduli applicativi per implementare il colloquio e produrre una documentazione tecnica e funzionale completa che renda possibile ai gestori dei vari sistemi di protocollo di adeguarli alle esigenze di comunicazione. Parte qualificante della realizzazione sarà anche la definizione (completa ovvero ad integrazione) dei contenuti informativi che devono essere scambiate fra Proxy Applicativo e SIL (contenuto dei messaggi primari e dei messaggi di servizio). Di seguito riportiamo il risultato di una prima fase di analisi di tali informazioni che constituisce un esempio non vincolante per la realizzazione. Esempio di strutturazione dell'interfaccia. Il Proxy per l Interoperabilità dei Protocolli ideato per attuare la cooperazione applicativa è una componente che opera in modalità multicanale, sul versante del sistema informativo locale, con modalità di colloquio aperte e scalabili al fine di consentire una facile integrazione delle diverse realtà cooperanti, anche quelle più obsolete. Relativamente al sistema di gestione del protocollo del sistema informativo locale, sono state classificate alcune situazioni, tipiche, ipotizzando per ognuna una canale di riferimento, che in ogni caso non risulta vincolante. La classificazione dei sistemi di gestione del protocollo è la seguente: Rientra in questa classe un sistema di gestione del protocollo che ha già presenti le funzioni per gestire i documenti firmati digitalmente e per generare il file Segnatura.xml. Questo sistema ha come riferimento il canale SOAP/HTTPS con il quale trasmetterà al Proxy gli elementi necessari all invio del messaggio, che sono: Codice A00 del destinatario Flag richiesta di conferma ricezione Segnatura.XML Documento principale firmato

36 eventuali Allegati firmati. Rientra in questa classe un sistema di gestione del protocollo che non ha le funzioni per generare il file Segnatura.xml. Questo sistema ha come riferimento il canale SOAP/HTTPS con il quale trasmetterà al Proxy tutti documenti e puntualmente tutte le informazioni necessarie alla generazione del Segnatura.xml da parte del Proxy stesso. Il sistema di gestione del protocollo di questa catagoria non è in standard AIPA e non è in grado di utilizzare i canali tecnologicamente più evoluti. In questo caso il proxy consentirà lo scambio delle informazioni via HTTP (getpost) mediante opportuni file strutturati. Le modalità di colloquio sopra citate sono maggiormente dettagliate nel seguito del capitolo. Interfaccia via HTTPS/SOAP L interfaccia che utilizza il SOAP su HTTPS espone un insieme di metodi per lo scambio delle informazioni da e per il Proxy. Il sistema di gestione del protocollo locale, dovrà assimilare al suo interno un sottoinsieme di tali metodi in ragione della sua capacità di aggregare le informazioni necessarie all interoperabilità. Interfaccia via FORM di upload/download L interfaccia che utilizza questa modalità come modo di scambio delle informazioni da e per il Proxy per l Interoperabilità dei Protocolli è sostanzialmente un insieme di file strutturati in cui vengono collocate le informazioni. Il tracciato dei file che svolge funzioni di repository per la CODA dei messaggi in ingresso ed in uscita è articolato in due files distinti. Relativamente all indice delle AOO locale (LDAP), per la lettura e l aggiornamento del medesimo, sono presenti un insieme di file di scambio. Infine è stata definita una struttura di scambio delle informazioni relativa alle ricevute del trasporto. Più in dettaglio le tabelle relative alle attività di protocollazione sono:

37

38