Použití CASE/CABE pro řízení workflow ve firmě

Transkript

1 Použití CASE/CABE pro řízení workflow ve firmě Autoři: Ondřej Pršala Jan Melichar Miroslav Joha Předmět: 4IT450 Datum: 19. prosince

2 OBSAH Seznam obrázků... 3 Úvod... 4 BPMN - Business Process Modeling Notation... 5 Základní objekty BPMN... 5 Event (Událost)... 5 Activity (Činnost)... 7 Gateway (Rozcestník, Rozhodnutí)... 7 Connectors (Propojení)... 9 Podmínečný Sequence Flow... 9 Default (Výchozí) Sequence Flow Message flow Association (Předávání dat) Organizační objekty Pools Lanes Groups (Skupiny) Další pravidla Subproces Mapování BPMN do BPEL4WS Navazující technologie BPEL (Business Process Execution Language) SOA Architektura orientovaná na služby Webové služby PowerDesigner Vytvoření procesu v PowerDesigneru Zhodnocení nástroje Vygenerování BPEL4WS Struktura BPEL dokumentu Dodatek k vygenerovanému dokumentu UDDI (Universal Description Discovery and Integration) CASE nástroj TeamTrack Automatizace procesů Oblast správy požadavků Upozorňování Znalostní báze Audit Trail automatická tvorba historie Reporting a sestavy Integrace s jinými systémy Novinky TeamTrack verze Referenční model workflow Workflow Proč referenční model? Funkční oblasti Funkce pro návrh Oblast provozní funkcionality Oblast provozních interakcí Referenční model workflow Workflow engine (jádro) Workflow enactment service (WES, běhové prostředí) Process definition tools (nástroje pro definici procesu) Klientské aplikace Rozhraní WAPI Rozhraní mezi WES a nástroji pro definici procesu Rozhraní mezi WES a klientskou aplikací Zdroje

3 Seznam obrázků OBRÁZEK 1 - UDÁLOSTI... 5 OBRÁZEK 2 - TYPY UDÁLOSTÍ... 6 OBRÁZEK 3 - PŘERUŠENÍ ČINNOSTI... 6 OBRÁZEK 4 - RESTART ČINNOSTI... 7 OBRÁZEK 5 ČINNOSTI - TYPY... 7 OBRÁZEK 7 - EXCLUSIVE GATEWAY... 8 OBRÁZEK 8 - INCLUSIVE GATEWAY... 8 OBRÁZEK 9 - PROPOJENÍ (CONNECTORS)... 9 OBRÁZEK 10 - PODMÍNĚNÉ VĚTVENÍ... 9 OBRÁZEK 11 - DEFAULT SEQUENCE FLOW OBRÁZEK 12 - PŘEDÁVÁNÍ ZPRÁV OBRÁZEK 13 - PŘEDÁVÁNÍ DAT OBRÁZEK 14 - DVĚ ALTERNATIVY VYJÁDŘENÍ JEDNÉ SKUTEČNOSTI OBRÁZEK 15 - LANES OBRÁZEK 16 - GROUPS (SESKUPOVÁNÍ) OBRÁZEK 17 - SUB-PROCES OBRÁZEK 18 - MAPOVÁNÍ BPMN DO BPEL4WS...13 OBRÁZEK 19 - SCHÉMA PRÁCE S WEBOVOU SLUŽBOU OBRÁZEK 20 - PROCES OBCHODNÍ PŘÍPAD OBRÁZEK 21 - PROCES V JAZYKU BPEL4WS OBRÁZEK 22 - ARCHITEKTURA APLIKACE TEAMTRACK OBRÁZEK 23 - UKÁZKA NÁVRHU WORKFLOW PROCESU VE WORKFLOW EDITORU OBRÁZEK 24 - UKÁZKA PROJEKTOVÉHO POŽADAVKU OBRÁZEK 25 - UKÁZKA ZADÁNÍ NOVÉ OVÉ NOTIFIKACE OBRÁZEK 26 - REFERENČNÍ MODEL WORKFLOW KOMPONENTY A ROZHRANÍ OBRÁZEK 27 PŘECHODY STAVŮ INSTANCE PROCESU OBRÁZEK 28 SCHÉMA ROZHRANÍ MEZI KLIENTSKOU APLIKACÍ A KOMPONENTOU WES

4 Úvod Text této práce je kompilátem tří témat, kterými bychom rádi obohatili tématiku Použití CASE/CABE pro řízení workflow ve firmě v kontextu předmětu 4IT450. V návaznosti na předchozí dvě práce našich kolegů jsme se rozhodli pro tři okruhy, která předkládáme na následujících stránkách. Jedná se o BPMN (Process Modeling Notation), představení workflow produktu TeamTrack, kterým chceme doplnit seznam produktů představených v předchozích pracích, a téma, které práci zakončuje, je referenční model workflow. 4

