Tvorba AIP balíčku

Archivní modul

O generování AIP balíčků se ve FormFlow stará Archivní modul. Tento modul definuje sedm repozitářů, nad kterými jsou spouštěny jednotlivé služby. Každá služba provede s položkou repozitáře předepsanou akci a přesune položku do dalšího repozitáře. Procesu transformace vstupních dokumentů do AIP balíčku se říká Ingest proces; ten je popsán v následující kapitole.

Ingest proces

Ingest proces lze graficky znázornit níže uvedeným obrázkem. Skládá se ze sedmi repozitářů a pěti služeb. Tyto služby běží pod jednou FFS službou (am_ingest).

image952

Služba Získání SIP

Jejím úkolem je získání dokumentů z vnějšího zdroje. Vnější zdroj může být webová služba, složka na disku, 602XML formulář atd. Služba získá dokument, zabalí ho do interního SIP balíčku a uloží ho do repozitáře „Karanténa“.

Služba Antivirová kontrola

Vstupem služby je repozitář „Karanténa“. Služba provede antivirovou kontrolu nad přílohami SIP balíčku a v případě detekce viru odsune balíček do repozitáře „Vyloučených SIP balíčků“. V opačném případě přesune SIP do repozitáře „Kontrola podpisů“.

Služba Kontrola podpisů SIP

Vstupem je repozitář „Kontrola podpisů“. Služba prověří platnost podpisu SIP balíčku. Pokud je podpis v pořádku, je SIP přesunut do repozitáře „Generování AIP“. V opačném případě je SIP přesunut do repozitáře „Vyloučených SIP“.

Služba Generování AIP

Vstupem je repozitář „Generování AIP“. Služba vygeneruje základní strukturu AIP balíčku a uloží ho do repozitáře „Konverze příloh“. Pokud se službě nepodaří transformovat SIP balíček na AIP balíček, je SIP balíček přesunut do repozitáře „Vyloučených SIP“.

Služba Finalizace AIP

V repozitáři „Konverze příloh“ leží AIP balíček, dokud konverzní služba nezkonvertuje všechny přílohy patřící k tomuto balíčku. Poté dojde k finalizaci AIP balíčku a jeho trvalému uložení v Archivu. Od této chvíle je balíček viditelný pro službu dlouhodobé údržby dokumentů a může k ní být registrován.

Toto je pouze jeden z možných scénářů generování AIP balíčku. Jediný povinný repozitář, ve kterém musí skončit AIP balíček, je repozitář „Trvalé uložení“.

Výchozí implementace procesu vytahování příloh formulářů

Ve FFS je výchozí implementace ingest procesu. Vstupem je archivovaný formulář, u kterého již došlo k vytažení příloh pomocí udat služby. Služba udat pro vytahování příloh pracuje pouze s datovou větou uloženou v RECEIVED_DATA_UFRM či RECEIVED_XSLFO_UFRM. Nespouští žádné pluginy. Např. tedy nereaguje na změny, které provede form_download_plugin. S tímto je třeba počítat a modifikovat přílohy a jejich atributy jako ltv_accept_udat před uložením datové věty do databáze. Vytvořené AIP balíčky budou připojeny jako přílohy formulářů, ze kterých vznikly.

Konfigurace v config.php

  • XMLGW_AM_JAVA_HOME: cesta k Java home adresáři. Např. c:/Program Files/Java/jre.

Konfigurace na šabloně formuláře

Na šabloně formuláře v sekci Informace je potřeba zaškrtnout pole Vytvářet AIP balíčky.

image953

Struktura AIP balíčku

AIP balíček je v archivu uložen jako asic-e kontejner. Tento kontejner má následující strukturu.

/
├── META-INF/ ← adresář s informacemi o balíčku
│       ├── mets.xml ← nepodepsaná metadata k souborům
│       ├── signatures.xml ← soubor s externími podpisy
│       └── transaction.log ← záznam, co se s balíčkem dělalo
├── contents.xml ← METS kontejner
├── DOCUMENT_ID.pdf ← příloha x
├── DOCUMENT_ID.doc ← příloha y
├── DOCUMENT_ID.txt ← příloha z
└── mimetype

META-INF/mets.xml & contents.xml

Soubor META-INF/mets.xml obsahuje nepodepsaná metadata. Tato metadata se v průběhu života balíčku mohou měnit. Pokud dojde k modifikaci metadat v archivovaném formuláři stavba nebo dokument, projeví se změna i v tomto souboru.

Soubor contents.xml obsahuje odkazy na přílohy. Dále obsahuje metadata stavby a jednotlivých příloh v době vzniku balíčku. Tato část je podepsaná a není ji tedy možné dále upravovat.

signatures.xml

