(PDF) Tesi di Giuseppe Borgese pdfsubjetc - CORE · Capitolo1 Introduzione Numerosi soggetti istituzionali sono oggi attivi nel promuovere l’adozione e lo svi-luppo del software Open

UNIVERSITA’ DI PISA

Facoltà di Scienze Matematiche, Fisiche e Naturali

Corso di Laurea Specialistica in Informatica

Tesi di Laurea Specialistica

Integrazione tra Strumenti di Protocollo e GestioneDocumentale per la Pubblica Amministrazione

Candidato:

Giuseppe Borgese

Relatori Controrelatore

Prof. Andrea Corradini Prof. Carlo Montangero

Prof. Tito Flagella

ANNO ACCADEMICO 2008/2009

A mamma e papà, sponsor e sostenitoridi questa mia fantastica avventura pisana

Indice

1 Introduzione 91.1 Sommario della tesi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2 Requisiti CNIPA per sistemi di protocollo e gestione documentale 152.1 Definizione di protocollo . . . . . . . . . . . . . . . . . . . . . . . . . 152.2 Introduzione e normativa di riferimento . . . . . . . . . . . . . . . . . 162.3 Adempimenti delle amministrazioni . . . . . . . . . . . . . . . . . . . 172.4 Cosa è stato fatto e tempistiche . . . . . . . . . . . . . . . . . . . . . 182.5 Definizione delle Aree Organizzative Omogenee AOO . . . . . . . . . 192.6 Funzionalità minime e requisiti . . . . . . . . . . . . . . . . . . . . . 192.7 Gestione documentale . . . . . . . . . . . . . . . . . . . . . . . . . . 202.8 Gestione dei flussi di lavoro . . . . . . . . . . . . . . . . . . . . . . . 212.9 Requisiti dei documenti informatici . . . . . . . . . . . . . . . . . . . 212.10 Conservazione ed esibizione dei documenti informatici . . . . . . . . . 222.11 Requisiti del sistema per la gestione dei flussi documentali . . . . . . 232.12 Verifica dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.13 Posta Elettronica Certificata PEC . . . . . . . . . . . . . . . . . . . 24

3 Linee Guida alla realizzazione per sistemi di protocollo elettronicoe gestione documentale 253.1 Quali funzionalità realizzare? . . . . . . . . . . . . . . . . . . . . . . 253.2 I livelli realizzativi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.2.1 Nucleo minimo di protocollo . . . . . . . . . . . . . . . . . . . 273.2.2 Gestione Documentale . . . . . . . . . . . . . . . . . . . . . . 283.2.3 Workflow Documentali . . . . . . . . . . . . . . . . . . . . . . 283.2.4 BPR (Business Process Reengineering) . . . . . . . . . . . . . 29

3.3 Come impostare l’architettura informatica? . . . . . . . . . . . . . . . 303.3.1 Soluzione minima . . . . . . . . . . . . . . . . . . . . . . . . . 303.3.2 Soluzione monolitica . . . . . . . . . . . . . . . . . . . . . . . 30

6 INDICE

3.3.3 Soluzione modulare . . . . . . . . . . . . . . . . . . . . . . . . 303.3.4 Soluzioni intermedie . . . . . . . . . . . . . . . . . . . . . . . 31

3.4 Architettura modulare . . . . . . . . . . . . . . . . . . . . . . . . . . 313.4.1 Servizi e Applicazioni . . . . . . . . . . . . . . . . . . . . . . . 32

4 E-prot: un sistema per il protocollo informatico 354.1 Descrizione del progetto . . . . . . . . . . . . . . . . . . . . . . . . . 354.2 Architettura del software . . . . . . . . . . . . . . . . . . . . . . . . . 384.3 Evoluzione nelle sue versioni . . . . . . . . . . . . . . . . . . . . . . . 38

4.3.1 Versione 1.0: l’originale rilasciata da Almaviva . . . . . . . . 394.3.2 Versione 1.1: la prima manutenzione di FlossLab . . . . . . . 414.3.3 Versione 1.2: nuove feature e documentazione per sviluppatori 414.3.4 Problema con Mac OS X . . . . . . . . . . . . . . . . . . . . . 434.3.5 Versione 1.3: nuove feature e documentazione utente estesa . . 43

4.4 Specifiche del protocollo . . . . . . . . . . . . . . . . . . . . . . . . . 454.4.1 Tabella di Controllo - sezione 1 . . . . . . . . . . . . . . . . . 464.4.2 Tabella di Controllo - sezione 2 . . . . . . . . . . . . . . . . . 514.4.3 Tabella di Controllo - sezione 3 . . . . . . . . . . . . . . . . . 524.4.4 Tabella di controllo di interoperabilità . . . . . . . . . . . . . 53

4.5 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5 Alfresco: un sistema documentale 575.1 Perché Alfresco e perché Open Source . . . . . . . . . . . . . . . . . 575.2 Il content repository . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.3 Il content repository di Alfresco . . . . . . . . . . . . . . . . . . . . . 595.4 Architettura Scalabile . . . . . . . . . . . . . . . . . . . . . . . . . . 595.5 Sicurezza e controlli di accesso . . . . . . . . . . . . . . . . . . . . . . 625.6 Servizi di libreria essenziali . . . . . . . . . . . . . . . . . . . . . . . 635.7 Integrazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635.8 Possibili utilizzi di Alfresco . . . . . . . . . . . . . . . . . . . . . . . . 635.9 Modulo per il Records Management . . . . . . . . . . . . . . . . . . . 66

5.9.1 Record Management: Introduzione . . . . . . . . . . . . . . . 665.9.2 Funzionamento del modulo . . . . . . . . . . . . . . . . . . . . 66

5.10 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

6 Verso l’integrazione di e-prot e Alfresco: motivazioni 696.1 Ciclo di vita del documento e necessità di sistemi documentali . . . . 696.2 Specifiche della dematerializzazione . . . . . . . . . . . . . . . . . . . 72

INDICE 7

6.2.1 Introduzione sulla dematerializzazione . . . . . . . . . . . . . 726.2.2 Il problema del diverso ambiente tecnologico . . . . . . . . . . 736.2.3 Il sistema di workflow . . . . . . . . . . . . . . . . . . . . . . 736.2.4 Le informazioni rimosse e i log . . . . . . . . . . . . . . . . . . 746.2.5 I supporti ottici . . . . . . . . . . . . . . . . . . . . . . . . . . 74

6.3 La gestione integrata dei documenti e il mantenimento degli archivi . 756.3.1 L’archivio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 756.3.2 La conservazione . . . . . . . . . . . . . . . . . . . . . . . . . 766.3.3 Il sistema documentario . . . . . . . . . . . . . . . . . . . . . 776.3.4 Il servizio per la gestione dei documenti e il mantenimento

dell’archivio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776.3.5 La gestione dell’archivio di deposito . . . . . . . . . . . . . . . 78

6.4 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

7 I Web Services di Alfresco 817.1 Il problema della documentazione . . . . . . . . . . . . . . . . . . . . 817.2 Connessione : prima di tutto . . . . . . . . . . . . . . . . . . . . . . . 82

7.2.1 I Web Service Client . . . . . . . . . . . . . . . . . . . . . . . 827.2.2 L’ambiente . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

7.3 Descrizione dei WS in Alfresco . . . . . . . . . . . . . . . . . . . . . . 857.3.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . 867.3.2 Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . 867.3.3 Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 877.3.4 Administration . . . . . . . . . . . . . . . . . . . . . . . . . . 87

7.4 Problemi nell’uso dei Web Services . . . . . . . . . . . . . . . . . . . 887.5 Creiamo un sovrastrato . . . . . . . . . . . . . . . . . . . . . . . . . . 90

7.5.1 I metodi della classe UsiWS . . . . . . . . . . . . . . . . . . . 917.6 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

8 Integrazione e-prot Alfresco 958.1 Installazione e-prot . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

8.1.1 Problemi d’installazione . . . . . . . . . . . . . . . . . . . . . 968.2 Organizzazione documenti in Alfresco . . . . . . . . . . . . . . . . . . 97

8.2.1 Sistema documentale . . . . . . . . . . . . . . . . . . . . . . . 978.2.2 Protocollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 978.2.3 Utenze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

8.3 E-prot: analisi dei sorgenti . . . . . . . . . . . . . . . . . . . . . . . 998.4 E-prot: modifica dell’architettura . . . . . . . . . . . . . . . . . . . . 101

8 INDICE

8.5 Difficoltà incontrate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1058.6 Ambiente di test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1068.7 Sincronizzazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

8.7.1 Spiegazione e funzionalità principali . . . . . . . . . . . . . . . 1068.7.2 La funzione di backup . . . . . . . . . . . . . . . . . . . . . . 1078.7.3 Architettura della classe SincronizzaDBtoAlfr.java . . . . . . . 108

8.8 Database e dettagli del codice . . . . . . . . . . . . . . . . . . . . . . 108

9 Conclusioni 111

Capitolo 1

Introduzione

Numerosi soggetti istituzionali sono oggi attivi nel promuovere l’adozione e lo svi-luppo del software Open Source in Italia. Particolare attenzione a questo temaè stata posto negli ultimi anni nell’ambito delle PA, tramite iniziative rilevanti,quali l’istituzione di una Commissione per il software a codice sorgente aperto nel-la Pubblica Amministrazione [INTRO4], la direttiva Stanca del 19 dicembre 2003[INTRO5], l’attività del Gruppo di lavoro “Codice Sorgente Aperto”, l’attivazionedell’Osservatorio Open Source da parte del CNIPA [INTRO6], l’organizzazione dinumerosi workshop specifici su questo tema, come ad esempio, la conferenza SAL-PA organizzata annualmente dalla Provincia di Pisa [INTRO7], il workshop Esperta[INTRO8], tenutosi nell’ambito della Conferenza Internazionale sui Sistemi OpenSource del 2006.

Nonostante tutto questo fermento, il Software Open Source nella PA non riescea decollare e finora non si è riusciti ad individuare misure adeguate per favorirnelo sviluppo. In effetti gli strumenti tradizionali di intervento non sono facilmenteapplicabili a questo contesto. Come per molte delle iniziative che hanno caratteriz-zato la crescita di Internet, anche il software Open Source non nasce da un’idea dibusiness pianificata a tavolino, ma piuttosto dall’iniziativa individuale di qualcuno,che reagisce a una propria precisa esigenza avviando un nuovo progetto con licenzaOpen Source. La successiva aggregazione attorno al progetto di un’ampia comunitàdi utenti e sviluppatori esperti del dominio applicativo diventa poi il meccanismonaturale di selezione dei progetti, che porta ad emergere solo quelli di maggiore qua-lità. Se non è facile, quindi, pianificare e facilitare la nascita di nuovi progetti OpenSource, è però possibile agire per favorire l’aggregazione e finalizzare gli sforzi deitanti sviluppatori ed utenti di software Open Source, già attivi o solamente poten-ziali, evitando così la dispersione di risorse e competenze potenzialmente prezioseper la Pubblica Amministrazione Italiana. Un tale ruolo di aggregazione può peral-

10 CAPITOLO 1. INTRODUZIONE

tro essere più efficace in domini ben delineati, dove ci sia un’effettiva condivisionedi interessi e competenze.

Un esempio di successo di un progetto di aggregazione di Software Open Sourceè il progetto Gov4J. Questi si muove in un dominio applicativo molto preciso, le in-frastrutture per la Pubblica Amministrazione Italiana, e in un contesto tecnologicoaltrettanto puntuale, il linguaggio Java e l’architettura J2EE. Il progetto Gov4J sipropone di portare avanti la progettazione e realizzazione di un framework OpenSource basato su Java, che copra i principali aspetti dell’infrastruttura applicati-va della Pubblica Amministrazione Italiana. Il progetto nasce dall’esigenza realedi due progetti Open Source, i progetti OpenSPCoop [OPSPC] e Japs [jAPS], icui fondatori sono convinti di poter ottenere significativi benefici dall’adozione diquest’approccio.

Il framework Gov4j comprende attualmente 6 progetti:

• OpenSPCoop è un’implementazione Open Source delle specifiche per la Coope-razione Applicativa nella Pubblica Amministrazione, generalmente note comeServizio Pubblico di Cooperazione (SPCoop).

• E-prot è una soluzione per il protocollo informatico e la gestione documentale,realizzata da Almaviva e FlossLab.

• jAPS è il primo framework italiano Open Source, sviluppato in Java, per larealizzazione di portali "accessibili" informativi e di servizi.

• j4Sign [j4sign] è un semplice insieme di API per la firma digitale, quando siarichiesto l’uso di un dispositivo crittografico (es: Smart Card).

• PICASSO ha l’obiettivo di realizzare una Piattaforma per l’Interoperabilità ela Cooperazione Applicativa, aderente alla normativa in vigore per le StruttureSanitarie ed Ospedaliere Italiane.

• JPEC [OPEC] si pone come obiettivo l’estensione dell’engine OpenSPCoop,per consentire l’utilizzo di trasmissioni certificate tramite un quasiasi sistemadi Posta Elettronica Certificata aderente allo standard corrente.

Dopo una fase di startup sono in corso varie attività d’integrazione tra le componentisoftware e il lavoro si concentra nel portare a maturità i progetti.

Questa tesi di laurea nasce all’interno della comunità Gov4j: il software e-protanalizzato ed esteso come vedremo afferisce a questa comunità. La tesi parte dal-lo studio delle specifiche CNIPA per la progettazione e messa in opera di sistemidi protocollo e archiviazione documentale, analizza la soluzione per il protocollo

elettronico presente nella comunity Gov4j, e propone una soluzione per estenderla,andando a soddisfare i requisiti più stringenti del CNIPA.

E-prot [eSITE] è un Sistema di Protocollo e Gestione documentale, conformealla normativa vigente, che si propone di offrire un efficace strumento per la pro-tocollazione e la gestione documentale a supporto delle attività di una pubblicaamministrazione sia centrale che locale. E-prot consente la gestione completa del-l’iter di un protocollo per Aree Organizzative Omogenee, ponendo quindi, le basiper il raggiungimento di obiettivi concreti e misurabili: adeguamento alla normativavigente che accompagna le innovazioni di tipo funzionale organizzativo, introdottedalle leggi e decreti più recenti; passaggio da un sistema di archiviazione “cartacea”dei documenti ad un sistema di “gestione documentale” elettronico, che consenta l’u-nivocità del documento e il puntuale reperimento; possibilità di utilizzo del databasedel sistema di archiviazione per accedere ai documenti con diverse chiavi di ricerca,parametrizzabili rispetto alle esigenze dei vari contesti di utente; miglioramento del-l’efficienza e dell’efficacia rispetto alle attività degli utenti che accedono alla bancadati/informazioni dei documenti; maggior sicurezza del servizio, nella conservazionee nella bassa circolazione degli originali, con l’effettiva certezza del reperimento diun documento e la possibile immediata verifica della relazione con altri documenti;possibile accesso contemporaneo allo stesso documento da parte di più utenti, supe-rando i problemi relativi alle consultazioni contestuali o ai documenti fuori posto;recupero di spazio e costi richiesto dall’archiviazione cartacea.

Come si vedrà nel dettaglio nei capitoli dedicati ad e-prot e alle specifiche delprotocollo, il software risultava funzionalmente incompleto in diversi punti nellaversione 1.0, ma la sua evoluzione fino alla versione 1.3 ha colmato molte delle la-cune presenti in un progetto giovane e con un obiettivo molto ambizioso. Tuttavia,analizzando le specifiche CNIPA, sono emersi diversi requisiti non ancora soddi-sfatti. La soluzione che noi proponiamo per colmare queste mancanze è costituitadall’integrazione di e-prot con un sistema documentale. Nella prospettiva di riusodel software esistente, naturale nel contesto Open Source, invece di sviluppare dazero un back-end documentale per e-prot, si è guardato ai prodotti Open Sourcedisponibili.

Come sistema di archiviazione documentale da integrare con e-prot è stato sceltol’Enterprise Content Management Alfresco [ALFIT]. Alfresco è un’ottima soluzioneOpen Source per la gestione del contenuto dei documenti e delle relative informazionidi un’azienda, offre le funzionalità mancanti e necessarie per e-prot. Tra le piùimportanti, permette anche, in prospettiva di gestire in maniera semplice ed efficaceil ciclo di vita dei documenti, un requisito da cui nessun software per il protocollo

12 CAPITOLO 1. INTRODUZIONE

elettronico può sottrarsi.Quindi abbiamo analizzato come integrare in e-prot Alfresco. Le scelte che si sono

prospettate erano due: interagire tramite api Java disponibili su Alfresco secondolo standard JSR, oppure utilizzare i Web Service forniti da Alfresco.

Allo scopo di garantire un accoppiamento più lasco tra le due componenti, lascelta progettuale è caduta sull’uso dei Web Services. Questa scelta può far sembra-re l’approccio semplice e immediato: se questo strumento fosse ben documentato,potrebbe essere realmente così. Purtroppo la documentazione è scarna, ridotta ameno dell’essenziale e molto spesso si è dovuti andare a tentativi, esperimenti esupposizioni per riuscire a far funzionare i Web Services in maniera corretta.

Il prodotto finale risultante da questa integrazione permette di avere un salva-taggio sincrono, dei documenti e delle meta informazioni relative al protocollo, suldocumentale Alfresco durante la normale esecuzione di e-prot, oppure, nel caso lasituazione lo richiedesse, si può effettuare una sincronizzazione posticipata del siste-ma documentale con le informazioni aggiornate di e-prot. Quest’ultima funzionalitàrealizza la funzione di backup tanto auspicata da utenti e committenti. In questomodo i requisiti del CNIPA sono soddisfatti e la gestione dei documenti protocollativiene notevolmente semplificata.

Possibili sviluppi del lavoro di tesi comprendono l’eliminazione completa deldatabase di e-prot, sostituendolo con il sistema documentale.

1.1 Sommario della tesi

L’ordine dei capitoli delle tesi segue all’incirca quello seguito durante il lavoro. Ilprimo passo in assoluto è stato uno studio approfondito e dettagliato delle specifichedel CNIPA per poi passare all’aspetto tecnologico.

Nel cap 2 si analizzano le specifiche per i sistemi di protocollo elettronico, poi sipassa alla gestione documentale, vedendo anche lo stato d’informatizzazione attualedella pubblica amministrazione italiana. Alla fine del capitolo si accenna ancheallo strumento della PEC (Posta Elettronica Certificata), parte fondamentale di unqualsiasi sistema di protocollo informatico in grado di interagire con l’esterno.

Nel cap 3 si analizzano i documenti del CNIPA che parlano di come svilupparei sistemi di protocollo e gestione documentale, analizzando i possibili livelli dove unsoftware di protocollo si può collocare.

Nel cap 4 si analizza nel dettaglio il progetto per il protocollo elettronico e-prot,vedendone l’evoluzione delle sue versioni, i pregi, ma anche le diverse mancanze. Lacompilazione della check list del CNIPA per sistemi di protocollo e gestione docu-

1.1. SOMMARIO DELLA TESI 13

mentale, effettuata dopo la fase di studio del progetto e-prot, è stata di fondamentaleimportanza per inquadrare il problema e focalizzare le carenze del progetto.

Nel cap 5 sono presenti tutte le informazioni di uno dei prodotti leader delmercato in quanto a gestione documentale, Alfresco. Il prodotto copre un ampioraggio di funzionalità. Nella tesi ci si è focalizzati su quelle che si sono usate eritenute più utili per assolvere le specifiche.

Nel cap 6 vengono posti sotto la lente d’ingrandimento tutti i requisiti che nonsono soddisfatti dal sistema di protocollo e come l’integrazione del documentalerisolve buona parte di queste problematiche. Non è solo uno studio di requisiti e distrumenti, ma una maniera più estesa di come utilizzare tutti gli strumenti presentiper raggiungere l’obiettivo chiesto nelle specifiche.

Nel cap 7 viene presento il lavoro che ha permesso la connessione tramite WebServices di Alfresco. Lo strumento Web Services di Alfresco si è dimostrato pa-recchio immaturo per quanto riguarda documentazione e la facilità di utilizzo. Dicontro l’operare a basso livello che consente lo stato attuale dei Web Services per-mette una notevole potenza di operazioni. Il problema è proprio capire come faree come non impiegare eccessivo tempo per compiere una qualsiasi operazione. L’o-biettivo di questo capitolo è stato raggiunto con la produzione di una classe cheha rappresentato circa la metà del codice scritto e una documentazione dettagliatadell’uso della classe.

Nel cap 8 si analizza nel dettaglio la struttura del codice di e-prot, mettendo inrisalto tutti i cambiamenti che sono stati fatti e le funzionalità che sono state svilup-pate per integrarlo con il sistema documentale Alfresco. L’obiettivo posto all’iniziodel lavoro di avere un software di protocollo integrato con un sistema documen-tale, in modo da soddisfare le molteplici specifiche ancora mancanti nelle versioniattualmente disponibili, può ritenersi soddisfatto.

14 CAPITOLO 1. INTRODUZIONE

Capitolo 2

Requisiti CNIPA per sistemi diprotocollo e gestione documentale

Questo capitolo riassume i requisiti emanati dal CNIPA per la messa in opera disistemi di protocollo elettronici e di archiviazione documentale. [LGUI]

2.1 Definizione di protocollo

Il protocollo è un sistema per tenere traccia di tutti i documenti che entrano o esconoda una pubblica amministrazione più formalmente potremmo dire che:

• il protocollo “classico” è uno strumento tecnico costituito dall’insieme delleprocedure e dagli elementi attraverso i quali i documenti vengono trattaticon finalità giuridico-probatorie e gestionali; certifica l’avvenuta ricezione ospedizione di un documento, la sua data e provenienza, indipendentementedalla sua regolarità, ed è idoneo a produrre effetti giuridici a favore o a dannodelle parti. (Università degli studi di Trieste - Normativa di Ateneo).

• Il protocollo informatico e, più in generale, la gestione elettronica dei flussidocumentali hanno la finalità di migliorare l’efficienza interna degli uffici attra-verso l’eliminazione dei registri cartacei, la riduzione degli uffici di protocolloe la razionalizzazione dei flussi documentali. L’adozione di tali sistemi mi-gliorerà inoltre la trasparenza dell’azione amministrativa attraverso strumentiche facilitano l’accesso allo stato dei procedimenti ed ai relativi documenti daparte di cittadini, imprese ed altre amministrazioni.

16CAPITOLO 2. REQUISITI CNIPA PER SISTEMI DI PROTOCOLLO E GESTIONE DOCUMENTALE

2.2 Introduzione e normativa di riferimento

Con la direttiva del Ministro per l’innovazione e le tecnologie del 9 dicembre 2002sono stati definiti gli indirizzi per l’adozione delle norme in materia di protocolloinformatico e di trattamento elettronico dei procedimenti amministrativi. Il pro-tocollo informatico e, più in generale, la gestione elettronica dei flussi documentalihanno la finalità di migliorare l’efficienza interna degli uffici attraverso l’eliminazio-ne dei registri cartacei, la riduzione degli uffici di protocollo e la razionalizzazionedei flussi documentali. L’adozione di tali sistemi migliorerà inoltre la trasparen-za dell’azione amministrativa attraverso strumenti che facilitano l’accesso allo statodei procedimenti ed ai relativi documenti da parte di cittadini, imprese ed altreamministrazioni.

Le Pubbliche Amministrazioni dal 1° gennaio 2004, ai sensi dell’art. 50, comma3, del decreto del Presidente della Repubblica 28 dicembre 2000, n. 445, dovranno,quindi, attenersi ai principi e alle norme di seguito indicati:

• adozione del protocollo informatico per la registrazione dei dati e documentidelle Amministrazioni

• trattamento dei procedimenti amministrativi gestito completamente in modoinformatico

• formazione e conservazione dei documenti informatici

• sottoscrizione elettronica dei documenti informatici

• gestione informatica del sistema documentale e dei flussi documentali

• accessi telematici ai dati, ai documenti, ai sistemi, alle banche dati

• sicurezza dei dati, dei documenti, delle tecnologie

Il documento indica due possibili strade per raggiungere gli obiettivi posti sopra:

1. Approccio in un’unica soluzione tutto il sistema passa dalla vecchia manieraal nuovo modo di gestire in una sola volta. Praticamente irrealizzabile

2. Approccio graduale che comincia convertendo il protocollo in formato digitaleper poi far transitare verso l’organizzazione elettronica tutto il sistema.

“Ogni Amministrazione, in base alla propria situazione organizzativa e tecnologica,ferma restando la scadenza del 1° gennaio 2004, dovrà valutare la possibilità diadottare l’uno o l’altro approccio, partendo eventualmente da quello minimale per

2.3. ADEMPIMENTI DELLE AMMINISTRAZIONI 17

poi evolvere gradualmente verso un sistema gestionale completamente automatizzato.In tutti i casi, il livello minimale deve essere finalizzato a creare non solo un sistemadi protocollo in linea con la normativa ma anche un sistema documentale che sicaratterizza per essere un sistema digitale, con la relativa eliminazione dei documenticartacei una volta trasformati in digitale. “

