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