Wednesday 22 December 2010

Web Center - Patch Set 3

Začátkem prosince zorganizoval product management (PM) několik akcí na téma Patch Set 3 pro Web Center. Původně měl být tou dobou již k dispozici ke stažení; současný očekávaný termín je někdy v lednu - únoru.

Z prezentací a živých ukázek se zdá, že tento Patch Set, který ve skutečnosti dodává řadu nových funkcí, bude z pohledu produktu Web Center poměrně zásadní událostí.

Asi nejzásadnější novinkou je tzv. Web Center Portal, který do značné míry vychází a nahrazuje zavedený Weblogic Portal. Jak tomuto produktu rozumět? Při vytváření portálových aplikací je možné portál "spíše konfigurovat" (tj. hlavní podíl na jeho tvorbě mají business uživatelé - na tyto potřeby odpovídají Web Center Spaces) a nebo "spíše programovat"; a přesně k tomuto účelu slouží Web Center Portal. PM dokonce slibuje, že na základě prvních výkonostních testů by tento produkt mohl dosahovat ještě lepších výsledků, než Weblogic Portal, který je jinak prý držitelem všech světových rekordů při spracování transakcí zadávaných přes web. Tak uvidíme...

PS3 také jako první nabízí plnou integraci s Oracle UCM, zejména pak možnost využít funkce UCM 11g, jako je Site Studio for External Applications. Fakticky to znamená, že stránky tvořené čistě na základě obsahu (uloženého samozřejmě v UCM) jsou konstruovány prostředky UCM, ale zobrazovány v rámci portálu. Jakkoliv bylo možné tohoto efektu dosáhnout i v dřívějších verzích, nyní je vše možné zprovoznit doslova během pár kliknutí myší.

Z nových funkcionalit pak stojí za zmínku:
  • Personalization Engine, který v rámci Web Centra umožňuje definovat pravidly řízené úpravy do obsahu stránky (např. bannery na základě údajů známých o přihlášené osobě)
  • Business Users Mashups, což představuje mechanismus Data Control - Custom Visualizations - Reusable Mashups - Business Dictionary, tedy možnost portletizovat nejrůznější data z aplikací, dokonce je dávat k dispozici jako zdroje pro stránky ostatních uživatelů. Vzhledem ke konceptu Fusion Applications je již dnes možné získat řadu (otestovaných a podporovaných) data controls zejména nad Oracle Applications.
  • zjednodušení správy stránek a dalších zdrojů a distribuovaná zodpovědnost (nominování správce odpovědného za určitou oblast)
Tolik aspoň k tomu nejdůležitějšímu.

Wednesday 15 December 2010

Deployment aplikace Site Studio for External Applications

Vraťme se naposledy k problematice WCM v releasu 11g. V minulých článcích jsme si postupně představili základní koncepty a změny oproti 10g (užití JSP a Jdeveloperu jako IDE). Jak se ale bude chovat aplikace v produkčním prostředí?

Odpověď je, možná, nepřekvapující: jako J2EE aplikace

Aplikace se na aplikační server dodává v .EAR souboru, který má tuto strukturu:

+ -- My Application.ear
+ -- MySites.war
+ -- adf/META-INF/
+ -- connections.xml
+ -- META-INF/
+ application.xml
+ weblogic-application.xml


MySites.war obsahuje reference na jeden content server a sites (které jsou uloženy na něm jako obsahové položky, tj. soubory .xml; jinak je najdete podle kritéria "WebSiteObject matches Project")
connections.xml obsahuje odkaz na URL Content Serveru, který obsahuje užité položky obsahu (dokumenty, obrázky, multimédia); bez autentizace je možné přistupovat jen na položky z bezp. skupiny 'Public', které jsou navíc přiřazeny danému site (při výběrech)
weblogic-application.xml obsahuje odkazy na sdílené knihovny Site Studia (a RIDC) na daném Weblogic serveru

Soubor MySites.war má pak tuto strukturu:

+ -- MySites.war
+ -- wcm/templates/
+ -- WEB-INF/
+ web.xml
+ wcm-config.xml
+ weblogic.xml

/templates/ je adresář obsahující všechny JSP/JSPX registrované ve wcm-config.xml
wcm-config.xml je hlavní konfigurační soubor pro Site Studio
weblogic.xml obsahuje reference na sdílené WAR knihovny Site Studia
web.xml je standardní konfigurační soubor pro J2EE aplikace

Jak je vidět z popisu, v architektuře existují 2 servery, aplikační server, který provozuje WCM aplikaci (a má k dispozici některé knihovny) a UCM server, který slouží čistě jako poskytovatel obsahu. I toto je vlastně změna oproti 10g, kdy se UCM server "staral o všechno". Bohužel, i kdyby se jednalo o skutečně dva různé servery, neplatí, že na provozním aplikačním serveru nemusí být licence UCM - vzhledem k instalaci knihoven musí být i tento server licencován pro UCM. Na druhé straně je ale možné využít mechanismus cachování obsahu na provozním aplikačním serveru, čímž je možné dále optimalizovat jak rychlost odezvy, tak zátěž poskytovatele obsahu.
A stále pak existuje možnost vypublikovat statické stránky (což se často využívá u internetových stránek, kde žádná autorizace uživatele pro přístup k dalším sekcím nedává smysl) na web server, kde samozřejmě žádné licence potřeba nejsou.

Wednesday 8 December 2010

Microsoft Sharepoint 2010 - opravdu je to tak levné řešení?

Jak jsme informovali před dvěma týdny, první místo v parametru Ability to Execute v gartnerovském magickém kvadrantu pro oblast ECM přenechala IBM Microsoftu, a to konkrétně produktu Microsoft Sharepoint (dále SP 2010). Tento produkt skutečně zaznamenává na trhu značný úspěch a dokonce už jej provází nimbus "ne snad tak robustního, ale levného řešení".

Osobně mám přinejmenším jednu zkušenost, kdy byl zákazník nucen poměrně brzy vystřízlivět. Jak to tedy vlastně je?

SharePoint se dodává ve třech různých verzích: "zadarmo" (Foundation), Standard a Enterprise

