Přehled vlastností Oracle UCM, část 6.

V dnešním článku budeme pokračovat popisem vlastností Oracle UCM a tentokrát se podíváme na oblast, ve které (a asi právem) vládnou určité nejasnosti kolem funkcionality i licencování - records management.

Sám výčet 'vlastností' modulu records management je poměrně strohý:

• records management; to si zaslouží další míru detailu
  
• URM content server adapter; tzn. pokud byste se rozhodli implementovat UCM i URM (k důvodům se také dostaneme - pravděpodobně ve speciálním článku o URM), adaptér, jehož úkolem je napojení URM do UCM a vynucování politik nastavených v URM na úrovni UCM, je součástí licence UCM

Jen pro připomenutí, hlavní požadavky na jakýkoliv ERMS systém jsou dva:

1. zaručit, že položky (na toto téma viz. zde), u kterých je k tomu nějaký důvod (zpravidla zákonný), se nesmažou
2. zaručit, že položky, u kterých k tomu důvod naopak je, se smažou, a to kontrolovaným způsobem dle významu položky

Příkladem z první kategorie mohou být došlé či vydané faktury, které mají skartační lhůtu 10 let; příkladem z druhé kategorie mohou být některé záznamy o zaměstancích, které ze zákona o ochraně osobnosti smí firma držet maximálně 2 roky po rozvázání pracovného poměru; jiným příkladem může být snaha smazat nepotřebný obsah (např. emaily).

V systému, ale vlastně i v metodice, se o splnění těchto požadavků stará spisový plán (angl. file plan či retention schedule), což je hierarchická struktura, zpravidla má podobu stromu, kde je možné uzlům přiřadit různé vlastnosti; zejména pak

• jedná-li se o položky, které nesmí uživatel ad-hoc smazat (viz faktury z našeho příkladu); v UCM/URM je tento požadavek implementován pomocí 3 metadatových 'flagů': isDeletable, isEditable, isRevisionable; mimochodem,všimnětě si, že s 'non-records' položkami je možné pracovat dále jako s živými, tj. vytvářet nové verze, měnit je, dokonce i mazat (v rámci bezpečnostních pravidel), ale přesto je možné na ně aplikovat pravidla jako na 'records'
  
• jaký je životní cyklus položky, resp. jaká dispoziční pravidla se na položku vztahují

Pozn. dispoziční pravidlo je vlastně definicí události a reakce na ni (např. na konci měsíce, v němž vyprší k ukončení pracovní smlouvy se zaměstnancem, počkej 2 roky a pak smaž obsah, včetně metadat). Událostí i možných reakcí je celá řada - události mohou být dané jak časem (př. 10 let po ukončení fiskálního roku), tak nějakou stavovou logikou závislou na vnějších faktorech (př. po dobu 1 roku nikdo položku nepřečetl); reakce pak kromě základních dvou, tj. 'smaž položku i metadata' nebo 'smaž položku, ale ponech metadata', umí pracovat s položkou na mnohem jemnější úrovni metadat či stavů - stavy jako 'Expired', 'Archived', 'Canceled' apod., což se velmi často používá pro přesun položky v rámci fyzického úložiště (s rychlého na pomalý disk či na pásku - samozřejmě, o přesun se stará HSM fyzického úložiště nebo databáze Oracle, nikoliv ERMS). V neposlední řadě je pak třeba zmínit, že jak události, tak reakce mohou být customizovány a že dispozičních pravidel může být přiřazeno hned několik (samozřejmě, každé z nich bude mít trochu jiný úkol - jedno může zaručovat přesun v úložišti, druhé zákonné povinnosti a třetí třeba migraci formátu).

(pokračování příště)