Petr Vašíček, IBA CZ
V tomto díle si povíme něco o jazyce BPEL a začneme modelovat proces založení objednávky, jež jsme modelovali v díle minulém. Rovněž tedy poprvé použijeme vývojové prostředí NetBeans a ukážeme si, jak v něm založit BPEL projekt a jakým způsobem jej nasadit na server.
O jazyce BPEL uvedeme pouze základní informace a budeme se spíše soustředit na samotné modelování procesu. V článku také nabídneme odkazy na materiály, které mohou poskytnout podrobnější informace či přímo specifikaci jazyka BPEL včetně přesného popisu jeho jednotlivých elementů. Uvedeme i odkazy na tutoriály k NetBeans IDE, na jehož podrobnější popis by rovněž nebylo v seriálu místo.
Úvod do jazyka BPEL
WS-BPEL, celým názvem Web Services – Business Process Executional Language (výslovnost uváděna jako „bipple“ či „B-pel“), je jazyk na bázi XML (eXtensible Markup Language), jež slouží pro zápis business procesů na vykonatelné úrovni. Proces implementovaný pomocí BPEL je nasazen do běhového prostředí, které je schopno jej interpretovat. Tímto prostředím může být buďto samostatný procesní server, modul v aplikačním serveru apod. V našem případě jde o plug-in (tzv. service engine) do implementace podnikové sběrnice OpenESB, kterou v našem prostředí použijeme. Komponenta má název WS-BPEL Service Engine a nasazení implementovaných business procesů lze provádět pohodlně přímo z vývojového prostředí NetBeans, které budeme používat.
Hlavní funkcí BPELu je orchestrace webových služeb, tedy řízení souhry funkcionality, kterou nabízí backendová část systému, či více systémů. Tato funkcionalita je dekomponována do operací, jež je možné volat přes webovou službu. Na druhé straně BPEL sám stojí za webovou službou, která definuje jeho rozhraní, tj. vstupní operace. Pro každý vstup do procesu (v BPMN objekt Start / Intermediate MessageEvent) je tedy ve webové službě, která popisuje rozhraní BPELu, jedna operace. Dá se tedy říci, že BPEL implementuje webovou službu. Přitom aplikace, která webovou službu používá, neví, zda se za ní skrývá proces, či zda je implementována např. EJB modulem. BPEL je rovněž nezávislý na platformě, implementace pro něj existují na platformě Java EE, .NET a jiných platformách. Proces implementovaný v jazyce BPEL pomocí jednoho nástroje by také mělo být možné přenést a spustit v nástroji jiném. Někteří výrobci BPMS ale používají svá vlastní rozšíření jazyka BPEL, která tuto přenositelnost zněmožňují.
První verze jazyka BPEL, pojmenovaného jako BPEL4WS, vznikla v červenci 2002 a spojila myšlenku jazyků WSFL od IBM a XLANG od spol. Microsoft. Kromě těchto dvou společností se na původním návrhu podílela i BEA. V květnu 2003 byl revidovaný návrh předložen organizaci pro rozvoj strukturovaných informačních standardů OASIS a BPEL4WS ve verzi 1.1 si začal získávat velkou podporu na poli modelování procesů. Jen o něco později byl uveden další jazyk pro definování spustitelných procesů, BPML 1.0, ten ale zejména díky silné podpoře pro konkurenční BPEL ze strany velkých hráčů na trhu neuspěl. Dnes není takřka využíván, přestože oproti BPELu toho má více co nabídnout (řeší např. business pravidla, lidskou interakci s procesem apod.). Současná verze 2.0 byla představena v prosinci 2005 a ratifikována v dubnu 2007 a nese již pozměněný název WS-BPEL 2.0. Oproti předchozí verzi představuje několik nových BPEL aktivit, přejmenovává některé existující a obsahuje několik dalších menších změn.
Struktura BPEL dokumentu
NetBeans IDE, stejně jako většina ostatních BPEL návrhářů, poskytuje grafické uživatelské rozhraní pro modelování procesu v jazyce BPEL. Je tedy možné celý proces „naklikat“ a kódem procesu se nezabývat. Čas od času je ovšem zapotřebí nahlédnout do XML kódu a provést nějaké úpravy, zejména při řešení chyb. Kromě toho nění úplně od věci se v procesu zapsaném v jazyce BPEL orientovat, a proto si krátce představíme strukturu BPEL dokumentu.
Základní struktura dokumentu je zobrazena na následujícím obrázku. Kořenový element {process} (pozor - u všech elementů jde o ostré závorky <...> - na tomto webu je pouze nejsme schopni s příslušnými elementy zobrazit) zahrnuje všechny ostatní XML elementy. Pomocí atributů tohoto elementů určíme název procesu a jmenné prostory (namespaces). Následuje element {import}, kterým definujeme odkazy na použité externí soubory, typicky popisovače webové služby, WSDL dokumenty. Pomocí elementů {partnerlink} specifikujeme účastníky procesu, tedy kromě WS rozhraní samotného procesu i WS modulů, které použijeme. Následuje definice proměnných v elementu {variables} a korelačních množin pomocí {correlationsets}. Pak se již nachází hlavní sekvence událostí, obsažená v XML elementu {sequence}, do které již umísťujeme BPEL aktivity, specifikující tok procesu.
BPEL aktivity
Objekty, které v jazyce BPEL reprezentují události či defunují tok procesu, se nazývají BPEL aktivity. Aktivitami se tedy neoznačuje pouze nějaká činnost, jako tomu je v BPMN, nýbrž všechny elementy jazyka, jež značí nějakou akci či strukturu procesu. Následující výčet zahrnuje deset nejčastěji používaných BPEL aktivit.
Základní aktivity (basic activities):
Receive - zastaví proces a čeká na příchod specifikované zprávy
Reply - zašle zprávu jako odpověď na dříve přijatou zprávu
Invoke - vyvolá WS operaci typu one-way nebo request-response
Assign - manipulace s proměnnými
Exit - okamžitě ukončí vykonávání instance business procesu
Strukturované aktivity (structured activities):
Sequence - obsahuje aktivity, jež jsou spouštěny sekvenčně
Flow - obsahuje aktivity, jež jsou spouštěny paralelně
If-else - vybere jednu větev podle pravdivostního výrazu
Pick - zastaví proces a čeká na příchod první z více definovaných událostí
While - obsažené aktivity jsou opakovány, dokud platí určitý predikát
Pro získání více informací o těchto a ostatních BPEL aktivitách, lze doporučit tyto zdroje:Specifikace WS-BPEL 2.0
Guide to BPEL
BPEL Activities
NetBeans BPEL a CA projekt
Nyní se dostáváme k samotnému vytvoření našeho projektu. K tomu budeme potřebovat vývojové prostředí NetBeans IDE. Pokud jej máte nainstalováno (odkaz ke stažení jsme uvedli ve druhém díle), můžete jej nyní spustit. Základní informace o tomto nástroji včetně několika jednoduchých tutoriálů lze najít zde.
Nejprve založíme v NetBeans projekt, který bude obsahovat implementovaný proces a soubory, popisující účastníky procesu, tedy definice datových typů (soubory XSD) a popisovače webových služeb (soubory WSDL). Z nabídky zvolíme File -> New Project -> Service Oriented Architecture -> BPEL Module, jako název projektu zvolíme „OrderingBPEL“, vybereme umístění a dokončíme tlačítkem „Finish“. Máme tedy vytvořený BPEL modul, ve kterém budeme mít samotný proces a k němu přidružené soubory.
Druhým projektem, který budeme potřebovat, je kompozitní aplikace. Tato aplikace je souhrný projekt, skládající se z jednoho či více JBI modulů. BPEL modul je právě příkladem JBI modulu. Kompozitní aplikace s jedním či více moduly je pak nasazena na JBI server, v našem případě do OpenESB. Kompozitní aplikaci vytvoříme z File -> New Project -> Service Oriented Architecture -> Composite Application, jako jméno nastavíme OrderingCA. Pro přidání JBI modulu klikneme pravým tlačítkem myši na kořenový uzel nově vytvořeného projektu a vybereme „Add JBI Module“. Vybereme adresář, ve kterém máme BPEL modul a tvorba kompozitní aplikace je hotova. Až budeme mít hotový BPEL projekt, provedeme pak jednoduše deploy kompozitní aplikace na server pomocí „Deploy“ v kontextové nabídce projektu.
Účelem seriálu ovšem není návod pro modelování v BPEL, nebudeme si tedy uvádět jak vytvářet XSD a WSDL soubory, ani se dopodrobna zabývat postupem a přesným nastavením při tvorbě BPEL dokumentu. Spíše se budeme snažit ukázat, jak obecně modelování probíhá a jak funguje nasazení a vykonání procesu. Pro zájemce u návod tvorby BPELu v NetBeans můžeme doporučit následující tutoriály:Dev Guide to the BPEL Designer
Hello World Composite Application
Developing Synchronous Process
Implementace první části procesu
Nyní si vytvoříme první krok procesu založení objednávky. Nebudeme v této chvíli ještě využívat webovou službu backendového modulu, tu zapojíme až v příštím díle. Předpokládáme, že již máme vytvořen XSD a WSDL soubor pro náš proces. Rozhraní procesu tvoří tři operace, z nichž zatím implementujeme tu první, a to sice createOrder. Do procesu vložíme aktivity Receive a Reply a spojíme je s touto operací. Mezi ně vložíme aktivitu Assign a v ní přiřadíme do návratové proměnné aktivity Reply zatím testovací hodnotu „123“.
Nyní máme hotový testovací BPEL a můžeme nasadit kompozitní aplikaci na server. V projektu OrderingCA zvolíme „Deploy“ a v záložce Services -> Servers -> Glassfish V2 -> JBI ->Service Assemblies můžeme zkontrolovat, že aplikace OrderingCA je skutečně nasazená na serveru.
Když jsme nasadili proces na server, můžeme otestovat vstupní operaci createOrder. Podle návodu na netbeans.org vytvoříme v kompozitní aplikaci test case a pro tuto operaci a spustíme jej volbou „Run“ v kontextové nabídce testu. V uložené SOAP odpovědi „Output.xml“ můžeme zkontrolovat, že v elementu newOrderId se opravdu nachází hodnota „123“.
V příštím díle
Příště si nejprve představíme backendovou část aplikace, která obsahuje funkcionalitu pro práci s objednávkami. Pak pomocí NetBeans dotvoříme zbytek procesu a napojíme ho na webovou službu objednávkového modulu. Hotový proces pak otestujeme. Všechny tři vytvořené NetBeans projekty – BPEL modul, kompozitní aplikaci i objednávkový backend - umístíme ke stažení, abyste si mohli příklad sami vyzkoušet i bez nutnosti modelování procesu podle našeho návodu.
5. část: Tvorba BPEL modulu
4. část: Modelování procesu
Petr Vašíček, IBA CZ
Minule jsme si představili grafickou notaci BPMN, jež je de facto standardem pro modelování business procesů, a uvedli jsme si nejčastěji používané elementy této notace včetně jejich vysvětlení na jednoduchém příkladu. V tomto díle budeme již modelovat proces popsaný v druhé části našeho seriálu. Začneme tvorbou modelu na vysoké úrovni a budeme dále zpřesňovat subproces znázorňující založení objednávky. Cílem bude uvést model do tvaru, který bude převeditelný do jazyka pro popis procesů na vykonatelné úrovni, v našem případě do jazyka BPEL (Business Process Executional Language).
Každý proces je možné vyjádřit různými typy diagramů a s různou mírou přesnosti podle toho, k jakému účelu bude sloužit. Jinak vypadá diagram, sloužící k hrubému náhledu na proces, a jinak diagram, jenž bude předlohou pro implementaci procesu v jazyce BPEL.
Neexistuje žádná specifická metodika, se kterou je BPMN spjato a která by popisovala, jakým způsobem se mají procesy modelovat a jakým postupem modely zpřesňovat. Obvyklé je však začít u modelu procesu na vysoké úrovni, tedy sekvenci subprocesů, a následně modelovat tyto jednotlivé subprocesy. Nejprve lze vytvořit hrubý model subprocesu a pak jej dále zjemňovat, přidávat aktivity, uspořádávat elementy do plaveckých drah atd.
V tomto díle se pokusíme nastínit jeden z možných způsobů, kterým toho lze docílit. Zopakujme tedy, že našim cílem bude vyjádřit proces ve tvaru, ve kterém ho budeme moci co nejsnáze převést do spustitelné podoby, tedy implementovat v jazyce BPEL. U minulého dílu seriálu se rozvinula zajímavá diskuze zejména ohledně názvosloví aktivit a událostí a bude určitě přínosem, pokud se i tentokrát podělíte o svoje názory a zkušenosti.
Tvorba high-level modelu
Diagram procesu na vysoké úrovni, tzv. high-level diagram, je zobrazen jako sekvence subprocesů. Jak bylo napsáno v minulém díle, subproces je aktivita, pod kterou se skrývá samostatný proces se svým počátkem a koncem. Tento subproces je zinicializován z high-level procesu v okamžiku, kdy do něj vstoupí tok procesu. Poté, co subproces skončí, pokračuje high-level proces sekvenčním tokem, vedoucím z grafického objektu, značícího subproces.
V našem seriálu se budeme věnovat pouze jednomu samostatnému procesu (Založit objednávku), jenž již nebude dekomponován na další subprocesy. Nyní se ale podívejme, jak by mohl vypadat high-level proces, kde Založit objednávku je jedním ze subprocesů:
Proces začíná požadavkem na vytvoření objednávky a následuje první subproces, Založit objednávku. Výsledkem tohoto subprocesu je mimo jiné to, zda byla objednávka schválena či nikoliv. Pokud byla zamítnuta, high-level proces je ukončen, v opačném případě pokračuje dál třemi zaznačenými subprocesy.
Modelování subprocesu
Soustřeďme se nyní na samostatný proces Založit objednávku. Ten začne požadavkem na vytvoření objednávky od Objednatele. Touto událostí by odstartoval uvedený high-level proces, my ji ale budeme chtít přesunout do procesu Založit objednávku, abychom ten mohli později implementovat jako samostatný proces bez implementování high-level procesu.
Budeme se tedy držet popisu, který jsme uvedli ve druhém díle seriálu. Po vytvoření objednávky probíhá její posouzení technickým oddělením. Pokud ji schválí, dojde k rozhodnutí podle ceny objednávky. V případě, že je nižší než 40.000 Kč, je objednávka přímo schválena, v opačném případě je navíc předána ke schválení finančnímu řediteli. Budeme nyní modelovat jen hrubý diagram procesu a využijeme tedy pouze základních grafických elementů notace BPMN – startovních a ukončovacích událostí, aktivit, rozhodovací brány a sekvenčního toku.
Uspořádání aktivit do plaveckých drah
V procesu vystupují tři aktoři – Objednatel, Technické oddělení a Finanční ředitel. Nyní budeme chtít uspořádat aktivity v procesu tak, abychom z diagramu mohli určit, kdo v něm provádí jakou činnost. K tomuto účelů slouží plavecké dráhy (swimlanes). Vytvoříme tedy jeden pool (v diagramu je pouze jeden proces), ten můžeme pojmenovat např. workflow, tedy „tok práce“. V něm vytvoříme plaveckou dráhu pro každého aktora, v diagramu tak budeme mít jeden pool, rozdělený na tři plavecké dráhy.
Zahrnutí systémových akcí do procesu
Naším cílem je převést proces na nižší úroveň, abychom jej mohli později snáze implementovat. Budeme tedy chtít zpřesnit proces zobrazení aktivit, jenž ukazují interakci s backendovou částí systému, v našem případě tedy např. modulem pro správu objednávek. Pokud uživatel vytvoří objednávku, budeme ji chtít zřejmě v systému uložit. Pokud je objednávka předána ke schválení nějaké roli, budeme to u ní chtít zachytit. A pokud je objednávka schválena či zamítnuta, chceme tento příznak u objednávky nastavit. Do diagramu přidáme novou plaveckou dráhu – Objednávkový modul. V ní vytvoříme zmíněné systémové akce (můžeme označit jako Service Task).
Vyjádření spustitelného procesu
Podívejme se nyní, jakým způsobem je proces „umístěn“ ve vyvíjeném systému. V prvním díle seriálu můžete na druhém obrázku vidět, že BPM vrstva se nachází mezi backendovou a prezentační vrstvou. Na následujícím obrázku jsou vybrány komponenty, na kterých můžeme vidět jakým způsobem proces interaguje se zbytkem systému. Uprostřed vidíme schéma nějakého procesu. Z jedné strany k němu přistupuje webová aplikace, tedy uživatelé. Na straně druhé proces komunikuje s moduly systému a využívá jejich funkcionality.
Nyní tedy potřebujeme proces dostat do tvaru, kdy bude na jedné straně komunikovat s uživateli a na straně druhé s backendovými moduly systému. Protože BPEL neumí řešit lidskou interakci s procesem, budou veškeré lidské akce „vytknuty“ z procesu a každá taková akce bude v procesu zaznačena přijmutím zprávy (message start/intermediate event) od účastníka procesu reprezentujícího právě lidské uživatele systému.
V procesu tak budeme mít tři účastíky, reprezentované třemi pooly – Uživatelé, Objednávkový modul a samotný proces, u něhož však nebudeme ohraničení poolu zobrazovat. První dva zmíněné pooly budou typu „blackbox“, nebude v nich tedy zobrazen jejich vlastní proces, pouze komunikace s hlavním procesem.
Vidíme, že takto vyjádřený proces skutečně interaguje na jedné straně s uživateli a na druhé s backendovou částí systému. Jeho rozhraní tvoří tři operace – vytvoření objednávky, rozhodnutí technického oddělení a rozhodnutí finančního ředitele. Tyto tři operace budou volány uživateli z webové aplikace. Na druhé straně proces volá rozhraní objednávkového modulu, jenž musí nabízet minimálně tři operace – vytvoření objednávky, nastavení schvalovatele a změnu stavu objednávky.
Takto specifikovaný proces již můžeme poměrně snadno převést do spustitelné podoby jeho implementací v nějakém jazyce pro popis vykonatelných procesů. V našem případě tedy do jazyka WS-BPEL. Proces bychom mohli ještě dále zpřesňovat, typicky odchytáváním výjimek a zaznačením chybového toku, specifikováním vypršení limitu (timeout) při čekání na rozhodnutí apod., ale pro jednoduchost již necháme proces v této formě.
V příštím díle
V příštím díle si představíme standard pro zápis spustitelných procesů, XML jazyk BPEL, ve kterém budeme dnes namodelovaný proces implementovat. Budeme poprvé pracovat s vývojovým nástrojem NetBeans a ukážeme si, jakým způsobem v něm lze implementovat navržený proces a ten pak nasadit do běhového prostředí (v našem případě BPEL engine v platformě OpenESB).
3. část: Úvod do BPMN
Petr Vašíček, IBA CZ
V minulém díle jsme si popsali proces založení objednávky, který budeme v rámci seriálu modelovat a implementovat. Ještě před tím si však představíme notaci BPMN, ve které bude modelování probíhat. Tento článek můžete brát jako takový jemný úvod do této notace. Komplexnější pohled na BPMN a detailnější návod pro modelování v něm by vystačil na samostatný seriál, proto si v dnešním díle uvedeme alespoň jeho základy. Závěrem uvedeme několik odkazů na dokumenty, ze kterých je možno získat podrobnější znalosti.
Pár slov o BPMN
Business Process Modeling Notation (BPMN) je grafická notace (soubor grafických objektů a pravidel, podle nichž mohou být mezi sebou spojovány), která slouží k modelování procesů. Za jejím vznikem stojí iniciativa BPMI (Business Process Management Initiative), jejímž primárním cílem bylo v tomto případě vytvořit notaci, která bude čitelná všemi účastníky životního cyklu procesu (business analytici, techničtí vývojáři, analytici monitorující procesy atd.). Díky BPMN se úspěšně podařilo zmenšit komunikační mezeru mezi návrhem a implementací procesu a díky desítkám nástrojů, které jej používají, se stalo de facto standardem pro modelování procesů.
Dalším cílem BPMI bylo představit notaci, jež bude na jednu stranu jednoduchá na pochopení a používání, na druhé straně ale nabídne možnost modelovat i komplexní business procesy. Důležité bylo rovněž definovat převod mezi návrhem procesu v BPMN a jeho implementací v BPEL, BPML, či jiném jazyce pro spouštění procesů. BPMN definuje, jak převádět jednotlivé elementy a sekvence těchto elementů do jazyka BPEL. Je tedy možné (manuálně) model procesu do jeho spustitelné podoby převést. Díky poměrné volnosti modelování v BPMN není možné vygenerovat BPEL automaticky, některé BPMS nástroje však tuto funkci nabízejí, a to za cenu určitých omezení při samotném modelování procesu.
V současné chvíli je BPMN ve verzi 1.1, jež byla formálně přijata v lednu 2008. Daleko používanější ovšem zůstává verze 1.0 (únor 2006), která se od novější verze liší pouze v několika kosmetických změnách. Verze 2.0, která by měla přinést zásadnější změny, je očekávána koncem roku 2008 či spíše během roku 2009.
BPMN definuje jediný diagram, tzv. Business Process Diagram (BPD). Ten je tvořen sítí grafických objektů, zejména aktivitami a zobrazením toku informací mezi nimi. Jednotlivé grafické objekty jsou od sebe dobře odlišené, což přispívá k přehlednosti diagramu. Jasně dány jsou tvary těchto objektů, které je třeba dodržovat, je ovšem možné volit pro ně vlastní barvy, například z odlišovacích účelů. V určitých případech lze použít v diagramu i vlastní grafický objekt, ten se však nesmí překrývat s žádným již existujícím a rovněž by neměl ovlivňovat samotný tok procesu, pouze jej upřesňovat, či poskytovat nějaké dodatečné informace.
Grafické elementy
Business Process Diagram obsahuje čtyři základní druhy grafických elementů, jež se ještě dále dělí na další podtypy. Nejastěji používané druhy ilustruje následující obrázek:
Následuje výpis základních informací o jednotlivých typech grafických objektů:
Flow Objects (Tokové objekty)
Objekty, které souvisí s tokem informací v procesu.
Event (Událost)
Activity (Aktivita)
Gateway (Brána)
Connecting Objects (Spojovací objekty)
Objekty, které slouží k spojení tokových objektů navzájem či s artefakty.
Sequence Flow (Sekvenční tok)
Message Flow (Tok zpráv)
Association (Asociace)
Artifacts (Artefakty)
Značí nějaké upřesňující informace pro proces, nemají vliv na jeho tok.
Data Object (Datový objekt)
Group (Seskupení)
Annotation (Poznámka)
Swimlanes (Plavecké dráhy)
Slouží k zobrazení účastníků procesu či uspořádání činnosti v procesu např. podle rolí.
Pool
Lane (Dráha)
Příklad Business process diagramu
Uveďme příklad procesu jednoduchého aukčního systému. Tok informací v tomto procesu je následující. Nejprve proběhne registrace položky do aukce. Pokud je položka v aukci, může být koupena buďto s okamžitou platností kdykoliv během trvání aukce (tzv. „Buy It Now“), nebo může aukce skončit po určené době. V tom případě je vydražena, pokud byl učiněn alespoň jeden příhoz. V případě, že položka byla vydražena (buďto „Buy It Now“ nebo přihazováním), čeká systém na přijetí platby. Pokud platba přijde do sedmi dní, nechá systém zaslat koupené zboží a proces je ukončen. Pokud položka nebyla vydražena či výherce do sedmi dní nezaplatil, je buď znovu registrována do aukce, nebo je proces ukončen (podle nastavení aukční položky).
Na obrázku můžete vidět, jak by zadaný proces mohl vypadat. Není to samozřejmě jediný možný model tohoto procesu, BPMN poskytuje poměrně velkou volnost při modelování, takže existuje více možností, jak navrhnout stejný proces pomocí této notace.
Nyní si popíšeme tok v procesu tak, jak jej vidíte na uvedeném obrázku. Začátek procesu je zaznačen zeleným kroužkem. Odtud míří tok procesu do aktivity, jež značí registraci položky do aukce. Poté, co je položka registrována začne běžet aukce. Během ní mohou proběhnout dvě události – buďto někdo koupí položku hned (příjem zprávy „Koupeno hned“), nebo dříve dojde ke skončení aukce vypršením stanovené doby (časová událost typu „Timer“). Je tedy použito rozhodnutí na základě události a proces bude pokračovat větví, ve které nastane událost jako první. Pokud jako první nastane konec aukce, je třeba rozlišit, zda existují na položku nějaké příhozy. Jestli ano, míří tok procesu k čekání na přijetí platby stejně jako v případě, že někdo koupil položku již před skončením aukce díky možnosti „Buy It Now“. K aktivitě „Přijmout platbu“ je připojena událost „Timer“ s popisem „7 dní“. Tím je řečeno, že pokud proces setrvá v této aktivitě sedm dní, bude jeho tok směřovat větví, jež vybíhá z této události. Pokud je do sedmi dní platba přijata, je zboží zasláno výherci aukce – aktivita „Zaslat zboží“ - a proces končí. Pokud položka nebyla koupena nebo platba nedorazila, tok procesu bude ústit do grafického objektu znázorňujícího rozhodnutí na základě informace (tedy jestli má být zboží nasazeno znovu do aukce). Pokud má být položka znovu registrována, míří tok procesu na začátek do první aktivity, v opačném případě proces spěje do ukončovací události (červený kroužek) a je zastaven.
Závěrem
Účelem tohoto dílu bylo poskytnout jemný úvod do grafické notace Business Process Modeling Notation, kterou budeme používat pro modelování procesu v příštím díle. Uvedli jsme základní informace o této notaci a krátce představili její nejčastěji používané grafické elementy. Na závěr jsme si ukázali jednoduchý proces, na kterém můžeme vidět v praxi některé z grafických objektů. K hlubšímu pochopení, jak tyto objekty používat, a vůbec k lepšímu pochopení konceptu modelování v BPMN můžeme doporučit následující dokumenty:
2. část: Nástroje a vzorový proces
Petr Vašíček, IBA CZ
V tomto díle se podíváme na konkrétní nástroje, které budeme v průběhu seriálu používat, a dozvíme se, jakým způsobem je lze získat. Dále si představíme jednoduchý vzorový proces, se kterým budeme v následujících dílech pracovat. Popíšeme si jeho průběh, účastníky (aktory), kteří v něm vystupují, a pro lepší představu o systému jako celku též zmíníme základní informace o backend a frontend části aplikace.
Použité nástroje
Jako první bude v seriálu představena platforma složená z nástrojů vyvinutých společností Sun Microsystems - OpenESB, NetBeans a aplikační server GlassFish:
V našem vzorovém projektu použijeme komunikační infrastrukturu OpenESB, na níž budeme postupně stavět BPMS infrastrukturu. OpenESB je implementací JBI (integrační standard specifikovaný v JSR-208 - více informací) a umožňuje přidávat další funkční celky v podobě JBI pluginů, čímž nám usnadní budování kompletního BPMS řešení. Jedním z důležitých pluginů je právě i WS-BPEL Service Engine pro spouštění procesů zapsaných v jazyce BPEL. Dalším může být například komponenta pro business pravidla či workflow.
Obrázek 1: Architektura JBI
OpenESB je dobře provázána s vývojovým prostředím NetBeans, ve kterém lze snadno modelovat procesy v jazyce BPEL a sestavovat kompozitní aplikace, sloužící k provázání komponent nasazovaných do ESB. Současně je možné pomocí NetBeans vytvářet backend i frontend vyvíjeného systému, což zmenšuje počet nástrojů nutných k jeho vývoji a unifikuje vývojářské prostředí. NetBeans lze spolu s aplikační serverem GlassFish a OpenESB stáhnout jako bundle (společně distribuovaný balík), což zjednodušuje jeho instalaci, konfiguraci a také použití.
Pro modelování procesu v grafické notaci BPMN budeme používat nástroj Business Process Visual Architect, který není sice zdarma, nicméně jeho cena je poměrně nízká. Navíc existuje možnost stáhnout si jej na zkoušku po dobu 30 dní, což pro náš účel postačí. Díky jednoduchosti notace BPMN existují i volně dostupné kreslítka, umožňující modelovat BPMN procesy, nicméně nedosahují kvalit BP-VA.
Vývojové prostředí NetBeans 6.0.1 včetně aplikačního serveru GlassFish obsahujícího i OpenESB lze stáhnout zde. Vyberte poslední download (all – 195 MB).
Pro běh IDE i serveru je třeba mít nainstaováno Java JDK, nejlépe ve verzi 5.0. To je možné získat zde, konkrétně doporučujeme vybrat „JDK 6 Update 4“.
Nástroj Business Process Visual Architect od Visual Paradigm, ve kterém budeme modelovat proces, můžete stáhnout zdarma na této adrese. Na této stránce je potřeba vlevo nahoře kliknout na odkaz „Get a FREE copy“, zaregistrovat se, stáhnout produkt a nechat si na zadanou emailovou adresu zaslat soubor s licencí.
Ukázkový proces
Jak jsme již předeslali v úvodu seriálu, budeme celý životní cyklus BPM demonstrovat na jednom konkrétním procesu.
Pro modelování jsme vybrali jednoduchý a názorný proces, který si každý bude moci snadno představit, a to sice proces vytváření a schválení objednávky. Při návrhu tohoto procesu jsme nekladli přílišný důraz na realizmus procesu co se týče samotných požadavků, ani zda je proces správně navržen z pohledu analytického, ale spíše na jeho jednoznačnost, přehlednost a jednoduchou technickou proveditelnost. Záměrná trivialita procesu usnadní vysvětlování jednotlivých aspektů při jeho modelování a rovněž umožní věnovat se podrobně celému procesu. Tento proces budeme v této podobě používat s drobnými úpravami nebo obměnami až do konce seriálu.
Implementaci tohoto procesu budeme realizovat ve středně velké (fiktivní) firmě. Tato firma již má definován proces pro vytvoření objednávky a prvním krokem v jeho životním cyklu bude jeho namodelování business analytikem. V procesu vystupují tři role:
Proces začíná vytvořením objednávky a končí jejím schválením či zamítnutím. V případě schválení je objednávka předána k objednání. To už je předmětem navazujícího procesu, o kterém budeme předpokládat, že je již namodelován a funkční, a nebudeme se jím podrobněji zabývat.
Obrázek 2: Modelový proces
Proces je tedy iniciován akcí Objednatele, který založí objednávku v systému, uvede druh zboží, kvantitu a důvod objednávky (business reason). Objednávka je následně předána technickému oddělení ke schválení. To ji posoudí (zda není zboží již zastaralé, zda je vhodné pro požadovaný účel apod.) a rozhodne o jejím schválení. Pokud technické oddělení objednávku nezamítne (s uvedeným důvodem), proces pokračuje do rozhodovacího okamžiku, ve kterém se rozvětví podle ceny objednaných položek. Pokud je vyšší či rovna 40.000 Kč, musí ji schválit Finanční ředitel, v opačném případě je schválena automaticky. Po schválení je objednávka označena jako připravená k objednání (přebírá ji Nákupčí). Proces je pro představu zachycen v uvedeném BPMN diagramu, význam jednotlivých grafických elementů a postup k detailnějšímu modelu bude ukázán v příštím díle.
Nyní ještě krátce popíšeme prezentační vrstvu (frontend) a vrstvu business logiky (backend), se kterými bude proces v interakci. Frontend podobných systému tvoří často portálové řešení, v našem případě si ale vystačíme s jednoduchou webovou aplikací, jež bude umožňovat přihlášení uživatele a podle jeho role mu nabídne možnost vytvořit objednávku, sledovat založené objednávky a vyjádřit se k objednávce, která byla přiřazena ke schválení tomuto uživateli. Aplikace poskytne formuláře pro provedení všech interakcí s procesem. Samotná business logika, která zpracovává požadavky a pracuje s databází, je obsažena v EJB modulu, jenž je nasazen v aplikačním serveru GlassFish. K tomuto modulu lze přistupovat přes rozhraní webových služeb, a to jak z procesu, tak přímo z webové aplikace.
V příštím díle
V příštím díle budeme modelovat představený proces v nástroji Business Process Visual Architect. Ukážeme si, jak přistoupit k návrhu celého procesu a jak jej realizovat, včetně jemného úvodu do grafické notace BPMN. Srovnáme také úrovně, na kterých lze proces modelovat. Výsledkem příštího dílu či možná dvou bude kompletní návrh procesu v BPMN, podle kterého bude proces následně převeden do XML jazyka BPEL.
1. část: Proč BPM s open source nástroji
Petr Vašíček, IBA CZ
Seriál je koncipován jako „end2end“ průřez celou problematikou. V jednotlivých dílech představí jednoduchý a názorný proces, na kterém bude ilustrován celý životní cyklus BPM, počínaje návrhem, nasazením (včetně integrace s backendovou a frontendovou částí aplikace) až po samotné sledování procesu a vyhodnocování jeho efektivity. Na základě získaných výsledků provedeme návrh vhodných úprav a následnou optimalizaci neefektivní části procesu. Seriál rovněž nastíní možnosti využití pravidel podnikání a řízení lidské interakce s procesem.
Obrázek 1: Životní cyklus BPM
Pro realizaci a optimalizaci procesu použijeme populární open-source platformy: kombinaci OpenESB + NetBeans a Intalio BPMS. Díky otevřenější povaze těchto nástrojů k BPM technikám může čtenář získat lepší povědomí o technologické stránce jednotlivých standardů a technologií než v případě komplexních komerčních řešení. Seriál současně představuje vhodnou cestu k zavedení BPM pro menší podniky, pro které jsou důležité nízké počáteční náklady a rychlé osvojení nových technologií. To jim může usnadnit případný pozdější přechod na pokročilejší komerční platformy.
Účelem seriálu není představit plně fukční a okamžitě použitelné řešení, ale spíše ukázat, že cesta k němu může vést i přes volně dostupné open-source nástroje. Pokud firma o zavedení BPM uvažuje, může seriál využít jako základ pro odstartování pilotního projektu. I proto budou články koncipovány hlavně jako praktický návod pro realizování modelového procesu s minimálními teoretickými „vsuvkami“. Předpokládáme, že frekvence jednotlivých článků bude 1-2 díly za měsíc a obsahová náplň seriálu se bude přizpůsobovat ohlasu čtenářů portálu.
Trochu teorie o BPMS
Systémy pro Business Process Management poskytují podporu pro modelování a optimalizaci business procesů v organizacích. Obsahují nástroje po pokrytí celého životního cyklu procesu - od analýzy a návrhu procesu až po jeho spouštění a monitorování. Procesy jsou navrhovány prostřednictvím grafických modelovacích jazyků, mezi nimiž se prosadila notace BPMN (Business Process Modeling Notation), de facto standard pro modelování business procesů (neznamená to ale, že by BPMN podporovaly všechny nástroje).
Mezi hlavní výhody BPMN patří čitelnost a přehlednost, což během tvorby procesu umožňuje každému (management, analytici, vývojáři) snadnou orientaci. Modely jsou poté (automaticky) převedeny do spustitelné podoby, většinou do XML jazyka BPEL (Business Process Executional Language). Po nasazení procesů na procesní server je umožněno procesy monitorovat a omezeně i zasahovat do jejich běhu.
Obrázek 2: BPMS komponenty
Nástroje pro BPM 1. 0 byly koncipovány spíše jako soubor menších komponent pro dílčí oblasti procesního modelování (návrh, spouštění), kdežto BPMS druhé generace již zahrnuje celý životní cyklus procesu a poskytuje celistvé nástroje s přívětivým uživatelským rozhraním.
Každý BPMS by měl minimálně obsahovat návrhář procesů, prostředí pro jejich spouštění, monitoring a podporu pro workflow (dlouho trvající procesy s lidskou interakcí) včetně potřebného uživatelského rozhraní (Human Task Management). Velice důležitá je podpora Business Rules, čili pravidel podnikání uložených vně procesu (databáze, XML, Excel, skriptovací jazyk), která se používají pro validační a rozhodovací akce v jeho průběhu.
Pokročilější BPMS počítají s BAM (Business Activity Monitoring) a udržováním verzí dokumentů vázajících se k procesům. Plné BPMS již vypadají jako kompletní ESB (sběrnice služeb), na níž jsou všechny komponenty napojeny, obsahují BI nástroj pro zpracování výsledků z BAM, repozitář metadat a další komponenty.
Na rozdíl od komerčních nástrojů nejsou open-source BPM platformy jednolitým komplexním nástrojem, ale buďto souborem nezávislých komponent, nebo sice jeden celistvě se tvářící nástroj, ale s omezenou funkcionalitou v porovnání s placenými alternativami. Nízké počáteční náklady jsou u těchto řešení vyváženy větším úsilím při prvotním osvojení. Je třeba zvolit a správně nastavit odpovídající technické prostředí, provést průzkum funkcí vybraného nástroje a ty, které neposkytuje, si případně doimplementovat. Vývojáři a procesní specialisté, kteří s nástrojem pracují, nejsou také tolik odstíněni od BPM technologií, musí lépe rozumět jejich principům a standardům v oblasti modelování obchodních procesů. To ale může být i výhodou a přispět k lepšímu pochopení těchto technologií, zvlášt při počátečním seznamování s BPM.
V příštím díle
se podíváme na konkrétní nástroje, jež budeme v seriálu používat a představíme si ukázkový proces, na kterém budeme BPM postupy a technologie demonstrovat.
Příspěvky