Pro všechny verze SP 2010 je předpokladem 64bitová verze Windows Serveru 2008 (či novějšího) a MS SQL 2005 (či novější). Pro klientskou stranu jsou třeba Windows Server CAL (Client Access License), ale především pak poslední verze MS Office 2010 (Standard či ProPlus). Především poslední fakt je pro řadu zákazníků jisté nemilé překvapení a oblíbená argumentace Microsoftu je prý, že k upgradu by stejně dříve nebo později došlo.
Jakmile si uživatelé na produkt "zadarmo" zvyknou, zjistí, že potřebují k jeho užívání další licence. Microsoft opět tvrdí (to jsem slyšel, možná v trochu parafrázované verzi, na vlastní uši): "pro většinu zákazníků stačí verze Standard a pro ty opravdu velké máme verzi Enterprise", což znamená serverové licence SP 2010 pro všechny (!) servery, které jsou součástí architektury (může jich být více: web server, app server, crawl/index server) a SP Standard nebo Enterprise CAL pro klientské stanice (vč. nutných předpokladů zmíněných výše).
Verze Standard obsahuje funkční moduly Portal, Doc/Rec. Mgmt, Social Computing, ECM/WCM, Enterprise Search a Legal Holds.
Verze Enterprise však začne být nutná:
  • pokud chce zákazník využívat SP i mimo svoji organizaci - chcete-li, pro scénáře typu "extranet"; zde se navíc najednou objeví potřeba zakoupit i další licenci, tzv. SharePoint Server 2010 for Internet Sites, jehož ceníková cena je více než $40K
  • pokud začne být položek hodně (stovky miliónů) - pak se nabízí FAST Search Server
  • pokud chce zákazník využívat BI či Business Applications Integration (pilíř PerformancePoint Services, který je součástí pouze Enterprise licence)
Pokud umíte číst mezi řádky, pak už je vám asi jasný postup: začít relativně "s ničím" a postupně utahovat šrouby. Navíc zástupci tohoto přístupu jsou koncoví uživatelé, kteří vždy jakoby dostávájí "latest and greatest". Což neznamená, že pro spoustu organizací to stále nemusí být optimální varianta. Pokud už však má vaše organizace/obsluhovaná komunita (pozor na "extranet") několik set hlav, doporučuji si udělat výhled tak na 3-5 let dopředu. Možná už vám pak SP 2010 řešení zas tak levné připadat nebude. Jinak ale klobouk dolů před tím, kdo tuto strategii vymýšlel.

Wednesday 1 December 2010

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

Schéma "prostřední" části definice stránky, tj. placeholderů a regionů, je opět nejlépe možné pochopit ze schématu:

Pokud budeme prozatím ignorovat nejnižší vrstvu, tj. elementy, a ponecháme stranou i subtemplates, zbydou nám 4 vzájemně úzce spojené objekty. Přibližme si je nejprve opět pomocí dalšího schématu:


Nejjednodušším objektem je placeholder. Vytváří se na úrovni stránky (tj. její šablony) buď přetažením příslušné ikony do designu stránky, nebo přidáním takovéhoto kódu:
Ke každému placeholderu musí existovat tři další objekty. Jeden, placeholder definition, určuje, jaké operace bude možné s daným placeholderem v přispěvovatelském módu provádět:


Druhým je pak Region Definition, která definuje "obsah" příslušného regionu - v našem příkladě z druhého obrázku má region 5 oblastí: Title, Subtitle, Intro Text, Body Text a Image. Na následujícím obrázku bude příklad regionu se dvěma oblastmi (elementy).


Aby to celé mohlo fungovat, je ještě nezbytné, aby bylo určeno, které oblasti regionu a v jaké podobě budou uživateli zobrazeny. K tomu pak slouží poslední objekt, Region Template, což je opět JSP definující podobu výstupu (při jeho definici je možné použít subtemplates, které opět mohou obsahovat další placeholdery).

Jak je také vidět z druhého obrázku, je teoreticky možné, že by k jedné existovalo více zobrazovacích šablon. V rámci definice definici placeholderu se pak určuje, která z nich se v dané situaci použije.

Poslední nutný link, mezi placeholderem a jeho definicí, se poněkud nelogicky provádí na úrovni site (tam, kde se příslušným stránkám přiřazují jejich primární a sekundární šablony), a to pomocí tlačítka s názvem Placeholder Definition Mappings.

Pro srovnání: dříve se v aplikaci SiteStudio prováděly všechny tyto operace na jednom místě. To je zřejmě daň za rozdělení formy (JSP) a pravidel chování/mapování mezi objekty (což je v podstatě XML).

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

Wednesday 24 November 2010

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.

Wednesday 17 November 2010

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ě)

Wednesday 10 November 2010

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)

Thursday 4 November 2010

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

Wednesday 3 November 2010

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).

Wednesday 27 October 2010

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.

Wednesday 20 October 2010

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.

Wednesday 13 October 2010

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.

Wednesday 6 October 2010

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ě)

Wednesday 29 September 2010

Uživatelské účty a role v UCM

V poslední době se objevilo několik otázek na téma uživatelských účtů (v UCM 11g manuálu je užit termín "login") a rolí. Jak jsme psali v tomto článku, je mezi verzemi 10g a 11g určitý rozdíl. Pojďme se však na celou problematiku podívat detailně.

Typově nejstarší jsou tzv. lokální uživatelé. Jedná se o uživatele definované v interní databázi content serveru (tabulka Users) a k jejich správě se užívá administrátorský applet UserAdmin.
Ve stejné aplikaci jsou pak vytvářeny, administrovány (tabulka RoleDefinition) a přiřazovány (tabulka UserSecurityAttributes) jejich role. Vztah mezi uživateli, rolemi a metadaty dokumentů je vysvětlen v tomto článku.
Pro každého nově vytvořeného uživatele se automaticky přiřazuje role guest, která jej opravňuje ke čtení veřejných dokumentů (tj. těch klasifikovaných do bezpečnostní skupiny Public).

Obdobou lokálních jsou tzv. globální uživatelé. Liší se pouze tím, že globální uživatelé slouží k přístupu na několik content serverů najednou - což se velmi často využívá (či spíše využívalo) při clusterovém řešení. Pro globální uživatele je vždy jeden server 'master' a ostatní si identitu uživatelů přebírají z něj.

Naopak poslední typ, tj. externí uživatelé, se plně přebírá odjinud - možnostmi jsou Windows Doména, Active Directory či LDAP Server. Jakkoli se data o externích uživatelích ukládají do databáze, samotného uživatele a jak nedávno všiml jeden z partnerů (podobně jako autor této otázky na fóru Oracle UCM) přiřazení rolí takovýmto uživatelům není možné v rámci appletu UserAdmin administrovat.

Ještě k vzájemnému vztahu obou světů: při autentikaci uživatele se nejprve prověřují externí a teprve následně lokální či globální uživatelé. Externí uživatelé tedy "mají přednost".

Nyní, vše výše uvedené platí pro svět 10g. V 11g se pracuje prakticky výhradně s externími uživateli. Release sice stále obsahuje UserAdmin a jednoho definovaného lokálního uživatele, ten je však využit výhradně pro přihlášení k administrátorským aplikacím jako SystemProperties ve stand-alone módu.

Dalším rozdílem oproti 10g je, že 11g běží na WebLogic Serveru (WLS), který obsahuje tzv. Embedded LDAP Server (více na toto téma zde), který je alternativně možné využít pro menší instalace (uvádí se do 10 000 uživatelských účtů). Tento server se spravuje pomocí administrátorské konzole Enterprise Manager for FMW Control. V případě využití jiného LDAP serveru se pak doporučuje integrovat LDAP spíše na úrovni WLS než UCM - důvody jsou jednak výkon, jednak možnost využít uživatelské identity pro ostatní FMW produkty, než jen pro samotné UCM.

