Vše nejlepší do roku 2010

Přeji Vám mnoho úspěchů v osobním i pracovním životě nejen do celého roku 2010.

... architektura v úložišti

Pokud bychom otočili zájem o architekturu naopak na vlastní úložiště nestrukturovaného obsahu (dále "ECM úložiště"), dostaneme se na relativně pevnější půdu Solution Architecture.

Základní přiblížení architektury se dá udělat dnes snad nejopakovanějším slidem v celém Oracle:

1. Pokud bychom začali úplně zespoda, nalezneme tam hardware, na kterém se ukládají nestrukturovaná data (v jazyce výrobců hardware znamená termín úložiště zpravidla právě a jenom toto). Podle objemu dat a dalších požadavků se může jednat o disk, pásku, diskové pole, či nejrůznější hybridní zařízení (např. na našem letošním hitu, Exadatě 2, která slouží jako úložiště - storage pro datové sklady a OLTP databáze se využívají z důvodu rychlosti kromě disků i flash paměti). Budiž však řečeno, že tato zařízení již dávno nejsou jen tupými boxy na odkládání informací (souborů) a že často obsahují velmi příjemné (bohužel však často též poměrně nákladné) doplňující funkce - např. pro podporu na tomto blogu diskutovaného konceptu garantovaného úložiště může úložiště - storage nabídnout redundantní uložení stejného souboru, které z pohledu vyšších vrstev (vč. uživatelů) transparentní, čímž výrazně sníží šanci ztráty obsahu z důvodu technického poškození úložného média.
Tato vrstva je pro jakýkoliv projekt úložiště nestrukturovaného obsahu nezbytná.
2. Na další vrstvě nalezneme to, čím je Oracle stále nejznámější - databázi. V našem ECM úložišti (Oracle UCM) může mít databáze dvojí roli - buď se využívá jen na ukládání metadat (tj. dat o souborech v úložišti - v tomto případě je možné využít i databáze od jiných dodavatelů, i jako důkaz toho, že řešení je skutečně otevřené), nebo slouží na ukládání metadat i vlastního obsahu.
Zejména v prostředí, kde již databázi Oracle znají, doporučujeme jako metodu první volby druhou možnost. Databáze totiž "v ceně" dodá do řešení spoustu funkcionalit (jen namátkou: fulltextové vyhledávání či stemming, a to v mnoha jazycích vč. češtiny, hierarchical storage management, unifikované zálohování a v neposlední řadě díky RAC i škálování výkonu). Za jistou nevýhodu by se mohlo považovat, že databáze zpravidla nedokáže plně využít, pravda často proprietární, "inteligence" hardwarových storage zařízení (někdy se funkcionalita zdvojuje, jako např. u HSM, jindy se ne plně využívá, jako např. u zmiňovaného redundantního ukládání). Přesto je možnost ukládat nestrukturované informace jistě velmi zajímavým doplňkem pro řadu řešení.
3. Na třetí úrovni, middleware, patří vlastní ECM úložiště, proto ji na okamžik vynechme.
4. Poslední vrstva nás pak přenese do širokého světa ostatních systémů a aplikací čerpající služby ECM úložiště. Tím bychom se vrátili k obsahu minulého týdne.

Pokud bychom se nyní zaměřili na detaily vlastního úložiště, můžeme pokračovat v naší logice definování jednotlivých vrstev a jejich role v rámci řešení.
a) na nejnižší vstvě najdeme využití služeb storage a databáze - pokud potřebuji najít či vložit dokument s identifikátorem XYZ, musím vědět, kde ho najdu a jak k němu přistupovat
b) na druhé nejnižší vrstvě najdeme pak poskytování základních dokumentačních služeb, jako je práce s metadaty, definování přístupů, podpora workflows atd., tedy úlohy, které se vyskytují prakticky v každém projektu
Kdysi, ještě za časů, kdy produkt vlastnila firma Stellent, se této vrstvě říkalo Content Server a její nasazení bylo nezbytnou podmínkou každého stellent projektu pro správu obsahu. Je třeba poznamenat, že ve své době se tímto Stellent lišil od řady svých konkurentů (jejichž portfolio často vznikalo akvizicemi velmi technologicky odlišných produktů, takže implementace ECM projektu pak představovala integrační projekt se všemi důsledky tohoto faktu - dnes už byla většina řešení redesignována a nová řešení již vznikají podle tohoto konceptu).
Tato vrstva může sloužit jako stand-alone řešení (např. pro oblast DMS) nebo poskytovat svoje služby dalším vrstvám nad ní.
c) řada těchto vyšších vrstev je standardně dodávána (kdysi ve stellentu byly licencovány odděleně) v rámci produktu Oracle UCM. Jedná se o komponenty pro disciplíny jako je Web Content Management, práci s multimediální obsahem, či podporu splnění nejrůznějších legislativních požadavků na uchovávání obsahu (spisová služba, records management). Zajímavostí z pohledu architektury je, že jsou postaveny tak, že čerpají služby základní komponenty a samy pak nabízejí další služby navenek. Stellent byl servisně orientován v době, kdy SOA ještě ani neexistovala.
Další příjemnou vlastností tohoto způsobu je, že jej je možné:

• snadno rozšiřovat - na každou vrstvu je možné doplňovat další a další služby (ať už Oracle nebo komunity dodávají řadu již hotových komponent)
  
• snadno měnit - pokud nějaká služba nedělá, co by bylo třeba, je možné ji upravit či úplně vyměnit

Celkový obrázek architektury úložiště ECM tak může vypadat např. takto:


Vzhledem k tomu, že toto je poslední článek před Vánocemi, přeji Vám šťastné a příjemné prožití svátků.

Úložiště v architektuře...

V tomto týdnu jsme byli spolu s dalšími kolegy z oddělení presales posláni na školení o významu architektury. Na zpáteční cestě jsem se proto rozhodl, že dnešní téma věnuji otázkám spojující architekturu (spíše ve významu Enterprise Architecture) a problematiku ECM.

Ponechme stranou otázku samotného termínu architektura (na toto téma např. článek) - připustme, že je možné dosáhnout jakéhosi ucházejícího přenesení logiky obchodních procesů do IT infrastruktury. Jaké místo v tomto modelu tedy bude zaujímat ECM úložiště? Předně, nejprve bude nezbytné udělat ještě o jeden krok zpět (ve smyslu modelu "vodopádu") a zapátrat, proč by organizace měla vůbec něco takového chtít (tj. pokusit se definovat požadavky).

ECM primárně řeší správu nestrukturovaného obsahu (textových dokumentů, emailů, multimédiálních souborů, skenů atd.) a jakkoli jsme si nijak nespecifikovali o jaké organizaci se bavíme (ať už velikostně či oborově), troufnu si tvrdit, že správu, tj. zavedení jakýchsi základních pravidel, jak s tímto obsahem pracovat, bude muset dříve nebo později zavést každý - když už kvůli ničemu jinému, tak proto, že tento obsah má tendence skutečně nekontrolovaně (exponenciálně?) růst a velmi často obsahuje v záplavě balastu informace, (dokumenty, soubory) které potřebujeme a nebo o které si naopak nemůžeme dovolit přijít.

Požadavkem, který už do jisté míry souvisí s architekturou, je, aby úložiště bylo pokud možno jen jedno - tento požadavek v podstatě diktuje selský rozum (pokud něco budu hledat, vím, kde to najdu - nebo naopak, že to najít nemohu). V ideálním stavu by tomu tak být mělo, ale v realitě je často úložišť hned několik (se všemi problémy, které jsou s tím pak spojeny - dlouhé vyhledávání, různé triky, pravidla a administrátoři pro různé aplikace atd.) - stačí se jen podívat, jak často jsou v ECM úložišti ukládány a spravovány emaily.

Vzhledem ke zbytku světa (rozuměj dalším systémům v rámci Enteprise architektury) je pak ECM úložiště ne nepodobné databázi (osobně proto někdy užívám termín: "databáze dokumentů") - musí umět přijmout, vyhledat, modifikovat a někdy i smazat spravovaný obsah. A pak samozřejmě provádět uvnitř sebe sama některé další operace, které výše uvedené podporují (příkladem může být např. konverze do formátů, které dokáží zobrazit obsah bez nutnosti instalovat na klientskou pracovní stanici speciální software). Kromě procesů, kdy se (na rozdíl od databáze) počítá, že koncoví uživatelé pracují přímo s úložištěm (přes nějaké grafické rozhraní) je to však v zásadě všechno...

Možná Vás napadne, že vše z výše uvedeného se dá splnit i pomocí poměrně výrazně jednodušších (a levnějších) prostředků (jako jsou souborový systém či zmiňovaná databáze). To je pravda. Zatímco se dá bez újmy na obecnosti tvrdit, že úložiště nestrukturovaného obsahu má místo v každé organizace, není možné říct, že by tím úložištěm nutně musel být produkt s nálepkou ECM. Z čehož vyplývá, že kritéria výběru vhodného typu úložiště jsou dána spíše potřebami jednotlivých systémů (procesů či dokonce uživatelů) čerpajících služby úložiště. Tedy spíše úrovní označovanou jako Solution Architecture. "Letecký snímek" organizace může spíše přispět tím, aby se na nějaké řešení při vyhodnocování potřeb nezapomnělo a nebo naopak při dopadové analýze zavádění nového systému.

