SPECIFICHE TECNICHE DEL SERVIZIO DI VERSAMENTO

Transcript

1 SPEIFICHE TECNICHE DEL REDAZIONE, VERIFICA, APPROVAZIONE Azione Data Nominativo Funzione Redazione 19/02/2019 Davide Madonnini Unità di Progettazione Verifica 27/02/2019 Annachiara Coviello Unità di Progettazione Approvazione 08/03/2019 Serenella Carota Responsabile del Servizio di Conservazione STATO DELLE REVISIONI N Ver/Rev Data emissione Modifiche apportate Osservazioni Vers /03/2019 Prima versione DOCUMENTI DI RIFERIMENTO Tipologia di documento Manuale di conservazione Manuale di Utilizzo La documentazione è pubblicata nel sito web del Polo di conservazione al seguente link Data 19/02/2019 Rev. 0 Pagina 1 di 53

2 INDICE 1. PREMESSA GLOSSARIO VERSAMENTO IN MODALITÀ REST DESCRIZIONE DEL WEB SERVICE DI VERSAMENTO STRUTTURA DELLA CHIAMATA LA STRUTTURA DELL INDICE DEL PACCHETTO DI VERSAMENTO Descrizione delle macro classi di metadati Metadati riferiti all Unità Documentaria Metadati riferiti al Profilo Archivistico Metadati riferiti al Profilo Unità Documentaria Metadati Specifici Metadati riferiti alle Unità Documentarie Collegate Metadati riferiti agli Allegati /Annessi / Annotazioni Metadato riferito all identificativo del documento Metadato riferito al Tipo Documento Metadati riferiti al Profilo Documento Metadati Specifici Struttura del Documento Metadati Riferiti agli Allegati / Annessi / Annotazioni VERSAMENTO DI UN PACCHETTO SIP VERSAMENTO DI UN PACCHETTO SIP DI MODIFICA Modifica di un SIP precedentemente versato Modifica dei soli metadati di un SIP precedentemente versato STRUTTURA DELLA RISPOSTA A SEGUITO DEL VERSAMENTO DI UN SIP RECUPERO DEL RAPPORTO DI VERSAMENTO (RDV) CONTROLLI FORMALI VERSAMENTO IN MODALITÀ FLUSSO DESCRIZIONE DEL CARICAMENTO TRAMITE FLUSSO STRUTTURA DELLA CHIAMATA LA STRUTTURA DELL INDICE DEL PACCHETTO DI VERSAMENTO VERSAMENTO DI UN PACCHETTO SIP Data 19/02/2019 Rev. 0 Pagina 2 di 53

3 4.5. VERSAMENTO DI UN PACCHETTO SIP DI MODIFICA RISPOSTA AL VERSAMENTO E RECUPERO DEL RAPPORTO DI VERSAMENTO (RDV) VERSAMENTO DI PACCHETTI SIP DUPLICATI CONTROLLI DI QUALITY ASSURANCE ALLEGATI ALLEGATO 1 TABELLA RIASSUNTIVA STATI SIP ALLEGATO 2 FILE XSD CHE DEFINISCE LA STRUTTURA DEL RAPPORTO DI VERSAMENTO Data 19/02/2019 Rev. 0 Pagina 3 di 53

4 1. PREMESSA Il sistema di conservazione DigiP è stato progettato per accogliere pacchetti di versamento (SIP Submission Information Package) disegnati principalmente secondo lo standard SINCRO. Tuttavia il sistema è altamente configurabile e personalizzabile ed è quindi in grado di accogliere qualsiasi tipo di Pacchetto di Versamento, garantendo in tal modo un elevato livello di flessibilità. Questa caratteristica ha permesso fin da subito la compatibilità (sebbene con alcune limitazioni, ad esempio il vincolo di 1 SIP => 1 unità documentaria) con il sistema di conservazione preesistente. Il SIP è definito da: un contenitore, dipendente dal canale trasmissivo scelto, che racchiude i contenuti del pacchetto informativo (es: file in formato zip, HTTP Request di tipo POST... ); un file XML (indice di versamento), descrittore del contenuto, dei metadati dell ente produttore e delle eventuali aggregazioni; detto indice può essere validato contro il proprio schema XSD; l'insieme dei file elencati nell'indice, con i propri metadati. Il caricamento di un pacchetto di versamento (SIP) può avvenire in diverse modalità, dipendentemente dagli accordi di servizio: REST: l applicazione versante, autenticata e autorizzata, trasmette al sistema i pacchetti di versamento utilizzando l apposita interfaccia web service REST (compatibile alle Specifiche tecniche del servizio di versamento in conservazione sostitutiva v. 1.3 del sistema di conservazione del Polo Archivistico Regionale dell Emilia Romagna) FLUSSO: i pacchetti SIP, definiti come file.zip, vengono posizionati in una specifica cartella ftp assegnata all utente (ente produttore). Il sistema tramite periodici controlli troverà il file e avvierà il processo di versamento. Data 19/02/2019 Rev. 0 Pagina 4 di 53

5 2. GLOSSARIO Unità Documentaria (UD): aggregato logico costituito da un Documento principale e da eventuali Allegati/Annessi/Annotazioni. Se l Unità Documentaria è costituita dal solo Documento principale questo può essere composto sia da file che da soli metadati. L Unità Documentaria è accompagnata da un file XML o indice di versamento, il quale riporta tutti i metadati che attestano i vari contesti di produzione originaria o riuso attraversati dal documento digitale nel corso della sua esistenza. I pacchetti informativi così formati, trasmessi da un ente produttore al sistema di conservazione DigiP sono denominati pacchetti informativi di versamento (SIP). Documento principale: documento che deve essere obbligatoriamente presente nell Unità Documentaria. Allegato: documento facoltativamente unito all Unità Documentaria per integrarne le informazioni. Annesso: documento facoltativamente unito all Unità Documentaria per integrarne le informazioni. Generalmente utilizzato per apportare aggiornamenti/modifiche ad un SIP precedentemente versato in DigiP. Annotazione: documento facoltativamente unito all Unità Documentaria per integrarne le informazioni (un tipico esempio di annotazione è rappresentato dalla segnatura di protocollo). Applicativo versante: sistema software utilizzato dall ente produttore per versare i SIP nel sistema di conservazione DigiP Indice del pacchetto di versamento: documento in formato XML prodotto dall ente produttore che contiene i metadati dell Unità Documentaria nonché i parametri di versamento (cfr. 3.3) Indice del pacchetto di archiviazione: documento contenente un insieme di informazioni articolate in uno Schema XML conforme allo standard SInCRO associato ad ogni pacchetto di archiviazione (AIP). SIP: pacchetto di versamento inviato a DigiP dall ente produttore. AIP: pacchetto di archiviazione UUID: universally unique identifier è un identificativo standard ed è documentato come parte dell'iso/iec 11578:1996 "Information technology Open Systems Interconnection Remote Procedure Call (RPC)" e più recentemente in ITU-T Rec. X.667 ISO/IEC :2005. UNI 11386:2010 Standard SInCRO: lo standard definisce la struttura dell insieme di dati a supporto del processo di conservazione individuando gli elementi informativi necessari alla creazione dell indice del pacchetto di archiviazione e descrivendone sia la semantica sia l articolazione per mezzo del linguaggio formale XML. L obiettivo dello standard è quello di Data 19/02/2019 Rev. 0 Pagina 5 di 53