Na závěr k využití LDAP ještě poznamenejme, že u tohoto řešení jsou uživatelská hesla mimo UCM a kromě uživatelů a rolí je možné LDAP využít ještě na další objekty - velmi často se z LDAP přebírají účty (bezpečnostní mechanismus mající hierarchickou strukturu často vycházející z hierarchie organizace, popsáno zde).

Wednesday 22 September 2010

Rozšiřitelnost Oracle UCM - využití hierarchických dotazů v databázi

V tomto článku si budeme demonstrovat rozšiřitelnost Oracle UCM na jednom konkrétním problému z reálného života. Jeden potenciální zákazník se na nás obrátil s otázkou, zda UCM umí na úrovni adresářů (komponenta Folders_g) pracovat s kvótami. Ve standardní verzi tato funkcionalita není, jedná se však o poměrně jednoduché rozšíření.

Představme si tedy, že budeme chtít implementovat kontrolu nepřekračování přidělovaných kvót v následujícím schématu:

Problém s kvótami je, že nemusí být přiřazeny pro všechny adresáře - např. kvóta pro společnost A, kterou přiděluje správce úložiště, může být dále rozdělena a i zde mohou existovat adresáře s omezeními kvóty či bez omezení. Tyto "díry" povedou na netriviální rekurzivní dotazy.

Př. 1. vkládání dokumentu do adresáře uživatele 2 se musí nejprve zjistit, zda existuje nějaký adresář (buď adresář sám, nebo některý z jeho předků v hierarchii) s nastavenou kvótou. Kontrola možného překročení kvóty pak bude probíhat na úrovni tohoto adresáře, pokud nějaký takový adresář vůbec existuje.

Př. 2. vlastní výpočet vyčerpané kvóty je rovněž rekurzivní:
  • kvótu mohou vyčerpat soubory vložené do adresáře
  • či podadresáře, přičemž je-li podadresáři přiřazena jeho kvóta, pak se počítá s ní; v opačném případě se opět musí najít soubory a podadresáře do něj vložené
Rekurzivní vazba je daná přímo v databázové tabulce Collections: každý adresář má svůj jednoznačný identifikátor (dCollectionId) a kromě kořenového adresáře též svého přímého předka (dParentCollectionId).

Nalezení prvního adresáře s nenulovou kvótou (Př. 1) může být v databázi Oracle implementováno přímo jako jeden dotaz (stejné je tomu s Př.2):
select DCOLLECTIONQUOTA, DCOLLECTIONID, DCOLLECTIONNAME from COLLECTIONS
where DCOLLECTIONQUOTA > 0
start with DCOLLECTIONID = ?
connect by DCOLLECTIONID = PRIOR DPARENTCOLLECTIONID and DCOLLECTIONQUOTA > 0 and PRIOR DCOLLECTIONQUOTA is null

? v dotazu představuje placeholder pro parametr dCollectionId adresáře, pro který dotaz voláme
O hierarchických dotazech si více přečtěte v článku Davida Krcha zde.

Tento případ hezky demonstruje, že Oracle UCM je skutečně otevřený systém, který dokáže využívat nejlepších vlastností ostatních technologií.

Wednesday 15 September 2010

Workflows, část 3.

Abychom si ukázali nějaké praktické využití, představte si následující situaci:


V prvním kroku dojde k roztřídění došlých zpráv (může se jednat třeba o skeny či datové zprávy) buď automaticky nebo manuálně na oddělení, která mají příslušné zprávy v gesci.

V každém kroku využívejte mnohem spíše skupiny uživatelů (v UCM se jim říká alias), než přímé přiřazení na konkrétní uživatele - přiřazení uživatele do skupiny je možné přebírat přímo z LDAP (např. ActiveDirectory); alias tedy v tomto případě reprezentuje roli v rámci workflow a je mnohem dynamičtější.

Protože se dá předpokládat, že průtok jednotlivými odděleními bude mít také povahu workflow, doporučuji tyto části implementovat jako subworkflow, což je speciální typ kriteriálního workflow, které nemá žádná vstupní kritéria (do se do něj vstoupit výhradně odskokem z jiného workflow).

Odskok z hlavního workflow do subworkflow je možné implementovat jako odskok (jump). V tomto případě je dokonce možné vše "naklikat" - v rámci odskoku si vyberete podmínku (založenou na metadatech) a workflow-krok, na který se má odskočit. Využití subworkflows má navíc tu výhodu, že můžete uchovat návratovou pozici (HasReturn), což zaručí, že po skončení subworkflow se řízení vrátí na správné místo v hlavním workflow - pokud znáte Basic, pak se to velmi podobá mechanismu podprogramů.

Na závěr možná jedno pozorování: nativní workflows v UCM jsou velmi silný mechanismus, byť dnes už se zastaralým GUI pro administraci, který splňuje požadavky pro implementaci oběhu jednoho dokumentu. V okamžiku, kdy potřebujete oběh více dokumentů (např. složka), nikdy se nesnažte synchronizovat workflow nad jednotlivými oddělenými dokumenty. UCM má pro reprezentaci "složky dokumentů" dva základní mechanismy:
  • přílohy (attachments - dodává komponenta ZipRenditionsManager) - zde jsou dokumenty přidány jako přílohy k základní položce, která může vstupovat do workflow; tato vazba je velmi pevná a její nevýhodou může být, že přílohy nemají vlastní metadata, ani je není možné vyhledat při vyhledávání
  • folia (komponenta Folios) - zde je kolem běžných položek vytvořena speciální položka, která se na ně odkazuje. Oběh této speciální položky pak může mít vliv i na odkazované dokumenty. Dokument však může být i ve více foliích - pro složitější vztahy se tento mechanismus může stát nepřehledným
Pro workflow složky pak někdy může být lepší jít "střední cestou" (takovou nabízí např. nepodporovaná komponenta Attachmentor, která vytváří pevnou vazbu rodič-potomek mezi položkami, které však mají vlastní metadata; do workflow může pak vstoupit jen rodičovská položka).

Zakončeme tedy výlet do světa workflow konstatováním, že i kdyby standardní funkcionalita nevyhovovala vašim požadavkům, vždy je možné UCM poměrně snadno upravit., což je beze vší pochyby jedna z jeho velmi silných vlastností.

Wednesday 8 September 2010

Workflows, část 2.

Podívejme se nyní na workflows v rámci Oracle UCM: workflows je v rámci tohoto nástroje možno implementovat dvěma způsoby. První jsou nativní workflows nástroje, které jsou součástí nástroje ještě od dob Stellentu; druhým jsou pak standardní BPEL workflows, která je možné provozovat (nad dokumenty uvnitř UCM) na BPEL Process Manageru v rámci omezené licence, která je součástí licence Oracle UCM. Vývojářským nástrojem pro modelování, psaní a ladění BPEL workflows je JDeveloper (nemáte-li na ně něco jiného).

