Koncept oddělení formy a obsahu webových stránek v Oracle UCM

Chtěl bych věnovat několik článků oblasti Web Content Managementu, který je v release 11g jednou z hlavních novinek - a od předchozího release je zde opravdový posun vpřed.

Abychom se mohli věnovat detailům, je nejprve třeba vysvětlit některé základní koncepty, které jsou vlastně stejné už po několik let, ale které je nyní možné využít ještě s větší efektivitou.

Prvním z nich je oddělení formy a obsahu, které ve svém důsledku znamená oddělení rolí při správě webového obsahu:

• designer/vývojář, se starají o formu stránek
• přispěvovatelé, se starají o obsah

Vše bude více evidentní z následujícího obrázku:


Jak je vidět, šablona stránky (kromě jiného) obsahuje tzv. regiony, což je oblast, do které designer/vývojář stránek dovoluje přiřadit obsah. Samotný region je opět možné dál rozdělit na tzv. elementy (v uvedeném příkladě má region tři části: nadpis, podtitulek a vlastní text) a těmto elementům je pak možné přidělit obsah, což je ve skutečnosti položka obsahu z úložiště.

Co vše může být obsahem, který je možné přiřadit k elementu?

• contributor data files - jednoduchá XML obsahující krátké texty; tyto texty je možné editovat v rámci WYSIWYG editoru přímo na stránkách
• native files - v podstatě jakýkoliv "dokument", který je možné konvertovat do HTML. Konverze probíhá (zpravidla) online a využívá se při ní DynamicConverter. Tyto soubory je možné editovat ve svých nativních aplikacích (MS Word, Excel, atp.)
• obrázky a další multimediální obsah (např. Flash animace, videa apod.) - i pro tento obsah se velmi často využívají nejrůznější konverze či streaming. Pro tyto konverze se využívá modul Digital Assets Management.

(pokračování někdy v budoucnu)

Odkaz na popis procesu upgrade z 10g na 11g

Ještě krátká informace ke článku z minulého týdne: guideline pro upgrade z verze 10g na 11g je k dispozici na tomto linku http://download.oracle.com/docs/cd/E14571_01/doc.1111/e16451/toc.htm

Ukládání nestrukturovaného obsahu do databáze

V dnešním článku se pokusím zaměřit na téma, o kterém stále koluje řada dezinformací. Protože se budu pouštět spíše na led databázistů (dokonce nejen oraclovských), dovoluji si požádat o benevolenci při technických detailech - v hlavních argumentech bych se ale plést neměl.

Jak je to tedy s tím ukládáním do databáze:
- první nezvratné tvrzení je, že je to možné, a to jak pro databáze Oracle (min. od verze 10g), tak pro Microsoft SQL Server (podle informací, které jsem našel, nejspíš od verze MS SQL 2005)
- druhé tvrzení je, že UCM 11g je certifikováno na oba výše zmíněné databázové servery. Ukládání se však neděje přímo do databáze, ale přes jakési dočasné úložiště na filesystému, a to pomocí komponent FileStore Provider (což jsou jakési speciální adaptéry, které umí ukládat obsah prakticky kamkoliv). Důvodem pro meziúložiště je to, že některé části systému (např. konverzní server) zatím neumí pracovat s ničím jiným, než soubory na disku
- třetí tvrzení je, že ukládání do databáze je pomalejší a méně efektivní (o režii, kterou databáze má). Nevím jak pro Microsoft, ale pro Oracle toto tvrzení (pro některé typy úloh) již neplatí. Od verze 11g obsahuje databáze technologii SecureFiles, která je optimalizovaná takovým způsobem, že
a) dokáže "mnoho malých souboru" načítat v dávce tak, že dokonce porazí ve výkonu filesystem. Toto řešení bylo optimalizováno především na ukládání emailů, což jsou velmi často poměrně krátké zprávy.
b) dokáže nad ukládáným obsahem provozovat kompresi, deduplikaci a šifrování, takže dokáže na některých operacích "ušetřit"
- čtvrtým tvrzením je, že pro mnohé ECM projekty je ukládání souborů do databáze sňatkem z rozumu. Kvůli metadatům je databáze tak jako tak nutnou částí projektu, takže možností ukládat i nestrukturovaná data je možné jednou ranou vyřešit zálohování/obnovy, disaster recovery scénáře a v konečném důsledku mít jednoho administrátora na všechno. Při využití vhodném využití technologií jako je partitioning, je možné jeden velký soubor rozdělit na přijatelné množství (vyhnout se druhému extrému: spoustu malých souborů) - byť vybrat vhodné kritérium pro partitioning může být u obecných dokumentových projektů poměrně obtížné. A v neposlední řadě je možné využít Automatic Storage Management, který se na základě metadat (UCM) postará o uložení na správné médium (HW) v rámci životního cyklu informace (ILC).

