Národní standard pro eSSL - 4.část: Operace (obecné koncepty)

Původně jsem po návratu z dovolené ještě uvažoval o zařazení lehčího tématu, ale když jsem uviděl, o kolik se po začátku uvedení seriálu o Národním standardu zvýšila navštěvovanost blogu, řekl jsem si, že by bylo škoda Vás nechat napínat, jaká bude koncovka. Jak už jsem psal, poslední téma, tj. požadavky na operace, které explicitně zmiňuje Národní standard, jsou natolik rozsáhlé téma, že se určitě do jednoho článku nevejde. Takže přinejmenším ještě jedno pokračování určitě bude.
Pro dnešek začněme se spíše obecnými koncepty.

Dědičnost
Prvním konceptem, který se táhne napříč řadou požadavků, je dědičnost. Pokud si ještě vzpomenete na první část našeho seriálu, kdy jsme se bavili o hierarchickém uspořádání spisového plánu, dědičnost z něj přesně vychází - dědičnost totiž specifikuje požadavky, aby bylo možné některé vlastnosti (přiřazení skartačních režimů, hodnoty metadat, vč. různých nastavení, co je možno a co ne) propagovat z objektů výše v hierarchii (tj. z věcných skupin do včleněných věcných skupin, spisů atd. - existuje i minimálně jeden příklad, kdy se naopak propagují informace z nižších vrstev nahoru, a to informace, že spis obsahuje kromě digitálních i analogové dokumenty) a na nižších vrstvách naopak vyžadovat splnění těchto přednastavených pravidel.

Automatické generování metadat
Z velmi podobného soudku je požadavek, aby systém automaticky generoval některá významná metadata (např. plně určené spisové znaky, jednací čísla, či jednoznačné identifikátory). Oproti dědičnosti tu však navíc přibývá jeden specifický požadavek, a to tvorba podacího deníku, který se (zpravidla po skončení kalendářního roku) uzavře a pro nové období se pořadové číslo dokumentů začne generovat znovu od počáteční hodnoty.

Operace nad seskupením
Opět do značné míry vycházejí z hierarchického uspořádání. Tentokrát však jde o to, aby se se seskupením (spisem, věcnou skupinou) dalo pracovat jako s celkem. Příkladem takovýchto operací je rozdělení věcné skupiny na dvě či přesunutí věcné skupiny v rámci spisového plánu na jiné místo.

Export/Import
Velmi specifickým příkladem takovéto operace jsou exporty či importy části hierarchické struktury. Příloha 2 pak obsahuje XML schémata, v jakých mají data poskytovat. Jinak importovat či exportovat se dá skutečně vše: dokumenty, spisové plány nebo jejich části, skartační plány (režimy), implicitně s tím aktualizace metadatového modelu a dokonce i transakční protokoly (audit).

(Pokračování za týden)

Rozdíly mezi edicemi UCM (UCM vs. UCM SE)

Jestliže před akvizicí firmy Stellent bylo v ceníku několik desítek položek, z nichž se každá ještě prodávala podle nejrůznějších metrik, takže sestavit srozumitelnou obchodní nabídku byl někdy sám o sobě docela obtížný úkol, v ceníku Oracle najdeme vlastně jen tři položky:
- Oracle Universal Content Management (UCM)
- Oracle Universal Content Management Standard Edition (UCM SE)
- Oracle Enterprise Content Management Suite, která se vlastně ale skládá jen z UCM a dvou dalších produktů (URM, I/PM)

Pro výběr vhodné edice je tedy klíčové pochopit licenční omezení UCM SE (jak už je u Oracle zvykem, jedná se ve skutečnosti o jeden a tentýž kód, u nějž jsou omezení dána výhradně na základě koupené licence a důvěry v koncového zákazníka).