Důležitá poznámka: tyto způsoby nejsou plně vzájemně nahraditelné. Nativní workflows mají kromě jiného vliv na stav položky - položka je ve stavu Workflow, což mj. znamená, že nemusí dovolovat vkládání nových verzí, nemusí být dostupná uživatelům mimo workflow apod. Naopak, BPEL (resp. BPMN) dovoluje i grafickou reprezentaci workflow. V kombinaci se velmi často využívají tak, že v rámci UCM se vytvoří "staré" jednokrokové workflow, jehož jediným úkolem je předat řízení BPELu a počkat dokud tam vše neskončí.

K BPEL/BPMN, které jsou standardem, nemá smysl nic dodávat. Koho zajímá více, nechť so podívá na některé linky: např. zde či zde.

Pokud jde o nativní workflow, ta jsou navržena výhradně na oběh dokumentů, resp. oběh jednoho dokumentu. Požadavky jsme zmiňovali v předešlém článku.

Workflows jsou v zásadě dvojího druhu:
  • criteria workflows, která se spouští automaticky, pokud byla (mimo workflow) vložena nová verze dokumentu splňujícího daná kritéria; pokud více workflow splňuje stejná kritéria, spouští se první nalezené (což může vést k neočekávaným výsledkům a velmi silně se nedoporučuje)
  • basic či ad hoc workflow, kde naopak uživatel (v UCM v rámci administrace workflows) určuje, které položky by do workflow měly vstoupit
Každé workflow je sekvencí kroků. Každý krok je možné chápat jako unikátní příkaz a sekvence je určena pořadím kroků v rámci definice workflow.
Krok má svůj název, který je možné chápat též jako název stavu položky, uživatelé či skupiny uživatelů (aliasy), kteří dostanou notifikační email, pokud položka vstoupí do tohoto stavu a přechodovou podmínku, což ve své jednoduché podobě bývá minimální počet uživatelů, kteří dají v daném stavu souhlas s předkládaným obsahem. Kromě toho ještě obsahuje krok definici, zda je možné:
  • jen schválit/zamítnout předkládanou verzi
  • vložit novou verzi, přičemž číslo verze zůstává zachováno
  • vložit novou verzi, přičemž číslo verze se zvyšuje
Pokud dojde ke splnění přechodové podmínky, přechází položka do dalšího stavu, či ukončuje se workflow.
Uživatelé workflow dostávají notifikační email, v němž je odkaz do UCM, který zobrazuje webovou reprezentaci dokumentu (pokud ta existuje - pro účely workflows se určitě vyplatí konverze do PDF či jiných web-viewable formátů). V rámci náhledu mohou dále provést zpravidla 2 akce:
  • obsah schválit (Approve)
  • obsah zamítnout (Reject), přičemž, zde je možné zadat důvod odmítnutí
  • pokud systém kromě UCM obsahuje též AutoVue (viz. např. tento článek), má uživatel ještě další možnost, a to kontextově okomentovat (Markup) obsah. Tyto komentáře nejsou součástí položky, proto je možné vkládat i do needitovatelných dokumentů (PDF či formáty vyžadující speciální software)
Pokud byste v rámci workflows potřebovali editovat i metadata, kontaktujte autora článku. Existuje (předem upozorňuji nepodporovaná) komponenta, o které jsme psali v seriálu v březnu, která požadované umí.

Pokud byste od workflow potřebovali něco víc, než sekvenční průchod kroků s předem danými uživateli, musíte se trochu víc seznámit s programováním v jazyce iDocScript či přinejmenším pokročilejší administrací workflows (jumps, tokens).
V každém kroku kromě již zmíněného lze naprogramovat chování tří událostí:
  • Entry: tato událost se vyvolá, pokud položka vstoupí do stavu; velmi často se používá pro poslání emailu o vstupu do stavu i dalším uživatelům, než jen účastníkům workflow (např. autorovi), alternativně je možné ji využít pro okamžitý odskok do jiného stavu, pokud nastanou nějaké speciální podmínky
  • Update: tato událost se vyvolá, buď pokud dojde k nějaké změně (vložení verze či schválení uživatelem), nebo po vypršení pravidelného časového intervalu
  • Exit: tato událost se vyvolá těsně před přechodem do dalšího stavu v případě splnění přechodové podmínky
V případě, že dojde k odmítnutí položky (Reject), nedojde k provedení kódu v Exit události a řízení se vrací do posledního stavu, ve kterém bylo možné vložit novou verzi dokumentu (stavy Review Only jsou v tomto případě "průchozí"). V každém workflow je "nultý" stav, do kterého se vrací položka v případě odmítnutí vrací autorovi. V tomto stavu ji nejde dále zamítnout (musí ji smazat administrátor).

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

Wednesday 1 September 2010

Workflows, část 1.

Poslední dobou se objevilo několik otázek na téma workflow. Protože se problematiku blízkou zde diskutovaným produktům, pokusíme se na něm strávit trochu času.

Především, co to je workflow? Wikipedia jej definuje jako sekvenci vzájemně propojených kroků, které představují zpravidla nějakou práci pro jednotlivce, či skupinu osob. Jakkoli je tato definice přesná, bylo by možná lepší se ptát, co workflow představuje? I na tuto otázku najdeme v referovaném článku odpověď: abstrakci skutečné práce, nebo chcete-li, abstrakci obchodního/pracovního/výrobního procesu...

Jako všechny konceptuální modely se musí workflow vypořádat se dvěma protichůdnými požadavky:
  • obsahovat dostatečnou míru detailu, aby postup podle workflow zaručil kvalitu výsledku
  • neobsahovat zbytečnou míru detailu, aby režie workflow zbytečně neprodražovala celý proces
a to samozřejmě ještě za předpokladů, že
  • kontroly nutné v reálném světě je možné nějak prověřit či zaručit
  • reálný proces je vůbec možné nějak abstrahovat (tj. organizace se vůbec dokáže shodnout na tom, že takto funguje - asi nikoho nepřekvapí, že toto je zpravidla nejtěžší problém)

Abychom se trochu vrátili do našeho světa, není neobvyklé, že obchodní proces či workflow bývá reprezentováno oběhem nějakého dokumentu, ať už skutečného "papíru" či nyní čím dál častěji nějakého jeho elektronické verze.

Pokud se podíváme na to, jaké činnosti se s dokumentem typicky dějí, pak jsou to:
  • pracovník/skupina se seznámí s obsahem dokumentu (máme evidenci, alternativně též v nějaké nezpochybnitelné verzi - podpis)
  • pracovník/skupina vyjádří souhlas s předloženým obsahem (alternativně též s podpisem)
  • pracovník/skupina doplní nějaké informace (obsah - i nový dokument! - i metadata)
  • pracovník/skupina vyjádří nesouhlas s předloženým obsahem (často ve formě nějakých kontextových připomínek, ze kterých nesouhlas vyplývá)
  • pracovník/skupina - na základě výše uvedeného - posune dokument k dalšímu zpracování
  • pro elektronické dokumenty (a v omezené míře i pro listinné) je pak možné ještě reagovat na to, když se s dokumentem dlouho nic neděje, popř. (v integraci s HR či IDM řešeními) hrozí, že se dlouho nic dít nebude (např. dotyčná osoba odchází na dovolenou či onemocní); v tom případě je možné aktivovat nejrůznější eskalační či alternativní větve procesu