Upgrade z verze UCM 10g na verzi 11g

Byť je to zřejmě ještě trochu předčasné, pokusme se zastavit nad tím, co by se muselo stát, aby se zákazník provozující verzi 10g zupgradoval na 11g.

Nejprve si položme otázku, co vlastně představuje běžící řešení (toto je poměrně obecná úvaha, která se ani zdaleka netýká jen Oracle UCM): řešení beží na nějakém hardware, na kterém je nainstalován nějaký běžící kód (software), další důležitou částí je pak konfigurace řešení a nakonec v tom celém jsou uložena nějaká data. Software bychom si pak mohli ještě rozdělit na standardní programy (např. balíková řešení, ale i třeba operační systém) a specifické programy (customizace - v UCM jsou to komponenty vyvíjené na míru potřebám konkrétního klienta).

Těchto pět částí, tj. hardware, standardní software, specifický software, konfigurace a data, představuje problém, se kterým se musíme vypořádat při upgradech, ale i třeba při budování záložního řešení, či obnově při výpadku.

a) hardware
Je smutnou pravdou, že při aktualizaci software, zejména jedná-li se o aktualizaci generační, bývá zpravidla nezbytné plně zaměnit hardware. Navíc vzhledem k tomu, že velmi často je prostě technicky nemožné "otočením klíčku" jedno řešení nahradit druhým, bývá nutné, aby po nějakou dobu běžela "staré" a "nové" řešení paralelně vedle sebe. Dnes může být řešením aplikační grid (či přímo "cloud"), pro zákazníky se skromnější infrastrukturou mohou vypomoci testovací či školící prostředí. S jistou mírou redundance je však třeba počítat vždy.

b) standardní software
Je-li řešení psáno jako vícevrstvé a dovolí-li to nároky na výkon a na bezpečnost, je možné při upgrade dosáhnout jisté synergie. Bohužel, díky zásadním změnám v architektuře mezi verzemi 10g a 11g existují v podstatě jen dvě komponenty, které jsou oběma společné - databáze a LDAP.

c) specifický software (v UCM custom komponenty)
Toto je samozřejmě šedá množina, o které se a priori nedá říct nic, než že je vše potřeba řádně otestovat, popř. opravit. V UCM je výhoda, že oba releases jsou minimálně psané v Javě, která je (teoreticky) plně přenositelná. Většina komponent je proto buď rovnou přenositelná nebo vyžaduje jen drobné úpravy. Existují výjimky, které se týkají změn v architektuře. Hlavní body jsou popsány v tomto příspěvku na fóru.
V ČR je využití custom komponent (s výjimkou jediného projektu, který je však ještě na starší verzi Stellentu) zatím minimální. Proto by s tímto bodem neměly být problémy.

d) konfigurace
Problém přenosu či uchování konfigurace se týká samozřejmě i např. přenosu mezi testovacími a produkčními prostředími. V UCM je k tomuto účelu určena komponenta Configuration Migration Utility (CMU), která umí exportovat či importovat většinu standardní konfigurace. Výjimku tvoří nastavení vytvořená v .cfg souborech (které je možné přenést jako takové) a pak konfigurace vytvořená pomocí některých komponent (např. i Folders; tj. definice hierarchie virtuálních adresářů).

e) data
I pro data, tj. vložené dokumenty a jejich metadata, existuje administrační aplikace zvaná Archiver. Původní využití této aplikace, jak možná napovídá název, bylo pro ukládání starších dokumentů do offline archivu. Již za časů Stellentu se však aplikace začala využívat i pro synchronizaci obsahu mezi servery, tedy potenciálně i pro migrace z jedné verze na další. V některých specifických případech (např. aktualizace metadat) je možné aplikaci využít i pro export a import dat ze stejného systému.

Pro verzi 11gR2 již existují specifikace, jak různé nástroje pro migraci konfigurace a dat sjednotit do jedné aplikace; rovněž bude implementována mnohem rozsáhlejší podpora pro hromadné operace nad více dokumenty.

Records Management vs. Spisová služba, část 3. - teoretické možnosti ochrany dlouhodobě ukládaných dokumentů

