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:
Příspěvky
