C4 Rete Regionale dei SUAP architettura generale maggio 2007
Sommario 1. ARCHITETTURA GENERALE... 3 1.1.1 Proxy Applicativo... 3 1.1.2 SIL Sistema Informativo Locale... 3 1.1.3 Messaggi ed Eventi... 3 1.1.4 Il Protocollo INTERSUAP... 4 2. ATTORI DEL SISTEMA... 5 3. REQUISITI TECNOLOGICI PER L IMPLEMENTAZIONE DEL PROTOCOLLO SUAP... 6 3.1.1 Dettaglio degli Eventi... 6
1. ARCHITETTURA GENERALE L obiettivo di questo sistema è finalizzato a monitorare sul territorio regionale, l apertura, il trasferimento verso gli enti terzi a cui viene chiesto un parere e la conclusione del procedimento amministrativo che consente l avvio di una impresa.. Per raggiungere questi obbiettivi si utilizza l infrastruttura di comunicazione cooperativa costruita da Regione Toscana (CART) ; di conseguenza è stato implementato un proxy applicativo la cui architettura è di seguito descritta. 1.1.1 Proxy Applicativo Un proxy applicativo è un componente software, installato in uno o più NAL (Nodo Applicativo Locale), le cui caratteristiche principali possono essere così riassunte: o Rappresenta un particolare dominio applicativo (nel nostro caso un SUAP). o Gestisce la pubblicazione e la ricezione di uno o più tipi di messaggio, relativamente agli eventi generati nel particolare dominio applicativo, secondo il modello Publish & Subscribe. o Opera per conto di uno o più SIL (Sistemi Informativi Locali), ovvero gestisce l insieme di tutti i sistemi informativi (e di altri componenti software) di qualunque Ente connesso al NAL sul quale il proxy applicativo stesso è installato. 1.1.2 SIL Sistema Informativo Locale Un SIL è la rappresentazione astratta di un Sistema Informativo Locale, di proprietà di un qualunque Ente che desidera partecipare alla Cooperazione Applicativa. Nell ambito del Sistema di Cooperazione Applicativa, un SIL può essere, in senso più ampio, un qualunque componente software che possa pubblicare o sottoscrivere eventi applicativi, o in grado di offrire e richiedere servizi, come ad esempio un GIS Server, un Mail Server, ecc. Un proxy applicativo è in grado di operare per conto di uno o più SIL, purché essi abbiano la facoltà di colloquiare con il NAL sul quale il proxy stesso risiede, attraverso uno o più protocolli telematici. Gli eventi che si generano nel tempo all interno di un SIL vengono propagati agli altri SIL sottoscrittori di tali eventi, attraverso l impiego di messaggi di cooperazione applicativa. 1.1.3 Messaggi ed Eventi Un evento è rappresentato dal cambiamento di stato in uno o più oggetti software, mantenuti all interno di un SIL. Un insieme di tipologie di evento, tra loro omogenee dal punto di vista del contesto applicativo, possono essere rese disponibili ad altri SIL, attraverso la loro pubblicazione nel Sistema di Cooperazione Applicativa, secondo il modello Publish & Subscribe. L elemento base di interscambio delle informazioni è il messaggio. Un messaggio rappresenta l insieme dei dati generati all accadere di un evento, nel momento in cui essi vengono convertiti e rappresentati in un formato (ad esempio XML/SOAP) atto a renderli trasmissibili in una rete telematica. Il SIL comunica le informazioni relative ai propri eventi al Proxy Applicativo, il quale a sua volta, dopo una eventuale fase di trasformazione e di validazione, pubblica i relativi messaggi nel sistema di Cooperazione Applicativa, allo scopo di consegnare tali messaggi a tutti i SIL sottoscrittori, attraverso i rispettivi Proxy Applicativi installati sui NAL di loro competenza. Un proxy applicativo, abbiamo visto, è in grado di gestire uno o più tipi di evento, e quindi di trasmettere e ricevere uno o più tipi di messaggio, in base alle esigenze del particolare dominio applicativo.
1.1.4 Il Protocollo INTERSUAP Il Protocollo INTERSUAP, peraltro divenuto standard nell ambito di e-toscana, viene introdotto come forma di colloquio e di scambio informativo tra i Nodi Applicativi Locali (NAL) che compongono la Rete dei SUAP. Questo Protocollo consente l interscambio di messaggi tra i SIL degli Enti in possesso (o utilizzatori) di applicativi SUAP, gli Enti Terzi in grado di esprimere pareri sui procedimenti in corso, ed il NAL di Regione Toscana, che ha funzione di collettore e di Repository di tutti questi messaggi. Da un punto di vista generale, è possibile delineare quindi la seguente configurazione architetturale, necessaria alla gestione del protocollo INTERSUAP:
2. ATTORI DEL SISTEMA COMUNI Utilizzatori o possessori di applicativi SUAP, pubblicano i messaggi INTERSUAP relativi agli eventi di propria competenza attraverso un NAL, sul quale verrà installato il Proxy Applicativo SUAP, e quindi utilizzano il Sistema di Cooperazione Applicativa. ENTI TERZI Sono in grado di esprimere pareri sui procedimenti in corso, possono essere configurati in una delle seguenti modalità: 1-Nel caso in cui siano in grado di utilizzare il Sistema di Cooperazione Applicativa, inviano le proprie espressioni di parere tramite l emissione di un messaggio INTERSUAP sul NAL ad essi associato. 2-Nel caso in cui non siano in grado di utilizzare il Sistema di Cooperazione Applicativa, utilizzano una Web Application, resa disponibile da Regione Toscana, per comunicare l espressione di parere relativa ad un determinato procedimento. REGIONE TOSCANA Riceve i messaggi INTERSUAP attraverso le seguenti due modalità: 1-Attraverso il NAL sul quale viene installato il Proxy Applicativo INTERSUAP. 2-Attraverso una Web Application, la quale viene utilizzata per raccogliere in modo interattivo i messaggi INTERSUAP dagli Enti Terzi che non sono in grado di utilizzare il Sistema di Cooperazione Applicativa. In ogni caso, è stato realizzato un INTERSUAP Integration Layer, ovvero uno strato software che fungerà da punto di raccolta e di normalizzazione dei messaggi INTERSUAP, prima di inserirli nel DB Meta-Iter.
3. REQUISITI TECNOLOGICI PER L IMPLEMENTAZIONE DEL PROTOCOLLO SUAP I requisiti tecnologici richiesti per l utilizzo del sistema in cooperazione Applicativa sono i seguenti. Un Proxy Applicativo SUAP, da installare sui NAL utilizzati dai Comuni, il quale è in grado di svolgere le seguenti attività: o Pubblicare un evento di tipo Notifica Attivazione di Procedimento o Pubblicare un evento di tipo Notifica Richiesta di Parere o Pubblicare un evento di tipo Notifica Conclusione di Procedimento o Sottoscrivere un evento di tipo Notifica Espressione di Parere Un Proxy Applicativo SUAP/ET, da installare sui NAL utilizzati dagli Enti Terzi, il quale è in grado di svolgere le seguenti attività: o Pubblicare un evento di tipo Notifica Espressione di Parere o Sottoscrivere un evento di tipo Notifica Richiesta di Parere Un Proxy Applicativo INTERSUAP, da installare sul NAL presente in Regione Toscana, il quale è in grado di svolgere le seguenti attività: o Sottoscrivere un evento di tipo Notifica Attivazione di Procedimento o Sottoscrivere un evento di tipo Notifica Richiesta di Parere o Sottoscrivere un evento di tipo Notifica Espressione di Parere o Sottoscrivere un evento di tipo Notifica Conclusione di Procedimento o Pubblicare un evento di tipo Notifica Espressione di Parere 3.1.1 Dettaglio degli Eventi 3.1.1.1 Notifica attivazione di un procedimento Questo evento viene pubblicato dal Comune una volta avviato un procedimento tramite la propria applicazione SUAP Le informazioni che devono essere trasmesse in formato XML per pubblicare un evento di questo tipo sono: o L Identificativo Procedimento, generato dal SIL del Comune. o La Data di Attivazione del procedimento. o La Tipologia di Procedimento relativa al procedimento attivato o Il Codice Fiscale/Partita IVA del richiedente il procedimento o La Denominazione del richiedente il procedimento Esempio di Messaggio XML: <EventoSUAP tipo= ATTIVAZIONE > <Procedimento> <IDProcedimento>0123456789</IDProcedimento> <DataAttivazione>01/03/2004</DataAttivazione> </Procedimento>
<IDUniversale> 001-0001-2004-000000000012 </IDUniversale> <TipoProcedimento>0028</TipoProcedimento> <EnteAttivatore>017048</EnteAttivatore> <SUAP>7274</SUAP> <Richiedente> <CodiceFiscale></CodiceFiscale> <PartitaIVA>84637285619</PartitaIVA> <Denominazione>Rossi srl</denominazione> </Richiedente> </EventoSUAP> 3.1.1.2 Notifica richiesta di parere Questo evento viene pubblicato dal Comune relativamente ad un proprio Procedimento Le informazioni che devono essere trasmesse in formato XML per pubblicare un evento di questo tipo sono: o L Identificativo Procedimento, e la Data di Attivazione del Procedimento, generati dal SIL del Comune. o L ID Universale Procedimento, generato dal Proxy Applicativo durante la pubblicazione dell evento Notifica Attivazione di Procedimento. Questo campo è facoltativo, ma la sua presenza consentirebbe una fase di validazione accurata, prima della pubblicazione dell evento. o La Data di Generazione della Richiesta di Parere. o Il Codice dell Ente Terzo al quale il parere viene sottoposto. Allo scopo di individuare l Ente che dovrà esprimere il parere, sarà possibile utilizzare un qualunque sistema di codifica che sarà ritenuto opportuno da Regione Toscana, come ad esempio il codice ISTAT, oppure il codice dell Indice (Regionale o Nazionale) della Pubblica Amministrazione. <EventoSUAP tipo= RICHIESTAPARERE > <Procedimento> <IDProcedimento>0123456789</IDProcedimento> <DataAttivazione>01/03/2004</DataAttivazione> </Procedimento> <IDUniversaleProcedimento> 001-0001-2004-000000000012 </IDUniversaleProcedimento> <IDUniversale> 001-0001-2004-000000000013 </IDUniversale> <EnteAttivatore>017048</EnteAttivatore> <SUAP>7274</SUAP> <DataGenerazioneRichiesta>01/03/2004</DataGenerazioneRichiesta> <EnteTerzo>0034-784627</EnteTerzo> </EventoSUAP> 3.1.1.3 Notifica espressione di parere Questo evento viene sottoscritto da un Comune, e viene ricevuto quando l Ente Terzo preposto ha
provveduto ad esprimere il parere richiesto. È importante notare che l evento Notifica Espressione di Parere può essere pubblicato da: o L Ente Terzo, se quest ultimo è in possesso di un NAL. o Il Proxy Applicativo INTERSUAP di Regione Toscana, qualora l Ente Terzo, non disponendo di un NAL, ha fornito questa informazione tramite la Web Application messa a disposizione a questo scopo da Regione Toscana Le informazioni che devono essere trasmesse in formato XML per pubblicare un evento di questo tipo sono: o L Identificativo Procedimento, e la Data di Attivazione del Procedimento, generati dal SIL del Comune. o L ID Universale Procedimento, generato dal Proxy Applicativo durante la pubblicazione dell evento Notifica Attivazione di Procedimento. o L ID Universale Espressione di Parere, generato dal Proxy Applicativo origine del messaggio. o L Esito dell Espressione di Parere. E prevedibile utilizzare un codice tipo Esito Positivo/Esito Negativo, oppure una forma più accurata di categorizzazione degli esiti o La Data di Espressione del Parere <EventoSUAP tipo= ESPRESSIONEPARERE > <Procedimento> <IDProcedimento>0123456789</IDProcedimento> <DataAttivazione>01/03/2004</DataAttivazione> </Procedimento> <IDUniversaleProcedimento> 001-0001-2004-000000000012 </IDUniversaleProcedimento> <IDUniversale> 004-0025-2004-000000000014 </IDUniversale> <EnteAttivatore>017048</EnteAttivatore> <SUAP>7274</SUAP> <DataEspressioneParere>12/04/2004</DataEspressioneParere> <CodiceParere>0001</CodiceParere> <EnteTerzo>0034-784627</EnteTerzo> </EventoSUAP> 3.1.1.4 Notifica conclusione di un procedimento Questo evento viene pubblicato dal Comune una volta terminato l iter di approvazione di un procedimento, tramite la propria applicazione SUAP Le informazioni che devono essere trasmesse in formato XML per pubblicare un evento di questo tipo sono: o L Identificativo Procedimento, e la Data di Attivazione del Procedimento, generati dal SIL del Comune. o L ID Universale Procedimento, generato dal Proxy Applicativo durante la pubblicazione dell evento Notifica Attivazione di Procedimento. Questo campo è facoltativo, ma la sua presenza consentirebbe una fase di validazione accurata, prima della pubblicazione
dell evento. o La Data di Conclusione del Procedimento. o L Esito della Conclusione del Procedimento. E prevedibile utilizzare un codice tipo Esito Positivo/Esito Negativo, oppure una forma più accurata di categorizzazione degli esiti. <EventoSUAP tipo= CONCLUSIONE > <Procedimento> <IDProcedimento>0123456789</IDProcedimento> <DataAttivazione>01/03/2004</DataAttivazione> </Procedimento> <IDUniversale> 001-0001-2004-000000000014 </IDUniversale> <IDUniversaleProcedimento> 001-0001-2004-000000000012 </IDUniversaleProcedimento> <EnteAttivatore>017048</EnteAttivatore> <SUAP>7274</SUAP> <DataConclusione>01/05/2004</DataConclusione> <CodiceEsito>0036</CodiceEsito> </EventoSUAP> Inoltre, il sistema è dotato di : Un applicazione web Monitor degli eventi pubblicati e sottoscritti attraverso i proxies ad uso del gestore del sistema, Un applicazione web che raccoglie i procedimenti amministrativi (Repository Regionale) che sono utilizzati dalle Amministrazioni per emettere le autorizzazioni e mostra l andamento delle comunicazioni tra Enti.(Metaiter). Un applicazione web, con requisiti funzionali minimali, per permettere agli enti non dotati di SIL automatizzato di espletare la sottoscrizione e la ricezione parere. Il Repository Regionale dei procedimenti ha lo scopo di raccogliere in forma strutturata gli endoprocedimenti, le best practices del sistema rete dei SUAP.; da un punto di vista funzionale, la soluzione consente l archiviazione delle diverse modalità con cui il singolo Suap realizza un procedimento unico Il Metaiter è l archivio che contiene gli stati di avanzamento delle pratiche cosi come generato attraverso gli eventi pubblicati dai SIL. La gestione del Meta-Iter permette al sistema Rete dei SUAP di soddisfare le seguenti problematiche:
Il mapping tra endoprocedimenti dei SUAP del territorio e quelli del dizionario centrale La notifica ad RT degli eventi relativi alle pratiche (meta-iter propriamente detto) Tracciamento da parte dei soggetti interessati dello stato di una pratica Il seguente è uno schema d insieme delle diverse componenti. Di recente il sistema è stato arricchito di una funzione di Esperto risponde realizzato per consentire di erogare un servizio consulenziale ai responsabili SUAP di regione Toscana. La realizzazione, basata su un CMS, consiste in una customizzazione del servizio di Forum in modo da consentire ad un pool di esperti di rispondere sulla base di Materie predefinite ed assegnate a ciascuno di essi. L utente può formulare quesiti attraverso il forum ed a ciascun componente del pool interessato viene recapitata in casella di mail il testo della domanda. L ambiente CMS, come detto opportunamente customizzato, consente l editing della risposta ; a risposta pubblicata l utente riceve un Mail di risposta disponibile. Sempre attraverso il CMS è esposto un set di informazioni utili all attività dei responsabili SUAP.