6 raggiungere un soddisfacente grado d interoperabilità nei processi di migrazione, grazie all adozione dello Schema XML appositamente elaborato. Ricevuta di Carico (RDC o Esito Versamento): attesta l esito dei controlli formali. Successivamente, se l esito di tali controlli è positivo, i pacchetti informativi di versamento (SIP) sono messi in coda per la validazione di qualità dove verranno applicate delle Regole definite con l ente produttore nel Disciplinare tecnico e verrà emessa un Rapporto di Versamento (RDV). Rapporto di Versamento (RDV): documento informatico opzionalmente firmato e protocollato che attesta l'avvenuta presa in carico da parte del sistema di conservazione dei pacchetti di versamento inviati dall ente produttore. Disciplinare tecnico: documento redatto da ogni ente produttore che definisce le specifiche operative e le modalità di descrizione e di versamento nel sistema di conservazione Marche DigiP. FITS (File Information Tool Set): strumento open source per l'identificazione e la convalida dei formati di file ( Archival Storage: funzione che gestisce l immagazzinamento a lungo termine delle risorse digitali affidate al sistema di Si tratta di un area funzionale non direttamente acceduta dagli utenti. KIP (Kernel Information Package): il sistema di conservazione DigiP individua, nella fase di Ingest, il momento in cui il SIP conferito dall ente produttore viene validato e quindi trasformato in AIP. Durante questo processo, i risultati delle validazioni e delle conversioni di formato, richieste dagli accordi di servizio e dalle politiche prestabilite, vengono raccolti e aggregati in una struttura di IP (Information Package) idonea alla successiva generazione dei corrispondenti pacchetti di archiviazione (AIP). Questa struttura transitoria identificata come KIP Kernel Information Package - è indipendente dai formati scelti per l'archiviazione. La struttura di questi ultimi segue lo standard SInCRO così come indicato nelle Regole tecniche in materia di conservazione (DPCM 03 dicembre 2013). Data 19/02/2019 Rev. 0 Pagina 6 di 53

7 3. VERSAMENTO IN MODALITÀ REST 3.1. DESCRIZIONE DEL WEB SERVICE DI VERSAMENTO Il web service di versamento è stato implementato sul modello REST (Representational State Transfer, allo scopo di superare le intrinseche limitazioni del protocollo SOAP, nato per trasportare messaggi tra differenti applicazioni ma poco adatto per la trasmissione di allegati di dimensioni consistenti. Questo modello di trasmissione è considerato molto efficiente, perché privo delle sovrastrutture imposte da SOAP, tra le quali si cita il vincolo di dover tradurre tutto il contenuto informativo in testo XML con la conseguente necessità di trasmettere gli allegati binari codificati tramite Base64. Inoltre, l utilizzo di un web service REST comporta diversi vantaggi: l utilizzo del protocollo standard HTTP, che risulta perfettamente gestibile anche in ambienti in cui siano presenti firewall o proxy il web service risulta completamente sincrono e la modalità di invocazione richiede l uso di un unico protocollo, cosa che rende lo sviluppo o l adeguamento di un client, relativamente semplice la possibilità offerta dal protocollo http di poter trasmettere gli allegati binari senza conversione in Base64, cosa che consente un tangibile incremento delle prestazioni ed un impiego più efficiente della rete STRUTTURA DELLA CHIAMATA Il pacchetto informativo di versamento (SIP), trasmesso dalla chiamata di versamento del web service, è costituito da una request https che usa il metodo POST ed è codificata come multipart/form-data. L utilizzo della modalità multipart consente di inviare tutte le componenti della request in un unica transazione. L utilizzo dell encoding form-data è stato scelto perché permette di gestire le parti che compongono la request come se fossero i campi (field) di una form di una pagina web; in particolare: le informazioni di tipo testuale (come i metadati in XML) vengono incapsulati in form fields gli allegati binari vengono semplicemente accodati nel pacchetto informativo, senza doverli convertire in formati testuali quali Base64 Data 19/02/2019 Rev. 0 Pagina 7 di 53

8 I campi che compongono la request sono: Nome campo Tipo Descrizione VERSIONE Form field Contiene la stringa relativa alla versione del web service. I controlli iniziali sul pacchetto variano a seconda della versione specificata nell'indice di versamento. Di seguito i dettagli: v 1.3: v 1.4: v.1.5: controllo versione controllo utente versatore controllo formato indice xml controllo della lunghezza massima del nome del file definito nell'indice xml controllo numero dei file allegati con numero dei file dichiarati nell'indice xml controllo versione controllo utente versatore controllo formato indice xml controllo della lunghezza massima del nome del file definito nell'indice xml controllo numero dei file allegati con numero dei file dichiarati nell'indice xml inserimento del valore dell'identificativo del pacchetto (UUID o idsip) nella Ricevuta di Carico (RDC) controllo versione controllo utente versatore controllo formato indice xml controllo della lunghezza massima del nome del file definito dai file allegati controllo numero e nome dei file allegati con numero e nome dei file dichiarati nell'indice xml inserimento del valore dell'identificativo del pacchetto (UUID o idsip) nella Ricevuta di Carico (RDC) LOGINNAME Form field Contiene il nome dell applicativo versante, come registrato nel sistema. Ogni applicativo dovrà essere preventivamente registrato presso DigiP allo scopo di ricevere un identificativo univoco PASSWORD Form field Contiene la password di autenticazione dell applicativo versante Data 19/02/2019 Rev. 0 Pagina 8 di 53

9 XMLSIP Form field Contiene l indice del pacchetto di versamento, in formato XML, contenente i metadati. Per ognuno dei file/componenti descritti, deve essere specificato un apposito campo ID univoco all interno del versamento, allo scopo di poter associare correttamente i metadati al file (cfr ). (Id univoco) File field Contiene i dati binari del file. Questo tipo di pacchetto dati viene replicato tante volte quanti sono i file da spedire LA STRUTTURA DELL INDICE DEL PACCHETTO DI VERSAMENTO In fase di versamento ogni Unità Documentaria inviata al sistema di conservazione viene descritta da una serie di metadati, raggruppati in macro classi. La struttura del file XML che descrive l oggetto di versamento risulta composta dalle macro classi riferite all Unità Documentaria, dalle macroclassi che descrivono il Documento principale ed infine, se sono presenti Allegati, dalle macro classi che descrivono ogni allegato. La macro struttura del file XML è pertanto la seguente: Tipologia di Metadato Descrizione Schema XML Metadati riferiti all Unità Documentaria Intestazione Metadati riferiti al Profilo Archivistico Metadati riferiti al Profilo Unità Documentaria Metadati Specifici Metadati riferiti a UD Collegate Metadati che permettono di identificare univocamente il Soggetto Versante, la Chiave e la tipologia dell UD versata. Metadati che consentono di descrivere a livello archivistico l UD versata. Metadati generali, comuni a tutte le tipologie documentali, che consentono di descrivere l UD oggetto di versamento. Metadati specifici per quella data tipologia di Unità Documentaria. Metadati che permettono di descrivere gli eventuali collegamenti esistenti tra l UD oggetto di versamento e altri documenti (che possono essere già versati o ancora da versare). <Intestazione> </Intestazione> <ProfiloArchivistico> </ProfiloArchivistico> <ProfiloUnitaDocumentaria> </ProfiloUnitaDocumentaria> <DatiSpecifici> </DatiSpecifici> <DocumentiCollegati> </DocumentiCollegati> Data 19/02/2019 Rev. 0 Pagina 9 di 53

10 Metadati riferiti agli allegati Metadati riferiti agli annessi Metadati riferiti alle annotazioni Numero di documenti allegati riferiti all UD. Numero di documenti annessi riferiti all UD. Numero di documenti annotazioni riferiti all UD. <Numero_Allegati> </ Numero_Allegati > <Numero_Annessi> </ Numero_Annessi > <Numero_Annotazioni> </ Numero_Annotazioni > Metadati riferiti al Documento (Documento principale e Allegato/Annesso/Annotazione) Identificativo Tipo Documento Profilo Documento Metadati Specifici Metadati Specifici Migrazione Struttura Identificativo del documento (principale / allegato / annesso / annotazione). Tipologia del documento. La tipologia di appartenenza determina i dati specifici. Metadati generali, comuni a tutte le tipologie documentali, che permettono di descrivere il documento (documento principale o allegato, sia generico che tipizzato). Altri metadati specifici per quella data tipologia documentaria. Metadati specifici di migrazione del documento. Strutturazione del documento versato. <IDDocumento> </IDDocumento> <TipoDocumento> </TipoDocumento> <ProfiloDocumento> </ProfiloDocumento> <DatiSpecifici> </DatiSpecifici> <DatiSpecificiMigrazione> </DatiSpecificiMigrazione> <StrutturaOriginale> </StrutturaOriginale> Descrizione delle macro classi di metadati Nei paragrafi seguenti sono indicati, per ogni metadato gestito dall indice di versamento: Nome Metadato Descrizione Data 19/02/2019 Rev. 0 Pagina 10 di 53

11 Obbligatorietà Dimensione Massima (indica il numero massimo di caratteri che possono essere inseriti nel relativo tag. Non è stata indicata nel caso di valori booleani e di tag che accettano solo valori predefiniti) I campi opzionali (per esempio il fascicolo), se vuoti, non devono essere inseriti nel file XML come tag vuoti. Quindi non sarà accettato, per esempio: <ProfiloArchivistico> <FascicoloPrincipale> <Classifica>1.0.0</Classifica> </FascicoloPrincipale> <FascicoliSecondari> <FascicoloSecondario/> Errore: i tag non valorizzati non devono essere inseriti nell XML </ProfiloArchivistico> Metadati riferiti all Unità Documentaria Metadato Descrizione Obbligatorio Dimensione Massima Versione Ambiente Ente Struttura Indica la versione di XSD utilizzata per la verifica dell XML. Deve coincidere con la versione utilizzata nella request del servizio (cfr. 3.2). Identificativo dell'ambiente, assegnato dal fornitore del servizio. Identificativo specifico per l'ente produttore assegnato dal fornitore del servizio. Struttura di produzione/competente del documento assegnato dal fornitore del servizio. X 100 X 100 X 100 X 100 Data 19/02/2019 Rev. 0 Pagina 11 di 53

12 UserID Identificativo dell'applicativo versante assegnato dal fornitore del servizio. Deve coincidere con lo UserID utilizzato nella request del servizio (cfr. 3.2). X 100 Numero Identificatore progressivo. X 100 Chiave Anno TipoRegistro Identificatore che definisce il contesto temporale. Identificatore che definisce il contesto organizzativo del soggetto versante (ad esempio il nome del registro o altro identificativo che renda univoche le precedenti chiavi). X 4 X 100 TipologiaUnitaDocume ntaria Rappresenta la tipologia dell Unità Documentaria. La tipologia di UD può determinare l eventuale serie di appartenenza. X Metadati riferiti al Profilo Archivistico Metadato Obbligatorio Dimension e Massima FascicoloPrincipale In questo macro tag sono incluse le informazioni relative alla Classifica Principale, al Fascicolo Principale di appartenenza e all eventuale sotto fascicolo. E possibile valorizzare solo la classifica e non i campi descrittivi del fascicolo (nel caso il documento sia stato solo classificato e non fascicolato). Data 19/02/2019 Rev. 0 Pagina 12 di 53

13 Classifica: codice con cui l UD è identificato all interno del sistema di classificazione corrente. I livelli (corrispondenti a categoria classe- sottoclasse) sono tra loro separati da punto (esempio: 1.2; 1; 1.2.3). 254 Fascicolo in cui è stata inserita l Unità Documentaria. Si compone di: Identificativo (stringa composta da Codice Classifica / Anno di Riferimento / Numero Progressivo). NB: se è stato valorizzato il campo Classifica, è necessario che sia uguale al codice classifica riportato nell identificativo fascicolo. 100 Oggetto 1024 Sottofascicolo in cui è stata inserita l unità documentaria. Si compone di: Identificativo (stringa composta da Codice Classifica / Anno di Riferimento / Numero Progressivo). NB: se è stato valorizzato il campo Classifica, è necessario che sia uguale al codice classifica riportato nell identificativo fascicolo. 100 Oggetto 1024 FascicoliSecondari (Contiene n tag FascicoloSecondario) Permette di gestire il caso in cui un documento sia stato inserito in n fascicoli. Il tag <FascicoliSecondari> a sua volta contiene tanti tag quanti sono i fascicoli secondari. Ogni fascicolo secondario è composto dai seguenti tag: Classifica: classifica secondaria assegnata all UD. I livelli (corrispondenti a categoria classe- sottoclasse) sono tra loro separati da punto (esempio: 1.2; 1; 1.2.3). 254 Data 19/02/2019 Rev. 0 Pagina 13 di 53

14 Fascicolo in cui è stata inserita l Unità Documentaria: Identificativo (stringa composta da Codice Classifica / Anno di Riferimento / Numero Progressivo). NB: se è stato valorizzato il campo Classifica, è necessario che sia uguale al codice classifica riportato nell identificativo fascicolo. 100 Oggetto 1024 Sottofascicolo in cui è stata inserita l Unità Documentaria: Identificativo (stringa composta da Codice Classifica / Anno di Riferimento / Numero Progressivo). NB: se è stato valorizzato il campo Classifica, è necessario che sia uguale al codice classifica riportato nell identificativo fascicolo. 100 Oggetto Metadati riferiti al Profilo Unità Documentaria Metadato Descrizione Obbligatorio Dimensione Massima Oggetto Oggetto dell Unità Documentaria da versare Data Cartaceo Campo data indicante la data dell UD. Assume valori True o False. Serve per indicare se l originale dell UD versata è in formato cartaceo o meno. Data 19/02/2019 Rev. 0 Pagina 14 di 53

15 Metadati Specifici In base alla tipologia associata all Unità documentaria (identificata dal metadato TipologiaUnitaDocumentaria ), è possibile inserire nello schema dei metadati specifici per tale tipologia. Sono metadati NON Obbligatori. La dimensione massima consentita per la valorizzazione di ogni singolo metadato specifico è di 4000 byte: ovviamente nell XSD riferito alla singola Unità Documentaria possono essere impostati limiti più restrittivi (per esempio inserire un numero massimo di 11 caratteri per il metadato specifico che descrive la Partita Iva, etc). Se la tipologia associata all Unità Documentaria prevede metadati specifici, è obbligatorio indicare il tag <DatiSpecifici> e opzionalmente la versione (<VersioneDatiSpecifici>). Se la tipologia di unità documentaria non prevede dati specifici, il tag <DatiSpecifici> non deve comparire nella request XML. Attualmente in DigiP i metadati specifici possono essere definiti come una lista flat di attributo/valore, ed il valore non può contenere altri element. Per gestire Metadati specifici strutturati o multipli, come per esempio contraenti nella gestione dei contratti (e più in generale i firmatari di un qualsiasi atto), con indicazione, per ogni contraente, del nominativo/ragione sociale, il CF/PIVA, ed il domicilio. destinatari di una lettera in uscita registrata nel sistema di protocollo con indicazione, per ogni destinatario, del nominativo/ragione sociale, il CF/PIVA, l'indirizzo di spedizione. si propongono le seguenti linee guida: 1) La prima, preferibile, è quella di inserire tale metadato come element indentato codificando i caratteri "<", ">" e "&" ( in modo che venga interpretato come semplice stringa. Ad esempio il metadato specifico strutturato e multiplo <contraenti> verrà valorizzato nel modo seguente: <contraenti> <contraente> <nome>paolo Rossi</nome> <cf>cppmrzxxxxx</cf> </contraente><contraente> <nome>michele Bianchi</nome> <cf>csgcrsxxxxx</cf> </contraente> </contraenti> 2) La seconda soluzione consiste nell usare dei campi stringa in cui concatenare i diversi valori, con marcatori di separazione. I separatori usati comunemente sono: Data 19/02/2019 Rev. 0 Pagina 15 di 53

16 la virgola "," (mutuando lo standard csv) come separatore di campo e il punto e virgola ; come separatore di record il circonflesso "^" (utilizzato in particolare nello standard DICOM) come separatore di campo ed il doppio circonflesso "^^" come separatori di record. Con questa soluzione si riesce a rappresentare solo dati in forma tabellare, di cui si perde la semantica Metadati riferiti alle Unità Documentarie Collegate Metadato Descrizione Obbligatorio Dimensione Massima ChiaveCollegamento Numero Identificatore progressivo locale. 100 Anno Identificatore che definisce il contesto temporale. 4 DescrizioneCollegamento TipoRegistro Identificatore che definisce il contesto organizzativo del soggetto versante (ad esempio il nome del registro o altro identificativo che renda univoche le precedenti chiavi). Descrizione del collegamento Metadati riferiti agli Allegati /Annessi / Annotazioni Metadato Descrizione Obbligatorio Dimensione Massima NumeroAllegati Rappresenta il numero di allegati. Assume valore 0 se non sono presenti allegati; nel caso siano presenti allegati il valore è pari al numero di oggetti presenti. 4 cifre Data 19/02/2019 Rev. 0 Pagina 16 di 53

17 NumeroAnnessi NumeroAnnotazioni Rappresenta il numero di annessi. Assume valore 0 se non sono presenti annessi; nel caso siano presenti annessi il valore è pari al numero di oggetti presenti. Rappresenta il numero di annotazioni. Assume valore 0 se non sono presenti annotazioni; nel caso siano presenti annotazioni il valore è pari al numero di oggetti presenti. 4 cifre 4 cifre Metadato riferito all identificativo del documento Metadato Descrizione Obbligatorio Dimensione Massima IDDocumento Rappresenta l identificativo del documento assegnato dall ente versante. Deve essere univoco all interno della stessa Unità Documentaria. X Metadato riferito al Tipo Documento Metadato Descrizione Obbligatorio Dimensione Massima TipoDocumento Rappresenta la tipologia del documento. X Metadati riferiti al Profilo Documento Metadato Descrizione Obbligatorio Dimensione Massima Descrizione Descrizione riferita al documento da versare Autore Utente che ha eseguito la creazione del documento. 254 Data 19/02/2019 Rev. 0 Pagina 17 di 53

18 Metadati Specifici In base alla tipologia associata al documento (identificata dal metadato TipoDocumento ), è possibile inserire nello schema dei metadati specifici per tale tipologia. Sono metadati NON Obbligatori. Se la tipologia associata al documento prevede metadati specifici, è obbligatorio il tag <DatiSpecifici> e opzionalmente indicarne la versione (<VersioneDatiSpecifici>). Se la tipologia di documento non prevede dati specifici, il tag <DatiSpecifici> non deve comparire nella request XML. Per la gestione di metadati specifici strutturati e multipli si rimanda a quanto descritto nei metadati specifici dell Unita Documentaria ( 3.3.5) Struttura del Documento Metadati Descrizione Obbligatorio Dimensione Massima TipoStruttura Descrive il tipo di struttura. Se non è valorizzato assume il valore di default (DocumentoGenerico). Componenti ID Consente di ricongiungere il componente versato al livello di appartenenza. E un metadato utilizzato per fini di congiungimento delle unità inviate. Deve essere univoco all interno della stessa Unità Documentaria. X 254 Componente OrdinePre sentazion e Numero che indica l ordine di successione della singola componente all interno della struttura originale. X 5 cifre TipoComp onente Tipologia di appartenenza del componente. Se non è valorizzato assume il valore di default (Contenuto). Data 19/02/2019 Rev. 0 Pagina 18 di 53

19 TipoSupp ortocomp onente Tipo di supporto del componente. Le attuali tipologie di supporto gestite dal sistema sono: - FILE - METADATI (nel caso il componente non abbia un file. Questa tipologia di supporto componente potrà essere utilizzata per eseguire modifiche ai Metadati o per segnalare un Annullamento di una UD precedentemente versata). TipoRappr esentazio necompo nente Tipo di rappresentazione del componente. Assume significato nel caso in cui l ente versi un file che intende rappresentare con uno specifico convertitore (il caso classico è rappresentato da file XML rappresentati con XSL_FO), che possono essere versati come file o come dati. NomeCom ponente Stringa che rappresenta il nome del file seguito dall estensione del formato (ad esempio: rapporto_trimestrale.pdf). X (se Tipo SupportoCom ponente = File) 254 FormatoFil eversato Rappresenta il formato del file. X (se Tipo SupportoCom ponente = File) HashVers ato Rappresenta l hash del file. 254 UrnVersat o Stringa univoca che rappresenta l'indirizzo logico dove memorizzare il file Data 19/02/2019 Rev. 0 Pagina 19 di 53

20 IDCompon enteversa to DatiSpecifi ci UtilizzoDat afirmaper RifTemp Identifica univocamente il componente entro l applicativo versante. 254 In base alla tipologia associata al componente (identificata dal metadato TipoComponente ), è possibile inserire dei metadati specifici per tale tipologia, indicando la versione di riferimento.se la tipologia associata al componente prevede metadati specifici, è obbligatorio il tag <DatiSpecifici> e indicarne opzionalmente la versione (<VersioneDatiSpecifici>). Se la tipologia di componente non prevede dati specifici, il tag <DatiSpecifici> non deve comparire nella request XML. Assume valore False. DigiP utilizza la data ed ora di versamento per le verifiche sulla firma. Riferiment otemporal e Utilizzato per consentire la verifica del file ad una precisa data. Il formato della data (anno-mese-giornoora:minuto:secondo.millisecondo+delta rispetto a UTC) è conforme allo standard ISO 8601 (per esempio: T16:49: :00). Descrizion eriferime ntotempo rale Consente di inserire una descrizione del riferimento temporale. 254 Ogni Componente può contenere n Sotto Componenti riferiti al componente stesso: per esempio il riferimento temporale riferito al file. I sottocomponenti sono descritti con una porzione dei metadati previsti per la descrizione del componente. In particolare, i sottocomponenti sono descritti con i seguenti metadati: Data 19/02/2019 Rev. 0 Pagina 20 di 53

21 ID Consente di ricongiungere il componente versato al livello di appartenenza. E un metadato utilizzato per fini di congiungimento delle unità inviate. Deve essere univoco all interno della stessa Unità Documentaria. X 254 OrdinePre sentazion e Numero che indica l ordine di successione della singola componente all interno della struttura originale. X 5 cifre TipoComp onente Tipologia di appartenenza del componente. Se non è valorizzato assume il valore di default (Contenuto). X TipoSupp ortocomp onente Tipo di supporto del componente. Le attuali tipologie di supporto gestite dal sistema sono: Sotto Componente - FILE - METADATI (nel caso il componente non abbia un file. Questa tipologia di supporto componente potrà essere utilizzata per eseguire modifiche ai Metadati o per segnalare un Annullamento di una UD precedentemente versata). NomeCo mponente Stringa che rappresenta il nome del file seguito dall estensione del formato (ad esempio: rapporto_trimestrale.pdf). X (se Tipo SupportoCo mponente = File) 254 FormatoFi leversato Rappresenta il formato del file. X (se Tipo SupportoCo mponente = File) UrnVersat o Stringa univoca che rappresenta l'indirizzo logico dove memorizzare il file Data 19/02/2019 Rev. 0 Pagina 21 di 53

22 IDCompo nentevers ato DatiSpecif ici Identifica univocamente il componente entro l applicativo versante. 254 In base alla tipologia associata al sottocomponente (identificata dal metadato TipoComponente ), è possibile inserire nello schema dei metadati specifici per tale tipologia, indicando la versione di riferimento. Sono metadati NON Obbligatori. Se la tipologia associata al sottocomponente prevede metadati specifici, è obbligatorio il tag <DatiSpecifici> e indicarne opzionalmente la versione (<VersioneDatiSpecifici>). Se la tipologia di sottocomponente non prevede dati specifici, il tag <DatiSpecifici> non deve comparire nella request XML Metadati Riferiti agli Allegati / Annessi / Annotazioni In questa sezione sono comprese le macro classi che permettono di descrivere gli eventuali documenti Allegati, Annessi ed Annotazioni. L Allegato è un documento facoltativamente unito al Documento principale per integrarne le informazioni redatto di norma contestualmente o precedentemente al Documento principale. L Annesso è un documento facoltativamente unito al Documento principale per integrarne le informazioni. E redatto di norma in un momento successivo a quello di redazione del Documento principale. L Annotazione è un file detached riferito all intera Unità Documentaria (un tipico esempio di annotazione è rappresentato dalla segnatura di protocollo). Ogni Allegato/Annesso/Annotazione versato deve essere associato a una specifica tipologia di documento, per ciascuna delle quali potranno essere definiti dati specifici, allo stesso modo del Documento principale. Data 19/02/2019 Rev. 0 Pagina 22 di 53

23 La struttura di un Allegato/Annesso/Annotazione è la seguente: <Allegato> <IDDocumento>token</IDDocumento> <TipoDocumento>token</TipoDocumento> <ProfiloDocumento> <Descrizione>string</Descrizione> <Autore>string</Autore> </ProfiloDocumento> <DatiSpecifici/> <StrutturaOriginale> <TipoStruttura>token</TipoStruttura> <Componenti> <Componente> <SottoComponenti> <SottoComponente> </SottoComponente> </SottoComponenti> </Componente> </Componenti> </StrutturaOriginale> </Allegato> 3.4. VERSAMENTO DI UN PACCHETTO SIP Il versamento di un SIP in modalità REST avviene in un unica chiamata con contestuale risposta tramite il servizio di versamento sincrono: AMBIENTE DI TEST: AMBIENTE DI PRODUZIONE: L elaborazione dei pacchetti presi in carico dal sistema di conservazione avviene in modalità asincrona. Nella tabella vengono descritte entrambe le fasi. Per quanto riguarda il processo di versamento asincrono sono indicati (in grassetto) gli stati dei SIP durante il processo di elaborazione degli stessi (cfr. ALLEGATO 1). Data 19/02/2019 Rev. 0 Pagina 23 di 53

24 Pre-condizioni: 1) L applicativo chiamante deve essere autorizzato al trasferimento su DigiP. Post-condizioni: 1) SIP correttamente inviato e generazione del corrispondente AIP. 2) L indice del pacchetto di versamento, che descrive i metadati dei documenti digitali da inviare in conservazione, deve essere strutturato secondo la struttura richiesta dall XSD previsto per la tipologia documentale cui si riferisce. Processo versamento - Fase sincrona 1) Il sistema rileva un nuovo versamento e trasferisce il SIP in una cartella di lavoro temporanea. Il sistema di conservazione recupera il file XSD definito per la tipologia documentaria specifica. 2) Il sistema fa i primi controlli sugli oggetti ricevuti se sono conformi agli accordi presi con l'ente produttore (cfr. 3.8): Controllo della versione del file xml di indice. Controllo utente versatore se abilitato al versamento. Controllo esistenza tipologia documentale definita nell'indice. Controllo struttura indice xml (non vuoto, validazione xsd). Controllo univocità del pacchetto SIP versato in base al nome del pacchetto (WS+Numero+Anno+TipoRegistro) e renaming sul nome del pacchetto con l'aggiunta finale di una stringa costruita random per la gestione di eventuali duplicati (cfr. cap. 5). Ad esempio: WS+Numero+Anno+TipoRegistro_random WS RGPGRM_INh. Controllo file allegati: non vuoti, lunghezza nome del file, numero e nome file allegati congruente a quanto dichiarato nell'indice. Questi controlli vengono effettuati se il supporto componente è di tipo FILE, se è di tipo METADATI il controllo non viene effettuato. Definizione dei file di Processo: file json creati dal sistema per ogni allegato. Vengono memorizzati metadati specifici utili per il processo. Controllo hash dei file allegati con quanto dichiarato nell'indice di versamento sulla base degli accordi con l'ente produttore (Disciplinare tecnico). 3) Salvataggio del pacchetto SIP: definizione di un UUID univoco e salvataggio sul repository dei file e sul database dei primi metadati. 4) Se i controlli sono corretti DigiP prende in carico il versamento generando un esito di versamento (Ricevuta di Carico - RDC) positivo, altrimenti l esito di versamento ne evidenza il rifiuto (RDC negativa). Il sistema notifica l esito di versamento all ente produttore (cfr. 3.6). Data 19/02/2019 Rev. 0 Pagina 24 di 53