(Pokračování někdy příště)

Wednesday 11 August 2010

WebCenter - kompozitní aplikace, 2. část

A jak do toho celého zapadá WebCenter?

Před zodpovězením této otázky je ještě na chvíli zastavme u termínu integrace. Máme-li připravené moduly, propojitelné pomocí otevřených standardů, pořád ještě někdo tyto stavební kostky pospojovat. Zůstanete-li v oraclovském světě, uděláme to za vás, pro některé neoraclovské systémy, se kterými se setkáváme často to uděláme také, pro jiné však budete potřebovat systémového integrátora či pár vlastních architektů a vývojářů.

Pokud bychom šli odspodu, pro kompozitní aplikace může být zajímavá i datová integrace, tj. sloučení mnoho, často heterogenních zdrojů, aby uživatel mohl dostat jednotný pohled na data organizace. To jsme ve světě BI, DWH či data miningu a na toto téma najdete spoustu zajímavého čtení na blogu kolegů.

Další vrstvou integrace je integrace na úrovni aplikací, což dnes zpravidla znamená využití web services, SOAP či XML messages. Pokud se jedná o orchestrované systémy, tady samozřejmě musí přiložit ruku k dílu jejich tvůrci. O backend processing se však už dokáží postarat komponenty middleware (u Oracle to je Oracle BPEL Process Manager). Kromě backendu je však potřeba občas interagovat i s uživatelem - a to je přesně místo pro WebCenter. Tím, že součástí licence WebCenter Suite je limitovaná licence BPEL PM, jsou v rámci WebCentra dodávány i hotové komponenty pro tzv. "human workflows", tj. pracovní seznamy apod.

Poslední vrstvou, kdy je možné integraci provést, je prezentační vrstva. Zde může WebCenter přispět dvěma způsoby:
1. pro již hotové aplikace je možné využít produkt Ensemble, který umí na úrovni proxy "smíchat" výstupy z několika výstupu (mashup) a dosáhnout tak efektu kompozitní aplikace tak říkajíc ad-hoc. Tento přístup se dá použít i při přechodu z existujících aplikací na nový framework (umí nejen Java a .NET aplikace, ale i skriptovací jazyky jako Perl či PHP). Jeho evidentním nedostatkem bude výkonnost. Výhodou je naopak to, že "smíchání" může provést zkušenější uživatel - vůbec tedy na něj nepotřebujete vývojáře!
2. pro vytvářené aplikace je možné využít WebCenter Framework a tím připravit aplikaci, aby jak uměla začlenit zdroje třetích stran (portlety či jiné zdroje), ale také aby se sama prakticky bezpracně stala takovýmto zdrojem. Není asi tajemstvím, že tímto způsobem jsou či budou upraveny i aplikace Oracle jako je Siebel, Peoplesoft či EBS. Postranním efektem je pak obohacení těchto aplikací o Web2.0 funkce jako je tagging, diskuze, online messaging apod.

Základní myšlenkou kompozitních aplikací je poskytnout uživatelům takovou funkcionalitu, jakou měli či mají ERP systémy, ale při zachování uživatelského komfortu a flexibility, na kterou jsou uživatelé zvyklí z portálových řešení a WebCenter je produkt, který pro tento požadavek nabízí unikátní výhody.

Tím, že odjíždím na dovolenou, se s Vámi až do září loučím. Užijte si konec prázdnin.

Wednesday 4 August 2010

Změny v licenční politice E2.0 produktů verze 11g

2. srpna byla konečně dořešena otázka licencování aplikačního serveru WebLogic pro E2.0 produkty. Jelikož jsou všechny produkty verze 11g instalovány jako J2EE aplikace na WebLogic server, byla dlouho ve vzduchu otázka, zda bude nezbytné licencovat aplikační server odděleně, či zda bude (podobně jako u IDM produktů) součástí licence na "hlavní produkt" i omezená licence na aplikační server.

Hlavní zpráva je, že b) je správně, tj. produkty obsahují omezenou licenci i na aplikační server.

V detailu to znamená:
  • UCM Standard Edition obsahuje omezenou licenci Weblogic Server Standard Edition
  • UCM obsahuje omezenou licenci Weblogic Server Enterprise Edition (z důvodu clusterování)
  • URM neobsahuje žádnou omezenou licenci
  • I/PM obsahuje omezenou licenci Weblogic Server Enterprise Edition
  • ECM Suite omezenou licenci Weblogic Server Enterprise Edition
  • WebCenter - nic se nemění, tj. neobsahuje žádnou omezenou licenci
"omezená licence" aplikačního serveru ve výše zmíněném textu znamená možnost provozovat na aplikačním serveru výhradně produkt (-y), které jsou součástí licence.

Wednesday 28 July 2010

WebCenter - kompozitní aplikace, 1. část

Abychom si na chvíli odpočinuli od UCM 11g, pojďme se věnovat jinému produktu, který by v fiskálním roce 2011 mohl mít úspěch - WebCentru.

Jedním z konceptů, na které se tento produkt velmi dobře hodí, jsou tzv. kompozitní aplikace (viz. např. definice na Wikipedii). O co jde? Zejména ve větších organizacích platí, že uživatelé přistupují v rámci svých pracovních povinností ke mnoha systémům. Zpravidla však ne všichni ke všem. Navíc, zde jako nikde jinde v IT může platit, že hodnota celku je výrazně větší než součet jednotlivých komponent.

Samozřejmě, to už tu jednou bylo - a říkalo se tomu Enterprise Resource Planning (ERP), což je termín, který se zdá v současnosti spíše na ústupu ze slávy. Proč?

V jednom speciálním Zverimexu prodávali opice. Opice byly poměrně drahé a tak to jednomu zákazníkovi nedalo a zeptal se, proč jedna opice stojí celých 5000 dolarů. "No tahle umí programovat v jazyce C," dostalo se mu odpovědi od prodavače. "A co umí tahle za 10000?" nedal se odradit zákazník. "No ta umí ještě C++." "A co tahle za 50000?" ptal se s úžasem zákazník. "No, to nevíme, ale říká, že je to konzultant na SAP."

Pokud se to někoho dotýká, nechť si klidně dosadí Oracle EBS či Siebel. V době, kdy jsem vtip poprvé viděl, jsem byl zaměstnán ve Walldorfu, tak mám na tuto verzi morální právo.

Kromě ceny však mají ERP systémy ještě několik dalších problémů, které by se daly shrnout pod termín nedostatek agility, tj. neschopnost dostatečně reagovat na měnící se podmínky či požadavky zákazníků, neschopnost integrace s okolím, pokud někdo jiný nabízí něco zajímavého a pak vysoké nároky na pracovníky obsluhující řešení díky značnému využití proprietárních technologií či know-how.