5 BPMN - Business Process Modeling Notation BPMN se stává novým standardem pro návrh podnikových procesů. Tato notace je vyvíjena pod záštitou organizace Business Process Management Initiative (BPMI), jejíž hlavním záměrem bylo vyvinout nástroj, který by byl dobře srozumitelný všem. Podnikovým analytikům, který vytvářejí prvotní návrh podnikových procesů i systémovým vývojářům. BPMN taktéž obsahuje vnitřní model, který umožní vygenerování spustitelného kódu jazyka BPEL4WS. Poslední schválená verze notace je z února 2006, která se stává oficiálním standardem OMG (Object management group). Jedná se o určitý kompromis výrobců modelovacích nástrojů využívající nejlepších přístupů a to s jediným cílem, čímž je standardizace. O výhodách standardizace předpokládám nemá cenu hovořit. Při návrhu BPMN byly přezkoumány stávající notace i metodologie - UML Activity Diagram, UML EDOC Business Processes, IDEF, ebxml BPSS, Activity-Decision Flow (ADF) Diagram, RosettaNet, LOVeM, and Event-Process Chains (EPCs). Modelování podnikových procesů v podobě jasného a srozumitelného diagramu slouží hned k několika účelům. Zaprvé se jedná o zmapování a vyjasnění současného stavu podnikových procesů. Zadruhé model slouží jako podklad pro monitoring a následnou inovaci a zkvalitnění podnikových procesů. Zatřetí je model využit při vývoji a integraci softwaru, jež má za úkol podpořit a formalizovat provádění procesů. Tento systém, ve kterém jsou jednotlivé softwarové komponenty propojeny do jednotného konsolidovaného celku se nazývá workflow. Hrubá architektura workflow systému se skládá z výkonného jádra, které řídí tok dat a zpráv mezi aplikacemi, dále z nástrojů pro správu a monitoring, díky nímž lze podnikové procesy sledovat a vyhodnocovat pro potřeby následné optimalizace (čas zpracování, úzké místa, využití zdrojů, přístupová práva, správa instancí procesu atd.). V neposlední řadě jednou z komponent architektury workflow systému jsou nástroje pro definici procesu, které slouží právě k tvorbě modelu procesu pomocí určité notace. A právě notace BPMN se zdá jako nejnadějnější adept pro uplatnění v nástrojích pro návrh workflow. Základní objekty BPMN Notaci BPMN později představím na praktické komplexní ukázce, nicméně neuškodí si již teď představit základní stavební kameny. Při rozboru BPMN notace se přidržím anglických názvů objektů. České ekvivalenty zatím nebyly představeny a mám pocit, že mě nepřísluší se pokoušet o důkladný překlad do češtiny, což by v některých případech mohlo být spíše matoucí než ku prospěchu. Nicméně v nesporných případech český překlad používám. Event (Událost) Události ovlivňují tok procesu proces spouští, přerušují či ukončují. - počáteční - přechodová/vnitřní - koncová Obrázek 1 - Události 5

6 Existují různé druhy startovních událostí a to v závislosti na typu události příchod zprávy, časová událost atd. Jsou počátečním bodem procesu a iniciují provádění procesu. Vnitřní události nějakým způsobem ovlivňují chod procesu, který už dříve započal. Přímo nespouštějí či neukončují proces. Nyní uvedu různé funkce, které mohou zastupovat: vyznačují místo v procesu, kde je očekáván příchod zprávy či kde se zpráva odesílá vyznačují časové prodlení v provádění procesu přerušují běžný tok procesu pomocí reakce na výjimku (exception handling) stanovují požadavek na opětovné provedení části procesu Koncové události či spíše stavy indikují ukončení procesu. Nemůže z nich vycházet další tok (sequence flow). Opět obrázek uprostřed konkretizuje charakter ukončení procesu. konec procesu okamžitě iniciuje provádění navazujícího procesu ukončí veškeré aktivity procesu, i v případě, že se vyskytuje v subprocesu Obrázek 2 - Typy událostí Události vně procesu se klasicky vyskytují mezi dvěmi aktivitami a leží na propojení znázorňující předávání řízení. Nově podle notace BPMN lze událost umístit na okraj aktivity/činnosti, čímž se indikuje, že aktivitu lze přerušit, pokud nastane daná událost. Uvedený příklad demonstruje pravidlo, které říká, že nedojde-li do dvou dnů k potvrzení objednávky, odešle se zákazníkovi zpráva o zrušení. Obrázek 3 - Přerušení činnosti 6

7 Obrázek 4 - Restart činnosti Pomocí této techniky lze znázornit i restart činnosti, v případě že dojde k určité události a je třeba provést celou činnost znovu. V našem příkladě máme subproces, který se musí spustit znovu v případě vzniku nového fyzického návrhu, čímž se mění podstatné skutečnosti pro daný proces. Activity (Činnost) Činnost je vykonávána jako konkrétní aktivita v rámci procesu. Může být atomická či složená (na nižší úrovni zobecnění se skládá z dílčích činností). Může být provedena jednou či probíhat ve více iteracích. Notace BPMN jednotlivé typy činností rozlišuje, viz. obrázek. Obrázek 5 Činnosti - typy Gateway (Rozcestník, Rozhodnutí) Rozcestníky jsou využívány pro určení dalšího směrování procesu. V nich se možné cesty rozbíhají či naopak setkávají. Jsou místem, kde je potřeba rozhodnout o dalším směru toku a toto rozhodnutí se může zakládat na různých principech. Rozcestník nemůže být zdrojem ani cílem zpráv (nelze propojit pomocí message flow). 7

8 Obrázek 6 - Gateways Exclusive Gateway vyznačuje místo, kdy se průběh procesu rozbíhá do více směrů, přičemž lze zvolit pouze jednu cestu. Výsledek rozhodnutí závisí buď na určité informaci či události (viz. Obrázek 7). Inclusive Gateway vyznačuje bod, kdy podle konkrétních požadavků dochází k větvení. Proces může pokračovat provedením jedné větve, či více větví současně (viz. Obrázek 8). Complex Gateway je využit pro pokročilé způsoby rozhodování. Paralel Gateway je využíván pro větvení paralelních činností (může být i vynechán, slouží zde spíše pro metodologické účely). Také se využívá pro zpětnou synchronizaci paralelních činností, kdy jedna činnost čeká na druhou. Tento příklad ilustruje způsob větvení na základě událostí. Podle toho, která událost nastane jako první, je zvolena příslušná alternativa. Konkrétně pokud dorazí zpráva No, pošle se oznámení o zrušení, pokud dorazí zpráva Yes, zašle se faktura a pokud se do tří dnů nestane nic, zašle se upomínka. Obrázek 7 - Exclusive Gateway Příklad ilustruje větvení běhu procesu, přičemž může proběhnout jedna větev, dvě, či všechny naráz. Konkrétně jde o rozhodnutí které části dokumentu jsou vyžadovány. Po vypracování vyžadovaných částí dochází ke kompilaci výsledného dokumentu. Souběh činností je opět zprostředkován pomocí Inclusive Gateway. Obrázek 8 - Inclusive Gateway 8