Chybějící funkcionalita
Nejvíce zřejmým je funkční omezení – UCM SE je řešením pro jedinou oblast ECM, a to Document Management (DM). Kromě základní komponenty, Content Server, která poskytuje všechny základní funkce pro DM, obsahuje UCM SE už jen dvě další komponenty, a to Desktop Integration Suite, který poskytuje přímou integraci s nástroji jako je Microsoft Office, Lotus Notes, ad., a Dynamic Converter, který slouží ke konverzi vložených dokumentů do formátu html (tj. pro read-only náhled do spravovaných dokumentů).
Všechny ostatní moduly, jako Web Content Management (WCM), Records Management (RM), Digital Asset Management (DAM) ad. nejsou v edici zahrnuty. Stejně tak nejsou v licenci zahrnuty ani produkty BPEL Process Manager či Conversion Server. UCM SE tak sice nabízí možnost definovat workflows; jedná se však o proprietární workflows psaná v jazyce IDOC Script, která lze jen obtížně využívat pro řízení workflows zahrnujících i jiné aplikace či vyžadujícíh složitější logiku, než je sekvenční změna stavu(-ů) jednoho konkrétního dokumentu.

Další omezení
Mezi další omezení pak patří:
- UCM SE je možné instalovat na server s maximálně 4 sockety (paticemi)
- k UCM SE není možné přistupovat přes Web Services – k integraci by se tedy muselo využít např. JAVA API
- UCM SE neumožňuje replikaci na ostatní UCM servery
- UCM SE neumožňuje active-active clustering

UCM SE je určeno jako samostatné (stand-alone) řešení pro uspokojení potřeb z oblasti Document Management pro menší či střední organizace.

Národní standard pro eSSL - 3.část: Metadata

V dnešní části seriálu na téma Národní standard se budeme věnovat metadatům. Po zkušenostech z minulého týdne se raději vystříhám užití tabulek (opravdu to v editoru vypadá jinak).

Zatímco první dvě části je v dokumentu poměrně snadné identifikovat, najít kompletní přehled metadat je možné jedině v přílohách (příloha 1.1, příloha 1.2, XML schéma - příloha 2.) Po pravdě řečeno, ani to není příliš velká pomoc - přílohy 1.1 a 1.2 jsou psány rekurzivním způsobem a příloha 2. jako předpis XML schématu. Bylo by zajímavé změřit, kolik by autorům trvalo odpovědět na otázku: která jsou povinná metadata objektu Dokument?

Nicméně, metadata jde v zásadě rozdělit do několika kategorií:

• identifikační či popisná: např. jednoznačný identifikátor, název, popis, klíčová slova (vybraná ze slovníku) ad.
  
• data: datum vytvoření, otevření, uzavření, vyřazení apod.
• oběh dokumentu/zabezpečení: osoba či oddělení přidelení pro vyřízení, typ dokumentu ad.
  
• specializovaná metadata pro spisovou službu: skartační režim (skartační lhůta), spisový a skartační znak, číslo jednací ad.
  
• metadata specifická pro konkrétní oblast: např. id datové schránky, id odeslané datové zprávy (pro položky vyměňované přes datové schránky), email, CC, předmět (pro emaily), id uživatele, id skenovací sady, počet snímků (pro dokumenty získané skenováním) ad.
• flagy: nastavení možnosti vytvářet ve spisech součásti nebo díly, označení dokumentu za "nezbytný" ad.

Největší pozornost si asi zasluhují metadata zmíněná v sekci specializovaná metadata pro spisovou službu:
Skartační režim - na úrovni věcné skupiny, spisu či dokumentu se jedná o přiřazená metadata; skartační režimy jsou však i objekty definované v rámci ERMS. Jejich rolí je na základě pravidel stanovených zákony či interními procedurami organizace zaručit, že a) nedojde ke smazání položek, u nichž to není možné (např. faktury před uplynutím 10leté skartační lhůty) b) po uplynutí skartační lhůty poslat příslušné dokumenty do skartačního řízení.
Skartační režim rovněž definuje skartační lhůtu - každé položce však může být přiřazeno více režimů (např. dokument může mít obecný skartační režim pro finanční dokumenty, protože se však jedná o fakturu od klíčového zákazníka, může mít nastavena i speciílní pravidla), minimálně však vždy musí být přiřazen alespoň jeden. Případné konflikty pak řeší příslušná správcovská role.
Skartační znak - je položka, jejíž hodnoty jsou dokonce zmíněny už na úrovni zákona 499/2004 Sb. - může mít hodnoty "V" (výběr), "S" (stoupa), "A" (archivováno - u nás do národního archívu).
Číslo jednací, Spisový znak - jedná se vlastně o identifikační metadata, která však mají poměrně úzce specializovaný proces generování - např. číslo jednací je složeno z pořadového čísla dokumentu, roku a kódu organizace či útvaru.