25 Processo versamento - Fase asincrona 5) Il SIP passa al processo per il controllo della qualità (Controlli di Quality Assurance - cfr. cap. 6): il sistema recupera ed esegue le Regole da applicare per la validazione in base all ente produttore e al tipo di documento che sta versando e sulla base di quanto specificato nel Disciplinare tecnico: Load: recupero e verifica della tipologia documentale, salvataggio di metadati relativi al pacchetto SIP. Detect: analisi dei file allegati tramite il tool FITS. Rule: applicazione di regole per il controllo dei pacchetti di versamento. 6) Il sistema elabora un Rapporto di Versamento (RDV) firmato e ne salva una copia sul repository: Esiti: recupero esiti, risultati delle regole e definizione del Rapporto di Versamento (RDV). Firma: firma del RDV (se abilitato). Marca Temporale: servizio di protocollazione (se abilitato). 7) Se il Rapporto di Versamento (RDV) è positivo, DigiP garantisce la creazione del pacchetto di archiviazione (AIP) e la sua memorizzazione nel sistema di conservazione; se negativo DigiP attesta il rifiuto del versamento con conseguente interruzione del processo di L ente produttore potrà verificare lo stato del pacchetto versato recuperando il RDV (cfr. 3.7). 8) Se le regole sono state tutte validate correttamente (il RDV è positivo), il sistema recupera ed esegue le trasformazioni opportune per rendere i file conformi agli accordi per l'archiviazione (attualmente lo standard UNI SInCRO 11386:2010): Trasformation: processi di trasformazione tipo conversione file, trasformazione xslt dall'indice in un formato standard (denominato KIP) ecc. 9) Il sistema genera un AIP e memorizza gli oggetti in una sezione specifica dell'archival Storage: Flussi di Errore: Generate AIP: - merge dei risultati (relativi alle trasformazioni applicate); - trasformazione indice KIP in indice del pacchetto AIP (ad oggi in formato SInCRO); - validazione xsd dell'indice relativo al pacchetto AIP; - creazione del uuid relativo al pacchetto AIP e salvataggio dei relativi metadati sul database. Firma: firma dell'indice AIP (se abilitato). Generate Complete: pulizia area di lavoro e SIP in ARCHIVED-COMPLETE. Data 19/02/2019 Rev. 0 Pagina 25 di 53