2.3 Adempimenti delle amministrazioni

Entro la data del 1° gennaio 2004 le pubbliche amministrazioni sono tenute adeffettuare i seguenti interventi

• introdurre piani di sviluppo per i sistemi informativi automatizzati;

• predisporre progetti per sostituire i registri di protocollo cartacei con quellielettronici;

• realizzare o revisionare i propri sistemi informativi.

Il sistema informativo viene considerato come un insieme integrato di dati, funzionie tecnologie, finalizzato non solo alla registrazione di dati e documenti in ingressoed in uscita, ma anche all’automazione del sistema procedimentale e documentale.

Ci sono dei passi intermedi che le pubbliche amministrazioni devono compiere:

• individuare le Aree Organizzative Omogenee (AOO) e i relativi uffici all’internodi ognuna.

• ogni AOO deve avere una casella di posta elettronica certificata che deve esserecomunicata per iscrivere la AOO nell’indice delle P.A.

• comunicare il responsabile della AOO al Centro Tecnico.

• adottare, per ogni AOO istituita, il manuale di gestione.

• pubblicare e rendere accessibile tramite internet il manuale di gestione chedescrive il sistema di gestione e di conservazione dei documenti e fornisce leistruzioni necessarie per il corretto funzionamento del servizio per la tenutadel protocollo informatico.

• predisporre un progetto per la progressiva messa in opera del protocollo inte-grato con la posta elettronica certificata.

18CAPITOLO 2. REQUISITI CNIPA PER SISTEMI DI PROTOCOLLO E GESTIONE DOCUMENTALE

2.4 Cosa è stato fatto e tempistiche

Per verificare alla data attuale di stesura della tesi (giugno 2009) il livello d’informa-tizzazione della pubblica amministrazione in Italia, si sono andati a ricercare dellestatistiche sul sito del CNIPA trovando quanto segue.

Tra i compiti istituzionali del CNIPA vi è quello di redigere e pubblicare ognianno una relazione che illustra lo stato dell’informatizzazione nelle PA, con par-ticolare riferimento al livello di utilizzazione effettiva delle tecnologie e ai relativicosti e benefici. A tale scopo il CNIPA raccoglie e analizza una notevole mole diinformazioni fornita dalle Pubbliche Amministrazioni Centrali.

Il Decreto Legislativo 12 febbraio 1993 n. 39, all’Art. 9 stabilisce che il CNI-PA deve presentare "al Presidente del Consiglio dei Ministri, entro il 30 aprile diogni anno, una relazione che dia conto dell’attività svolta nell’anno precedente edello stato dell’informatizzazione nelle amministrazioni, con particolare riferimentoal livello di utilizzazione effettiva delle tecnologie e ai relativi costi e benefici. IlPresidente del Consiglio dei Ministri trasmette entro trenta giorni la relazione alParlamento." Al fine di conferire al CNIPA tutte le conoscenze utili per compilarela relazione, ogni dirigente responsabile per i sistemi informativi automatizzati, inrelazione all’amministrazione di appartenenza, trasmette al Centro entro il mese difebbraio di ogni anno una relazione sullo stato dell’automazione a consuntivo del-l’anno precedente, con l’indicazione delle tecnologie impiegate, delle spese sostenute,delle risorse umane utilizzate e dei benefici conseguiti.

Al momento attuale sul sito del CNIPA nella sezione sullo stato d’informatizza-zione della pubblica amministrazione [STAT-INF] è presente il report dell’anno 2006[REP06] (che è stato consegnato il 4 luglio 2007 e non il 30 aprile come richiesto neldecreto legislativo citato sopra). Dal questo documento notiamo quanto segue.

L’ultima rilevazione sullo stato di diffusione e utilizzo dei sistemi di protocolloinformatico e gestione documentale evidenzia ancora, nonostante i molti progettiormai conclusi o in fase finale, significativi ritardi. Solo il 43% delle amministrazioniha raggiunto un tasso adeguato di diffusione del protocollo, mentre sono ancora piùarretrate l’automazione del flusso documentale e l’archiviazione elettronica.

La soglia del 43% è effettivamente preoccupante, si dovrebbe certamente pre-tendere dalle pubbliche amministrazioni il rispetto dei tempi. L’autorità massimain Italia nel settore informatico dovrebbe essere d’esempio e almeno lei dovrebberispettare le scadenze. Invece a giugno del 2009 non è presente il report dell’anno2007 e non si sa quando sarà presente quello del 2008.

2.5. DEFINIZIONE DELLE AREE ORGANIZZATIVE OMOGENEE AOO 19

2.5 Definizione delle Aree Organizzative Omogenee

AOO

Una corretta definizione delle AOO consente di ottenere una diminuzione e sempli-ficazione dei sistemi di protocollo attuali. Se un documento viene spedito da unaAOO all’altra deve essere protocollato, se, invece, viene assegnato all’interno dellastessa, non è necessario fare nessuna registrazione di protocollo. Il fenomeno dellaframmentazione dei registri di protocollo è una delle maggiori cause di inefficienzenella gestione dei documenti delle Pubbliche Amministrazioni. Tra le conseguenzenegative derivanti da tale frammentazione va certamente citata la ripetuta protocol-lazione del documento (con annesse le operazione di registrazione di dati ridondanti)ad ogni passaggio, anche tra strutture interne alla stessa Amministrazione, oltre allenotevoli difficoltà di reperimento del documento protocollato tali da rendere, para-dossalmente, l’individuazione della collocazione fisica del documento un problemasecondario rispetto all’individuazione del registro di protocollo in cui esso è statoregistrato.

Una AOO può essere definita come un insieme di unità organizzative dell’Ammi-nistrazione che usufruiscono, in modo omogeneo e coordinato, degli stessi servizi perla gestione dei flussi documentali. Una unità organizzativa associata ad una AOOè un utente dei servizi messi a disposizione dalla AOO stessa. Una AOO offre, inparticolare, il servizio di protocollo dei documenti in entrata ed in uscita che avvie-ne utilizzando una unica sequenza numerica, rinnovata ad ogni anno solare, propriaall’area stessa.

Al termine di questo processo di analisi, si deve comunicare al Centro Tecnicoper la R.U.P.A. la casella ufficiale di posta elettronica per l’iscrizione delle AOOnell’Indice della Pubblica Amministrazione.

2.6 Funzionalità minime e requisiti

Vi sono alcune funzionalità minime che le amministrazioni devono garantire per laregistrazione di protocollo. Le operazioni di registrazione e di segnatura di proto-collo e di classificazione costituiscono attività necessarie per la tenuta del sistema digestione informatica dei documenti da parte delle pubbliche amministrazioni.

In particolare, per la registrazione si devono rispettare le seguenti indicazioni:

• numero di protocollo del documento generato automaticamente dal sistema eregistrato in forma non modificabile;

20CAPITOLO 2. REQUISITI CNIPA PER SISTEMI DI PROTOCOLLO E GESTIONE DOCUMENTALE

• data di registrazione di protocollo assegnata automaticamente dal sistema eregistrata in forma non modificabile;

• mittente per i documenti ricevuti o, in alternativa, il destinatario o i destinatariper i documenti spediti, registrati in forma non modificabile;

• oggetto del documento, registrato in forma non modificabile;

• data e protocollo del documento ricevuto, se disponibili;

• l’impronta del documento informatico (la funzione SHA-1), se trasmesso pervia telematica, costituita dalla sequenza di simboli binari in grado di identifi-carne univocamente il contenuto, registrata in forma non modificabile.

Nelle funzionalità minime deve essere garantito che il sistema di protocollo sarà co-stituito da risorse informatiche destinate non solo alla registrazione e alla segnatura,ma anche alla conservazione della documentazione, al fine di rendere concreto l’ac-cesso alla documentazione da parte dei dipendenti abilitati sia in modalità localeche remota.

Vi sono altri requisiti che un sistema di protocollo, anche con funzionalità mini-me, deve rispettare:

• Il sistema deve consentire la produzione del registro giornaliero di protocollo;

• L’assegnazione delle informazioni nelle operazioni di registrazione di proto-collo è effettuata dal sistema in unica soluzione, con esclusione di interventiintermedi, anche indiretti, da parte dell’operatore, garantendo la completezzadell’intera operazione di modifica o registrazione dei dati.

2.7 Gestione documentale

La gestione documentale si occupa della gestione dei documenti in forma avan-zata. Essa esula dalle funzionalità di protocollo minimo viste prima. L’ambi-to di gestione documentale è molto vasto, ma fondamentalmente si occupa delladematerializzazione dei documenti cartacei e delle disponibilità di questi a livellocartaceo.

Prevede le seguenti attività:

• registrazione con trattamento delle immagini (acquisizione digitalizzata deidocumenti cartacei);

• assegnazione per via telematica al destinatario;

2.8. GESTIONE DEI FLUSSI DI LAVORO 21

• gestione avanzata della classificazione dei documenti;

• collegamento dei documenti alla gestione dei procedimenti.

2.8 Gestione dei flussi di lavoro

Anche la gestione dei flussi di lavoro, come la gestione documentale, è una funziona-lità avanzata. Essa prevede la reingegnerizzazione dei processi dell’Amministrazioneal fine di una loro successiva informatizzazione. In particolare, vengono gestiti, me-diante sistemi integrati di flussi di lavoro tutti quei processi che possiedono i requisitidi complessità, ripetitività e stabilità dell’iter. Lo scopo da raggiungere è la revisionee la razionalizzazione dei processi amministrativi.

La gestione dei flussi documentali realizza le seguenti funzionalità:

• informatizzazione dei processi relativi ai flussi documentali in entrata e inuscita;

• informatizzazione dei processi relativi ai flussi documentali interni;

• integrazione con i flussi di lavoro.

2.9 Requisiti dei documenti informatici

La formazione e la conservazione dei documenti informatici delle Pubbliche Ammi-nistrazioni devono essere effettuate secondo i seguenti requisiti:

• identificabilità del soggetto che ha formato il documento informatico e del-l’amministrazione di riferimento;

• sottoscrizione, quando prescritta, dei documenti informatici tramite la firmadigitale ;

• idoneità dei documenti ad essere gestiti mediante strumenti informatici e adessere registrati mediante il protocollo informatico;

• accessibilità ai documenti informatici tramite sistemi informativi automatiz-zati;

• leggibilità dei documenti;

• interscambiabilità dei documenti.

22CAPITOLO 2. REQUISITI CNIPA PER SISTEMI DI PROTOCOLLO E GESTIONE DOCUMENTALE

Il legislatore sottolinea che solo l’esistenza di tutti i requisiti rende validi e rilevantii documenti a tutti gli effetti di legge.

I formati dei documenti devo sottostare ai seguenti requisiti:

• consentire, nei diversi ambiti di applicazione e per le diverse tipologie di trat-tazione, l’archiviazione, la facilità di lettura, l’interoperabilità e l’interscambiodei documenti; Questo requisito è tutt’altro che banale, data la varietà di for-mati disponibili e la varietà di software che possono produrre questi formati.Si pensi che un documento testuale, prodotto da un editor di testo come Mi-crosoft Word, soffre in alcuni casi della difficoltà di lettura anche tra versionidifferenti della stessa applicazione oppure della stessa versione per sistemi ope-rativi differenti. Microsoft Word è disponibile anche per Mac OS X, oltre cheper Microsoft Windows, ma la perfetta compatibilità dei formati tra questedue piattaforme è tutt’altro che garantita. Il problema si aggrava ulterior-mente se ci troviamo a leggere documenti prodotti da applicazioni per ufficioMicrosoft con la suite Open Office. Una possibile soluzione, non ancora ot-timale però, è stata pensata dalla FlossLab nella versione 1.3 del software diprotocollo e-prot che converte tutti i documenti in pdf prima di acquisirli nelsuo sistema di protocollo, usando il convertitore disponibile in Open Office;

• la non alterabilità del documento durante le fasi di accesso e di conservazione;

• la possibilità di effettuare operazioni di ricerca tramite indici di classificazionee di archiviazione, nonché sui contenuti dei documenti;

• l’immutabilità nel tempo del contenuto e della sua struttura (per cui i do-cumenti informatici non devono contenere macroistruzioni o codice esegui-bile, tali da attivare funzionalità che possano modificarne la struttura o ilcontenuto);

• la possibilità di integrare il documento informatico con immagini, suoni e video,purché incorporati in modo irreversibile

2.10 Conservazione ed esibizione dei documenti in-

formatici

Attraverso la conservazione elettronica dei documenti si eviteranno duplicazioni eaccumuli di copie cartacee e verrà favorita la trasformazione graduale degli archivicartacei della P.A. in sistemi informativi automatizzati ad alto livello di sicurezza

2.11. REQUISITI DEL SISTEMA PER LA GESTIONE DEI FLUSSI DOCUMENTALI 23

ed affidabilità. Inoltre, sarà possibile realizzare sistemi di ricerca più efficaci e piùefficienti.

2.11 Requisiti del sistema per la gestione dei flussi

documentali

Il sistema per la gestione dei flussi documentali deve:

• fornire informazioni sul legame esistente tra ciascun documento registrato, ilfascicolo ed il singolo procedimento cui esso è associato;

• consentire il rapido reperimento delle informazioni riguardanti i fascicoli, ilprocedimento ed il relativo responsabile, nonché la gestione delle fasi delprocedimento;

• fornire informazioni statistiche sull’attività dell’ufficio;

• consentire lo scambio di informazioni con sistemi per la gestione dei flussidocumentali di altre amministrazioni al fine di determinare lo stato e l’iter deiprocedimenti complessi.

Il sistema di gestione dei documenti e dei relativi flussi deve quindi essere progettatoe realizzato in tutte le sue componenti “prima” dell’automazione del sistema stesso.Le amministrazioni devono definire la tipologia dei documenti, le relazioni tra do-cumenti e procedimenti, la struttura dei fascicoli relativi ai procedimenti, l’iter deiprocedimenti stessi, i sistemi di ricerca dei documenti e dei fascicoli. Non si trattasolo di una operazione informatica, ma di un intervento complesso di tipo documen-tale, organizzativo, procedurale e tecnico che deve impegnare tutta la dirigenza e/oi responsabili delle unità organizzative.

2.12 Verifica dei requisiti

Per aiutare le amministrazioni nella tenuta del protocollo, nella gestione dei docu-menti, e soprattutto, nella verifica delle funzionalità del sistema di protocollo e diarchiviazione documentale, è stato redatto il documento “Supporto alla verifica ealla valutazione dei Sistemi di protocollo informatico e di gestione dei flussi docu-mentali” denominato in breve CHECK LIST. Questo documento contiene una listadi controllo per la verifica della conformità di tali sistemi ai requisiti desumibili dalquadro di riferimento normativo e tecnologico. Nel capitolo riguardante il software

24CAPITOLO 2. REQUISITI CNIPA PER SISTEMI DI PROTOCOLLO E GESTIONE DOCUMENTALE

di protocollo scelto si utilizza questo strumento, evidenziando i requisiti rispettati equelli ancora da sviluppare.

2.13 Posta Elettronica Certificata PEC

Per scambiare documenti protocollati in formato digitale, lo strumento che il soft-ware di protocollo deve usare è la PEC [DEMA]. La PEC è un sistema di postaelettronica nel quale è fornita al mittente documentazione elettronica, con valen-za legale, attestante l’invio e la consegna di documenti informatici. “Certificare”l’invio e l’avvenuta consegna significa fornire al mittente, dal suo gestore di posta,una ricevuta che costituisce prova legale dell’avvenuta spedizione del messaggio edell’eventuale allegata documentazione. Allo stesso modo, quando il messaggio per-viene al destinatario, il gestore invia al mittente la ricevuta di avvenuta (o mancata)consegna con precisa indicazione temporale. Nel caso in cui il mittente smarriscale ricevute, la traccia informatica delle operazioni svolte viene conservata per unperiodo di tempo definito a cura dei gestori, con lo stesso valore giuridico dellericevute.

Capitolo 3

Linee Guida alla realizzazione persistemi di protocollo elettronico egestione documentale

In questo capitolo vengono definite in maniera più dettagliata i requisiti e le normedi sviluppo, su cui si dovrebbero basare i software per la pubblica amministrazionerelativi al protocollo informatico e alla gestione dei flussi documentali. [GED1]

3.1 Quali funzionalità realizzare?

Il sistema di protocollo informatico non è uno strumento a sè stante, ma deve esserein stretta relazione con altri strumenti di gestione, come il sistema di produzione,archiviazione e conservazione dei documenti, strumenti per la garanzia di accessoagli atti amministrativi, tracciamento ed esecuzione dei flussi di lavoro. Il protocolloclassico, prima realizzato tramite la trascrizione di informazioni in grossi registricartacei, adesso ormai in tutte le amministrazioni realizzato tramite la compilazionedi una form elettronica, deve essere in connessione con tutte le soluzioni di accessoe gestione dei documenti.

Nella figura 3.1 vengono definite tutto le possibili integrazioni del protocollo (el-lisse al centro), con processi di workflow, gestione documentale o acquisizione otticacartacea con funzionalità di OCR. Queste sono solo possibili soluzioni che un’am-ministrazione può decidere d’implementare attorno al nucleo minimo obbligatorio.Decidere d’implementare questi servizi aggiuntivi e come farlo spetta alla pubblicaamministrazione, dopo un’analisi approfondita delle proprie esigenze rapportate allepossibilità di sviluppo.

26CAPITOLO 3. LINEE GUIDA ALLA REALIZZAZIONE PER SISTEMI DI PROTOCOLLO ELETTRONICO E GESTIONE DOCUMENTALE

Figura 3.1: possibili integrazioni dei sistemi di protocollo

Le normative assumono una forma molto dettagliata solo nel regolamentare lecosiddette operazioni di “registrazione” e “segnatura” di protocollo ovvero, in ultimaanalisi, le minime operazioni necessarie per la tenuta di un registro informatico chetiene traccia degli eventi di transito attraverso i confini dell’AOO dei documentiufficiali, sia in ingresso che in uscita. Più specificamente, l’effettuazione di una“registrazione di protocollo” corrisponde alla assunzione delle seguenti responsabilitàda parte dell’amministrazione:

1. Certificare l’esistenza del documento almeno a partire da una certa data;

2. Nel caso di documenti ricevuti, certificare il fatto che il documento è entratonei confini dell’amministrazione e che subirà una qualche forma di trattamento.

3.2 I livelli realizzativi

Ogni amministrazione deve individuare il proprio “livello realizzativo”, corrispon-dente alle funzionalità che essa stessa vuole realizzare. In via indicativa sono statiindicati quattro livelli organizzativi visibili in figura.

Descriviamo ogni livello.

3.2. I LIVELLI REALIZZATIVI 27

Figura 3.2: i livelli organizzativi

3.2.1 Nucleo minimo di protocollo

Questo è il livello che tutte le pubbliche amministrazioni devono garantire. Pernucleo minimo di protocollo si intende la gestione informatica dei documenti inmodalità base.

Esso deve fornire i seguenti servizi:

• registrazione in un archivio informatico delle informazioni riguardanti un do-cumento (numero, data, mittente/destinatario, oggetto, ecc.);

• segnatura sul documento delle informazioni riguardanti il documento stesso(numero, data, AOO);

• classificazione d’archivio per una corretta organizzazione dei documenti, cor-rispondenti alle funzionalità minime previste dall’art. 7 del DPR 428/98, allequali può eventualmente essere aggiunta anche la indicazione dell’assegnatariosul registro di protocollo.

Limitarsi a questo livello di realizzazione significa, in estrema sintesi:

• circoscrivere l’obiettivo dell’intervento alla registrazione dei documenti e allaloro organizzazione nel sistema documentario;

• prendere in considerazione solamente i documenti protocollati;

• coinvolgere nel processo di informatizzazione esclusivamente l’Ufficio Proto-collo;

28CAPITOLO 3. LINEE GUIDA ALLA REALIZZAZIONE PER SISTEMI DI PROTOCOLLO ELETTRONICO E GESTIONE DOCUMENTALE

• consentire l’accesso in via informatica alle informazioni relative ai documenti,ma non ai documenti stessi.

3.2.2 Gestione Documentale

La gestione documentale è la gestione avanzata dei documenti informatici e permettedi esaltare tutte le potenzialità dei documenti informatici.

Essa prevede le seguenti operazioni:

• registrazione con trattamento delle immagini (scannerizzazione dei documenticartacei);

• assegnazione per via telematica al destinatario;

• gestione avanzata della classificazione dei documenti (utilizzo di thesauri evocabolari controllati, ecc.);

• collegamento dei documenti alla gestione dei procedimenti;

• in maniera opzionale potrebbe aggiungersi come funzionalità per alcuni docu-menti la possibilità di avere un trattamento particolare che potrebbe ancheportare a una pubblicazione su web e quindi ad aumentare la comunicazioneglobale.

In questo modo si tende a sviluppare il patrimonio informativo dell’amministrazioneconsiderando tutti i documenti e non solo quelli protocollati, coinvolgendo tuttigli uffici alla produzione e messa in mostra di documenti consentendo la massimadisponibilità anche all’esterno dell’amministrazione.

3.2.3 Workflow Documentali

Nella categoria dei workflow documentali sono compresi tutti i processi documentalidi una amministrazione escludendo quelli primari.

La gestione dei workflow prevede le seguenti attività:

• informatizzazione dei processi relativi ai flussi documentali in entrata;

• informatizzazione dei processi relativi ai flussi documentali in uscita;

• informatizzazione dei processi relativi ai flussi documentali interni;

• integrazione con gli eventuali workflow relativi ai processi primari.

3.2. I LIVELLI REALIZZATIVI 29

3.2.4 BPR (Business Process Reengineering)

In questo livello rientrano i processi che prevedono una reingegnerizzazione che abbiacome fine una informatizzazione. Vengono gestiti tramite sistemi di workflow tuttiquei processi che hanno requisisti di ripetitività e stabilità. Questa livello che staalla base della piramide non è obiettivo che si può raggiungere per ultimo, mase lo si vuole raggiungere deve essere il primo passo. Questo perchè, al contrariodei livelli sovrastanti, non è una funzione tecnologica/organizzativa aggiuntiva maesclusivamente un organizzazione logica. Per questo motivo, se non si effettua questopasso all’inizio, diventa impossibile effettuarlo successivamente.

Figura 3.3: come raggiungere il BPR

Il BPR rappresenta una scelta importante per molti motivi:

• assetto organizzativo e qualità;

• pianificazione strategica;

• controllo di gestione;

• monitoraggio dei costi e tempi.

Ristrutturare in meglio la gestione dei processi ha degli impatti notevoli in terminidi complessità, costi, formazione e gestione dei ruoli. Questo livello va conside-rato con cautela, perchè spesso non è necessario riorganizzare, quando si passa ainformatizzare il sistema.

30CAPITOLO 3. LINEE GUIDA ALLA REALIZZAZIONE PER SISTEMI DI PROTOCOLLO ELETTRONICO E GESTIONE DOCUMENTALE

3.3 Come impostare l’architettura informatica?

Dalle informazioni analizzate prima possiamo dedurre come sviluppare al megliol’architettura informatica. Si evince chiaramente che il sistema di protocollo deveessere fortemente integrato con il resto del sistema informativo dell’amministrazione.

3.3.1 Soluzione minima

La realizzazione della soluzione minima comprende le funzioni essenziali di registra-zione e classificazione. Realizzando la soluzione minima, si può tenere il protocolloinformatico come unico strumento informatizzato dell’intera area organizzativa omo-genea, in quanto potrebbero non esistere altri strumenti per la gestione correlata aldi fuori del protocollo come un sistema di gestione documentale.

Questo scenario può essere ragionevole se il volume delle informazioni che trattal’amministrazione è talmente ridotto da non portare vantaggi economici dall’utilizzodegli strumenti informatici, oppure nel caso che il personale sia fortemente imprepa-rato a supportare un livello informatico più alto. Si dovrebbe cercare di superare ilimiti della preparazione del personale, ma per un comune di 500 abitanti un sistemadi workflow per esempio non è affatto necessario.

3.3.2 Soluzione monolitica

Uno scenario tipico nelle amministrazioni può essere un software incentrato sul siste-ma di protocollo che permetta di gestire soluzioni più avanzate, per esempio la pos-sibilità di gestire forme più o meno sofisticate di workflow e/o accesso ai documentiprotocollati secondo svariate modalità di ricerca.

In applicazioni di questo tipo va creata all’interno della base di dati la strutturaorganizzativa con i tutte le informazioni dei soggetti responsabili. L’applicazionedi protocollo in questa soluzione si trova a invadere tutti i campi del patrimonioinformativo indipendentemente dal fatto che si trovino in un ambito di gestionedocumentale.

Questa soluzione è particolarmente adatta a contesti amministravi dove preva-le una forte staticità dei processi. Questo però lega fortemente l’amministrazioneimpedendone una evoluzione al pari passo con le tecnologia che il mercato offre.

3.3.3 Soluzione modulare

Uno scenario più evoluto rispetto alla soluzione monolitica è quello in cui il nucleominimo del protocollo sia visto come un modulo applicativo che svolga le funzioni

