jbil7
commented
4 years ago Dle mého názoru první dva body tohoto issue narážejí na pojetí rollbacku a incidentů, které se i podle mě rozchází se současným zadáním. Na základě mých zjištění dojde při neočekávané chybě (tj. chyba ve workflow definition, systémová chyba, chyba ve validaci, sip profilu atd.) k rollbacku spuštěnému automaticky systémem, pak už v ingestu není možno dále pokračovat. Řešení incidentu je poměrně úzce omezeno na nejasné definice v konfiguraci workflow.
V souvislosti se současným pojetím shledávám další problém, na který naráží výše i @kerschfilip v závěru issue: V transfer area pomalu dochází místo, neboť všechny balíky, které v průběhu našich testů spadly do chyby a automaticky skočily do rollbacku, zůstávají v transfer area přes veškerý potenciál jejich opravy a dodatečného ingestu již bez vazby na workflow dále nevyužité.
Rád bych proto navrhnul k diskusi takovéto řešení: dle mého názoru by bylo potřeba změnit pravidla spouštění rollbacků a incidentů. Namísto rollbacku by měl automaticky u všech chyb nastat incident, tedy jakýsi stav "Pozastaveno s chybami". Uživatel by měl mít možnost nastavit workflow, validační profil, opravit balíček ve workspace, nebo jinak libovolným způsobem ošetřit chybu. Následně by mu mělo být umožněno ingest znovu rozeběhnout, a to od začátku procesu, na němž ingest ohlásil chybu nebo od jiného procesu, který si sám uživatel zvolí. Pokud uživatel usoudí, že chybu nelze opravit, měl by mít možnost vyvolat rollback, tj. smazání z workspace, případně i z Archival storage.
Množství balíků v transfer area by se tím zároveň snížilo na uhlídatelnou a přehlednou mez, neboť by tam byly pouze balíky čekající na ingest a nebo balíky, které je nemožno opravit (u nichž by se třeba dal nastavit nějaký timeout pro smazání). Orientaci mezi nimi pro uživatele i pro systém by mohly umožnit prefixy v názvech souborů, o nichž byla řeč již na více předešlých schůzích (viz #39 ).
yantom
kerschfilip
Při další kontrole a testování funkčních požadavků jsem narazil na určitou nesrovnalost, a to v rámci funkcí ingestu: V původním dokumentu k funkčním požadavkům se píše:
V několika bodech ARCLib dané požadavky v tuto chvíli nesplňuje, jsou to:
administrátor má možnost vrátit data dodavateli (změna stavu) nebo data opravit sám – výměnou souboru například, editaci XML – a pak může SIP poslat znovu ke zpracování v Ingestu
výměna souboru či úprava XML není v administračním prostředí možná.
AIP XML je možné editovat při uložení, ale ne před ingestem nebo po ingestu, který selhal
administrátor může také v této fázi přiřadit jiný validační profil a znovu spustit zpracování Ingestu
Ingest obsahuje prostředí dostupné administrátorovi a vkladateli dat, kde je možné procházet data připravená k Ingestu (nebyl spuštěn Ingest)
Ne, že bych si chtěl stěžovat :-) , issue zakládám spíš pro upozornění na tuto nesrovnalost, a také pro případné otevření diskuze, zda některou z těchto funkcionalit přeci jen neimplementovat. Například možnost spustit znovu ingest, který selhal, s jiným SIP či validačním profilem nebo JSON konfigurací bez nutnosti znovu SIP vkládat (když je stejně nesmazaný a leží v Transfer Area) mi připadá jako docela dobrý nápad.