7. část: Testování a spuštění procesu

Petr Vašíček, IBA CZ

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

1. Spustíme test na operaci createOrder z výše uvedenými parametry (2x notebook). Vrátí se nám identifikátor nové zprávy. V databázi můžeme zkontrolovat, že se skutečně založil záznam s objednávkou.
2. Spustíme test na operaci techDecide, jako parametry uvedeme identifikátor objednávky a rozhodnutí o objednávce „approve“.
3. Jelikož byla objednávka na 2 notebooky o ceně 30.000, je celková cena vyšší jak 40.000 a je vyžadováno schválení finančním ředitelem. Proces nyní tedy čeká na zavolání operace findirDecide, jíž předáme stejné parametry jako předchozí operaci. V databázi pak můžeme zkontrolovat, že je již objednávka ve stavu „APPROVED“.

Ladění procesu

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é:

• Jan Novák – role: zaměstnanec
• Jiří Technik – role: zaměstnanec, technické oddělení
• Josef Ředitel – role: zaměstnanec, finanční ředitel

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.

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:

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ů:

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í.