Nový produkt: Oracle Forms Recognition

Tak trošku ve volném pokračování článku z minulého týdne budeme pokračovat v představování novinek. Od prosince se v ceníku objevil nový produkt Oracle Forms Recognition (je dokonce tak nový, že jej zatím nenajdete ani na stránkách www.oracle.com a opravdu nemá nic společného s technologií Oracle Forms&Reports).

Přesto si myslím, že se jedná o produkt, který může být pro určitou skupinu zákazníků velmi zajímavý - jedná se o podporu automatického zpracování tzv. semistrukturovaných dokumentů (faktur, objednávek apod.), u kterých sice víte, že obsahují nebo mohou obsahovat určitá data (číslo faktury, dodavatele, seznam položek, cenu za kus, celkovou cenu apod.), ale nevíte, kde přesně se tento údaj nalézá, tudíž použití technologií jako je zónové OCR rozpoznávání je přinejmenším problematické. Nasazení produktu je tedy poměrně jasné - na digitalizačních pracovištích došlých dokumentů (primárně faktur, ale nejen), zejména tam, kde tyto pochází z mnoha zdrojů a tudíž se dá očekávat značná variabilita.

Zpracování probíhá třífázově:

• Klasifikace: kdy se na základě "kontextu" (kterým může být jakýkoliv rozpoznávací znak - text, obrázek, či čárový kód na stránce) určí typ dokumentu (např. faktura od dodavatele XYZ). V rámci klasifikace však ale může dojít i k "rozlámání" souvislého toku stránek ze scanneru na jednotlivé dokumenty
• Extrakce: kdy opět na základě "kontextu" dojde k rozpoznání jednotlivých elementů (hlavička faktury, jednotlivé položky atp.)
• Validace a párování: kdy dochází k ověření takto získaných dat. Tím, že se při rozpoznávání dá velmi často využít již známých dat (např. číselníku dodavatelů z ERP, či seznamu položek z objednávky, pokud se nám podaří správně získat její číslo), je možné řadu kroků opravdu výrazně zefektivnit. Nástroj navíc obsahuje i fuzzy search, tj. párování na neúplnou shodu

Samozřejmě, jistě Vás napadne, že ani takto vybavený nástroj není všemocný - co když např. přijde formát, který jste dosud nikdy neviděli? I na toto je pamatováno ošetřením tzv. výjimek, které se samozřejmě předkládají k manuálnímu zpracování. Nástroj však podporuje i samoučící mechanismy, takže z často se objevujících výjimek se brzy může stát nové pravidlo. Kromě OCR je pak ještě podporováno rozpoznávání ICR. Obě jsou podporovány i v češtině.

Pokud byste hledali další reference na internetu, hledejte Brainware Distiller.

Produktové novinky

• čeština

1. Information Rights Management (Desktop Client) - poslední release produktu IRM (klientské části), konkrétně 10R3, PR5, je konečně k dispozici i v češtině! Jedná se o dlouho očekávanou (a slibovanou) vlastnost. "Sealování" je přeloženo jako "pečetění", což myslím, je poměrně zdařilý ekvivalent (i když osobně budu mít chvíli problémy si na něj zvyknout). Po stažení nové verze se Vám tedy může objevit např. toto (jedná se o Powerpoint 2007):
2. Universal Content Management - v listopadu se na OTN objevila také první Oraclem podporovaná verze lokalizace UCM do češtiny (předchozí verze byly tvořeny spolu s lokálními partnery). Prozatím se jedná o řetězce objevující se koncovým uživatelům (nikoliv tedy např. administrátorské applety - na ty si budeme muset počkat až do jarní verze). Výhodou oficiální verze je zejména kontinuita při aktualizacích verze a podpora překladu u všech standardně dodávaných komponent.
   

• Windows 7

1. kromě češtiny je také výše uvedená verze IRM podporována na operačním systému Windows 7. Z portfolia UCM, které běží vesměs buď jako serverová komponenta nebo je zobrazováno v internetovém prohlížeči, se Windows 7 týkají vlastně jen jediné komponenty, a to Desktop Integration Suite (integrace s klientskými aplikacemi balíku Office). I zde je poslední verze podporována i na Windows 7.