9 Connectors (Propojení) Sequence Flow vyznačuje pořadí činností, v jakém budou provedeny v rámci jednoho procesu (zdroj i cíl musí být buď událost, činnost, či rozcestník). Message Flow vyznačuje předávání zpráv mezi dvěmi entitami, které jsou připraveny tyto zprávy vysílat a přijímat. Asociace propojuje data, informace či předměty s ostatními objekty. Obrázek 9 - Propojení (Connectors) Podmínečný Sequence Flow To, že proces bude probíhat po určité větvi, můžeme navázat na konkrétní podmínku. Při splnění této podmínky bude realizována činnost určená tímto propojením. Podmínečné propojení je graficky znázorněno malým kosočtvercem na začátku Sequence Flow. Minimálně jedna podmínka musí být vždy splněna, aby mohl proces pokračovat. Pro názornost je uveden stejný příklad jako u Inclusive Gateway. Je vidět, že stejná situace lze graficky vyjádřit různě. Volba nejvhodnější varianty už záleží na citu a zkušenostech návrháře. Obrázek 10 - Podmíněné větvení 9

10 Default (Výchozí) Sequence Flow Při použití Inclusive či Exclusive Gateway lze jednu větev určit jako výchozí. Tato pak bude provedena, pokud podmínky u ostatních větví nebudou splněny. Značení se provádí přeškrtnutím začátku propojení. Obrázek 11 - Default sequence flow Message flow Message flow vyznačuje předávání zpráv mezi různými účastníky procesu. V BPMN jsou účastníci vyznačeni pomocí tzv. Pools. Message flow může propojovat jednotlivé Pools nebo objekty umístěné uvnitř. Nelze propojit objekty v rámci jednoho Pool. Obrázek 12 - Předávání zpráv Association (Předávání dat) Asociace přiřazuje data jednotlivým činnostem. Lze vyjádřit situaci, kdy konkrétní data jsou pro jednu činnost výstupem a pro druhou vstupem, viz. příklad. Všimněme si možnosti definovat stav dokumentu [Schválený]. Dokument v průběhu procesu svůj stav mění. Je třeba si uvědomit, že pomocí Sequnce Flow se předává řízení a že je jím určena posloupnost činností, nikoliv však předávání dat. K tomu je určena pouze asociace, která může probíhat paralelně se Sequnce Flow. Obrázek 13 - Předávání dat 10

11 Obrázek 14 - Dvě alternativy vyjádření jedné skutečnosti Organizační objekty Pools Pools reprezentují účastníky v interaktivním diagramu. Používáme je v případě, že model obsahuje dva či více oddělených subjektů, kteří navzájem komunikují pomocí zpráv (viz. Obrázek 12). Účastník může mít podobu obchodní role (zákazník, prodejce) či obchodní entity (konkrétní firma IBM, Tesco). V rámci jednoho Pool může probíhat proces, který však nesmí přesahovat hranice Pool. Interakce s okolím probíhá pouze pomocí Message Flow. Lanes Lanes vyznačují jednotlivé oddíly v rámci jednoho Pool. Klasicky je pomocí Pool vyznačena firma a pomocí Lanes její oddělení či organizační role (Management, Administrace, Web Server). Proces probíhá napříč jednotlivými Lanes. Obrázek 15 - Lanes Groups (Skupiny) Skupiny či spíše seskupování se využívá pro zvýraznění určité části modelu, která má shodné vlastnosti či nároky (např. oblast vyžadující zvýšenou bezpečnost). Seskupování nedefinuje 11

12 žádné dodatečné omezení jako v případě Pools a naopak může obsáhnout oblasti vyskytujících se v různých Pools. Obrázek 16 - Groups (Seskupování) Další pravidla Subproces Hierarchie modelu je realizována pomocí subprocesů. Tvorba a užití subprocesů má svá pravidla: Sequence Flow nesmí překročit hranici sub-procesu Message Flow a Association (Předávání dat) mohou překročit hranici sub-procesu Obrázek 17 - Sub-proces Proces je chronologický (zleva doprava), je iniciován určitou spouštěcí událostí a postupně spěje k nějakému smysluplnému konci. Všechny činnosti by měly být přiděleny konkrétní roli. Model by měl obsahovat kompletní životní cyklus dat či dokumentů v průběhu celého procesu. Není na škodu zavést jmenné konvence (např. činnost = sloveso + [příd.jméno] + podstatné jméno). Mapování BPMN do BPEL4WS Notace BPMN odstraňuje jednu z hlavních nevýhod předchozích notací, čímž byla nutnost manuálního překladů procesního modelu do jazyka IT. BPMN umí převést grafický model do sady XML příkazů jazyka BPEL4WS (Business Process Execution Language for Web Services). Příklad ilustruje základní pojmy. 12