26 1) Se l applicativo chiamante compie un errore nella chiamata al servizio viene generato errore. 2) Se l applicativo chiamante non è autorizzato al versamento il sistema di conservazione genera errore. 3) Se l applicativo chiamante non invia il file XML il sistema di conservazione genera errore. 4) Se la tipologia documentaria indicata nel file XML non corrisponde ad una delle tipologie documentarie configurate all interno dell ente versante, il sistema genera errore. 5) Se la validazione del file XML con il relativo XSD non va a buon fine il sistema di conservazione genera errore. 6) Se dal controllo sulla Chiave (cfr ) risulta che l Unità Documentaria è già stata versata in DigiP, il sistema di conservazione genera errore, a meno che l ente produttore abbia scelto di gestire i pacchetti SIP duplicati. 7) Nel caso in cui i controlli di qualità (Quality Assurance) sui file inviati non vadano a buon fine (almeno un esito negativo nelle verifiche dei file che compongono l Unità Documentaria oggetto di versamento) il sistema di conservazione genera un RDV negativo con conseguente interruzione del processo di L ente produttore potrà procedere con il riversamento del pacchetto una volta corretto l errore VERSAMENTO DI UN PACCHETTO SIP DI MODIFICA Una volta generati i pacchetti di archiviazione (AIP) questi possono essere oggetto di aggiornamenti/modifiche nel corso del tempo. Sulla base degli accordi presi tra l'ente produttore e Marche DigiP e soprattutto rispettando le normative sulla conservazione è possibile, da parte dell ente produttore, inviare un SIP di modifica la cui generazione del corrispondente AIP andrà ad aggiornare/modificare un AIP precedentemente archiviato Modifica di un SIP precedentemente versato In questo scenario l ente produttore esegue l aggiornamento/modifica di un pacchetto di archiviazione (AIP) conservato in DigiP mediante la produzione di un nuovo SIP il cui corrispondente AIP si andrà a collegare a quello già presente nel sistema di Il SIP di modifica verrà versato come Annesso, il cui indice di versamento è così strutturato: <?xml version="1.0" encoding="utf-8"?> <UnitaDocAggAllegati xmlns:xsd= xmlns:xsi=" <Intestazione> <Versione> </Versione> Data 19/02/2019 Rev. 0 Pagina 26 di 53