V dnešním článku se zaměříme na ochranné prvky pro dlouhodobé ukládání elektronických dokumentů tak, jak je zná zákon 499/2004, tj. na elektronický podpis a časové razítko, stejně jako na další alternativní možnosti, jak zaručit 3 aspekty dlouhodobého uložení, tj. čitelnost, prokazatelnost a neměnnost.

Asi každý zná základní fakta, že dokument v digitální podobě se považuje za pravý, byl-li podepsán platným uznávaným elektronickým podpisem nebo označen platnou elektronickou značkou osoby ... a opatřen kvalifikovaným časovým razítkem. Stejně tak je známé, že elektronický podpis je platný max. po dobu 1 roku a časové razítko max. 5 let.

Na počátku jsou problémy hlavně s podpisy - zejm. jejich platností. Bude-li dokument opatřen platným podpisem, ale dorazí-li k příjemci až po vypršení platnosti, je problém. Toto je problém zejména ve spojitosti s autorizovanou konverzí el. dokumentu na listinnou podobu, ke které nemusí dojít okamžitě po doručení dokumentu.
Další drobnou komplikací souvidející z datovými schránkami je to, že u většiny schránek (typicky u osobních schránek), má doručení přes datové schránky stejnou právní platnost jako by byl dokument podepsán. To je možné vyřešit podepisováním - zde asi spíš značkou organizace - na příjmu.
Je-li však dokument podepsán, stejně není vyhráno, protože je třeba provést ověření platnosti podpisu. To je možné až na "next-business-day", protože rejstříky zneplatněných certifikátů se aktualizují (prý) někdy přes noc. Jen na okraj: ergo, datové schránky z podstaty věci není možné užít na "rychloobrátkové" dokumenty, kdy je třeba reagovat v rámci hodin či 1-2 dnů.
Z hlediska dlouhodobého uložení je však důležitější, že protokol o ověření platnosti podpisu (razítka) je také ZD a musí být uložen spolu s průvodním dokumentem.
K časovému razítku jen asi poznámku, že u datových schránek jimi sice opatřuje zprávu sám systém, jedná se však o razítko na celou zprávu (chcete-li: na zprávu v obálce), nikoliv na razítko přiloženého dokumentu/-ů. Ergo, budete-li chtít s dokumenty pracovat odděleně, budete jej muset zřejmě stejně přerazítkovat (pokud tak neučinil odesílatel).

Řekněme, že s tím se nějak vypořádáme. K problémům, na něž zatím neexistuje jasná odpověď, pak dojde v okamžiku vypršení platnosti časového razítka. Na nastalou situaci existují dva právní názory: jeden tvrdí, že pak je třeba dokument znovu přerazítkovat; druhý tvrdí, že není třeba dělat nic, protože v okamžiku zakládání dokumentu bylo vše platné. S druhým názorem by se mělo bojovat - pokud dojde k prolomení šifry, na které jsou založeny podpisy a razítka, může pak někdo "vyrobit" Vámi podepsaný dokument opatřený časovým razítkem, který jste nikdy neviděli. Aby toho nebylo málo, dodejme, že i ukládání elektronických podpisů není věčné - ukládají se myslím na 10 či 12 let, takže po této době se již ani nebude možné dopátrat, kdo to vlastně dokument podepsal.
Ani přerazítkovávání však není příliš lákavá možnost (tedy, pokud nejste certifikační autorita): pokud za rok vytvoříte X dokumentů, pak za 5 let budete přerazítkovávat X, za 10 let 2X, za 15 let 3x atd. A to prosím zpravidla najednou - nejspíš po měsíčních dávkách. Tedy náklady a jakási práce (nejspíš plně automatizovaná - RM systémy vám v tom mohou pomoci sledováním vypršení platnosti časového razítka).

Abychom už měli přehled úplný, dodejme ještě problém, který se zatím nikde moc neeskaloval - problém s čitelností. Dnes je čitelnost řešena taxatorním vyjmenováním formátů, ve kterých je možné dokumenty dlouhodobě ukládat - např. pro texty to je primárně PDF/A. Protože se však bavíme o dlouhých skartačních lhůtách -u některých dokumentů to může být na desítky let či "navždy", dá se předpokládat, že i od tohoto formátu se někdy upustí. Pokud někdo vyspecifikuje, jak PDF/A převést na formát XYZ (bude to další instituce pro autorizovanou konverzi?), je třeba dořešit, jak tento nový dokument svázat s původním obsahem, který obsahuje již dávno neplatné a možná i neexistující identifikátory původce -nejspíš tedy bude možné nějak "přibalit" XYZ k původnímu obsahu a držet vše pohromadě - toto je ostatně myšlenka tzv. archívních balíčků (AIP) z normy OAIS, kterou bude zřejmě nezbytné brzy zapracovat do zákona či vyhlášky.