13 Obrázek 18 - Mapování BPMN do BPEL4WS Navazující technologie BPEL (Business Process Execution Language) BPEL je programovací jazyk napsaný v XML. Pomocí něj lze sladit existující webové služby do procesu (umí sladit JEN webové služby!). Vývojáři jsou schopni pomocí nástrojů pro návrh vizuálních procesů, které jsou založeny na BPEL, používat diagramy typu drag-and-drop k vytváření programů automatizujících interakce mezi webovými službami. Této činnosti se často říká "sladění webových služeb" (web services orchestration). Procesy mohou být jednoduché i složité a s webovými službami se mohou domlouvat, ať už jsou provozovány na jakékoliv platformě, například na Java 2 Platform Enterprise Edition nebo.net. Je důležité zdůraznit, že BPEL umí jen komunikovat s webovými službami (web services). Sladění webových služeb je vše, co dokáže. Není určen k integrování se zdroji, které neposkytují rozhraní pro webové služby (jako jsou například uživatelské aplikace). Předpokládá se, že BPEL bude často rozšiřován o další jazyky, například Javu, a spojován s jinými technologiemi, aby mohl tyto potřeby uspokojit. Jazyk BPEL má dobré předpoklady k využití významného moderního trendu v IT, kterým je SOA normovaná metodologie organizace a designu. SOA umožňuje lépe a opakovaně využít výhod IT díky standardním rozhraním a sdílení webových služeb, které pomáhají zastřít technickou složitost IT prostředí na pozadí. To může vést k rychlejšímu rozvoji a spolehlivějším dodávkám nových a zdokonalených podnikových služeb. Jakmile společnost postaví knihovnu opakovaně použitelných webových služeb, jazyk BPEL umožní naprosto přirozené spojení těchto služeb spolu s novými aplikacemi. Ovšem tyto služby musejí být odněkud dostupné. IT bude muset tyto služby vytvořit, dát je k dispozici a řídit je. SOA Architektura orientovaná na služby Servisně orientovaná architektura (SOA) nabízí způsob organizace informačních systémů v podobě služeb, které jsou přímo spjaty s procesy v organizaci. Základním pravidlem této architektury je distribuce dat a služeb. Služby plní vždy jen specifické úlohy, využívají omezenou množinu dat. Funkcionalitu služeb využívají klienti sytému a jiné služby. Výhodou servisně orientované architektury je autonomie takto fungujících služeb. Služby pracují jako 13

14 autonomní aplikace. Dohromady pak služby a klienti vytváří komplexní informační systém.. Jednotlivé prvky systému (služby, klienti, technické vybavení) je možné měnit (aktualizovat) dle potřeby, a to bez zásadního zásahu do fungování celého informačního systému. Pokud je zachováno rozhraní služby, může být její obsah, změněn bez zásahu do dalších služeb. Služba může být rovněž přesunuta na jiný počítač, bez změny zbytku systému. Jediné co musí být v systému změněno je aktualizace umístění služby. Webové služby Webové služby nejsou nic záhadného a komplikovaného. Velmi jednoduše lze říci, že nabízí způsob propojení dříve neslučitelných aplikací. Díky webovým službám je možné snadno rozšiřovat funkcionalitu stávajících aplikací. Webové služby jsou komponenty, které poskytují sadu metod, které jsou přístupné přes jasně definovaný protokol prostřednictvím počítačové sítě. Klient webové služby volá vybranou metodu služby, předává jí parametry volání a zpět od služby dostává odpověď. Parametry volání i odpověď mohou být buď jednoduché datové typy (např. řetězec, číslo) nebo i komplexní objekty (např. mapa, obdélník atd.). Klientem webové služby může být buď uživatelem ovládaná aplikace nebo jiná webová služba. Uživatel si pouze připojí službu s jasně definovaným rozhraním (např. WFS) a může si tak ve své aplikaci např. zobrazit data spravovaná ministerstvem životního prostředí či používat vyhledávač adres. Webové služby naleznou uplatnění v mnoha oblastech. Uvedu proto pouze ty nejčastější:. Máte firemní intranet a potřebujete dostat některá data z něj do specializovaného produktu, který s daty pracuje. Typické propojení intranetu a dalšího produktu. Intranetový informační systém funguje jako poskytovatel služby. Máte fungující e-shop a chcete v něm nabízet produkty dalšího partnera. Není nic lehčího, než aby vám partner zpřístupnil data pomocí webových služeb a váš e-shop z ní data četl, případně prováděl určité operace. Tvoříte stolní (desktopovou) aplikaci a je potřeba do ní stahovat aktualizace a rozšíření. Poměrně rychle vytvoříte webovou službu poskytující aktualizace. Jak fungují webové služby? Výše je stručně představen princip webových služeb. Je zřejmé, že proces publikace služby, její vyhledání a připojení musí být realizováno přesně definovanými protokoly. Ty lze rozdělit do 4 oblastí: přenos služby (na principu HTTP, SMTP, FTP a další) XML komunikace (XML messaging) popis služby (Service description) vyhledání služby (Service discovery) Obrázek 19 - Schéma práce s webovou službou 14

15 PowerDesigner V programu PowerDesigner 12.1 vytvořím jednoduchý proces, přičemž vyzkouším schopnosti tohoto nástroje pracovat s pravidly BPMN 1.0 a následně zkusím vygenerovat kód v jazyku BPEL a prozkoumám jeho strukturu. Vytvoření procesu v PowerDesigneru Obrázek 20 - Proces obchodní případ Zhodnocení nástroje Nástroj podporuje veškeré prvky notace BPMN 1.0. Dodržuje dané omezení dané BPMN (např. Gateway nelze propojit s datovým prvkem pomocí message flow, z koncového stavu nemůže vycházet další tok atd.). Jediný nedostatek, kterého jsem si všimnul je, to, že nelze připojit událost na okraj procesu pro případné odchycení vyjímek (viz. Obrázek 3). Vygenerování BPEL4WS 1.1 Nejdříve model převedeme do procesního jazyka BPEL4WS 1.1 a následně vygenerujeme kod: Obrázek 21 - Proces v jazyku BPEL4WS