Jakkoli jistě ani v Oracle není vše ideální, přeci jen byl Larry Ellison jedním z prvních pionýrů, který nastínil nový trend (viz např. Fusion Application).

Kompozitní aplikace stojí na třech pilířích:
  • znovupoužitelnost služeb a zdrojů
  • standardizace
  • de-coupling (což by šlo přeložit jako "rozlámání na menší kousky")
Příkladem znovupoužitelnosti může být například to, co se děje za poslední tři roky s Oracle UCM nebo workflow engine BPEL - prakticky každá aplikace pracuje s dokumenty (např. v Siebelu se tomuto modul říká Siebel Files) či obsahuje nějaké workflow. Pro technologického dodavatele to pak znamená buď udržovat to samé vícekrát (např. v jednom okamžiku prý měl Oracle 17 různých workflows) a nebo v rámci možností říznout do živého a sjednotit požadavky na nějaké jedné platformě. Ani ta druhá cesta není nijak jednoduchá a jen budoucnost ukáže, kdo měl pravdu (první cesty se drží např. IBM).
Pokud jde o standardizaci, to je velmi vstřícný krok směrem k zákazníkům - máte-li již nějaké řešení, které podporuje standardy, nebo zdá-li se vám v nějaké oblasti jiné řešení lákavější, budeme vás rádi podporovat tam, kde si nás vyberete. Pod standardizaci patří hesla jako XML, XSLT, web services, SOAP, UDDI, BPEL, či BPMN, tedy něco, co Oracle podporuje, ale zdaleka nekontroluje.
A de-coupling? Některé v současnosti velmi úspěšné produkty (např. Oracle Business Intelligence SE1 či EE) vznikly odštěpením (zde od balíku Siebel). Ještě zajímavější je tento koncept však z pohledu samotných aplikací, které jsou psány modulárně (např. správa uživatelských účtů se bere skutečně jako nezavislý modul, takže je v zásadě jedno, kdo jej dodává).

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

Wednesday 21 July 2010

Přenositelnost komponent do 11g

Pokud bychom se podívali detailně na problém přenositelnosti komponent speciálně optikou releasu 11g, pak zjistíme přibližně toto:
  • pro Custom Components budete stále využívat Component Wizard nebo link Component Manager v části Admin Server
  • kromě faktu, že komponenty nově běží v prostředí WLS, je třeba se vyrovnat i s jistou "restrukturalizací" instalace. Zatímco dříve byly všechny soubory instalovány (pro jednu instanci content serveru) do jednoho adresáře, v 11g existuje "obecný ECM adresář" (na mé instalaci to bylo C:\Oracle\Middleware\Oracle_ECM1\ucm) a pak jednotlivé adresáře pro instance (např. C:\Oracle\ucm_instances\ecm1\ucm).
  • pokud budete hledat standardní zdroje (např. std_page obsahující většinu includes), určitě je hledejte v "obecném" adresáři. Možná se pak bude hodit i informace, že na rozdíl od starších releasů, kdy byly všechny zdroje v souborech s příponami .htm, maximálně .hda, nyní již tomu tak být nemusí - např. zmíněný soubor std_page má příponu .idoc, zdroje obsahující překlady v komponentě Localization pak příponu .xlf apod.
  • ze změn souvisejících s přechodem na WLS pak připomeňme vše týkající se administrace uživatelů (která je nově zcela v režii WLS)
  • některé komponenty pak byly v 11g zcela přepsány. Jedná se zejména o Folia a FileStoreProvider (komponentu, která má na starosti zápis dokumentů do fyzického úložiště - tyto změny jsou důvodem výrazného zrychlení zápisu na disk či do databáze)
  • kromě celých komponent pak byly ještě přepsány některé jednotlivé služby. Jejich seznam najdete zde.
Vzhledem k projektům implementovaným v České republice věřím, že se tyto změny nikoho nedoktnou. Berte proto prosím tento článek spíše jako dokreslení, jak složité (či jednoduché) může být udržování komponent, o kterém jsme psali minule. Ostatně, dá se očekávat, že při upgrade na 11gR2 už bude komponent, které bude třeba oprášit, více, protože řada implementovaných customizací se týkala GUI, které bude podle všeho značně pozměněno.

Wednesday 14 July 2010

Přenositelnost komponent, možnosti vzájemných kolizí

Pokud se pustíte do vývoje vlastních komponent v UCM, měli byste pamatovat, že tato jistě bohulibá činnost v sobě skrývá 2 úskalí:
  • problém přenositelnosti, tj. zajištění, že komponenta fungující ve verzi n bude fungovat i ve verzi n+1
  • problém možného konfliktu mezi komponentami (dvě či více komponent spolu nemohou fungovat najednou na jednom systému)

Konflikty
Jak může dojít ke konfliktu? Nejčastějším důvodem je přepsání standardní služby, které je sice kompatibilní se základním content serverem, ale není kompatibilní s jinou custom service. V 10g byly takovým příkladem modul Records Management a UCM adaptér pro URM - systém tedy mohl buď sám poskytovat records management funkce a nebo mohl být klientem pro URM, nikoliv však obojí najednou. V 11g je tento konflikt již vyřešen (UCM modul byl přepsán tak, že nabízí URM kód).
Mechanismem pro řešení případných konfliktů je loadOrder, což je hodnota, která je povinným parametrem každého zdroje. Content Server nahrává zdroje podle jejich hodnoty loadOrder (vyšší později) - pokud tedy chcete mít jistotu, že bude váš kód užit, nastavte tuto hodnotu na dostatečně vysokou hodnotu (obvykle stačí tak 100).
Dalším pomocníkem může být mechanismus dědičnosti. Byť to není (možná bohužel) nezbytné, jak iDocScript, tak Java umožňují nejen zcela předefinovat chování služby, ale při psaní využít i existující kód, který se tak ve vhodný okamžik převolává. Užitím dědičnosti se výrazně snižuje riziko konfliktů i podporuje přenositelnost.

Přenositelnost
U nekonfliktních komponent je riziko problémů při migraci na další verzi minimální. Přesto existuje a občas bude třeba do kódu sáhnout. Jedním z takových příkladů byl například přechod z verze 7.5 (ještě Stellent) na 10g (již Oracle), kde došlo k zásahům do GUI (místo combo boxu nabízejícího funkce proveditelné nad položkou byly tyto rozdistribuovány do jakési lišty na hodním menu - starší komponenty, které "natvrdo" přidávaly své funkce na známé místo na to samozřejmě nebyly připraveny).
Tím, že je 11gR1 velmi podobný (snad s výjimkou práce s uživatelskými účty) starší verzi, dá se předpokládat, že by tyto verze neměly mít na úrovni komponent vážné problémy.

Wednesday 7 July 2010

Definování vazeb mezi dokumenty v UCM

Definování vazeb mezi dokumenty je jedním ze základních nároků na každý systém pracující s dokumenty.