27 <Versatore> <Ambiente> </Ambiente> <Ente> </Ente> <Struttura> </Struttura> <UserID> </UserID> </Versatore> <Chiave> <Numero> </Numero> <Anno> </Anno> <TipoRegistro> </TipoRegistro> </Chiave> </Intestazione> <Annesso> <IDDocumento> </IDDocumento> <TipoDocumento> </TipoDocumento> <ProfiloDocumento> <Descrizione> </Descrizione> <Autore> </Autore> </ProfiloDocumento> <DatiSpecifici> </DatiSpecifici> <StrutturaOriginale> <TipoStruttura>DocumentoGenerico</TipoStruttura> <Componenti> <Componente> <ID> </ID> <OrdinePresentazione> </OrdinePresentazione> <TipoComponente> </TipoComponente> <TipoSupportoComponente> </TipoSupportoComponente> <NomeComponente> </NomeComponente> <FormatoFileVersato> </FormatoFileVersato> <HashVersato></HashVersato> <IDComponenteVersato> </IDComponenteVersato> <UtilizzoDataFirmaPerRifTemp> </UtilizzoDataFirmaPerRifTemp> </Componente> </Componenti> </StrutturaOriginale> </Annesso> </UnitaDocAggAllegati> Il versamento del SIP di modifica avverrà tramite il servizio di versamento sincrono di aggiornamento/modifica: AMBIENTE DI TEST: Data 19/02/2019 Rev. 0 Pagina 27 di 53

