Petr Vašíček, IBA CZ
V nadcházejících dvou dílech se budeme zabývat tzv. business rules (též business pravidla nebo pravidla podnikání). V prvním z těchto dvou článků si stanovíme úsek v našem modelovém příkladě, který budeme transformovat na business pravidlo. Podíváme se také, jaké nástroje můžeme se zvoleným běhovým prostředím použít a vybereme z nich vhodného kandidáta podle našich potřeb.
Úvod do Business Rules
Business rules neboli pravidla podnikání jsou deklarativně definované příkazy tvaru „JESTLIŽE je splněna určitá podmínka TAK udělej určenou akci“. V nejčastěji uváděném příkladě se určuje míra slevy podle platební historie či typu zákazníka, pravidla je však možno použít v zásadě jakémkoliv případě, kde je potřeba nějaké rozhodnutí, ať již jde o pravidlo validační (jsou vstupní údaje validní?) či transformační (pokud vyhovují zadané podmínce, proveď následující operaci).
Business pravidla jsou typicky seskupována do množin (Business Ruleset). Například pro proces příjímání nového zaměstnance a rozhodování o typu HW, který mu bude přidělen, může množina pravidel (ruleset) obsahovat pravidla jako „pokud je administrativní pracovník, dostane pracovní stanici“, „pokud je programátor a zároveň jeho pozice je senior developer, dostane notebook“ apod.
Business pravidla tedy pokrývají určitá rozhodnutí, jež jsou součástí procesu. Business procesy se čas od času mohou měnit – ať již na základě požadavku na faktickou změnu v procesu, či jeho optimalizací na základě výsledků monitorování. Tento proces (návrh změny, validace, aktualizace modelu, implementace, testování, nasazení) však bývá poměrně zdlouhavý, přitom business pravidla jsou dynamičtější než samotný proces a v určitých případech se jejich zadání může měnit velice často. Namísto jejich deklarace přímo v procesu se tedy vyplatí uchovávat je v externím repozitáři, ke kterému proces přistupuje prostřednictvím nějakého nástroje. Ten umožňuje přijmout vstupní data, načíst z repozitáře příslušná pravidla, ty vyhodnotit a výsledek zaslat zpět. Tento nástroj se nazývá Business Rules Engine (BRE).
Ilustrace 1: Architektura BRMS
Pro integraci v SOA je potřeba aby Business Rules Engine umožňoval vystavit business pravidla jako webové služby a nepostradatelná je i webová administrace, jež umožní okamžitou změnu pravidel a je přehledná i pro netechnické pracovníky. Tento pokročilejší systém se nazývá BRMS (Business Rules Management systém) a bývá obvykle součástí pokročilejších BPMS.
Trendem při modelování business procesu je právě transformovat všechna místa, jež by mohla být předmětem změny, do business pravidel. To umožní flexibilní změnu chování procesu bez nutnosti jeho znovunasazení. Samotná změna pravidla pak obnáší pouze přenastavení potřebných parametrů a nasazení pravidla, což je obvykle záležitostí jednoho kliknutí. Změna se projeví okamžitě a všechny instance procesů, co od té chvíle projdou rozhodovacím bodem, se budou řídit novým nastavením.
Pravidla pracují s různými objekty a atributy, které se vyskytují v business procesu a je obvykle možné navázat je i na okolní prostředí, jako datum, čas, dny v týdnu, organizační struktura ve firmě apod.
Limit schvalování žádosti
Vraťme se nyní k našemu příkladu schvalování žádostí a zaměřme se na okamžik rozhodování, kdy se podle ceny objednávky určí, zda ji bude po technickém oddělení schvalovat i finanční ředitel. Prahová hodnota (tzv. threshold) je nastavena na 40.000 Kč. Tato hodnota může typicky být předmětem změny. Finanční ředitel bude chtít například nastavit, že chce schvalovat již objednávky nad 20 tisíc Kč. Nebo naopak může (například díky monitorování) vyjít najevo, že poměrně velká část objednávek se pohybuje těsně nad hranicí 40 tisíc Kč. V takovém případě může finanční ředitel naznat, že při zvýšení limitu na 45 tisíc Kč dojde k výraznému snížení jeho práce na objednávkách a také zrychlení procesu schvalování objednávek. Přitom riziko, že firma nevhodně vydá prostředky pro nákup zboží, vzroste jen nepatrně.
Ilustrace 2: Výsek BPMN diagramu s rozhodováním o ceně objednávky
Hraniční hodnota ceny objednávky může tedy být často se měnící veličina v našem procesu. Pokud bychom chtěli tuto hodnotu změnit, museli bychom otevřít vývojové prostředí, příslušný BPEL projekt, provést změnu v BPEL kódu, validovat jeho správnost a provést deploy do běhového prostředí. To s sebou nese riziko chybně provedené změny, problémy při znovunasazení procesu či nekompatibilitu s již běžícími instancemi staré verze procesu. Navíc to není typ úkonu, který očekáváme u netechnického pracovníka. Řešením tedy bude umístit rozhodovací bod mimo proces a transformovat jej do business pravidla, což umožní jeho flexibilní změnu v reálném čase.
Výběr vhodného nástroje
Do našeho BPMS můžeme integrovat takřka jakýkoliv systém pro správu business pravidel, otázkou je pouze kolik úsilí chceme na tuto integraci vynaložit. I kdybychom vzali jednoduchý engine, který bude schopen vyhodnocovat pravidla na základě nějakého vstupu, není nijak velký problém napsat pro něj vlastní prezentační vrstvu a konektory pro webové služby, aby mohl pravidla využívat i proces zapsaný v jazyce WS-BPEL. Nic nebrání ani vytvoření vlastního BRE. Rozhodně je však lepší vzít nějaký již osvědčený produkt, kterých je na poli open source několik.
OpenRules
Jedním z těchto je OpenRules, jenž používá jako základní nástroj pro zadávání dat Excel. Jedná se o jednoduché prostředí s krátkou dobou potřebnou pro jeho zvládnutí. Pravidla jsou v OpenRules definována v rozhodovacích tabulkách, jenž jsou dobře zpracované a přehledné, nicméně problém může nastat se specifikací komplexnějších pravidel. Rovněž není zajištěna podpora databází, tu je třeba si případně doimplementovat. Také absence webového rozhraní by vyžadovala větší pracnost při integraci v našem řešení.
OpenLexicon
Dalším, a velmi populárním, open source nástrojem pro řízení business pravidel je OpenLexicon. Ten poskytuje přehledné webové rozhraní pro správu pravidel a jejich množin, zorientuje se v něm poměrně snadno i netechnický uživatel. Upravení pravidla má okamžitou platnost bez nutnosti rekompilace, což bývá často považováno za stěžejní funkci. Co se týče využití systému pro externí aplikaci, nabízí OpenLexicon přístup přes webovou službu.
Drools
Jako poslední variantu si uvedeme Drools, což je nástroj pro business pravidla od Jboss. Drools poskytuje pokročilý editor pravidel na bázi Eclipse, nabízí ovšem i velice dobře vypadající webové rozhraní pro editaci a tvorbu nových pravidel. Webová aplikace je doporučena k nasazení na JBoss AS, ale fungovat by měla na kterémkoliv aplikačním serveru či servletovém kontejneru. Největším problémem Drools při nasazení do SOA architektury je problematičtější vystavování pravidel jako webových služeb. To je třeba nyní dělat manuálně, automatické vystavení webové služby pro nové pravidlo je plánováno do budoucna.
Vhodné varianty z tohoto krátkého přehledu jsou dvě. Jednou z nich je OpenLexicon, jehož použití si ovšem necháme na pokračování seriálu s Intalio BPMS a zvolíme druhou možnost, kterou je Drools. To má o něco přívětivější uživatelské rozhraní, jediné co budeme muset řešit navíc je jakýsi prostředník, který jednotlivá pravidla zpřístupní přes operace webové služby. To z důvodu, abychom mohli k pravidlům přistupovat z BPEL procesu. Vytvoření tohoto prostředníka ale není nic složitého, navíc získáme lepší kontrolu nad komunikací s BRMS, můžeme operaci volat pouze s parametry, které budeme opravdu potřebovat apod.
Ilustrace 3: Ukázka prostředí Drools BRMS
Implementaci tohoto „prostředníka“ detailně popisovat nebudeme, jedná se o jednoduchou webovou službu, která jednoduše přijme vstup s parametry pro dané pravidlo, získá od Drools balíček s tímto pravidlem a pomocí jednoduché funkce, kterou Drools poskytuje, pravidlo s příslušnými vstupními hodnotami vyhodnotí a výsledek vrátí jako odpověď.
V příštím díle
V následujícím díle si ukážeme, jak vytvořit ve zvoleném nástroji požadované pravidlo a jak nástroj pro podporu business rules do systému zakomponovat, abychom mohli toto pravidlo používat. Jak se změna v reálném čase provádí ukážeme opět pomocí přehledného video screencastu. Podíváme se také, jak lze přizpůsobit vizuální stránku editace pravidel do již existující enterprise aplikace.
8. část: Business Rules I.
7. část: Testování a spuštění procesu
Petr Vašíček, IBA CZ Ladění procesu Na videu probíhá scénář, kdy uživatel Jan Novák objedná 6 ks LCD monitorů o celkové ceně 60.000 Kč. Následně se přihlásí do systému Jiří Technik jako zástupce technického oddělení. V seznamu objednávek ke schválení vidí novou objednávku a nechá ji schválit. Proces pak postupuje přes rozhodovací bod, kdy je cena objednávky porovnána s částkou 40.000 Kč. Jelikož je objednávka dražší, je předána k rozhodnutí finančnímu řediteli. Ten se přihlásí, nechá objednávku schválit a tím je objednávka označena za schválenou. Uvažujme nyní odlišný scénář – technické oddělení ve druhém kroku objednávku zamítne. Posloupnost operací je tedy stejná až do kroku č. 6. V sedmém kroku vyhodnotí proces objednávku jako zamítnutou a proběhne tedy posloupnost kroků:
V tomto díle si ukážeme, jak proces, jež jsme implementovali v posledním díle, otestovat a jaké možnosti skýtá jeho ladění (debugging). Dále představíme webovou aplikaci, pomocí které může uživatel s procesem interagovat. Projdeme si také různé scénáře životního cyklu objednávky a vysvětlíme si, jaké události při nich v procesu probíhají.
Testování procesu
Abychom mohli proces otestovat, musíme jej nejprve nasadit na server. Jak již bylo popsáno dříve, BPEL modul je přidán do tzv. kompozitní aplikace (souhrný projekt, skládající se z jednoho či více modulů), která je následně nasazena do běhového prostředí. Pro založení aplikace vybereme v prostředí NetBeans „New Project -> Service Oriented Architecture -> Composite Application“, zvolíme název (například „OrderingCA“) a dokončíme. Do kompozitní aplikace vložíme hotový BPEL modul pomocí „Add JBI Module...“, vše ostatní se již provede za nás. Z kontextového menu projektu pak vybereme „Deploy“ pro nasazení na aplikační server Glassfish. Pokud nechcete kompozitní aplikaci vytvářet, můžete si ji jako kompletní projekt stáhnout z této adresy. Jsou v ní obsaženy i všechny testy, bude ovšem zřejmě nutné specifikovat v nastavení cestu k umístění BPEL modulu, pokud nebudou oba projekty ve stejném adresáři.
Nyní již můžeme vytvořit testy. Proces má celkem tři vstupní operace, budou nám tedy stačit tři testy. V každém z nich definujeme vstup do dané operace pomocí SOAP zpráv v XML formátu a požadovaný výstup, podle kterého se zkontroluje skutečný výstup, který nám testovaná operace vrátí. Pokud se výstupy shodují, je test vyhodnocen jako úspěšný. Musíme mít však na paměti, že u operace, která nám pokaždé vrátí jinou zprávu (například naše operace createOrder vrací identifikátor nově založené objednávky, který je pochopitelně vždy jiný), se výstupy shodovat nebudou a výsledek operace tak musíme zkontrolovat sami.
Při vytvoření testu je připravena vstupní zpráva, do které doplníme požadované hodnoty. Při testování operace createOrder vyplníme identifikátor osoby, která objednávku zakládá, identifikátor položky a kvantitu. Příklad vyplněné vstupní zprávy lze vidět na následujícím obrázku:
Pokud tento test spustíme, je vytvořena objednávka na zboží s identifikátorem „1“ - notebook. Objednatelem je v tomto případě Jan Novák (identifikátor „1“ v tabulce uživatelů) a zboží je objednáno v množství dvou kusů. Odpověď na tuto zprávu obsahuje jediný parametr, a to sice identifikátor nově vytvořené objednávky. Výstupní SOAP zpráva tedy vypadá takto:
Podobně vytvoříme testy i na zbylé dvě operace, techDecide a findirDecide. V obou případech vyplníme ve vstupní zprávě identifikátor objednávky a typ rozhodnutí (approve/decline) a ve výstupní zprávě je pouze příznak zpracování požadavku, pravdivostní hodnota „true“. Otestování jednoho scénáře procesu tak může vypadat následovně:
Ladění procesu (tzv. debugging) nám poskytne cenné informace o běhu procesu a umožňuje jednoduše vystopovat a lokalizovat chyby, které v něm nastávají. Pomocí debuggingu můžeme proces postupně „odkrokovat“ a zjistit jak se chová, kterou větví prochází apod. Rovněž máme přístup k proměnným, které jsou v procesu použity a můžeme sledovat, jak se v nich mění hodnoty po provedení různých akcí.
Ilustrace 1: Ladění BPEL procesu v NetBeans IDE
V prostředí NetBeans můžeme ladění využít, pokud jsme nastartovali server v debuggovacím módu a připojili BPEL debugger (pomocí „Attach debugger“). Do procesu zaznačíme body přerušení (tzv. breakpoints), na kterých se nám proces automaticky zastaví. Při spuštění procesu, ať už testováním nebo standardní cestou přes klientskou aplikaci, je pak umožněno jeho ladění. Pokud proces projde bodem přerušení, je jeho tok pozastaven dokud uživatel neprovede nějakou akci. Touto akcí může být pokračování běhu (resume) nebo posunutí k dalšímu kroku (step). V okamžiku, kdy je proces přerušen jej můžeme podle potřeby zkoumat, např. prohlížet hodnoty v proměnných. To je zvláště přínosné při testování (i neúplného) procesu, lokalizaci chyb a podobných činnostech.
Klientská aplikace
Poslední ze základních komponent systému, která nám chybí, je klientská aplikace. Ta podle zásad SOA přistupuje k funkcionalitě backendu a procesu přes webové služby. Ve skutečnosti aplikace nepozná, zda se za webovou službou skrývá BPEL, modul v Javě nebo jinak zapsaná business logika. Díky tomu je například možné zaměnit implementaci služby za jinou, aniž bychom museli provádět rozsáhlejší změny v klientské aplikaci (tedy za předpokladu, že zachováme rozhraní této služby). Klientská aplikace může být buďto desktopová (tlustý klient) nebo častěji webová (tenký klient). Díky univerzálnímu přístupu přes webové služby může být naprogramována v libovolném jazyce. Vhodným řešením pro firemní webovou aplikaci postavenou na principech BPM a SOA může být například portál.
Nyní se vraťme k našemu příkladu. Abyste si proces založení objednávky mohli vyzkoušet v praxi, připravili jsme pro vás jednoduchou webovou aplikaci, jež využívá webové služby vystavené procesem a backendem. Stáhnout si ji můžete opět z této adresy. Při instalaci postupujte podobně jako v případě backendového modulu – ve webové administrační konzoli vyberete záložku Web Applications, zvolte Deploy, zadejte cestu k souboru OrderingWeb.war a potvrďte.
Aplikace umožňuje proklikat základní scénáře s vytvořením objednávky a následným schválením či zamítnutím uživatele systému z technického oddělení, popřípadě finančním ředitelem, pokud je objednávka na zboží nad 40.000 a projde prvním schvalovacím krokem. Při provedení nějaké akce je zavolána webová služba, kterou implementuje BPEL, je provedena sekvence činností definovaných v procesu a je zaslána odpověď zpět klientovi. Jak práce s webovou aplikací probíhá a co se děje během ní v procesu je názorně zachyceno na videu, které můžete shlédnout na této adrese.
Ilustrace 2: Náhled video prezentace webové aplikace
V systému jsou připraveni tři uživatelé:
Scénáře běhu procesu
Pojďme se nyní podívat blíže na to, co probíhá v životním cyklu procesu. V následující tabulce můžete vidět posloupnost operací které probíhají v jednotlivých komponentách systému při výše popsaném scénáři. Každá komponenta vlevo vždy volá operaci komponenty v tabulce napravo od ní. V závorce za popisem akce je uveden název této operace:
7. BPEL: Vyhodnocení rozhodnutí – zamítnuto
8. BPEL: Změna stavu objednávky na DISPPROVED (setOrderState)
9. Backend: Nastavení stavu objednávky v DB
Nyní si vezmeme ještě třetí variantu scénáře – objednávka je pouze na 3 ks LCD monitorů a její celková cena je tedy 30.000 Kč. Posloupnost bude nyní stejná jako v prvním případě až do kroku č. 9, po kterém dojde k odlišnému vyhodnocení podmínky, týkající se ceny objednávky. Posloupnost kroků tedy proběhne následovně:
10. BPEL: Vyhodnocení ceny objednávky – pod 40.000 Kč
11. BPEL: Změna stavu objednávky na APPROVED (setOrderState)
12. Backend: Nastavení stavu objednávky v DB
V příštím díle
Příště se budeme zabývat tzv. business rules (též business pravidla nebo pravidla podnikání). Podíváme se, jaké nástroje například můžeme se zvoleným běhovým prostředím použít a ukážeme si, jak nástroj pro podporu business rules do systému zakomponovat. Součástí bude opět krátké video, které ukáže změnu pravidla v našem procesu a to, jak se změna při procházení scénáře projeví.
6. část: Implementace procesu v BPEL
Petr Vašíček, IBA CZ
V tomto díle si nejprve představíme backendovou část aplikace, která obsahuje funkcionalitu pro práci s objednávkami. Ukážeme si pro představu diagram tříd a rozhraní webové služby, kterou tento modul poskytuje. Uvedeme instrukce pro stažení a deploy backendového modulu na aplikační server, abychom webovou službu mohli využít z business procesu.
Ve druhé části rozdělíme BPMN proces založení objednávky do několika úseků, které následně převedeme do jazyka BPEL. Nebudeme se zabývat přílišnými detaily při implementaci procesu ani si uvádět návod jak přesně tento konkrétní proces v prostředí NetBeans „naklikat“, místo toho nastíníme obecný postup při tvorbě BPEL dokumentu z BPMN modelu, jak vše napojit na webové služby a úspěšně nasadit a spustit v aplikačním serveru. BPEL modul i kompozitní aplikaci samozřejmě nabídneme ke stažení, abyste si mohli příklad vyzkoušet v praxi.
Tento díl je již hodně o IT, BPEL a programování v Java EE. Podle ohlasů na předchozí díly se dá očekávat, že mu část čtenářů nebude rozumět (hlavně vyhranění „procesáři“), takže nevěšte hlavu a berte to jako ilustraci toho, co se v IT musí udělat, než se BPMN „omalovánce“ vdechne život.
Objednávkový modul
Backendová část naší aplikace bude implementována pomocí Enterprise Java Beans 3.0, tedy standardu pro vývoj distribuovaných aplikací v jazyce Java. V projektu budeme pracovat se čtyřmi entitními beany (v praxi databázovými tabulkami). Nyní si uvedeme o jaké půjde a jaké vlastnosti (sloupce tabulky) budou kromě identifikátoru (primárního klíče) mít: 
Ilustrace 1: Diagram tříd objednávkového modulu
Při určení rozhraní webové služby, kterou bude modul poskytovat můžeme vycházet z potřeb business procesu a webové aplikace. Když se podíváme na BPMN diagram vidíme tři typy akcí jež proces volá na backendu – uložení objednávky, nastavení role k posuzování objednávky a označení stavu objednávky. Kromě těchto tří metod budeme ve webové službě potřebovat implementovat i metody pro webovou aplikaci – získání informací o uživateli, položce a objednávce, získání seznamu všech uživatelů, položek a objednávek a seznam objednávek podle zakladatele a schvalovatele. Místo entit bude modul vracet tzv. data transfer objekty (DTO), jenž budou mít veškeré vlastnosti, které budeme u entit ve webové aplikaci potřebovat. V rozhraní webové služby se tedy budou nacházet následující operace:
Ilustrace 2: Rozhraní webové služby objednávkového modulu
Nyní si popíšeme, jak provést deploy modulu na aplikační server. Nejprve si stáhněte z této adresy distribuční Java archív OrderingModule.jar. Pro jeho nasazení na server nejprve server spusťte z prostředí NetBeans aplikační server Glassfish (Services -> Servers -> Glassfish V2 -> Start). Následně otevřete administrační konzoli serveru (na adrese http:/localhost:4848/, přihlašovací údaje admin / adminadmin), na pravé straně vyberte z nabídky Applications -> EJB Modules a v hlavní části webové stránky zvolte „Deploy“. V části „Location“ vyberte umístění staženého Java archívu a zvolte „OK“.
V současné chvíli by již měly být v databázi připravené tabulky pro jednotlivé entity. V záložce Services v prostředí NetBeans vyberte „Databases“, nalezněte databázi s názvem sample (název zdroje „jdbc:derby://localhost:1527/sample“ a z kontextového menu zvolte „Connect...“. V záložce „Tables“ můžete zkontrolovat existenci tabulek ITEMENTITY, ORDERENTITY, ROLEENTITY, USERENTITY, a USERENTITY_ROLEENTITY. Nyní ještě potřebujeme naplnit tabulku rolí, uživatelů a položek testovacími údaji. Stáhněte si z této adresy sql skript pro naplnění těchto tabulek. Po kliknutí pravým tlačítkem na databázi sample vyberte „Execute Command...“, do textového pole vložte obsah staženého souboru create.sql a spusťte příkaz ikonkou se zelenou šipkou v pravé horní části obrazovky. Po provedení příkazu by měly být tabulky naplněny, což můžete zkontrolovat zvolením „View Data...“ v kontextových nabídkách jednotlivých tabulek.
Jako poslední zkontrolujeme správné nasazení webové služby modulu. Otevřeme v prohlížeči adresu http://localhost:8080/OrderWSService/OrderWS?wsdl a měli bychom uvidět definici webové služby ve formátu XML, včetně definice všech operací, které jsme si uvedli výše. Nyní je tedy ze strany backendového modulu vše připraveno a můžeme začít s implementací samotného procesu.
Implementace procesu
Jako předlohu pro tvorbu BPEL dokumentu si vezmeme proces namodelovaný pomocí notace BPMN ze 4. dílu. Rozdělíme si jej do tří částí, které budeme postupně převádět do implementační formy. První úsek jsme již částečně naimplementovali minule, pouze jsme vynechali vazbu na webovou službu backendu. Proces bude mít celkem tři vstupy, to znamená, že webová služba, která bude představovat rozhraní procesu, bude mít tři operace – vytvoření objednávky (createOrder), rozhodnutí technického oddělení (techDecide) a rozhodnutí finančního ředitele (findirDecide).
Ilustrace 3: BPMN proces rozdělený na jednotlivé části
Po vytvoření BPEL modulu a BPEL procesu v něm je třeba vytvořit WSDL soubor, jež slouží k popisu webové služby procesu a který bude definovat zmíněné tři operace, dále pak XSD soubor, jenž popisuje použité datové typy. Postup tvorby těchto souborů si uvádět nebudeme, budou ale k dispozici hotové spolu s celým projektem. Nyní již zbývá pouze naimportovat WSDL a XSD soubor k webové službě backendu. Z kontextové nabídky BPEL projektu vybereme New -> Other a pak z kategorie XML zvolíme External WSDL Document(s) a stiskneme tlačítko „Next“. Do textového boxu zkopírujeme adresu, na které se nachází definice webové služby objednávkového modulu, tedy http://localhost:8080/OrderWSService/OrderWS?wsdl a stiskneme „Finish“.
Nyní již máme v projektu všechny potřebné soubory a k začátku implementace procesu nám chybí pouze vytvořit v BPEL dokumentu odkazy na obě použité webové služby, tedy partner linky. Otevřeme tedy (příp. vytvoříme) soubor startOrder.bpel a do okna, které se otevře, přetáhneme oba WSDL soubory, tedy startOrder.wsdl a OrderWS.wsdl. První partner link můžeme pojmenovat například „Interface“ (rozhraní procesu) a druhý „OrderModule“ (webová služba objednávkového modulu).
První část
První část je v obrázku ohraničen červenou čárou. Proces je odstartován přijetím požadavku na vytvoření objednávky, tedy v BPMN objekt Start Message Event. V BPELu je alternativou k tomuto objektu aktivita Receive, tu tedy umístíme na začátek procesu a navážeme ji na operaci createOrder v partner linku Interface. Následně musí proces provést dvě aktivity – vytvořit objednávku (uložit ji do databáze) a nastavit jako schvalovatele technické oddělení. Tyto aktivity, tedy vyvolání webových služeb, lze v BPELu realizovat pomocí objektu Invoke. První task (nazveme jej „Create“) zavolá operaci createOrder v partner linku OrderModule a předá ji data, která zaslal uživatel. Druhá pak volá operaci setApprover a té předá unikátní textový identifikátor dané role, tedy v našem případě „tech“. Nakonec vrátíme uživateli odpověď, jež obsahuje ID nově vytvořené objednávky. To provedeme pomocí BPEL aktivity Reply. Pro manipulaci s proměnnými využijeme dvou aktivit typu Assign – AssignOrderDetails a AssigntTechApprover. Jak vypadá první část lze vidět na následujícím obrázku:
Ilustrace 4: První část BPEL procesu
Druhá část
V druhé části procesu zpracujeme rozhodnutí technického oddělení a na jeho základě označíme objednávku za schválenou či zamítnutou. Rozhodování finančního ředitele si necháme až do poslední části. V BPMN modelu je na začátku druhého úseku objekt typu Message Intermediate Event, který mapujeme do aktivity Receive (pojmenujeme „ReceiveTechDecision“) a spojíme jí s operací techDecide v partner linku Interface. To znamená, že pokud webový klient zavolá tuto operaci a proces čeká v aktivitě ReceiveTechDecision, tak bude přijata zaslaná zpráva (obsahující identifikátor objednávky a rozhodnutí technického oddělení) a proces bude pokračovat dále.
Nyní budeme chtít uživateli vrátit zprávu (operace techDecide je typu request – response), to učiníme opět pomocí aktivity Reply a obsahem této zprávy bude pouze pravdivostní hodnota „true“. Dále následuje v BPMN diagramu Data-based Exclusive Decision, tedy rozhodnutí na základě dat, jež je v BPELu zastoupeno aktivitou If. Tu tedy vložíme do procesu a pomocí BPEL mapperu (editor pro přiřazení proměnných) navolíme podmínku pro první větev rozhodování. Můžeme využít vizuálních prvků a pomocí nich navolit podmínku „ReceiveTechDecision.type = approve“ tak, jak je to vidět na následujícím obrázku:
Ilustrace 5: Rozhodnutí technického oddělení
Pokud tedy technické oddělení objednávku schválilo, proces projde první větví, v opačném případě druhou. Podle toho musíme označit objednávku za schválenou či zamítnutou. Do první větve tedy umístíme aktivitu AssignApproved a do druhé AssignDeclined, ve kterých přiřadíme příslušný konečný stav objednávky. V BPMN diagramu máme označení objednávky za schválenou či zamítnutou ve dvou aktivitách, po nichž následuje konec procesu (End Event). Při převodu do BPELu můžeme buďto ponechat obě aktivity zvlášť (jedna Invoke aktivita v každé větvi), nebo je sloučit do jedné (jeden Invoke po sloučení větví), s tím, že v jednotlivých větvích přiřadíme příznak schválení či zamítnutí do vstupní zprávy volané operace webové služby backendu SetOrderState. My zvolíme druhou možnost a pod sloučení větví přidáme Invoke aktivitu SetFinalOrderState, která zavolá příslušnou operaci v objednávkovém modulu a nechá změnit stav objednávky podle předchozího určení. Druhá část je tedy hotova, pokračování implementovaného procesu opět můžete vidět na obrázku.
Ilustrace 6: Druhá část BPEL procesu
Třetí část
Nyní by byl proces kompletní, pokud bychom chtěli, aby o objednávce rozhodovalo pouze technické oddělení. Proces tedy upravíme tak, aby v určitém případě musel rozhodovat i finanční ředitel. Poslední část procesu je v BPMN modelu ohraničena zelenou čárou. Prvním elementem je rozhodování podle částky, což už víme, že je v BPELu realizováno pomocí aktivity If. Nejprve ovšem musíme cenu objednávky zjistit. Jelikož je v objednávce pouze jeden druh zboží, získáme informace o něm včetně ceny zavoláním operace GetItemDTO ve webové službě backendu. Tato operace nám vrátí cenu objednané položky, kterou znásobíme objednanou kvantitou (tu zadal uživatel při vytváření objednávky) a tak získáme celkovou cenu objednávky. Vyvolání zmíněné operace i rozhodovací prvek vložíme do té větve, která značí případ, kdy objednávka byla schválena technickým oddělením (ve druhé větvi ponecháme pouze aktivitu AssignDeclined). Celkovou cenu objednávky porovnáme s částkou 40.000, čímž se nám proces rozdělí do dvou větví – když je částka větší a když je stejná nebo menší. Následující obrázek ukazuje, jak vypadá výraz, podle kterého se vyhodnocuje rozhodnutí o ceně objednávky:
Ilustrace 7: Rozhodnutí podle ceny objednávky
Zbytek procesu si již popíšeme stručně, jelikož rozhodnutí finančního ředitele je obdobou předchozího rozhodnutí technického oddělení. Nejprve tedy nastavíme objednávku k posouzení vyvoláním operace setApprover a čekáme na přijetí rozhodnutí v Receive aktivitě na operaci findirDecide. Následně provedeme obdobné rozhodnutí podle schválení či zamítnutí objednávky, jako v předchozím případě. Pozor si musíme dát na to, aby v každém z možných průchodů procesem (celkem jsou čtyři) byl správně určen konečný stav objednávky. Následující obrázek ukazuje kompletní proces implementovaný v jazyce BPEL tak, jak jej umožňuje vizualizovat BPEL designer v prostředí NetBeans IDE. Kompletní projekt, který obsahuje veškeré potřebné soubory, si můžete stáhnout z této adresy.
Ilustrace 8: Kompletní BPEL proces
V příštím díle
Příště si ukážeme, jak implementovaný proces otestovat a jaké možnosti skýtá jeho ladění (debugging). Dále představíme webovou aplikaci, pomocí které může uživatel s procesem interagovat. Projdeme si také různé scénáře životního cyklu objednávky a vysvětlíme si, jaké události při nich v procesu probíhají.
Příspěvky