16 Struktura BPEL dokumentu <?xml version="1.0" encoding="utf-8"?> <!-- Web Service Description Language --> <!-- Author: Ondra --> <!-- Modified: 17. prosince :19:30 --> <process name="top-level Process" targetnamespace=" Process.Ondra.com" querylanguage=" expressionlanguage=" suppressjoinfailure="no" enableinstancecompensation="no" variableaccessserializable="no" abstractprocess="no" xmlns=" xmlns:tns=" Process.Ondra.com" xmlns:lns=" případ_bpel.ondra.com"> <partnerlinks> </partnerlinks> <variables> </variables> <sequence> <empty name="zpracování objednávky"> <switch name="forma dodání"> <case condition="osobní odběr"> <empty name="rezervace položek"> <empty name="čekání na příchod zákazníka"> <sequence> <flow> <empty name="příjem platby"> <empty name="vydání zboží ze skladu"> <empty name="uzavření obchodního případu"> <empty name="zrušení rezervace položek"> </flow> <empty name="příjem platby"> <empty name="vydání zboží ze skladu"> <empty name="uzavření obchodního případu"> <empty name="zrušení rezervace položek"> </sequence> </case> <case condition="zásilková společnost"> <empty name="příprava položek"> <empty name="vyexpedování zboží"> <switch name="zboží vyexpedováno"> <case condition="zákazník zaplatil"> <empty name="příjem peněz"> <empty name="uzavření obchodního případu"> </case> <case condition="zákazník nezaplatil"> <empty name="návrat zboží na sklad"> </case> </switch> <empty name="příjem peněz"> <empty name="uzavření obchodního případu"> <empty name="návrat zboží na sklad"> </case> </switch> <empty name="rezervace položek"> <empty name="čekání na příchod zákazníka"> <sequence> <flow> <empty name="příjem platby"> <empty name="vydání zboží ze skladu"> <empty name="uzavření obchodního případu"> <empty name="zrušení rezervace položek"> </flow> <empty name="příjem platby"> <empty name="vydání zboží ze skladu"> <empty name="uzavření obchodního případu"> <empty name="zrušení rezervace položek"> </sequence> <empty name="příprava položek"> <empty name="vyexpedování zboží"> <switch name="zboží vyexpedováno"> <case condition="zákazník zaplatil"> <empty name="příjem peněz"> <empty name="uzavření obchodního případu"> </case> <case condition="zákazník nezaplatil"> <empty name="návrat zboží na sklad"> </case> </switch> <empty name="příjem peněz"> <empty name="uzavření obchodního případu"> <empty name="návrat zboží na sklad"> </sequence> </process> 16

17 Dodatek k vygenerovanému dokumentu PowerDesigner vygeneroval pouze strukturu BPEL dokumentu a to z toho důvodu, že proces neintegroval webové služby, ale pouze činnosti jako jejich zástupce. Jedná se však o příklad ilustrativní a pro základní představu to stačí. Základní struktura dokumentu je následující: <process name = "Top-Level Process" > <partnerlinks> --- deklarace využívaných služeb --- </partnerlinks> <variables> --- deklarace proměnných --- </variables> <sequence> --- definice samotného procesu --- </sequence> </process> PowerDesigner 12.1 dále nabízí možnost webové služby importovat. Pomocí příkazu Language Import WSDL lze přímo vložit URL webové služby či lze využít vyhledávač webových služeb na internetu. K dispozici máme předdefinované registry webových služeb (UDDI): UDDI (Universal Description Discovery and Integration) Jedná se o registr webových služeb. V tomto registru jsou shromažďovány odkazy na webové služby a informace k jejich použití napsaných v jazyku WSDL (Web Services Description Language). Ten popisuje rozhraní webové služby (metody, parametry, výstupy). UDDI je otevřený obchodní registr založený na XML. Nabízí seznam služeb a kontaktů, v kterých je možno vyhledávat. 17

18 CASE nástroj TeamTrack Nástroj TeamTrack je robustním CASE (Computer Aided Systems Engineering) nástrojem a portálovým řešením pro řízení jednoduchých i poměrně složitých pracovních toků, tedy workflow. Jde o platformu, která umožňuje automatizovat firemní procesy, v průběhu celého životního cyklu projektu centrálně evidovat uživatelské problémy a požadavky, a ty posléze vyhodnocovat a řešit. Přínosem tohoto nástroje je kromě jiného i podpora procesů kompatibilních s ITIL (IT Infrastructure Library) jedná se tedy o podporu helpdesku a incident managementu, problém managementu, defekt managementu, managementu změn a task managementu. Podporovány jsou taktéž procesy kompatibilní s Sarbanes-Oxley. Z tohoto důvodu byl také TeamTrack certifikován společností Pink Elephant. TeamTrack je založen na webové architektuře (viz Chyba! Nenalezen zdroj odkazů.). Znamená to, že uživatelé k němu přistupují prostřednictvím webového prohlížeče či mobilního zařízení (Smartphone, PDA). Výhoda tohoto přístupu spočívá v tom, že není třeba na uživatelskou stanici instalovat žádnou aplikaci. TeamTrack na straně serveru podporuje clusterovou konfiguraci pro zapojení více serverů a tzv. load balancing, systém více clusterů, rozdělujících rovnoměrně zátěž ať již v podobě velkého počtu požadavků či současně přistupujících uživatelů do systému. Operačními systémy, na kterých může být nástroj TeamTrack nainstalován, jsou Win NT, Win2000, Win2003 a Solaris. V blízké budoucnosti je plánována také podpora systémů Linux a AIX (Advanced Interactive Execution). Obrázek 22 - Architektura aplikace TeamTrack Z obrázku 22 je patrná vzájemná spolupráce všech částí komplexního nástroje TeamTrack, a sice web serveru, samotné aplikace, databáze a prvků pro přístup a ovládání nástroje (vzdálený administrator a TeamTrack administrator). Automatizace procesů Automatizace procesů je jednou ze silných stránek nástroje TeamTrack. 18