3.4. ARCHITETTURA MODULARE 31

previste sotto il punto di vista del protocollo, ma che sia accessibile da parte dialtre applicazioni, o componenti, che costituiscono il sistema informatico dell’am-ministrazione. In altre parole, il servizio di protocollo è un servizio richiamabileda altre parti (e quindi integrabile nei più vari contesti applicativi). Devono esserequindi disponibili, oltre al protocollo, altri servizi che costituiscono il patrimoniocomune dell’amministrazione, ovviamente rispettando le regole di accessibilità.

3.3.4 Soluzioni intermedie

Lo scenario che si viene spesso a profilare è quello della soluzione intermedia tra lamonolitica e la modulare. Una soluzione ricorrente è quella di un database centra-lizzato che offra ai client la possibilità di accedere e modificare alcuni documentie/o processi. La decisione di modularizzare un sistema di gestione documentale edi protocollo informatico è una decisione che va presa dopo un’attenta analisi deicosti/benefici.

3.4 Architettura modulare

Nella figura 3.4 è presente una possibile gestione dell’architettura modulare per unsistema di protocollo e di gestione documentale.

Figura 3.4: un’architettura modulare

32CAPITOLO 3. LINEE GUIDA ALLA REALIZZAZIONE PER SISTEMI DI PROTOCOLLO ELETTRONICO E GESTIONE DOCUMENTALE

• In alto a sinistra troviamo i servizi di certificazione, cioè il sistema di protocollocon gestione della firma digitale. Questi possono essere viste come clienti.

• In alto a destra troviamo i servizi più avanzati di gestione documentale, cheinvece possono essere visti come serventi.

• Al secondo livello, freccia orizzontale, troviamo le modalità d’interconnes-sione dei servizi verso i sistemi di persistenza (ultimo livello in basso) o dicomunicazione (terzo livello).

• Al terzo livello, all’interno del rettangolo, vi sono i servizi di workflow o servizidi comunicazione esterna PEC o altro

• All’ultimo livello, in basso possono esserci le entità più concrete database oaltre infrastrutture tecnologiche già esistenti prima della modularizzazione.

3.4.1 Servizi e Applicazioni

I servizi rappresentano il patrimonio di una pubblica amministrazione e devonoessere in grado di resistere in un arco temporale medio. Per esempio un servizio didocument warehouse (detto anche sistema documentale) che contiene i documentiprotocollati e classificati deve persistere nel tempo. Avere un sistema documentalenon vuol dire avere un solo database perchè poi a livello sottostante l’informazionepuò essere suddivisa. L’accesso però avviene a monte nel servizio di repository (laparte alta se ci si vuol riferire alla figura 3.4 ). La base documentale potrebbe essereun punto di accesso per l’integrazione di diverse applicazioni ed è proprio questol’obiettivo a cui le specifiche vogliono tendere e quello che si è cercato di fare nellavoro di tesi.

La centralizzazione di informazioni riguardanti informazioni condivise non è peròda intendersi per i soli documenti, ma anche per tutte le informazioni di gestionedella struttura organizzativa, presenza e ruolo di soggetti esterni, privilegi di accessoalle risorse per i soggetti ecc. Queste informazioni che si possono condividere tra leapplicazioni, portando un miglioramento nella complessità di gestione delle stesse,potrebbero formare una sorta di directory dell’amministrazione.

La possibilità di accedere a un dato servizio o informazione deve avere il conno-tato di continuità di accesso nel tempo.

Il sistema non deve essere rigido, ma altamente adattabile alle necessità del-l’amministrazione. Facciamo un esempio. Il servizio di protocollazione si occupaprincipalmente di protocollare un documento, ma può presentarsi un ulteriore ca-so. Un documento viene posto in un certo punto ed è previsto che, se non subisce

3.4. ARCHITETTURA MODULARE 33

ulteriori modifiche entro un limite di tempo diventi un documento ufficiale. Per farquesto può esserci un motore di wokflow che si occupa alla scadenza del timeoutdi protocollare il documento. Questo può essere realizzato senza che il servizio diprotocollo debba intervenire in alcun modo.

Bisogna porre una certa attenzione alle tecnologie che si utilizzano per costruirele applicazioni e motori di workflow in modo da usare soluzioni possibilmente aperte,leader del mercato, quindi durevoli nel tempo e di facile utilizzo da più applicazioni.

34CAPITOLO 3. LINEE GUIDA ALLA REALIZZAZIONE PER SISTEMI DI PROTOCOLLO ELETTRONICO E GESTIONE DOCUMENTALE

Capitolo 4

E-prot: un sistema per il protocolloinformatico

4.1 Descrizione del progetto

Il software e-prot è stato sviluppato per offrire uno strumento Open Source atto allaprotocollazione e gestione documentale per attività di una pubblica amministrazione.Grazie a questo prodotto, è possibile dare maggior ordine ed efficienza all’azioneamministrativa, ridurre il volume cartaceo, tramite lo scambio e l’elaborazione deidocumenti in formato digitale. Inoltre, sarà possibile adempiere alle norme di leggein materia di protocollo informatico.

Come si vede nelle figure sottostanti, e-prot svolge due funzioni indipendenti:

• Il sistema di protocollo in figura 4.1;

• Il sistema di gestione documentale in figura 4.2.

E-prot realizza la gestione completa dell’iter di un protocollo per Aree Organiz-zative Omogenee (figura 4.3) che vanno create dall’amministratore tramite la scheda“Amministrazione” subito dopo l’installazione del software.

E-prot permette:

• adeguamento delle pubbliche amministrazioni alle normative in materia diprotocollo, innovazioni di tipo funzionale organizzativo, introdotte dalle leggie decreti più recenti;

• passaggio da un sistema di archiviazione “cartacea” dei documenti ad un si-stema di “gestione documentale” elettronico, che consente la univocità deldocumento e il puntuale reperimento;

36CAPITOLO 4. E-PROT: UN SISTEMA PER IL PROTOCOLLO INFORMATICO

Figura 4.1: e-prot schermata iniziale

Figura 4.2: e-prot gestione documentale

4.1. DESCRIZIONE DEL PROGETTO 37

Figura 4.3: e-prot gestione AOO

• possibilità di utilizzo del database del sistema di archiviazione per accedere aidocumenti con diverse chiavi di ricerca sui metadati del documento o ricerchefull text;

• maggior sicurezza del servizio, nella conservazione e nella bassa circolazio-ne degli originali, con l’effettiva certezza del reperimento di un documento ela possibile immediata verifica della relazione con altri documenti grazie allacreazione di fascicoli e faldoni virtuali;

• possibile accesso contemporaneo allo stesso documento da parte di più utenti,in modalità di sola lettura o di creazione collaborativa di documenti, superandoi problemi relativi alle consultazioni contestuali o ai documenti fuori posto;

• recupero di spazio, costi e tempo richiesto dall’archiviazione cartacea rispettoa una digitale;

E-prot realizza tutto questo tramite un’entità chiamata nella sua documentazionearchivio corrente o archivio di lavoro. Questi sono organizzati in un unico databasepostgresql esterno all’applicazione da configurare in fase d’installazione.

Le funzioni principali disponibili in e-prot sono:

• funzione di protocollo;

• acquisizione, classificazione, consultazione, produzione collaborativa, controlloe gestione dei documenti;

• gestione delle versioni dei documenti modificati;

38CAPITOLO 4. E-PROT: UN SISTEMA PER IL PROTOCOLLO INFORMATICO

• controllo e gestione dei fascicoli.

E’ possibile definire per ciascun utente livelli di accesso ai documenti in base al ruoloricoperto.

4.2 Architettura del software

Il prodotto e-prot ha subito diversi cambiamenti che analizzeremo meglio nel para-grafo dedicato alla differenza tra le sue versioni. L’architettura fondamentale è peròrimasta la stessa.

Le operazioni vengono eseguite tramite interfaccia web da un qualsiasi brow-ser, comunicando tramite HTTP con l’application server. Il server scelto per e-protè Apache Tomcat per la sua semplicità e leggerezza, rispetto a un ambiente piùpesante da avviare e configurare (ma anche più performante) come JBoss. I filedi configurazione sono predisposti per funzionare con Tomcat, ma possono esserefacilmente adattati anche per JBoss. I dati sono memorizzati su database e sonoaccessibili dall’applicazione tramite connessione TCP/IP attraverso lo standard dicomunicazione Java JDBC. Il database di default è postgresql da configurare se-guendo le istruzioni presenti nella cartella “doc” e gli script della cartella “db”. Ilprogramma è anche predisposto per funzionare con database Oracle per realtà chehanno bisogno di maggiori performance.

Nell’Application Server risiede tutta la logica dell’applicazione: distribuita sudiversi strati (“n-tier”), ovvero, logica, interfaccia utente, persistenza dei dati, etc,sono indipendenti l’uno dall’altro. La comunicazione tra questi diversi strati avvienetramite il modello ad oggetti (Object Model). Nello specifico, utilizza il framework“Jakarta Struts” per implementare un architettura di tipo “MVC”.

Ecco un schema un po’ più dettagliato dell’architettura.Vedremo nel capitolo 8 che è dedicato alla modifica dell’architettura un’analisi

dello schema delle classi e dei package.

4.3 Evoluzione nelle sue versioni

Al momento dell’inizio del lavoro, ottobre 2008, erano disponibili tramite la comunityGov4j due versioni di e-prot la 1.0 sviluppata da Almaviva (www.almavivaitalia.it)e la versione 1.1 realizzata dall’azienda cagliaritana FlossLab (www.flosslab.it) cheestendeva la 1.0 con alcune funzionalità aggiuntive. Il fatto di appartenere a unacomunity ha facilitato le operazioni di sviluppo del software per la possibilità avuta

4.3. EVOLUZIONE NELLE SUE VERSIONI 39

Figura 4.4: e-prot schema architettura

di scambiare pareri, opinioni e condividere problemi e soluzioni con altri utilizzatorie sviluppatori.

4.3.1 Versione 1.0: l’originale rilasciata da Almaviva

La versione 1.0 è stata la prima versione del software, è stata rilasciata nella primametà del 2007 da Almaviva. E’ stata anche la prima versione che ho provato nellavoro di studio e analisi. Durante la messa in funzione del sistema, mi sono accortoche il progetto era praticamente abbandonato a se stesso. Scarsa documentazione siadal punto di vista dell’utilizzo che dal punto di vista delle modalità d’installazione.Il download era possibile da due fonti:

1. dal sito di Almaviva, dove era presente una pagina evidentemente non piùcurata da diverso tempo che dava degli errori al tentativo di scaricamento;

2. dall’svn di Gov4j dove veniva riportato il comando svn da eseguire per fare ilcheck-out del progetto, ma addirittura mancavano username e password chevenivano poi richiesti. Dopo aver fatto un po’ di password guessing, sonoriuscito a scaricare con username “eprot” e password “eprot”.

Della versione scaricata non si riusciva a fare il deploy sotto Tomcat, come indicavanole istruzioni, a causa di due errori. Analizzando i log e i file di configurazione, hocostatato la mancanza di una classe che inspiegabilmente non era nei sorgenti edegli errori di sintassi in un file di configurazione del database. Commentando

40CAPITOLO 4. E-PROT: UN SISTEMA PER IL PROTOCOLLO INFORMATICO

nel file web.xml la classe EtichetteServlet e correggendo degli errori di sintassi inclasses/DbConfig.properties si riesce ad ottenere il deploy corretto dell’applicazione.

A un primo utilizzo viene subito fuori l’immaturità del software che genera saltua-riamente eccezioni che vengono visualizzate dentro il browser in maniera piuttostopreoccupante per un utente comune.

L’immagine nella brochure di presentazione è quantomeno fuorviante, se si pre-ferisce evitare il termine ingannevole.

Figura 4.5: e-prot 1.0 presentazione

Tutti i servizi mostrati sono servizi esterni al software che devono essere gestitidall’abilità dell’utente. Si sa che l’utente delle pubbliche amministrazioni è tutt’altroche pratico nell’utilizzo degli strumenti informatici più semplici, figuriamoci in quellicon un grado di difficoltà appena superiore. Inoltre, dalle domande sulla mailing listl’integrazione sembra tutt’altro che immediata e senza problemi.

Durante l’installazione e l’utilizzo ho provato a contattare Almaviva, ma nonho ricevuto mai alcuna risposta. Fortunatamente, la FlossLab ha preso in mano ilprogetto.

4.3. EVOLUZIONE NELLE SUE VERSIONI 41

4.3.2 Versione 1.1: la prima manutenzione di FlossLab

La prima edizione di e-prot, targata FlossLab la 1.1 è stata resa disponibile nell’svnil 9 ottobre del 2008, ha fornito le seguenti nuove funzionalità ben documentatenella guida: oggettario, assegnazione multipla per competenza, multi-mittente, im-port del titolario, stampa della ricevuta. La nuova release non presentava grandimiglioramenti e aveva bene o male gli stessi problemi della 1.0. La grande differenzaperò era nell’impegno della nuova azienda che ha deciso d’investire sul prodotto. Nelperiodo successivo al rilascio della prima versione, la mailing list era tempestata dimessaggi riguardanti problemi d’installazione, suggerimenti di nuove features, testdi alcune funzionalità ecc. L’azienda cagliaritana è stata molto attiva, ha raccoltotutti i feedback della mailing list, rispondendo in maniera pronta e precisa alle do-mande, correggendo gli errori, aggiornando i documenti d’installazione e preparandola nuova versione del software.

Anche lei al primo rilascio del software ha destato serie perplessità causate da ungrave errore sul ripristino del db. Veniva fornito un file di .backup per db postgresche causava un errore al momento dell’esecuzione sulla base di dati. L’aziendaperò è stata pronta e, grazie ai feedback degli utenti/sviluppatori, ha prontamentecorretto il doppio errore sullo script di creazione della base di dati e sulle informazionid’installazione.

4.3.3 Versione 1.2: nuove feature e documentazione per svi-

luppatori

Il 12 dicembre del 2008 è una data da ricordare per lo sviluppo di sistemi di protocolloOpen Source per la pubblica amministrazione italiana: infatti è stata resa disponibilesul sito della FlossLab la versione 1.2 di e-prot.

La versione 1.2 ha fatto compiere un salto di qualità notevole al prodotto e-prot.Ha portato una serie di funzionalità in più qui elencate sinteticamente. Per maggioriinformazioni si può vedere [DOCE]

• Mittente o Destinatario non modificabile - è una funzionalità richiesta dallanorma CNIPA già considerata nel paragrafo della check list

• Popolamento rapido oggettario e mittenti - consente un notevole risparmio ditempo, una facility importante richiesta dagli utenti della comunity

• Dashboard è nella prima pagina che compare all’utente, quando accede alsistema. Esso consente di visualizzare un riepilogo delle “cose da fare” inmaniera immediata e veloce.

42CAPITOLO 4. E-PROT: UN SISTEMA PER IL PROTOCOLLO INFORMATICO

• Nuova interfaccia utente: l’interfaccia utente è stata migliorata e resa piùintuitiva. Anche se devo dire che la scelta dei bottoni verde scuro con lescritte nere non facilita moltissimo l’utente a causa del basso contrasto. In unsoftware usato da utenti che spesso hanno dai quaranta anni in su e spessocon una vista non più acutissima non è una cosa così trascurabile. Sarebbe dariconsiderare l’accoppiamento dei colori dei pulsanti.

• Gestione dei permessi: ogni utente possiede un insieme di permessi che rap-presentano l’insieme di voci di menu (e dunque di URL) che può utilizzare.

Il miglioramento, a mio parere più importante, passando dalla versione 1.1 alla ver-sione 1.2 è stata la scelta che nei documenti di FlossLab viene denominata comeDynamic Web Project. Al contrario delle prime versioni di e-prot, che non faci-litavano affatto lo sviluppo collaborativo lasciando con pochissime, per non direnulle, informazioni sulla compilazione del progetto, l’azienda cagliaritana ha decisodi creare una vera e propria miniguida per configurare l’IDE Eclipse (uno dei piùusati e diffusi framework per lo sviluppo sotto Java, ma non solo, a livello mondiale,fra l’altro anche Open Source). La guida è strutturata molto bene, sia per sistemiLinux che Windows, inizialmente illustra la preparazione dell’ambiente, descriven-do quali software bisogna installare (PostgreSQL, pgAdmin III, Tomcat 6, EclipseJ2EE Edition) e le configurazioni base che bisogna darvi, poi passa al check-outdel progetto dall’svn utilizzando Eclipse, come configurare Eclipse per far partireTomcat al suo interno. Questo passo permette di ridurre notevolmente i tempi disviluppo. Infine conclude con alcuni dettagli utili per il deploy esterno ad Eclipse,una volta terminato il progetto.

Aver avuto questa guida così ben dettagliata ha permesso uno sviluppo più rapidodell’integrazione di e-prot con Alfresco, anche se ci sono da aggiungere alcuni dettagliche possono migliorarla. Di ciò si parlerà in seguito, quando si analizzerà il lavorodi sviluppo del codice. La cura nel preparare queste informazioni per incoraggiarelo sviluppo del software da parte di terze parti indica una vera e reale adesioneall’idea di Open Source e sviluppo collaborativo. Chi mette a disposizione i sorgentionline solo perché obbligato dalla licenza, quando estende un software open, nonaderisce veramente alla filosofia del codice aperto. Durante la fase iniziale del lavoro,ho analizzato altri software open che non fornivano neanche una miniguida per lostartup del progetto, ma soprattutto non indicavano (ne quanto meno includevano)tutte le librerie necessarie, inoltre qualcuno non forniva tutte le classi, rendendoimpossibile non solo lo sviluppo, ma neanche l’avvio del progetto, dimenticanza oscelta volontariamente ostracista non è dato saperlo. La FlossLab con la versione 1.2

4.3. EVOLUZIONE NELLE SUE VERSIONI 43

ha fatto scuola ad altri enti di come si estende e si mette veramente a disposizionedella comunità un prodotto Open Source.

4.3.4 Problema con Mac OS X

E-prot viene rilasciato per funzionare sotto Linux o Windows. Dato che è un’ap-plicazione Java, si potrebbe naturalmente pensare che la famosa portabilità di Javanon causi problemi nell’uso del software in altri contesti.

Le prove dalla versione 1.0 sono state effettuate su una macchina con Mac OSX 10.4 sotto architettura Power PC (PPC) e il risultato finale è stata la correttacompilazione e deploy del software sotto Tomcat. Passando alla versione 1.2 invecesi è presentato un errore insormontabile per utenti del sistema della mela. Grazieal supporto della comunity di e-prot, che comprende anche un altro utente Mac OSoltre me, ho potuto costatare un problema di compatibilità di librerie.

Il problema risiede sulla diversa gestione delle librerie Java da parte della Apple,impedendo in tal modo la compilazione corretta di e-prot. Infatti, è ben noto chele distribuzioni Java per Mac Os sono rilasciate direttamente dalla Apple e nondalla Sun. Si è anche provato a compilare e-prot 1.2 su Linux e Windows e poitrasferirlo su Mac (nelle versioni 10.4.11, 10.5.6 e 10.5.6 Server - sia su PPC che Intel)senza risultato. Inoltre ho notato alcuni problemi, ritengo per la diversa gestionedelle librerie, nell’esecuzione di Tomcat 6 su mac rispetto a Linux e Windows. Daalcune ricerche che ho condotto sui vari forum, soprattutto su quello Apple, hoeffettivamente riscontrato questa diversità di gestione di Java.

Per queste ragioni si è dovuto abbandonare lo sviluppo sotto Mac OS X passandoesclusivamente a Linux

4.3.5 Versione 1.3: nuove feature e documentazione utente

estesa

La versione 1.3 è stata rilasciata sull’svn di Gov4j il 9 aprile del 2009 quando nelprogetto di questa tesi l’integrazione tra e-prot e Alfresco era già in fase avanzata.Per questo motivo non si è tenuto conto di quest’ultima versione, ma quella diriferimento è rimasta la 1.2.

Con questa release si evince una chiara intenzione di FlossLab d’investire for-temente sul prodotto e-prot. A un utente delle precedenti versioni salta subitoall’occhio la presenza di un manuale di ben 66 pagine sull’uso di e-prot. Sembreràforse strano, ma nelle precedenti versioni non era presente un manuale, ma solo unhelp online che spiegava cosa faceva una singola parte dell’interfaccia, mancando

44CAPITOLO 4. E-PROT: UN SISTEMA PER IL PROTOCOLLO INFORMATICO

quindi una trattazione più sistematica e ordinata. I cambiamenti che hanno portatoa un cambio di rotta sostanziale sono però altri:

• Salvataggio su filesystem (protocollo e documentale): da questa versione ifile che vengono allegati al protocollo e al documentale vengono salvati nelfilesystem e non più come BLOB (Binary Large OBject, collezioni di datibinari memorizzati come singola entità in un DBMS) nel database.

• Conversione in pdf: i file allegati al protocollo e al documentale vengono auto-maticamente convertiti in PDF. Poiché la conversione è basata su OpenOffice,i formati supportati per la conversione sono gli stessi di OpenOffice. I formatinon supportati vengono allegati nel loro formato originario.

• Ricerca full text: è stata implementata utilizzando il framework Lucene, nellaversione 1.2 era disponibile tramite SQL dato che i file si trovavano nel db.Secondo la responsabile del progetto di FlossLab, grazie a questo cambiamento,le ricerche full text sono più performanti.

Il cambiamento più rilevante è il modo diverso di memorizzare i file e di non usarepiù il database per questa funzione. In questo modo il progetto e-prot si divide indue strade perché l’estensione, che è stata sviluppata in questa tesi, terrà la memo-rizzazione dei documenti sul db e permetterà un opzionale salvataggio su Alfresco.L’altra invece memorizzerà i file sul File System in formato PDF appoggiandosi aOpen Office. Queste divisioni accadono nei progetti Open Source giovani che man-cano di un coordinamento centrale dove come in questo caso due entità lavorano auno stesso progetto e non conoscono bene i rispettivi lavori.

La conversione in pdf genera però alcuni dubbi, perchè va a cambiare il formatodel documento ricevuto prima di protocollarlo e memorizzarlo. Questo perchè si staprotocollando un documento che non è quello originale. Inoltre, il convertitore diOpen Office non è detto che riesca a convertire fedelmente il documento ricevuto.E’ vero che, se si mantiene il formato originale, è possibile che venga interpretato inmaniera diversa in base allo strumento di visualizzazione, ma il formato del docu-mento è sempre quello originale e non una versione che potrebbe essere alterata. Chiè avvezzo a usare Open Office per aprire documenti Microsoft Office complessi cono-sce tutte le possibili problematiche di alterazione della formattazione originale. Lasoluzione ideale sarebbe spedire i documenti direttamente in formato pdf, ma questodipende dall’utente, una forzatura di ciò da parte dello strumento di protocollazioneforse sarebbe una limitazione eccessiva.

Una motivazione per la scelta di questa caratteristica di conversione forzata è lascelta di passare a un formato non modificabile, requisito ripetuto molteplici volte

4.4. SPECIFICHE DEL PROTOCOLLO 45

in tutti i documenti di specifica e della check-list. Personalmente non mi trovod’accordo con questa scelta, perchè il requisito di non modificabilità deve esseregarantito dal sistema una volta effettuata la protocollazione del documento e nondal formato del documento. Anche perchè l’immodificabilità del documento nonpuò che essere garantita fino allo scaricamento dal sistema di protocollo. Una voltascaricato, l’utente può comunque modificare sia un pdf che un documento in un altroformato, la modifica di un pdf è un’operazione più complessa rispetto alla modificadei normali formati da ufficio, ma sempre possibile. Un vantaggio di questa sceltadi conversione sta nel fatto che se in un documento sono presenti macro con laconversione in pdf queste non hanno più effetto. La scelta di inglobare macro inun documento da protocollare rappresenta comunque un tentativo di operazionequantomeno sospetta, che potrebbe portare a un annullamento dell’operazione diprotocollazione.

Come si può vedere il formato dei documenti è un argomento abbastanza spinoso.Una possibile soluzione potrebbe essere forzare la conversione in pdf solo dopo averaccertato la presenza di macro nel documento. Si dovrebbe però effettuare un’ul-teriore operazione che porterebbe uno spreco di risorse. Andrebbe fatta un’analisiapprofondita con dei test sulla conversione per verificarne la fattibilità.

4.4 Specifiche del protocollo

Il CNIPA impone alle pubbliche amministrazioni di: “rendere i propri sistemi con-formi alla circolare Aipa n.28 del 7 maggio 2001 per la trasmissione e scambio didocumenti elettronici aventi validità giuridica e testare i loro sistemi sulla correttaricezione, interpretazione e protocollazione di tali messaggi”. Per poter effettua-re questo, il CNIPA utilizza il sistema della check list per verificare la conformitàdi un generico sistema di protocollo informatico ai requisiti desumibili dal quadronormativo di riferimento.

