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

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

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

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

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