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