La check-list si rivolge principalmente ai produttori di software, per verificare lecaratteristiche del proprio programma, ma anche all’operatore della pubblica am-ministrazione che mette in funzione il sistema. Sono state valutate tramite questostrumento solo le funzioni che riguardano l’analisi del software e-prot nella versionedi riferimento per questa tesi la 1.2, escludendo le caratteristiche che riguardanola corretta configurazione del sistema operativo che ospita l’application server, ildatabase, o il browser.

Per maggiori dettagli di ogni requisito si rimanda al documento disponibile sulsito del CNIPA [CHEKLIST]

46CAPITOLO 4. E-PROT: UN SISTEMA PER IL PROTOCOLLO INFORMATICO

La tabella di controllo è stata compilata accuratamente durante il lavoro ditesi, per capire meglio come e dove migliorare e-prot. La check list è un ottimostrumento, ma non è l’unico. Va infatti integrata con lo studio dei documenti dispecifica visti nei capitoli precedenti, senza i quali rimane uno strumento scarno etroppo sintetico per effettuare un’analisi approfondita. Per poter compilare la tabellaserve una conoscenza molto approfondita del software e-prot, per compilarne alcunipunti si è contattato l’azienda FlossLab con cui si sono scambiati anche pareri persviluppi futuri. Dopo aver compilato la check list e studiato in maniera approfonditai documenti, si sono trovate le motivazioni che hanno portato alle profonde scelte dimodifica del software di protocollo.

L’uso della tabella è abbastanza intuitivo:Il primo campo indica il livello del requisito

• Livello “A” verifica dei requisiti riferiti alle funzionalità minime

• Livello “AA” verifica dei requisiti alle funzionalità minime e quelli riferiti alsupporto della gestione documentale e dei flussi informativi

• Livello “AAA” verifica dei requisiti riferiti ai livelli precedenti e ad ulteriorirelativi a funzionalità aggiuntive

• Livello “B” verifica dei requisiti riferiti relativi all’interoperabilità

Il secondo campo indica il codice numerico che identifica il requisito utile se si vuoleavere una descrizione più approfondita di quella presente in tabella. Il terzo campoè il riferimento normativo relativo alla legge. Il quarto campo è una descrizionesintetica, e infine i campi Si e No dove è presente una spunta che indica se il requisitoè soddisfatto o meno.

4.4.1 Tabella di Controllo - sezione 1

In questa tabella si verificano dei requisiti riferiti alle funzionalità minime del sistema

Requisiti Funzionali/Tecnologici

Liv. Cod.RiferimentoNormativo

Descrizione Si No

A R.1.1 [TU4452000/52/1/a]Garanzie di sicurezza e integrità delsistema

A R.1.2 [DPCM311000/7/1]Requisiti minimi di sicurezza del sistemaoperativo dell’elaboratore

4.4. SPECIFICHE DEL PROTOCOLLO 47

A R.1.3[DPCM311000/7/2]

[TU445/52/1e]

Disponibilità di meccanismi che consenta-no il controllo differenziato dell’accesso al-le risorse del sistema per ciascun utente ogruppo di utenti in condizioni di sicurezzanel rispetto delle disposizioni in materiadi tutela delle persone e di altri soggettirispetto al trattamento dei dati personali

A R.1.4 [DPCM311000/7/3]

Tracciamentoento da parte del sistema diprotocollo informatico di qualsiasi eventodi modifica delle informazioni trattate eindividuazione del suo autore

A R.1.5 [DPCM311000/7/4]Protezione delle registrazioni di traccia-mento da modifiche non autorizzate

A R.1.6 [TU4452000/52/1/b]Garanzie sulla corretta e puntuale regi-strazione di protocollo dei documenti inentrata e in uscita

A R.1.7 [TU4452000/53/1/a]Generazione automatica del numero diprotocollo e sua registrazione in forma nonmodificabile

A R.1.8 [TU4452000/57/1]

Il numero di protocollo è un numero pro-gressivo e costituito da almeno sette cifrenumeriche e la numerazione di protocolloè rinnovata ogni anno solare

A R.1.9 [TU4452000/53/1/b]Generazione automatica della data di regi-strazione di protocollo e sua registrazionein forma non modificabile

A R.1.10 [TU4452000/53/1/c]

Registrazione in forma non modificabi-le del mittente per idocumenti ricevutio, in alternativa, del destinatario o deidestinatari per i documenti spediti

A R.1.11 [TU4452000/53/1/d]Registrazione in forma non modificabiledell’oggetto del documento

A R.1.12 [TU4452000/53/1/e]Possibilità di registrare la data e protocol-lo del documento ricevuto, se disponibili

48CAPITOLO 4. E-PROT: UN SISTEMA PER IL PROTOCOLLO INFORMATICO

A R.1.13 [TU4452000/53/1/f]

Registrazione in forma non modificabiledell’impronta del documento informatico,se trasmesso per via telematica, costituitadalla sequenza di simboli binari in gradodi identificarne univocamente il contenuto

A R.1.14 [DPCM311000/17/2]

L’impronta è generata utilizzando lafunzione di hash, definita nella normaISO/IEC 10118-3:1998, Dedicated Hash-Function 3, corrispondente alla funzioneSHA-1

A R.1.15 [TU4452000/53/3]

Assegnazione delle informazioni nelle ope-razioni di registrazione di protocollo ef-fettuata dal sistema in un’unica soluzio-ne, con esclusione di interventi interme-di, anche indiretti, da parte del’operato-re, garantendo la completezza dell’interaoperazione di modifica o registrazione deidati

A R.1.16[TU4452000/54/1][DPCM311000/8]

Esistenza di una funzione di annullamen-to delle informazioni non modificabili delleregistrazioni e/o dell’intera registrazione

A R.1.17[TU4452000/54/1][DPCM311000/8]

Memorizzazione delle informazioni annul-late nella base di dati

A R.1.18 [TU4452000/54/2]

Mantenimento per le informazioni annul-late di una dicitura o un segno in posi-zione sempre visibile e tale da consenti-re la lettura di tutte le informazioni ori-ginarie unitamente alla data, all’identifi-cativo dell’operatore ed agli estremi delprovvedimento d’autorizzazione

A R.1.19 [TU4452000/55/1]Apposizione in forma permanente e nonmodificabile della segnatura di protocolloall’originale del documento

4.4. SPECIFICHE DEL PROTOCOLLO 49

A R.1.20[TU4452000/55/1][DPCM311000/9/1]

Presenza nella segnatura di protocollo del-le informazioni minime per l’identificazio-ne univoca di ciascun documento: codi-ce identificativo dell’Amministrazione, co-dice identificativo dell’Area OrganizzativaOmogenea, progressivo di protocollo, datadi protocollo

A R.1.21 [TU4452000/55/2]L’operazione di segnatura del protocolloeffettuata contemporaneamente all’opera-zione di registrazione di protocollo

A R.1.22 [TU4452000/55/3]

La segnatura di protocollo può includereulteriori informazioni quali il codice iden-tificativo dell’ufficio cui il documento è as-segnato o il codice dell’ufficio che ha pro-dotto il documento, l’indice di classifica-zione del documento e ogni altra informa-zione utile o necessaria, qualora tali infor-mazioni siano disponibili già al momentodella registrazione di protocollo

A R.1.23 [TU4452000/53/2]Produzione del registro giornaliero diprotocollo

A R.1.24 [TU4452000/63/5]

Esistenza di un’apposita funzione di re-cupero dei dati che consenta l’inserimen-to delle informazioni relative ai documen-ti protocollati in emergenza, in seguitoad interruzione nella disponibilità dellaprocedura informatica, senza ritardo alripristino delle funzionalità del sistema

A R.1.25 [TU4452000/63/5]

Attribuzione durante la fase di ripristino aciascun documento registrato in emergen-za di un numero di protocollo del sistemainformatico ordinario

A R.1.26 [TU4452000/63/5]Correlazione stabile tra il numero di pro-tocollo del sistema informatico ordinariocon il numero utilizzato in emergenza

50CAPITOLO 4. E-PROT: UN SISTEMA PER IL PROTOCOLLO INFORMATICO

A R.1.27 [TU4452000/52/1/c]

Fornitura da parte del sistema delle infor-mazioni sul collegamento esistente tra cia-scun documento ricevuto dall’amministra-zione e i documenti dalla stessa formatinell’adozione dei provvedimenti finali

A R.1.28 [TU4452000/52/1/f]Disponibilità di funzioni per il supportoe la gestione del sistema di classificazioned’archivio (titolario d’archivio)

A R.1.29 [derivato]

Funzioni che consentano l’utilizzo di stru-menti di navigazione grafica e di brow-sing all’interno del sistema di classifica-zione adottato (a fini di selezione, ricerca,visualizzazione)

A R.1.30 [TU4452000/52/1/f]Corretta organizzazione dei documentinell’ambito del sistema di classificazioned’archivio adottato

A R.1.31 [derivato]Funzione di numerazione progressiva au-tomatica dei fascicoli

A R.1.32 [derivato] Funzioni di gestione dei fascicoli V

A R.1.33 [derivato]Funzioni per la creazione, la gestio-ne e la manutenzione dell’organigrammadell’amministrazione

A R.1.34 [derivato]

Il sistema deve gestire un indice dei cor-rispondenti in modo da facilitare le ope-razioni di protocollazione dei documen-ti ricevuti e spediti. Deve essere pos-sibile effettuare delle ricerche ed alimen-tare l’indice attraverso le operazioni diprotocollazione

A R.1.35 [TU4452000/52/1/d]Reperimento delle informazioni riguar-danti i documenti registrati

A R.1.36 [TU4452000/58/2]Esistenza di criteri di selezione basati sututti i tipi d’informazioni registrate per laricerca delle informazioni del sistema

A R.1.37 [TU4452000/58/3]Possibilità di elaborazioni statistiche sulleinformazioni registrate

4.4. SPECIFICHE DEL PROTOCOLLO 51

• R1.1 e R1.2 non dipendono dal software e-prot ma dalla corretta configurazioneglobale del sistema da parte del sistemista

4.4.2 Tabella di Controllo - sezione 2

In questa tabella si verificano i requisiti legati alle funzionalità minime e quelli riferitial supporto della gestione documentale e dei flussi informativi.

Requisiti Funzionali/Tecnologici

Liv. Cod. RiferimentoNormativo

Descrizione Si No

AA R.2.1 [derivato] Acquisizione dei documenti cartacei informato immagine attraverso uno scanner

AA R.2.2 [derivato] Acquisizione di documenti da file system VAA R.2.3 [derivato] Acquisizione documenti da casella di

posta elettronicaV

AA R.2.4 [derivato] Gestione dei principali formati dei docu-menti elettronici

AA R.2.5 [derivato] Immodificabilità dei documenti acquisitinel sistema e protocollati

AA R.2.6 [derivato] Meccanismi per la gestione dell’accesso aidocumenti in modifica da parte di piùutenti (check-in/check-out)

AA R.2.7 [derivato] Visualizzazione e stampa dei documenti VAA R.2.8 [derivato] Funzionalità di OCR ausiliari alle opera-

zioni di protocollazioneV

AA R.2.9 [derivato] Funzionalità di OCR per consentire ricer-che full text sui documenti acquisiti informato immagine

AA R.2.10 [TU4452000/58/2] Ricerche full text estese al contenuto deldocumento informatico

AA R.2.11 [derivato] Trasparenza dei sistemi hardware dimemorizzazione in modalità “on-line”,“near-line” ed “off line”

• R 2.1 - 2.8 - 2.9 non sono presenti in e-prot direttamente ma si devono eseguireesternamente e poi immettere i file risultanti

• R 2.11 non è rispettato perché tutte le memorizzazioni/elaborazioni dei do-

52CAPITOLO 4. E-PROT: UN SISTEMA PER IL PROTOCOLLO INFORMATICO

cumenti avvengono nel database. Per effettuare gli spostamenti bisogna agiremanualmente sul db, questo, oltre ad essere un’operazione delicata, è tutt’altroche trasparente. Anche se nel manuale della versione 1.0 dichiara la presenzadei tre archivi richiesti nelle specifiche in verità c’è un solo archivio: quello deldb.

4.4.3 Tabella di Controllo - sezione 3

In questa tabella si verificano i requisiti riferiti ai livelli precedenti, oltre a quellirelativi a funzionalità aggiuntive

Requisiti Funzionali/Tecnologici

Liv. Cod.RiferimentoNormativo

Descrizione Si No

AA R.3.1 [derivato] Il sistema deve prevedere la definizione ela gestione di Access Control List (ACL)sui documenti e sui fascicoli

AA R.3.2 [derivato] Gestione di meccanismi di visibilità deidocumenti sulla base della posizionegerarchica degli utenti e dei ruoli

AA R.3.3 [derivato] Invio di notifiche per gli eventi piùsignificativi che accadono all’interno delsistema

AA R.3.4 [derivato] Gestione dell’assegnazione telematica aidiversi soggetti a cui è attribuita laresponsabilità dei procedimenti attivatidal documento o ai quali il documento ècorrelato (assegnazione perresponsabilità)

AA R.3.5 [derivato] Gestione dell’assegnazione telematica adaltri soggetti ai quali il documento ècorrelato (assegnazione per conoscenza)

AA R.3.6 [derivato] Gestione delle sotto assegnazioni V

AA R.3.7 [derivato] Evidenza della presa in carico di undocumento assegnato

AAA R.3.8 [derivato] Possibilità di gestire liste di attivitàpendenti per persone o ruoli

AA R.3.9 [derivato] Trasmissione dei fascicoli V

4.4. SPECIFICHE DEL PROTOCOLLO 53

AA R.3.10 [derivato] Tracciamento da parte del sistema dellemovimentazioni dei documenti e deifascicoli

AAA R.3.11 [derivato] Supporto alla formazione dei documenti,alla regolamentazione ed al tracciamentodella redazione delle diverse versioni diun documento (versioning)

AAA R.3.12 [derivato] Ciclo di approvazione dei documenti V

AAA R.3.13 [derivato] Integrazione della firma elettronica

AA R.3.14 [derivato] Meccanismi per la gestione del ciclo divita del fascicolo

AA R.3.15 [derivato] Gestione dell’archivio corrente V

AA R.3.16 [TU4452000/67/1] Gestione dell’archivio di deposito V

AA R.3.17 [TU4452000/69/1] Funzioni di supporto all’archiviazionesostitutiva

AA R.3.18[TU4452000/65/1/a][TU4452000/65/1/b]

Correlazione dei fascicoli ai procedimentiamministrativi

AAA R.3.19 [derivato] Integrazione con motori di Workflow V

• 3.3 discutendo con FlossLab si è concluso che non si riesce a definire quali sonoqueste operazioni quindi per adesso questa funzionalità è stata trascurata

• 3,13 e 3.17 - La firma digitale non viene creata all’interno dell’applicazione maesternamente con appositi strumenti. E-prot permette di leggere i file firmatidigitalmente (la loro conformità).

4.4.4 Tabella di controllo di interoperabilità

In questa tabella sono verificati i requisiti legati all’interoperabilità.

Requisiti Funzionali/Tecnologici

Liv. Cod.RiferimentoNormativo

Descrizione Si No

54CAPITOLO 4. E-PROT: UN SISTEMA PER IL PROTOCOLLO INFORMATICO

B R.4. 1[DPCM311000/15/1][TU4452000/14/1]

Lo scambio dei documenti informatici sog-getti alla registrazione di protocollo è ef-fettuato mediante messaggi conformi aisistemi di posta elettronica compatibilicon il protocollo SMTP/MIME definitonelle specifiche pubbliche RFC 821-822,RFC 2045-2049 e successive modificazionio integrazioni

B R.4. 2 [DPCM311000/15/2] Corrispondenza di una unica operazionedi registrazione di protocollo ad ogni mes-saggio di posta elettronica ricevuto da unaarea organizzativa omogenea

B R.4. 3 [DPCM311000/18/1] I dati relativi alla segnatura di proto-collo di un documento trasmesso da unaarea organizzativa omogenea sono con-tenuti, un’unica volta nell’ambito dellostesso messaggio, in un file, conforme al-le specifiche dell’Extensible Markup Lan-guage (XML) 1.0 (raccomandazione W3C10 febbraio 1998), conforme con un fileDTD (Document Type Definition) di cuialla circolare Aipa n. 28 del 7/5/2001,ovvero alla sua versione più recente

B R.4. 4[DPCM311000/19/1][DPCM311000/19/2]

Requisito di completezza della segnaturainformatica

B R.4. 5 [AIPACIRC28/5] Il sistema deve trattare messaggi protocol-lati codificati secondo una struttura MI-ME, forma di codifica che rappresenta lamodalità di aggregazione di documenti in-formatici ai fini della trasmissione in ununico messaggio

4.5. CONCLUSIONI 55

B R.4. 6 [AIPACIRC28/5] La segnatura informatica è contenuta inuna body part avente nome Segnatu-ra.xml. L’uso del nome Segnatura.xml peruna body part è riservato a questo unicoscopo

B R.4. 7[DPCM311000/18/

3]Il sistema deve supportare e/o integrarestrumenti di firma elettronica ai fini dellasottoscrizione dei documenti informatici ealla loro gestione (visualizzazione, verificadella firma)

B R.4. 8 [AIPACIRC28/6] Gestione automatica dei messaggi diritorno

B R.4. 9 [AIPACIRC28/6/1] Gestione messaggi di conferma di ricezione V

B R.4. 10 [AIPACIRC28/6/2] Gestione messaggi di notifica di eccezione

B R.4. 11 [AIPACIRC28/6/3] Gestione messaggi di aggiornamento diconferma

B R.4. 12 [AIPACIRC28/6/4] Gestione messaggi di annullamento diprotocollazione

B R.4. 13 [DPCM311000/17/1] Nell’effettuare l’operazione di registrazio-ne di protocollo dei documenti informaticiva calcolata per tutti i file inclusi nel mes-saggio di posta elettronica l’impronta dicui all’art. 53, comma 1, lettera f), delTesto unico n. 445/2000

B R.4. 14 [DPCM311000/11] Il sistema dovrà prevedere delle funzio-ni di accesso all’Indice delle amministra-zioni pubbliche e delle Aree organizzativeomogenee

• 4.7 vedi la risposta al 3.17

4.5 Conclusioni

La storia di e-prot è un valido esempio di come, a partire da specifiche molto strin-genti emanate da un soggetto esterno, si produca e cresca un software Open Source.Se non ci fosse stata la comunity e il progetto non fosse stato open probabilmente e-

56CAPITOLO 4. E-PROT: UN SISTEMA PER IL PROTOCOLLO INFORMATICO

prot sarebbe morto una volta abbandonato dalla sua casa madre, Almaviva. Invece,tutto il lavoro di sviluppo del prodotto e-prot non è stato sprecato, ma grazie allafilosofia Open Source, qualcun altro ha potuto continuare quel lavoro migliorandoloe rendendolo molto competitivo.

Tutti i soggetti hanno avuto e avranno benefici dalla scelta open perché:

• Almaviva riceverà notorietà perché il progetto core sarà sempre il suo.

• FlossLab ha potuto sviluppare una sua soluzione di protocollo avendo già unabuona base sperimentata e, non dovendo reinventare tutto da zero, i vantaggiin termini di risparmio economico e temporale sono notevoli.

• L’autore della tesi ha potuto realizzare una funzionalità importante, appog-giandosi su ben tre società. Infatti oltre alle due italiane già citate c’è anchel’azienda che produce il documentale Alfresco con cui e-prot viene integrato.

• Alfresco ha espanso ulteriormente il suo mercato.

• La pubblica amministrazione e la comunity Gov4j hanno un prodotto in più aloro disposizione.

Capitolo 5

Alfresco: un sistema documentale

Nei capitoli precedenti abbiamo spiegato il motivo di usare un sistema documentaleper memorizzare i dati di e-prot. In questo capitolo esponiamo le caratteristiche delprodotto scelto come documentale, Alfresco.

5.1 Perché Alfresco e perché Open Source

I sistemi di Enterprise Content Management (detti ECM) sono una categoria disoftware che sta crescendo velocemente. I clienti, che si trovano ad implementare oaggiornare i loro sistemi, stanno fronteggiando i seguenti problemi:

• alti costi di manutenzione;

• mancanza di standardizzazione;

• intenzioni del venditore di legare inscindibilmente il cliente ai propri prodotti,problema del vendor lock-in.

Le tecnologie Open Source e open standards stanno diventando delle potenti alter-native alle soluzioni ECM commerciali closed source.

Alfresco è una società fondata nel 2005 che sta guadagnando spazio in questocampo, usando lo stato dell’arte delle tecnologie Open Source e degli standard aperti.

Alfresco sta promuovendo l’alternativa Open Source per gli ambienti enterprisedi content management. Accoppia l’innovazione dell’Open Source con la stabilità diuna piattaforma che può essere usata anche per ambienti critici. Come vedremo piùin dettaglio nell’analisi dell’architettura, la scelta Open Source permette ad Alfrescodi usare le migliori tecnologie aperte, ottenendo così un software di alta qualitàprodotto velocemente e a basso costo.

58 CAPITOLO 5. ALFRESCO: UN SISTEMA DOCUMENTALE

5.2 Il content repository

Alfresco è un content repository. Un content repository è un servizio o una serie diservizi usati per memorizzare, cercare, accedere ai contenuti. Il content repositoryfornisce questi servizi ad applicazioni specializzate di gestione di contenuti:

• document management (software che serve a organizzare e facilitare la crea-zione collaborativa di documenti e di altri contenuti);

• web content management system (sistema di gestione dei contenuti web, cono-sciuto con l’acronimo W CMS utile per facilitare la gestione di siti web senzaavere conoscenze di nozioni di programmazione);

• image storage (per memorizzare e gestire le immagini in maniera più funzionalerispetto a considerarli dei soli file);

• retrieval system (sistemi per ridurre l’overload di informazioni nella ricerca dicontenuti effettuata via dati e metadati di un documento);

• qualunque altra applicazione che richiede la memorizzazione, la ricerca e ilrecupero di grandi quantità d’informazioni.

Il repository fornisce servizi per contenuti, quali memorizzazione, classificazione,sicurezza, controllo dei contenuti attraverso check-in e check-out, utilizzo di querycomplesse. In alcuni casi di lavoro cooperativo a un documento si effettua prima unafase di check-out. Questa pone il documento originale in modalità di sola lettura ecrea una copia di lavoro dove vengono effettuate le modifiche. Dopo aver modificatoil documento, si effettua il check-in e la copia originale viene aggiornata e postadi nuovo in stato modificabile. Se un soggetto ha già fatto il check-out, un altrosoggetto non può effettuare un altro check-out, finchè il primo non abbia effettuatoil check-in.

Quello che distingue un content management system da altre tipiche applicazionidi database è il livello di controllo esercitato sopra ogni singolo oggetto e la capacitàdi ricercare i contenuti. Accedere a questi servizi richiede che siano controllatele chiamate attraverso i filtri di sicurezza per prevenire accessi non autorizzati omodifiche ai contenuti o ai loro metadati. La granularità fine degli accessi e dellapolitica di sicurezza, che potrebbe essere necessaria in ambienti complessi, richiededei meccanismi più sofisticati rispetto a quelli dei database tradizionali.

I complessi requisiti di questi servizi implicano che spesso la complessità e ladimensione di un content repository, con tutti i suoi dati e metadati, può essere piùgrande del database stesso, che contiene invece i soli dati. Tutti i venditori di content

5.3. IL CONTENT REPOSITORY DI ALFRESCO 59

repository forniscono interfacce con servizi proprietari per incapsulare la varietà dellefunzionalità richieste. La metodologia di fornire interfacce con servizi proprietari vacontro i tentativi iniziati nel 1997 di standardizzare queste interfacce. Per venireincontro all’idea di standardizzazione nel 2005 la comunity Java ha adottato lostandard JSR-2005. Il repository di Alfresco si basa su questo standard e su quelliad esso collegati.

5.3 Il content repository di Alfresco

Nell’immagine in Figura 5.1 è mostrata una panoramica del sistema di contentrepository di Alfresco e la sua integrazione con:

• Virtual File Systems, un livello di astrazione che permette di accedere a un filesystem in maniera trasparente rispetto alla tecnologia concretamente utilizzata

• Web Applications, l’interfaccia di accesso al repository tramite web browser

• Knowledge Portals, un insieme di metodologie che forniscono una vista spe-cifica su un dominio di informazioni per facilitare gli utenti nel ritrovamentodelle stesse.

• Web Services, nel lavoro di tesi è stato il modo scelto per connettersi al contentrepository di Alfresco. La connessione viene realizzata tramite librerie da usarelato client, come si vedrà in dettaglio nel capitolo riguardante i Web Servicesdi Alfresco.

• High Availability assicura la continuità del servizio mediante sistemi di repli-cazione e sostituzione a caldo di componenti guasti.

• Alfresco è predisposto per gestire molteplici formati di documenti, tipici disuite per ufficio, multimediali, d’archivio, pagine web ecc.

5.4 Architettura Scalabile