Slíbil jsem ale přehled dalších možností, jak by se daly tři pilíře implementovat jinak:

1. certifikace systému
První možností jsou certifikace - u nás nejspíš stát jmenuje autoritu, která prověří systém (pro MoReq2 existuje sada testovacích případů, kterými bude testovaný systém prověřen). Poté platí, že je-li dokument vložen do systému jako ZD, pak je autentický a nezměněný. Tento princip dokáže řešit všechny tři pilíře (i konverzi je možné otestovat) a je užit např. v Belgii.

2. nezávislý arbitr
Myšlenkou tohoto řešení je, že bude existovat jeden centrální systém, ve kterém budou uloženy kopie všech dokumentů - pokud budete chtít mít jistotu, zeptáte se, zda dokument, který máte k dispozici, je originálem, za který se vydává. Toto řešení - zatím jen pro dokumenty z datových schránek pod hlavičkou CEED či CEDD - prezentovali někteří dodavatelé. Pokud by zároveň s licencí na provozování systému získali právo na provádění konverzí z důvodů čitelnosti, mohlo by to pro určité omezené celky (např. datové schránky) fungovat. Neumím si však představit, že by to fungovalo jako řešení pro RM obecně (když nic jiného: jak by se u tohoto Velkého Bratra řešila bezpečnost obsahu dokumentů?)

3. ochrana hardwarovými prostředky
Pro neměnnost a autenticitu dokumentu existuje ještě jedno řešení: využití technologií WORM (write-once-read-many), které z definice nedovolují obsah měnit. Protože však ani hardware není věčný, mají tato řešení podporu redundantního ukládání záznamu, resp. garanci dostupnosti. Fakticky se tak jedná o jakousi speciální verzi certifikace systému.

Records Management vs. Spisová služba, část 2.

Abychom se dokázali posunout dále a vyhnuli se pokud možno termínové pasti, je třeba si narovnat základní pojmy: pro anglický termín document budu nadále používat český ekvivalent dokument a pro anglický termín record navrhuji založený, popř. zaknihovaný či zaregistrovaný dokument (zkráceně ZD).

Tento termín v sobě implicitně obsahuje informaci, že ZD je dokument, který prošel nějakým dalším procesem; osobně preferuji adjektivum založený, protože vychází ze zvyklosti, kdy se důležité listinné dokumenty, na kterým organizaci záleželo, zakládaly do spisů.

Takto vybaveni pokusíme zapátrat na internetu po definici pojmu records management. Poměrně vyčerpávající jsem našel na mé oblíbené wikipedii, a to zde. Až se probereme detaily, zkuste jen ze zvědavosti srovnat detaily s definicí spisové služby tamtéž.

1. RM je způsob uchovávání ZD organizace od jejich vzniku až po případnou dobu jejich skartace; RM zahrnuje klasifikaci, uložení, zabezpečení a zničení ZD (v některých případech i jejich archivní uchovávání)
... v této obecné rovině moc rozdílů nenajdeme

2. ISO 15489:2001 (jedna z mezinárodních norem specifikující pojem records management) zahrnuje do RM:

• nastavení politik a standardů
• přiřazení zodpovědností a odpovědností
• vydání směrnic
• poskytování řady služeb spojených se správou a užíváním ZD
• navržení, zprovoznění a udržování systémů pro správu ZD
• integraci RM s ostatními systémy a procesy organizace

... zde už pár drobných rozdílů najdeme. Především, musíme si uvědomit, že rozmach RM nastal (jak se ostatně v anglickém článku na wikipedii zmiňuje) po aféře společnosti Enron, která ve spolupráci s poradenskou firmou Arthur Andersen, podváděla své investory - na základě zfalšované či ztracené dokumentace.
U nás je praxe trochu jiná - RM či spisovou službu organizace provádějí, "protože to po nich stát chce"; často však aniž by stát sám věděl proč, či měl mechanismy jak provádět kontrolu

Můj oblíbený příklad, který uvádím při prezentacích: podle zákona 499/2004 Sb. mají povinnost uchovávat dokumenty také politické strany. Ve smyslu výše uvedeného případu Enron/Andersen by bylo zajímavé provést kontrolu, zda politické strany také neuvádějí v omyl své investory, tj. voliče...