Soubor signatures.xml obsahuje externí podpisy souborů, ležící v rootu balíčku. V tomto případě obsahuje soubor signatures.xml externí podpisy souborů contents.xml, DOCUMENT_ID.pdf, DOCUMENT_ID.doc, DOCUMENT_ID.txt.

transaction.log

Soubor transaction.log obsahuje záznam akcí, které se s balíčkem prováděly. Jsou to akce jako dlouhodobá údržba nebo stažení balíčku.

DOCUMENT_ID.pdf, DOCUMENT_ID.doc, DOCUMENT_ID.txt

Vlastní přílohy balíčku.

mimetype

Soubor mimetype obsahuje application/vnd.etsi.asic-e+zip, což je mimetype asic-e kontejneru.

Popis fungování AIP balíčku

Nastavení šablony formuláře

archiv aip sablona

Aby bylo možné vytvářet AIP balíčky, je nutné v šabloně formuláře nastavit, že se mají generovat z příloh archivních formulářů.

Vytvoření AIP balíčku

Služba AIP service vezme daný formulář a vytvoří k němu obálku pomocí funkce Create AIP repository (AM_SIPCreateAIPRepository).

Výsledek této operace se projeví v tabulce XG_AMRR, kde ve sloupci ID_AMRE_AMRR najdete ID odpovídající vytvoření AIP repository (AM_SIPCreateAIPRepository).

Řešení chyb při vytváření

Pokud v této fázi nastane chyba, formulář bude mít v tabulce XG_AMRR hodnotu ID_UFRM_AMRR, která odpovídá ID_UFRM v XG_UFRM.

V poli ID_AMRE bude nastaveno ID SIP exclude repository (AM_SIPExcludeRepository).

Opětovné zařazení formuláře do procesu

Pokud nastane výše uvedená situace, je vhodné počkat, až hodnota NUMBER_OF_READ_AMRR dosáhne 5.

archiv aip tabulka

Pokud má formulář v ID_AMRE_AMRR hodnotu odpovídající SIP exclude repository (AM_SIPExcludeRepository), lze jej znovu zařadit do procesu tím, že se smaže příslušný záznam v tabulce XG_AMRR podle ID_AMRR.

Kontrola příloh a konverze

  1. V další fázi se kontroluje, zda má daný AIP balíček všechny přílohy, zda tyto přílohy existují a zda daný formulář nebyl mezitím smazán.

  2. Po skončení této fáze je v tabulce XG_AMRR pro daný formulář hodnota ID_AMRE_AMRR nastavena na ID pro AIP normalization files repository (AM_AM_AIPNormalizationFilesRepository).

  3. Současně se kontroluje, zda byly všechny přílohy úspěšně zkonvertovány pomocí služby LTA. Je potřeba zajistit, aby služba LTA běžela.

Uložení do permanentního úložiště – dokončený AIP

Pokud vše proběhne v pořádku, bude mít daný AIP balíček v tabulce XG_AMRR hodnotu ID_AMRE_AMRR = ID pro Permanent repository for AIP packages (AM_AIPPermanentRepository).

Postup při chybě konverze

  1. Pokud nastane chyba, bude v ID_AMRE_AMRR nastaveno ID pro AIP exclude repository (AM_AIPExcludeRepository).

  2. Je potřeba počkat, až bude NUMBER_OF_READ_AMRR na hodnotě 5.

  3. Pokud tato situace nastane, doporučuje se zkontrolovat tabulku XG_CONV a zjistit, které přílohy se nezkonvertovaly, jaké mají chybové hlášení PDFA_ERROR_MESSAGE_CONV a případně kód výstupu PDFA_RESULT_CODE_CONV.

archiv aip tabulka

Stav konverze dokumentu (AIP balíček)

CONVERSION_OK = 2000

Konverze proběhla úspěšně.

CONVERSION_FAILED_TEMP = 2001

Konverze dočasně selhala (např. kvůli dočasnému problému, lze zkusit znovu).

CONVERSION_FAILED = 2002

Konverze trvale selhala (nelze dokončit).

CONVERSION_NOT_NEED = 2003

Konverze není potřeba (dokument je již ve správném formátu).

CORRUPTED_DOCUMENT = 2004

Dokument je poškozený a nelze jej zpracovat.

CONVERSION_HAS_NOT_YET_BEEN_MADE = 2005

Konverze zatím nebyla provedena.

CONVERSION_IN_PROCESS = 2006

Konverze právě probíhá.

PREPARE_FOR_INPLACE_CONVERSION = 3000

Příprava na konverzi přímo na místě (in-place).

Výjimky při konverzi příloh (AIP balíček)

  • Pokud je kód konverze jeden z těchto: 7, 92, 15, 111, místo konvertované přílohy se použije originál přílohy.

  • Pokud se konverze nepovede ani po 5 neúspěšných pokusech, je nutné ponechat originál přílohy a dále analyzovat důvod selhání konverze.