Il più importante aspetto dell’architettura di Alfresco sono i livelli sottostanti. L’ar-chitettura di Alfresco fornisce alta disponibilità per applicazioni critiche usandomeccanismi di clustering, caching, replicazione e supporto tra server multipli. NellaFigura 5.2 si possono vedere i vari livelli dell’architettura.

Basandosi su standard aperti, le applicazioni che si appoggiano ad Alfrescopossono:

60 CAPITOLO 5. ALFRESCO: UN SISTEMA DOCUMENTALE

Figura 5.1: Alfresco Content Repository

Figura 5.2: architettura di Alfresco

5.4. ARCHITETTURA SCALABILE 61

• essere sviluppate su qualsiasi ambiente, come Windows, Linux, Mac ecc.

• usare qualsiasi database, come Oracle, Mysql ecc.

• girare su qualsiasi application server, come JBoss Application Server, ApacheTomcat ecc.

• lavorare con qualsiasi browser, come Mozilla Firefox, Internet Explorer

• essere integrati con qualunque portale, come JBoss Portal, Liferay Portal,jAPS Portal (integrato con Alfresco dalla comunity www.gov4j.it).

In molte organizzazioni, per esempio nell’ambito dei media, farmaceutico, della sa-lute ecc la quantità dei contenuti aumenta esponenzialmente ogni anno. La scala-bilità è quindi un aspetto critico, quando si valuta una soluzione ECM. Alfresco, seconfigurato opportunamente è altamente scalabile.

Adottando gli standard aperti per gli ECM diminuiscono i rischi d’incompatibili-tà con le tecnologie esistenti, inoltre l’integrazione, la sostituzione e il miglioramentodelle singole componenti viene facilitato.

Alfresco è completamente basato sui seguenti open standard:

• Java 1.5

• JSR 170 e JSR-168— JSR (Java Specification Request) è un documento ema-nato da uno più membri del PMO (Programma Management Office, un grup-po designato dalla Sun per sorvegliare e amministrare i processi della JavaComunity), per proporre lo sviluppo di una nuova specifica o una revisionesignificativa a una specifica già esistente. L’obbiettivo della JSR-168 è crea-re uno standard per Java Portal Applications, che aiuti a unificare un’areaframmentata. LA JSR-170 specifica lo standard api per accedere ai contentrepository in Java

• Spring 1.2 Aspect-Oriented Framework— è un framework per lo sviluppo diapplicazioni su piattaforma Java

• ACEGI Aspect-Oriented Security Framework— è un sotto progetto di Spring,fornisce servizi di sicurezza per applicazioni J2EE.

• MyFaces 1.0.9 JSF Implementation— Apache MyFaces è un progetto dell’A-pache Software Foundation che ospita diversi sotto progetti collegati con la tec-nologia JSF. JFS (.JavaServer Faces) è uno standard per sviluppare frameworkweb in Java.

62 CAPITOLO 5. ALFRESCO: UN SISTEMA DOCUMENTALE

• Hibernate 3.0 ORM Persistence— è una piattaforma middleware Open Sourceper lo sviluppo di applicazioni Java che fornisce un servizio di Object-relationalmapping (ORM), ovvero che gestisce la rappresentazione e il mantenimentosu database relazionale di un sistema di oggetti Java.

• Lucene 1.4 Text Search Engine— è una libreria per la ricerca di testi in Java

• JLAN— è un file server (quindi mette a disposizione dei file sulla rete) in Javache implementa i protocolli SMB/CIFS, NFS, e FTP .

• WebDAV/DeltaV JBoss App Server 4.0— è un’estensione di HTTP che per-mette di modificare e amministrare i files in maniera collaborativa su un serverwww

• JBoss Portal 2.—- permette agli utenti di combinare assieme applicazionee contenuti in un unico ambiente, semplificando l’accesso a questi servizi efornendo una possibilità di personalizzazione notevole dei portali creati.

• Jakarta POI— delle APIs in Java per manipolare vari formati di casa Microsoftbasati sopra Microsoft’s OLE 2 Compound Document e Office OpenXML.

• PDFBox—Open Source Java PDF Library

• Open Office 2.0

• JSR-223 Java Language Integration— è una specifica che descrive meccanismiper permettere ai linguaggi di scripting di accedere alle informazioni sviluppatein una piattaforma Java e alle pagine con gli script di accedere alle applicazioniJava Server-side.

5.5 Sicurezza e controlli di accesso

La protezione contro gli accessi non autorizzati è il requisito chiave per ogni soluzioneenterprise. Questo è un requisito essenziale per applicazioni che gestiscono siti web,intranets, extranets e per dati legati alla pubblica amministrazione come nel nostroambito.

I permessi in Alfresco possono essere applicati sia a livello di cartelle che a livellodi singoli contenuti. Alfresco supporta database relazionali, basati sui sistemi deimembri, e anche gestioni esterne, come LDAP, NTLM, Kerberos e Active Directory.

5.6. SERVIZI DI LIBRERIA ESSENZIALI 63

5.6 Servizi di libreria essenziali

I sevizi di libreria sono requisiti essenziali, se si vuole amministrare, modificare econtrollare i contenuti in un sistema ECM. Alfresco fornisce sistemi di librerie quali:

• check-in/check-out— per la produzione collaborativa di un documento, primadi fare modifiche, un utente effettua il check-out. Il documento originale passain modalità READ-ONLY. Viene creata una Working-Copy su cui vengonofatte le modifiche. Ultimate le modifiche viene fatto il ckeck-in della Working-Copy, cioè viene sovrascritto l’originale.

• controllo delle versioni— permette di vedere la storia del documento in tuttele sue modifiche avendo sempre a disposizione la possibilità di ripristinare unaversione precedente.

• informazioni di auditing— conoscere l’utente che ha fatto una modifica aldocumento e il momento in cui l’ha fatta

• content streaming— visualizzazione dei contenuti in streaming

Si possono definire delle regole per eseguire questi servizi automaticamente. Peresempio, su ogni contenuto su cui viene fatta una operazione di edit o su cui vieneeffettuato un check-out deve essere attivato il sistema di versioning.

Alfresco fornisce servizi addizionali che definisce esageratamente “servizi per ren-dere un contenuto intelligente”, permette di aggiungere metadati, regole di sicu-rezza, regole che permettono la collaborazione dinamica su un contenuto, regoletransazionali e regole che permettono un’autocategorizzazione del contenuto.

5.7 Integrazione

Parafrasando la celebre frase “Nessun Uomo è un’Isola” del poeta e religioso londineseJohn Donne si può dire che “Nessuna applicazione è un’isola”. Alfresco fornisce WebServices e Java Content Repository Application Programming Interface (JCR API)per permettere l’integrazione con applicazioni esterne.

5.8 Possibili utilizzi di Alfresco

Alfresco offre sistemi di ECM quali:

• document management

64 CAPITOLO 5. ALFRESCO: UN SISTEMA DOCUMENTALE

• collaboration management— Alfresco fornisce un sistema per il lavoro collabo-rativo. Oltre ai già spiegati meccanismi di check-in/check-out, all’auditing eal sistema di versionamento, fornisce la possibilità di avere dei punti d’integra-zione. Sono disponibili degli strumenti per accedere, condividere, distribuirecontenuti tra utenti o sistemi.

• records management system— un records management system permette dimantenere i records dal momento della loro creazione fino al loro eventualesmaltimento. Un records management può permettere operazioni di classifica-zione, memorizzazione, sicurezza, distruzione e archiviazione in maniera inal-terabile (masterizzazione su supporti ottici). Un record può essere un qual-siasi oggetto tangibile o un’informazione digitale quali certificati di nascita,immagini mediche, database, email, documenti per ufficio ecc.

• web content management— Alfresco può essere usato per amministrare con-tenuti web; permette di effetture delle comode operazioni di amministrazionegrazie alla sua interfaccia basata su AJAX, un sistema di workflow flessibile,al supporto per linguaggio multipli e un robusto e stabile motore di ricercatesti.

• content search— Alfresco può essere usato come sistema di ricerca; forniscericerche per i documenti in modalità full-text o sui metadati; permette disalvare le ricerche e di condividerne i risultati.

Nel nostro lavoro viene usato Alfresco come Document Management. Quindi appro-fondiamo questa caratteristica di Alfresco.

Le caratteristiche di Alfresco permettono di organizzare tutti i servizi necessariper creare, convertire, amministrare e condividere documenti elettronici. Costruitosopra gli standard di piattaforme Open Source, Alfresco fornisce amministrazionedelle versioni, capacità di ricerca e visualizzazione, mostrando le relazioni e le di-pendenze. Usa architetture standard e Open Source, viste nei paragrafi precedenti.L’architettura fornisce alta disponibilità, usando una sincronizzazione distribuita ditipo master/slave all’interno di data center attraverso due fasi di commit, oppureremotamente attraverso la replicazione tra due siti. Supporta un accesso standardtramite Windows Network File Share.

L’interfaccia di amministrazione del document management permette di:

• importare/esportare workspace e documenti

• definire le politiche di sicurezza

5.8. POSSIBILI UTILIZZI DI ALFRESCO 65

• amministrare gli utenti tramite utenti, gruppi e ruoli.

L’amministrazione dei dati e il motore di trasformazione permettono di trasformarei dati nei formati richiesti, basandosi sulle regole definite. I motori di workflowintegrati forniscono un controllo pieno sopra il ciclo di vita del documento, la suaamministrazione e il suo flusso.

I template di presentazione e la dashboard view forniscono una visione persona-lizzata e in real time del contenuto. La funzione di preview è utile per vedere uncontenuto contemporaneamente ad altri.

In un contratto commerciale può essere necessario garantire validità, tracciabilitàe inalterabilità. Il ciclo di vita dei documenti di Alfresco assicura che persone dicompagnie, dipartimenti, divisioni e regioni possano lavorare insieme, supportandotutti i processi collegati a un contratto attraverso il suo ciclo di vita, dalla creazioneverso l’adempimento, la modifica e la terminazione.

Le caratteristiche chiave includono:

• amministrazione dei dati flessibile

• pieno controllo sull’audit

• trasformazione dei dati

• sicurezza e controllo delle versioni

• indicizzazione e ricerche full text

• locking, check-in/ check-out

• sincronizzazione offline, per permettere di accedere ai contenuti offline

• tassonomia (classificazione gerarchica) e categorizzazione dei contenuti

• ricerche avanzate combinate con metadati, locazioni, ricerche multi-category

• report avanzati

• composizione dei documenti con raggruppamenti logici di contenuti vari

• caratteristiche di anteprime con template di presentazione

• supporto alla cancellazione dei documenti con possibilità di recupero.

• possibilità di schedulare azioni e lavori

• libreria per gestire le immagini

66 CAPITOLO 5. ALFRESCO: UN SISTEMA DOCUMENTALE

5.9 Modulo per il Records Management

5.9.1 Record Management: Introduzione

Una funzionalità importantissima per il documentale Alfresco è data da un moduloesterno, che consente di effettuare una pianificazione per la gestione dei file. Unapianificazione dei file è una serie di configurazioni che permettono all’utente di farseguire a un record un determinato ciclo di vita.

In qualsiasi compagnia (Pubbliche amministrazioni comprese) è importante te-nere traccia di tutti i dati. Spesso ci sono delle regole ben precise che un record deveseguire a partire dalla sua creazione. Il termine record comprende qualsiasi tipo difile, come un documento di tipo office automation (word, excel), o un’immagine, oun pdf ecc. Tutti vengono trattati alla stessa maniera nel record management.

5.9.2 Funzionamento del modulo

L’azienda Alfresco ha sviluppato un modulo che permette di aggiungere la funziona-lità di record management al suo sistema documentale. Attraverso questo modulosi possono specificare azioni specifiche per diversi tipi di dati. C’è un tipo di cartellache viene chiamata “file plan” con delle determinate proprietà, ogni file che vieneposto dentro questa cartella eredita le proprietà del file plan.

Il modulo di record management è uno strumento che aiuta a identificare, classifi-care, archiviare o distruggere un record durante il suo ciclo di vita. L’identificazionee la classificazione sono fatte da un identificatore di categoria di record. Questo èun numero o una stringa che si assegna al file plan. A tutti i record che si trovanoin quel file plan viene aggiunto l’identificatore di categoria come un prefisso del loronome.

Si può configurare il file plan per ricordarsi che bisogna rivedere un record. Perapplicare delle regole specifiche a dei gruppi di file plan, si possono creare delle cate-gorie. Tutti i file che finiscono in quella determinata cartella di file plan riceverannola categoria impostata.

Alla scadenza di un certa data, il motore documentale può essere impostato perspostare il file in un’altra cartella che potrebbe trovarsi in una unità di memoriz-zazione più capiente, ma più lenta di quella originale, oppure il file potrebbe essererimosso, se non è più utile, liberando spazio.

Nel file plan è possibile configurare periodi nel quale la funzione può essereattivata o meno.

5.10. CONCLUSIONI 67

5.10 Conclusioni

In questo capitolo abbiamo analizzato l’architettura e le molteplici possibilità diAlfresco, vedendo come questo prodotto accoppia l’innovazione aziendale del modelloOpen Source, con la stabilità di un’applicazione per contesti commerciali con altirequisiti. Alfresco per comporre il suo ECM si avvale delle migliori tecnologie OpenSource. Grazie a queste ha prodotto un software di alta qualità in tempi e costiinferiori rispetto a soluzioni analoghe proprietarie.

68 CAPITOLO 5. ALFRESCO: UN SISTEMA DOCUMENTALE

Capitolo 6

Verso l’integrazione di e-prot eAlfresco: motivazioni

In questo capitolo si analizzano in dettaglio quali sono i requisiti che non vengonosoddisfatti dei software analizzati, mostrando i motivi che hanno portato alla sceltad’integrazione tra il sistema di protocollo e-prot e il documentale Alfresco.

6.1 Ciclo di vita del documento e necessità di siste-

mi documentali

Il problema dell’archiviazione dei documenti in un qualsiasi contesto è quello del-l’accessibilità, come si vede in Figura 6.1.

• Ogni documento ha una sua fase attiva che corrisponde al suo primo ciclodi vita e parte dalla sua creazione. In questa fase il documento è utilizzatofrequentemente e può avere accessi sia in lettura che in scrittura. Più unitàpossono accedere in maniera concorrente al documento e i tempi di accessodevono essere ridotti.

• Dopo questa fase il documento passa in una fase meno attiva della precedentee di solito non viene più modificato, ma solo consultato in lettura e in manierapiù sporadica. In questa fase le esigenze di accesso e i tempi ad questi legatisono meno stringenti. Diventano invece più importanti l’economicità dellamemorizzazione, la salvaguardia dell’integrità e l’alta visibilità.

Le Figure 6.2 esprime chiaramente i fattori direttamente proporzionali della ve-locità di accesso e del costo del supporto di memorizzazione. La maggior parte deidocumenti hanno un ciclo di vito lungo.

70CAPITOLO 6. VERSO L’INTEGRAZIONE DI E-PROT E ALFRESCO: MOTIVAZIONI

Figura 6.1: ciclo di vita di un documento

Figura 6.2: costo della memorizzazione di un documento

6.1. CICLO DI VITA DEL DOCUMENTO E NECESSITÀ DI SISTEMI DOCUMENTALI71

Date queste considerazioni si può definire una semplice tabella riassuntiva

Breve ciclo di vita odocumento nella fase attiva

Lungo ciclo di vita odocumento dopo la fase

attiva

Condivisibile Una modalità di condivisionequalsiasi tramite la intranet

Sistema Documentale

Non condivisibile Sistema locale, cartella del disconon condivisa

Sistema Documentale con livellid’accesso controllati

Come emerge dalla tabella risulta particolarmente indicato il ricorso ad una so-luzione di tipo Sistema Documentale, qualora un documento sia caratterizzato daun lungo ciclo di vita e che sia condivisibile, cioè nel caso in cui è presumibile cheil documento sia acceduto da più persone per un lungo periodo di tempo. I do-cumenti, il cui accesso è limitato ad un insieme ristretto di soggetti, ma che sonocaratterizzati da un lungo ciclo di vita, possono essere collocati nel Sistema Docu-mentale, garantendo un adeguato controllo degli accessi. La decisione se utilizzareil medesimo supporto tecnologico, sia per i documenti condivisibili che per quellinon condivisibili, dovrà scaturire da una attenta valutazione dei costi e dei rischilegati alla tecnologia. Naturalmente tali scelte sono strettamente connesse alla va-lutazione dei tempi di selezione e conservazione dei documenti definiti d’intesa conl’amministrazione archivistica.

Si noti, comunque, che i documenti soggetti alla registrazione di protocollo sonogeneralmente mantenuti per un periodo temporale misurabile in anni 16 e possonoperciò essere considerati come documenti con un lungo ciclo di vita e quindi con lecaratteristiche minime per essere gestiti da un Sistema Documentale.

In ogni caso, il Sistema Documentale dovrà essere arricchito di tutte le informa-zioni necessarie in modo da garantire i seguenti obiettivi:

• facilitare la ricerca dei documenti;

• garantire sicurezza ed adeguati livelli di accesso;

• facilitare le operazioni di selezione e conservazione dagli archivi di deposito;

• rendere sempre individuabile la localizzazione fisica dei documenti cartacei;

• migliorare la circolarità delle informazioni all’interno dell’amministrazione

• garantire l’integrità e l’accessibilità dei documenti selezionati per la conserva-zione permanente.

72CAPITOLO 6. VERSO L’INTEGRAZIONE DI E-PROT E ALFRESCO: MOTIVAZIONI

Passando all’integrazione con un sistema documentale, si riescono a soddisfare tuttele specifiche qui richieste. In particolar modo, con una corretta configurazione di unmodulo come il “Records Management” si riesce ad effettuare lo spostamento degliarchivi (transitando quindi da “fase attiva” ad “archiviazione a lungo termine”), contutte le funzione di backup che si ritengano opportune.

6.2 Specifiche della dematerializzazione

In questo paragrafo si spiegano le specifiche riguardanti la pratica della demateria-lizzazione ampiamente discussa e incentivata nel documento [DEMA]

6.2.1 Introduzione sulla dematerializzazione

Le tecnologie digitali sono una rilevante risorsa per l’efficienza e la produttività del-la Pubblica Amministrazione. Uno Stato che costa meno e lavora meglio crea piùricchezza per l’Italia. Questo è un obiettivo che il Governo ha promosso e devecontinuare a costituire una priorità per il nostro Paese anche nel futuro. In tale pro-spettiva, il tema della dematerializzazione assume particolare rilevanza e attualità.Infatti, l’impulso dato dalla nostra politica per la modernizzazione della PubblicaAmministrazione attraverso nuove applicazioni tecnologiche, un quadro normativocoerente, un’organizzazione dedicata, un metodo condiviso e una cultura diffusadell’e-government, consente oggi di realizzare quegli ingenti benefici, in termini dirisparmio e di efficacia, che il passaggio del documento amministrativo dalla carta albit ha sempre prospettato. Con l’entrata in vigore del Codice dell’Amministrazionedigitale viene data attuazione, ricorrendo alle più avanzate tecnologie informatiche,ai meccanismi deputati a realizzare in concreto la tanto auspicata “scomparsa dellacarta”. Un’immagine che impegna a una trasformazione profonda del modo di ope-rare di ogni pubblica amministrazione e a una valorizzazione delle proprie risorseprofessionali.

Lo scopo è risolvere molti problemi inerenti la gestione della documentazioneamministrativa, attraverso l’eliminazione della documentazione cartacea esistente eevitando la produzione di nuova carta. Questo progetto è collegato al più ampioimpegno di razionalizzare i processi di trasformazione e modernizzazione della bu-rocrazia italiana. Occorre superare alcune barriere culturali ostili al cambiamento,all’abbandono della carta, per un atteggiamento di fiducia nel documento infor-matico come generatore di progresso e valore economico. Occorre convincere “gliincerti”, insistendo nel percorso della divulgazione, della presentazione di esperienzee risultati, della formazione.

6.2. SPECIFICHE DELLA DEMATERIALIZZAZIONE 73

6.2.2 Il problema del diverso ambiente tecnologico

La conservazione digitale necessita, quindi, di un insieme di attività e strumenti chepermettano il mantenimento dell’accessibilità, della leggibilità, della intelligibilità,dell’autenticità e dell’integrità nel lungo periodo dei documenti informatici, in unambiente tecnologico diverso da quello di origine. In questo senso la pratica conser-vativa non può coincidere con la preservazione del flusso di bit, ma implica ancheil mantenimento delle informazioni necessarie ad assicurare l’interpretazione di taleflusso, attraverso la predisposizione di set di metadati descrittivi e gestionali.

La versione presa in considerazione di e-prot la 1.2, manca del requisito fonda-mentale che garantisca tutte le caratteristiche (accessibilità, leggibilità ecc. ) “inun ambiente diverso da quello di origine”. Anche nella versione 1.3, che prevede ilsalvataggio su file system, e, quindi la possibilità di accesso “in un ambiente diversoda quello di origine”, non garantisce tutte quelle caratteristiche a causa della debo-lezza dello strumento file system rispetto, per esempio, a un sistema documentale.Grazie al salvataggio su un sistema documentale e quindi alla possibilità di accederealle informazioni con tutti i modi che un sistema del genere consente (interfacciaweb e Web Services sono quelli utilizzati in questa tesi, ma ne sono presenti anchealtri) si riescono a rispettare questi vincoli dettati dalle specifiche della demateria-lizzazione. Creare un’applicazione esterna, che acceda direttamente al db di e-protsenza intermediazioni del software, genererebbe diversi problemi e non garantirebbeil completo rispetto dei requisiti.

6.2.3 Il sistema di workflow

La riforma del sistema amministrativo pubblico sta provocando una forte trasfor-mazione nell’ambito della gestione documentale, sempre più affidata a sistemi infor-mativi che, grazie alle tecnologie informatiche, consentono la completa automazionedell’organizzazione dei documenti (in particolare con i sistemi di protocollazione eclassificazione), lo scambio dei dati per via telematica, la produzione di documentiinformatici con pieno valore giuridico (soprattutto tramite i sistemi di firma digitale),la gestione dei processi amministrativi attraverso sistemi di workflow management.Il processo normativo alla base di tale trasformazione ha considerato la tematica del-la conservazione dei documenti nell’ambito di una serie di provvedimenti che hannocontribuito a delineare il quadro di riferimento attualmente in atto, con particola-re riguardo alle pratiche di conservazione della documentazione informatica ed aiprocessi di conservazione sostitutiva della documentazione cartacea.

74CAPITOLO 6. VERSO L’INTEGRAZIONE DI E-PROT E ALFRESCO: MOTIVAZIONI

Attualmente su e-prot non è presente che un semplice sistema di workflow. Quin-di, la “gestione dei processi amministrativi attraverso sistemi di workflow mana-gement” non è attualmente raggiungibile. Grazie all’integrazione con un sistemadocumentale avanzato, è possibile usare il ben più sviluppato sistema di workflowpresente su questa piattaforma e, quindi, ottenere senza sforzo l’amministrazionedei sistemi di workflow. Un possibile workflow potrebbe essere quello che realizzail backup dei documenti oppure la transazione da archivio corrente ad archivio dideposito, come già accennato precedentemente.

6.2.4 Le informazioni rimosse e i log

Il Testo Unico in materia di documentazione amministrativa (DPR 28 dicembre2000, n. 445) e le relative regole tecniche (DPCM 31 ottobre 2000) prevedono inparticolare: operazioni di salvataggio periodiche; la necessità di mantenere leggi-bili le informazioni rimosse dal sistema; nel caso della conservazione sostitutiva, ilmantenimento delle informazioni relative alla gestione informatica dei documenticome parte integrante del sistema di indicizzazione e di organizzazione dei docu-menti oggetto delle procedure di conservazione; l’obbligatorietà del log di sistemacon la registrazione e verifica degli utenti e di tutti gli interventi effettuati e la ge-stione conservativa delle informazioni; la garanzia di leggibilità nel tempo di tutti idocumenti trasmessi, compresi gli allegati.

Queste e altre specifiche (leggibilità delle informazioni rimosse), richieste, semprenel documento riguardante la dematerializzazione, non sono garantite alla versioneattuale di e-prot, ma, grazie all’integrazione con il sistema documentale, questefunzioni possono essere attivate di default su tutti i dati memorizzati su quest’ultimo.Il sistema documentale può anche garantire un sistema di logging più fine rispettoal software di protocollazione

6.2.5 I supporti ottici

La Deliberazione CNIPA n. 11 del 19 febbraio 2004 detta i principi in materia diconservazione. La conservazione di documenti digitali avviene mediante la memo-rizzazione su supporti ottici e termina con l’apposizione sull’insieme dei documentidel riferimento temporale e della firma digitale da parte del responsabile della con-servazione che attesta il corretto svolgimento del processo. Solo per una partico-lare categoria di documenti è prevista anche l’apposizione della firma da parte delpubblico ufficiale.

6.3. LA GESTIONE INTEGRATA DEI DOCUMENTI E IL MANTENIMENTO DEGLI ARCHIVI 75