19 V rámci pracovních rolí nástroje TeamTrack existuje základní rozdělení pracovníků na tzv. manažery a uživatele. Uživatelé členěni na tzv. zadavatele a řešitele. Úlohou manažera je procesy definovat, tzn. nakreslit proces včetně všech jeho atributů, stavů a přechodů. Další z úloh, které náleží manažerovi projektu, je vytvoření nového projektu a přiřazení příslušných rolí a práv uživatelům, kteří se budou na projektu specifickým způsobem podílet. Nástrojem manažera k řízení projektu a sledování pracovních týmů je tzv. dashboard, což je panel nástrojů, sloužící ke sledování všech pracovních týmů a projektů, jejich řízení a vyhodnocování v podobě statistických výsledků (grafů apod), které slouží také jako podklad pro případné změny v procesech. Zadavatelé jsou ti uživatelé, kteří do systému zadávají požadavky, hlášení či problémy, které se právě vyskytly a mají také přehled o tom, jakým způsobem jsou tyto problémy či požadavky řešeny a zpracovávány. Taktéž mohou k informacím o průběhu jejich řešení připojovat různé poznámky či související přílohy ve formě souborů. Řešitelé jsou zodpovědní za řešení problémů a požadavků, které do systému vložili zadavatelé. Obrázek 23 - Ukázka návrhu workflow procesu ve Workflow Editoru Oblast správy požadavků V oblasti správy požadavků na fungování určitě aplikace je prvním krokem vytvoření pracovního toku workflow celého procesu. Jak již bylo zmíněno, tento krok má na starosti manažer, který v grafickém editoru celý workflow proces nakreslí. Všem procesům přiřadí jejich atributy, stavy a přechody a vlastníky těchto stavů. Poté je třeba nadefinovat všechny nutné záznamy a položky, které budou v rámci tohoto celého procesu evidovány. 19

20 Dále je třeba založit příslušný projekt v tomto případě jde o systém pro správu (uživatelských) požadavků na aplikaci a příslušným uživatelům přiřadit jejich práva pro vkládání zmíněných požadavků. Obrázek 24 - Ukázka projektového požadavku Na obrázku 24 je znázorněna obrazovka se stavem procesu projektového požadavku na zajištění přístupu do CRM pro uživatele R2. Kromě standardních informací obsahujících například stupeň priority požadavku jsou zde k dispozici také uživatelské informace (odhadovaná pracnost, omezení realizace projektu, termín realizace atd.), a v neposlední řadě také velmi důležitý přehled historie změn stavů. Je zde patrné, že proces prošel již několika přechody a stavy: předložením prvotní specifikace, která byla následně předložena, dále bylo posuzováno přiřazení projektu. Dalšími funkcionalitami, které nástroj TeamTrack nabízí, jsou například: možnost notifikace (upozorňování), znalostní báze, integrace s jinými systémy, audit trail (automatická tvorba historie) a reporting a sestavy. Upozorňování Notifikace neboli upozorňování je, dle názoru odborníků, velmi silnou a vydařenou funkcionalitou nástroje TeamTrack, jejím cílem je, aby všechny zadané požadavky, týkající se různých situací či problémů, byly zpracovány a vyřešeny příslušnými odpovědnými řešiteli. 20

21 Funkce upozorňování je založena na systému pravidel. V těchto pravidlech jsou zaznamenány příslušné podmínky, kdy daná situace nastane a na jejímž základě je spuštěna příslušná funkce například upozornění uživatele em, že byla úspěšně ukončena část procesu (viz obrázek 1.4). Obrázek 25 - Ukázka zadání nové ové notifikace Znalostní báze Přínos této funkcionality nástroje TeamTrack spočívá ve znovupoužití určitého řešení problému, který byl nalezen a vyřešen v minulosti. Tato znalostní báze tedy spočívá v archivaci (v podobě hierarchické struktury) řešení určitého problému. Pokud uživatel narazí na problém, k němuž nemůže nalézt řešení, může mu pomoci právě tato znalostní báze. Uživatel má možnost v této bázi na základě různých kritérií vyhledávat. Audit Trail automatická tvorba historie Ať už uživatel provede v TeamTracku jakoukoli akci, je tato akce automaticky zaznamenána a stává se tak součástí tzv. historie. Při práci se systémem je pak tedy možné nalézt všechny s procesem související změny, které byly během práce s nástrojem TeamTrack učiněny. Ze své podstaty slouží tato historie taktéž jako určitý důkazní prostředek při řešení nejasností či určitých sporů, které se během práce mohou vyskytnout. Reporting a sestavy Silnou funkcionalitou TeamTracku jsou sestavy. Tyto sestavy je možné vytvářet v přehledném a uživatelsky přívětivém nástroji a jejich výstupem mohou být výsledky v podobě přehledných grafů či tabulek. Tyto sestavy mohou sloužit manažerům pro určitá strategická rozhodování, 21

22 jelikož výsledky těchto sestav mohou být využity pro určování jistých trendů a dalších statistických ukazatelů. Samozřejmostí je možnost exportu výstupu zvolených sestav do nástroje MS Excel. Integrace s jinými systémy Další z výhod nástroje TeamTrack je možnost integrace s mnoha jinými systémy, jejichž účelem je též správa procesů. Těmito nástroji jsou například TestDirector (product společnosti Mecrury Interactive) či PVCS (Polytron Version Control System), což je nástroj od firmy Merant. Pro komunikaci s jinými systémy lze využít rozhraní XML Bridge, které umožňuje potřebná data vytvářet a odesílat či přijímat. Pro přijímání a odesílání dat zde existuje možnsost propojení systému s ovým klientem. Novinky TeamTrack verze 6.6 Novinkami ve verzi TeamTrack 6.6 je několik (zdroj: [5]): podpora webových služeb o dodatečné programovací jazyky C#, Java, BPEL podpora vylepšeného elektronického podpisu o možnost vynucené opětovné autentifikace při přechodu v módu Administrator (tato možnost byla dříve dostupná pouze v podobě externího skriptu, nyní je součástí aplikace TeamTrack) vylepšený nástroj Tracker Migration podpora aplikace SQL Server 2005 Produkt, verze Serena TeamTrack 6.1 Výrobce Podporované platformy Serena Software Aplikační servery: - Apache Web Server - Java Sun One - MS IIS Databáze: - IBM DB2 - Oracle - MS Access - SQL Server Operační systémy: - Windows - Solaris Očekávané OS: 22

23 - Linux - AIX Cena $ za 10 uživatelských jmen $ za 10 současně připojených uživatelů Tabulka Přehled nástroje TeamTrack