28 AMBIENTE DI PRODUZIONE: Pre-condizioni: 1) L applicativo chiamante deve essere autorizzato al trasferimento su DigiP. 2) Il sistema di conservazione DigiP ha archiviato l AIP oggetto di aggiornamento/modifica. Post-condizioni: 1) SIP di modifica correttamente inviato e generazione del corrispondente AIP il quale sarà collegato all AIP oggetto di aggiornamento/modifica. 3) L indice del pacchetto di versamento deve contenere obbligatoriamente la <Chiave> (Numero-Anno-TipoRegistro) la quale deve essere la stessa del pacchetto AIP da modificare precedentemente versato. Processo versamento - Fase sincrona 1) Il sistema rileva un nuovo versamento e trasferisce il SIP in una cartella di lavoro temporanea. Il sistema di conservazione recupera il file XSD definito per la tipologia documentaria specifica. 2) Il sistema recupera la tipologia documentale in base alla tipologia documentale di modifica dichiarata nell'indice del pacchetto di versamento e fa i primi controlli sugli oggetti ricevuti se sono conformi agli accordi presi con l'ente produttore (cfr. 3.8): Controllo della versione del file xml di indice. Controllo utente versatore se abilitato al versamento. Controllo esistenza tipologia documentale definita nell'indice. Controllo struttura indice xml (non vuoto, validazione xsd). Controllo del pacchetto SIP versato in base al nome del pacchetto (WS+Numero+Anno+TipoRegistro) e renaming sul nome del pacchetto con l'aggiunta finale di una stringa costruita random per la gestione di eventuali duplicati (cfr. cap. 5). Ad esempio: WS+Numero+Anno+TipoRegistro_random WS RGPGRM_INh. Controllo file allegati: non vuoti, lunghezza nome del file, numero e nome file allegati congruente a quanto dichiarato nell'indice. Questi controlli vengono effettuati se il supporto componente è di tipo FILE, se è di tipo METADATI il controllo non viene effettuato. Definizione dei file di Processo: file json creati dal sistema per ogni allegato. Vengono memorizzati metadati specifici utili per il processo. Controllo hash dei file allegati con quanto dichiarato nell'indice di versamento sulla base degli accordi con l'ente produttore (Disciplinare tecnico). Data 19/02/2019 Rev. 0 Pagina 28 di 53