V poslední části, kterou vzhledem k rozsáhlosti tématu bude možná nutné rozdělit do více článků, bychom se ještě podívali na operace, které národní standard vyžaduje podporovat. Vzhledem k mé dovolené si dovolím na příští týden publikovat článek na jiné téma a k národnímu standardu se pak vrátíme, jakmile to časové možnosti dovolí.

Národní standard pro eSSL - 2.část: Zabezpečení

V druhé části se budeme zabývat zabezpečením, tj. zejména rolemi, které definují oprávnění přístupu k obsahu, resp. oprávnění provádět operace. Tato problematika je do jisté míry samopopisná a vychází z tabulky:

Funkce	Role
	uživatelské	správcovské
	Běžný uživatel	Posuzovatel skartačních operací	Místní správce	Ústřední správce
Tvořit nové spisy	Ano	Ne	Ne	Ne
Přijímat dokumenty	Ano	Ne	Ne	Ne
Přetřídit dokument do seskupení	Ano	Ano	Ano	Ano
Vyhledávat a číst dokumenty	Ano	Ano	Ano	Ano
Měnit metadata spisu	Ne	Ano	Ano	Ano
Udržovat spisový plán	Ne	Ano	Ano	Ano
Smazat spisy	Ne	Ano	Ano	Ano
Měnit metadata dokumentů	Ne	Ano	Ano	Ano
Smazat dokumenty	Ne	Ano	Ano	Ano
Zavést nebo odstranit pozastavení skartační operace	Ne	Ano	Ano	Ano
Exportovat a importovat seskupení a dokumenty	Ne	Ano	Ano	Ano
Prohlížet transakční protokoly	Ne	Ano	Ano	Ano
Přidělovat vlastní přístupová práva jiným uživatelům	Ne	Ano	Ano	Ano
Definovat a prohlížet systémové zprávy	Ne	Ano	Ano	Ano
Změna skartačního režimu	Ne	Ano	Ne	Ne
Zničení nebo přenos dokumentu nebo seskupení	Ne	Ano	Ne	Ne
Přidávat nové věcné skupiny	Ne	Ne	Ano	Ano
Přesunout data transakčního protokolu do off-line paměťových médií	Ne	Ne	Ano	Ano
Provádět všechny operace související s uživateli a jejich přístupovými právy	Ne	Ne	Ano	Ano
Konfigurovat a spravovat transakční protokol	Ne	Ne	Ne	Ano
Přidělovat přístupová práva místním správcům	Ne	Ne	Ne	Ano
Zřizovat a spravovat role pro správu typových spisů	Ne	Ne	Ne	Ano
Udržovat systémové parametry	Ne	Ne	Ne	Ano
Měnit obsah dokumentů	Ne	Ne	Ne	Ne
Měnit údaje transakčního protokolu	Ne	Ne	Ne	Ne

Z tabulky snad jen zdůrazněme pokus o oddělení práce s přípravou obsahu (tvorba spisů, možnost přijímat dokumenty "na sebe") od administrátorských úloh - stejně tak některé specifické úkony (např. změna skartačního režimu) jsou k dispozici jen specifické administrátorské roli.
Z tabulky lze však rovněž získat i poměrně zevrubný přehled, jaké operace by měl ERMS podporovat. K tomu se vrátímě někdy příště.