24 Referenční model workflow Všechny workflow management produkty mají určitou množinu společných charakteristik. Tyto společné vlastnosti představují určitý potenciální prostor pro vzájemnou interoperabilitu produktů různých výrobců. Taková interoperabilita, která je jistě žádoucí, je podmíněna existencí společných standardů pro onu společnou funkcionalitu workflow systémů. Za účelem identifikace funkčních oblastí vhodných ke standardizaci a následnému vytvoření patřičných specifikací byla založena organizace WFMC, od které pochází také Workflow Reference Model (referenční model workflow), který chceme v této kapitole představit. Standardizace na tomto poli usnadní interoperabilitu heterogenních workflow produktů a zdokonalí tím jejich integraci s dalšími IT službami (mail, dokument management). Východiskem pro různé specifikace v této oblasti představuje tzv. referenční model pro workflow management systémy (WFMS). Tento model popisuje vlastnosti, terminologii a komponenty WFMS, které pak tvoří společný kontext pro jednotlivé specifikace. Workflow Workflow je spojováno s automatizací procedur, při nichž jsou dokumenty, informace či úkoly předávány mezi účastníky s ohledem na definovanou množinu pravidel tak, aby se dosáhlo (nebo přispělo k dosažení) celopodnikového cíle. Takto široce definovaný pojem workflow nevylučuje manuální organizaci, nicméně v praxi je spíše běžná organizace workflow v rámci nějakého informačního systému a automatizace je docíleno pomocí prostředků výpočetní techniky. Workflow tak tedy znamená automatizaci (či usnadnění) business procesu (nebo jeho části) pomocí prostředků výpočetní techniky. Workflow Management System zajišťuje procedurální automatizaci business procesů řízením a správou posloupnosti pracovních činností a jejich přiřazením odpovídající osobě či jinému IT zdroji, které jsou přiřazeny k dané činnosti či kroku. Workflow Management Systém (WFMS) je systém, který zcela definuje, řídí a vykonává jednotlivé workflow prostřednictvím Proč referenční model? Různé procesy v různých organizacích mohou mít odlišnou délku, strukturu, složení dílčích aktivit atp. Implementace WFMS nad těmito procesy se mohou lišit jeden od druhého mimo jiné tím, do jaké míry jsou zapojeny prostředky výpočetní techniky, jakým způsobem je využívána komunikační infrastruktura, jak velká je organizace atd. Navíc se mohou pochopitelně lišit i různé WFMS nad týmiž procesy v jedné organizaci, pocházejí-li od různých dodavatelů. Na druhou stranu WFMS vykazují určitý okruh společných charakteristických vlastností, které jsou pilířem pro interoperabilitu mezi jinak heterogenními produkty. Referenční model má za úkol jednak zrcadlit zmíněnou širokou různorodost a pojmout veškeré možné techniky implementace a další odlišnosti týkající se např. prostředí, ve kterém je daný systém v provozu, jednak musí popisovat společný model pro tvorbu workflow systému a identifikovat prostředky pro interakci s workflow systémy, které jsou implementovány odlišnými technikami. Funkční oblasti Na nejvyšší úrovni modelu workflow systému jsou definovány 3 oblasti funkcionality, které by měl každý WFMS podporovat. Jedná se zároveň o jakési základní 3 vrstvy workflow systému: 1) oblast funkcionality pro návrh (tzv. build-time functions) 2) oblast provozní funkcionality (run-time functions) 3) oblast provozních interakcí (run-time interactions) 24

25 Funkce pro návrh Tato funkcionalita pokrývá proces přeměny procesu z reálného světa do formalizované podoby zpracovatelné počítačem, která se nazývá definice procesu. Definice procesu zahrnuje řadu samostatných aktivit (kroků), k nimž jsou přiřazeny operace, prováděné počítačem či člověkem, a pravidla, kterým se tyto dílčí kroky a operace nad nimi podřizují. Formální vyjádření definice procesu může mít textovou či grafickou podobu, nebo může být popsáno nějakým formálním jazykem. Oblast provozní funkcionality Během provozu workflow systému je definice procesu interpretována softwarem, který vytváří jednotlivé operační instance procesu, plánuje dílčí kroky uvnitř procesu a vyvolává příslušné počítačové i lidské zdroje. Základem pro tuto funkcionalitu je klíčová část celého WFMS, tzv. engine, který celý systém řídí, zodpovídá za tvorbu a rušení procesů, načasování dílčích kroků uvnitř procesu a interakci s uživateli či aplikačními prostředky. Oblast provozních interakcí Tato oblast pokrývá interakce uživatelů a aplikačních nástrojů pro zpracování jednotlivých kroků procesu (např. vyplnění webového formuláře reprezentujícího vystavenou fakturu) se softwarem řídícím procesy. Využití standardizovaného frameworku pro tuto funkční oblast přináší výhody, jako např. stejné a konzistentní aplikační a uživatelské rozhraní u různých systémů, možnost tvorby společných aplikačních nástrojů schopných spolupracovat s různými workflow produkty atd. Po stručném popisu základního pohledu na workflow systému z hlediska funkčních oblastí přistupme k základnímu popisu samotného referenčního modelu. Referenční model workflow Každý workflow sytém obsahuje řadu typických komponent, které navzájem spolupracují. Problém nastává při snaze o interoperabilitu mezi těmito komponentami u produktů různých výrobců. Každá takováto typická komponenta se tak může vyznačovat různou úrovní funkcionality a schopností. Zde je žádoucí, pro komunikaci mezi jednotlivými komponentami existovala určitá množina standardizovaných rozhraní a formátů pro výměnu dat. Obrázek 26 - Referenční model workflow komponenty a rozhraní 25

