Realizzazione di un sistema per l’archiviazione, la ...conservazione.pa.umbria.it/documentazione-airumbria/Specifiche... · Realizzazione di un sistema Progetto AIRUmbria per l’archiviazione,

Progetto AIRUmbria

Realizzazione di un sistema per l’archiviazione, la conservazione sostitutiva e la dematerializzazione dei documenti MODULI SW REALIZZATI E FUNZIONANTI DEL SERVIZIO DI

CONSERVAZIONE Specifiche del nucleo minimo di conservazione

1/61

Codice: 571-99-02-663 Emesso il:2-08-2011 Versione: 2

PROGETTO AIRUMBRIA

Realizzazione di un sistema per l’archiviazione, la conservazione sostitutiva e la dematerializzazione

dei documenti

MODULI SW REALIZZATI E FUNZIONANTI DEL SERVIZIO DI CONSERVAZIONE

Specifiche del nucleo minimo di conservazione (documento 6.6.3)

Progetto AIRUmbria



2/61


Data:

01/08/2011 Compilato: Alessandro Cavazzoni____________________ Alfredo Larotonda ____________________

Data: 02/08/2011 Rivisto: Alfredo Larotonda ____________________

Data: 02/08/2011 Approvato: Brunella Pierini ____________________

Destinatari: Webred S.p.A. Regione Umbria

Progetto AIRUmbria



3/61


Indice dei contenuti

1 GENERALITÀ .............................................................................................................................. 5

2 GENERALITÀ .............................................................................................................................. 6

3 SCHEMA CONCETTUALE DEL NUCLEO MINIMO DI CONSERVAZIONE ............. 8

4 ARCHITETTURA LOGICA DEL GATEWAY .................................................................... 10

5 ARCHITETTURA TECNICA DEL GATEWAY ................................................................... 12

5.1 SERVIZI .............................................................................................................................................. 15

6 CASI D’USO DI UTILIZZO DEL GATEWAY ..................................................................... 17

6.1 INVIO IN CONSERVAZIONE DI UNO O PIÙ DOCUMENTI CON

COMUNICAZIONE DI TIPO SINCRONO ................................................................................... 17

6.1.1 CONTESTO............................................................................................................................. 17

6.1.2 SCENARIO BASE .................................................................................................................. 17

6.1.3 DETTAGLI .............................................................................................................................. 21


COMUNICAZIONE DI TIPO ASINCRONO ................................................................................ 22

6.2.1 CONTESTO............................................................................................................................. 22

6.2.2 SCENARIO BASE .................................................................................................................. 22

6.2.3 DETTAGLI .............................................................................................................................................. 28

6.3 CONSULTAZIONE DELLE INFORMAZIONI DI TRACING ................................................... 29

6.3.1 CONTESTO ............................................................................................................................................. 29

6.3.2 SCENARIO BASE ................................................................................................................................... 29

6.3.3 DETTAGLI .............................................................................................................................................. 31

7 ANALISI PER LA GENERALIZZAZIONE DELL’INTERFACCIA VERSO IL

CONSERVATORE .................................................................................................................... 34

7.1 STRUTTURA DOCUMENTO DI CONSEGNA AD UNIMATICA ........................................... 34

7.2 STRUTTURA DOCUMENTO DI TEST DI CONSEGNA AD UNIMATICA ............................ 36

7.3 TABELLA PARAMETRI DI RICHIESTA NORMALIZZATA PER SERVIZIO DI

RICHIESTA CONSEGNA ................................................................................................................ 38

7.4 TABELLA PARAMETRI DI RISPOSTA NORMALIZZATA A SERVIZIO DI

RICHIESTA CONSEGNA ................................................................................................................ 47

8 COLLEGAMENTI ED AUTORIZZAZIONE ....................................................................... 52

9 MODIFICHE RICHIESTE AL SISTEMA INTERPA .......................................................... 53

9.1 MODIFICHE ALL’INTERFACCIA UTENTE ED ALLE FUNZIONALITÀ

GESTIONALI PER SUPPORTARE L’INVIO MANUALE AL GATEWAY DI

CONSERVAZIONE .......................................................................................................................... 53

9.2 MODIFICHE ALLE FUNZIONALITÀ GESTIONALI PER L’INVIO AUTOMATICO

AL GATEWAY DI CONSERVAZIONE ......................................................................................... 60

Progetto AIRUmbria



5/61


1 GENERALITÀ

Oggetto:

Realizzazione di un sistema per l’archiviazione, la conservazione sostitutiva e la dematerializzazione dei documenti MODULI SW REALIZZATI E FUNZIONANTI DEL SERVIZIO DI CONSERVAZIONE – Specifiche del nucleo minimo di conservazione

Riferimenti a documenti aziendali:

[1] Integrazione Studio di Fattibilità PEI 2007 del 5/11/2009 [2] Manuale d’uso dell’Interfaccia tecnica di riversamento e relativi file tecnici del 1-6-2011 [3] Manuale Conservazione-interfaccia web di caricamento ed esibizione rev. 1 del 2/3/2011

Riferimenti esterni:

Moduli utilizzati

History V1: rilascio iniziale (28-10-2011) V2: recepite le specifiche di ulteriori funzionalità gestionali di INTERPA (02-08-2011)

Glossario, abbreviazioni e acronimi:

SGD Sistema di Gestione Documentale.

SCN Sistema di Conservazione

Progetto AIRUmbria



6/61


2 GENERALITÀ

Il documento fornisce la progettazione tecnica Nucleo Minimo di Conservazione. Per ―nucleo minimo del sistema‖ si intende l’approntamento di una infrastruttura software funzionante in grado di inoltrare, archiviare e conservare documenti. Tale infrastruttura si è evoluta rispetto a quanto descritto nell’integrazione allo studio di fattibilità [1] in quanto si è tenuto conto delle funzionalità esposte dall’aggiudicatario della gara di Conservazione a Norma, UNIMATICA SpA, e del fatto che l’erogatore del servizio può cambiare nel tempo o addirittura possono coesistere più conservatori contemporaneamente. Si è introdotto quindi il concetto di Gateway Unico di Conservazione che rappresenta il componente principale del Nucleo Minimo. Sono inoltre state arricchite le funzionalità previste nel sistema INTERPA, soprattutto al fine di facilitare le operazioni di invio in conservazione da parte dell’utente. Il Gateway Unico di Conservazione ha le seguenti principali caratteristiche:

- Convoglia i documenti da mandare in conservazione e provenienti da una pluralità di sistemi, verso uno o più conservatori

- Il Gateway è progettato per supportare un’interfaccia normalizzata, ovvero un’interfaccia che, nei limiti di quanto noto, è indipendente dal Conservatore che in un dato momento fornisce il servizio di Conservazione a Norma. Per la normalizzazione sono state considerate le interfacce di UNIMATICA ed INFOCERT che operano in modo differente tra loro. IL documento riporta l’analisi relativa;

