Nový Magic Quadrant pro segment Enterprise Content Management

Minulý týden vyšel oblíbený roční report o stavu produktů v oblasti Enterprise Content Management, tzv. magický kvadrant společnosti Gartner. Celý report naleznete na tomto linku.
Co je v něm nového? Především, Oracle se opět posunul "doprava" a "nahoru". V parametru Completeness of Vision nám dokonce report přisuzuje úplně nejlepší pozici! I v parametru Ability to Execute je změna na pozici leadera - IBM byla nahrazena Microsoftem.

Letošní vynikající výsledek je jistě přinejmenším z velké části důsledkem release UCM 11g, o kterém již nějakou dobu na tomto blogu píšeme. Gartner nám tradičně přisuzuje dobrou pozici zejména díky integraci s balíkem aplikací Oracle (PeopleSoft, E-Business Suite). Pro naše zeměpisné šířky je možná zajímavější informace, že podobná integrace je možná, hotová, referencovatelná a dokonce certifikovaná v testovacích laboratořích ve Walldorfu, i s SAP. To, že se toto řešení tolik nepropaguje, je možná způsobeno tím, že se jedná o řešení partnerské, konkrétně italské firmy Altea. Mezi varováními upozorňuje Gartner zejména na to, že pro řadu menších klientů může být naše řešení vnímáno jako příliš finančně náročné (což ostatně platí kromě Microsoftu o všech leaderech). Jak už to tak bývá, žadný bezplatný oběd není zadarmo - téma Microsoft SharePoint a celkové náklady na jeho provozování je však obsáhlejší a zaslouží si vlastní článek. Pokud bychom si nejprve zametli před vlastním prahem, řešíme finanční dostupnost pro menší klienty především spolu s partnery, kdy je pro dodávku UCM v rámci partnerské aplikace (licenční modely ASFU či embedded) při respektování určitých pravidel možné dosáhnout velmi zajímavých podmínek.

Přeci jen si však pro dnešek neodpustím dvě citace na adresu konkurence:

• SAP DMS byl vyřazen z hodnocení, protože SAP bude nadále preferovat uzší spolupráci s dalšími dodavateli (zmíněn OpenText), než pokračovat ve vlastním rozvoji
• u IBM je tento citát: "IBM má mnoho produktů, které spadají do oblasti ECM; ty ale pocházejí původně od různých výrobců a mají některé vzájemně se překrývající funkce ... stávající i potenciální zákazníci často vyjadřují zmatení v tom, který produkt je pro jejich potřeby optimální a který je strategický pro samotnou IBM". V dalším textu je pak zmíněno, že IBM začíná ztrácet některé zákazníky ve prospěch konkurence, což je ostatně odraženo ve ztrátě první pozice v parametru Ability to Execute.

Jakkoli je samozřejmě třeba brát analytické reporty s jistou měrou zdravého rozumu, musím potvrdit, že minimálně ta fakta a trendy, které cituji v tomto článku, vnímám i na našem relativně malém českém trhu. Snad i proto stojí za to si report prostudovat podrobněji.

Dekompozice stránky ve WCM - odshora dolů (část 1.)

Podívejme se nyní trochu detailněji na to, z čeho se skládá stránka, resp. její šablona (Page Template)



Jak je vidět, šablona stránky se kromě statického textu (který většinou bývá minimální) skládá z tzv.

• fragmentů, což jsou menší znovupoužitelné celky, které podobně jako šablona stránky definují "šablonu" pro nějakou konkrétní část stránky (viz příklad: fragment pro navigaci či footer stránky)
• regionů, reprezentovaných placeholdery, kterým je naopak možné přiřadit obsah z úložiště, resp. tento v nich aktualizovat
• kromě těchto dvou konceptů je možné v definici stránky využít i obsah spravovaný třetí stranou; často se jedná o reklamní bannery či výstupy webových aplikací. Pro tento typ zadání se používá HTML tag iframe. WCM však v tomto případě nemá žádnou kontrolu nad obsahem. Pokud by byla kontrola vyžadována, je možné použít technologii mashup, která je k dispozici v rámci produktu WebCenter.

Co je v release 11g nového, je to, že šablony stránek či fragmentů je možné nyní psát také pomocí notace JSP (v 10g to bylo možné výhradně pomocí proprietárního jazyka iDocScript). Vývojovým nástrojem pro psaní (či grafický design pomocí drag&drop) je nástroj JDeveloper. "Starý" způsob přes iDocScript se ani náhodou neruší. Naopak, produkt management do budoucna slibuje, že způsobů, pomocí kterých bude možné šablony vytvářet, bude neustále přibývat. Tak uvidíme...

Primární a sekundární stránky
Aby se snížil počet vytvářených šablon, nabízí WCM (i v 10g) koncept tzv. primárních a sekundárních stránek.
Primární stránka je definice stránky tak, jak ji návštěvník vidí, když se na stránku dívá poprvé. Obsah (tj. i provázání na položky, které vyplňují jednotlivé regiony) je na ní definován staticky. Představme si ovšem, že obsah přestavuje výpis odkazů na dokumenty dle určitého kritéria, např. tisková prohlášení (pozor! Nenechte se zmást - statická je zde definice dotazu, seznam se samozřejmě bude dynamicky měnit podle aktuálního obsahu úložiště). Nyní bychom ale chtěli na jeden klik zobrazit obsah jednotlivých dokumentů.
A přesně k tomuto jsou určeny sekundární stránky, které provádějí provázání dynamicky, a to až v okamžiku kliknutí na příslušný odkaz.
Bývá dobrou praxí, že primární a sekundární stránky využívají stejnou, nebo alespoň podobnou šablonu (v našem příkladu bychom nejspíš chtěli, aby sekundární stránka obsahovala přinejmenším sekce Banner Image, Side Nav Fragment a Footer Fragment).

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

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.