Národní standard pro eSSL - 1.část: Uspořádání dokumentů

V dnešním článku se budeme věnovat dlouho avizovanému tématu, a to návrhu Národního standardu pro elektronické spisové služby tak, jak je dnes k dispozici. Protože se jedná o rozsáhlé téma, bude třeba jej rozdělit na několik částí. V této začneme od uspořádání dokumentů uvnitř systému ERMS.
Uspořádání vychází z tohoto schématu:

Pokud by tento obrázek byl pro Vás nepochopitelný, nabídnu ještě jeden, který sice neobsahuje všechny detaily, ale za to je naprosto jasný:

Začněme úplně na nejnižší úrovni: dokument se může skládat z jedné či několika komponent, tj. několika souborů. Ideou, která je za tímto požadavkem je práce s emaily, které mohou mít více příloh (každá příloha bude komponentou). Podobně může vypadat zpráva poslaná přes datové schránky. Přesto, z pohledu mnoha operací je nejmenší jednotkou dokument a od dalšího dělení můžeme abstrahovat.
Pokud bychom přeskočili na úplně opačný konec, systém ERMS musí umožňovat definici a spravování několika spisových plánů. Ty se pak dále dělí na věcné skupiny a spisy, přičemž v jedné věcné skupině mohou být pouze věcné skupiny nebo pouze spisy a členění věcných skupin musí být umožněno alespoň na 3 úrovně; počet hierarchií spisového plánu pak nesmí být vůbec omezen.
K čemu slouží takovéto dělení? Jednak vychází ze zvyklostí. Z hlediska elektronického zpracování však podporují dvě základní vlastnosti:

• dědičnost - např. při změně metadat (např. spisový znak) je změna na vyšší úrovni automaticky propagována do všech nižších úrovní; podobně je možné od nějaké úrovně dolů vše uzavřít, tj. zakázat přidávání dalších dokumentů, změny metadat apod.
  
• hromadné operace - např. import či export celé věcné skupiny

Od úrovně spisu je možné přiřadit velmi specifický parametr ERMS, a to skartační režim. Detailně se mu budeme věnovat někdy příště, ale toto je parametr, který se stará o to, aby položku nebylo možné smazat před uplynutím skartační lhůty a naopak, aby po jejím uplynutí položka automaticky vstoupila do skartačního workflow.
Na úrovni uprostřed schématu je pak ještě možné spis dále dělit na (volitelné) součásti a díly. Jejich specifikum spočívá v tom, že v jedné otevřené součásti může být jen jeden otevřený díl, tj. díl do kterého je možné přidávat další dokumenty, či měnit metadata.

Oracle UCM se umístil mezi leadery v gartnerovském magickém kvadrantu pro WCM na rok 2009

Původně jsem plánoval, že se tento týden vrátíme k návrhu Národního stadardu pro eSSL, ale vyšla zpráva, o kterou se jednoduše nemohu nepodělit: Oracle UCM se (opět) umístil mezi leadery v magickém kvadrantu analytické společnosti Gartner pro oblast Web Content Management na rok 2009.

Kompletní správa je k dispozici na tomto linku.


Dovolím si ještě pár komentářů: Oracle se umístil jako nejlépe hodnocená firma v oblasti "ability to execute", což je v podstatě schopnost doručit projekt za domluvených podmínek a ne náhodou souvisí i s počtem dodávaných projektů v daném období.

Naše pozice v oblasti "completeness of vision" může být ovlivněna i tím, že nová verze 11g pro produkt UCM bude uvolněna teprve v druhé polovině tohoto roku. Očekává se zejména mnohem větší provázání s portálovými řešeními - někdy se objevuje termín Open WCM, tj. schopnost provádět úpravu webového obsahu, např. tak, jak jsme je viděli v ukázkách v článku z 29.7.2009, a to v plně personalizovaném portálovém prostředí. Uvidíme ale, co se nakonec do 11g podaří vše dostat.