- Utilizza uno strumento di amministrazione per il tracing dei flussi.

Il nucleo minimo si avvale anche di ulteriori funzionalità messe a disposizione dal Conservatore e da altre funzionalità che devono essere aggiunte al

Progetto AIRUmbria



7/61


prodotto INTERPA. In particolare: - Il Conservatore mette a disposizione una interfaccia web per il

caricamento manuale dei documenti e per l’esibizione dei documenti. L’interfaccia è descritta in [3]. Tale interfaccia, relativamente al caricamento manuale dei documenti, è adatta per piccoli interventi e non è utilizzabile per grosse moli di archiviazione;

- INTERPA viene adeguato o mediante l’integrazione al Gateway Unico di Conservazione a cui

si è accennato sopra o mediante l’aggiunta di una interfaccia per l’invio manuale al

Gateway o mediante l’aggiunta di ulteriori funzioni gestionali per l’invio

automatico al Gateway Il capitolo 3 illustra lo schema concettuale complessivo del nucleo minimo. I capitoli 4, 5, 6 sono specifici del Gateway Unico di Conservazione. Il capitolo 7 costituisce l’analisi dei dati di interfaccia di INFOCERT ed UNIMATICA al fine di sintetizzare un’interfaccia unica che si possa adatatre facilmente ai vari Conservatori. Il capitolo 9 è relativo alla specificazione delle modifiche all’applicativo INTERPA.

Progetto AIRUmbria



8/61


3 SCHEMA CONCETTUALE DEL NUCLEO MINIMO DI CONSERVAZIONE

Il sistema del Nucleo Minimo di Conservazione, operante in logica centralizzata, consente l’accesso alle sezioni applicative a qualsiasi utente autorizzato pur con le limitazioni iniziali e le differenze tipologiche rispetto a:

Enti che già utilizzano il sistema InterPA in ASP o in house (Ente tipo#1).

Questi enti, grazie alle modifiche effettuate su INTERPA, potranno

mandare in conservazione documenti manualmente o con modalità

semiautomatiche/automatiche. L’operazione di adattamento

dell’applicazione INTERPA è per l’Ente a costo zero;

Enti che hanno sistemi gestionali diversi da InterPA (Ente tipo#2). Questi

Enti dovranno adattare il loro applicativo all’interfaccia esposta dal

gateway e descritta dettagliatamente in [2]. Se vorranno potranno

aggiungere funzionalità aggiuntive all’applicativo per automatizzare

l’invio dei documenti. Gli oneri di tali adattamenti sono a carico dell’Ente;

Enti che non hanno un sistema di protocollo/gestione documentale

informatizzato (Ente tipo#3). Per questi Enti è disponibile un semplice

applicativo web messo a disposizione dal Conservatore che consente di

riversare documenti in modo semplificato

Tutti gli enti possono esibire i documenti conservati, operazione che

avviene di norma molto raramente, utilizzando l’interfaccia messa a

disposizione dal Conservatore

La figura seguente rappresenta lo schema concettuale del sistema AIR-Umbria e le relazioni tra le diverse tipologie di Ente mettendo in evidenza le componenti da realizzare (in arancione).

Progetto AIRUmbria



9/61


In particolare le componenti da realizzare sono le seguenti:

1. Gateway Unico di Conservazione

2. Modulo di integrazione di INTERPA con il Gateway e funzionalità di invio manuale al Gateway

3. Modulo di funzionalità gestionali aggiuntive di INTERPA per l’invio automatico al Gateway

Gateway

Unico di

Conservazione

Sistema in

produzione –

CONSERVATORE

Richiede

di conservare

Richiede

di conservare

Sistema di test

CONSERVATORE

INTERPAENTE tipo#1

Con INTERPA

(in ASP o on-site)

Integrazione

Funz. Gest. Agg.

Altro sistema

Integrazione

Funz. Gest. Agg.

ENTE tipo#2

Con altra piattaforma

documentale/protocollo

Richiede

di conservare ENTE tipo#3

Senza documentale/

protocollo

Richiesta di

conservare

Richiede

di esibireTUTTI gli ENTI

COAP

SPC

COAP

SPC

Figura 1 Schema concettuale del nucleo minimo di conservazione

Progetto AIRUmbria



10/61


4 ARCHITETTURA LOGICA DEL GATEWAY

L’architettura prevede l’introduzione di un Gateway di Conservazione che effettua fondamentalmente due operazioni:

- Il disaccoppiamento più alto possibile tra l’ente ed il conservatore introducendo un’interfaccia normalizzata esposta dal Gateway

- La gestione degli invii in modalità sincrona ed asincrona. - La registrazione delle informazioni relative a ciascun invio

Il disaccoppiamento viene ottenuto mediante strati di trasformazione che riportano le strutture dati di input/output ad una forma ―neutra‖ intermedia indipendente dal Conservatore. La struttura a blocchi è riportata nella figura seguente.

GATEWAY

Applicazione

verticale #1

…...

Client ws

Applicazione

verticale #N

Client ws

Framework di reliable messaging

Socket sincrono

Modulo di

trasformazione

Modulo di

tracing

Socket asincrono

DB

Conservatore

decoder

Binding

interface

Modulo di invio

Figura 2 Struttura a blocchi del gateway

Progetto AIRUmbria



11/61


Il flusso generale è invece riportato nella figura seguente.

Operazioni sui datI di REQUEST di conservazione

Applicazione Verticale

Indetificazione

Conservatore

dell-Ente

Trasformazione

nel formato del

Conservatore

supplysupply

input

Il Conservatore è

determinato in funzione

dell’Ente

La relazione Ente-

Conservatore è su DB

Chiamata verso

il Conservatore

Durante la trasformazione

alcuni dati statici possono

essere aggiunti.

Questi dati sono su DB e

possono dipendere

dall’Ente e/o dal

Conservatore

output

Eventuale

bufferizzazione

per la consegna

asincrona

affidabile

Il gateway deve poter

supportare un invio

sincrono ed asincrono

relativamente all’inviante

supply

Operazioni sui datI di RESPONSE di conservazione

output

Trasformazione

nel formato

Normalizzato

Tracing delle

informazioni di

flusso

extract

Le informazioni di tracing

sono poste su un db

consultabili da portale

supply

Tracing delle

informazioni di

flusso

extract

return

Informazioni di

tracing associate a

quelle di request

Figura 3 Schematizzazione del flusso complessivo

Progetto AIRUmbria



12/61


5 ARCHITETTURA TECNICA DEL GATEWAY

L’obiettivo del gateway in base alle considerazioni fatte è:

Disaccoppiare i client degli enti dai conservatori

Garantire la consegna dei messaggi inviati al conservatore

Gestire le problematiche di integrazione (validazione,trasformazione,routing dei messaggi)

Garantire l’elaborazione dei messaggi in modalità asincrona Per garantire i requisiti elencati il gateway sarà realizzato secondo un’architettura a strati che integri un sistema di message brokering. Al client sarà esposta una interfaccia standard indipendente dal conservatore. Il gateway si occuperà di validare formalmente i messaggi in entrata, validare applicativamente i messaggi in base al conservatore scelto , dirigere il messaggio verso il conservatore. Per il client inviare un documento in conservazione consisterà nell’invocazione di un servizio web. Sarà il gateway ad occuparsi delle problematiche di consegna del messaggio. La soluzione sarà quindi un messaging system in cui il sender , l’applicativo dell’ente, genera un messaggio e lo invia al receiver , il conservatore.

Figura 4 - Messaging System

Vanno definite le modalità con le quali saranno esposte le interfacce verso gli enti e le elaborazioni che subisce il messaggio prima di giungere a

Progetto AIRUmbria



13/61


destinazione. La logica è la seguente:

Il client dell’ente si interfaccia con un web service esposto dal gateway.

Il gateway invoca il web service esposto dal conservatore.

All’interno del gateway il messaggio subisce le opportune validazioni e trasformazioni.

Stabilito che il gateway sia per il client dell’ente che per il conservatore è di tipo HTTP ed il messaggio è di tipo SOAP bisogna definire le operazioni da effettuare sul messaggio prima che arrivi a destinazione. Le operazioni possono essere individuate nelle seguenti:

Validazione formale del messaggio in base allo schema definito

Acquisizione delle informazioni sul conservatore a partire dall’ente chiamante

Routing del messaggio in base al conservatore scelto

Validazioni applicative specifiche per il conservatore scelto

Trasformazione del messaggio nel formato del conservatore

Invio del messaggio al conservatore Ad ogni passo del processo vanno inoltre memorizzate le informazioni per il tracing del messaggio.

Progetto AIRUmbria



14/61


Di seguito sono raffigurate le azioni compiute sul messaggio nei vari passi sul canale.

Figura 5 - Pipeline

In Figura 5 i blocchi rappresentano le azioni effettuate sul messaggio nella pipeline. I simboli numerati rappresentano i messaggi nei vari stati della pipeline:

Messaggio 0 Il payload inviato dall’Ente viene ricevuto

Messaggio 1 Il payload ricevuto dal client viene validato in base allo schema

Messaggio 2 In base all’ente chiamante viene effettuato il routing del messaggio verso il corretto conservatore

Progetto AIRUmbria



15/61


Messaggio3 Il payload ricevuto dal client viene validato in base alle regole di business del singolo conservatore

Messaggio4 Il payload viene trasformato nel formato del conservatore

Messaggio5 In base all’esito della chiamata al conservatore viene generata la risposta da ritornare al client.

L’esito di ognuna delle operazioni sopra elencate viene registrata attraverso una chiamata al tracing service. Il processo raffigurato è quello che avviene all’interno del gateway. Il medesimo processo sarà esposto al client in due modalità:

Modalità sincrona (request/response) Il client riceve un messaggio di ritorno indicante l’avvenuta consegna del messaggio al conservatore. Il messaggio sarà un messaggio SOAP con un payload strutturato in base ad uno schema stabilito.

Modalità asincrona (one way) Il client riceve un messaggio di avvenuta consegna al gateway. Il messaggio sarà un messaggio SOAP con un payload strutturato in base ad uno schema stabilito e identico al caso di modalità sincrona.

In caso di modalità asincrona saranno inviate notifiche via email nel caso in cui vi sia un errore nella consegna del messaggio al conservatore.

5.1 SERVIZI

Il gateway definisce tre servizi di base:

ServizioConservazione

Progetto AIRUmbria



16/61


ServizioConservazioneSincrono

ServizioConservazioneAsincrono ServizioConservazione è il servizio esposto ai client con interfaccia standard. Il ServizioConservazione in base al valore del campo tipo_invio contenuto nel messaggio, che può essere SINCRONO o ASINCRONO, dirige l’elaborazione verso il servizio corrispondente. I due servizi ServizioConservatoreSincrono e ServizioConservatoreAsincrono non sono pubblicati all’esterno e sono identici per le azioni operate sui messaggi ma differiscono per la modalità di invocazione.

Figura 6 - Servizi del Gateway

Per ogni conservatore va poi sviluppato un servizio che riceve il messaggio standard lo trasforma nel formato del conservatore ed invoca il web service del conservatore.

Progetto AIRUmbria



17/61


6 CASI D’USO DI UTILIZZO DEL GATEWAY


COMUNICAZIONE DI TIPO SINCRONO

6.1.1 CONTESTO

Un Ente deve inviare, mediante un Applicativo Verticale, uno o più documenti, con eventuali allegati, in conservazione. A questo scopo l’Applicativo Verticale deve invocare l’apposito servizio esposto dal Gateway di Conservazione mediante una interfaccia standard ed attendere l’esito del Gateway. In questo caso la risposta del gateway ha il significato di ―esito della consegna al CONSERVATORE‖ del singolo documento più gli eventuali allegati.

6.1.2 SCENARIO BASE

Obiettivo: Inviare in conservazione uno o più documenti

Pre-Condizioni:

Post-Condizioni per Successo:

L’invocazione del servizio ha restituito successo

Post-Condizioni per Fallimento:

L’invocazione del servizio non ha restituito successo

Estende il caso d’uso: N.A.

Specializza il caso d’uso:

N.A.

SCENARIO DI BASE

Passo Descrizione

1. L’utente dell’Applicazione Verticale richiede l’invio di uno o

Progetto AIRUmbria



18/61


Passo Descrizione

più documenti in conservazione comprensivi o meno di allegati

2. L’Applicazione Verticale, invoca – per ogni documento comprensivo o meno di allegati - il servizio sincrono esposto dal Gateway di Conservazione per la trasmissione dei documenti e si mette in attesa della risposta da parte del Gateway

3. Il Gateway processa il messaggio eseguendo i seguenti task:

Inizia la tracciatura1 del messaggio memorizzando: o Ente o Struttura o Applicazione o Installazione o tipoDocumento o Data/ora richiesta conservazione o ID documento o Nome del documento o Tipo di invio (S=SINCRONO) o Conservatore (attualmente UNI = Unimatica;

INF=INFOCERT) o Numero degli allegati o Per ciascun allegato il nome

assembla il messaggio secondo quanto richiesto dal Conservatore

aggiunge eventuali parametri statici dipendenti dal tipo di Conservatore scelto e dall’Utente

1 E’ opportuno che internamente a ciascuna richiesta di conservazione venga fatto corrispondere un id univoco (idInternoRichiesta) corrispondete alla nuova richiesta

Progetto AIRUmbria



19/61


Passo Descrizione

I parametri aggiunti derivano da parametri presenti in un database

4. Il Gateway invia al Conservatore la richiesta e si mette in attesa della risposta

5. Il Conservatore esegue l’operazione di messa in conservazione

6. Il Gateway riceve la risposta – ESITO = SUCCESSO - dal Conservatore ed esegue i seguenti task:

completa la tracciatura della richiesta inserendo o esito (S = Successo) o data/ora invio o data/ora di risposta o eventuale handle del documento restituito dal

Conservatore (codiceDocumentoConservatore) o eventuale codice della tracciatura restituito dal

Conservatore (richiestaID)

assembla la risposta secondo il formato standard

ritorna all’Applicativo Verticale.

SCENARI ALTERNATIVI

Passo Descrizione

6-alt. Sono presenti degli Errori/Warning generati dal Conservatore o dal Gateway. In questo caso il passo 6 diventa: CASO ERRORE GENERATO DA CONSERVATORE

completa la tracciatura della richiesta inserendo o esito (E = ERRORE oppure W = Warning)

Progetto AIRUmbria



20/61


Passo Descrizione

o data/ora invio o data/ora di risposta o Eventuale codice di tracing (richiestaID) o codice Anomalia o descrizioneAnomalia


ritorna all’Applicativo Verticale

CASO ERRORE GENERATO DA MANCATA CONNESSIONE o INTERNO DEL GATEWAY

completa la tracciatura2 della richiesta inserendo o esito (E = ERRORE oppure W = Warning) o data/ora invio o la data/ora di rilevazione dell’errore o descrizione Anomalia quanto rilevato dal

gateway


ritorna all’Applicativo Verticale

2 Il completamento della tracciatura è dipendente dalla disponibilità del db che potrebbe essere esso stesso causa dell’errore

Progetto AIRUmbria



21/61


6.1.3 DETTAGLI

Operazioni sui dati ricevuti

preliminari al passaggio al ConservatoreApplicazione Verticale

Determina il

Conservatore

Trasformazione

dati per l’invio

supplysupply

input

Il Conservatore è

determinato in funzione

dell’Ente

La relazione Ente-

Conservatore è su DB

Chiamata verso

il Conservatore

Durante la trasformazione

alcuni dati statici possono

essere aggiunti.


possono dipendere

dall’Ente e/o dal

Conservatore

Tracing

supply

Vengono memorizzate le

informazioni per il tracing

dei flussi

Figura 7 Invio sincrono dei dati al Conservatore mediante Gateway

Progetto AIRUmbria



22/61



COMUNICAZIONE DI TIPO ASINCRONO

6.2.1 CONTESTO

Un Ente deve inviare, mediante un Applicativo Verticale, uno o più documenti in conservazione. A questo scopo l’Applicativo Verticale deve invocare l’apposito servizio esposto dal Gateway di Conservazione mediante una interfaccia standard ed attendere la risposta del Gateway. In questo caso la risposta del gateway ha il significato di ―presa in consegna‖ del documento. Sarà compito del Gateway occuparsi della consegna affidabile del documento al Conservatore e tracciarne l’esito sul db del Gateway in modo che il Responsabile della Conservazione dell’Ente possa, se vuole, prenderne visione.

6.2.2 SCENARIO BASE

Obiettivo: Inviare in conservazione uno o più documenti

Pre-Condizioni:

Post-Condizioni per Successo:

L’invocazione del servizio ha restituito successo

Post-Condizioni per Fallimento:

L’invocazione del servizio non ha restituito successo

Estende il caso d’uso: N.A.

Specializza il caso d’uso:

N.A.

SCENARIO DI BASE

Passo Descrizione

Progetto AIRUmbria



23/61


Passo Descrizione

1. L’utente dell’Applicazione Verticale richiede l’invio di uno o più documenti in conservazione comprensivi o meno di allegati

2. L’Applicazione Verticale, invoca – per ogni documento comprensivo o meno di allegati - il servizio asincrono esposto dal Gateway di Conservazione per la trasmissione dei documenti e si mette in attesa della risposta da parte del Gateway

3. Il Gateway processa3 il messaggio eseguendo i seguenti task:

Bufferizza il documento per consentire una molteplicità di ri-trasmissioni al Conservatore nel caso di esito di trasmissione fallito

Inizia la tracciatura del messaggio memorizzando una nuova riga contenente:

o Ente o Struttura o Applicazione o Installazione o tipoDocumento o Data/ora richiesta conservazione o ID documento o Nome del documento o Tipo di invio (A= ASINCRONO) o Conservatore (attualmente UNI = Unimatica;

INF=INFOCERT) o Numero degli allegati

3 3 E’ opportuno che internamente a ciascuna richiesta di conservazione venga fatto corrispondere un id univoco (idInternoRichiesta) corrispondete alla nuova richiesta

Progetto AIRUmbria



24/61


Passo Descrizione

o Per ciascun allegato il nome

Ritorna al chiamante con l’esito di queste operazioni preliminari (Esito = Successo). Non sono in questo caso valorizzati i campi:

o codiceDocumentoConservatore o richiestaID o codice Anomalia

4. Il Gateway estrae dal buffer il messaggio utilizzando le sue politiche di estrazione a tempo coerentemente con il numero massimo di tentativi configurati.

5. Il Gateway:

assembla il messaggio secondo quanto richiesto dal Conservatore

aggiunge eventuali parametri statici dipendenti dal tipo di Conservatore scelto e dall’Utente

I parametri aggiunti derivano da parametri presenti in un data/orabase

6. Il Gateway invia al Conservatore la richiesta e si mette in attesa della risposta

7. Il Conservatore esegue l’operazione di messa in conservazione

8. Il Gateway riceve la risposta dal Conservatore ed esegue i seguenti task:

completa la tracciatura della richiesta inserendo un nuovo record riferito ai dati immessi all’atto della richiesta di conservazione

o esito (S = Successo) o data/ora invio

Progetto AIRUmbria



25/61


Passo Descrizione

o data/ora di risposta o eventuale handle del documento restituito dal

Conservatore (codiceDocumentoConservatore) o eventuale codice della tracciatura restituito dal

Conservatore (richiestaID) o numero del tentativo4

elimina dalla coda il messaggio inviato contenente il documento conservato con successo

SCENARI ALTERNATIVI

Passo Descrizione

3-alt. Sono presenti degli Errori/Warning generati dal Gateway nella fase di ricezione della richiesta da parte dell’Applicazione Verticale. In questo caso il passo 3 diventa: CASO ERRORE GENERATO DA INTERNO DEL GATEWAY

completa la tracciatura5 della richiesta inserendo un nuovo record riferito ai dati immessi all’atto della richiesta di conservazione:

o esito (E = ERRORE) o la data/ora di rilevazione dell’errore o descrizione Anomalia quanto rilevato dal

gateway

elimina il messaggio dalla coda di invio qualora questo

4 Il tentativo si intende riferito al tentativo di trasmissione al Conservatore 5 Il completamento della tracciatura è dipendente dalla disponibilità del db che potrebbe essere esso stesso causa dell’errore

Progetto AIRUmbria



26/61


Passo Descrizione

sia già stato bufferizzato


ritorna al chiamante con Esito = Errore

8-alt Sono presenti degli Errori/Warning generati dal Conservatore o dal Gateway nella fase di invio del messaggio al Conservatore. In questo caso il passo 8 diventa: CASO ERRORE GENERATO DA CONSERVATORE

completa la tracciatura della richiesta inserendo o esito (E = ERRORE oppure W = Warning) o data/ora di risposta o Eventuale codice di tracing (richiestaID) o codice Anomalia o descrizione Anomalia

elimina il messaggio dalla coda di invio

invio una mail di alert ad una casella di email prefissata contenente:

o la descrizione dell’anomalia o il codice dell’ente o il codice del documento (documentoID)

CASO ERRORE GENERATO DA MANCATA CONNESSIONE o INTERNO DEL GATEWAY

completa la tracciatura della richiesta inserendo un nuovo record riferito ai dati immessi all’atto della richiesta di conservazione:

o esito (E = ERRORE oppure W = Warning) o la data/ora di rilevazione dell’errore

Progetto AIRUmbria



27/61


Passo Descrizione

o descrizione Anomalia quanto rilevato dal gateway

o numero del tentativo

dopo tun numero programmabile di tentativi, invio una mail di alert ad una casella di email prefissata contenente:

o la descrizione dell’anomalia o il codice dell’ente o il codice del documento (documentoID) o una dicitura in chiaro che indica l’impossibilità di

inviare il documento ed elimina il messaggio dalla coda di invio

Progetto AIRUmbria



28/61


6.2.3 DETTAGLI

Operazioni sui dati ricevuti

preliminari al passaggio al ConservatoreApplicazione Verticale

Determina il

Conservatore

Trasformazione

dati per l’invio

supplysupply

input

Il Conservatore è

determinato in

funzione dell’Ente

La relazione Ente-

Conservatore è su

DB

Chiamata verso

il Conservatore

Durante la

trasformazione alcuni

dati statici possono

essere aggiunti.


possono dipendere

dall’Ente e/o dal

Conservatore

Tracing

supply

Vengono

memorizzate le

informazioni per il

tracing dei flussi

Funzioni di

buffering e

consegna

affidabile

supply

La consegna dei messaggi

è di tipo asincrono.

Un apposito framework si

deve occupare di buffering

e di consegna affidabile dei

messaggi contenenti il

documento

Invio mail di

alert

supply

Nel caso di

mancate

ritrasmissioni o di

errore dal

conservatore, viene

inviato un alert

Figura 8 Invio asincrono dei dati al Conservatore mediante Gateway

Relativamente al passo 4. è necessario utilizzare una piattaforma concepita per la gestione asincrona dell’invio dei messaggi in ottica SOA. In particolare dovrà essere possibile configurare su tale piattaforma i seguenti parametri:

- numero di tentativi di ritrasmissione in caso di mancata trasmissione dovuta a mancanza di connessione

- tempo di polling - politica di retention dei documenti per i quali è scaduto il timout di

ritrasmissioni

Progetto AIRUmbria



29/61


6.3 CONSULTAZIONE DELLE INFORMAZIONI DI TRACING

6.3.1 CONTESTO

Il Responsabile della Conservazione deve poter accedere ai dati di tracciatura per due motivi fondamentali:

- Verificare, in generale, l’esistenza dei flussi - Rintracciare, nel caso asincrono, esiti di trasmissione effettuate verso il

Conservatore, ricerca di codici nel caso di esibizione o in generale a scopo di verifica in caso di malfunzionamenti

6.3.2 SCENARIO BASE

Passo Descrizione

1. Un utente abilitato (di norma il Responsabile della Conservazione) accede ad un portale appositamente costituito per la consultazione delle informazioni di tracing

2. L’utente si autentica sul sistema FedUmbria ed entra nell’area riservata dove potrà consultare solo i dati relativi al proprio Ente6

3. Il Responsabile della Conservazione potrà interrogare per i seguenti campi:

o data richiesta conservazione DA (giorno/mese/anno)

o data richiesta conservazione A (giorno/mese/anno)

o ID documento o Nome del documento

6 Si osservi che dove esistere il profilo di Amministratore che consente la consultazione delle informazioni di tracing di TUTTI gli Enti

Progetto AIRUmbria



30/61


Passo Descrizione

Di default: data richiesta conservazione A = oggi data richiesta conservazione DA = 3 mesi all’indietro

4. A seguito della richiesta di interrogazione il portale restituisce le informazioni paginate (20-30 record per pagina ordinati in senso decrescente di data-richiesta-conservazione [dal record più recente a quello più vecchio]). Le informazioni restituite sono le seguenti:

a. Struttura b. Applicazione c. Installazione d. tipoDocumento e. Data/ora richiesta conservazione f. ID documento g. Nome del documento h. Tipo di invio i. Data/ora invio j. Esito k. data/ora di risposta l. eventuale handle del documento restituito dal

Conservatore (codiceDocumentoConservatore) m. eventuale codice della tracciatura restituito dal

Conservatore (richiestaID) n. codice Anomalia o. descrizione Anomalia p. descrizione Dettagliata q. Conservatore r. Numero degli allegati s. Per ciascun allegato il nome

Progetto AIRUmbria



31/61


Passo Descrizione

Le informazioni che hanno molteplicità N in funzione del numero dei tentativi di invio sono consultabili in un’apposita finestra di dettaglio.

SCENARIO ALTERNATIVO

5. Qualora l’interrogazione non riesca il portale deve riportare una descrizione user-friendly del problema:

- mancata connessione al db - ….

6.3.3 DETTAGLI

Pagina di filtro

Struttura ApplicazioneTipo

Documento

Data

Richiesta

Identificativo

Documento

Nome

DocumentoEsito

Richieste di conservazione ENTE: xxxxxxxxxx

Ricerca

Home>Ricerca>

Ente Installazione

Figura 9 Pagina di Filtro

Si osservi che esiste anche il campo Ente che può essere utilizzato solo dall’Amministratore di Sistema. I campi Installazione/Struttura/Applicazione si riferiscono alle Strutture ed Applicazioni di quell’Ente

Progetto AIRUmbria



32/61


Pagina dei risultati

Struttura ApplicazioneTipo

Documento

Data

Richiesta

Identificativo

Documento

Nome

Documento

Richieste di conservazione ENTE: xxxxxxxxxx

DA: xx/xx/xxxx A: xx/xx/xxxx

………………..

Dettaglio

Dettaglio

Dettaglio

Dettaglio

Home>Ricerca>Risultati

<< < > >>Sfoglia

Figura 10 Pagina web principale di consultazione informazioni di tracing

Progetto AIRUmbria



33/61


Pagina di dettaglio

Dettagli richiesta di conservazione ENTE: xxxxxxxxxx

Numero richiesta interna: xxxxxxx

ID Documento: xxx Nome documento: xxxxxx

Tipo Documento: xxxxxx

Data Richiesta: xx/xx/xxxx

Conservatore: xxxxxx Installazione: xxxxxxx

Tipo invio: x

Esito

Data/ora invio

Data/ora risposta

ID del conservatore

(eventuale)

ID tracciatura

conservatore

(eventuale)

Codice anomalia

del Conservatore

Descrizione

Anomalia

Descrizione

Dettagliata

Home>Ricerca>Risultat>Dettaglio

<< < > >>Sfoglia

Nomi allegati

Figura 11 Pagina di dettaglio

Progetto AIRUmbria



34/61


7 ANALISI PER LA GENERALIZZAZIONE DELL’INTERFACCIA VERSO IL

CONSERVATORE

7.1 STRUTTURA DOCUMENTO DI CONSEGNA AD UNIMATICA

<ConsegnaAnticipata> </proprieta> <!—è l’identificativo del client. Contiene i valori di FAMILY, ORGANIZZAZIONE, STRUTTURA, USER_ID --> <documento> </chiave> <!—è l’identificativo del documento --> </profilo archivistico> [F] </forza conservazione> [F] </forza conservazione> [F] </tipo documento> [O] <!—ad esempio DELIBERA --> <versione originale> <formato versione> [O] <!—ad esempio PDF --> <parti> <!—se ci sono più parti questo blocco si ripete --> </formato parte> [O] <!—ad esempio PDF --> </numero parte> [O]

<files> <!—questo blocco è ripetibile --> </dati> [O] <!—encoded base 64 --> </nome del file> [O] </formato_file> [O] </id_cliente> [O] </ordine_presentazione> [O] </hash> [F] </riferimento?temporale> [F]

</ files > </parti> </versione originale> <allegati> <!—se ci sono allegati questa parte si ripete in funzione del numero di allegati -->

</tipo allegato> [O] 

</chiave allegato> [O] <!—nome del file allegato --> <versione originale> <formato versione> [O] <parti> </formato parte> [O] </numero parte> [O]

<files> </dati> [O] <!—encoded base 64 --> </nome del file> [O] </formato_file> [O] </id_cliente> [O] </ordine_presentazione> [O] </hash> [F] </riferimento?temporale> [F]

Progetto AIRUmbria



35/61


</ files > </parti> </versione originale>

</allegati> </documento>

</ConsegnaAnticipata>

Progetto AIRUmbria



36/61


7.2 STRUTTURA DOCUMENTO DI TEST DI CONSEGNA AD UNIMATICA

Il documento a cui fa riferimento lo schema di seguito riportato (CARTELLATEST) è composto da:

- 2file principali (FILEA, FILEB) - 2 file allegati (ALLEGATOX, ALLEGATOY)

La struttura schematizzata sarà quindi la seguente: <ConsegnaAnticipata>

</proprieta> <!—è l’identificativo del client. Contiene i valori di FAMILY, ORGANIZZAZIONE, STRUTTURA, USER_ID --> <documento> </chiave> <!—è l’identificativo del documento --> </profilo archivistico> [F] </tipo documento> [O] <!—ad esempio DELIBERA --> <versione originale> <formato versione> [O] <!—ad esempio PDF --> <parti> <!— --> </formato parte> [O] <!—ad esempio PDF --> </numero parte> = 0

<files> <!—FILEA --> </dati> [O] <!—encoded base 64 --> </nome del file> = FILEA_PARTE0 </ordine_presentazione> = 0

</ files > <files> <!—FILEB -->

</dati> [O] <!—encoded base 64 --> </nome del file> = FILEB </ordine_presentazione> = 1

</ files > </parti> </versione originale> <allegati>

</tipo allegato> [O]  </chiave allegato> = ALLEGATOX

<versione originale> <formato versione> [O] <parti> </formato parte> [O] </numero parte> = 0

<files> </dati> [O] <!—encoded base 64 --> </nome del file> = ALLEGATOX


Progetto AIRUmbria



37/61


</allegati> <allegati>

</tipo allegato> [O]  </chiave allegato> = ALLEGATOY

<versione originale> <formato versione> [O] <parti> </formato parte> [O] </numero parte> = 0

<files> </dati> [O] <!—encoded base 64 --> </nome del file> = ALLEGATOY


</allegati> </documento>

</ConsegnaAnticipata>

Progetto AIRUmbria



38/61


7.3 TABELLA PARAMETRI DI RICHIESTA NORMALIZZATA PER SERVIZIO DI RICHIESTA CONSEGNA

Nome normalizzato Unimatica Infocert Note Obbligatorio Tipo Concordato tra Ente e

Conservatore UNIMATICA

Note di utilizzo con UNIMATICA

Posto automaticam

ente dal gateway

Ente organizzazione ente Identificativo specifico per l’Ente cui appartiene il documento. Viene concordato all’atto della delega del servizio al Conservatore. Ad esempio ―COMUNE SPOLETO‖

S Stringa X

Struttura struttura areaOrg Identificativo dell’Area Organizzativa Omognea cui appartiene il documento. Ad esempio ―ECONOMATO‖

S Stringa X

Ufficio - ufficio Codice dell’ufficio cui appartiene il

N Stringa - Valore: ―NA‖

Progetto AIRUmbria



39/61





Posto automaticam

ente dal gateway

documento.

applicazione user_id sgd Identificativo dell’applicazione dell’Utente. Ad esempio ―INTERPA‖

S Stringa X

installazione family endUserId Identificativo dell’installazione . Ad esempio ―PRODUZIONE‖ oppure ―TEST‖

S Stringa X

abilitazioneID - chiaveLegalDoc Chiave di Abilitazione per l’accesso al sistema Infocert

S Stringa Valore: ―NA‖

tipoDocumento documento> chiave:tipo_documento ed anche in profiloArchivistico> chiave:classificazione

classFree Campo per la classificazione dei documenti. Ad esempio ―FATTURA‖.

S Stringa dipende L’insieme dei tipi di documenti può essere autodeterminato o preconfigurato

Progetto AIRUmbria



40/61





Posto automaticam

ente dal gateway

Forza_conservazione Forza_conservazione - Questo parametro indica la precisa volontà del versante di voler conservare il documento anche se questo non e firmato.

Forza_accettazione Forza_accettazione Se questo campo ha valore true il documento verrà accettato, anche se la verifica sui propri file è fallita. Se il campo ha valore false oppure è assente, il documento sarà accettato o respinto in base all'esito della verifica sui propri file.

documentoId1 Chiave> chiave:numero

classKey Un identificatore alfanumerico del

S Stringa

Progetto AIRUmbria



41/61





Posto automaticam

ente dal gateway

documento impostato dall’applicazione. Ad esempio ―PG1001/A‖

documentoId2 Chiave> chiave:anno

- Un identificatore che definisce il contesto temporale nel formato yyyy. Ad esempio ―2011‖.

S Stringa

documentoId3 Chiave> chiave:classificazione

- Un identificatore che definisce il contesto organizzativo del Soggetto Versante o altro identificativo che renda univoche le precedenti chiavi. Ad esempio ―DELIBERE‖. Si osservi che questa proprietà non è legata alla classificazione archivistica, ovvero al contenuto di

S Stringa

Progetto AIRUmbria



42/61





Posto automaticam

ente dal gateway

tipoDocumento

analogicoDigitale - origType Stabilisce se l’origine del file è analogica o digitale. ―D‖ = documento originariamente informatico ―A‖= documento originariamente analogico ―NA‖ default

S Stringa Valore: ―NA‖ X

riferimentoTemporale Riferimento_temporale timestamp Il formato è dipendente dal Conservatore UNIMATICA: YYYY-MM-DDTHH:MM:SS INFOCERT: YYYYMMDDHHMMSS Per Unimatica è la data del documento e può essere usata, assieme al campo

S Stringa Formato da usare YYYY-MM-DDTHH:MM:SS

Progetto AIRUmbria



43/61





Posto automaticam

ente dal gateway

descrizioneRiferimentoTemporale

descrzioneRiferimentoTemporale Descrizione_riferimento_temporale

- Descrive il riferimento temporale. Ad es, ―Data di protocollo‖. E’ facoltativo

vettore Documenti

Si tratta di un vettore di informazioni. Ogni posizione del vettore è riferita ad un documento ed ai relativi metadati

documento Dati - S Stringa Il file deve essere codificato Base64

Potrebbe essere codificato dal

Gateway

tipoAllegato tipo_allegato

Infocert non ha il concetto di

Allegato

Deve essere valorizzato se il documento costituisce un allegato dei documenti principali.

N Stringa Valori possibili - GENERICO - IN_PROTOCOLLO

nomeAllegato chiave_allegato È il nome dell’allegato N Stringa

Progetto AIRUmbria



44/61





Posto automaticam

ente dal gateway

se questi è presente

ordine Presentazione ordine_presentazione fileShowOrder Numerico . Il valore iniziale è dipendente dal Conservatore: UNIMATICA: 0 INFOCERT: 1

S Numerico Valore iniziale pari a 0

nomeFile nome_file

fileName Nome del file corrispondente al documento senza path . Ad esempio se si deve versare “c:\temp\pippo.pdf” va scritto solo ―pippo.pdf” Si osservi che il nome deve essere univoco all’interno dello stesso documento

S Stringa

documentoIDVersante id_cliente - E’ l’identificativo del file corrispondente al documento nel sistema

S Stringa

Progetto AIRUmbria



45/61





Posto automaticam

ente dal gateway

del versante. Può assumere lo stesso valore del nomeDocumento

FormatoDocumento versione Originale>parti>files> formato_file e versione Originale>parti>files> formato_parte

fileMime Rappresenta il formato del file corrispondente al documento. Ad esempio ―PDF‖

S Stringa

versioneFormatoDocumnto versione Originale>parti>files> formato_versione

fileMimeVersion Versione del mime type del file corrispondente al documento. ―NA‖ se il mime non ha una versione significativa. Valore di default ―NA‖.

S Stringa Valore: ―NA‖

hashDocumento Hash fileHash Hash del file corrispondente al

S Stringa Va codificato in esadecimale Potrebbe essere calcolato dal

Progetto AIRUmbria



46/61





Posto automaticam

ente dal gateway

documento. L’hash del file viene calcolato usando i seguenti algoritmi: UNIMATICA: SHA1 INFOCERT: SHA-1

gateway…

Vettore Profilo Archivistico

chiave Documento>profiloArchivistico>proprieta>chiave

- Il profilo Archivistico è una peculiarità di UNIMATICA

No Stringa X

valore Documento>profiloArchivistico>proprieta>valore

- No Stringa X

Progetto AIRUmbria



47/61


7.4 TABELLA PARAMETRI DI RISPOSTA NORMALIZZATA A SERVIZIO DI RICHIESTA CONSEGNA



Note di utilizzo con

UNIMATICA

Posto dal

sistema

Conservatore - - Codice del Conservatrore - UNI = UNIMATICA - INF = INFOCERT

Stringa X

versioneApplicativo ConsegnaAnticipataResponse>VERSIONE_APPLICATIVO

Info>prodotto + versione

dataRicezione - - Nel formato YYYYMMDDHHMMSS

Inserito dal sistema

documentoId1 Chiave> chiave:numero

- Nel caso UNIMATICA la risposta restituisce il codice del documento fornito alla richiesta del conservatore. Nel caso INFOCERT questi campi sono posti dal Gateway

Stringa

documentoId2 Chiave> chiave:anno

- Stringa

documentoId3 Chiave> chiave:classificazione

- Stringa

codiceDocumentoConservatore - Documento>tokenLegalDoc Nel caso INFOCERT la risposta restituisce, IN CASO DI SUCCESSO, un handle del file che di norma va

Stringa Posto a stringa

―NA‖ nel

Progetto AIRUmbria



48/61





UNIMATICA

Posto dal

sistema

memorizzato nell’applicativo qualora si desideri interrogare successivamente il conservatore. Si osservi che il codice è presente se non sono presenti errori o warning Si consiglia di memorizzare tale codice associandolo – nell’Applicativo Verticale- al documentoID. NON VALORIZZATO IN CASO DI SPEDIZIONE ASINCRONA.

caso UNIMATI

CA

richiestaID - - Nel caso INFOCERT la risposta restituisce, SEMPRE, un codice finalizzato al tracing. NON VALORIZZATO IN CASO DI SPEDIZIONE ASINCRONA

Stringa Posto a stringa

―NA‖ nel caso

UNIMATICA

Esito esito success La codifica di questo campo da parte di UNIMATICA ed INFOCERT è diversa UNIMATICA:

Stringa

Progetto AIRUmbria



49/61





UNIMATICA

Posto dal

sistema

- 0000 = successo - 0001 = warning - 0002 = errore

INFOCERT: - S = successo - N = fallimento

Sono compresi tra questi gli esiti del Gateway nel caso di

- mancata risposta dal Conservatore nel caso sincrono

- problemi del Gateway o del messaggio nel caso asincrono

L’uscita standard è quindi: - S = Successo - E = Errore (fallimento) - W = Warning

codiceAnomalia anomalie>codice errore>codice Il codice del Conservatore. Questa info è presente solo nel caso di

Stringa

Progetto AIRUmbria



50/61





UNIMATICA

Posto dal

sistema

Errore/Warning. NON VALORIZZATO IN CASO DI SPEDIZIONE ASINCRONA

gravitaAnomalia anomalie>gravita - Codice utilizzato da UNIMATICA. Non sembra essere di nessuna utilità.

Stringa

descrizioneAnomalia anomalie>descrizione errore>descrizione La descrizione dell’anomalia fornita dal Conservatore. Questa info è presente solo nel caso di Errore/Warning

Stringa

descrizioneDettagliata infoVerificaDocumento errore>eccezione Una descrizione proprietaria, o lo stesso stack trace, del dettaglio dell’anomalia.

Stringa Data la verbosità di questa

parte, dovrà

esistere una

proprietà per

abilitare/disabilitare

Progetto AIRUmbria



51/61





UNIMATICA

Posto dal

sistema

la tracciatura

Progetto AIRUmbria



52/61


8 COLLEGAMENTI ED AUTORIZZAZIONE

La trasmissione verso il conservatore avviene sempre allo stesso URL indipendentemente dall’Ente che intende conservare. Questo sia per UNIMATICA che per INFOCERT. La destinazione di conservazione è dunque identificata univocamente dalla struttura dati

- Ente - Struttura - Applicazione - Installazione

che deve essere codificata all’interno del Gateway al fine di evitare invii non autorizzati. Anche se al momento non viene utilizzato viene lasciato nell’interfaccia il parametro abilitazioneID per eventuali usi futuri.

Progetto AIRUmbria



53/61


9 MODIFICHE RICHIESTE AL SISTEMA INTERPA

Il sistema INTERPA richiede due tipi di intervento: a. Modifiche all’interfaccia utente ed alle funzionalità gestionali per

supportare l’invio manuale al Gateway Unico di Conservazione. Questo primo tipo di intervento prevede ovviamente il modulo di integrazione tra INTERPA e l’interfaccia web service del Gateway descritta in dettaglio in [2].

b. Modifiche alle funzionalità gestionali per l’invio automatico al Gateway Unico di Conservazione.

I capitoli seguenti descrivono le specifiche degli interventi.

9.1 MODIFICHE ALL’INTERFACCIA UTENTE ED ALLE FUNZIONALITÀ

GESTIONALI PER SUPPORTARE L’INVIO MANUALE AL GATEWAY DI

CONSERVAZIONE

L’utente deve effettuare l’accesso al sistema InterPA e aprire il fascicolo contenente l’allegato che vuole inviare al conservatore esterno. Il documento è firmato digitalmente in uno dei formati convenuti nella scheda tecnica con il Conservatore. Attualmente vengono utilizzati formati p7m e pdf.

Progetto AIRUmbria



54/61


Figura 12 Fascicolo contenente un documento allegato Pdf firmato digitalmente

Per inviare il file al servizio di conservazione sostituiva l’utente deve fare clic sul pulsante relativo.

Progetto AIRUmbria



55/61


Figura 13 Tramite l’operazione “Conservazione sostitutiva” si avvia il processo di conservazione

In questo modo il documento passerà nello stato ―In attesa di archiviazione sostitutiva‖. Un processo automatico periodicamente scandirà l’elenco dei documenti dei fascicoli e provvederà a effettuare l’invio.

Progetto AIRUmbria



56/61


Figura 14 Il documento viene messo in attesa di processamento da parte del sistema

Durante la fase di processamento, accanto all’allegato segnato comparirà l’icona di una clessidra. Questo simbolo indica che l’allegato sta attendendo il suo turno per essere inviato al conservatore esterno.

Progetto AIRUmbria



57/61


Figura 15 Il fascicolo relativo indica che l’allegato è in attesa di processa mento

Una volta che il processo automatico avrà effettuato con successo l’operazione di invio accanto all’allegato comparirà un’icona che indica che è stato correttamente conservato.

Progetto AIRUmbria



58/61


Figura 16 Il fascicolo relativo indica che l’allegato è stato conservato

Il conservatore sostitutivo risponde alla richiesta tramite codice di ritorno 0 o 1 per indicare se il processo è andato a buon fine o meno. In caso di errore viene anche segnalata una descrizione dell’anomalia riscontrata. L’esito della richiesta viene mostrato a fondo pagina in un riquadro: in tale area verranno riportate le informazioni principali utili all’operatore per future operazioni presso il servizio di conservazione.

Progetto AIRUmbria



59/61


Figura 17 Il documento dell’allegato Pdf conterrà il file xml di risposta ricevuto dal conservatore

In caso si verifichi un errore nell’invocazione col sistema di conservazione sostitutiva il messaggio relativo verrà visualizzato nel pannello ―anomalie conservazione sostitutiva‖ in fondo alla pagina di gestione del fascicolo. Nel caso in esame in Errore. L'origine riferimento non è stata trovata. si mostra l’invio di un documento già conservato utilizzando la stessa chiave di conservazione.

Progetto AIRUmbria



60/61


Figura 18 Anomalia ricevuta dal conservatore

9.2 MODIFICHE ALLE FUNZIONALITÀ GESTIONALI PER L’INVIO

AUTOMATICO AL GATEWAY DI CONSERVAZIONE

Di seguito sono descritte le modifiche da apportare all’applicativo INTERPA per automatizzare il processo di invio al servizio di CONSERVAZIONE SOSTITUTIVA delle registrazioni del protocollo contenenti file con estensione .pdf e p7m.

Progetto AIRUmbria



61/61


Verrà creato un apposito agent che, schedulato, provvederà a controllare le registrazioni protocollate, partendo dal giorno di ultimo processamento scritto in configurazione e marcherà le registrazioni come da ―conservare‖. Le registrazioni da ―conservare‖ verranno inserite in fascicoli denominati "Documenti per conservazione sostitutiva". I fascicoli avranno la seguente struttura: Fascicolo = Anno di riferimento Sottofascicoli = Uno per ogni mese Inserti = Giorni corrispondenti per il relativo mese Il fascicolo creato verrà marcato con un flag, che servirà ad un secondo agent schedulato per processare i fascicoli che necessitano di invio al servizio di CONSERVAZIONE SOSTITUTIVA. Se il processo va a buon fine viene aggiornata la data in configurazione incrementandola di 1 giorno.

Documents

Realizzazione di un sistema per l’archiviazione, la ...conservazione.pa.umbria.it/documentazione-airumbria/Specifiche... · Realizzazione di un sistema Progetto AIRUmbria per l’archiviazione,