29 3) Salvataggio del pacchetto SIP: definizione di un UUID univoco e salvataggio sul repository dei file e sul database dei primi metadati. 4) Se i controlli sono corretti DigiP prende in carico il versamento generando un esito di versamento (Ricevuta di Carico - RDC) positivo, altrimenti l esito di versamento ne evidenza il rifiuto (RDC negativa). Il sistema notifica l esito di versamento all ente produttore (cfr. 3.6) Processo versamento - Fase asincrona 5) Il sistema controlla se in archivio esiste il pacchetto da aggiornare/modificare con la stessa Chiave. Se presente verifica che lo stato del pacchetto da aggiornare/modificare sia COMPLETE e procede. Se non è presente o lo stato del pacchetto da aggiornare/modificare è in RUNNING o in ERROR non procede e pone il versamento di modifica in uno stato di attesa o di errore a seconda dei casi: Modify: recupero stato del pacchetto da aggiornare/modificare (se ci sono duplicati recupera il più vecchio valido): - Se lo stato è NOT_PRESENT Il versamento di modifica viene bloccato e va in stato NO_MODIFICA ERROR ("Chiave Documento non esiste: documento non presente e impossibile la modifica") - Se lo stato è NOT_VALIDATED Il versamento di modifica viene bloccato e va in stato NOT_VALIDATED-ERROR ( Chiave SIP esiste ma il SIP non risulta valido ) - Se lo stato è in RUNNING Il versamento di modifica va in uno stato WAITING e attende che il pacchetto 'Principale' termini l'elaborazione. - Se lo stato è COMPLETE Il versamento di modifica procede coi passaggi successivi. 6) Il SIP passa al processo per il controllo della qualità (Controlli di Quality Assurance - cfr. cap. 6): il sistema recupera ed esegue le Regole da applicare per la validazione in base al soggetto produttore e al tipo di documento che sta versando e sulla base di quanto specificato nel Disciplinare tecnico: Load: recupero e verifica della tipologia documentale, salvataggio di metadati relativi al pacchetto SIP. Detect: analisi dei file allegati tramite il tool FITS. Rule: applicazione di regole per il controllo dei pacchetti di versamento. 7) Il sistema elabora un Rapporto di Versamento (RDV) firmato e ne salva una copia sul repository: Esiti: recupero esiti, risultati delle regole, e definizione del Rapporto di Versamento (RDV). Firma: firma del RDV (se abilitato). Marca Temporale: servizio di protocollazione (se abilitato). 8) Se il Rapporto di Versamento (RDV) è positivo, DigiP garantisce la creazione del pacchetto Data 19/02/2019 Rev. 0 Pagina 29 di 53