26 Workflow engine (jádro) Jádro spravuje běhové prostředí, kterým je WES (workflow enactment service, viz níže). Zodpovídá za provádění operací nad instancemi procesů, např.: - interpretace definice procesu (která je výstupem 1. funkční oblasti uvedené výše) - řízení instancí procesu vytváření, aktivace, přerušení atd. - časování kroků procesu - autentizace a autorizace účastníků procesu - generování a zpracování informací vztahujících se k workflow a určených uživatelům či aplikacím atd. Podívejme se nyní na ty nejdůležitější části modelu. Workflow enactment service (WES, běhové prostředí) Tato komponenta poskytuje běhové prostředí, ve kterém komponenta jádra (workflow engine) vytváří a aktivuje instance procesu pode jeho definice. WES lze definovat jako softwarovou službu, která zajišťuje vytvoření, řízení a správu workflow instancí pomocí jedné či více komponent jádra. Vzájemná spolupráce s dalšími aplikacemi (čili přístup aplikací k WES) je pak zprostředkována pomocí WAPI (workflow application programming interface). WES je z pohledu systému jedna logická entita, ačkoliv fyzicky může jít i o distribuovanou funkcionalitu. Kromě toho, že v rámci jedné komponenty WES může být zapojeno více jader, může navíc celý workflow systém, např. jde-li o distribuovaný systém, obsahovat více než jednu komponentu WES. WAPI obsahuje rovněž podmnožinu rozhraní pro komunikaci a předávání zpráv mezi týmiž komponentami navzájem (Interface 4 na obrázku výše). WES si lze představit jako zařízení, pomocí něhož jednotlivé instance procesů přechází z jednoho stavu do jiného v závislosti na podnětech, které instance obdrží z vnějšku komponenty (např. dokončení určitých kroků), nebo které obdrží v podobě nějaké řídící instrukce od samotného jádra. Na zde uvedeném schématu můžeme vidět příklad, kde instance procesu prochází různými stavy. Obrázek 27 Přechody stavů instance procesu Process definition tools (nástroje pro definici procesu) Komponenta představující sadu různých prostředků (v modelu nahoře process definition tools) pomocí nichž se proces reálného světa transformuje do softwarové podoby (definice procesu) může a nemusí být součástí samotného workflow systému. Pokud je jeho součástí, nemusí být definice procesu zpřístupněna okolí a může zůstat pouze uvnitř workflow systému. Lze ale také využít nástrojů třetích stran, které dokáží proces definovat a publikují jej ve 26

27 výsledné podobě dovnitř workflow systému, případně jej uloží do společné báze, ke které má WFMS přístup. Definici procesu interpretuje jádro uvnitř WES. Klientské aplikace Aplikace pro interakci koncových uživatelů mohou být integrovány přímo ve workflow systému, či mohou být produktem třetí strany stojící vně WFMS. Komunikaci mezi jádrem a klientskou aplikací umožňuje příslušné rozhraní. Vyjádřením této komunikace je pak tzv. worklist, což je v podstatě řada činností, které jsou vygenerovány jádrem a určeny již pro konkrétního uživatele. Tyto jednotlivé kroky z worklistu mohou patřit i k více instancím jednoho procesu, případně k různým procesům. Jednou z hlavních úloh klientské aplikace je pak prezentační funkce, kdy kroky nebo činnosti, vygenerované jádrem transformuje podoby srozumitelné lidskému uživateli. Aktivace jednotlivých kroků worklistu může být ve správě klientské aplikace, eventuelně závisí na úkonu uživatele. Rozhraní WAPI V modelu vidíme, že vrstva mezi WES a ostatními částmi WFMS je tvořena rozhraním WAPI, které spolu s funkcionalitou pro vzájemnou výměnu informací umožňuje komunikaci mezi komponentou WES a ostatními aplikacemi a zdroji standardizovaným způsobem (definice rozhraní WAPI je předmětem samostatných standardů). Prostřednictvím WAPI jsou zpřístupněny vnějším aplikacím informace o instancích procesů, nikoliv však data popisující vnitřní stav těchto instancí, která WES spravuje. Taková data si v závislosti na implementaci mohou vyměňovat pouze různá jádra uvnitř jedné komponenty WES. WAPI je rozčleněno do jednotlivých rozhraní podle komponent, na jejichž hraně se nachází. Rozhraní mezi WES a nástroji pro definici procesu Interface 1 reprezentuje rozhraní pro komunikaci mezi běhovým prostředím a nástroji pro definici procesu. Slouží pro import/export této definice. Rozhraní podporuje kromě přenosu kompletní definice také dílčí instrukce pro parciální změny či úpravu parametrů definice procesu. Rozhraní mezi WES a klientskou aplikací Funkcionalita tohoto rozhraní je rozdělena do několika oblastí kromě jiného např. vytváření a správa relací, získávání informací týkajících se definice procesu, instrukce pro vytváření (instanciaci) procesů a následné změny stavů procesů, funkce pro získávání dat a také vyvolávání dalších aplikací. 27

28 Obrázek 28 Schéma rozhraní mezi klientskou aplikací a komponentou WES 28

29 Zdroje [1] Henrich Palo; TeamTrack vaše procesy pod kontrolou; Správa požadavků pomocí workflow systému; internetový článek; LBMS, [2] Maggie Biggsová; TeamTrack udrží obchodní procesy v chodu; článek časopisu Computer World 14/2004, [3] LBMS; Nástroj TeamTrack; informační materiály společnosti LBMS, [4] Henrich Palo; TeamTrack vaše procesy pod kontrolou; časopis Connect, leden 2005, [5] Serena TeamTrack leasing solution for operations process management; [6] Karel Heinige; Nasazení aplikace TeamTrack v ING; rozhovor s Henrichem Palem a Stanislavem Mlynářem v časopisu IT systems - 11/2005, TT-v-ING.pdf [7] OMG Final Adopted BPMN 1-0 Spec PDF ( [8] Introduction to BPMN PDF ( [9] OMG BPMN Tutoriál PDF ( [10] [11] [12] Růžička, Jan: Servisně orientovaná architerkura základ budování NGII PDF [13] David Hollingsworth; The Workflow Reference Model; on-line 29