Jiný případ nesouvisí přímo s dokumenty: během své civilní služby v polovině devadesátých let jsem na základní škole Na Líše prováděl kontrolu počtu plynových masek pro děti. Masky byly staré, zaprášené, nemyslím, že by v případě chemického poplachu byly velkou pomocí a naopak možná by spíš způsobily pár problémů v případě cvičení. Přesto, kdyby se ztratila byť jediná, tak paní ředitelku zavřou...

Ale k meritu věci: rozdíl mezi RM a spisovou službou je ten, že RM je mnohem více metodologie, či proces, který slouží k ochraně něčeho, co buď organizace, nebo stát chce chránit. Jeho hlavní podstatou je říct, co se má dělat a kdo je za to zodpovědný a je mnohem volnější v provedení jak. Naopak, spisová služba je hlavně povinnost. Specifikuje co, je velmi detailní v jak, ale je velmi vágní v definování odpovědnosti (zkuste si např. najít v textech najít slovo "odpovědn*"). V jisté extrémní interpretaci se naplnění povinnosti chápe jako "implementace (aplikace) spisové služby" - tj. termínem "spisová služba" se míní sama aplikace.

3. zastavme se ještě u standardů
Pokud připustíme, že i v komerční organizaci existují elektronické dokumenty, které má smysl dlouhodobě uchovávat, ale na které se nevztahuje zákon 499/2004 Sb. (nebo jiný, např. 235/2004 Sb., který se vztahuje na účetní dokumenty - účtenky a faktury, pokud by byly vydávány v elektronické podobě) - může se jednat o nejrůznější vnitrofiremní standardy a procedury, či např. osobní údaje zaměstnanců či údaje o zákaznících (zde může RM pomoci zejména se zákonnou skartací danou zákonem 101/2000 Sb. o ochraně osobních údajů), pak standardy uvedené v zákoně o spisové službě, resp. jeho prováděcí vyhlášce, mohou být značně na obtíž - asi není nic špatného na formátu PDF/A (zajišťujícím čitelnost), dost možná však nebudou třeba elektronický podpis (autenticita - vnitrofiremní systémy si jistě s autenticitou vkladatele poradí), ani časové razítko (neměnnost - opět, organizace bude "věřit" svému systému), nemluvě o košatém metadatovém modelu Národního standardu.

4. časově omezená platnost ochranných prvků aneb legislativní časovaná bomba?
V neposlední řadě je třeba zmínit snad již poměrně známý fakt, že ochranné prvky zajišťující dlouhodobé uložení, mají samy časově poměrně omezenou platnost - což. J. Peterka nazývá ve svém článku "Časovanou bombou v e-Governmentu". Toto téma si zaslouží samostatný článek.

Records Management vs. Spisová služba, část 1.

Pokud bych se měl vyjádřit expresívně, pak v tom v tom tvůrci národního standardu pro spisové služby, byť možná ve vleku zákonodárce, udělali pěkný bordel.

Národní standard je do značné míry překladem evropské normy MoReq2 (mimochodem, už se připravuje nový standard MoReq2010 - bude se tedy Národní standard aktualizovat?), který ovšem obsahuje některé "překladatelské boty" (že by cui bono?), které ve svém důsledku vedou k naprostému zmatení pojmů. Totiž, větu, která v originále zní:

"some documents become records"

přeložili jako

"záznamy se stávají dokumenty"

(to jest prohodili pojmy).

Pojem "Electronic Records Management System" pak překládají jako "Elektronický systém spisové služby", což má evidentně navodit dojem, že "spisová služba" je tím pravým ořechovým pro udržování elektronických dokumentů.

Jakkoli je těchto pojmech beze vší pochyby značný překryv a existují organizace, kde plně splývají, spisová služba není totéž co records management a naopak.

Problém s termínem spisová služba je totiž ten, že je poměrně jasně specifikován zákonem 499/2004 Sb. - §63 stanoví kdo spisovou službu vykonává a §70 potom jakým způsobem.

Termíny spisová služba a records management tedy splývají výhradně u organizací uvedených v §63.

Sám zákon 499/2004 Sb. však stanoví, že "Povinnost uchovávat dokumenty a umožnit výběr archiválií mají" též další organizace dané zákonem. A pokud by tak nepřikazoval zákon, v přiměřené míře by tak měl přikazovat zdravý rozum (minimálně pro tu část věty "uchovávat dokumenty"), protože pro řadu organizací představují dokumenty a jejich efektivní správa skutečnou hodnotu. A troufnu si tvrdit, že přestože by řada z nich ocenila (možná pod vlivem okolností) records management, spisová služba by pro ně byla zbytečnou přítěží.

V čem tedy spočívá rozdíl?

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