Al momento, con tutti i documenti sul database (e-prot 1.2) o sul file system(e-prot 1.3), l’operazione di memorizzazione su supporti ottici diviene difficilissimanella versione 1.2, più facile, ma con problemi di gestione, causati dalla scelta delfile system nella versione 1.3.

6.3 La gestione integrata dei documenti e il mante-

nimento degli archivi

In questo paragrafo si analizzano le buone norme di gestione elettronica dei docu-menti e per la corretta conservazione degli archivi. Per un ulteriore approfondimentovedi [TENAR]

6.3.1 L’archivio

L’archivio è definito come il complesso dei documenti prodotti o acquisiti dal sog-getto produttore nell’esercizio delle sue funzioni. In relazione alle diverse fasi diorganizzazione, si distingue in:

• archivio corrente: insieme dei documenti correnti;

• archivio di deposito: insieme dei documenti semi-attivi;

• archivio storico: insieme dei documenti storici.

Archivio corrente: è l’insieme organico di documenti prodotti, acquisiti e conservatida una persona fisica o giuridica nell’esercizio delle sue funzioni (ad esempio, nelsettore pubblico da un’area organizzativa omogenea) e necessari allo svolgimentodell’attività corrente

Archivio di deposito: è il complesso dei documenti prodotti o acquisiti dal sog-getto produttore ancora utili per finalità amministrative e giuridiche, ma non piùnecessari allo svolgimento delle attività correnti. L’archivio di deposito, al pari del-l’archivio corrente, costituisce una componente essenziale del sistema informativodocumentale

Il termine archivio è utilizzato anche per indicare il luogo fisico in cui si con-servano i documenti (nelle diverse fasi di gestione) e la struttura organizzativa cuitale gestione è affidata. L’archivio storico è sempre affidato a una parte terza, chenel caso dello Stato, ai sensi della normativa vigente, è rappresentata dall’Archiviocentrale dello Stato e dagli archivi di Stato competenti per territorio, mentre, nelcaso di tutte le altre amministrazioni pubbliche non statali, il compito è riconosciuto

76CAPITOLO 6. VERSO L’INTEGRAZIONE DI E-PROT E ALFRESCO: MOTIVAZIONI

a un servizio archivistico, interno all’amministrazione, ma dotato di un certo gradodi autonomia e affidato a personale specializzato nella disciplina archivistica. È tut-tavia opportuno chiarire non solo che l’archivio storico costituisce bene culturale edè perciò soggetto a una specifica azione di tutela da parte dello Stato, ma anche checostituiscono beni archivistici tutelati "gli archivi e i singoli documenti dello Stato"e "gli archivi e i singoli documenti degli enti pubblici", indipendentemente dalla spe-cifica fase di organizzazione (corrente, di deposito, storica). Il compito della tutelaè affidato agli Archivi di Stato e all’Archivio centrale dello Stato per le carte delleamministrazioni statali centrali e periferiche e alle Soprintendenze archivistiche peri documenti degli enti pubblici.

Sono considerati beni archivistici sottoposti a tutela da parte degli organi delMinistero per i beni e le attività culturali sia gli archivi correnti e di deposito chegli archivi storici.

Con l’informatizzazione e la conseguente dematerializzazione dei documenti, ilrischio di danneggiamento e perdita del documento come bene culturale diventa ri-levante. Il meccanismo di memorizzazione di un documento a livello di un semplicedatabase con un software che vi accede come accade in e-prot mette in notevole ri-salto questo problema. La memorizzazione a livello di sistema documentale e quindiil passaggio dalla visione su db a quella di più alto livello rappresentata dal docu-mentale può attenuare in parte questo problema. Questo problema è sottolineatoulteriormente nelle indicazioni che le specifiche danno sulla “conservazione”

6.3.2 La conservazione

L’archiviazione ottica sostitutiva deve sempre basarsi sull’esistenza di piani di clas-sificazione e conservazione, cioè sull’analisi e sulla valutazione dei concreti bisogniorganizzativi e deve contare su soluzioni idonee anche dal punto di vista della lorosostenibilità. Se, pertanto, si intende procedere a interventi di informatizzazione delsistema documentale, è indispensabile assicurare la corretta organizzazione dell’ar-chivio corrente (ad esempio, la formazione dei fascicoli e la definizione dei termini edelle modalità di conservazione) e valutare con attenzione l’efficacia di programmimassicci e generali di digitalizzazione. In ogni caso, l’informatizzazione non devemai prescindere dalla considerazione delle esigenze di conservazione nel tempo deidocumenti, in particolare per quel materiale archivistico oggi corrente, ma destinatoa una durata illimitata per ragioni di ricerca storica e scientifica. L’invito a tenereconto dei problemi della conservazione è indispensabile in una fase in cui le am-ministrazioni sono fortemente orientate a investire nell’uso massiccio di strumentiinformatici anche nella produzione di documenti originali in forma elettronica. Non

6.3. LA GESTIONE INTEGRATA DEI DOCUMENTI E IL MANTENIMENTO DEGLI ARCHIVI 77

sembra che ci sia, sul piano organizzativo e nelle soluzioni tecniche finora adottate,la dovuta attenzione ai problemi della conservazione a lungo termine, in particolarealla necessità di predefinire per tempo regole di comportamento e formati standard,la cui adozione a distanza di anni non potrebbe che avere costi molto impegnati-vi, ma che soprattutto accrescerebbe il rischio già oggi molto consistente di perditeirreparabili.

6.3.3 Il sistema documentario

Il sistema documentario è un concetto più ampio di quello di archivio; si riferiscenon solo all’insieme dei documenti prodotti o acquisiti da un soggetto produttorenell’esercizio delle sue funzioni (l’archivio nelle sue fasi), ma include anche il sistemaper la gestione dei documenti, cioè l’insieme delle regole, delle procedure e dellerisorse (umane, finanziarie e strumentali) per la loro formazione, organizzazione,reperimento, utilizzo e conservazione; garantisce il controllo generale e sistematico daparte del soggetto produttore sulla propria documentazione archivistica. Un sistemadi gestione documentale è uno strumento tecnico per una migliore organizzazione deidocumenti, e, in forma minore, anche del personale, quindi, si avvicina maggiormentea un sistema documentario vero e proprio.

6.3.4 Il servizio per la gestione dei documenti e il manteni-

mento dell’archivio

Ha la finalità di garantire:

• la adeguata formazione dei documenti;

• la corretta organizzazione di un sistema documentario efficiente, con partico-lare riferimento alle attività e agli strumenti di registrazione e classificazionedei documenti;

• la tenuta dell’archivio corrente e di deposito, nonché dei relativi strumenti diconsultazione;

• la selezione periodica dei fascicoli conservati nell’archivio corrente e di depo-sito;

• la conservazione nel tempo dell’archivio storico, nonché dei relativi strumentidi consultazione;

• l’accessibilità nel tempo al sistema documentario ;

78CAPITOLO 6. VERSO L’INTEGRAZIONE DI E-PROT E ALFRESCO: MOTIVAZIONI

• la sicurezza del sistema documentario.

Il sistema di memorizzazione di e-prot 1.2 tramite db o nella versione 1.3 tramitefile system non è chiaramente un sistema documentario, un sistema documentale alcontrario può essere visto in tale modo.

La conservazione nel tempo dell’archivio e degli strumenti non è assolutamentegarantita a causa dell’evoluzione del software nelle sue versioni. Infatti, vi sonoregistrate da parte degli utenti problemi a passare dalla versione 1.0 alla 1.1 e ancheda questa alla 1.2 . Problemi tutt’altro che scomparsi con la 1.3, passando ulterioretempo, e, quindi con ulteriori versioni del software e del sistema di memorizzazione.

6.3.5 La gestione dell’archivio di deposito

L’archivio di deposito costituisce la fase più complessa dell’attività di tenuta degliarchivi. Questo a causa della insufficienza di tutte le risorse necessarie per conver-sare documenti cartacei (gli archivi fisici sono molto costosi), dovuta anche al minorinteresse che il materiale conservato riveste per l’attività corrente del soggetto pro-duttore. La tendenza generale di questi ultimi anni è stata quella di considerare ildeposito come semplice locale di accumulazione dei documenti, piuttosto che luogodi "conservazione", ovvero di gestione attiva e responsabile. Nel definire la strutturae i requisiti di un archivio di deposito, è opportuno ricordare che le finalità di talefunzione riguardano:

• esigenze di natura essenzialmente economica: conservare i documenti menorichiesti in luoghi dedicati che rispondano a specifiche caratteristiche in terminidi localizzazione e costo degli spazi utilizzati (ad esempio, depositi in zoneperiferiche a minor costo);

• esigenze di natura funzionale-archivistica: garantire la corretta conservazio-ne del materiale e mantenere il controllo conoscitivo, oltre che fisico sulladocumentazione;

• esigenze di natura giuridica: garantire la conservazione dell’autenticità e del-l’accessibilità dei documenti nel tempo.

Obiettivi fondamentali dell’organizzazione dei documenti nell’archivio di depositoriguardano:

• il controllo sui documenti in termini di responsabilità sia del soggetto/strutturache versa i documenti sia di chi gestisce il deposito medesimo;

• l’accesso rapido alla documentazione conservata;

6.4. CONCLUSIONI 79

• la conservazione del materiale secondo l’ordine originario (cfr. articolo 67 delTesto unico);

• la definizione certa della durata dei documenti definiti nel piano di conserva-zione e la facile identificazione dei materiali destinati allo scarto.

L’attività fondamentale riguarda la gestione dei trasferimenti/versamenti dei fasci-coli. Con il termine versamento o trasferimento si intende l’operazione con cui unufficio trasferisce periodicamente in archivio (storico, ma anche di deposito) i fasci-coli non più correnti, cioè non più necessari alla trattazione degli affari. Indica sial’azione che il gruppo di documenti trasferiti. Comprende - sia in ambiente tradi-zionale che digitale - due fasi che naturalmente hanno modalità diverse in relazionealle tecnologie impiegate:

1. la preparazione del versamento da parte dell’ufficio, che richiede la predisposi-zione di un elenco di consistenza dell’ufficio versante, include la indicazione ela descrizione delle serie, gli estremi cronologici, la consistenza, i termini e lemodalità specifiche di conservazione, l’ufficio responsabile

2. l’acquisizione e la gestione del versamento da parte dell’ufficio di concentra-zione, include la registrazione dei versamenti con il nome dell’ente versante,il controllo incrociato dei diversi versamenti relativi al medesimo ufficio diprovenienza, il collegamento delle informazioni relative ai diversi uffici di pro-venienza, la valutazione se i versamenti vadano fusi (pur tenendo traccia dellefasi distinte di versamento) o lasciati separati, la conservazione degli strumentioriginari di consultazione e ricerca dei documenti (registri di protocollo, sche-dari, rubriche, repertori dei fascicoli, ecc.), nonché degli elenchi di versamento(utili in fase di riordinamento, descrizione e consultazione in sala di studio).

6.4 Conclusioni

Tutte queste indicazioni sulla gestione archivistica, mostrano quanto lo stato attualedel sistema di protocollo e-prot sia al momento (versione 1.2 e 1.3) inadeguato.La memorizzazione mista della versione 1.3 file system/db e, ancor di più, quellaesclusivamente sotto database comporta una difficoltà intrinseca nelle operazioni digestione di archivio. La totale mancanza di strumenti che permettano i più voltecitati versamenti da un archivio all’altro necessitano di una soluzione immediata.

Questa necessità è stata fatta presente anche dagli utilizzatori del sistema nellamailing list. In una mail un utente chiedeva di inserire una funzione per il backup dei

80CAPITOLO 6. VERSO L’INTEGRAZIONE DI E-PROT E ALFRESCO: MOTIVAZIONI

dati, avendo rilevato che spiegare il funzionamento di pgadmin a persone a digiunodi informatica è molto difficoltoso e pericoloso per i dati.

L’integrazione con un sistema documentale sembra proprio la scelta adeguata persemplificare questa tipologia di problemi. La soluzione si conforma esattamente allespecifiche. Infatti, l’accesso a un db è più veloce rispetto a un documentale e quindipiù adatto alla prima fase del documento quando è in fase attiva. Ma la presenzadelle informazioni nella base documentale permette al costo di un piccolo overheadtemporale una gestione migliore nel tempo. Inoltre, le operazioni di versamentofortemente consigliate vengono facilitate dalla gestione a livello di documentale ri-spetto al database/file system. La procedura delle operazioni di versamento, peròè tutt’altro che risolta con l’avvento del documentale, ma deve essere in ogni casodefinita nel dettaglio, calandosi nelle necessità della pubblica amministrazione.

La soluzione prospettata consente il doppio salvataggio db documentale in duemodalità: contemporanea e posticipata. Nella modalità contemporanea ogni voltache viene effettuata una modifica viene riportata sul database/file system e sul siste-ma documentale. In quella posticipata, quando si vuole, si effettua l’aggiornamento,copiando le informazioni dal database/file system al documentale.

Capitolo 7

I Web Services di Alfresco

Come anticipato nell’introduzione, per connettersi al documentale Alfresco è statoscelto il sistema dei Web Services. Le motivazioni che ci hanno portato ad usarequesta tecnologia sono le seguenti:

• i WS utilizzano formati standard, protocolli aperti come XML il che li rendefacilmente comprensibili e utilizzabili;

• usando come protocollo di trasporto http, passano tranquillamente attraversoi firewall;

• permettono un’elevata interoperabilità, perché predisposti per formare servizicomplessi, integrandosi con applicazioni già sviluppate.

In questo capitolo si parlerà dei Web Services sotto il punto di vista del client. Illato server è già attivo su Alfresco e si presuppone già perfettamente funzionante.

7.1 Il problema della documentazione

Si potrebbe erroneamente pensare che, per un prodotto così maturo come Alfrescoe una tecnologia così affermata come i Web Services, si trovi moltissimo materiale,esempi, documentazione ecc. Invece, ho potuto sperimentare che non è affatto così.Sul sito di Alfresco si rimanda al wiki appositohttp://wiki.alfresco.com/wiki/Alfresco_Content_Management_Web_Services,una pagina molto scarna che spiega per sommi capi i servizi offerti da Alfresco perquesta tecnologia.

Vi sono esempi per tre linguaggi Java, PHP, Ruby e un link non ancora attivoper dot Net. Dato che Alfresco è un prodotto sviluppato in Java per questo lin-guaggio, vi sono ben sei esempi di codice, contro un esempio disponibile per PHP

82 CAPITOLO 7. I WEB SERVICES DI ALFRESCO

e Ruby. Cercando in rete, non si trova niente di utile, forse perché questo metododi connessione non è molto usato oppure perché chi lo usa non ama condividere leesperienze.

L’unico riferimento sicuro è stato il forum di Alfrescohttp://forums.alfresco.com nella sezione dedicata ai Web Services. Ma per lastessa definizione di forum, questi non potrà mai essere un sostituto di una guidaesaustiva, ma solo un mezzo che serve per domande precise, dubbi e curiosità. Ilproblema che ho incontrato, dovendo cominciare a lavorare con questa tecnologia diAlfresco, è proprio la mancanza di una guida che introduca il funzionamento dei WSin Alfresco in maniera ordinata e sistematica. In questo capitolo cercherò di fornireuna guida organizzata, sfruttando l’esperienza acquisita durante questi mesi nel miolavoro di tesi in modo da rispondere a una domanda che esce abbastanza spesso sulforum da parte di altri utenti. Riporto testualmente un post del 7 Maggio 2009

“Hi, do you know where I can find some documentation, guide or something likethat on webservices more exhaustive than wiki pages? thank you.”

L’obiettivo che il capitolo si pone è quello di fornire agli sviluppatori di Alfre-sco che usano i WS, una guida, che parta dalla teoria, mostri degli esempi bencommentati, illustri un uso completo e fornisca in ultimo un sovrastrato alle API,permettendo un uso più semplice e immediato di questa tecnologia.

7.2 Connessione : prima di tutto

La prima cosa da fare è interconnettersi ad Alfresco, scaricando i Web Services cliente preparando l’ambiente.

7.2.1 I Web Service Client