Spisy
Po formální stránce jsou v definování vazeb nejdále asi Spisy - tak jak jsou definovány např. v Národním standardu pro spisové služby. Logicky tvoří spis skupinu dokumentů, se kterou se pracuje v jistých operacích (např. uzavírání, přesun, skartace) najednou. Tato problematika je pokryta v UCM modulem Records Management a při popisu spisových služeb jsme se mu věnovali již několikrát.

Méně formální vazby
Pokud bychom nechali ale zákon 499/2004 Sb. stranou, bude pořád stále mnoho případů, kdy je třeba definovat vazbu mezi dokumenty. V UCM vznikla za tímto účelem řada komponent:
  • ZipRenditionManagement - komponenta, která umožní ke každé položce vytvořit tzv. přílohy. Tyto přílohy, kterých může být libovolný počet (byť na vstupní masce je možné najendou jich přidat jen maximálně 5), nemají vlastní metadata a jsou zcela závislé na své mateřské položce.

    Př. užití: jakákoliv položka ve workflow, ke které jsou přikládány dodatečné informace (třeba i naskenované), které se primárně užity právě pro rozhodování ve workflow, či nesou historii.

  • RelatedContent - tato komponenta naopak umožňuje vytvořit naprosto volné vazby mezi jakýmikoliv existujícími nezávislými položkami. Komponenta umí vytvářet vztahy typu: rodič - potomek či sourozenecké (peer-to-peer)

    Př. užití: informační vazby, rejstříky - bohužel se jedná o vazbu na úrovni metadat

  • Folios - stojí někde uprostřed mezi dvěma výše zmíněnými způsoby. Položky ve Fóliu jsou na jednu stranu nezávislé (např. vstoupí-li do workflow Folio, neznamená to automaticky, že by do workflow vstoupila sama položka - uvědomme si navíc, že položka může být najednou ve více fóliích), na druhou stranu Fólio umožňuje vytvořit strukturovaný vztah mezi svými položkami

    Př. užití: dokumentace pro výběrové řízení, které musí mít určité povinné položky
    Př. užití 2: Fólio je možné využít i na koncept tzv. kompozitního dokumentu, kdy na jednom dokumentu (např. knize) pracuje najednou více autorů, kteří se tak navzájem neblokují v práci (každý na své kapitole). Fólio mj. podporuje funkci "zobraz jako celek".

Wednesday 30 June 2010

UCM 11g, 3. část: Změny v GUI

Pokud se poprvé přihlásíte do webového rozhraní UCM 11g, zjistíte - že je skoro stejné jako UCM 10g. To je na jednu stranu dobře, protože není problém se v něm okamžitě vyznat - na druhou stranu by člověk po 3 letech přeci jen čekal nějaký posun. Release 11gR1 tyto změny bohužel nepřináší (na rozdíl např. od I/PM 11g) a budeme si na ně muset počkat nejméně do 11gR2. Ono je to ale na druhou stranu pochopitelné - UCM se čím dál víc posouvá do pozice backend systému a zejména díky produktu WebCenter, s nímž je velmi úzce spojeno, pak potřeby na úpravy GUI jsou potlačeny do pozadí.

Release 11gR1 přesto přináší změny v GUI, a to tam, kde se nejvíce dostává do kontaktu s koncovými uživateli - v komponentě Desktop Integration Suite (která se stará o přístup do úložiště z desktop aplikací jako jsou aplikace balíku MS Office, ale také např. z Lotus Notes či Windows Exploreru). Zásadní novinkou je možnost přímo z těchto aplikací vkládat dokumenty s pomocí profilů:

Dřívější způsob, tj. vydefinovat metadata na úrovni adresáře a vložit dokument "bez ohledu na metadata" zůstal zachován, takže je opravdu jen a jen na uživateli, který způsob mu bude bližší.
Kromě této změny upravuje Desktop Integration Suite ještě rozhraní pro Windows Explorer, a to tak, že umožňuje přímý přístup na položky ve workflow resp. na vložené dotazy - jinými slovy nabízí základní vyhledávání a práci s workflows přímo z Exploreru.

Další skupinou, kterou 11gR1 potěší, jsou administrátoři. V čem se produkt výrazně posunul, že místo nastavení rozmístěných na zanořených stránkách, nabízí jakési "standardní konfigurace", které může administrátor jednoduše zapnout a o víc se nestarat. Jako příklad si uveďme Records Management nebo komponenty - u těch navíc platí, že všechny komponenty podporované Oraclem jsou automaticky nainstalovány a administrátor jen řekne, o které případně má či nemá zájem. Pro custom komponenty je stále možné využít Component Wizard.

Wednesday 23 June 2010

UCM 11g, 2. část: škálování a výkon

Minulý článek jsme zakončili tvrzením, že jedním z největším přínosů verze 11g je velký posun ve výkonu a možnostech škálování celého řešení.

Co se tím přesně míní? Pro výkon ECM řešení jsou důležité především 2 operace:
  • vkládání nového obsahu
  • schopnost zobrazit požadovaný obsah
Při vkládání je výzvou zejména jednorázové vkládání mnoha, relativně krátkých položek, které je třeba stejně rychle dát k dispozici uživatelům (opačný extrém, tj. vkládání velkých položek se moc optimalizovat nedá, protože závisí primárně na průtoku sítě). Typickým případem ze skutečného života může být zpracování emailů či např. vydaných faktur (na toto téma např. tento článek).
Pro poskytování obsahu je náročné zvládnout zejména scénář obsluhy dynamických webových stránek pro velkou komunitu uživatelů (public web).

Detailní výsledky je možné najít v tomto dokumentu a jsou skutečně impozantní. Např. na poměrně běžném hardware (2 CPU 2.33 GHz Xenon, 16 GB RAM) dosahuje UCM 11g pro soubory o velikostech 4-200 kB rychlosti vkládání 270, resp. 128 souborů za sekundu, to je 11-23 miliónů dokumentů denně na jednom uzlu UCM 11g!

Čím jsou takové rychlosti dosahovány? Hlavními přispěvovateli jsou databáze Oracle 11g (zejména technologie Oracle SecureFiles) a pak Fast Checkin mechanismus UCM, který umožňuje některé generické funkce (konverze, zahájení workflow, indexace na fulltextové vyhledávání) vypínat pro ty dokumenty, pro které to nemá smysl - např. TIFF vytvořený skenovací linkou nemá smysl ani konvertovat, ani indexovat.

A pokud by Vám dosahované hodnoty stále nestačily, je možné nasadit Sun Oracle Database Machine (Exadatu), na které je možné se dobrat až takových hodnot jako 1060 dok./sec (91 mil. denně) na 1/4 Exadaty, resp. 2070 dok./sec (179 mil. denně) na 1/2 Exadaty - testy byly prováděny se 100kB soubory.