Mezi silnými stránkami je zmiňován i "recommendation engine" a CRM. To druhé asi představovat není třeba, ale první termín může být relativně neznámý. Jedná se o produkt Real-Time Decision Maker (RTD). Spolupráce s WCM (a CRM na druhé straně) se týká především toho, že RTD sleduje chování koncových uživatelů a dokáže-li uživatele nějakým způsobem autentikovat (ať už přímo jeho identitu, nebo "příslušnost ke skupině"), může patřičně změnit obsah i formu stránek. Nejčastěji se mění nabízené inzeráty (na produkty či služby). Pravidla mohou být buď přímo řízena (např. odd. marketingu) nebo mohou být i samoučící (znáte např. z amazon.com, kdy se zobrazují sekce "Frequently Bought Together" a "Customer Who Bought This Item Also Bought"). Obávám se ale, že u nás zatím o podobné řešení moc zájem nebude - souvisí to zejména se stavem využívání CRM systémů obecně.

Výtka vůči cenám licencí Oracle v porovnání s cenami konkurence trošku srovnává hrušky s jablky - existuje řada řešení, např. RedDot, nedávno koupený OpenTextem, která neumí nic jiného, než WCM, a je jasné, že už jen z tohoto titulu budou levnější. Samozřejmě, nepožaduje-li zákazník nic jiného navíc, a to ani v blízké budoucnosti (tak s výhledem na 5 let), nemá mu asi smysl naše řešení nabízet. Na druhé straně, s Oracle UCM dostane v ceně vlastně všechny komponenty ECM řešení - Document Management, WCM, Digital Asset Management, Records Management, ad., a to za jednu cenu. Při implementaci dalších modulů se už využívá centrální komponenta UCM, Content Server a navazuje se na běžné nutné administrátorské úkony (zálohování, mazání nepotřebného obsahu atd.) a navíc na rozdíl od řady dalších dodavatelů není nutné jednotlivé moduly spolu integrovat, takže v celku může vyjít cena řešení výrazně méně. Je ovšem zřejmé, že tento koncept musí nejprve zákazníkům někdo představit a také, že určitě budou existovat organizace, které se v něm nenajdou.

S odkazem na budoucí vývoj budiž řečeno, že už nyní existuje suite, která obsahuje licence jak na Web Center, tak na Oracle UCM.

Kde mohu najít další informace?

V souvislosti s konáním Webcastu minulý týden (mimochodem, pokud jste jej nestihli a měli byste o obsah zájem, celý záznam je k dispozici na stejném linku v sekci Recorded Events) mě napadlo věnovat článek tento týden přehledu míst, kde je možné získat další informace.

Především je to tento blog a česká E2.0 wiki, na které budeme postupně doplňovat články "trvalejšího" charaketru (how-to's, knowledge base). Pokud Vám nějaké informace zásadně chybí, pošlete mi email a já se to v rámci časových možností zkusím napravit.

Pokud máte zájem o informace z Product Managementu, pořádají se pravidelné čtvrtletní webcasty. Jejich aktualizovaný přehled by měl být na tomto linku (ten poslední tam ale není, tak nevím - raději o něm budu informovat také).

Pokud byste potřebovali pomoci s nějakým technickým problémem či potřebovali radu a nezdálo by se Vám možné použít Metalink, doporučuji 2 diskuzní fóra:

• fórum provozované Oraclem
• veřejné fórum na yahoo

Pro úplnost uvedu ještě některé knihy, které jsou v blízkém vztahu k technologiím Oracle v oblasti E2.0, ale zároveň přinášejí i obecné koncepty pro řešení v dané oblasti, které jsou vlastně technologicky naprosto nezávislé:

• Reshaping Your Business with Web 2.0
• Transforming Infoglut! A Pragmatic Strategy for Oracle Enterprise Content Management (metodika pro projekty)
  
• The Definitive Guide to Stellent Content Server Development (bible pro vývojáře)
• Content Management Bible (již trochu starší - z r.2002 - jniha o konceptech)