Andare sulla pagina di download(http://wiki.alfresco.com/wiki/Labs_3_Final_download_files) e scaricare leclassi che permettono l’interconnessione lato client ai Web Services di Alfresco.Scegliere il formato che si preferisce tra tar.gz e .zip

Figura 7.1: Alfresco Web Service Client

7.2. CONNESSIONE : PRIMA DI TUTTO 83

Un volta decompresso il file scaricato, vi si trovano due elementi,“alfresco-web-service-client.jar” e una cartella denominata “alfresco”. La car-tella a sua volta contiene un file “webserviceclient.properties” con il seguentecontenuto:

# Set the following property to reference the Alfresco

# server endpoint that you would like

# web service client to communicate with

repository.location=http://localhost:8080/alfresco/api

Bisogna modificare appropriatamente la proprietà, indicando il reale ip e la portasu cui il nostro documentale è in funzione. L’url è lo stesso a cui ci si collega quandosi usa l’interfaccia web tramite borwser, con l’aggiunta del suffisso “/api”

7.2.2 L’ambiente

Come ambiente di sviluppo ho scelto di usare il framework Eclipse, perché l’inte-grazione che si realizzerà nei capitoli successivi con e-prot lo consiglia fortemente.Inoltre, questo framework occupa una posizione leader nel mercato. Le operazionidescritte successivamente sono però abbastanza generali e quindi si possono applicarea qualsiasi altro ambiente.

Bisogna compiere una serie di passi:

1. Aprire Eclipse, creare un nuovo progetto, va bene un “Java Project”;

2. Creare il package org.alfresco.sample.webservice . Questo non è obbli-gatorio, ma, dato che gli esempi disponibili sul sito di Alfresco sono in questopackage, meglio evitare di dover cambiare il codice in ogni sorgente;

3. Copiare dentro il package appena creato il codice Java di esempio che si trovanell’svn di Alfresco[?]. Vi sono otto file .java da cui si riesce a capire qualcosasu come usare questi WS. L’accesso all’svn sarà molto utile per poter con-sultare i sorgenti delle classi che si utilizzeranno successivamente in manieraapprofondita;

4. Copiare la cartella alfresco con il suo contenuto “webserviceclient.properties”nella cartella dov’è presente il package org (la cartella di default in Eclipse èsrc). Includere il file alfresco-web-service-client.jar come external jaroppure creare una cartella lib. Io ho deciso di usare un external jar, click conil tasto destro sul progetto, “Build path”, “Configure Build Path”, “Libraries”,

84 CAPITOLO 7. I WEB SERVICES DI ALFRESCO

“Add External JARs”, selezionare il file alfresco-web-service-client.jar

cliccare su OK. A questo punto dovrebbero essere spariti tutti gli errori ri-guardanti l’utilizzo di classi contenute dentro il suddetto jar.

5. Per far funzionare i Web Services però non basta includere la libreria fornita,ma ne servono altre. Nel wiki di Alfresco questa cosa non è scritta, gli errorimostrati però ci fanno capire il contrario. Eclipse mostra immediatamente lanecessità della libreria axis.jar scaricabile dal sito dihttp://ws.apache.org/axis/, ma sono necessarie anche delle altre librerieperché altrimenti, in fase di esecuzione, dà degli errori di “NoClassDefFoun-dError”. Queste librerie si possono trovare nella cartellaalfresco/tomcat/webapps/alfresco/WEB-INF/lib

presente nella nostra installazione server di Alfresco. In questa cartella sonopresenti 96 librerie perché sono quelle necessarie per far funzionare tutto il la-to server di Alfresco. Includerle tutte sicuramente porta ad un funzionamentosenza errori del programma, ma anche ad avere un progetto troppo pesantecon la maggior parte delle librerie non sfruttate. Per questa ragione ho effet-tuato diverse prove che mi hanno portato ad avere una lista di sole 12 librerienecessarie:alfresco-remote-api.jar

commons-logging-1.1.jar

mail.jar

wss4j.jar

axis-1.4.jar

jaxrpc.jar

opensaml- 1.0.1.jar

xmlsec-1.4.1.jar

commons-discovery-0.2.jar

log4j-1.2.15.jar

wsdl4j-1.6.2.jar

saa j-api-1.3.jar

Questo non è però un elenco assoluto ma quello che ho usato io. Dal forumun altro utente segnala un’altra libreria che a lui è servita, quindi si può usa-re quello come elenco di partenza. Poi, a seconda di cosa si sfrutta dei webservices si includono le librerie necessarie. Con l’elenco scritto sopra si riescead usare la maggior parte degli esempi presenti dei web services forniti daAlfresco.

7.3. DESCRIZIONE DEI WS IN ALFRESCO 85

6. Adesso dovrebbero essere spariti tutti gli errori riguardanti le classi utilizzatedentro il jar. Vanno corretti anche degli errori causati dalla mancata gestionedi alcune eccezioni aggiungendo qualche try catch.

7. Per verificare che tutto funzioni, basta scaricare le due classi basi“SamplesBase.java” e “GetSores.java”, selezionare la classe GetStores an-dare su “Run” “Run As” “Java Application”. Se tutto va bene dovrebbe daredei messaggi d’informazione sul repository;

8. Se dovesse mancare qualche classe per ritrovarla, all’interno delle librerie diAlfresco si può lanciare il seguente script unix posizionandosi prima all’internodella cartella del server.

for lib in $(ls ./*); do jar tf $lib | grep "SOAPException";

echo "--^ $lib ";done

sostituendo SOAPException con la classe che si vuol trovare all’interno dellelibrerie

Ho scritto un breve post più sintetico della descrizione appena fatta, “Use the webservice client with Java and eclipse” (in inglese) in merito sul blog di Alfresco pervenire incontro a uno sviluppatore alle prime armi.

Adesso che abbiamo configurato tutti i parametri, ottenendo un ambiente fun-zionante, possiamo passare alla studio completo dei Web Services.

7.3 Descrizione dei WS in Alfresco

Nel wiki di documentazione troviamo una tabella che elenca i vari servizi disponibili:

86 CAPITOLO 7. I WEB SERVICES DI ALFRESCO

Service Description Status

Authentication login and logout AvailableRepository query and model manipulation AvailableContent content manipulation AvailableAuthoring collaborative content creation Available

Classification apply classifications and categories AvailableAccess Control roles, permissions & ownership Available

Action manage actions and rules AvailableAdministration user management, export & import AvailableDictionary model descriptions AvailableFileSystem common file and folder methods Future

Non conviene invocare direttamente i servizi ma grazie alle classi client disponibilisi può accedere in maniera più semplice e immediata. Andiamo a vedere i serviziprincipali.

7.3.1 Authentication

Per poter fare qualsiasi operazione in Alfresco, bisogna autenticarsi. Questo va-le anche con i web services. Invece di usare il servizio di autenticazione diretta-mente, si utilizza una utility (presente all’interno della libreria scaricata per usarei web service). Per realizzare l’autenticazione, basta scrivere questa riga di co-dice “AuthenticationUtils.startSession(username, password)”, dove userna-me e password sono le stringhe che identificano l’utente. Dopo aver completatole operazioni, bisogna eseguire il comando AuthenticationUtils.endSession()

che effettuerà la chiusura della sessione per quell’utente. Tutte le operazioni chevengono effettute tra le due suddette invocazioni saranno eseguite con i privilegidell’utente autenticato all’inizio. Se viene eseguita qualche operazione invalida dicui l’utente non abbia il permesso (per esempio un utente senza privilegi ammini-strativi tenta di accedere alle cartelle di un altro utente oppure prova a creare un’u-tenza), viene generata un’eccezione. La classe AuthenticationUtils si trova dentroorg.alfresco.webservice.util.

7.3.2 Repository

Per effettuare tutte le operazioni di gestione del repository, come, per esempio,manipolazione delle cartelle, modifiche delle metainformazioni dei file, interrogazio-ni/ricerche ecc. si usa il servizio repository. Per le operazioni di creazione o modificadel contenuto dei file invece si utilizza il servizio Content.

7.3. DESCRIZIONE DEI WS IN ALFRESCO 87

Per prima cosa si ottiene l’oggetto repository tramite il metodo getRepository-Service() “RepositoryServiceSoapBindingStub repositoryService = WebServiceFac-tory.getRepositoryService();” poi si esegue il metodo appropriato che restituisce ilrisultato tramite un tipo predefinito di Alfresco da interpretare.

Ecco i metodi:

• Due metodi per la gestione dello store “createStore” e “getStores” non sonomolto utili, dato che basta lasciare sempre lo store di default;

• Quattro metodi per l’esecuzione di query “query”, “queryChildren”, “queryPa-rents”, “queryAssociated”;

• Un metodo per gestire le query “fetchMore”;

• Un metodo per effetture scritture sul repository “update”;

• Due per leggere le informazioni di una risorsa “describe” e “get”.

7.3.3 Content

Il servizio Content è più semplice del servizio repository, perché, al contrario delprecedente, non agisce a livello di gestione totale, ma effettuerà solamente modificheall’interno del contenuto stesso.

Per questo motivo ci sono solo tre metodi abbastanza intuitivi: “read”, “write” e“clear”.

Quindi, per esempio, una modifica al nome del file si effettua con il servizioRepository, mentre una modifica del contenuto di un file in scrittura o in lettura sieffettua con il servizio di Content. Per creare un file invece vanno usati entrambi iservizi.

Per ottenere un oggetto di tipo Content, si usa il metodo getContentService()ottenendo un oggettoContentServiceSoapBindingStub contenService=WebServiceFactory.getContentService();

7.3.4 Administration

Questo servizio serve per gestire le utenze. Come i precedenti, si ottiene un oggettoAdministrationServiceSoapBindingStub administrationService =

WebServiceFactory.getAdministrationService() su cui si possono eseguirei seguenti metodi:

• queryUsers

88 CAPITOLO 7. I WEB SERVICES DI ALFRESCO

• fetchMoreUsers

• getUser

• createUsers

• updateUsers

• changePassword

• deleteUsers

7.4 Problemi nell’uso dei Web Services

Utilizzando i Web Services di Alfresco, si sono riscontrate diverse difficoltà soprat-tutto al primo approccio. Uno dei casi più comuni nell’utilizzo dei WS è quello didepositare un contenuto (un file di testo o binario, per esempio). Dato il tipo mol-to comune di operazione, si potrebbe erroneamente pensare che sia un’operazionesemplice, che basti indicare il file e magari la cartella dove lo si voglia depositare.Vediamo il codice per svolgere questa operazione:

1. ParentReference parentReference2 = new ParentReference (STORE,

riferimentoAllaCartellaPadre.getUuid(), null,

Constants.ASSOC_CONTAINS, Constants.createQNameString(

Constants.NAMESPACE_CONTENT_MODEL, nomePathDelContenuto));

2. NamedValue[] properties2 = new NamedValue[]{

Utils.createNamedValue(Constants.PROP_NAME,

nomeVisualizzatoDelContenuto)};

3. CMLCreate create2 = new CMLCreate("1", parentReference2, null,

null, null, Constants.TYPE_CONTENT, properties2);

4. CML cml2 = new CML();

5. cml2.setCreate(new CMLCreate[]{create2});

6. UpdateResult[] results2 =

WebServiceFactory.getRepositoryService().update(cml2);

7. ContentFormat format = new

ContentFormat(Constants.MIMETYPE_TEXT_PLAIN, "UTF-8");

7.4. PROBLEMI NELL’USO DEI WEB SERVICES 89

8. ContentServiceSoapBindingStubcontenService=WebServiceFactory.getContentService();

9. Contentcontent2=contenService.write(results2[0].getDestination(),

Constants.PROP_CONTENT, contenuto, format);

Come si può vedere, il codice è tutt’altro che semplice. Diamo una spiegazionerigo per rigo.

1. Per prima cosa bisogna avere un oggetto di tipo ParentReference questo,per essere formato, ha bisogno di un STORE (una costante in tutto il pro-gramma), l’uuid della cartella padre (uuid è un identificativo alfanumeri-co univoco di un qualsiasi elemento che si trova dentro Alfresco), Constan-ts.ASSOC_CONTAINS indica tramite la classe che gestisce le costanti crean-do il namespace, che è un contenitore, Constants.createQNameString è unmetodo che forma il path del contenuto che si deve creare sempre usando ilnamespace del modello.

2. L’oggetto NamedValue[] indica le proprietà del contenuto. Qui ci si è limitatoa indicare il nome, ma per farlo è necessario appoggiarsi a una classe utilityche restituisce un oggetto di tipo NamedValue creato a partire da una costanteche specifica che quello è un nome e dal valore del nome vero e proprio.

3. Il passo successivo è creare un oggetto di tipo CMLCreate che specifica l’azioneda compiere, e cioè quella di creare un contenuto. Si passa una costante, il ri-ferimento all’oggetto ParentReference creato precedentemente, altri parametriche possono essere ignorati, si specifica tramite costante che è un contenuto,infine si passa l’oggetto di tipo NamedValue[] creato precedentemente che con-tiene il nome. Questo è un oggetto specifico di creazione e non è quello che ciserve, bisogna infatti creare

4. un oggetto di tipo CML generico che poi verrà passato al servizio

5. su questo oggetto eseguiamo il metodo setCreate a cui passiamo l’oggetto dicreazione specifico

6. Finalmente possiamo eseguireWebServiceFactory.getRepositoryService().update(cml2) che sarebbe il servi-zio di Repository visto nel paragrafo precedente . Questo restituisce un oggetto

90 CAPITOLO 7. I WEB SERVICES DI ALFRESCO

UpdateResult[] utile per verificare l’esito dell’update. Se tutto è andato benel’oggetto sotto il punto di vista “descrittivo” dovrebbe essere stato creato, maancora è una “scatola vuota”. Bisogna metterci il contenuto.

7. Per poter operare a livello dei contenuti, per prima cosa bisogna creare unoggetto di tipo ContentFormat che indica il formato del contenuto.

8. Nella riga 8 otteniamo l’oggetto che ci serve per invocare il servizio.

9. Finalmente, dopo tante righe di codice, invochiamo il metodo che permette dimettere questi byte del contenuto dentro il documentale, passiamo la destina-zione ottenuta dal servizio di Repository, una costante che indica il contenuto,i byte del contenuto e il formato.

Inoltre ottenere il Reference alla cartella padre è tutt’altro che semplice, dato chesolitamente si conosce solo il path della cartella. Tutto quella spiegato fin ora è dacapire e saper usare senza una guida che ti spieghi passo passo come è stato fattoqui, ma solo con alcuni sintetici commenti al codice.

7.5 Creiamo un sovrastrato

Come si evince dal paragrafo precedente con il semplice esempio della creazione di uncontenuto, usare in maniera nativa i WS di Alfresco è una cosa improponibile. Perpoter usare e-prot con i WS di Alfresco, ho creato una classe chiamata “UsiWS.java”che rende l’utilizzo dei WS un po’ meno arduo.

Grazie a questo sovra strato che nel lavoro di tesi è stato inserito dentro ilsoftware e-prot, ma che può essere usato da qualunque altra applicazione essendocodice liberamente disponibile e modificabile, è possibile usare in maniera menocomplessa i WS di Alfresco.

Riprendendo l’esempio visto prima per la creazione di un contenuto, il metododa richiamare è

public Reference createContentFromBytes(Reference

riferimentoAllaCartellaPadre,String nomeVisualizzatoDelContenuto,

String nomePathDelContenuto, byte[] contenuto)

Questo è molto più semplice e intuitivo del codice visto prima.Una cosa ignorata precedentemente è come ottenere, a partire dal path di una

cartella, il suo Reference da cui estrarre l’uuid. Anche quest’operazione, che com-prende diversi passi, viene automatizzata parecchio dalla classe, risolvendo moltiproblemi con cui ci si scontra durante la creazione del path.

7.5. CREIAMO UN SOVRASTRATO 91

Figura 7.2: il sovra strato

7.5.1 I metodi della classe UsiWS

Il lavoro di sviluppo dellla classe è stato fondamentale e difficile, visto la documen-tazione quasi assente e il complesso interfacciamento con i Web Services di Alfre-sco. Questo lavoro può essere molto utile per chi si accinge a svilluppare soluzionid’interfacciamento ad Alfresco con possibilità di estensioni future.

Spieghiamo in breve tutti i metodi che sono stati creati in questa classe:

• public void printNodeDefinition(String nodeId), non molto utile usa-to in fase di sperimentazione, i node definition non contengono i valori, masolo la struttura, richiama il metodo classDefinitionStampaInfo - private voidclassDefinitionPrintInfo(ClassDefinition cd) vedi stampaNodeDefinition.

• public ResultSetRow[] getFolderInfo(Reference riferimentoDelContent)

restituisce tutti i dati di una cartella, fa una query children quindi funzionasolo sulle cartelle.

• public static void outputResultSet(ResultSetRow[] rows) stampa tut-te le info contenuto in rows.

92 CAPITOLO 7. I WEB SERVICES DI ALFRESCO

• public Reference getReferenceFromNodeuuid(String stringuuid) autoep-slicativo.

• public Reference getReferenceFromRow(ResultSetRow resultSetRow) re-stituisce il primo refrence della riga.

• public Reference getParentFromReference(Reference figlio) restitui-sce il riferimento al padre tramite una queryParents.

• public Reference getParentFromRows(ResultSetRow resultSetRow) tra-mite dei rows , si estrae il primo (che magari è l’unico) e da quello si ottieneil riferimento al padre.

• public Reference createContenutFromBytes(Reference

riferimentoAllaCartellaPadre, String nomeVisualizzatoDelContenuto,

String nomePathDelContenuto, byte[] contenuto) autoesplicativo.

• private void printInfoProperties(NamedValue[] properties2) le infodi un array di properties, non molto utile, usato in fase di sperimentazione.

• public boolean existFolder(String path[]) controlla tramite eccezionese una cartella è assente.

• public boolean existFolderUserHomes(String path[]) come sopra ma conpath per la cartella utente, questi medoti non funzionano con i contenuti,valgono solo per le cartelle.

• public Reference getContentReferenceFromPathUserHomes(String path[])

metodo per i contenuti, che tramite il path restituiscono il riferimento delcontenuto.

• public Reference createFolder(String nomeVisualizzato, String path[])

crea una cartella e ne restituisce il riferimento, se cartella è già presenterestituisce null.

• public void deleteSomething(String path[]) funziona sia per le cartelleche per i contenuti, cancella una cartella con tutti i contenuti, quindi atten-zione. Il tutto finisce nel cestino quindi è recuperabile tramite interfacciaweb.

• public String buildAGoodPath(String[] path) metodo che dato un pathin formato array restituisce una stringa unica e ben formata.

7.6. CONCLUSIONI 93

• private String createPathUserHomes(String[] path) crea il path preci-so per le cartelle utente, che è diverso da

• private String createPath(String[] path) questo invece crea il path percartelle di tipo non utente

• public static ResultSetRow[] searchContents(String words) La ricer-ca viene fatta sul contenuto del documento e non sulle meta informazioni. Sesi passa una stringa formata da più parole separate da spazi, le parole vengonomess in or, quindi viene restituito se c’è almeno una parola per documento.

• public static void outputResultSet(ResultSetRow[] rows, boolean graffe)

nelle sue varianti stampa il tutto con le informazioni di namespace o meno

• public void printContent(Reference riferimentoDelContent) stampa avideo il contenuto passato per riferimento

• public void updateContent(Reference riferimentoDelContent, String

contenutoAggiornato) aggiorna il contenuto, in eprot non viene usato perchèsi deve fare sul contenuto su cui viene fatto un checkout.

• public Reference createBinaryContent(Reference padre,

String nomeContenuto, String percorsoFile) in disuso conviene passarei byte tramite metodo anche perchè altrimenti diventa difficile fare tutto, nonfunziona bene, andrebbe sistemato

• public NodeDefinition[] readMetaInfo(Reference riferimentoDelContent)

legge la struttura delle meta informazioni restituisce la classe NodeDefinitionche le contiene

7.6 Conclusioni

La domanda che ci si pone durante il lungo e arduo lavoro sui WS di Alfresco è:perché questi servizi sono stati resi disponibili alla comunity in questa maniera? Eun’altra domanda è: perché non sono presenti guide che ne consentano una com-prensione maggiore e che spieghino come usarli al meglio nei dettagli? Capire cosafa il codice e come si possa sfruttarlo al meglio, quando si hanno solo pochi com-menti e pochissimi esempi, non è cosa banale. Anche nei libri scritti su Alfresco,dove vengono spiegati nel dettaglio le sue possibilità di utilizzo, la metodologia diconnessione via Web Service viene soltanto nominata e mai affrontata. La rispo-sta potrebbe essere lo scarso utilizzo di questa metodologia di connessione, quindi

94 CAPITOLO 7. I WEB SERVICES DI ALFRESCO

lo scarso sviluppo sia sotto forma di codice che sotto forma di documentazione daparte della casa produttrice di Alfresco e della comunity open che vi gravita attorno.

Capitolo 8

Integrazione e-prot Alfresco

In questo capitolo, dopo aver descritto come si può istallare e-prot in modalitàsviluppo consentendogli di accedere alle librerie di Alfresco, spieghiamo come deveessere configurato Alfresco per contenere copia dei documenti e delle informazionirelative al protocollo di e-prot. Quindi, analizzeremo la struttura del codice di e-prote descriveremo come ne abbiamo modificato l’architettura, integrandolo con Alfre-sco, sfruttando la classe wsproxy.java. In seguito discuteremo alcuni dei problemiincontrati, l’ambiente che abbiamo realizzato per testare il software, e le funzionalitàaggiuntive di sincronizzazione tra e-prot e Alfresco che abbiamo sviluppato.

L’approccio seguito è consistito nell’individuare nei sorgenti di e-prot le porzionidi codice che operano sul database e nell’espanderle con istruzioni che effettuanooperazioni analoghe su Alfresco. In questo modo viene creata e mantenuta unacopia sincronizzata delle informazioni di e-prot nel sistema documentale. Le partioriginali inserite nel codice di e-prot consistono essenzialmente nella invocazione dimetodi della classe wsproxy.java, descritta nella sezione

8.1 Installazione e-prot

Bisogna installare e-prot in modalità sviluppo. L’alternativa, se non si volesse svi-luppare e-prot, ma usarlo così com’è, è prelevare la cartella “eprot-bin” e fare ildeploy con il proprio application server preferito.

La FlossLab ha sviluppato un’ottima guida per installare eprot [EPRLX] inmodalità sviluppo. La guida in sintesi spiega i passi dell’installazione:

1. come configurare postgresql;

2. come configurare Tomcat;

96 CAPITOLO 8. INTEGRAZIONE E-PROT ALFRESCO

3. indica la versione da installare di Eclipse, quella per sviluppatori j2ee (dettaanche Ganimede);

4. come installare il plugin Tigris per scaricare i progetti dell’svn in eclipse;

5. come configurare eclipse per far partire Tomcat al suo interno.

8.1.1 Problemi d’installazione

In questa sezione sono descritti alcuni problemi d’installazione risolti, in modo daevitare perdite di tempo ad altri possibili sviluppatori.

Librerie

Da aggiungere alla guida ci sono alcuni particolari secondari, ma comunque interes-santi per chi si accinge a compilare e modificare questo software. Eclipse effettuala compilazione e, quindi, il controllo delle librerie tramite le informazioni che so-no specificate nel suo build path e a cui si accede cliccando con il tasto destro delmouse sul progetto, selezionando “Build Path”, “Configure Build Path”, “Java BuildPath”, “Libraries”. In questa finestra bisogna specificare tutte le librerie di Tomcat,se il sistema non le ha inserite automaticamente, e le librerie utili per collegarsi adAlfresco. Se non si è dimenticata nessuna libreria, il sistema non darà errori in fasedi compilazione. Quando però viene eseguito il programma, vengono generate delleeccezioni per librerie non trovate. Questo perchè il server Tomcat non ha la visibilitàdelle librerie di Eclipse. Per risolvere questo problema, bisogna andare nella cartellalib del progetto situata come dice la guida in

workspace\.metadata\.plugins\ org.eclipse.wst.server.core\tmp0\wtpwebapps\eprotDyna\WEB-INF\libe copiarvi tutte le librerie di cui il progetto ha bisogno. Le librerie già presenti

nella lib di Tomcat e-prot le vede di default. Quindi non è necessario fare alcunacopia di queste.

Le librerie da inserire nel build path sono quelle esposte nel capitolo dei WebServices di Alfresco e quelle di Tomcat. Nella cartella della WEB-INF/lib vannocopiate solo quelle di Alfresco.

Come versione di Tomcat, al momento in cui si è effettuato il lavoro di tesi, laversione corrente era la 6.0.18 ne erano presenti due versioni la “Core” e la “Deployer”.La versione che funziona ed è adatta per e-prot è la Core, ma dentro la versioneDeployer vi è una libreria necessaria, che nella Core non è presente. La libreria ètomcat-juli.jar.

8.2. ORGANIZZAZIONE DOCUMENTI IN ALFRESCO 97

Configurazione server Tomcat

Nella guida è presente una sezione in cui si spiega come modificare il file server.xmlpresente dentro le impostazioni di configurazione dentro Eclipse di Tomcat, perpermettere l’accesso al database e impostare altri parametri da parte della web ap-plication e-prot. Dopo aver modificato opportunamente questo file da dentro l’editorEclipse, l’applicazione continuava a non avviarsi, mostrando sempre dei messaggi dierrore. Ho capito che il file non veniva riletto, nonostante le ripetute azioni di aggior-namento forzato che venivano fatte nella directory attraverso il navigatore dell’IDE.Solo riavviando il framework Eclipse il file veniva riletto e il progetto si è potutoavviare con le nuove impostazioni.

8.2 Organizzazione documenti in Alfresco

Come si è visto nel capitolo di descrizione di e-prot, il software di protocollo è divisoin due grosse sezioni. Una funziona da sistema documentale l’altra da protocol-lo, ognuna di queste sezioni funziona in maniera indipendente dall’altra e memo-rizza i dati in maniera diversa. Per questa memorizzazione anche in Alfresco lamemorizzazione avviene in maniera diversa e indipendente.

8.2.1 Sistema documentale

Alfresco riproduce il sistema documentale di e-prot in maniera perfettamente fedele.Dentro e-prot ogni utente può memorizzare i dati solo nella sua home directory.Quindi anche in Alfresco avviene la medesima cosa. Tutti i documenti e la strutturadelle cartelle di e-prot vengono riprodotti esattamente nella cartella definita in Al-fresco come My_Home che corrisponde al nome utente. Il path esatto in Alfresco ècompany_home/user_homes/user_name . Ogni modifica effettuata in e-prot vieneriportata su Alfresco.

8.2.2 Protocollo

Al contrario del sistema documentale, i protocolli devono essere disponibili a tuttigli utenti che ne hanno il diritto. Per questo motivo deve essere creata in fase diconfigurazione del sistema documentale Alfresco, una cartella chiamata “Protocol-li”. Inoltre, deve essere creato un gruppo, di cui fanno parte tutti gli utenti chepossono effetturare protocollazione (un gruppo di cui fanno parte tutti gli utentiè “EVERYONE”), che abbia accesso in scrittura a questa cartella. Per settare le

98 CAPITOLO 8. INTEGRAZIONE E-PROT ALFRESCO

impostazioni, andare da utente amministratore dentro la cartella “Protocolli”, clic-care su “More Actions”, “Manage Spaces Users”, in alto a destra cliccare su “Invite”.Apparirà una schermata dove bisogna selezionare la voce “Groups” (la predefinitaè users), cercare il gruppo degli utenti precedentemente creato (cliccare sul tastoSearch lasciando la casella di testo vuota visualizza tutti i gruppi), selezionarlo enella casella sottostante selezionare il ruolo “Coordinator” e cliccare sul tasto “Addto list”. Successivamente cliccare sul tasto “Next in alto a destra”, si passerà quindialla seconda schermata dove ci sono altre impostazioni che si possono lasciare inva-riate e cliccare nuovamente su “Next” e poi su “Finish”. La configurazione adesso ècompleta.

Dentro la cartella “Protocolli” ci deve essere una cartella per ogni anno. Quellarelativa all’anno corrente viene chiamata “ANNO-2009”. Dentro ogni cartella relativaall’anno è presente una cartella per ogni AOO (chiamata “AOO-1” o “AOO-2” ecosì via) che ha effettuato protocolli nell’anno. Dentro ogni cartella di una AOOviene creata una cartella che contiene i documenti protocollati in base al numero diprotocollo. La prima si chiamerà sempre “DA1A100” e contiene i primi 100 protocolli(il valore 100 è quello di default, ma si può ovviamente cambiare). La scelta dei nomiè tutt’altro che casuale. Se in Alfresco vengono create cartelle che non iniziano perlettera o contengono spazi, il sistema crea il path in una maniera non prevedibile,usando una composizione di caratteri particolari. Questa è una problematica concui ci si è scontrati nell’adattamento da e-prot ad Alfresco, perchè, per accedere,come si è detto precedentemente, si usa il sistema dei nomi e quindi bisogna fare inmodo che il sistema documentale generi un path prevedibile.

La cartella “Protocolli” deve essere creata al momento della configurazione delsistema dopo l’installazione di Alfresco. Le cartelle relative all’anno, alla AOO eai numeri di protocollo vengono create al bisogno dal programma. I permessi dellesottocartelle vengono automaticamente ereditati dalla cartella “Protocolli”.

8.2.3 Utenze

Anche le utenze vengono replicate nel sistema documentale. La maggior parte deicampi sono stati adattati intuitivamente (userName in e-prot corrisponde al campoLoginName in Alfresco). Alcuni hanno dei nomi un po’ meno intuitivi che convienespiegare per non trovarsi con dei dubbi davanti a un codice Java o all’interfacciaweb di Alfresco.

8.3. E-PROT: ANALISI DEI SORGENTI 99

Alfresco Nome AlfrescoSpiegazione

e-prot nome e-prot spiegazione

userOrg id dell’organiz-zazione

aooid identificativo univocoarea organizzativa

omogeneauserMiddlename sta tra il nome e

il cognomecodice fiscale è stato adattato in modo

da avere il codice fiscaleinvece del middlename

che non si usaAlfresco permette in ogni caso di personalizzare le proprietà dell’utente, quindi

è possibile, se lo si ritiene utile fare una mappatura più precisa delle proprietà die-prot su Alfresco.

8.3 E-prot: analisi dei sorgenti

Grazie al lavoro di FlossLab che ha indicato nei dettagli come sviluppare ed estendereil programma sotto Eclipse, questa fase del lavoro è stata facilitata. L’estensioneè permessa grazie al fatto che tutto il codice di e-prot è liberamente disponibile emodificabile. Inoltre, dopo un’analisi molto approfondita, posso affermare che è benorganizzato e nei punti più complessi ha degli adeguati commenti.

Vediamo un’analisi dei package in generale:Vi sono le classi del software base sviluppate da Almaviva, situate nel package

it.finsiel.siged

• it.finsiel.siged.constant: vi sono tutte le costanti: generali, per le email,per accesso ai file, di protocollo, a livello di permessi e valori di ritorno;

• it.finsiel.siged.dao: package la sigla DAO spiega bene la funzione diquesto package Data Access Object, per accesso dei dati a diversi livelli. Inquesto package c’è la classe per verificare la Firma, per accedere al file system,per accedere alle mail certificata e non. Nel sottopackage “jdbc” si trova lamaggior parte del codice sql del progetto;

• it.finsiel.siged.exception: vi sono definite tutte le eccezioni;

• it.finsiel.siged.model: modelli utili al programma, come il fascicolo, ilfaldone ecc;

• it.finsiel.siged.model.documentale: modelli del documentale;

100 CAPITOLO 8. INTEGRAZIONE E-PROT ALFRESCO

• it.finsiel.siged.model.organizzazione : modelli generali;

• it.finsiel.siged.model.protocollo: modelli del protocollo;

• it.finsiel.siged.mvc : tutte le classi utili per realizzare il paradigma delmodel view controller;

• it.finsiel.siged.rdb : contiene una classe sola per modifiche al database;

• it.finsiel.siged.report.protocollo : una classe per i report del proto-collo;

• it.finsiel.siged. servlet : due classi per il servlet;

• it.finsiel.siged.task.jobs: classi per operazioni da compiere in momentideterminati come aggiornamento delle Certification List e la gestione dellee-mail;

• it.finsiel.siged. test : una classe per il test;

• it.finsiel.siged.util : utility per firma digitale, ssl, ldap e altro;

Poi vi sono i package introdotti da FlossLab it.flosslab

• it.flosslab.helper : una sola classe che aiuta a svolgere delle funzioni inmaniera più semplice;

• it.flosslab.jdbc: classi per le operazioni sul db di FlossLab, che eseguonomodifiche sulle caratteristiche in più fornite da FlossLab;

• it.flosslab.mvc : analogo a quello di Almaviva;

• it.flosslab.parser : due classi per leggere i fogli di calcolo e creare iltitolario (una funzione opzionale che aggiunge una comodità in più);

• it.flosslab.report : due classi per generazione di report;

• test : un package di test creato sempre da FlossLab;

Infine c’è una package della “Apache Software Fondation”

• org.apache.commons.threadpool : gestione di pool di thread

8.4. E-PROT: MODIFICA DELL’ARCHITETTURA 101

8.4 E-prot: modifica dell’architettura

E-prot è stato modificato aggiungendo nel package borsoft due classi “UsiWS.java”,analizzata nel capitolo dei WS di Alfresco, e “wsproxy.java”. Quest’ultima è laclasse che s’interpone tra le due e che viene richiamata direttamente dal codice die-prot. Ogni singolo metodo dalle informazioni passategli apre la connessione con ildocumentale tramite WS e, se è necessario, con il database di e-prot, in modo darecuperare le informazioni mancanti.

Vediamo la firma dei metodi e spieghiamone in breve il funzionamento, dove ènecessario

• public static void creaCartella(CartellaVO c)

• private static String[] creaPath(FileVO aFile, CartellaVO c, String

username) throws DataException; crea il path in formato vettore a partireda un file e da una cartella (entrambi del formato di e-prot) che gli vengonopassati.

• private static String[] creaPath(CartellaVO c,String username) throws

DataException; come sopra ma per la cartella

• private static CartellaVO getCartellaPadre(CartellaVO c)

throws DataException; restituisce la cartella padre

• private static CartellaVO getCartellaPadre(int cartellaId) throws

DataException; come sopra ma usando l’id

• private static CartellaVO getCartellaFromID(int id) throws DataException;dall’id di una cartella restituisce l’oggetto cartella di e-prot

• private static String[] getUserNameEPassFromId(int utenteId) throws

DataException; recupera username e password dal db di e-prot a partiredall’id dell’utente

• private static String[] getUserNameEPassFromUserName(String username)

throws DataException; recupera username e password dal db di e-prot apartire dall’username dell’utente

• public static void cancellaCartella(int cartellaId)

• private static void avviabackup() ; avvia il backup chiamando la classe“SincronizzaDBtoAlfr.java”

102 CAPITOLO 8. INTEGRAZIONE E-PROT ALFRESCO

• public static void updateCartella(CartellaVO c); aggiorna la cartella

• public static void newFile(FileVO aFile); crea un nuovo documento,nella parte documentale di Alfresco

• public static void deleteFile(int dfaId) ; elimina un documento

• public static void checkOut(int docId, int utenteId); effettua l’ope-razione di ckeck-in nel documentale

• public static void checkIn(int docId); effettua l’operazione di ckeck-out nel documentale

• public static void updateACheckOutDocumentAndCheckIn(Documento

aDocument); aggiorna un documento di cui è stato fatto il check-out

• public static void move(int cartellaDestinazioneId, int dfaId); spo-sta un documento in un’altra cartella

• public static void addProtocollo(DocumentoVO documento,ProtocolloVO

protocollo); aggiunge un protocollo leggendo le info da una cartella tempo-ranea di Tomcat

• public static void addProtocollo(DocumentoVO documento,ProtocolloVO

protocollo,boolean db); aggiunge un protocollo leggendo le info dal data-base

• private static byte[] estraiInfoProtocolloInByte(ProtocolloVO

protocollo); estrae le meta informazioni di una registrazione di protocollo informato byte

• private static String estraiInfoProtocolloInString(ProtocolloVO

protocollo); estrae le meta informazioni di una registrazione di protocollo informato stringa

• private static String ottieniCartellaDalNumero(int numeroProtocollo);ottiene il nome della cartella dal numero di protocollo

• public static void newUser(UtenteVO utenteVO); crea un nuovo utente

• public static void newUser(UtenteVO utenteVO,String

usernameAlfresco,String passwordAlfresco); crea un nuovo utente con ipermessi di un altro utente di Alfresco

8.4. E-PROT: MODIFICA DELL’ARCHITETTURA 103

• public static void updateProtocolloMetaInfo(ProtocolloVO protocollo);aggiorna le meta informazioni di un protocollo

• public static void addProtocolloAssegnatari(AssegnatarioVO

assegnatario, ProtocolloVO protocollo); aggiunge gli assegnatari alle me-ta informazioni di protocollo

• private static String estraiAssegnatarioProtocollo(AssegnatarioVO

assegnatario); estrae le meta informazioni di un assegnatario

A titolo d’esempio vediamo cosa fa uno di questi metodi e scegliamo addProtocol-lo(DocumentoVO documento,ProtocolloVO protocollo,boolean db):

1. Il metodo per prima cosa estrae le informazioni dell’utente che ha creato ilprotocollo e stabilisce una connessione con il sistema documentale.

2. Se l’operazione di assegnazione di protocollo ha un documento allegato, neestrae il contenuto, capendo dalla variabile booleana db, se deve andare a leg-gere queste informazioni da una cartella temporanea di Tomcat oppure daldatabase. Notiamo che un’operazione di protocollo non deve avere obbliga-toriamente un documento associato, perchè, per esempio, l’operatore non loaveva in formato digitale e non ha voluto convertirlo. In questo caso viene pre-parato un file di testo con il seguente contenuto "Nessun documento associatoal protocollo", in modo da non generare confusione a chi legge dal sistemadocumentale.

3. Successivamente calcola le cartelle dell’anno, dell’Area Organizzativa Omoge-nea e del numero di protocollo, prendendo le informazioni dall’oggetto “proto-collo” di tipo “ProtocolloVO”. Se qualche cartella non esistesse sulla base docu-mentale, perchè ancora non è stata effettuata una registrazione di protocollo,con quelle informazioni viene creata.

4. Viene creato un file di testo con le meta informazioni estratte dall’oggetto“protocollo” e dagli oggetti associati ad esso. Ogni oggetto associato ha un suometodo che serializza le informazioni.

5. Dopo la preparazione delle cartelle, vengono posti i due file con i nomi appro-priati. Uno è il documento, l’altro è un file di testo preparato al punto prece-dente. I nomi sono nel formato "NUM-"+numeroProtocollo+"-Documento-"+nomeFile per il documento di protocollo, "NUM-"+numeroProtocollo+"-Informazioni.txt" per le meta informazioni della registrazione di protocollo.

104 CAPITOLO 8. INTEGRAZIONE E-PROT ALFRESCO

Questo è solo uno dei metodi della classe. Non è stato messo il codice nella spie-gazione perchè è stato scritto in maniera semplice seguendo le buone norme di pro-grammazione, tra cui l’inserimento di commenti nei punti opportuni. Quindi, sia ilcodice di questo metodo che degli altri è facilmente leggibile da chiunque.

In Figura 8.1 è mostrato uno schema semplificato dell’architettura.

Figura 8.1: schema architettura e-prot

Grazie agli strumenti di debug e analisi di codice di Eclipse, si è riusciti ad indivi-duare i punti dove il software accede al database e quindi modificarli opportunamenteper richiamare la classe wsproxy.

I punti del codice orginale di e-prot che sono stati modificati sono i seguenti :

• it.finsiel.siged.dao.jdbc la classe DocumentaleDAOjdbc.java effettual’ultimo passaggio per la memorizzazione degli oggetti accedendo direttamenteal database;

• it.finsiel.siged.dao.jdbc.DocumentoDAOjdbc.javamanipola l’oggetto do-cumento che poi viene serializzato e memorizzato nel database;

• it.finsiel.siged.dao.jdbc.UtenteDAOjdbc.java come DocumentoDAO-jdbc, ma a livello di utente;

• it.finsiel.siged.dao.jdbc..ProtocolloDAOjdbc come le due viste sopra,ma a livello di protocollo;

8.5. DIFFICOLTÀ INCONTRATE 105

• it.finsiel.mvc.buisiness.DocumentaleDelegate.java prepara l’accessoal database a livello un po’ più alto controllando gli oggetti preparando leconnessioni che poi vengono passati alla classe DocumentaleDAOjdbc;

• it.finsiel.mvc.buisiness.ProtocolloDelegate.java come Documenta-leDelegate ma a livello di protocollo.

8.5 Difficoltà incontrate

La difficoltà maggiore nell’implementazione è sicuramente la corretta comprensionedell’uso dei web service di Alfresco, per i motivi visti nei capitoli precedenti. Unaltro grosso scoglio è stato quello di adattare il modello dei web services di Alfresco.Questo è basato sui riferimenti dei suoi oggetti conosciuti come Reference e sugliidentificatori univoci uuid di ogni oggetto.

Una possibile soluzione del problema sarebbe stata quella di modificare il data-base ed aggiungere per ogni oggetto l’identificatore univoco uuid. In questa manierasarebbe stato tutto più facile. Il problema risiede nel fatto che l’uso del documentaleviene messo anche per semplificare la vita agli amministratori che possono aggiun-gere alla loro versione di e-prot questa funzionalità, cambiando solamente le classiJava. In questo modo si può ottenere anche un backup su un sistema documentale.La modifica del database invece è un’operazione che non semplifica affatto, ma rendetutto molto difficoltoso. Per questo motivo si è scelta un’altra strada.

E-prot basa tutta la sua organizzazione sui nomi dei file. Quindi si è dovutoadattare tutto il sistema da nomi a riferimenti univoci, il che ha portato le seguentiproblematiche che si sono dovute risolvere:

• ricerche dei contenuti (file o cartelle) in base al nome;

• attenzione alla duplicazione dei nomi dei contenuti. Alfresco per ogni conte-nuto ha un nome file e un path. Bisogna prestare attenzione perchè questedue proprietà potrebbero non coincidere;

• la navigazione delle cartelle in e-prot è sempre la stessa, in Alfresco invecevaria in base alla tipologia di cartella a cui si accede;

• gli spazi i caratteri speciali vengono trattati in maniera non prevedibile in Al-fresco. Quindi, prima di passare un qualsiasi file o cartella, bisognava sostituirele suddette occorenze.

106 CAPITOLO 8. INTEGRAZIONE E-PROT ALFRESCO

8.6 Ambiente di test

Per settare in maniera adeguata l’ambiente su cui lavorare ed effettuare i test hodeciso di riprodurre fedelmente l’amministrazione del mio comune di residenza, Val-verde, in provincia di Catania con una popolazione di 7000 abitanti. Sono statiriprodotti gli utenti e gli uffici in maniera fedele rispetto alla reale organizzazionedell’amministrazione. Per motivi di test però è stata modulata un’altra organiz-zazione delle Aree Organizzative Omogenee (AOO). Nella realtà del comune vi èun solo ufficio di protocollo realmente attivo e poi tutti gli uffici a cui i documentivengono smistati, quindi una sola AOO. Per effettuare i test si è suddiviso invece ilcomune in più AOO. Questo è anche il sistema più adatto in modo che le AOO siscambino i documenti ufficiali.

Ecco l’elenco:

1. Direzione Generale, capo settore e segretario Marano Sebastiano

2. Servizi Demografici e direzione generale del protocollo, capo settore MicheleCosentino

3. Servizi Sociali, capo settore Maria Magrì

4. Ufficio Tecnico, capo settore Laganà Giacomo

5. Ragioneria, capo settore Balsamo Rosario

6. Ufficio Servizi di manutenzione, capo settore Finocchiaro Giuseppe

7. Vigili Urbani, capo settore Pavone Filippo

Al livello di test sono state effettuate diverse registrazioni di protocollo da parte dipiù utenti di diverse AOO. Inoltre, è stato riprodotto un archivio di lavoro tipico diun ufficio comunale con molteplici cartelle e documenti in lavorazione e completati.

8.7 Sincronizzazione

8.7.1 Spiegazione e funzionalità principali

La situazione ideale è quella in cui il sistema documentale Alfresco viene messo infunzione in contemporanea al sistema di protocollo e-prot, e che rimanga sempredisponibile. In questo modo avviene il salvataggio contemporaneo sia nel databaseche nel sistema documentale.

8.7. SINCRONIZZAZIONE 107

Vi è la possibilità però che la base documentale per qualche ragione tecnica abbiadei disservizi e quindi il sistema di protocollo debba continuare a funzionare senzail suo supporto. In questo caso lo stato del sistema documentale rimarrà arretratorispetto a quello del protocollo.

Un’altra possibilità invece sta nel fatto che il sistema di protocollo sia già attivonella pubblica amministrazione e che si voglia aggiungere la base documentale in unsecondo momento.

In entrambi i casi è necessaria una funzionalità che permetta di portare o ri-portare lo stato del documentale allo stesso livello del sistema di protocollo. Que-sta funzionalità viene ricoperta dalla classe “SincronizzaDBtoAlfr.java”. La classeeffettua una sincronizzazione su tre livelli attivabili in toto o in maniera disgregata.

1. Sincronizzazione delle utenze.

2. Sincronizzazione del sistema di protocollo.

3. Sincronizzazione della parte documentale dei singoli utenti.

E’ fortemente consigliato effettuare sempre la sincronizzazione totale ma se per qual-che ragione dipendente dall’amministrazione si dovesse usare la funzione disgregataconviene seguire l’ordine dell’elenco. O meglio, va effettuata sempre prima di tuttouna sincronizzazione degli utenti e solo dopo attivare la funzione 2 e 3 di sincroniz-zazione. Infatti nel caso del protocollo genererebbe confusione vedere un documentodi proprietà di un utente che non esiste nel sistema documentale. Nel caso del si-stema documentale genererebbe errori e quindi non sarebbe possibile effettuare, lagestione di file e cartelle di un utente inesistente, anche perchè vengono posti nellacartella di proprietà dell’utente stesso.

8.7.2 La funzione di backup

Un possibile uso del progetto potrebbe essere quello di effettuare solamente il bac-kup. Se l’amministrazione ritenesse opportuno, per le sue necessità, non usare ilsistema documentale in maniera sincronizzata, ma usarlo solamente in fase di bac-kup, l’utilizzo di questa classe sarebbe preponderante. E’ possibile impostare in fased’installazione il sistema come non sincronizzato e solo al momento del backup, effet-tuare la connessione al sistema documentale Alfresco, ricalcando tutta la strutturadelle utenze, dei protocolli e dei documenti.

108 CAPITOLO 8. INTEGRAZIONE E-PROT ALFRESCO

8.7.3 Architettura della classe SincronizzaDBtoAlfr.java

La classe è molto semplice, perchè invoca diversi metodi delle classi “UsiWS.java” e“wsproxy.java” che abbiamo già visto precedentemente e dove viene svolto tutto illavoro.

I metodi principali sono questi:

• public boolen tutto(String username, String password); sincronizza tut-to

• public boolean sincroUtenti(String username, String password); sin-cronizza gli utenti

• public boolena sincroProtocolli(String username, String password,

int anno); sincronizza i protocolli dell’anno specificato

• public boolean sincronizzaDocumentale(String username,

String password); sincronizza la cartella documentale di ogni utente

• private void sincroFile(String userHomeName, String username, String

password); usato nella sincronizzazione dei file del documentale

• private void sincroCartelle(String userHomeName, String username,

String password); usato per la sincronizzazione delle cartelle del documen-tale

8.8 Database e dettagli del codice

Questa sezione spiega alcuni dettagli relativi al codice di e-prot 1.2 e al suo database.Queste informazioni, ricavate durante lo studio, e la modifica dei sorgenti possonoessere utili a chi volesse sviluppare in una qualsiasi direzione il software di protocollo.

La tabella principale è sicuramente “protocolli”, dove ci sono le informazioniprincipali del protocollo. L’oggetto corrispondente che contiene tutte le info del-la tabella è ProtocolloVO del package it.finsiel.siged.mvc.vo.protocollo . Per ac-cedere a questa tabella, si deve usare la classe “ProtocolloDAOjdbc” nel packageit.finsiel.siged.dao.jdbc che ha tutti i metodi adatti.

La tabella, dove sono contenuti i documenti relativi ad ogni protocollo (un proto-collo può non avere documenti allegati, o averne uno quello principale, o oltre quelloprincipale può avere altri documenti) è la tabella “documenti”. Il campo “documen-to_id” chiave primaria della tabella “documenti”, è anche la chiave esterna dellatabella “protocolli” che lega le due entità (ci si riferisce al documento principale di

8.8. DATABASE E DETTAGLI DEL CODICE 109

un protocollo). Per accedere alla tabella “documenti”, si usa la classe Documen-toDAOjdbc del package it.finsiel.siged.dao.jdbc. La classe che viene serializzata èDocumentoVO.

Per quanto riguarda la parte relativa alle funzioni di documentale, integrate ine-prot le tabelle principali sono due:

1. la tabella “cartelle”, con oggetto da serializzare CartellaVO;

2. la tabella “doc_file”, con oggetto da serilizzare DocumentoVO;

La classe di riferimento per effettuare le operazioni è “DocumentaleDAOjdbc.java”.

110 CAPITOLO 8. INTEGRAZIONE E-PROT ALFRESCO

Capitolo 9

Conclusioni

Il lavoro di tesi è iniziato con uno studio approfondito della documentazione e dellespecifiche CNIPA. Questa parte del lavoro ha richiesto un notevole impegno. Suc-cessivamente, si è passati ad un’analisi degli strumenti tecnologici che ha portatoalla scelta della soluzione d’integrare Alfresco con e-prot, dopo aver pure analizzatouna soluzione proposta dalla regione Piemonte, che proponeva una versione modi-ficata di Alfresco, denominata Doqui [DOQUI]. Per quanto riguarda e-prot, ci si èscontrati con una evoluzione delle versioni che è avvenuta durante il lavoro di tesi.Tutto quest’iter ha comportato un impegno superiore al previsto per inquadrareesattamente il problema e configurare opportunamente gli strumenti richiesti per losvolgimento del lavoro.

Completata questa fase, ci si è focalizzati sull’obiettivo principale di integrazio-ne de e-prot con Alfresco, utilizzando le interfacce Web Services già disponibili perAlfresco. A causa della mancanza di documentazione, l’interazione con Alfrescoattraverso i suoi Web Service si è dimostrato tutt’altro che semplice, rendendo ne-cessario ricorrere per l’uso a supposizioni, esperimenti e tentativi, prima di ottenereun utilizzo senza eccezioni, corretto, semplice e scorrevole.

A tal proposito, il lavoro di tesi ha portato alla produzione di documentazione(cap 7) e di utility (classe UsiWS.java), che opportunamente pubblicizzati potrannoessere molto utili a chiunque voglia interagire con Alfresco in maniera automatizzataattraverso i suoi Web Services. Si intende ora avviare un nuovo progetto di sviluppofinalizzato all’evoluzione ed alla manutenzione del codice e della documentazioneprodotta. In questo modo il lavoro svolto potrà essere maggiormente valorizzato enon rimarrà legato al solo ambito di tesi o a quello degli sviluppatori di e-prot.

Superati i problemi sopra descritti, è stato quindi possibile raggiungere gli obittividi integrazione che ci si era posti inizialmente, producendo una nuova versoine di

111

112 CAPITOLO 9. CONCLUSIONI

e-prot, in grado di supportare completamente le specifiche legate al ciclo di vita deidocumenti, un requisito obbligatorio per un software per il protocollo informatico.

Il prodotto finale, di questa tesi, e-prot con Alfresco, anche se testato e funzionan-te, non è un prodotto completamente maturo. Manca il riscontro con gli utilizzatoriin un reale ambiente di produzione con molteplici utenti collegati che effettuanooperazioni contemporaneamente. Quindi, pur non potendo assolutamente generaredanni agli archivi, dato che crea una copia aggiuntiva delle informazioni, nella suamodalità sincrona è ancora da perfezionare a causa dei rallentamenti che questaconnessione al documentale può causare sotto stress. Al contrario, la funzionalitàdi backup è a un buon livello di maturazione, perchè non ci sono tempi di rispostastringenti nell’ordine dei secondi, come invece lo sono le operazioni di registrazionedi protocollo. In entrambi i casi però potrebbero emergere dei malfunzionamentiminori durante l’utilizzo reale, a causa della relativa immaturità del prodotto.

La tesi è stata anche parte delle attività di sperimentazione del protocollo in-formatico all’interno dell’azienda Link.it, interessata soprattutto a studiare l’inte-roperabilità delle specifiche di Protocollo Informatico nell’ambito del paradigma diCooperazione Applicativa SPCoop. Per questo motivo è stato fatto un lungo lavorodi analisi delle specifiche, scelta della strumentazione, motivazioni e modalità d’in-tegrazione. Tutto ciò ha comportato un impiego di tempo che è stato sottratto allavoro di sviluppo vero e proprio. Nonostante ciò, il prodotto risultante raggiungegli obiettivi che ci era posti inizialmente. Un interessante sviluppo futuro è costi-tuito da una maggiore integrazione di e-prot con il sistema documentale Alfresco,arrivando alla dismissione completa dell’attuale DB usato da e-prot. Questa è un’i-dea già emersa in FlossLab, l’azienda attuale manutentrice del progetto e-prot, chevorrebbe realizzarla attraverso le api Java utilizzando lo standard java JSR-170.In alternativa, lo stesso obiettivo potrebbe essere perseguito utilizzando l’approccioWeb Services, come gia’ in parte utilizzanto in questa Tesi. Si tratta comunquedi una scelta da valutare approfonditamente, sperimentando entrambe le soluzioni,considerando difficoltà, prestazioni e adattabilità al progetto e-prot.

Bibliografia

[GOV4J] L’introduzione che descrive la comunity Gov4jhttp://www.gov4j.it/gov4j/doc/gov4j_intro.pdf

[LGUI] Linee guida per l’adozione del protocollo informatico e per iltrattamento informatico dei procedimenti amministrativi. Il file èLinee_guida_prtcl.pdf disponibile sul sito del CNIPA

[DEMA] La dematerializzazione della documentazione amministrativa.Libro Bianco del Gruppo di Lavoro interministeriale per ladematerializzazione della documentazione tramite supporto digitale. Ilfile è dematerializzazione.pdf si può scaricare dal sito del CNIPA all’urlhttp://www.cnipa.gov.it/site/_files/Libro%20BiancoDEM.pdf

[GED1] Linee guida alla realizzazione dei sistemi di protocolloinformatico e gestione dei flussi documentali nelle pubblicheamministrazioni. Il file disponibile sul sito CNIPA è gedoc2.doc i capitolidi riferimento sono il 4 e il 5.

[DOCE] I miglioramenti dalla versione 1.1 alla versione 1.2 di e-prot. Ilfile è progetto_estensione_eprot R1 .2_v1.0.odt , un documento che sitrova nella cartella doc della versione 1.2 di e-prot scaricabile dall’svn aquesto url svn://gov4j.it/gov4j/eprot/branches/1.2

113

114 BIBLIOGRAFIA

[TENAR] La gestione elettronica dei documenti e la tenuta degli archivi.Principi generali e requisiti archivistici ilo file è sito CNIPAgest_doc_e_tenuta_degli_archivi.pdf

[SVN] Gli esempi per l’utilizzo dei web services in Alfresco possono esserescaricati a quest’indirizzohttp://svn.alfresco.com/repos/alfresco-open-mirror/alfresco/HEAD/root/projects/sdk/samples/WebServiceSamples/source/org/alfresco/sample/webservice/

[INTRO1] Il progetto Open Source Jakarta della comunity di apachehttp://jakarta.apache.org

[INTRO2] Il sito ufficiale del progetto OpenSPCoop:http://openspcoop.org

[INTRO3] Progetto JAPS: http://www.japsportal.org

[INTRO4] Indagine conoscitiva sul software a codice sorgente apertonella Pubblica Amministrazione:http://www.innovazione.gov.it/ita/normativa/indagine_opensource.shtml

[INTRO5] Direttiva del 19 dicembre 2003 "Sviluppo ed utilizzazione deiprogrammi informatici da parte delle PA":http://www.innovazione.gov.it/ita/normativa/allegati/Dir1912 03.pdf

BIBLIOGRAFIA 115

[INTRO6] Osservatorio Open Source del CNIPA:http://www.cnipa.gov.it/site/it- IT/Attivit%C3%A0/Osservatorio_Open_Source/

[INTRO7] Conferenza Salpa:http://www.salpa.pisa.it/salpa/cda/templates/index_it.jsp

[INTRO8] Sessione Esperta di OSS2006:http://oss2006.dti.unimi.it/index.php?esperta.html

[EPRLX] Le istruzioni per la configurazione di e-prot in eclipse si trovanonei file eprot-linux.pdf o (la versione analoga per windows)eprot-windows.pdf . Disponibili nella cartella eprot-src/doc dell’svn

[STAT-INF] Sito del CNIPA, stato d’informatizzazione nella pubblicaamministrazione http://www.cnipa.gov.it/site/it-IT/Attività/Stato_dell’informatizzazione_della_PA/Informatizzazione_della_PAC/

[REP06] Il documento pdf dei report dell’anno 2006http://www.cnipa.gov.it/site/_files/cnipa_relaz06_v2.pdf

[CHEKLIST] La check list per Sistemi di protocollo informatico e digestione dei flussi documentali si può recuperare dal sito del CNIPA aquesto url http://www.cnipa.gov.it/site/_files/check-list_vfin.pdf

[OPSPC] OpenSPCoop sito ufficiale http://www.openspcoop.org/

116 BIBLIOGRAFIA

[SPC01] “Sistema Pubblico di Cooperazione: Architettura”, Versione 1.0,25 Novembre 2004, http://www.cnipa.gov.it/site/_files/SPCoop-Architettura_v1.0_20041125_.pdf

[eSITE] Il sito di e-prot con molte informazion utili http://www.e-prot.it/

[ALFIT] La presentazione in italiano di Alfrescohttp://www.alfresco.com/it/about/

[jAPS] Il sito ufficiale di jAPS http://www.japsportal.org/jAPSPortal/

[j4sign] Il link a source forge dove è possibile sacaricare il progettohttp://j4sign.sourceforge.net

[OPEC] Il sito ufficale di Open PEC http://www.openpec.org

[DOQUI] Doqui, il sistema Alfresco modificato dalla regione Piemontehttp://www.doqui.it

(PDF) Tesi di Giuseppe Borgese pdfsubjetc - CORE · Capitolo1 Introduzione Numerosi soggetti istituzionali sono oggi attivi nel promuovere l’adozione e lo svi-luppo del software Open - PDFSLIDE.NET (2024)