Při poskytování webového obsahu se plně využívá Weblogic Server. Technologie "Open WCM" využívá tzv. smart caching - tj. webový objekt je z UCM přenesen přímo na Weblogic Server, kde setrvává, dokud jej UCM neprohlásí za neplatný. V jiném modelu je možné proaktivně vyspecifikovat, které objekty se takto mají cachovat přímo v rámci implementace site.
Tyto mechanismy lze ještě doplnit o cachování na proxy, kde se ukládají celé stránky.
V testech se kombinací dosahovalo výsledků až 124 stránek za sekundu (na komoditním hardware).

Při škálování, čímž se zde míní provozování na více uzlech clusteru, je pak žádoucí, aby režie clusteru byla co nejnižší, tj. aby byla investice do dalšího hardware co nejvíce využita. V tomto ohledu dokument příliš specifický není - jen zmiňuje, že UCM 11g dosahuje průměrného poměru kolem 95% (tj. 5% výkonu je spotřebováno režií clusteru). Zde záleží především na výběru operačního systému - pro Windows je režie větší, např. pro 128 uzlů Solaris byla režie jen kolem 2%.

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

Wednesday 16 June 2010

UCM 11g, 1. část: změny v architektuře a jejich dopad

První a velkou změnou v UCM 11g je přebudování celé aplikace tak, že se (na rozdíl od 10g) jedná o J2EE aplikaci. Pro její běh je tudíž třeba aplikační server - v 11gR1 musí být tímto serverem Weblogic Server; v dalších releasech je očekávána i verze pro další aplikační servery (prozatím se mluví o Websphere a JBossu).

Pokud si stáhnete instalační balík na tomto linku a nahlédnete do dokumentace (nejlépe např. Quick Installation Guide), zjistíte, že instalační proces je na první pohled výrazně složitější. Např. datové schéma se vytváří pomocí aplikace RCU (Repository Creation Utility) a vlastní instalace pak jako deployment J2EE aplikace do prostředí Weblogic. Ve skutečnosti však šlo o to, aby se instalace všech produktů z balíku ECM prováděla více-méně stejně, a to i z důvodu následné vzájemné provázanosti těchto produktů mezi sebou, která už je prakticky bez jakéhokoliv dalšího úsilí.

Dalším důsledkem přechodu na Weblogic (resp. aplikační server) jsou dopady na správu uživatelů. Jakkoli stále ještě najdeme v administraci známý User Administration applet, uživatelé zde vytvoření (dříve se nazývali lokální) již nebudou mít do systému právo přístupu. Jedinou výjimkou (kvůli které je ještě tento artefakt zachován) jsou některé standalone aplikace (System Properties, Component Wizard), kam se stále přihlašuje "postaru" - i to ale časem zmizí a pak už všichni uživatelé budou výhradně externí, tj. definováni v LDAP resp. v security realmu aplikačního serveru. Hlavní výhodou je konsolidace správy uživatelů a mnohem lepší podpora standardních mechanismů jako Single Sign-On, správa webových služeb, jejich zabezpečení (standard SAML) apod.

Přechodem na Weblogic pak UCM také automaticky získává silný nástroj pro správu zdrojů, Enterprise Manager, ve kterém je zároveň možné sledovat vytížení, predikovat případné problémy s výkonem či dostupností, konfigurovat recovery management a v neposlední řadě tvořit nejrůznější reporty. Starý nástroj, Admin Server, zůstává (už není třeba jej startovat explicitně od Content Serveru), ale slouží výhradně pro správu UCM-specific úloh (správu komponent, editaci config souborů apod.)

Nejdůležitějším dopadem přechodu na Weblogic jsou však dopady na výkon a potenciál pro škálování celého řešení.

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

Wednesday 9 June 2010

Verze UCM 11g je venku!

Tento týden došlo konečně k uvolnění informačního embarga na oznámení o existenci verze 11g - konkrétně se týká o produkty
  • Universal Content Management
  • Universal Records Management
(pro Imaging and Process Management je verze 11g k dispozici už od začátku kalendářního roku)

Pokud byste měli zájem o informace z první ruky, registrujte se na webcast, který bude zítra 10.6.2010 ve 20 hodin na tomto linku.

Jinak budeme samozřejmě o novinkách spojených s novou verzí informovat na tomto blogu či na lokálně organizovaných akcích.

Novinky z Oracle CZ

Po velmi úspěšném působení Milana Sameše se ujímá vedení české pobočky Oracle Zdeněk Pilz, který donedávna stál v čele české pobočky Sun Microsystems.

S jeho názory se můžete seznámit i v interview nedávno poskytnutém Americké komoře, ze kterého jsou fotografie i video.

Jak možná někteyří vědí, v Oracle začíná v červnu nový fiskální rok, který bude kromě jiného také ve znamení stěhování české pobočky na novou adresu (zatím není definitivně potvrzena), takže se zdá, že se s novinkami skutečně roztrhl pytel.

Wednesday 2 June 2010

Zabezpečení přístupu k dokumentům v Oracle UCM, část 4

4. Stavy položky v UCM
Kromě dříve zmíněných mechanismů může být přístup k položce omezen také díky interní stavové logice (reprezentované interním atributem Status, kterou není možné aktualizovat jako ostatní metadata). V podstatě platí, že není-li položka ve stavu Released, je buď něco špatně a nebo čeká na dokončení nějakého interního tasku.

Které akce mohou měnit stav položky?

a) nastavení ReleaseDate či ExpirationDate - položka je ve stavu Done či Expired a zobrazuje se výhradně v administrátorské aplikaci Repository Manager
b) vstup položky (nové verze položky) do workflow - položka je ve stavu Review resp. Edit resp. Pending a kromě Repository Manageru ji mohou vidět i účastníci workflow, kterým je přiřazena
c) konverze nativního dokumentu do web-viewable formátu (je-li užíváno) - položka je ve stavu GenWWW, tento stav by měl mít krátké trvání
d) smazání položky - položka je ve stavu Deleted

O změně hodnoty stavu položky viz. tento manuál, str. 1-16.

5. Speciální komponenty

Není asi překvapením, že kromě těchto standardních mechanismů existuje i nespočet bezpečnostních mechanismů dodávaných komponentami. Jako příklad uveďme rozšíření vyplývající ze standardní komponenty RecordsManager (DoD Edition) - viz zde. Zde se jedná o tzv. klasifikaci položky ('Důvěrné', 'Tajné', 'Supertajné'). Tato konkrétní implementace je velmi podobná bezpečnostním třídám - kromě nastavení atributu položky je však vyžádováno, aby si položka s sebou nesla i základní informace o klasifikaci resp. deklasifikaci položky; fakticky se tedy jedná o doplnění dalších metadat, které se základním atributem souvisí.
Jiným případem z oblasti RecordsManageru jsou tzv. doplňující označení (supplemental markings). Jedná se opět o textovou klasifikaci položky, na základě je možné přiřadit přístup k položce uživatelům. Na rozdíl od bezpečnostních skupin, či účtů, může být jedné položce přiřazeno více označení a uživatel má přístup k položce jen tehdy, má-li definováno oprávnění ke všem přiřazeným označením.