30 di archiviazione (AIP) e la sua memorizzazione nel sistema di conservazione; se negativo DigiP attesta il rifiuto del versamento con conseguente interruzione del processo di L ente produttore potrà verificare lo stato del pacchetto versato recuperando il RDV (cfr. 3.7). 9) Se le regole sono state tutte validate correttamente (il RDV è positivo), il sistema recupera ed esegue le trasformazioni opportune per rendere i file conformi agli accordi per l'archiviazione (attualmente lo standard UNI SInCRO 11386:2010): Trasformation: processi di trasformazione tipo conversione file, trasformazione xslt dall'indice in un formato standard (denominato KIP) ecc. 10) Il sistema genera un AIP e memorizza gli oggetti in una sezione specifica dell'archival Storage: Generate AIP: - merge dei risultati (relativi alle trasformazioni applicate) - trasformazione indice KIP in indice del pacchetto AIP (ad oggi in formato SInCRO) - validazione xsd dell'indice relativo al pacchetto AIP - creazione del UUID relativo al pacchetto AIP e salvataggio dei relativi metadati sul database Firma: firma dell'indice AIP (se abilitato) Generate Complete: pulizia area di lavoro e SIP in ARCHIVED-COMPLETE Flussi di Errore: (cfr. Flussi di Errore del 3.4) Modifica dei soli metadati di un SIP precedentemente versato In questo scenario l ente produttore esegue l aggiornamento/modifica dei soli metadati specifici di un SIP precedentemente versato in DigiP; tale modifica verrà recepita attraverso il versamento di un SIP di modifica (Annesso). In questo caso nell indice di versamento il tag <TipoSupportoComponente> deve essere valorizzato a METADATI, (eseguendo quindi il solo invio dell indice XML, senza file). Pre-condizioni: 1) L applicativo chiamante deve essere autorizzato al trasferimento su DigiP. 2) Il sistema di conservazione DigiP ha archiviato l AIP oggetto di aggiornamento/modifica. Post-condizioni: 1) SIP di modifica correttamente inviato e generazione del corrispondente AIP il quale sarà collegato all AIP oggetto di aggiornamento/modifica. 3) L indice di versamento deve contenere Data 19/02/2019 Rev. 0 Pagina 30 di 53

31 obbligatoriamente la <Chiave> (Numero- Anno-TipoRegistro) del pacchetto di versamento precedentemente versato che si vuole modificare e il tag <TipoSupportoComponente> deve essere valorizzato con METADATI Processo versamento - Fase sincrona 1) Il sistema rileva un nuovo versamento e trasferisce il SIP in una cartella di lavoro temporanea. Il sistema di conservazione recupera il file XSD definito per la tipologia documentaria specifica 2) Il sistema recupera la tipologia documentale in base alla tipologia documentale di modifica dichiarata nell'indice di versamento e fa i primi controlli sugli oggetti ricevuti se sono conformi agli accordi presi con l'ente produttore (cfr. 3.8): Controllo della versione del file xml di indice. Controllo utente versatore se abilitato al versamento. Controllo esistenza tipologia documentale definita nell'indice. Controllo struttura indice xml (non vuoto, validazione xsd). Controllo del pacchetto SIP versato in base al nome del pacchetto (WS+Numero+Anno+TipoRegistro) e renaming sul nome del pacchetto con l'aggiunta finale di una stringa costruita random per la gestione di eventuali duplicati (cfr. cap. 5). Ad esempio: WS+Numero+Anno+TipoRegistro_random WS RGPGRM_INh. Controllo file allegati: non vuoti, lunghezza nome del file, numero e nome file allegati congruente a quanto dichiarato nell'indice. Questi controlli vengono effettuati se il supporto componente è di tipo FILE, se è di tipo METADATI il controllo non viene effettuato. Definizione dei file di Processo: file json creati dal sistema per ogni allegato. Vengono memorizzati metadati specifici utili per il processo. Controllo hash dei file allegati con quanto dichiarato nell'indice di versamento sulla base degli accordi con l'ente produttore (Disciplinare tecnico). 3) Salvataggio del pacchetto SIP: definizione di un UUID univoco e salvataggio sul repository dei file e sul database dei primi metadati. 4) Se i controlli sono corretti DigiP prende in carica il versamento generando un esito di versamento (Ricevuta di Carico - RDC) positivo, altrimenti l esito di versamento ne evidenza il rifiuto (RDC negativa). Il sistema notifica l esito di versamento all ente produttore ( 3.6) Processo versamento - Fase asincrona 5) Controlla se in archivio esiste il pacchetto da aggiornare/modificare con la stessa Chiave. Se presente verifica che lo stato del pacchetto da aggiornare/modificare sia COMPLETE e procede. Se non è presente o lo stato del pacchetto da aggiornare/modificare è in RUNNING Data 19/02/2019 Rev. 0 Pagina 31 di 53