business process management - atw.huusers.atw.hu/infnav/informatikai-navigator-05.pdfsabb a bpm...

2011. Október

Informatikai NavigátorGondolatok a szoftverek használatáról és fejlesztésérőll

Business Process Management

5. szám

Informatikai Navigator Gondolatok a szoftverek használatáról és fejlesztéséről

Tartalomjegyzék1. Bevezető az üzleti folyamatokhoz 3

2. Workflow tervezési minták 11

3. Business Process Management Notation 24

4. A Bonita Workflow motor áttekintése 40

5. Bonita - A munkafolyamatok tervezése és megvalósítása 46

6. Bonita - GUI készítése humán feladatokhoz 62

7. Bonita - Az egységes feladatkosár (User Experience) 72

8. Bonita - Konnektorok készítése 80

9. A Bonita produktív környezet telepítése 91

10.A folyamatszervezési módszertan rövid áttekintése 97

11.A Groovy programozási nyelv rövid áttekintése 104

12.Bonita - A folyamatok szimulációja 113

13.A BPM megközelítés 10 aranyszabálya 119

14.Bonita - Tippek és Trükkök 121

15.A Bonita API használata 130

Főszerkesztő: Nyiri Imre ([email protected])

2

Business Process Management Bevezető az üzleti folyamatokhoz

1. Bevezető az üzleti folyamatokhoz

Minden vállalatnak, függetlenül a méreteitől és az iparági hovatartozástól, vannak üzleti folya-matai. Egyre többen ismerik fel a szolgáltatásalapú architektúra (SOA) és az eseményvezéreltműködési modell előnyeit. Az üzleti funkciók mögötti szolgáltatások nyílt szabványú felhasználásaés ezáltal az üzleti folyamatok hatékonyabb támogatása, összetett folyamatok gyors és rugalmasképzése nagymértékben javítja az üzleti versenyképességet. Ezen célkitűzések hatékony informati-kai támogatása az IT részleg feladata.

A szervezéselmélet talán legtöbbet hangozta-tott elve a Cél→Folyamat→Szervezet egysége,ebben a sorrendben következve egymásból. Aszervezetek kiemelkedő értékei közé tartoznakazok az üzleti folyamatok, amelyek képesek ver-senyképesen fenntartani a működésüket. ABusiness Process Management (BPM ) fegyver-tára szervezési módszerekből, informatikai ter-vező eszközökből és technológiákból áll. Mindezegyütt hatékonyan támogatja az üzlet és infor-matikai részleg eddigieknél együttműködőbb kö-zös munkáját.

A BPM meghatározása

Alapelvek

A BPM egy olyan megközelítés, amely tudato-san felismeri és tudományos módszerekkel pró-bálja támogatni a folyamatok építését és fejlesz-tését. A BPM-nek van néhány fontos alapelve(BPM Fundamentals), ezek a következőek (zá-rójelbe tettük az angol kulcsszavakat):

• Rugalmas (flexible) és alkalmazkodó(adaptive) folyamatokra kell törekedni.

• Az átláthatóság (visibility) és ellenőrzés(control) lehetősége mindig legyen be-építve.

• A folyamatok lehetőleg legyenek szabá-lyozottak (standards) és megismételhetőek(repeatable).

• A folyamatok végrehajtása szimulálhatólegyen (simulation), ezzel tesztelve és op-timalizálva (optimization) azt.

• Szerepalapú kompozit alkalmazásokkal le-gyen támogatható (Workflow applica-tions).

Az üzleti folyamatok vizsgálatának fontosabbnézőpontjait a 1.1. ábra mutatja.

1.1. ábra. BPM perspektívák

A BPM megközelítés (BPM Approach)

A BMP alapú szervezeti működés a jól ismertmérni és tökéletesíteni elvre épül, ami részlete-sen a következő tevékenységek időközönként valóelvégzését jelenti:

3


1. Az üzleti célok beazonosítása és mérniazok teljesülését néhány kifejező KPI (KeyPerformance Indicator) segítségével

2. Mindenki azt mérje ahol dolgozik

3. Meghatározni, hogy mi az ami hasznos ésmi az ami nem

4. Javítani és tökéletesíteni a problémás te-rületeket

5. Az értékteremtés folyamatos számítása

A BPM funkcionális moduljai

A BPM kialakulása során a következő funkcio-nális modulok kristályosodtak ki:

• Mérések : A folyamat valós idejű átlátha-tósága, monitorozása.

• Portálok : Integrált felhasználói felületek aworkflow alkalmazásokra. Egységes mun-kakosár használata.

• Modellezés : A workflow-k és humán task-ok tervezése, ehhez informatikai eszközhasználata.

• Leíró adatok (Metadata): A folyamatok ésazok jellemzőinek leíró adatbázisa.

• Szimuláció: A folyamat modell használa-tával a process vizsgálata különféle konfi-gurációkra és input adatokra.

• Analízis : A folyamatok statisztikai és gra-fikus vizsgálatai.

• Integration: Kapcsolatok kiépítése az em-berekkel, információs rendszerekkel, szol-gáltatásokkal és más folyamatokkal.

• Execution: A folyamatok hangolása a va-lós idejű igényekhez.

Egy folyamat definiálása

A gyakorlatban a folyamatok azonosításához ésleírásához sokat segít a SIPOC modell (1.2.ábra). Suppliers, illetve Customers lehet min-den olyan egyén, rendszer, funkció (azaz entitás)amelyek képesek inputot vagy outputot szolgál-tatni az üzleti folyamat számára. A processezeket az inputokat transzformálja output érté-kekre. Az input lehet anyag, energia, informá-ció, bármilyen eszköz. Az elsődleges output az,amire a customer-nek szüksége van, ugyanakkormindig vannak veszteségek és egyéb mellékter-mékek is.

1.2. ábra. SIPOC megközelítés

A BPM architektúrája

Három nézőpont létezik, ezek a következőek:

• Business architektúra (az érték dimenzió):A vevők és egyéb érdekeltek (stakeholders)elvárásaiból levezetett célok rendszerezettegyüttese, amikhez stratégiák, felelősök ésszerepkörök rendelése szükséges, hogy el-érhessük őket. Itt az értékteremtésen vana hangsúly, azaz olyan folyamatokra vanszükség, amik a hatékony termelést, fej-lesztést és a fenntartható növekedést való-sítják meg.

• Process architektúra (a transzformáció di-menziója): A célok eléréséhez kiépített ésstrukturált tevékenységekből álló folyama-tok eljárásai, szabályai, kialakult jógyakor-latok. Mindehhez emberi erőforrások és

4


tőke van rendelve valamilyen mértékben ésidőbeli eloszlásban. Itt kialakult néhányfontosabb vizsgálati szempont: a folyamathatékonysága, átláthatóság és mérhetőség(BAM = Business Activity Monitoring) ésa folyamat agilitásának foka (a kivételesesetek kezelésének hatékonysága).

• Management architektúra: A vezetés alap-vető felelőssége a működő folyamatok ki-alakítása és menedzselése. Elemezni kella bennük résztvevő emberek, rendsze-rek viselkedését, a folyamatok működésé-nek negatív jellemzőit, az idők túllépé-seit. Szükség esetén a processek újra-tervezése is megtörténik. Ez néha na-gyobb, az egész céget átfogó BPR (Busi-ness Process Reengineering/Redesign) te-vékenységet is jelenthet. A BPR mód-szertana valamikor az 1980-as évek végénszületett, itt most nincs lehetőség az eb-ben való elmélyülésre. Az 1.3. ábra afolyamatok életciklusát szemlélteti. Érde-mes még megemlíteni a CPI1 folyamatosmunkafolyamat tökéletesítési módszereketis, mint a Lean (http://hu.wikipedia.org/wiki/Lean) és Six Sigma (http://en.wikipedia.org/wiki/Six_Sigma).

1.3. ábra. Business Process életciklus

A BPM üzleti motivációja

A kutatások szerint a BPM hatékonyan képestámogatni az üzletmenet működését, ugyanis né-hány szempontból olyan üzleti kihívásokat képeskezelni, ami ezen megközelítés használata nélkülnehezebben vagy talán nem is lehetne elérhető.Melyek ezek a kategóriák? A következőkben eztfoglaljuk össze röviden.

Napjaink üzleti elvárásai

A globalizáció mindenki részéről ismert jelenség,amit az alacsonyabb költségek, jobb minőségűtermékek (folyamatos innováció) és a nagyobbpiacon való megjelenés idéz elő. Mindez azösszetettebb működést is jelenti, amiket lehető-leg tudatos folyamatokkal kell lefedni. A piaconvaló megjelenés is egyre korszerűbb módszerek-kel kell történjen, bekapcsolva a partnereinketa folyamatainkba. A termelékenység (producti-vity) mindig fontos elvárás volt, azonban a to-vábbi növelése sok esetben már tudományosabbmegközelítést és más eszközök (például automa-tizált munkafolyamatok) bevonását igényelheti.Ez több érték előállítását jelenti, lehetőleg keve-sebb erőforrás ráfordítás mellett. A Lean mód-szer például így lett ismert, amikor a Toyota ter-melési rendszerét javították vele. Persze mindezállandó innovációt (innovation) is jelent, nemcsak az előállított termékekben, hanem az azokatelőállító termelő folyamatokban is. Az üzlet ter-mészetesen egyre gyorsabban akarja elérni eze-ket a céljait, így a gyorsaság (Speed) is kiemeltelvárás. Aki hamarabb jelenik meg egy-egy újtermékkel, nagyobb piaci szegmenst uralhat akésőbbiekben, hamarabb márkanév lehet, minta versenytársak (példa: Coca-Cola, Android te-lefon). Minden menedzsmentnek van egyfajtastílusa, amiben hisz, így a folyamatoknak is úgykell működniük, hogy azok megfelelősége (comp-liance) ezzel összhangban legyen. Egy tudatos

1CPI = Continuous Process Improvement

5


BPM építkezéssel a szabályozások és ellenőrzé-sek is jobban elvégezhetőek, így a vezetők jobbanés gyakrabban értesülnek arról, hogy a folyamatilleszkedik-e a cég elképzeléseihez. Amennyibennem, úgy azok változtatása is könnyebb, hiszena jelenlegi is egy tervezettebb módszerrel műkö-dött. Napjainkban sok információra van szük-ségünk, mindenkinek másra. A BPM segíthetiaz információk terítésének tudatos kiépítését is.Fontos, hogy változzon és alkalmazkodjon a mun-kavégzés és a környezet a modern világhoz, ami-hez számítógépes és kommunikációs eszközöketkell használni. A folyamatok automatizálása tá-mogatja a következő lépés vagy feladat megta-lálását és végrehajtásának agilis igénylését, fe-lelősökhöz és határidőkhöz rendelve. Léteznekelőre elkészített együttműködést támogató szoft-ver rendszerek, amik az általános irodai munkáttudják folyamatokba szervezni. Ilyen az Alfre-sco (http://www.alfresco.com/) vagy a Mic-rosoft SPS. Helyes üzleti gondolkodás, hogy avevő mindig az első (customer first), így a fo-lyamatok építésénél erre mindig gondolni kell.Vevőink hűsége kiemelt fontosságú.

A BPM hajtóereje

A korszerűsítendő vagy javítandó (al)folyamatoktökéletesítésének igénye szinte állandóan jelent-kezik, a gond csak az, hogy ennek megvalósításais pénzbe kerül. Így mindig szelektálni kell azo-kat az üzleti részterületeket, ahol ezt el kell vé-gezni, hiszen végesek az erőforrásaink, ugyanak-kor a javulás elmaradása pedig veszteséggel jár.Általában csak ott érdemes munkafolyamat tá-mogató keretrendszert használni, ahol ez ténylegmegtérül, így a gyakorlatban általában csak azarra érdemes alfolyamatokat szoktuk automati-zálni. Ez viszont általában hatékonyabb és gyor-sabb a BPM szemléletet követve. Az IT szer-vezetek ismerik, sok helyen már el is fogadtákés alkalmazzák a SOA megközelítést, amiről az

Informatikai Navigátor 3. számában egy teljescikket írtunk. A BPM és a SOA egymást kiegé-szítő és egymással még erőteljesebben működőeszközrendszert tud adni. A BPM megadja amódszert és a technológiai megközelítés módját,melyek SOA oldalon IT szervizként és irányítás-ként jelennek meg.

A BPM funkcionális céljai

A szakirodalomban általában ezek a deklaráltcélok vannak:

• Folyamathatékonyság

• A folyamatok jobb átláthatósága

• Termelékeny munkakörnyezet kialakítása

• A folyamat kellő agilitásának biztosítása

A BPM szemlélet feltételezi, hogy a folyamatokmenedzselésére valamilyen keretrendszert hasz-nálunk, amivel formálisan is koordináljuk a tevé-kenységeket (taszkokat), szerepköröket. Az esz-köz az elindult folyamatpéldányok online moni-torozását támogatja, ami KPI-okkal mért opti-mális működés egyik alapja lehet. Az aktuálisprocessek státusza követhető, szükség esetén au-tomatikus eszkalációk indulhatnak el. Fejlettebbhasználatkor a „What-if”, azaz „mi történne, ha”elemzéssel optimálisabbá tehetjük a folyamata-inkat. Egy-egy számítógépes workflow automa-tizálva, agilis módon segíti a business processcélhoz érését, miközben komfortossá teszi a tasz-kok elvégzését, támogatja a munkához szükségesinformációk lehetőleg gyors beszerzését. A ve-zetői kontroll és döntéshozatal is egyszerűsödikemiatt. BPM esetén a folyamat modellje nemcsak egy egyszerű design, hanem az is fog végre-hajtódni: WYMIWYR2.

2WYMIWYR = what you model is what you run

6


Az üzlet, folyamat és menedzsmentarchitektúrája

A 4. oldalon már írtunk a a BPM architektú-rájáról, ezt szeretnénk még kiegészíteni néhányhasznos további tudnivalóval. Természetesen atechnológia egymaga nem képes az üzlet igényeitkielégíteni, az csak egy eszköz. A vállalat műkö-dését érdemes olyanra kialakítani, hogy a BPMezen 3 pillére megfelelően tudja tartani azt a he-lyes irányt és működést, amit az informatika ma-napság már kiváló eszközökkel támogat.

A BPM business architektúra

Az üzleti célok teljesítésére egy szervezeti struk-túra jön létre, amiben az emberek különféle sze-repkörökben dolgoznak az értékteremtő célokmegvalósításán. Arról már esett szó, hogy üz-leti folyamat centrikusan szerveződnek a vállal-tok, ahol tervezés, termelés, pénzügy és egyébhasonló területek képezik a legfontosabb részte-rületeket. A modern cégeknél néhány érdekesszerepkör alakult ki:

• Chief Process Officer : A process architec-tek vezetője, aki felelős a vállalati folyama-tok karbantartásáért, az ilyen irányú kul-túra fejlesztéséért.

• Process Architect (Folyamatépítész): Ter-vezi és modellezi a vállalati folyamatokat,amihez általában valamilyen informatikaieszközrendszert is használ. A folyama-tok általában szabályzatok formájában ismegjelennek, ahol azok méréséhez KPI-okat határoz meg. Amennyiben egy folya-mat arra érdemes, úgy javasol(hat)ja an-nak workflow alkalmazásokkal történő au-tomatikus informatikai támogatását is.

• Business Process Owners: Egyszemélyi fe-lelős, aki a hozzárendelt folyamatok nor-mális lefutását menedzseli, ehhez intézke-dési jogköre is van.

• Process Engineers: Informatikus mérnök,aki a munkafolyamatokat támogató kom-pozit workflow alkalmazásokat készíti, an-nak bevezetésében közreműködik.

• Process Analyst : Elemző, tervező szak-ember, aki néhány üzleti területet ismerés képes definiálni az üzleti folyamatokatolyan pontossággal, hogy azt a processengineers-ek képesek legyenek automati-zált módon megvalósítani. Ők határozzákmeg a folyamatok mérföldköveit, monito-rozási igényeit is.

• Process Performers : Ők a munkafolyamat„munkásai”, akiknek a tevékenysége ered-ményezi a folyamat egy-egy példányánaka végrehajtását.

Ezek a szerepkörök nem jelentenek feltétlenülmindig külön embereket, azaz 1 ember több sze-repben is lehet. A process owner tipikusan üzletiember, aki képes felismerni a folyamattal kapcso-latos változtatási igényeket és ennek megvalósí-tásához megfelelő hatalommal rendelkezik. A fo-lyamatok pénzügyi teljesítménye a legfontosabb,amit magas szinten a következő képlettel szoktakjellemezni:

VNET = VNEW − (Cost+ Time+Waste)

VNET→ a folyamat által keletkezett nettó je-lenérték

VNEW→ A teljes megtermelt új értékA zárójelben a levonandó ráfordítások, azaz

az új folyamat létrehozásának teljes költsége, afolyamat működtetésének költsége és a veszteségvan.

IT oldalról szükséges az üzlettel való együtt-működés magasabb szintre emelése, BPM eszkö-zök biztosítása, illetve az integrációs informati-kai megoldások magas szintű biztosítása. A pro-cess engineers szerepkör tipikusan IT szaktudástigényel.

7


A BPM process architektúra

Itt az egész vállalaton átívelő értékláncok kiala-kítása a gondolkodás alakítója. A termelési ésmenedzsment támogató folyamatok a legtipiku-sabbak. A már említett process javítási meto-dológiák is (Lean, Six Sigma, SCOR) itt kapnakhangsúlyos szerepet. Fontos fogalom a processlife-cycle (élettartam), azaz a folyamatok defi-niálása, működtetése, tökéletesítése és esetlegesátalakítása, megszüntetése vagy összevonása egymásik folyamattal.

A BPM management architektúra

A már leírtakhoz csak annyit szeretnénk hozzá-tenni, hogy ide tartozik a

• projektek menedzselése (tervezés, elemzés,design, bevezetés)

• folyamatok vezetése, menedzselése és töké-letesítése (BI módszerek, BAM=BusinessActivity Monitoring)

A BPM informatikai architektúrája

A 1.4. ábra a BPM informatikai felépítését mu-tatja, amit röviden szeretnénk ismertetni. AUnified Workspace (egységes munkakörnyezet)szerepe az, hogy a munkafolyamatokban kelet-kező feladatokat (Taskokat) egységesen mutassa(mint egy levelező rendszer postafiókja). Min-den egyes feladathoz, amihez emberi közremű-ködés szükséges, tartozik egy felhasználói felü-let, hiszen valamilyen informatikai programmaldolgozni kell a feladaton. A folyamatok konkrétpéldányait (nevezik még: instance, case) moni-torozni kell, ami nem csak a folyamat státuszá-ról informál bennünket, hanem különféle KPI-okat és statisztikákat is biztosít annak működé-séről. Ez jól jön a későbbi optimalizációs törek-vésekhez. A következő logikai egység az Exe-cution Environment, ami a folyamatok lefutá-sának technológiai eszköze. Központi része a

Process Engine, azaz a folyamat motor szoft-ver elem, ez futtatja a folyamatot reprezentálóprogramot. A Business Rule Engine (Üzleti sza-bályokat tartalmazó szoftver elem) tartalmazzaazokat az üzleti szabályokat, amiket a folyamatnem sérthet meg, illetve be kell tartania. A maimodern informatikai környezetekben ez egy kü-lön szerver szoftver szokott lenni (példa: Drools,http://www.jboss.org/drools). Az AnalyticsEngine a folyamat futásának elemzését bizto-sítja, ez dolgozik a dashboard felület számárais. A harmadik egység a Simulation Engine,aminek a jelentősége ott van, hogy folyamata-inkat tesztadatokkal már akkor kipróbálhatjuk,amikor még nem vezettük be éles körülményekközé. Segíti a szűk keresztmetszetek és a feles-leges vagy hiányzó folyamatlépések megtalálá-sát. A Process Design Tools maga a fejlesztőikörnyezet, ami szabványokon alapuló modellező,tesztelő és fejlesztő eszközökből áll. A MetadataRepository a folyamatok leírásának adatbázisa,így azokat mindig leltárszerűen elő tudjuk venni.Aki ismeri az ARIS eszközt, az egy ilyen reposi-toryt ismer.

A 1.5. ábra a BPM technológiai alapmo-delljét foglalja össze. Ez egy technológiai ar-chitektúra, amin meg lehet valósítani az előb-bekben részletezett komponenseket. Aki mos-tanában foglalkozik a middleware eszközökkelazoknak az ábra egyes dobozai ismerősek lehet-nek. Legelterjedtebben az ilyen környezeteketJava (JEE=Java Enterprise Edition), ritkábban.NET környezetekben szoktak megvalósítani. A4. cikktől egy ilyen környezetet, a Java plat-formra épülő Bonitát fogjuk bemutatni. Azegyes dobozokban lévő SOA, Enterprise ServiceBus, B2B és hasonló kifejezések bizonyára min-denkinek ismerősek. Az integrációs gondolkodáskiemelkedő jelentőségű, ugyanis maguk a mun-kafolyamatok is ma már kompozit alkalmazások,amely elemek között interface-ek biztosítják akommunikációt.

8


1.4. ábra. A BPM informatikai felépítése

1.5. ábra. A BPM technológiai alapmodellje

9


Miről szólnak a következő cikkek?

Miután röviden megnéztük, hogy az üzleti fo-lyamatoknak (és a BPM megközelítésnek) mia jelentősége, tekintsük át miről szólnak a to-vábbi cikkek! A 2. és 3. írás a munkafolyama-tok tervezését segítő elméleti informatikai esz-közöket tárgyalja. A workflow tervezési mintákazért fontosak, mert megnevezik és tudatossá te-szik azon szerkezetek használatát, amik külön-ben csak mindig laikusan lennének használva.Ezekre a nevekre hivatkozva ráadásul a szak-emberek gyorsabban és hatékonyabban képesekegymással eszmét cserélni. A BPMN egy olyanszabvány, ami eszközt ad a folyamatok mérnökipontosságú lerajzolásához és annak pontos értel-mezéséhez. Az elmélet után egy konkrét BPMmotor, a Bonita vizsgálata következik. Néhány,egymást követő írás részletesen áttekinti ezt a ki-váló eszközt, amit az előzetes elméleti alapokraépítve remélhetőleg hatékonyan fogunk tudnihasználni a mindennapokban. Külön kitérünka Bonita szimulációt támogató lehetőségeire is.Áttekintjük a Bonita Studió BPMN használa-tát, a felhasználói GUI felületek készítését és azegységes munkakosár támogatást (azaz a UnifiedWorkspace támogatását). Megnézzük az eszközéles üzembe helyezési beállításait. A Bonita Javaplatformon fut, így működéséhez a Java nyel-vet hívhatjuk segítségül, amennyiben valami-lyen különleges adattípusra vagy osztályra vanszükségünk. Külön cikk foglalkozik azokkal aJava osztályokkal, amiket konnektoroknak hí-vunk, ugyanis ezek biztosítják a Bonita motorés a külvilág közötti hatékony kommunikációt,együttműködést. A Groovy script nyelv ismerte-tése azért került a kiadványba, mert a workflowműködéséhez sok rövid algoritmikus leírást vagyváltozó hivatkozást ezzel tudunk megfogalmazni,így célszerű ezt az eszközt valamennyire megis-

merni. A Bonita tippek és trükkök írás azokróla lehetőségekről szól, amik munkánk során újraés újra fel fognak bukkanni:

• autentikáció beállítások,

• jogosultságkezelés,

• Active Directory használat,

• Egy Bonita közösségi komponens telepí-tése,

• Java és XML adattípusok használata,

• stb...

Az utolsó írás a munkafolyamatok készítéséneknéhány módszertani ismeretét foglalja össze, mi-közben az ismert Best Practice-ekre is kitér.Igyekszünk bemutatni azokat a szervezői eszkö-zöket, amikkel sikerrel vághatunk bele egy-egyworkflow alkalmazás készítő projektbe. Kité-rünk a folyamatok leírásának, kidolgozásának éskonzisztencia vizsgálatának módszereire.

BPM szakirodalom

• Az Object Management Group hivatalosoldala: http://bpmi.org/

• Tartalmas BPM és SOA cikkek forrása:http://www.ebizq.net/

• Érdekes elemzések és cikkek: http://bptrends.com/

• Szakemberek egymás között: http://www.bpminstitute.org/

• A BPM vendorok írásaiból: http://www.bpm.com/

10

Business Process Management Workflow tervezési minták

2. Workflow tervezési minták

A munkafolyamatok tervezése során modellező eszközt használunk, ami nagyban segíti az összetettfolyamatok áttekinthetőségét, illetve egy közös nyelv kialakítását az üzleti terület képviselőivel. Amunkafolyamatok tervezése során észrevették, hogy sok visszatérő jógyakorlat van, amit érdemesmegjegyezni, elnevezni és tudatosan használni. Ezeket workflow design patterneknek nevezzük ésösszefoglalásukra tesz kísérletet ez a cikk.

A munkafolyamatok modellezésére az UML3

is kiválóan alkalmazható, azonban az utóbbiévek erőfeszítései nyomán egy külön eszköz, aBPMN lett erre megalkotva, ami pillanatnyilag alegnagyobb támogatottsággal rendelkezik a nagycégeket és a fejlesztő eszközöket tekintve egy-aránt. Előnye az is, hogy tervezésekor az volt azegyik cél, hogy olyan ábrázolástechnikát alkal-mazzanak, amit az informatikusokon kívül bár-mely üzleti szakember is megért. A klasszikusalapmintákat a BPMN-nel fogjuk bemutatni, ígyez a cikk és a 3. írás együtt egy nagyobb egy-séget képez. Aki alapszinten ismeri a BPMN-t,az nyugodtan olvassa tovább ezt a pontot, vi-szont ennek hiányában javasoljuk először a 3.cikket elolvasni. Néha talán meglepődünk, hogyegy-egy minta modellezése milyen egyszerű, deez ne tévesszen meg bennünket. A BPMN pontolyanra lett tervezve, hogy ezek a workflow de-sign patternek könnyen ábrázolhatóak legyenekbenne.

Alapvető vezérlések(Basic Control patterns)

Sequence pattern

A 2.1. ábra által mutatott Sequence pattern atevékenységek sorba rendezett végrehajtása. Arendezettséget a nyilakkal jelölt konnektorok de-finiálják. A B akkor kezdődhet el, amikor Akompletté vált, azaz befejeződött. A C pedigB után kezdődhet csak el. Emiatt a tevékeny-

ségek ezen végrehajtását soros folyamnak (sequ-ence flow) is nevezzük. A működést el lehet úgyképzelni egy ilyen szekvencia mentén, hogy vanegy TOKEN (stafétabot), amit vagy éppen azegyik task (feladat) birtokol és akkor az ő vég-rehajtása folyik. Amikor az activity befejeztemunkáját lemond a TOKEN-ről, ezt követően anyíl határozza meg, hogy mely task veszi át astafétát. A sequence flow konnektorai sohasemrendelkeznek átmenetet védő logikai feltétellel,hiszen más irányba nem tudna menni a vezérlés,ugyanakkor a TOKEN-t átadó task sem tud márbefolyást gyakorolni az esetlegesen hamis felté-telre, így a folyam idő előtt megállna. A „Be-vásárlás” → ”Főzés” → „Takarítás” → „Olvasás”ilyen sorrendben való végrehajtása egy tipikussoros minta.

2.1. ábra. Sequence pattern

Parallel Split pattern

Maradjunk az otthoni példáknál és a 2.2. ábrataskjai jelentsék ezt: A→Reggelizés, B→Főzés,C→Takarítás. Arra „üzleti igény” van, hogy acsalád együtt reggelizzen, de utána az apa ésanya mehet a dolgára. Az egyik főzni fog, a má-sik takarít. Mindezt párhuzamosan végezhetik,de csak akkor, ha befejeződött, azaz kompletté

3Elsősorban a tevékenység és szekvencia diagramok

11


vált a reggelizés. Ezt hívjuk párhuzamos szétvá-lásnak (split vagy fork). A „+” gateway fogadjaa TOKEN-t a reggelizés feladattól, majd kiállítaz alapján 2 újat, így képes egyszerre 2 felada-tot is staféta bottal (vagy további nevei: jegy,vezérjel, feladat indító engedély) ellátni és ezzelaz indulását engedélyezni. A kapuknak mindigilyen szervező feladatuk van, maguk sosem vesz-nek részt egyetlen feladat megvalósításában sem.

2.2. ábra. Parallel split pattern - 3. jelölés

A 2.3 és 2.4 ábrák is a parallel split min-tát modellezik, szemantikailag és hatásában eza 2 ábra megegyezik azzal, amit a „+”-os ga-teway nyújt. A 2.3. ábra kihasználja, hogy egytaskból több sequence flow nyíl is kimehet (mul-tiple outgoing), ami ilyenkor párhuzamos ágakathoz létre. A „+” gateway használata emiatt nemszükséges, de sok modellező, mint jó-gyakorlatotszereti mégis feltüntetni.


A 2.4. ábra valójában egy „kinyitott” (ex-panded) alfolyamat, amiben 2 task van, minden-fajta sorrend nélkül. Ilyenkor azok párhuzamo-

san kezdődnek el és maga a sub-process akkorfejeződik be, amikor az összes taskja teljes lesz.Ebben az esetben a B és C feladatok tetszőlegessorrendben indulhatnak el és párhuzamosan mű-ködhetnek, de a külső sub-process task csak ak-kor lesz befejezett, ha mindkét beágyazott taskjakompletté vált.


Synchronization pattern

A 2.5. ábra a parallel splittel gyakran együtt al-kalmazott mintát, a szinkronizációt (vagy join)mutatja. Itt a „+” gateway azon tudása kerülkihasználásra, hogy bevárja az összes bemenőTOKEN-t és csak utána adja tovább a felada-tot a workflow következő step-jeinek. A példakedvéért folytassuk az előző példát! A→Főzés,B→Takarítás, C→Fűnyírás (az ábrán más be-tűt kaptak a taskok!). A „+” gateway a Fő-zés és Takarítás bejövő TOKEN-jeit bevárja éscsak utána kezdi el a kimenő vezérlőjelet kiosz-tani. Így szinkronizációra képes, azaz a fűnyírásfeladat elkezdésének engedélye és elkezdése csakakkor következhet be, ha a Főzés és a Takarításis befejeződött és erről a gateway (azaz a kép-zeletbeli diszpécserünk) is értesült. A 2.6. ábratriviálisan ugyanezt a feladatot oldja meg, hi-szen a sub-process task komplett lesz, amikor abenne lévő folyamat befejeződött.

12


2.5. ábra. Synchronization pattern - 2. jelölés

2.6. ábra. Synchronization pattern - 1. jelölés

Exclusive Choice pattern

A BPMN megvalósítást a 2.7. ábra mutatja. AzA task utáni „X” gateway megvizsgálja a mun-kafolyamat belső állapotát és ez alapján döntésthoz, hogy B vagy C task kapja-e meg a TOKEN-t. Itt az egyik task kizárja a másikat, azaz nemcsak a párhuzamosság hiányáról van szó, ha-nem arról is, hogy a kimaradt task most nemis hajtódik végre. Az A→Reggelizés, B→Mozi,C→Strand otthoni példánál maradva, a reggeliután az „X” kapu megvizsgálja az időjárást ésez alapján vagy a mozizásra vagy a strandolásraállítja ki nekünk a TOKEN-t.

2.7. ábra. Exclusive Choice pattern

Az egyes ágak feltételeit – az összekötő nyi-lak mentén – érdemes mindig feltüntetni a mo-dellben (2.8. ábra). A kis szakasszal áthúzottátmenet az un. alapértelmezett útvonal (defa-ult path), amely akkor jelöli ki az irányt, amikoregyik feltétel sem teljesül.

2.8. ábra. Exclusive Choice - feltételekkel

Simple Merge Pattern

A legalapvetőbb vezérlő minták utolsó esete aSimple Merge, amit a 2.9. ábra szemléltet, dea 2.10. ábra is ugyanazt az eredményt adja.Az „X” gateway az input TOKEN-t fogadhatjaA vagy B tasktól egyaránt, azonban amikor azegyiktől megérkezik, akkor már ki is állítja a Cszámára a stafétabotot és átadja számára a fel-adat elkezdés lehetőségét. Itt tehát nincs szink-ronizálás, az első input TOKEN már a folyta-tást, azaz a C elkezdését jelenti. Érdemes meg-jegyezni, hogy ezt a mintát gyakran az előzőexclusive choice-szal együtt használjuk, így amásik ágon amúgy sem jönne sosem input jel.

13


Amennyiben a C a vacsorázást jelenti, úgy ak-kor is sor fog kerülni rá, ha a moziban voltunkvagy a strandon. Bármelyiken is vagyunk túl,már nem kell várni a másikra, indulhat a közösétkezés este.

2.9. ábra. Simple Merge Pattern - 2. jelölés

2.10. ábra. Simple Merge Pattern - 1. jelölés

2.11. ábra. Alapvető vezérlések - összefoglalás és egyéb megvalósítások

14


Fejlett vezérlések és szinkronizációk

Ezen minták (Advanced Branching and Synchro-nization patterns) már a bonyolultabb workflowépítés eszközei, de szerencsére a BPMN nagyonsokat segít az ábrázolásban és a tervezésben,azonban ne essünk abba a hibába, hogy ezeketnagyon egyszerűnek gondoljuk. Persze semminehéz nincs bennük, de amennyiben hagyomá-nyos módon programoznánk le őket, elég sok ésismétlődő feladatunk lenne.

Multiple Choice pattern

A több választási lehetőség minta (2.12. ábra)azt jelenti, hogy a munkafolyamat párhuzamo-san szétágazik, aminek szervezését az „O” ga-teway végzi. Itt tehát több feladat végrehajtásaegyütt is elkezdődhet (odaadható valakinek), ha-sonlóan a parallel split-hez, de ott nem védtükezeket a feladat elkezdéseket semmilyen feltétel-lel.

2.12. ábra. Multi Choice Pattern

Vegyünk ismét egy példát! Legyenek az áb-rán lévő taskok konkrétan ezek: A → Reggeli-zés, B → Fűnyírás, C → Főzés, D → Takarí-tás. A reggeli után az „O” átjáró megkapja aTOKEN-t és elkezdi kielemezni, hogy a folyta-táshoz milyen output jegyeket készítsen. A fűmár nagyon hosszú, azt le kell nyírni. Étel nemkell, mert délben elmegyünk enni a piacra. A ta-karítás viszont szükséges, mert 1 hete nem volt

porszívózva. Ezek alapján az „O” kapu kiállítegy munkajegyet (TOKEN-t) fűnyírásra és ta-karításra, amely feladatok elkezdését kezdemé-nyezi is, párhuzamosan indulhatnak. Az ebéd-készítésre ezúttal – a munkafolyamat pillanatnyibelső állapota miatt – nem kerül sor.

A 2.13. ábra az „O” gateway-hez hasonló mű-ködést mutat, de ehhez a nyíl szárához kapcsoltmini-gateway-t használjuk, ami mellé a feltételodaírható. Olyan irányokba keletkezik TOKEN,amelyekre a kiértékeléskor a feltétel igaz. Ezt ajelölést kényelmesebb használni, ha egy feladatotsok párhuzamosítható feladat követi. A szerzőa gyakorlatból ismer olyan munkafolyamatokat,ahol 20-30 feltételtől függően induló, de párhuza-mosan végezhető task is következhet 1 elvégzettfeladatot. Ilyenkor szinte kötelező ezt az ábrá-zolási módot előnyben részesíteni.

2.13. ábra. Multi Choice Pattern - mini-gateway

Multiple Merge pattern

Ebben a mintában (2.14. ábra) egy új és haté-kony lehetőséget fedezhetünk fel, ugyanis a Dtask minden ág TOKEN-jére példányosodhat.Erre vegyünk ismét egy könnyű hazai példátés a feladatok jelentése legyen a következő: A→ Reggelizés, B → Kirándulás, C → Foci, D→ Cipőtisztitás. Reggeli után kiderül, hogy jóaz idő, így valaki kirándulni, más pedig fociznimegy a családból. Mindkét tevékenység tartvalameddig, közöttük egyáltalán nem szüksé-

15


ges semmilyen szinkronizáció. Tegyük fel, hogyelőbb a kiránduló családtag érkezik meg, leadjaa TOKEN-jét és kap egy másikat, hogy pucoljaki a cipőjét, azaz végezze el a D taskot. Vala-mikor megérkezik a focista is, aki szintén leadjaa képzeletbeli jegyét, hogy felvegye a cipőtisztí-tás nemes feladatát, azaz D task 2 alkalommalpéldányosodott (instantiated). Itt a merge szótehát valami olyasmit jelent, hogy bármi is voltelőtte a feladatod, itt ezt el kell majd utána vé-gezned.

2.14. ábra. Multi Merge Pattern

Discriminator pattern

A 2.15. ábra mutatja a mintát, ahol van egyparallel split, azaz B és C feladatok átfedésben,párhuzamosan hajtódnak végre. Fontos az üzletifolyamatban, hogy mindkét feladat megvalósul-jon, majd utána 1 példányban legyen a D taskmegcsinálva, azaz egy sima sequence flow követ-kezzen. Itt tehát a multiple merge patternnelellentétben arról kell gondoskodni, hogy D nepéldányosodjon több alkalommal. Az „X” (exc-lusive) gateway pont erre szolgál, ezért ennek amintának a BPMN megvalósítása tényleg egy-szerű. Az ilyen gateway – ahogy már említet-tük, de ismételten elmondjuk – bármely inputTOKEN-re (legyen az B vagy C ágon jövő) elő-állítja az output TOKEN-t, így az első ág beér-kezése után már megy is a D feladat kiosztása.Később hiába végez a másik ág(ak), az(ok) márblokkolódva lesznek, belőlük már nem lesz out-put TOKEN létrehozva az „X” átjáró révén.

2.15. ábra. Discrinimator Pattern

N out of M Join pattern

Ez a minta valahol a Synchronization és Discri-minator pattern között van, BPMN-es megvaló-sítását a 2.16. ábráról láthatjuk.

2.16. ábra. N out of M Join pattern

A „*”-os átjáró neve: complex gateway(összetett átjáró). Ezzel a kapuval képesek va-gyunk deklarálni, hogy mennyi input TOKENérkezzen be a gateway-be, hogy az utána elő-állíthassa a kimenő TOKEN-t. Az eddigi ese-tekkel ellentétben most tehát nem arról van szó,hogy az első vagy az összes input jel beérkezésekell a folytatáshoz, hanem arról, hogy valahányinput után mehet tovább a folyamat a követ-kező stepre. Megadhatunk egy kifejezést vagykonstans számot a kapunak, ami ennyi bejövőjel megérkezése után fogja az output TOKEN-telkészíteni. Ezután a további ágakról érkező in-put TOKEN-ek már nem játszanak szerepet, afolyamat már továbblépett. A complex gatewaytípus pont azért került be a BPMN eszköztárba,

16


hogy segítségével ezt a valóságban gyakori szi-tuációt könnyen modellezni lehessen. A mintaonnan kapta a nevét, hogy tervezéskor M da-rab nyíl futhat be a „*”-os gateway-be, de ebbőlN ≤ M input TOKEN is elég a folytatáshoz.

Synchronizing Merge pattern

Ez a minta a Synchronization pattern egy variá-ciója, a 2.17. ábra mutatja a megvalósítását. Az„O” gateway párhuzamos ágakat hoz létre, azon-ban ezek száma tervezéskor nem ismert, hiszenfutás közben dinamikusan – a teljesült feltételekalapján – dőlt el, hogy valójában mennyi pár-huzamos task van. Ezt a helyzetet például amár ismertetett Multiple Choice pattern segít-ségével tudjuk könnyen előállítani. A minta azta szituációt fogalmazza meg és ad rá megoldást,hogy a D feladat elkezdése előtt ezeket az ágakatszinkronizálni kell, azaz be kell várni. A kihívástpont az adja, hogy előre nem tudhatja a 2. „O”átjáró, hogy a szinkronizálás során mennyi in-put TOKEN-re számítson, ezért képesnek kelllennie ezt az információt megszerezni. Ezt a tu-dást pedig egy workflow-kat készítő programozóbizonyára sosem tudja eléggé megköszönni.

2.17. ábra. Synchronizing Merge pattern

Szerkezeti minták

A szerkezeti minták (Structural patterns) a cik-lusokkal való ismétlődésekkel és egy-egy párhu-

zamos ág terminálásával befolyásolják a munka-folyamat végrehajtásának alakulását.

Arbitary Cycles pattern

Az „önkényes” ciklus az iteratív, egyre finomodómunkafolyamat végrehajtásának vagy egy-egydöntéstől függő tevékenység sorozat kihagyásokvagy beiktatások alapvető eszköze. Alapelemeaz exclusive gateway és a nyíl. Az átjáróban szü-letik a döntés, a nyíl pedig az ettől függő ugrástvalósítja meg. A 2.18. ábra F és G tevékenységeközötti döntés kimenete lehet, hogy a C felada-tot újra el kell végezni, sőt az ábra esetében aC→D→F folyamat szakasz egészét meg kell is-mételni.

Képzeljük el, hogy van 3 tevékenységünk:

1. T1→ Rendelünk egy eszközt

2. T2→ A munkahelyi vezető engedélyez

3. T3→ A beszerző beszerez

A munkafolyamat lefutása ekkor így néz ki:T1→T2→T3. Ugyanakkor T2 és T3 lépésben islehet olyan megfontolás, ami ismételt feladatrakéri fel az eddigi szereplőket, azaz ezen tevékeny-ségek kimenetele után kell egy-egy kizárólagosdöntést hozó kaput beiktatni. Itt lehetőség vanarra, hogy például T2 visszakérdezzen T1 felé,azaz egyelőre nem fogadja el az igényt. A be-szerző is hasonlóan járhat el. Ilyenkor a BPMNdiagramon nyíl jelzi (mert rácsatlakozik a tas-kra), hogy a tevékenység ismételten végrehaj-tásra fog kerülni, ugyanis ilyen döntést hozottaz arra jogosult szereplő (az actor, aki a taskotkezelte). A vezető kérheti T1 task ismételt végre-hajtását, mert pontosítást kér. A beszerző lehet,hogy csak azért „nyilaz” vissza a T2 taskra, merta rendelkezésre álló pénzkeret emelését szeretnékérni.

17


2.18. ábra. Arbitary Cycles pattern

Implicit termination pattern

A befejeződési minta (2.19. ábra) azt fogal-mazza meg, hogy a munkafolyamat valamelypárhuzamos ága vagy egésze befejeződik, ami-kor azon az útvonalon már nincs több feladat ésnem is akarjuk ezt az ágat összefésülni (merge)egy másikkal. A befejeződés jele az end event(vége esemény=vastag kör). Ellentétben sok áb-rázolási eszközzel, itt az end event általában csakannak az ágnak a befejeződését jelöli, amelyiketlezárja. A 3.20. ábra mutatja ezeket a lehetsé-ges esemény típusokat, amik közül a teljes pro-cess befejeződését csak a Terminate event (vas-tag körben egy azt majdnem kitöltő fekete ko-rong) váltja ki. Ebben az esetben a folyamatmég akkor is leáll, ha vannak aktív vagy még elsem indult tevékenységek.

2.19. ábra. Implicit Termination pattern

Multiple instances patterns

A következő mintacsoport azért érdekes, mertlehetővé teszik, hogy egy tevékenység több al-

kalommal hajtódjon végre mielőtt a TOKEN akövetkező task-ra megy. A feladatok általábanmegoldhatóak kétféleképpen is:

• Ténylegesen párhuzamosan, egyszerretöbb példányban (multiple instances) jönlétre a megadott activity (Ilyenkor a taskmarker ez: ||)

• Ciklusban (Looping), sorosan egymás utánjönnk létre ugyanannak a tevékenységneka példányai (A task marker: 3/4 kör)

A BPMN rendelkezik attributum megadási le-hetőségekkel, amiket ebben a mintacsoportbanerősen ki is kell használni. A több példánybanműködő task-ra jellemzően ezek a paraméterekgyakorolnak MI szempontból hatást:

• LoopType → ezzel állítjuk be, hogy ez atevékenység multi instance jellegű. Értékeekkor: MI

• MI_Condition → Itt adható meg, hogy atask mennyi példányban jöjjön létre

• LoopCondition → Ezzel lehet arról ren-delkezni, hogy dinamikusan, futás közbenlegyen meghatározva a létrejövő activityinstance-ok száma.

• MI_InstanceGeneration → Ha értéke Pa-rallel, akkor párhuzamosan jönnek létre afeladat példányok, különben sorosan.

18


• MI_FlowCondition → Ezzel a jellemző-vel azt lehet szabályozni, hogy a több pél-dányban létrejött task szinkronizálása mi-lyen módon történjen. Amikor az értékeAll, akkor mindegyik instance befejeződésiTOKEN-je kell ahhoz, hogy a workflow akövetkező feladatra menjen. Lehetséges aNone érték is, mely esetben a szinkronizá-cióra semmilyen megkötést nem teszünk, akövetkező task elkezdődhet úgy is, hogy azelőtte létrejött több példányos step-ek egyrésze vagy egésze még mindig aktív, azaznem adták át a stafétabotot a következőlépés számára.

A 3.2 és 3.3. ábrák és a hozzájuk tartozó ma-gyarázatok további segítséget adnak megértenia Looping és MI taskok használatát, ott bemu-tattuk a task marker-es és az azt nem használómegoldási lehetőséget egyaránt.

MI with a priory design timeknowledge pattern

Ezen minta azt az esetet fogalmazza meg, ami-kor már tervezési időben tudjuk a szükséges ac-tivity példányok számát. A 2.20. ábra mind-két oldala az MI eset szerint van konfigurálva.Az (a) ábra mutatja, amikor nem szinkronizá-lunk, azaz C task akár egyből is elkezdődhet.Ez a MI_FlowCondition=None beállítás miattvan így. Ezzel szemben a (b) ábra ezt az ér-téket All-ra állítja, de ez az eset az „MI requi-ring synchronization” minta résznél lesz megtár-gyalva. Az MI_Condition és a LoopConditionegyüttes megfelelő beállítása éri el azt a hatást,hogy a tervező előre be tudja állítani az instance-ok számát.

A jobb megértés kedvéért vegyünk egy pél-dát! Ez egy vélemény összegyűjtő workflow(Collect Feedback workflow) lesz. Az egyes tas-ok jelentése a 2.20. ábrán most legyen a követ-kező:

• A→ a dokumentum befejezése és elküldésevéleményezésre

• B → véleményezés

• C → a dokumentum lezárása és publiká-lása

Esetünkben a tervező tudja, hogy 10 ember-nek kell véleményeznie, ezért beállítja a 10 pél-dányt. Ez lehetne szekvenciálisan, sorban egy-más után (Looping eset), de mehet párhuza-mosan (MI eset) is. Futás során a B task 10példányban létrejön. Amennyiben a tervező azMI_FlowCondition=All beállítást tette, úgy aC task csak akkor kapja meg a TOKEN-t, ami-kor mind a 10 véleményező task lezárult. Ellen-kező esetben a C task el is indulhatna, de ennekmost nincs értelme, hiszen miért is csinálnánkazt meg félkész dokumentumon?

2.20. ábra. MI with a priory knowledge pattern

MI with a priory runtimeknowledge pattern

Ezt a mintát szintén a 2.20. ábráról olvashatjukle, azonban itt a designer nem ismeri előre a Btask-ból szükséges példányok számát. Ebben azesetben a LoopCondition jellemzőben lévő kife-jezés futás közben számítódik ki, a kapott értéklesz a létrejövő példányok száma. A fenti pél-dánkban B véleményező feladatok példányszámaegy kalkuláció eredményétől fog függni. Ez pél-dául a dokumentum típusától vagy az előtte lévőA task beállításától is származhat.

19


MI with no a prioryknowledge pattern

Nem mindig vagyunk abban a helyzetben, hogyakár tervezéskor, akár futáskor, a több példányostask elindulása előtt ki tudjuk számolni, hogymennyi lesz az instance-ok száma. Erre ad meg-oldást a 2.21. ábrán bemutatott minta, amineka neve onnan jön, hogy a task példányok lét-rehozásakor nincs még előzetes ismeretünk azokszükséges számáról. Példaképpen tekintsük átaz (a) ábrát, ahogy megvalósítja a kívánt mű-ködést. A B task az, ami több példányban jönlétre, a C pedig a kiértékelési lépést végzi el. Az

A task és az azt követő „X” kapu után jön egy„+” parallel split lépés. Így B és C taskok iselindulnak. C akár hamar is be fogja fejezni aworkflow állapotának a módosítását, emiatt azazt követő „X” döntési kapuban érdemes vizs-gálni, hogy kell-e új példány B-ből. Amennyibenmég kell példány, úgy a folyamat ezen párhuza-mos ága visszahurkolódik az A feladatot követő„X” átjáróhoz és ezzel ismételten létrejön egy Bés C. Persze a C taskok hamar „halnak”, a vé-gén a C ága az „E” task előtti „X” kapuhoz fogcsatlakozni, miközben a sok létrejött B task akármindegyike még aktív lehet.

2.21. ábra. MI with no a priory knowledge pattern

MI requiring synchronizationpattern

Ez a minta lényegében már ismertetésre került a2.20. ábra jobb oldalán, amikor megemlítettük,hogy az MI_FlowCondition=All beállítás szin-ronizációt is jelent a C task elindulásához. ABPMN tehát beépített eszközökkel képes támo-gatni ezt a mintát is.

Állapotokra épülő minták(Stated based patterns)

Az itt lévő minták feladata az, hogy megoldjákazokat a workflow lefutási igényeket, amik nemcsak a BPMN belső struktúrájától és a folyamatpéldány állapotától függenek, hanem egy folya-

maton kívüli eseménytől is. Ez nem más, mintaz üzleti folyamat alakulása a külvilág befolyá-sos alakítóinak (actor-ok) döntései alapján, amitmindig az adott szituációnak megfelelően hoz-nak meg és azt valamilyen kommunikációs csa-tornán juttatják el a munkafolyamat felé. Az iselképzelhető, hogy ezek a döntések egy részét va-lamilyen Rule Engine (szabályokat kezelő szoft-ver motor) közbeiktatásával hozzák meg.

Deferred Choice pattern

A késleltetett választás (2.22. ábra) minta egymódosult változata az exclusive choice mintá-nak, ugyanis az event alapú „*”-os gateway úgyműködik, hogy az utána rajzolt köztes esemé-nyek ágait szervezi. Amelyik megfelelő esemény

20


hamarabb érkezik be, úgy a kapu B vagy C taskirányába adja tovább a TOKEN-t. Az ábránmost egyszerű message event van, de természe-tesen mindegyik eseménytípus használható. Le-hetne az egyik ágon egy timer is, aminek lejárta-kor a „*”-os kapu abba az irányba engedélyeznéa továbblépést.

2.22. ábra. Deferred Choice pattern

Interleaved Parallel Routing pattern

A 2.23. ábra – ha egy kicsit elgondolkodunkrajta – önmagáért beszél. A munkafolyamat

szekvenciális sorrendbe tett, de azon belül pár-huzamos ágakból áll. Az egyes párhuzamos sza-kaszok között még az sem számít sokszor, hogya benne lévő párhuzamos task-okat milyen sor-rendben hajtjuk végre (ezek un. ad-hoc taskokilyenkor). Ez a minta jól támogatja azt, amikoregy munkafolyamat jól elhatárolható szakaszok-ból áll, de az azon belüli feladatokat párhuza-mosan is végre lehet hajtani. Az ábra egy olyanmegvalósítást mutat, ahol a „+” gateway szink-ronizál az egyes szakaszok végén. A B és C step-ek párhuzamosan indulnak, majd az utána lévő„+” kapu szinkronizálja őket. A példa folytatásaérdekes, mert egy kizárólagos döntéssel csak a D,vagy E ágon mehetünk tovább, de ettől függet-lenül az ott lévő D vagy E task után a másik isindul. Emiatt még F és G is párhuzamos lesz,majd a végén H feladat előtt egy „+” kapu újraszinkronizál. A működés hatása láthatóan tény-leg az, amit szeretnénk: párhuzamos folyamatdarabkák egymás utáni végrehajtása.

2.23. ábra. Interleaved Parallel Routing pattern

21


Milestone pattern

A mérföldkő minta (milestone) azt modellezi,amikor egy olyan nevezetes activity is végrehaj-tódott, amit külön figyelünk és bekövetkezése-kor egy extra teendőt szeretnénk beiktatni. Afolyamatépítészek számára ez egy ismert körül-mény, a project munkalebontási tervekbe is beszoktuk jelölni a mérföldköveket. A 2.24. ábraegy lehetséges implementációt mutat, ami a Link

Event-re épül. A B task egy milestone az ábrán,ezért ott egy Link Event is kibocsátódik, miköz-ben a C task persze el is indulhat folytatásként.A Link Event egy message flow (szaggatott üze-net közvetítő nyíl a medencék, azaz folyamatokközött) segítségével megérkezik a másik munka-folyamat erre várakozó pontjára, amire az el isindul, kezelvén ezzel a mérföldkő által kiváltottkülönleges teendőket.

2.24. ábra. Milestone Pattern

Visszavonási minták

A visszavonási minták (Cancellation patterns)a feladatok vagy a process példányok (nevezzükmég ezeket case-eknek is, innen jön a 2. mintaneve) törlésével, visszavonásával foglalkoznak.

Cancel Activity pattern

A 2.25. ábra ismét egy tipikus használatot áb-rázol. Van 2 egymással versenyző activity, B ésC feladat. Amikor B task hamarabb képes be-fejeződni, akkor a sequence flow egy Cancel Cköztes esemény generáló node-ra fut, amit a Ctask határeseménye (boundary task) kap el éskiváltja a C task azonnali befejeződését.

2.25. ábra. Cancel Activity pattern

Cancel Case pattern

Az utolsó klasszikus minta arra ad megoldást,hogy milyen módon lehet a teljes folyamatot le-

22


állítani (2.26. ábra), amire a Terminate Eventad eszközt.

2.26. ábra. Cancel Case pattern

További workflow minták

Az eddig bemutatott workflow design patterneka legalapvetőbbek, ezek születtek meg legkoráb-ban, hiszen pont azt írják le, ami a munkafo-lyamat lényege, azaz a lefutás vezérlési jógya-korlatait foglalják össze. Szűkebb értelembenezeket hívjuk workflow mintáknak, azonban akésőbbiek során sok más, egyéb szempontokatfókuszba helyező patternek is születtek, amiketa http://www.workflowpatterns.com/ helyenrendszerbe szedve tanulmányozhatunk. Ezek aminták a következő témakörökbe csoportosítha-tóak:

• Az adatok kezelése és láthatósága (DataVisibility patterns). Ismertebb minták:Task data, Block data, Scope data, Casedata, Multiple instance data, Folder data,Workflow data, Environment data.

• Adatkommunikáció a tevékenységek között(Data Interaction patterns)

• Az adatok mozgatása (Data Transfer pat-terns). Ismertebb minták: Data Transferby value, Data Transfer by reference, DataTransformation patterns.

• Adat alapú tevékenység kiosztások (DataBased Routing patterns). Ismertebb min-ták: Task precondition, Task postcondi-tion, Event based task trigger, Data basedtask trigger, Data based routing.

• Erőforráskezelési minták (Resource pat-terns). Ismertebb minták: Creation pat-terns, Push patterns, Pull patterns, Det-our patterns, Auto start patterns, Visibi-lity patterns, Multiple resources patterns,Distribution by allocation, Chained execu-tion, Simultaneous execution.

• Kivételes helyzeteket kezelő minták (Ex-ception Handling patterns). Itt van né-hány visszatérő ok, amit kezelni illik: hibaaz activity belsejében, valamilyen határidőlejárt, az egyik szükséges erőforrás nem ér-hető el, egy külső trigger, valamilyen üzletiszabály meg lett sértve.

Amióta a fenti típusú minták kidolgozása és fo-lyamatos bővítése, finomítása elkezdődött, azótaaz eredeti 21 darabot vezérlés alapú (ControlFlow patterns) pattern-eknek hívjuk. A rend-szerbe szedett minták kapnak egy nevet, rövidleírást, a létrejöttük motivációja is leírásra kerül,érdemes adni néhány kifejező példát és megoldá-sukat. Fontos, hogy kiderüljön a minta használ-hatóságának a kontextusa, az esetleges előnyökés hátrányok, illetve a felmerülhető problémákés az azokra adható megkerülő megoldások.

23

Business Process Management Business Process Management Notation

3. Business Process Management Notation

A munkafolyamatok tervezői és megvalósítói számára kiváló modellező eszköz a BPMN. A szab-vány gondozója az Object Management Group - Business Process Management Initiative (webhely:http://www.bpmn.org/). Egy BPMN-ben megtervezett workflow BPMN XML formátumban tá-rolódik, amit egy BPMN-t ismerő workflow motor képes értelmezni. Ez a cikk a BPMN rövid, deteljes bemutatására vállalkozik.

Egy workflow mindig valamilyen összehan-golt tevékenységsorozatot valósít meg egy előremeghatározott cél(ok) érdekében. Természete-sen fontos, hogy mit, mikor, milyen feltételekmellett, milyen sorrendben végzünk el. Lénye-ges, hogy az időzítések is megfelelően legyenekbeállítva, illetve a folyamat közben keletkezetthibás helyzetek kezelve legyenek. Néha a gyakor-latban meglepően bonyolult, párhuzamosan egy-más mellett működő szituációkat kell modellez-nünk, amire a BPMN valóban kiváló és mára ta-lán a legelterjedtebb eszköz lett. Kifejező szim-bólumrendszere mellett további előnyei is van-nak, mert egy XML nyelv segítségével a konkrétmodellező alkalmazástól független leírást is defi-niál, amit BPMN XML leírónyelvnek nevezünk.Támogatja a folyamat számítógépes implemen-tálását is, ugyanis sok olyan workflow engine lé-tezik, ami megérti ezt a nyelvet. A következők-ben áttekintjük a BPMN modellezés eszköztá-rát, aminek megértését sok példával igyekszünkillusztrálni.

A Tevékenység

Egy munkafolyamat alapvetően az elvégzettvagy elvégzendő tevékenységek sorozatából áll,aminek jele egy lekerekített téglalap, ahogy azta 3.1. ábra is mutatja és a következő szavakatszoktuk még használni rá: activity, task, step,feladat. Egy tevékenység egy külön megneve-zett része az összes elvégzendő feladatnak. Lé-nyeges tulajdonsága, hogy elkezdődik, tart egyideig, majd befejeződik, azaz kompletté válik.

Ilyenkor – hacsak az egész munkafolyamat vé-get nem ért – jön a következő task, amely me-chanizmust az egyik feladatból a másikba valóátmenetnek (transition) nevezzük. További jel-lemző az is, hogy a feladatot milyen szerepkör-ben lévő egyed (ember, program) végzi el, azazki az actor. A feladatokat olyan sorrendben kellelvégezni, ahogy azokat a nyilakkal jelölt kon-nektorok meghatározzák, ezt soros tevékenységfolyamnak (sequence flow, path, útvonal, ág) ne-vezzük. Többségében a workflow-k általábantöbb párhuzamos ágból állhatnak, de erre majdcsak a későbbiekben térünk ki.

3.1. ábra. A Tevékenység (Task, Activity, Step)

A BPMN activity lehet atomi vagy nematomi (összetett=compound). Az utóbbi esetakkor fordul elő, amikor egy step-et jelképezőtéglalap egy alfolyamatot vagy több példányban(sorosan vagy párhuzamosan működő) is létre-jövő task-ot reprezentál. A következő task típu-sokat különböztetjük meg:

24


1. Human Task. Emberi közreműködést igé-nyel. Ez az a klasszikus eset, amikor a fel-használó valamilyen GUI felületen keresz-tül tudja a feladatot (engedélyezés, kére-lem, stb.) elvégezni.

2. Service Task (Automatic Task). Em-beri közreműködést nem igényel, a BPMNezen a ponton egy automatikusan végre-hajtandó tevékenységet jelöl. Az imple-mentált megoldásban itt a BPMN mo-tor az ilyen taskokat egyszerűen meghívja,végrehajtatja.

3. Call Activity. Ez a tevékenység egy alfo-lyamat elkezdését képes inicializálni. Amígaz alfolyamat fut, addig vár, azonbanannak a befejeződése egyben ennek azactivity-nek a befejeződését is jelenti.

4. Script Task. Olyan, mint a service task,de az automatikusan végrehajtandó lépé-seket az implementációban egy beágyazottscript tartalmazza.

5. Send Task. Amikor egy process eléri ezta taskot, akkor az egy üzenetet (Message)képes elküldeni.

6. Receive Task. Amikor egy process eléri ezta taskot, akkor az megnézi, hogy van-e szá-mára értelmezhető üzenet. Amennyibenigen, úgy azt feldolgozza, ellenkező esetbenblokkolódik és vár egy neki szánt üzenetre.

A modellező eszközök a tevékenységek fenti ese-teit általában valamilyen kis ikonnal szoktákmegcímkézni. A 3.1. ábrán ezenkívül továbbikis ikonok is láthatóak, amik az alábbi működésijellemzőket szimbolizálják és a téglalap középső-alsó részében szokás őket feltüntetni:

1. Looping. Az ilyen task többször, szekven-ciálisan végrehajtódik, aminek a számos-ságát vagy az ismétlődés befejeződésének

logikai feltételét a modellező egy jellem-zőben megadhatja. Az ilyen eset jelzé-sére egy kis nyíllal végződő 3/4 kör szol-gál. Már itt megjegyezzük, hogy az ígyfelcímkézett task természetesen kiválthatólenne egy feltétel vizsgálattal és a vezér-lés visszahurkolásával is, azonban ez olyangyakori, hogy érdemes volt ezt az egysze-rűsített ábrázolást bevezetni. A 3.2. ábraegy konkrét esettel érzékelteti a loopingcímke szemantikáját, aminek a bal oldalamutatja azt, amikor közvetlenül a loop-ing ikont használjuk, míg a jobb oldalaaz ennek megfelelő döntés és visszahurko-lás alapú megoldást tartalmazza. Az elsőesetben az „Until there are no errors” kife-jezés a task egyik belső property-je, míg amásodik esetben a döntési kapu (diamondszimbólum) vezérlési feltétele.

2. Multiple Instances (röviden: MI). Az ígyjelölt taskok (jele: 2 db, rövid párhuza-mos vonal) is többször hajtódnak végre,de ezek párhuzamosak egymással. Ez aztjelenti, hogy ezekből a taskokból egyszerretöbb élő példány (instance) van, amik emi-att nem szekvenciálisan hajtódnak végre.A későbbiekben tanult gateway-ek hasz-nálatával ez a működés is megvalósíthatólenne, de ismételten elmondhatjuk, hogyez is olyan sűrűn előforduló eleme a munka-folyamatnak, hogy kényelmesebb csak ezta taggelt taskot használni helyette.

3. Ad Hoc. Az olyan taskok, amiket a tervezőnem tud előre megtervezni, véletlenszerűenjelentkezhet a munkafolyamatban. Az ígymegjelölt taskok (Jele: „~”) actora ismert,de annak időbeli vagy a szekvenciális vég-rehajtáskor definiálható sorrendi pozíciójahatározatlan, így ilyen task nem rendelkez-het bemenő, a szekvenciális sorrendet jelzőnyíllal. Végrehajtására emiatt valamilyenüzenet hatására kerül sor.

25


4. Compensation. Ez egy olyan tevé-kenység (Jele: „<‌<”, azaz a rewind-button=visszatekerés gomb), ami akkorhajtódik végre, amikor valamit vissza sze-retnénk vonni (példák: kártérítés, más ke-zelési mód szükséges, egyszerű UNDO egytask-ra vagy egy egész process-re) mertmégis másképpen kell csinálni. A 3.4. áb-rán mutatott példa és a hozzá tartozó ma-gyarázat egy konkrét használaton keresz-tül mutatja be a kompenzációt.

3.2. ábra. Looping task

A 2. pont azaz az MI task jobb megértéseérdekében tekintsük a 3.3. ábrát! A bal oldali„||” jelet használó MI task annyi példányt repre-zentál, amennyi válasz érkezett a Survey-re (fel-mérésre). Ez megtehető hiszen az egyes válaszokegymástól függetlenek és mindegyik ugyanezt afeldolgozást igényli. A jobb oldal mutatja, hogyMI task nélkül mennyire komplexnek kell len-nie a megoldásnak. Egyelőre még nem ismerjük,de az „X” és „+” jelzésű rombuszok az exclusive(kizárólagosan 1 ágra megy a vezérlés a döntéseredménye szerint) és parallel (párhuzamos) ka-

pukat jelentik. Amennyiben a cikk későbbi ré-széből ezek ismeretét is megszerezzük, javaslom,hogy térjenek vissza ehhez az ábrához és gondol-kodjanak el rajta. Érdemes lesz megérteni, ezértpár szóval elmagyarázzuk a jobb oldali ábra mű-ködését is. Látható, hogy az MI task helyettegy szaggatott vonallal jelölt elem csoport van(a szaggatott vonallal körbevett elemek egy lo-gikai group-ot alkotnak, erről a cikk vége felémajd olvashatunk), ami nem jelent szemantika-ilag semmit, de az ábra olvasóinak jelzi, hogyezek az elemek együtt valami értelmeset csinál-nak. Mi tudjuk, hogy ez az „értelmes dolog” azMI tasknak megfelelő funkcionalitás megvalósí-tása, ahogy azt a megjegyzés (annotation) el ismagyarázza nekünk az ábrán. A „Compile Re-sults” MI task jobb oldali implementációja ottkezdődik, hogy egy üres rombuszba kerül a folya-mat vezérlése. Ez egy exclusive kapu, azaz bár-mely bemenő nyílra (nem várja meg a többi nyi-lat, azaz TOKEN-t) megy tovább a vezérlés. Azelső nyíl, azaz transition nyilván az lesz, amelyika „Collect Responses” step-ből jön, majd az előb-biek miatt egyből átlépünk a „+” jelű parallel ka-pura, ami definíció szerint „gondolkodás nélkül”2 párhuzamos ágat nyit, azaz a TOKEN tovább-megy és párhuzamosan elkezdődik a „CompileSingle Result” és „Inspect Response Queue” tas-kok működése. A „+”-os parallel kapu szinkroni-zációt valósít meg, azaz onnan csak akkor megyki output TOKEN, ha minden nyíl beérkezett.Az „X”-es exclusive kapu – hasonlóan az üresrombuszhoz – számára szintén elég, ha csak azegyik nyíl jön be, máris megy tovább az outputTOKEN belőle. Az „Inspect Response Queue”task egy gyors művelet, az ő nyila kis idő alattbe fog érkezni a „X”-es gateway-be, ahol egy dön-tés születik arról, hogy van-e még feladat (a fel-tétel=”No More Responses”). Amennyiben van,úgy visszakerül a vezérlés az üres rombuszhoz,aminek most ez az egyetlen, de a továbblépés-hez emiatt elégséges inputja, majd az előzőekhezhasonlóan létrejön a 2. „Compile Single Result”

26


task, miközben az előbbi még futhat. Itt van apárhuzamosság! Persze csak annyi ilyen task foglétrejönni, amennyi feladat a queue-ban van. Atöbb példányban létrejött „Compile Single Re-sult” taskból kimenő „+” gateway elég cseles,gondoljuk csak meg! Szinkronizál és csak ak-kor engedi tovább a TOKEN-t a „Review Re-sults” step-re, ha mindegyik nyíl, azaz számárabefutó TOKEN megérkezett hozzá. De mennyiis ez? Kettő? Nem! Minden létrejött párhuza-mos tasktól várni fog egy befejeződés jelentést,azaz, ha N db task volt, akkor a befutó TOKEN-ek száma N+1, mert a „No More Responses” a+1 nyíl.

3.3. ábra. Multi Instance (MI) task

A 3.4. ábra a kompenzációs taskra mutat egyjellemző használati esetet. Az ábráról is látható,hogy a „Credit Buyer” task (ami lehetne egysub-process is) egy kompenzációs feladat és mintilyen nem része a normál folyamat lefutásnak.A példa egy lehetséges együttműködést ábrázolegy vevő (Buyer) és az eladó (Seller) között. A

Buyer vesz valamit a „Purchase Item” step-nél,majd átmegy a „Receive Item” várakozásba, il-letve amikor az megérkezik, akkor fogadja is azárut még ebben a feladatban, ami csak ezutánválik kompletté. Előtte azonban még küldöttegy üzenetet a Seller-nek, akinek az első taskjaa „Charge Buyer”, azaz felszámolja a díjat, majdleszállítja a vásárolt árut, amiről a Buyer értesül,átveszi azt és számára még a vásárlás értékelésevan hátra. Amennyiben elégedett a vásárlással,úgy egyből lezárul a folyamat, ellenkező esetben„dob” egy „Unhappy With Purchase” compen-sation folyamatot záró üzenetet (vastag körbenvan a szimbólum), ami szintén a process végétjelenti a Buyer számára. Ez a kompenzációsevent eljut minden olyan helyre, ahol kompen-zációs task van a BPMN ábrán, ez esetünkbencsak a „Credit Buyer”. Ez a működés hangsú-lyosan nem része a normál folyamat lefutásnak!Az ábrán azonban jelölhetjük, hogy ez a task a„Charge Buyer” feladattal van asszociációs kap-csolatban (Jele: pontozott vonal=dotted line),azaz annak a működését javítja ki, esetleg egyegész alfolyamat indításával.

3.4. ábra. A Compensation task használata

27


A fenti kis „+, 3/4 kör, ||, ~, <‌<,” ikono-kat értelemszerűen egyszere is lehet használni,azaz például az 1. és 4. ikon ugyanabban azactivity-ben is megjelenhet. A dupla keretbenlévő Transactions task is egy alfolyamatot rep-rezentál, aminek az a jellegzetessége, hogy a vál-toztatások akkor lesznek csak véglegesítve (com-mit), vagy visszavonva (rollback) amikor az alfo-lyamatban lévő összes résztvevő ezt együttesenígy akarja.

Az alfolyamatokat a Collapsed Sub-Process(a + jel mutatja) és az Expanded Sub-Processtéglalapok reprezentálják. Ezek az eszközökazért jók, mert az összetettebb folyamatokat hi-erarchiába tudjuk szervezni, így azok sokkal job-ban áttekinthetőek lesznek. Egy sub-processmindig egy összetett activity. A collapsed sub-process „+” jele mutatja, hogy az alprocess-nektovábbi finomítása is van egy alacsonyabb szin-ten, ha képzeletben kinyitjuk a „+” jelet, akkorelénk tárulhat az alfolyamat (lásd a 3.5. ábrát),aminek megvalósítása lehet Embedded vagy In-dependent. Az első esetben az alfolyamat az ac-tivity téglalapjába van rajzolva, míg a másodikesetben egy külön helyen, ahova csak hivatko-zás történik a téglalapból. Emiatt ezen másodikeset az újrahasznosítható folyamat szakaszok lét-rehozását is támogatja.

3.5. ábra. Kinyitott alfolyamat

A 3.6. ábra az expanded sub-process egy ér-

dekes használatát mutatja, ahol a C és D tas-kok párhuzamosan élve működnek, a hatás olyanlesz, mintha egy parallel gateway keltette volna.Az A task kompletté válása után egy embeddedalfolyamat indul, amiben 2 olyan task van, amiközött nincs semmilyen szekvenciális kapcsolat,azok párhuzamosan indulnak el. Amikor C ésD is komplett lesz, akkor lesz komplett maga asub-process is, utána folytatódik a folyamat azE step-pel.

3.6. ábra. A sub-process, mint Parallel Box

Összekapcsolók (Connectors)

A 3.7. ábra összefoglalja a BPMN összekap-csolóit. Az egyes activity-ket a Normal Sequ-ence Flow kapcsolja össze, így definiálódik kö-zöttük egy szekvenciális végrehajtási sorrend.Van olyan eset, amikor a workflow elágazik és azegyes ágak feltételekkel vannak védve. A DefaultSequence Flow (aminek a szárát egy kis vonallaláthúzzuk) jelzi azt az utat, amerre akkor megy avégrehajtás, amikor az egyik feltétel sem teljesül.A Message Flow nyíl segítségével tudunk egyküldőtől üzenetet továbbítani egy fogadó pont-hoz. Az ilyen küldés és fogadás funkciókat el-látó egység a BPMN-ben a medence (Pool), amiegyébként mindig 1 workflow-t reprezentál.

28


3.7. ábra. Összekapcsolók (Connectors)

A tevékenységekből több Conditional Sequ-ence Flow (aminek a szárán egy kis diamondszimbólum van, ezért mini gateway-nek is hív-juk és használatára a 3.8. ábra mutat pél-dát) konnektor is kijöhet, amiket feltételekkel isvédhetünk. Minden egyes így létrejött ág pár-huzamosan folyik le. Az Assotiation feladata,hogy összetartozási relációt rendelhessünk egy-egy objektumhoz, információhoz, adathoz vagyartifact-hoz (műtermék).

3.8. ábra. Feltételes sequence flow

Végül az Exception Flow kapcsolók olyanok,amik eseményekből (lásd. később) képesek csat-lakozni, használatát a 3.9. ábra tanítja meg.Látható a „Work All Day” task, ami egy Timer-

rel rendelkezik. Amennyiben az idő nem „csat-tan el”, úgy a „Normal Flow” mentén történik atransition (átmenet), ellenkező esetben – time-out esetén – az „Eat Lunch” task lesz végre-hajtva.

3.9. ábra. Az Exception flow használata

Kapuk (Gateways, Átjárók)

A BPMN gateway-ek a workflow lefutásánakszervezésében játszanak szerepet, segítségük-kel a folyamatok szétválasztása és összeolvasz-

29


tása valósítható meg. Ezek az elemek az egy-szerű döntési elágazásoktól az összetettebb vég-rehajtási utak kialakításáig egyaránt nélkülöz-hetetlenek, amiket a nyilakkal (connector-okkal)együttműködve valósítanak meg. A gateway ál-talános jele a diamond (rombusz) alakzat, ahogyazt a 3.10. ábra is mutatja. Általában a dia-mond belsejébe valamilyen jel is kerül, amitmar-kernek hívunk. A markerek kiemelt szemanti-kával rendelkeznek, így a BPMN használata so-rán elkerülhetetlen alapos ismeretük, ezért ittmi is részletesen bemutatjuk őket. Az alapve-tően szekvenciális tevékenység-sorozatok (végre-hajtási utak=sequence flow) az átjárók segítsé-gével exclusive (kizárólagos, azaz csak sorosan 1ág megy tovább) és inclusive (párhuzamos) mó-don ágazhatnak el. A kapukon bizonyos irányok-ban engedélyezett vagy tiltott az átjárás. Ami-kor egy-egy út eljut a kapuig, mert minden előttelévő task végrehajtódott, akkor ez az átjáró szá-mára egy-egy beérkező TOKEN-t jelent, majdjön a gateway döntése, hogy az áthaladás melyirányokba lehetséges, azaz az output TOKEN-ek(nevezhetnénk stafétabotnak is) merre indulhat-nak tovább.

3.10. ábra. Gateway szimbólumok

Exclusive (XOR) gateway

A 3.11. ábra egy kizárólagos elágazást mu-tat, ahol az átjáró garantáltan csak az egyikirányba engedi tovább a munkafolyamat alakulá-sát. Emiatt ezzel a kapuval (üres rombusz) olyanelágazásokat lehet kialakítani, amely ágak közülkizárólag mindig csak az egyiken mehet továbba TOKEN. Innen ered a gateway elnevezése is.

3.11. ábra. Döntés XOR kapuval

Az üres és az „X”-et tartalmazó diamondszimbólum (ez egy opcionális lehetőség. A kapubelsejében most nincs „X”, de ha volna, az tel-jesen ugyanazt jelentené) egyaránt a XOR (ki-záró vagy) kaput szimbolizálja, amit az első kétalakzat mutat a 3.10. ábrán. Az XOR gatewaycsak addig vár, amíg az első lehetséges input megnem érkezik, utána engedélyezi a workflow foly-tatását, azonban mindig csak pontosan egyet-len irányba. Példánkban csak 1 befutó nyíl van,így a TOKEN csak onnan érkezhet. De melyikaz output irány? A válasz egyszerű, mert az,amelyik ág feltétele teljesül. Emiatt ezt dön-tési (decision vagy IF) kapunak is nevezik, amibiztosítja, hogy a process mindig a belső álla-potnak megfelelően – de csak jól meghatározotttevékenység-sorozat ágon – haladhasson tovább.A 3.12. ábra egy példával érzékelteti a XOR

30


kapu használatát. Az átjáró „Is Junk Mail” (Hul-ladék mail?) vizsgálata dönti el, hogy a workflowinstance (a BPMN a workflow példányt gyak-ran case-nek is nevezi) az „Open Mail” → ”ReadMail” → „Discard Mail” vagy a „Open Mail”→ „Discard Mail” tevékenység-sorozaton megy-ekeresztül.

3.12. ábra. Exlusive gateway példa

Inclusive (beleértett vagy megengedő OR)gateway

A kapuból kimenő elágazások közül egyszerretöbb ágon is továbbmehet a munkafolyamat. A3.13. ábra egy tipikus szituációban mutatja azOR kaput . Itt is döntésről van szó, de ellentét-ben a XOR kapuval a TOKEN minden iránybatovábbhalad, ahol a feltétel igaz, azaz itt egypárhuzamosság jöhet létre. Az OR gateway (in-nen származik a diamond belsejében a nagy „O”)addig vár, amíg az összes lehetséges input TO-KEN meg nem érkezik a kapuba (azaz szinkro-nizációt ad), majd utána engedélyezi a workflow

folytatását minden – az ágörző feltételt kielégítő– irányba. Az áthúzott szárú nyíl az un. „defaultpath”, ami felé akkor megy tovább a folyamat,ha egyik feltétel sem teljesül.

3.13. ábra. OR (Inclusive) gateway

3.14. ábra. Inclusive gateway példa

A 3.14. ábra egy tipikus használatot mutat.A „Documents Required?” kérdésre akár mind-három ág teljesülhet, mely esetben 3 taskot iskell párhuzamosan végezni. Ezek a taskok eltérőidőpontban lesznek komplettek, de ekkor ezt egyinput TOKEN formájában jelentik a jobb ol-dali exclusive átjárónak, aki tudja, hogy 3 dbTOKEN-t kell bevárnia. Amikor mindegyik step

31


készre jelentődik, akkor az output TOKEN elin-dítja a „Compilate Documents” taskot. Ez az útnincs feltétellel védve, így a transition meg fogtörténni.

Parallel (vagy AND) gateway

A parallel gateway szintén a párhuzamos utak(path) közötti szinkronizáció eszköze. Ez a kapuis kötelezően bevárja az összes lehetséges be-futó útról érkező vezérlést (TOKEN-t) mielőtt aworklfow futásának továbblépését engedélyezné.Amennyiben a kapuból több kimenő út is van(multiple output), úgy mindegyik útirány min-denfajta feltétel ellenőrzés nélkül megkapja a ve-zérlést (TOKEN-t). Aki ismeri az UML Acti-vity diagram (Tevékenység diagram) fork és joinszimbólumait, az a 3.15. és 3.16. ábrákról ráis-merhet ezekre a funkcionalitásokra. A Join sze-repkörben lévő átjáró természetesen szinkronizális mielőtt a folyamat továbblépését engedélyeznéegy output TOKEN-nel.

3.15. ábra. Parallel gateway - Fork szerepkörben

3.16. ábra. Parallel gateway - Join szerepkörben

A 3.17. ábra mutatja, hogy a BPMN 2.0-tól már nem szükséges a parallel gateway fel-tüntetése a feltétel nélküli párhuzamos elágazás-hoz, ugyanis a nyilak közvetlenül is kijöhetnek éscsatlakozhatnak a következő párhuzamosan el-végzendő taskokhoz.

3.17. ábra. A párhuzamosság másik jelölése

Complex gateway

3.18. ábra. Complex gateway

Ez a kapu (3.18. ábra) a párhuzamosan futóágak összetettebb szinkronizációs viselkedésénekkönnyebb modellezésére szolgál. Ahogy az Inc-lusive és Parallel kapuk, úgy ez is egyaránt hasz-nálható split (azaz párhuzamos ágak létreho-zása) és merge (párhuzamosan befutó ágak egye-

32


sítése) feladatra. Például ezzel jellemzőként köz-vetlenül beállítható a már ismertetett „N out ofM JOIN” workflow pattern viselkedése. Enneka döntéseket támogató kapunak a jele az asterix(csillag). A token jellegzetessége, hogy belső ál-lapota van, aminek konfigurálásával igény eseténösszetettebb viselkedés állítható be, például van-nak többszörözési lehetőségek és szabályok defi-niálhatóak rá.

Event-Based (Eseményalapú) gateway

A 3.19. ábrán látható event-based átjáró exc-lusive típusú, azaz a 3 lehetséges event receiveregyike fogja csak fogadni a beérkező TOKEN-t.Ellentétben a XOR kapu belső állapoton nyugvóinternal döntésén, itt a kapu mindig a külvilág-tól érkező jel alapján hozza meg a döntését. Vá-rakoztat az eseményen nyugvó TOKEN megér-kezéséig, amit értelmez és „Message 1”, „Message2” vagy „Time Out” esetén el is engedi az outputTOKEN-t.

3.19. ábra. Event-Based gateway

Események (Events)

Az esemény egy olyan valami, ami „megtörténik”és van a kiváltásának okozója. Az üzleti folya-mat lefutására valamilyen hatással van, befolyá-

solja az üzleti folyamat lefolyásának alakulását.Egy esemény képes elindítani (start), megszakí-tani (interrupt) vagy befejezni (end) a processt.Példák tipikus eseményekre: e-mail érkezett, 5óra van, hiba keletkezett, megüresedett a raktár.Az események keletkezésének fontosabb okai:

• elindult vagy befejeződött egy process(start vagy stop)

• valamilyen idő lejárt vagy bekövetkezett(time-out)

• egy hiba vagy egyéb kivételes állapot kö-vetkezett be a munkafolyamatban

• valamilyen szabály (rule) szerinti állítás el-kezdődött teljesülni vagy éppen azt meg-szegte a folyamat

• a workflow valamely pontja egy direct üze-netet küldött, ami egy másik helyen ese-ményként jelenik meg

Az esemény jele a kör, aminek a következő eseteivannak:

1. Kezdőesemény: (start events): egyszimpla körben van.

2. Köztes események: (intermediate events,valahol a process közepén keletkezhet):egy dupla körben van.

3. Záró események (end events): vastagítottkörben van.

Mindegyik eseménytípusnak 2 alfajtája létezik:

1. Sender eset: Amikor egy esemény elküldé-séről van szó (throw a message)

2. Receiver eset: Amikor egy esemény foga-dásáról van szó (catch a message)

33


3.20. ábra. Események (Events)

A kör alakú event szimbólumok belsejébenegy jelző szimbólum (marker) található, ami azesemény jellegére utal (3.20. ábra). A Generalevent nem tartalmaz semmilyen markert, mertez az esemény egy nem definiált okból váltódikki. Ilyen például egy workflow indítása. A Mes-sage típusú event (jele: boríték, envelop mar-ker) egy üzenet küldése vagy fogadása a munka-folyamat valamely részéről. A Timer eseményvalamilyen időpont bekövetkezésekor váltódik ki(jele: az óra, clock marker). A Conditional (fel-tételes) esemény (jele: vonalkázott papír, linedpaper marker) egy feltétel teljesülése esetén vál-tódik ki. Például a hőmérséklet nagyobb, mint30 fok.

Az eseményekről többet a használat konkrétszituációiban mutatunk majd be, de még a kö-vetkező fontosabb markerek vannak:

1. Nincs marker (üres kör): A folyamat kez-detét indító esemény jelöli. Köztes ese-mény indító és záró esemény között fordulelő. Befolyásolja a folyamat lefolyását, denem indít vagy fejez be (közvetlenül) fo-lyamatot. A záró esemény a folyamat be-fejezését jelöli.

2. Message (üzenet): Egy résztvevőtől üzenetérkezik és eseményt vált ki. Ha a folyamatüzenetre várt, akkor az üzenet start, con-tinue vagy end (indító, folytató vagy záró)hatással van rá, illetve ha kivétel történik,a folyam megváltozik. A záró típusú üze-net esemény azt jelöli, hogy a résztvevőnekegy üzenet kerül kiküldésre a folyamat be-fejezésekkor.

3. Signal marker : A jelek (signals) küldéséreés fogadására szolgál. Ez nem azonos amessage marker-rel, mert itt folyamatonbelüli kommunikációról van szó, míg az afolyamatok közötti jelzés eszköze.

4. Timer marker (időzítés): Beállítható egymeghatározott idő vagy ciklus, ami ki-váltja a folyamat indítását vagy folytatá-sát. Az idő alapú késleltetések modellezé-séhez köztes timer használható.

5. Rule marker (szabály): Ez a típusú ese-mény akkor kerül kiváltásra, amikor egyszabály feltételei teljesülnek. A szabályoknagyon hasznosak amikor folyamat hur-kot kell megszakítani, például: „Ismétlésekszáma = N”. Köztes szabály csak kivétel-kezelésre lehet használni.

6. Link marker (hivatkozás): A hivatkozás(vagy link) egy folyamat végét (eredmé-nyét) egy másik indításához (kiváltásához)kapcsolja. Az így összekapcsolt folyama-tok általában egyazon szülőfolyamat alfo-lyamatai. Hivatkozás használható példáulamikor a munkafelület (oldal) túl kevés -másik oldalra kell lépni.

7. Error marker (Hibaesemények kezelése):Az ilyen típusú záróesemény azt jelöli,hogy egy bizonyos hibát kell generálni. Ezta hibát egy köztes esemény fogja elkapni azesemény kontextusában.

34


8. Escalation marker : Egy eszkaláció küldése

9. Cancel marker (elvetés): Ez a típusú ese-mény a tranzakciós alfolyamatoknál jele-nik meg. Ezt a típusú eseményt az alfo-lyamat határához kell kapcsolni. Az ese-mény ki fog váltódni, amennyiben egy „El-vető Záró Esemény” történik a tranzakciósalfolyamatban.

10. Compensation marker : Ez a típusú ese-mény kompenzációkezelést (beállítás ésvégrehajtás) jelöl. Ha az esemény egynormál folyamat része, kompenzációt hívmeg. Amikor egy tevékenység határáhozvan csatolva, egy adott kompenzációs hí-vásra reagál. Nagyon hasznos tranzakciórollback modellezésére.

11. Terminate marker (befejezés): Ez a tí-pusú befejezés azt jelöli, hogy a folyamatminden tevékenysége azonnal befejeződik,beleértve a több-példányú tevékenységekminden példányát. A folyamat kompenzá-ció és eseménykezelés nélkül fejeződik be.

12. Multiple marker: Ez a típusú esemény afolyamat kiváltásának többféle módját je-löli. Ezek közül csak egy szükséges ahhoz,hogy a Folyamat elinduljon, folytatódjonvagy befejeződjön.

Az event szimbólumokat a konnektorokhoz (nor-mal event) vagy a tevékenységekhez (Boun-dary event) tehetjük. A következőkben mind-két esetre nézünk egy-egy példát, ezzel remélhe-tőleg érthetővé válik, hogy az eseményeket mi-lyen módon használjuk. A 3.21. ábra példájaegy kérdésekre adott szavazási folyamat részle-tét mutatja. Az „Announce Issues for Vote” taska kérdések feltevése, majd onnan a „Voting Res-ponse” Message event receiverhez (catching) ke-rülünk. Amikor jön egy válasz, akkor léphetünkis tovább az „Increment Tally” stephez, azaz nö-veljük valamelyik szavazatra adott számot. Ezek

a lépések egy MI taskban is lehetnek, ekkor azösszes válasz összegyűjtésére alkalmas lenne azmunkafolyamatunk.

3.21. ábra. Normál (nem boundary) event

A 3.22. ábra egy boundary (határ) eseménytmutat. A „Receive Confirmation” stepet sza-bályosan elhagyhatjuk, amennyiben a time-outelőtt érkezik a megerősítés. Amennyiben 2 napis eltelt. úgy a task megszakad és a time-outágon a „Cancellation Notice” task kerül megva-lósításra. A határesemények tehát a taskhoz kö-tődnek, míg a normál események egy taskon kí-vül működnek.

3.22. ábra. Boundary event

A gateway-eknél foglalkoztunk már az EventBased átjáróval. után egy esemény bocsáthatóki. A 3.23. ábrán a döntés utáni ág elvégzi amegfelelő esemény kiküldését, amelyre ha meg-érkezik az event, akkor a „Process Request” taskfogja azt feldolgozni.

35


3.23. ábra. Normál határesemények

A 3.26. ábra egy nagyon hasznos összefogla-lást ad arról, hogy milyen esetekben, melyik ese-mény használható és milyen szerepben. Vegyükészre, hogy „körvonalas” marker jelzi az eseményelfogását (catching), míg annak dobását (thro-wing) a feketére színezett ikon mutatja.

Üzenetek folyamatot között

Az egyes folyamatok (medencék) egymással valókommunikációjának (Messages) bemutatásávalzárjuk az eseményekkel való ismerkedésünket,amire egy szemléletes példát ad a 3.24. áb-rán lévő BPMN diagram. Esetünkben az egyesmedencék a Customer és a Bank nézőpontját(perspective) mutatják, mint egymással kommu-nikáló folyamatok. A szaggatott, kitöltetlen fejűnyíl az üzeneteket közvetíti, az induló és érkezőpontja mindig egy-egy activity. Az üzenetet fo-gadó step mindig várakozik egy ilyen üzenetre,ami megérkezése esetén a task-ot felébreszti ésaz elvégezheti a szükséges feladatát. Például aCustomer „Request Cash” taskja küld egy kérek100$-t („Give me $100”) üzenetet a Bank „Re-ceive Request” erre várakozó taskja felé, amelyerre felébred és ezzel az információval mindjártkezdődhet a pénz elérhetőségének megerősítésestep („Confirm Availability of Cach”). Ezutánpárhuzamosan lehet elvégezni a Customer szám-lájának terhelését („Update Account Balance”)

és a pénz elküldését a Customer felé („DeliverCash”), ami egy „$100” üzenet a vevő irányába,aki ezt már blokkolva várja a „Receive Cash”activity-nél. A Bank előbbi párhuzamos mun-káját egy „+” rombusz, azaz parallel gatewayszinkronizálja, ugyanis amíg mindkét task nincselvégezve, addig a kiléptetésre való várakozásnaksincs értelme („Receive Logout Command”). ACustomer és Bank példa folyamata azt tanítottamost meg számunkra, hogy 2 folyamat milyenmódon tud együttműködni egy közös munkafo-lyamat teljesítése érdekében.

3.24. ábra. Folyamatközi üzenetek (Messages)

36


3.25. ábra. Az események rendszerezése

37


Medencék (Pool) és Sávok (Lane)

3.26. ábra. Medencék és sávok (Pools and Lanes)

Ezt a témakört az előző pont utolsó példájábanérintettük, most az ott megszerzett ismeretekhezszeretnénk néhány további kiegészítést tenni. Amedence és sáv leginkább egy szervezetet, sze-repkört, rendszert vagy felelősségi kört jelöl. Pél-dául: Egyetem, Kereskedelmi divízió, Raktár,ERP rendszer. A sáv a medence felosztásábólszármazó rész, melyet a tevékenységek továbbirendezésére és kategorizálására használnak, ígykiváló eszköz a karakterisztikus folyamatok jel-lemzők szétválasztására. A medence egy folya-mat résztvevőjét jelöli (Actor) és valamilyen üz-leti folyamatot tartalmaz, amit B2B szituáció-ban is kiválóan lehet használni (lásd. a 3.24.ábrát). A medencék közötti párbeszéd a mes-sage flow segítségével valósítható meg. A lanekülön partíciókra oszthatja a medencét, amely

sávokban a szervezeti szerepkörök vagy valamimás karakterisztikus folyamat jellemzők választ-hatóak szét. A BPMN-ben történő medence éssáv ábrázolást a 3.26. ábra mutatja.

A 3.27. ábra alapján való működés az ed-digiek alapján már könnyen megérthető, azérttettük csak ide, mert megtanítja, hogy a „POMessage” message-hez érdemes asszociálni egyartifact-ot (terméket), ami most egy Order ob-jektum. Az ebben lévő információ kíséri az üze-netet. A Seller (eladó) egy megrendelés ajánla-tot küld a Buyer (vevő) részére, aki éppen errevár, mert az ábrán nem látható előző lépésekegyikében ilyet kért.

3.27. ábra. Pool and Lane sample

Termékek (Artifacts)

A 3.28. ábra a BPMN beépített artifact-okatmutatja. A termék kiegészítő információkatnyújt a folyamatról, így használatával teljesebblesz annak a dokumentálása és megértése. Szük-ség esetén a modellezők és a modellező eszközökszabadon hozzáadhatnak új termék típusokat is,amiket akár ezekből is származtathatják. A be-épített termékek a következőek:

38


• Objektum: Az adatobjektum információtszolgáltat arról, hogy milyen eseménye-ket szükséges kiváltani és/vagy azok mithoznak létre. Az objektumok (Data Ob-jects) olyan termékek, amik a folyamatközben jönnek létre, illetve egy másik te-vékenység input információként is használ-hatja. A tevékenységekbe befutó INPUTés OUTPUT igény szerinti reprezentálá-sának elengedhetetlen eszköze. A terméknincs közvetlen hatással üzenetfolyamravagy szekvencia-folyamra. Az adatobjek-tumnak lehet állapota is. Példák adat ob-jektumra: Egy levél, E-mail üzenet, XMLdokumentum, Megerősítés.

• Csoportosítás : A csoportosítás dokumen-tációs és elemzési célt szolgál, ugyanak-kor használható medencék közötti elosz-tott tranzakciók tevékenységeinek azonosí-tásához is. A tevékenységek csoportosításanem befolyásolja a szekvencia vagy üzenet-folyamot.

• Megjegyzés : Megjegyzések segítségével amodellező további információkat nyújthata BPMN diagram olvasójának. Az Anno-tation (Text Annotation=megjegyzés) szö-veges kiegészítéseket tud rendelni mindenprocess elemhez, amihez az asszociációskonnektort használja.

Ezen BPMN elemek tehát olyan további infor-mációkat képesek szolgáltatni, rögzíteni egy-egy

workflow-ról, amit az eddigi elemeket kiegészí-tik. Ezek azonban nem részei a BPMN-ből mo-dellből generálgató implementációnak, viszontaz üzleti analitikus munka során elengedhetet-lenül fontosak.

3.28. ábra. Egyéb műtermékek (Artifacts)

A 3.29. ábra is példát mutat az Objektumtípusú termék használatára. Jól látható, hogy atask és az Order objektum közötti asszociációskapcsolat feltüntetése milyen sokat tud jelentenia teljes folyamat működésének megértésében.

3.29. ábra. Az Objektumok használata

39

Business Process Management A Bonita Workflow motor áttekintése

4. A Bonita Workflow motor áttekintése

Ebben az összefoglalóban elkezdünk megismerkedni a Bonita nevű BPM motorral, ugyanis azeddig tanult elméleti tudásunkat csak akkor tudjuk fejleszteni, ha valamilyen konkrét eszközzel kiis próbáljuk. A Bonita egy nagyon fejlett és kimagasló képeségekkel rendelkező szoftver (webhely:http://www.bonitasoft.com/). A szerző először 2004. évben találkozott ezzel az eszközzel,ami akkor már stabil és produktív verzióval rendelkezett. Akkorriban az ObjectWeb (webhely:http://www.ow2.org/) community keretében fejlődött ez az alkalmazás, amit mindenkinek jószívvel ajánlok bármilyen nagyvállalati produktív megoldáshoz is.

4.1. ábra. Bonita Studio

Mi a Bonita?

A Bonita egy olyan szoftver, ami a BPM megol-dások (workflow alkalmazások) számítógépes au-tomatizálásához szükséges minden szerver oldaliés fejlesztő eszközt megad. Három nagy részbőláll:

1. Egy hatékony BPM/Workflow motor,amely a workflow alkalmazások futási kör-nyezetét biztosítja (részletesen az 5. cikktárgyalja ezt a témakört).

2. A Bonita Studio (4.1. ábra) a BPMNalapú workflow építést, a feladatok mögött

40


lévő web alkalmazások készítését és a sze-repalapú feladat hozzárendelések definiálá-sát támogatja. Ezen eszközben készíthetőel az a produktum, amit a workflow motorfuttatni képes (részletesen a 6. cikk tár-

gyalja ez a témakört).

3. A felhasználók részére biztosított egy egy-séges munkakörnyezet, a User Experience(részletesen a 7. cikk tárgyalja ez a téma-kört).

4.2. ábra. A Bonita BPM platform felépítése

A 4.2. ábra mutatja a Bonita architektúrá-ját. A stúdióban fejleszthetünk, amit a BonitaExecution Engine környezetbe lehet telepíteni.A felhasználók (3 típusa van: egyszerű végfel-használó, folyamat adminisztrátor és fejlesztő) aBonita User Experience GUI környezetben tud-ják a feladataikat elvégezni. A generált web űr-lapok is beépülnek ebbe a környezetbe, így azo-kat ezen egységes munkakosáron keresztül is ellehet érni, ami lehetővé teszi a feladatok köz-ponti felületen való teljesítését. Az ábráról nemtűnik ki, de vannak további kiegészítő részei isa platformnak. A hitelesítés (autentikáció) ésjogosultságkezelés (authorization) komoly és fej-lett támogatással rendelkezik. A külvilággal ki-terjedt konnektor készlet biztosítja a kommuni-kációs kapcsolatokat, ahogy azt a 4.3. ábra ismutatja.

4.3. ábra. Bonita konnektorok41


A következő pontban egy-egy gondolat ere-jéig, de kirészletezve bemutatjuk a Bonita leg-fontosabb lehetőségeit. Maga a szoftver teljesegészében Java környezetre épül, így az egyiklegfontosabb jellemző természetesen az, hogy ezaz önmagában sem kicsi technológiai együttesegyszerűen elérhető és használható.

A Bonita lehetőségei

Folyamat modellezés

• A munkafolyamatok tervezéséhezmegismertük a BPMN-t, ami a Bonitaegyik legalapvetőbb eszköze, ennek hasz-nálatához nagyon fejlett támogatást nyújt(BPMN2 process modeler).

• Fejlett szerep kezelés (Advanced roleresolving and filtering). A feladatok sze-repkörökhöz vannak rendelve, amiket amunkafolyamat használatakor felhaszná-lókra és csoportokra oldunk fel, miközbenezt a filterekkel is finomhangolhatjuk.

• A Bonita Stúdió támogatja, hogya process tervezését az üzleti kolléga, azelemző, tervező és programozó közösen,ugyanazon eszközben kezelhesse (Collabo-rative process modeling).

• A megtervezett és elmentett folyama-tok BPMN leírásait központilag el lehetérni, így a folyamatok leírásai és leltáramindig rendelkezésre áll (Central reposi-tory).

• A BPMN ábrák készítésekor a ter-vező támogatja, hogy egy-egy rajzelem he-lyi menüjéből kezdjük meg az ábra rajzo-lásának a folytatását (Context palette for

fast design), ritkán kell használni a klasszi-kus eszközpaletta ablakot. Ez a modernmegközelítés gyorsítja a design implemen-tálását.

• A tervezés során a külső rendszerkap-csolatokat konnektorokkal lehet reprezen-tálni, amiből sok előre elkészített is van(SAP, adatbázis, MS Exchange és SPS,LDAP, különféle közösségi oldalak, stb.),de a fejlesztők igény szerint újat is készít-hetnek (Contributed connectors).

• A Bonita támogatja az agilis fejlesz-tést, mert az iteratív fejlesztés-tesztelésciklus hatékonyan megvalósítható vele(Iterative development).

• Képesek vagyunk a process-t megvál-toztatni az éles környezetben is, miközbenaz élő tranzakciókat át lehet venni a régidesignból az újba (Live process update).

• A fejlesztés során sok ellenőrzési lehe-tőség van, ami azt vizsgálja, hogy az ép-pen aktuálisan tervezett process kész van-e már és kielégíti a tervezés alapvetőenigényelt feltételeit (Process diagrams vali-dation). Például egy taszk rendelkezik-emár beállított actor-ral, akinek a feladatotvégre kell hajtania. Valamely hiányosságesetén a tervező felület erről hibaüzenetetküld.

• Manapság a BPMN mellett még többrégi tervezési nyelvet használnak: XPDL,jBPM. Ez a funkció lehetővé teszi, hogyezekből importáljunk process-t a projek-tünkbe, így a legacy megoldások migrálásais könnyebbé válhat (Process import mo-dules).

42


• A szimuláció jelentőségéről már ír-tunk, itt azt szeretnénk kiemelni, hogya Stúdió támogatja, hogy ilyen eszközthasználva teszteljük és optimalizáljuk amegtervezett folyamatokat (Process simu-lation).

• A verziókezelés támogatása (Processversioning).

A megtervezett folyamatok BPMN rajzai ex-portálhatóak különféle grafikus formátumokba:JPG, SVG, PNG, BMP, GIF, PDF.

Fejlesztés

• Az implementáció során az egészworkflow-t kísérő globális, illetve egy-egytask szintjén jelentkező lokális adatokathasználunk. A Bonita fejlett adatkeze-lést (Advanced data management) biztosít,ugyanis azok típusa lehet egy Java osztály,XML példány, illetve csatolt dokumentumis.

• A Bonita stúdió másik kiemelkedő le-hetősége, hogy a GUI-k generálását au-tomatikusan, illetve testre szabott módonis el lehet végezni az Application Builderfunkcióval. Lehet GUI template-eket ké-szíteni, amiket az automatikus űrlap gene-rálók alkalmaznak. Fejlett mező és formvalidációk adhatóak meg. A formok lapoksorozata (Page Flow, azaz lehet lapozni aformok között) is lehet, amivel kényelmesfelhasználói felületek készíthetőek.

• Több, mint 100 előre beépítettkonnektor (Built-in connectors) segíti aworkflow-t implementáló szakember mun-káját, amikkel az ismertebb informatikai

rendszereket (SAP, Exchange, ...) el le-het érni, azokkal az üzenetváltás (adat-csere vagy egyéb okból) könnyen megvaló-sítható. Rugalmas lehetőség a saját kon-nektorok készítése, amit Java nyelven lehetelvégezni, emiatt gyakorlatilag bármilyenműködésre megtanítható (például megsze-rezni, hogy hány fok van most San Fran-ciscóban).

• Ez a funkció lehetővé teszi, hogy üzletiszabályokat tároljunk el (Business Rules),amik különféle feltételektől való működéstbiztosíthatnak, lényegében kódolás nélkül.Ezzel a tevékenységek közötti átmenetekszabályai is jól definiálhatóak.

• Amikor a workflow egyes task-jaitimplementáljuk, akkor sok apró adatke-zelési művelet szükséges, amit egy erre acélra szolgáló eszköz a Data managementeditor támogat. Itt a Groovy script nyel-vet használjuk az algoritmusok és adathi-vatkozások leírására.

• A fejlesztés iteratív folyamat, ahol fo-lyamatosan tesztelni, esetenként a műkö-dést nyomkövetni kell (Debug and Test),amihez a Bonita Studio beépített eszközö-ket biztosít.

• A fejlesztői környezet szabványosHTML alkalmazásokat generál az egyestaszkok kezelésére. A generált vagy atestre szabott űrlapokat egy előzetes temp-late alapján is el lehet készíteni, erre erőstámogatást nyújt a Bonita.

A Workflow motor (futtatás)

• A Bonita Workflow motor (ScalableWorkflow Engine) megbízhatóan használ-

43


ható nagyvállalati környezetben, feladataa megtervezett munkafolyamatok számító-gépes futtatása, ahhoz informatikai infra-struktúra környezet biztosítása. Az engineképes szinkron és asszinkron (Synchrono-us/Asynchronous execution) működésre isés teljes körű tranzakciókezelést szolgáltat.

• A humán feladatok szerepkörök sze-rint vannak a felhasználókhoz rendelve.(human tasks management) Ezen szerep-körök a fejlesztés során alakíthatóak ki.

• A BPMN modellezés során eseményekhasználhatóak, amiket a Bonita teljes kö-rűen támogat (Event processing).

• Elképzelhető, hogy néhány feladatmegoldásához (például írunk egy teljesentestre szabott Google Webtoolkit alapúklienst) közvetlenül a motor API-ját sze-retnénk használni (Powerful APIs). Eztkülönféle technológiákon keresztül is meg-tehetjük: EJB4 2 vagy 3, egyszerű Javakönyvtár (jar file), REST webservice felü-let.

• A környezet jól támogatja az újworkflow engine verziókra való áttérést(Migration tool).

Egységes munkakörnyezet

• A Bonita User Experience egy mail-box szerű felület, ahol kezelhetjük a fel-adatainkat, folyamat példányokat. Lehe-tőséget ad a feladatok delegálására és többegyéb szükséges tevékenység elvégzésére is.

Maga az alkalmazás egy web felület, amireSSO módon léphetünk be, így integrálhatóa meglévő portálunkba is.

• A munkafolyamat futása során ke-letkezett eseményeket figyelemmel kísér-hetjük, fogadhatjuk a folyamatok esetle-ges automatikus hiba és státusz jelentéseit(Real-time follow-up and alerts).

• A címkézés és kategorizálás nagyonhasznos funkció (Labels and categories),ugyanis amikor a taszkjaink száma és fé-lesége elkezd nőni, akkor ez teszi lehetővéazok rendszerezését és áttekinthetőségét.

• A Bonita képes többnyelvű módonműködni (Multilingual support). A nyelvilefedettség jelenlegi helyzetét itt tekinthet-jük meg: http://www.bonitasoft.org/translations/.

• Hatékony adminisztrációs lehetőség,amivel több távoli (hálózaton keresztül el-érhető) workflow motor (Remote enginemanagement) is menedzselhető ugyanazongépről.

• Az eszköz kiválóan integrálható a Fa-cebook, Twitter és egyéb közösségi hálóza-tokkal (Social BPM ).

• Az egységes munkakörnyezet szerep-körök szerint szolgáltatja az elérhető funk-cionalitásokat (User settings).

4EJB = Enterprise JavaBean5BI = Business Intelligence6BAM = Business Activity Monitoring

44


Monitorozás

• A Bonita hasznos és érdekes lehető-sége a BI5 és BAM6 funkciók támogatása,amihez jól testre szabható dashboard, sta-tisztikai és riportkészítési eszközöket is biz-tosít. A BI rendszerekről a korábbi In-formatikai Navigátorban írtunk. Az üzletiaktivitás monitorozása pedig a mindenna-pok tevékenységeinek figyelését jelenti, el-sősorban azonnali beavatkozás vagy álta-lános folyamat optimalizálási céllal.

• A megfelelő jogosultságok (olvasás,módosítás) finomszemcsés kalibrálási lehe-tősége is épít a használat monitorozására(Advanced right management). Lehetőlegmindenki csak annyi jogot kapjon, ami fel-tétlenül szükséges a számára.

• A monitorozás során észlelt folyamat-hibák korrigálhatóak, az azokat kísérő ada-tok auditálható módon javíthatóak (Datamanagement).

• A dashboard részére KPI-ok határoz-hatóak meg, amik gyűjtése a monitorozásszerves része.

• A munkafolyamat életciklusa mene-dzselhet (Process lifecycle management),engedélyezhető, letiltható és archiválható.

• A feladatok valós időben szintén me-nedzselhetőek (Tasks management), azokfelfüggeszthetőek, folytathatóak, stb.

• A workflow felhasználói és csoport-jai a létező user adatbázisokkal (LDAP,AD, adatbázis) összerendelhetőek (Usermanagement and mapping), így azok esz-közeivel is figyelemmel kísérhetjük a rend-szer használóit.

A szimulációk és elemző riportok (4.4. ábra)lehetősége kiemelkedően hasznos és jó eszköz atöbbi hasonló BPM eszközzel összehasonlítva. Aszimulációk és statisztikák segítik a folyamata-ink hatékonyságának mérését, az optimalizálásilehetőségek megtalálását.

4.4. ábra. Bonita Dashboard lehetőségek

45

Business Process Management Bonita - A munkafolyamatok tervezése és megvalósítása

5. Bonita - A munkafolyamatok tervezése és megvalósítása

Kezdjük el! Ebben a pontban megtanuljuk, hogy a Bonita Stúdió segítségével miképpen tudunk egymunkafolyamatot BPMN eszközzel megtervezni. Megismerkedünk a workflow-kat kísérő globálisés lokális adatok megadási lehetőségeivel is. A feladatokhoz kötelezően hozzárendelendő actorokbeállítását is megérthetjük. Alapvető célunk az, hogy a BPMN ismeretében képessé váljunk azt aBonita környezetben hasznosítani.

5.1. ábra. A Bonita Studio munkafelülete

A Bonita Stúdió áttekintése

A fejlesztői felület részei

Az 5.1. ábra a Bonita fejlesztői környezet főbbrészeit mutatja, amikre a továbbiakban sokat fo-gunk hivatkozni, így itt most röviden áttekint-jük. A Menubar hagyományos menürendszerenkeresztül teszi lehetővé a program használatát,melyek közül a legfontosabb funkciók a Task barszalagon ikonként is megjelennek. Alaphelyzet-ben a bal oldalon található a Palette, amely

a BPMN szimbólumok rajzkészlete, használatamegegyezik a más programoknál már megszo-kott technikával (Drag and Drop). A munkafo-lyamatokat (azaz a nekik megfelelő Pool-okat)reprezentáló BPMN diagramok a Whiteboard -ra készülnek. A bal alsó sarokban található azOverview panel, biztosítva a whiteboard átte-kintését és azon való gyors mozgást. Az utolsóterület, amit meg kell jegyeznünk a Detail Pa-nel. Itt a BPMN munkafolyamat minden jel-lemzőjét (adatok, actor-ok, GUI űrlapok) ké-

46


nyelmesen be tudjuk konfigurálni. A megjelenőtöbblapos property sheet mindig arra a BPMNelemre (tevékenység, esemény, átmenet nyíl) kí-nálja fel a jellemzők beállítását, amelyik aktív,azaz amelyikre utoljára kattintottunk az egér-rel. A most ismertetett képernyő részletekre atovábbiakban mindig ezekkel a nevekkel fogunkhivatkozni: Palette, Whiteboard, Overview, De-tail Panel, Menubar, Task bar. Az Edit → Pre-ferences→ Bonita→ Studio menüpontnál a stú-dió egészére vonatkozó beállításokat (például ahasznált nyelv) lehet elvégezni.

A Palette panel

5.2. ábra. A Palette panel

Az 5.2. ábra a Palette eszközkészletét mutatja, 3különféle nézetben. Látható, hogy a BPMN tel-jes fegyvertára használható a folyamatok meg-tervezéséhez. Ez a választás hatékonnyá és kor-szerűvé teszi a Bonita platformot. Az egyes ele-meknek mindig valamilyen medencén (pool) és

sávon (lane) belül kell elhelyezkedniük, ugyanisa munkafolyamatokat a medencék reprezentál-ják.

A helyi eszközök használata

5.3. ábra. A helyi eszközök (Context Panel)

Az 5.3. ábra mutatja, hogy egy whiteboard-onlévő BPMN elemre kattintva és az egeret otttartva egy helyi eszközkészlet jelenik meg, aminagyon hatékonnyá teszi a tervező munkát. Gya-korlatilag a Palette használata ezzel minimálisraszorul vissza, hiszen – ahogy az ábrán is látható– a Step1 activity-re kattintva minden értelmesrajzolási lehetőséget folytathatunk. A megfelelőkis ikonból kiindulva létrehozhatjuk a következőtevékenységet, gateway-t, eseményt. A Transit-ion nyíllal egy létező elemre való összeköttetésttehetünk meg. Az éppen aktív elemünkhöz vala-milyen megjegyzést (Text annotation) tehetünk.A Tools pedig egy helyi menüs beállítási lehető-séget biztosít.

5.4. ábra. Detail Panel

47


A Detail Panel

Az egyes elemekre, a teljes diagramra, meden-cére vagy egy sávra a jellemzőket a Detail Panel-en (5.4. ábra) tudjuk beállítani. A General fülaz adott kontextusra értelmezhető beállítási le-hetőségeket gyűjti össze, amiket az ábrán a kö-vetkező alfülekkel láthatunk:

• General: általános jellemzők, például aBPMN elem neve.

• Advanced: Az opcionális finombeállítá-sok, például egy activity legyen-e multiinstance-os.

• UserXP: Itt az egységes munkakörnye-zetre, azaz a User Experience-re tehetünkbeállításokat.

• Data: Az elemre, annak belső állapotárajellemző adatokat adhatjuk itt meg (Java,XML vagy csatolmány).

• Actors: Az activity-hez rendelt szerepkörmegadása.

• Connectors: A kimenő konnektorra vonat-kozó feltételek beállítása, amellyel szabá-lyozható, hogy a munkafolyamat folyta-tása abba az irányba mehet-e vagy sem.

Az Application fül a generálandó GUI űr-lap(sorozat) beállítási lehetőségeit tartalmazza,míg az Appearance az egyes design elemek ki-nézeti beállításait (betűk, vonalak, színek) teszilehetővé. A Simulation tab a process szimulá-cióhoz szükséges input adatok megadását bizto-sítja.

Az Overview panel

Az overview panelnek 2 nézete van: fa és gyors-navigáló nézet. A fa nézet az elemek egymáshozviszonyított logikai elhelyezkedését is mutatja,

így a fában gyorsan megkereshetjük azt a kom-ponenst, amivel éppen valamit csinálni szeret-nénk. A gyorsnavigáló nézet kis méretben mu-tatja az egész whiteboard-ot, amiben egy kis tég-lalapocskát tudunk mozgatni. Ami ebben látszó-dik, azt látjuk a fehér munkaasztalunkon is.

Egy process tervezése

A Diagram a tervezési nézet legfelsőbb szintje,ebben helyezkednek el a munkafolyamatokatreprezentáló pool-ok, amiből általában több islehet egy diagramon. Magára a diagramra is te-hetünk beállításokat a Detail Panel-en, amennyi-ben minden medencén kívülre kattintunk azegérrel. A diagram nevén, verzióján és rövid le-írásán kívül Actor Selector -okat és dependenciá-kat állíthatunk be rá. Az előbbi egy alapértelme-zett szerepkör lehetőségek megadását, az utóbbia külső Java könyvtárak (*.jar file-ok) csato-lását jelenti. A következő alpontokban részle-tezzük a fontosabb BPMN diagram elemek be-állítási lehetőségeit. Emlékezzünk rá, hogy azösszes lehetséges beállítást minden esetben a De-tail Panel-en tehetjük meg, itt csak a legfonto-sabb jellemzőkre térünk ki. Minden komponensrendelkezik névvel, verzióval és rövid leírással,így ezt itt jegyezzük meg, a továbbiakban márnem hivatkozunk erre többet.

Medence (Pool) létrehozása

A pool a folyamattal ekvivalens fogalom, aBPMN diagramon több is lehet belőle, hiszen azegyes folyamatok üzenetekkel képesek egymássalkommunikálni, ami hatékony modellezési meg-közelítést tesz lehetővé. A pool-okat a Palettepanelről lehet a whiteboard-ra húzni. A me-dence Detail Panel-je mindegyik főfülön fontosbeállításokat enged meg. Nézzük meg röviden!Kezdjük a General főfüllel:

• User Experience (UserXP) beállítások (kü-lön cikk foglalkozik ezzel)

48


• Adatmegadási lehetőségek (Data fül). Amedencéhez, azaz a teljes folyamathoz köt-hető globális belső változók megadása.

• Actor Selector-ok megadása (lásd. ké-sőbb!).

• Konnektorok (Connectors): a medence ésa külvilág közötti kommunikációk támoga-tása.

• Függőségek (Dependencies): külső java jarvagy *.bar (bar=Bonita Archive) file-okcsatolása.

Az Application főfül a medencéhez társított al-kalmazás részlet (űrlap vagy űrlap sorozat) ki-alakítását biztosítja. Itt készíthetjük el a „firstform”-ot, amivel a most definiálandó processegy-egy példányát elindíthatjuk (a neve: EntryPageflow). Lehetőség van lokális átmeneti ada-tok (Transient Data) megadására is, amennyi-ben egy űrlapsorozatot készítünk, mert ez lehe-tővé teszi a 2 űrlap közötti kommunikációt.

5.5. ábra. A Sáv

Sáv (Lane) létrehozása

A sávokat csak valamely medence részeként (5.5.ábra) lehet létrehozni és az a feladatuk, hogy lo-gikailag strukturálják a medencén belüli BPMNelemeket. Ugyanakkor a Detail Panel-en mind-azon beállítások is tovább finomíthatóak – mostmár az adott sávra nézve – amit a pool-nál meg-adtunk (General, Application, Appearance, Si-mulation főfülek).

Feladatok (Task) definiálása

A feladat olyan aktivitás, amit egy ember vagya Bonita futtató környezet kezdeményez és hajtvégre. A BPMN-t ismertető összes task típusttámogatja a Bonita, itt csak emlékeztetőül fel-soroljuk ismét őket: Humán Task, Service Task,Call Activity (egy alprocess hívása), Script Task(egy Groovy script futtatása), Send Task (ami-kor a folyamat ehhez a task-hoz ér, az küld együzenetet), Receive Task (amikor egy folyamatideér, akkor ennél a tasknál várakozik egy üze-netre). A task típusát, egyéb jellemzőit (MultiInstance, Looping) és az őt kezelő web form ge-nerálásának paramétereit természetesen a DetailPanel-nél lehet megadni, ahogy azt a 5.6. ábrais mutatja.

5.6. ábra. A Task részleteinek beállítása

A prioritás Normal, High (magas) vagy Ur-gent (sürgős) lehet. A későbbiekben majd lát-juk, hogy a task-okhoz milyen kifinomult módontudunk akár egyedileg kialakított kezelő GUI for-mot is készíteni. A feladatok belső állapotát le-

49


író adatokat a Data alfülön lehet felvenni, eztlentebb részletesen is bemutatjuk. Az Actors al-fül a feladat lehetséges végrehajtóit állítja be. AConnectors tab pedig a task elindulásakor, befe-jeződésekor és más értelmes szituációkban mű-ködő külső, konnektorokon alapuló kommuniká-ciós lehetőségek beállíthatóságáért felel.

Események létrehozása

A Bonita elérhetővé teszi a BPMN 2 eseményekhasználatát, ahogy erről az 5.7. ábrán is meg-győződhetünk.

5.7. ábra. Bonita Events

Az események típusait a BPMN cikknél márleírtuk, említettük azt is, hogy a kör belsejé-ben lehet tele vagy körvonalas szimbólum. Azelső a sender, a második a receiver event cso-mópontot jelöli. Minden ott ismertetett tudni-való természetesen igaz a Bonitában is, így aztmost nem ismételjük meg. Példaként tekintsük

a kis levél ikonnal szimbolizált message even-thasználatát. Ez például egy acticity után kö-vetkezhet, a tele ikonos sender egy üzenetet ké-pes kibocsátani, majd jöhet egy következő tevé-kenység. Ez egy tipikusan asszinkron helyzet.Egy másik medencében a folyamatnak kell egykörvonalas levél ikonnal reprezentált event node-dal rendelkeznie, amely egy ilyen üzenetet el tudkapni. A sender event Detail Palette beállítá-sainál a Messages alfül az Add funkciója teszilehetővé a kiküldendő üzenet specifikálását. Ittmeg lehet adni a Target (cél) pool Target step-jének a nevét, azaz az üzenet pontos címzett-jét. Ugyanezen ablakban lehetőség van az üzenetbelső adattartalmának a pontos megadására is.A cél medence receiver event-jét ezek után úgykonfigurálhatjuk, hogy Catch Event property-jeugyanezen nevű Event-et kapja el. Itt egyelőrecsak a Bonita Studio lehetőségeit tárgyaltuk, azesemények (timer, signal, message, error) hasz-nálatáról a későbbiekben még lesz szó.

Kapu (Gateway) beiktatása

A BPMN cikknél részletezett gateway-ek rendel-kezésre állnak, azokat a Palette vagy a ContextPalette-ból könnyen el tudjuk érni és beszúrhat-juk a tervezés alatt lévő process diagramba.

5.8. ábra. Egy Gateway beszúrása

Az 5.8. ábra bal oldali része azt mutatja,ahogy a helyi eszközözök közül kiválasztjuk a„+” kaput, a jobb oldal pedig az eredményt mu-tatja. A beiktatott kapu beállításait utána a De-tail Panel-en szükség szerint módosíthatjuk.

50


5.9. ábra. A tevékenységek közötti átmenetek (Transition)

Az átmenet (Transition) megadása

5.10. ábra. Az átmenet Detail Panel-je

Amikor ránézünk az 5.9. ábrára, akkor vilá-gossá válik, hogy mennyire fontos a folyamat

leírásánál a „nyíl”, azaz az átmenet (Transit-ion). Az ábra egy Bonita folyamat terv ré-sze. A tevékenységek sorrendjének meghatáro-zása mellett azok a feltételek (Conditions) is ittadhatóak meg, amik őrködnek az állapotátme-netek felett. Amennyiben egy feltétel hamis,úgy abba az irányba nem lehet továbblépni. Atransition Detail Panel-jénél (5.10. ábra) lehetezeket a dinamikus feltételeket megadni, ame-lyek akár összetettebb Goovy scriptek is lehetnekvagy csak a Default Flow checkbox-ot szeretnénkbepipálni. Az ábrán a „Process_A” dinamikusmedence „Check_For_New_File” script típusúactivity-je figyeli, hogy jött-e új file a rendszer-hez. Látható, hogy a kimenet kétféle lehet, adefault (alapértelmezett) ág az, hogy igen. Amásik ágon („If nothing found”) akkor mehetünkki, ha nem. Itt várunk 10 másodpercet egy Ti-

51


mer event segítségével, majd a „+” kapunak ad-juk, hogy indulhat újra az új file ellenőrzése task.Azonban ebbe a „+” kapuba egy az előzőleg, afile megléte miatt kibocsátott end event-től isjön egy transition, így amíg az nem érkezik meg,addig a kapuból sem megy tovább a TOKEN.Ez az end event egyébként a „Process_B” folya-matot indítja, ami a file foldolgozására hivatott.

Nézzük még meg az 5.10. ábrán mutatotttransition Detail Panel további lehetőségeit is! ADefault Flow-t már ismerjük. Az átmenet felté-telének megfogalmazásakor (Condition bevitelimező) a következő lehetőségek közül választha-tunk:

• Edit Expression...: Amikor ezt választjuk,feljön a Groovy script editor, amivel össze-tett feltétel (condition) vagy szabály (rule)adható meg.

• Create Data: A feltételek megfogalmazá-sához új adatelemeket vehetünk itt fel.

• Edit Decision Table: A tábla használatátaz 5.11. ábra mutatja. Az állapot átmenetfeltételére több sort is megadhatunk, ígyezzel rögzíthetjük az összetett üzleti sza-bályokat.

5.11. ábra. A Decision Table szerkesztése

Megjegyzés hozzáadása

Mindegyik BPMN komponenshez – ahogy azta szabvány rögzíti – egy Text Annotation elemrendelhető, aminek az okos használatára szinténaz 5.9. ábra mutat példát. A workflow tervünkreezzel olyan kiegészítő megjegyzések kerülhetnek,amik jelentősen hozzájárulnak a folyamat isme-retének birtoklásához.

Actorok rendelése a feladatokhoz

Áttekintés

Az Actor egy egyed (konkrét szereplő, ember)vagy egyedek csoportja, aminek a folyamat ter-vezése során egy külön nevet adunk. A workflowmotor az actorokat hívja meg, hogy végezzék ela kiosztott feladatot, azaz őket rendeli a pro-cess tervezője az activity elemekhez. Ez a hozzá-rendelés történhet közvetlenül a task-hoz, vagyközvetve – amennyiben a step nem rendelkezikactor hozzárendeléssel – a sávon és a medencénkeresztül is, kaszkádolt módon. Minden HumanTask kötelezően kell, hogy actorral rendelkezzen.A munkafolyamat végrehajtása során a belépettfelhasználók (user) válnak actorrá. Egy actorhozzárendelés jellemzően dinamikusan elvégzettfeladat, így valójában a hozzárendelések készí-tésénél csak Actor Selector -okat tudunk elkészí-teni és őket rendeljük hozzá a process-hez. Azactor selector olyan, mint egy konnektor, a fel-adata azonban speciális, amennyiben az adotttask esetén azokat az egyedeket kell visszaadnia,akik ahhoz hozzá lesznek rendelve.

Egy Actor Selector létrehozása és fajtái

A pool szintjén a Detail Panel General → Ac-tor Selectors tab kiválasztása után az 5.12. ábraablaka nyitódik meg, ahol egy új, névvel ellátottActor Selector hozható létre.

52


5.12. ábra. Actor Selectors és típusai

Látható, hogy a szelektorok 3 kategóriábólkerülhetnek ki:

1. Bonita: Ezek a selectorok egy-egy actorlistát adnak vissza, amik a User Experi-ence eszközben vannak definiálva: Users(felhasználók), Roles (szerepkörök), Gro-ups (csoportok), Delegees (delegálások),Managers (vezetők), Team members (csa-pattagok).

2. Adatbázis (Database): Az actorok egykülső adatbázisból lesznek lekérdezve.

3. Címtár (LDAP): Az actorok egy LDAP-ból lesznek lekérdezve.

5.13. ábra. Egy Actor Selector kiválasztása

Az új actor selector létrehozása után az hoz-zárendelhető lesz bármely task-hoz, pool-hoz,lane-hez, amennyiben annak Actor Selectors al-fülét kiválasztjuk (5.13. ábra). Az Initiator sze-lektor alapértelmezésben létezik és azt a usertszolgáltatja, aki az egész munkafolyamatot el-indította az első, process indító űrlapon. AzLDAP és adatbázis alapú Actor Selector-ok lét-rehozásának technikai részleteit a Bonita tippekés trükkök cikk egy-egy részében fogjuk ismer-tetni, azonban most áttekintjük azok típusait:

• LDAP vagy adatbázis alapú Actor Selec-tor: Egy LDAP vagy adatbázis query ered-ményhalmaza adja az actor-ok listáját.

• Actor Selector egy workflow belső vál-tozóban tárolt lista alapján: Példakéntképzeljük el, hogy a process rendelkezikegy humanResources nevű belső változó-val, amely actorok listáját tartalmazza.Ezt persze dinamikusan karbantarthatjuk,de mindig van egy pillanatnyi user listabenne. Az ilyen típusú Actor Selector (Bo-nita → User List) megadásnál erre a válto-zóra így tudunk hivatkozni: ${humanRe-sources} és ez kijelöli a mindenkor vissza-adandó actorok listáját.

• Statikusan létrehozott Actor Selector. Afejlesztéskor egy vesszővel ellátott, későbbmár nem változtatható user lista. Példa:inyiri, jkovacs, lszabo esetén ez egy 3 eleműactor lista lesz.

• Egy egyedi actor visszaadása.

Filterezés

Amikor egy konkrét Task-hoz, Pool-hoz vagyLane-hez rendeljük a megfelelő Actor Selectornevét (General → Actors fül), akkor ezen műve-let során még szűkíthetjük azt a halmazt, amit aszelektor vissza fog adni. Vannak előre definiáltBonita filterek, de magunk is készíthetünk egy

53


olyat, ami az igényünket legjobban lefedi. Ezta Groovy script nyelven tudjuk implementálni.Az előre beépített filterek a következőek, amiketaz 5.14. ábra mutat:

• Actor continuity: Kiválasztani azt azactor-t, aki valamelyik előző task-hoz márhozzá volt rendelve. A beállításhoz azelőző taszk nevét kell megadni.

• Has Performed Tasks: Kiválaszthatóakazok az előző taszkok (itt most több ismegadható), amelyek actor-ainak halmazalesz ennek a stepnek az actor halmaza.

• A legrugalmasabb filter, amikor a script le-hetőséget választjuk és mi magunk készít-jük el Groovy nyelven.

5.14. ábra. Egy filterezési lehetőség kiválasztása

Fejlesztés alatt használható Actor-ok

A Bonita Studio használata során vannak előrebeépített, csak a fejlesztés során használhatóuser-ek: john, jack, james (a jelszavuk: bpm).Az admin user (jelszava: bpm) is használható,sőt a studio futtatás gombjára induló tesztelésalapértelmezésben ezzel a felhasználóval jelent-kezik be.

Egy folyamat belső adatai

A workflow állapotát leíró adatok

A workflow fejlesztése során a belső állapototreprezentáló adatokat hozhatunk létre, amelyek-nek 2 fajtájuk van:

• globális: Pool szintű, az egész munkafolya-mat minden pontján látható és

• lokális: Task szintű, azaz élettartamuk aTask-éval egyezk meg.

5.15. ábra. Egy új adat megadása

A változókat a Pool, illetve a Task General→ Data alfülön kezelhetjük (Add, Edit, Removegombok). Az Add gomb megnyomására az 5.15.ábra ablaka jön fel, ahol megadhatjuk az újon-nan létrehozandó változó nevét, leírását és tí-pusát. A Multipciplity lehet single vagy mul-tiple, attól függően, hogy egy egyszerű skalártvagy tömböt szeretnénk-e megadni. A háttér-ben ezek a workflow példányhoz köthető adatokadatbázisba lesznek perzisztálva. Amikor JavaObject típust választunk, akkor a rendszer ál-tal ismert típusok mindegyike használható, mégazok is, amiket mi készítünk el és a jar-t linkeljüka workflow-hoz. Amikor XML típust választunk,akkor ott annak az XSD sémája lesz bekérve.

54


Groovy kifejezések szerkesztése

5.16. ábra. Groovy kifejezések szerkesztése

A process belső adatainak elérése legkönyebbena Groovy script nyelven keresztül valósíthatómeg, mert az közvetlenül eléri (írja, olvassa) eze-ket a változókat. Az 5.16. ábra a Bonita beépí-tett Groovy szerkesztőjét mutatja (az Edit exp-ression kiválasztására jelenik meg az ablak).

Az alfolyamatok használata

Alfolyamatot (subprocess) azért hozunk létre,mert ezzel kisebb, áttekinthető részekre oszthat-juk az üzleti folyamatot. Ugyanakkor ennek amegközelítésnek van egy járuléskos előnye is, hi-szen a paraméterezhető subprocess-ek lehetővéteszik, hogy őket újrahasznosítsuk. Alfolyama-tot a Bonitában kétféleképpen használhatunk:

• Call Activity : Ekkor a step egy külső (má-sik digramon vagy Pool-ban van), újra-hasznosítható process-t hív.

• Event Subprocess : A folyamatunk be-ágyazva tartalmazza.

Call Activity

Bármely process hívható egy másikból, ha a CallActivity típusú task-ot használjuk, azaz ilyenreállítjuk annak típusát. Ezt az 5.17. ábra taskok-ra vonatkozó beállító paneljének segítségével te-hetjük meg, amit természetesen a Detail Panelentalálunk. Látható, hogy ilyenkor a meghívandóSubprocess-t is ki kell választani.

5.17. ábra. Call Activity beállítása

Amikor egy alprocess meghívásra kerül, ak-kor el kell látni induló adatokkal, hogy megfele-lően inicializálhassa magát. Ehhez a fő és alpro-cess közötti mapinget (belső változók összeren-delése) használhatjuk, ahogy azt az 5.18. ábratanítja. Az ábra a fő process változóinak alpro-cess változókra való leképzését mutatja, de eztigény szerint fordítva is, azaz SubProcess Data→ Source Data el kell végezni. Mindezt úgy kellértelmezni, hogy az alprocess elindulásakor átve-szi a számára szükséges változók értéket, majdlefutása után visszaírja a főprocess-be a relevánsadatokat. A Bonita biztosít egy jó refaktorálásilehetőséget, azaz egy összetettebb folyamatbólaz „extract a subprocess” menüponttal egy alfo-lyamat (egy másik menenceként a diagramon) ésaz őt hívó Call Activity automatikusan elkészül.

55


5.18. ábra. Process - Alprocess mapping

Event Subprocess

Ekkor az Activity típusát az Event Subprocessértékre kell állítani. A „+” jel itt is mutatja(5.19. ábra), hogy mögötte egy alfolyamat van,azonban rákattintva a Timeout Handler részleteihelyben fognak bejönni és az elem nyitott álla-potát a „–” jel mutatja.

5.19. ábra. Event Subprocess

A feladatok ismételt végrehajtása

A BPMN-t ismertető cikkben megtanultuk,hogy mit jelent az, ha egy task-nak a Loop jel-lemzőjét beállítjuk. Ilyenkor a task ismétlődikvalamennyiszer, illetve egy Groovy kifejezésselennek a feltételét is megadhatjuk. Láthatjukaz 5.20. ábrán, ahogy egy activity Loop felté-telét megadhatjuk, azaz beállítjuk az isLoopedrádiógombot. A task elindítása előtt vagy utánis megvizsgálhatjuk, hogy a Loop while feltételteljesül-e.

5.20. ábra. A Task Loop property-je

Multiple Instances (MI Task)

Ebben az esetben ugyanaz a feladat párhuzamo-san több példányban kerül végrehajtásra, ami-nek a részleteit szintén a BPMN cikkben olvas-hatjuk. Ahogy azt az 5.21. ábra mutatja, bekell állítani az is Multi-Instantiated checkbox-ot,valamint Instantiator -t és Join Checker -t kellmeghatározni.

5.21. ábra. MI Task konfigurálása

Tipikus példa szokott lenni az MI task-ra aszavazási folyamatban lévő szavazat leadási fel-adat, ami egy MI task. Ilyenkor az Instantiatorgondoskodik, hogy mindenki 1 alkalommal sza-vazhasson, míg a Join Checker biztosítja a szava-zatleadások korrekt befejeződését, hogy a szám-lálás elkezdődhessen.

Egy Instantiator konfigurálása

A Browse gomb megnyomásával (5.22. ábra)létrehozható Instantiator feladata, hogy minden

56


egyes task példányt a megfelelő adatértékekkelinicializáljon. Egy Instantiator hasonlít egy kon-nektorhoz, a különféle típusait az ábra mutatja.Például a Number of instances lehetőség válasz-tása esetén egy user (vagy actor) listát kell meg-adni, hogy az egyes task példányok kihez legye-nek rendelve. A Bonita sajátkészítésű Multi Ins-tantiator létrehozását is támogatja (Connectors→ multi Instantiation → New Instantiator me-nüpont).

5.22. ábra. Bonita Multi Instantiator

Egy Join Checker konfigurálása

5.23. ábra. Join Checker

Egy multi-Instantiated step párhuzamos utakathoz létre (multiple parallel paths), így azok be-

fejeződésekor történő szinkronizálást (Join) biz-tosítja ez a konfigurálási lehetőség (5.23. ábra).Látható, hogy többféle szinkronizáció közül vá-laszthatunk:

• az összes tasknak be kell fejeződnie

• csak valamilyen %-ban kell befejeződniüka taskoknak, stb..

Az időzítők (Timers) használata

Háromféle Timer létezik:

• Start Timer (zöld színű),

• Köztes Timer (Intermediate, kék színű) és

• Határ Timer (Boundary), ami egy stephez(azaz activity-hez) van csatolva.

5.24. ábra. Timer kiválasztása a palettáról

A Start és Köztes timerek feladata, hogy fel-függessze a folyamatot, amíg valamilyen időtar-tam (duration) el nem telik vagy egy konkrétidőpont be nem következik, mely esetben egy Ti-mer Event kerül kibocsátásra, aminek a kezelőjeegy konnektor hívást is el tud végezni. Ezzelegyütt a fő hatás az, hogy az addig felfüggesz-tett munkafolyamat elkezd folytatódni. A Boun-dary Timer mindig egy taskhoz kapcsolódik ésegy határidőt (deadline) reprezentál a task szá-mára, amiből így kétféleképpen tudunk kijönni.

57


Az első lehetőség, hogy a feladat normálisan be-fejeződött, míg a második esetben lejárt a taskhatárideje, így az megszakítódik és egy másikágon megy tovább a folyamat, miközben egy Ti-mer Event is kibocsátódik.

Egy Start Timer létrehozása

Tekintettel arra, hogy a Timer egy start event,így ez egy folyamat elindítására alkalmas. Ami-kor a Detail Panelen konfiguráljuk, akkor a névés leírás mellett a Timer Condition-t kell meg-adni, aminek a szerkesztő ablakát az 5.25. ábramutatja.

5.25. ábra. Egy Timer konfigurálása

Egy Intermediate Timer létrehozása

A process közepére bárhova betehetünk egy In-termediate Timer-t, ami képes azt várakoztatni.A Timer Condition résznél ilyenkor előzetesen 3lehetőségből választhatunk:

• Duration: egy bizonyos időtartamot vár

• Date: ebben az időpontban folytassa aprocess a futását

• Variable: egy változó értéke alapján dől ela folytatás időpontja

Egy Boundary Timer létrehozása

Ekkor a Timer egy taskhoz lesz rendelve, amintazt az 5.26. ábra vizuálisan is mutatja. A Step1task kap egy határidőt a végrehajtásra, amelyha lejár, akkor az meg lesz szakítva és a Step2irányába megy tovább a munkafolyamat.

5.26. ábra. Egy Boundary Timer

Üzenetek a munkafolyamaton belül

5.27. ábra. Throw link létrehozása

A BPMN kapcsoló események (Link Events)arra szolgálnak, hogy ezzel egy pool-on, azazmunkafolyamaton belül annak 2 pontja közöttüzeneteket tudjunk váltani. Az üzenetküldés he-lye a Throw Link, a fogadás pontja pedig a CatchLink ( 5.27. ábra). A Throw link esetén aztlehet megadni, hogy mely linkre mutat, míg aCatch link esetén azon linkek listája adható meg,

58


amelyről mutatnak oda. Ezzel a mechanizmus-sal lehet tájékoztatni a folyamat másik pontját,hogy a vele párhuzamos ág már elért valahova.

Üzenetek küldése és fogadása

A kis borítékkal jelölt Message Event a folyama-tok (medencék) közötti kommunikáció eszköze.A következő fajtái vannak:

• Throw Message: Elküldi az üzenetet

• Catch Message: Fogadja az üzenetet

• Start Message: A process elején van, elkapegy üzenetet, amire a folyamat elindul

• End Message: A process-t leállítja és külderről egy üzenetet

• Boundary Message: ez egy Catch Message,így ha elkap egy üzenetet, akkor a hozzá-rendelt task leáll és az üzenet által kijelöltalternatív ágon megy tovább a vezérlés

5.28. ábra. Egy Throw Message beállítása

Az 5.28. ábra mutatja, ahogy egy ThrowMessage konfigurálásra kerül a következő adatokmegadásával:

• Target Pool : Ennek a medencének szeret-nénk az üzenetet elküldeni

• Target Task : A célmedence ezen CatchMessage eleme fogadja az üzenetet

• Add data: Ilyen adatokat küldünk a másikfolyamat részére (hasonló felületen adhatómeg, mint a folyamat belső adatai)

• Az elküldött üzenet érvényességének lejá-rati időtartama

A fogadó oldal konfigurálását az 5.29. ábra mu-tatja. A Matching condition egy Groovy scriptlehet, ami belenéz az üzenetet kísérő adatba éscsak akkor kapja el azt, ha a megadott feltételreilleszkedik. A Boundary típusú Catch Messageműködése a Boundary Timer-ével analóg módontörténik.

5.29. ábra. Egy Catch Message beállítása

Hiba definiálása

Az Error elem feladata, hogy a hibás állapotróladjon információt a folyamat más pontjai szá-mára, a következő fajtái vannak:

• End Error : Leállítja a process-t és küldegy error üzenetet.

59


• Start Error : Fogad egy error üzenetet éselindít erre egy process-t

• Boundary Error : Elkap egy error üzene-tet, majd megszakítja azt a taskot, amihezcsatolva van

A konfiguráló felületek a Message event elemhezhasonlóak, azonban itt az adat helyett az errorkód adható meg.

Szignál létrehozása

A Signal az üzenethez hasonlóan szintén az in-formációk szétküldésének és elfogásának eszköze,így ennek is az az 5 db esete van, mint a message-nek, azonban itt csak egy-egy szignál kód (Stringkonstansok) küldésére és fogadására van lehető-ség. Az 5.30. ábra a már ismert működést mo-dellezi. Amikor a Step1 melletti szignál beérke-zik, akkor megszakad a task és a szignál ágánStep2 felé megy tovább a process.

5.30. ábra. Boundary Catch Signal

Tranzakciókezelés

A munkafolyamatok vonatkozásában a tranzak-ció egy olyan csoportja a tevékenységeknek (azazaz Activity elemeknek), amiket mindenképpenbe kell fejezni mielőtt a workflow folytatódna.A tevékenységek szinkron sorozata tranzakcio-nális a Bonitában. Amennyiben egy Activity as-szinkronra van állítva, úgy az külön tranzakciós

kontextust kap, a munkafolyamat pedig onnanegyből továbbhalad.

Konnektorok

A konnektorok világával egy külön cikkben fo-gunk megismerkedni, így a tudnivalókat ott fog-juk részletezni. Az 5.31. ábra egy tipikus kon-nektor használatot mutat, amikor egy HumánTask élettartam eseményeire egy-egy konnektorhívást „akaszthatunk” rá. A Select Event rész-nél külön konnektorokat rendelhetünk a task-bavaló belépéshez, kilépéshez, annak elindulásá-hoz, felfüggesztéséhez és folytatásához.

5.31. ábra. Konnektorok használata

Kategóriák

A kategóriák olyan címkék, amikkel a tervezőmeg tudja jelölni a konkrét process-eket és ezt aUserXP-ben is láthatjuk. Az 5.32. ábrán a „+”gombbal hozhatunk létre új kategóriát.

60


5.32. ábra. Kategóriák létrehozása

Egy Bonita kiterjesztés feltelepítése

A Menubar Extensions → Browse contributionsmenüpontjának kiválasztásával a Bonita Stu-dio hozzákapcsolódik egy szoftver repository-hoz, ahonnan plugin-eket tölthetünk le, ezzeltudjuk a lehetőségeinket bővíteni. Ez a helyazért érdekes, mert sok olyan kész komponensérhető el, amiket különben nekünk kellett volnaelkészíteni. Ilyenek tipikusan a konnektorok, dekész workflow megoldások is letölthetők, példáulelőre elkészített Collect-Feedback workflow.

5.33. ábra. Bonita szoftver pluginek

A folyamat tervek menedzselése

A Bonita Process főmenüje támogatja, hogy atervező létrehozza, menthesse vagy importálja aprocess file-okat.

5.34. ábra. A Process kezelése Bonitában

A process kipróbálása

Fejlesztés során helyben kipróbálhatjuk a fejlesz-tés eddigi állapotát, ha a Task Bar futtatás ikon-jára kattintunk. Ilyenkor a Bonita Studio előál-lítja a futtatható workflow alkalmazást, telepítiés el is indítja az admin user nevében. A háttér-ben ezek történnek röviden:

• a process-ek bar file-jának (Bonita Ar-chive) elkészítése

• a web alkalmazás generálása és becsoma-golása, a war file előállítása

• egy browser ablak nyitása és a workflowstart űrlapjának lekérése

61

Business Process Management Bonita - GUI készítése humán feladatokhoz

6. Bonita - GUI készítése humán feladatokhoz

A workflow alkalmazások fontos része az a grafikus GUI felület, ami lehetővé teszi, hogy új mun-kafolyamatokat indítsunk, feladatokat oldjunk meg vagy régebbi processek adatait lekérhessük. ABonita egy Application Builder eszközt kínál ezen feladatok hatékony és jó minőségű elvégzésére,amit ez az írás szeretne megismertetni a kedves olvasóval.

Áttekintés

A workflow minden egyes humán feladata, illetvemaga a workflow elindítása is egy-egy GUI felü-letet igényel. Az eddigiekben megismerkedtünka munkafolyamatok implementálásával, most aBonita felhasználói felületek készítését szeret-nénk részletesebben ismertetni. Elöljáróban fon-tos megérteni, hogy a Bonita minden taskhozgenerál egy alapértelmezett űrlapot (erre mu-tat példát a 6.1. ábra), ami persze nincs testreszabva, azaz sem kinézetre, sem funkcionali-tásra nem a legkidolgozottabb, viszont teszte-lésre vagy gyors prototípus készítésre kiváló esz-köz, mert azonnal tesztelhetjük vele magát amunkafolyamatot.

6.1. ábra. Nem testre szabott Bonita űrlap

Mire épül ez az automatikus űrlapgenerálás?A task rendelkezik a már ismert lokális, állapo-tát leíró adatokkal, illetve maga az egész pro-cesshez is léteznek globális változók. Ezen érté-kek kerülhetnek az űrlapra, de checkbox-szal ki

is válogathatjuk, hogy mely adatmezők kellenekcsak. Másfelől a Bonita rendelkezik előregyár-tott és azt bővíthető – például a cégünk logójáttartalmazó – html template készlettel is, amitkiválaszthatunk az alkalmazáshoz. Többféle ge-neráló template is készíthető, melyek röviden akövetkezőek:

• Process Template: Ez az a keret, amibenaz űrlapok meg fognak jelenni

• Form Layout template: Az űrlapok (htmlform-ok) template-je

Ugyanakkor az Application Builder segítségévelmező szinten is testre szabhatjuk az űrlapok ki-nézetét. Amennyiben egészen különleges igé-nyeink vannak, úgy bármilyen webes vagy GUIkörnyezetben (GWT, .NET) is elkészíthetjük azalkalmazás felületeit, hiszen a workflow engineegy külön API-n keresztül megszólítható, pon-tosabban java class, EJB vagy Rest webservicetechnológiákkal. Általában kétféle űrlapról be-szélünk:

• Entry Page (vagy PageFlow): Ez egy adat-bevitelre alkalmas űrlap.

• View Page (vagy PageFlow): Csak megje-lenítést tud biztosítani.

A pageflow űrlapok sorozatát jelenti, ugyanisegy-egy task-hoz képernyő szekvenciák is ren-delhetők. További lehetőség, hogy a hibaüzene-tek, welcome page-ek és Login form-ok is egye-dileg kialakíthatóak. A 6.2. ábra a Bonita FormBuilder-t mutatja, ami a Stúdio beépített részeés akkor tudjuk használatba venni, amikor az„Application” főfülön dolgozunk.

62


6.2. ábra. Bonita Form Builder

Látható, hogy az űrlapkészítő eszköz is ha-sonló felépítésű, mint a process designer modul,azaz van Palette, Whiteboard, Detail Panel ésOverview része.

Egy feladat kezelő űrlap létrehozása

Az alapok

Most ismerkedjünk meg azzal, hogy miképpentudunk egy workflow feladathoz felhasználói fe-lületet készíteni! Első lépésként ki kell válasz-tanunk a kérdéses activity téglalapját a BPMNábránkon, majd a Detail Panel Application főfü-let tegyük aktívvá és a 6.3. ábrán látható felülettárul a szemünk elé. Itt kiválaszthatjuk, hogymost adatbeviteli (Entry) vagy böngésző (View)űrlapot akarunk-e készíteni. Amennyiben a Skiprádiógombot választjuk, úgy nem lesz GUI meg-jelenítve ehhez a task-hoz, amikor a munkafolya-

mat odaér a végrehajtásban.

6.3. ábra. Application főfül

Az Add... gomb választásával a 6.4. ábraablaka jelenik meg, ahol kiválaszthatjuk azo-

63


kat az adatelemeket (ez most a Wheels és aCrome_line), amiket az űrlapra ki szeretnénktenni. A Bonita az egyes adattípusoknak megfe-lelően javaslatokat ad az arra jól illeszkedő gra-fikus Widget típusára, ahogy azt az ábráról isláthatjuk. A varázsló Finish gombjára kattintvajön be a 6.2. ábra ablaka, azaz a Form Builder.

6.4. ábra. Egy új Form létrehozása

A 6.5. ábrán látható automatikusan generáltform persze testre szabható, sőt utólag új mező-ket és oszlopokat is felvehetünk vagy törölhetünkaz ábrán jelzett „+” és „–” ikonok segítségével. AWidget cellák mozgathatóak is, áttehetjük őketegy másik sor, oszlop pozícióba (Drag’n’Drop).Amennyibe szükséges, úgy több cellát egyesíthe-tünk is (merge).

Egy új Widget finom beállítása

A Bonita által biztosított grafikus vezérlő elemekkészletét a 6.6. ábra mutatja.

6.5. ábra. Sorok és cellák törlése, hozzáadása

6.6. ábra. Widget készlet

A generált űrlap bármely mezőjére állva, an-nak Detail Panel-en lévő property-eit beállíthat-juk. A 6.7. ábra mutatja a kiválasztott és ge-nerált Wheels mező beállítási lehetőségeit. AWidget típusa – kizáró választás lévén – rádió-gomb csoport vagy Select mező lehet. A Name

64


(a vezérlő neve) és label (szöveges címke a ve-zérlő mellett) beállítása mindenképpen ajánlott.A label Groovy kifejezés is lehet, így ezzel azI18N 7 is hatékonyan megoldható.

6.7. ábra. Az űrlapmező jellemzőinek beállítása

A Widget készletben a korszerű Suggestbox (autocomplete funkció, 6.8. ábra) vagyaz Editable grid is megtalálható. A Sug-gest Box Available values értéke egy JavaMap<String,String> típus.

6.8. ábra. A Suggest Box beállító ablaka

A Text és Message típusú mezők csak meg-jelenítők, azaz read-only módon használhatóak.A Table egy konténer, ami mátrix alakú elrende-zést tesz lehetővé a workflow belső változóinakmegjelenítésére. A beállítási lehetőségeket a 6.9.és 6.10. ábrák foglalják össze.

6.9. ábra. A Table Widget jellemzői

6.10. ábra. Table Widget - Megjelenés

A szerkeszthető rács

Az Editable Grid Widget egy táblázatos adatbe-viteli lehetőséget biztosít. Sok beállítása van, deezek megszokott műveletek, így itt nem részle-tezzük. Az rácson editálható értékekeket a Cellsmezőnél rendelhetjük a workflow belső változói-hoz.

6.11. ábra. Editable Grid beállításai7I18N=Nyelvfüggő szövegek

65


Az űrlap mezők Options beállításai

Minden mezőre beállíthatjuk (6.12. ábra),hogy kötelező legyen-e a kitöltése (Is mandatorycheckbox), illetve csak olvasható legyen (Readonly checkbox). A kötelező mezőknél megad-hatjuk azt a szimbólumot is, ami ezt jelzi, java-soljuk, hogy ez a szokásos „*” karakter legyen.Az Insert widget if egy nagyon rugalmas lehe-tőség, ami azt szabályozza, hogy a mező csak amegadott kifejezés igaz esetében jelenik meg. Ajogosultsági rendszer finombeállításának kiválóeszköze.

6.12. ábra. Az Options alfül lehetőségei

Az űrlap előzetes megtekintése

A munka során időnkét érdemes az űrlap ki-nézetét gyorsan leellenőrizni, amit a Previewikon használatával tehetünk meg. Ez megmu-tatja, hogy milyen form lesz generálva az alkal-mazásba.

A mezők érték tartalmának pontosítása

A Detail Palette Data alfülön kiválasztható ab-lak (6.13. ábra) az egyes mezőkre (esetünkbenpéldául a Wheels mezőre) lehetővé teszi a mezőkmögött lévő értékeket újradefiniálását. Az ablakAvailable values része egy Stringek listája vagyegyMap, ahol a címkék (label) és értékek (value)adhatók meg. Az Initial value lehetővé teszi,hogy egy induló értéket adjunk meg. Az Expres-sion mező ${field_Wheels} GUI szintű változójaa ${Wheels} belső változóba (Save to) menti azértéket, de ez itt átkonfigurálható, illetve a mezőváltozó helyett a forrás érték akár egy Groovyscript eredménye is lehetne. Amennyiben mégnem létező belső változóba szeretnénk menteni,úgy azt itt is létrehozhatjuk a Create data gomb-bal.

6.13. ábra. A Widget tartalom pontosítása

A mező validátorok használata

A mezőkhöz rendelt alapértelmezett Validátorcsak azt korlátozza, hogy a bevitt adat felel-

jen meg a típusnak, azaz egy szám esetén ne le-hessen betűt bevinni. Amennyiben egy mezőreennél kifinomultabb ellenőrzést szeretnénk, azt

66


a 6.14. ábra paneljét használva tehetjük meg.Létezik sok előre elkészített validátor, amelyek-ből egyszerre többet is rendelhetünk a mezőhöz(Add gomb). A példában éppen az e-mail vali-dátort látjuk. A szerző kedvence a Regex valida-

tor, mert ezzel nagyon finomhangolt ellenőrzé-sek is megfogalmazhatóak. A Create... gombbalsaját validátor is készíthető, amit egy Java nyel-vet támogató szerkesztő ablakban implementál-hatunk.

6.14. ábra. A Validátorok beállítása

6.15. ábra. A mezők kinézetének szerkesztése

67


A layout oszlopok és sorok méretezése

Egy űrlap mező mérete az Appearance → Gridfül segítségével pixel vagy % értékben egzaktmódon megadható. Itt a cellák, címkék és to-vábbi mezőbeállítások is elvégezhetők, amennyi-ben erre szükségünk van.

A mezők kinézetének testre szabása

A 6.15. ábrát tanulmányozzuk, mert mindenmagyarázatnál jobban érzékelteti a formázási le-hetőségeinket! A CSS szintjéig lemenve mindenHTML elemet konfigurálhatunk.

A többlapos formok

Néha szükséges, hogy egy humán feladathoz egyképernyősorozatot adjunk mert. Ennek több okais lehet. Elképzelhető, hogy egy „Next, Next, Fi-nish” varázslót akarunk készíteni a taskhoz, deaz is lehet, hogy a nagyon sok mezőt így érde-mes szétosztani több lapra. Természetesen ilyen-kor a feladathoz több formot kell létrehozni, bekell állítani azok sorrendjét. A Next és PreviousWidget-ek is ilyenkor használhatóak, mert velüklehet navigálni az űrlapok között.

Egy pool kezelő űrlap létrehozása

Medence szintjén az Entry és View típusú formmellett még egy Overview is készíthető, amit

szintén a User Experience-ben tudunk majdhasználni. Az űrlapok létrehozása teljesen meg-egyezik a feladatoknál már megismert lehetősé-gekkel. Az ilyen típusú űrlap egy process pél-dány (vagy más szóval: case) elindítására szol-gál, emiatt ezt First Form-nak is hívjuk. A Skiprádiógomb lehetővé teszi ennek a formnak a ki-hagyását is.

Az űrlapgenerálás testreszabása

Ismét egy fontos témához érkeztünk, hiszen min-den cég, szervezet vagy intézmény saját kinézetűweblapokat akar, így nem lenne olyan nagy elő-relépés a Bonita Form Builder, ha mindig csakugyanolyan kinézetű html lapokat tudna gene-rálni. Erre a fejlesztők is gondoltak, így többszinten is lehetővé tették, hogy olyan template-eket készítsünk, amiket az Apply a Look ’n’ Feelfülön beállítva használ a form generátor.

A Process szintű Template

A beépített Process Template-eket az Applica-tions → Look’n’Feel → Apply a Look ’n’ Feel he-lyen érhetjük el. Itt megtekinthetjük a template-eket, amelyekre példákat mutatnak az 1-4 Prog-ramlisták. Másfelől egy saját template – amitelőzetesen elkészítettünk – importálását is itt te-hetjük meg. Az utolsó fontos funkció ezen a he-lyen, hogy kiválaszthatjuk azt a template-et, amialapján a formjaink generálódni fognak.

1 // 1 . Progaml ista : bonita_process_defau l t . html23 <!DOCTYPEHTML PUBLIC "−//W3C//DTD␣XHTML␣ 1 .0 ␣ S t r i c t //EN" "http ://www.w3 . org /TR/xhtml1/DTD/xhtml1å

−s t r i c t . dtd">4 <html dir=" l t r " xml : lang="en" xmlns="http ://www.w3 . org /1999/ xhtml" lang="en">5 <head>6 <meta http−equiv="Content−Type" content=" text /html ; ␣ cha r s e t=UTF−8"/>7 <meta name=" de s c r i p t i o n " content="Bonita ␣Forms␣Appl i ca t ion "/>8 <t i t l e>Bonita Form</ t i t l e>9 <l ink href=" c s s /bonita_form_default . c s s " rel=" s t y l e s h e e t " type=" text / c s s "/>

10 </head>11 <body class="bonita−body">12 <div id="bonita_user_xp_link" class="bonita_user_xp_link"></div>13 <div id="bonita−p r i n c i pa l−conta iner−top"></div>14 <div id="bonita−p r i n c i pa l−conta iner−middle ">15 <div id="bonita−bonita−open−s o lu t i on−l ogo "></div>

68


16 <div id="bonita−r i ght−corner−area ">17 <div id="bonita−i d e n t i f i c a t i o n −area ">18 <div id="bonita_username" class="bonita_username"></div>å

| <div id="bonita_logout_button" class="åbonita_logout_button"></div>

19 </div>20 <div id="bonita_process_labe l " class="bonita_process_labe l "></å

div>21 </div>22 <div id="bonita_form">2324 </div>25 </div>26 <div id="bonita−p r i n c i pa l−conta iner−bottom" class="bonita−f o o t e r ">Created with å

Bonita Open So lu t i on</div>27 </body>28 </html>

1 // 2 . Progaml ista : default_page_template . html23 <!DOCTYPEHTML PUBLIC "−//W3C//DTD␣XHTML␣ 1 .0 ␣ S t r i c t //EN" "http ://www.w3 . org /TR/xhtml1/DTD/xhtml1å

−s t r i c t . dtd">4 <html dir=" l t r " xml : lang="en" xmlns="http ://www.w3 . org /1999/ xhtml" lang="en">5 <head>6 <meta http−equiv="Content−Type" content=" text /html ; ␣ cha r s e t=UTF−8"/>7 <meta name=" de s c r i p t i o n " content="Bonita ␣Forms␣Appl i ca t ion "/>8 <l ink href=" c s s /bonita_form_default . c s s " rel=" s t y l e s h e e t " type=" text / c s s "/>9 </head>

10 <body>11 <div id="bonita_form_page_label " class="bonita_form_page_label "></div>12 <div class="bonita_form_container ">1314 </div>15 </body>16 </html>

1 // 3 . Progaml ista : default_view_page_template . html23 <!DOCTYPEHTML PUBLIC "−//W3C//DTD␣XHTML␣ 1 .0 ␣ S t r i c t //EN" "http ://www.w3 . org /TR/xhtml1/DTD/xhtml1å

−s t r i c t . dtd">4 <html dir=" l t r " xml : lang="en" xmlns="http ://www.w3 . org /1999/ xhtml" lang="en">5 <head>6 <meta http−equiv="Content−Type" content=" text /html ; ␣ cha r s e t=UTF−8"/>7 <meta name=" de s c r i p t i o n " content="Bonita ␣Forms␣Appl i ca t ion "/>8 <l ink href=" c s s /bonita_form_default . c s s " rel=" s t y l e s h e e t " type=" text / c s s "/>9 </head>

10 <body>11 <div id="bonita_form_page_label " class="bonita_form_page_label "></div>12 <div class="bonita_form_container ">1314 </div>15 </body>16 </html>

1 // 4 . Progaml ista : bon i ta_defau l t_error . html23 <!DOCTYPEHTML PUBLIC "−//W3C//DTD␣XHTML␣ 1 .0 ␣ S t r i c t //EN" "http ://www.w3 . org /TR/xhtml1/DTD/xhtml1å

−s t r i c t . dtd">4 <html dir=" l t r " xml : lang="en" xmlns="http ://www.w3 . org /1999/ xhtml" lang="en">5 <head>6 <meta http−equiv="Content−Type" content=" text /html ; ␣ cha r s e t=UTF−8"/>7 <meta name=" de s c r i p t i o n " content="Bonita ␣Forms␣Appl i ca t ion "/>8 <l ink href=" c s s /bonita_form_default . c s s " rel=" s t y l e s h e e t " type=" text / c s s "/>

69


9 </head>10 <body>11 <div class="bonita_form_container ">12 <div id="bonita_form_error_message" class="bonita_form_error_message"></å

div>13 <div id="bonita_form_cause_message" class="bonita_form_cause_message"></å

div>14 </div>15 </body>16 </html>

6.16. ábra. A Web template ZIP szerkezete

Egy teljes template kiválasztása esetén aztegy ZIP file-ba tudjuk exportálni (6.16. ábra),amit át is lehet utána nevezni, szerkeszteni,majd vissza importálni és saját mintacsomag-ként használni. A template készítésénél a követ-kező html element azonosítók vannak:

• bonita_logout_box: A logout doboza (op-cionális)

• bonita_user_xp_link: Link a Bonita UserExperience Web alkalmazásra (opcionális)

• bonita_process_label: A folyamat neve(opcionális)

• bonita_form_container: Process és Viewkonténer (Kötelező)

• bonita_form: Az Entry és View űrlapokkonténere (Kötelező)

• bonita_refresh_button (opcionális)

A Task szintű Template

A Task szintű template módosításához a TaskDetail Panel-re kell menni, majd az Entry vagyView pageflow General fül Default generatedtemplate gomb kiválasztásával lementhetjük atask szintű mintánkat (a file neve: generated-Template.html lesz), amit igény szerint átszab-hatunk. A template elemei (placeholders) a kö-vetkezőek:

• $bonita_step_state: az aktuális step(task) állapota

• $bonita_step_assignee: az actor, akihez astep rendelve lett

• $bonita_step_candidates: a stepre jelöltactor

• $bonita_step_lastUpdate: a step utolsóváltoztatásának időpontja

• $bonita_step_label: a Bonita Studiobanilyen nevet adtunk a stepnek

• $bonita_step_description: a Bonita Stu-dioban ilyen leírást adtunk a stepnek

• $bonita_step_createdDate: ekkor jöttlétre a step

70


• $bonita_step_readyDate: ekkor vált elér-hetővé a step végrehajtásra

• $bonita_step_startedDate: ekkor volt astep formja kitöltve

• $bonita_step_endedDate: ekkor men-tünk a következő stepre, befejezve ezt

• $bonita_step_executedBy: ez az actor ke-zelte a taskot

• $bonita_step_expectedEndDate: az el-várt teljesítés dátuma

• $bonita_step_priority: a step prioritása

• $bonita_step_remainingTime: a stepmég hátralévő ideje

Error, Welcome és Login űrlapok

A Look ‘n Feel fül Error Template (4. Progam-lista) szolgál a hibaüzenetek testre szabására:

• bonita_form_error_message: a hibaüze-net (Kötelező)

• bonita_form_cause_message a hiba oka(Kötelező)

A pool Detail Panel Application → Resourcesállítható be a Welcome és Login Page template(6.17. ábra).

6.17. ábra. Wecome és Login Page template-ek testre szabása

6.18. ábra. Confirmation message

Confirmation

A 6.18. ábra mutatja a Confirmation templateand messages beállítását, ami lehet Pool vagy

Task szintű is. Ez mindig valamely művelet meg-erősítését, visszanyugtázását teszi lehetővé.

71

Business Process Management Bonita - Az egységes feladatkosár

7. Bonita - Az egységes feladatkosár (User Experience)

A Bonita User Experience az egységes munkakörnyezet és task kosár korszerű megvalósítása. Több-nyelvű használatot támogat, a magyar nyelv is elérhető. A végfelhasználó jól szervezett esetbencsak ezt a környezetet használja, ugyanis itt láthatja a különféle taszkjait, aminek kezelő és megje-lenítő felületei automatikusan beépülnek ebbe a keretkörnyezetbe. A UserXP-vel most ismerkedőkazt vehetik észre, hogy kinézete és használata hasonlít a népszerű webmail felületekhez.

7.1. ábra. User Experience (röviden: UserXP)

Ebben a cikkben áttekintjük a UserXP (7.1.ábra), mint egységes workflow munkakörnyezetlehetőségeit, amit 3 külön szerepkörben lehethasználni:

• Process Developer (a fejlesztő nézete)

• Folyamat Adminisztrátor és a

• Felhasználó nézete

Fejlesztés közben a UserXP a Bonita Studiobólis elindítható, a localhost-on nyit egy böngészőablakot és oda tölti be a web alkalmazást. ABonita futtató környezet workflow és GUI alkal-mazásokat képes futtatni, miközben az adatokat

adatbázisban tartja. A UserXP is egy alkalma-zás, így az ott elvégzett összes művelet szintén aBonita perzisztens tárba kerül, azaz ez mindenkiszámára egy jól használható csoportmunka meg-oldás is egyben. A továbbiakban mindháromszerepkörre specifikusan tekintjük át a UserXPhasználatát.

A folyamat fejlesztő nézete

A fejlesztő természetesen képes a felhasználó(User) és adminisztrátor (Administrator) szerep-körben elérhető funkciókat egyaránt tesztelni,így azokat a tudnivalókat ott írjuk le. A fej-

72


lesztés közben használt Bonita szerver UserXPpéldányát a Studio-ból lehet elindítani, aminekbeállítási lehetőségeit a 7.2. ábra mutatja.

7.2. ábra. Bonita Studio Preferences

Látható, hogy a beépített, fejlesztési célrahasznált Jetty (http://jetty.codehaus.org/jetty/) szerver a localhost 9090-es portjára vanmost állítva. Célszerű egy külső böngésző hasz-nálata. A fejlesztő futtató környezetében előrefelvett user-ek vannak, ilyen az admin is, a mos-tani beállítás azt mutatja, hogy ezen user-kéntautomatikusan be is fogunk lépni a UserXP Rungomb hatására, de természetesen utána átjelent-kezhetünk más user-re is. A következő 2 check-box megértése fontos. A Drop Data base on star-tup bepipálása esetén a a Bonita Studio kiürítiaz adatbázist a következő UserXP indításkor,azaz nem fogjuk látni az előző teszteket. Emi-att ezt a pipát vegyük ki, amikor nem akarjukelveszíteni az elmúlt napok tesztadatait. A Ret-rieve users and roles while dropping data basekapcsoló mindenképpen megtartja a felhaszná-lók profil adatait, azaz adatbázis drop eseténsem veszik el.

A felhasználó nézete

A UserXP-t leginkább a munkafolyamatokbanközreműködő felhasználók használják. Itt mártermészetesen nem a fejlesztés van a középpont-ban, ugyanakkor ezt az eszközt nagyon hatéko-nyan lehet használni, amit ezért a fejlesztőnek isérdemes alaposan megismernie.

A munkafeladatok menedzselése

A Bonita használja az angol case, azaz ügy ter-minológiát, amit fontos, hogy precízen megért-sünk. A case vagy magyarul ügy egy elindítottmunkafolyamat példány, azonban azt is érdemesbelegondolni, hogy éppen most milyen felada-tom (azaz task-om) van ezzel kapcsolatosan. AUserXP (7.3. ábra) bal oldalán elhelyezkedővezérlőpanel a következő menüpontokat tartal-mazza:

• Inbox : Minden task, vagy másképpen ér-telmezve ügy (azaz case, munkafolyamat)itt van felsorolva, amit a felhasználónakkell elvégeznie, azaz dolga van vele (olyan,mint a mail inbox). Egy sor tehát a processvalamely példányát jelenti, amiben dolgo-zunk, illetve ahol konkrét elvégzendő fel-adatunk van.

• Starred : Minden egyes ügyet csillaggal lát-hatunk el, hasonlóan, ahogy ezt a gmail-ben is tesszük.

• My cases : Azok az ügyek (folyamatok),amiket az aktuálisan bejelentkezett fel-használó indított el.

• At risk : A rizikós ügyeink, például határ-idő túllépés fenyegethet.

• Overdue: A határidőn túl lévő ügyeink,amiket már el kellett volna végezni.

73


7.3. ábra. User Experience - A felhasználó nézete

7.4. ábra. Az ügyek és feladatok áttekintése

Az ügyek (case, task) áttekintése, kezelése

Amennyiben az inbox egyik sorára kattintunk,úgy a 7.4. ábrán mutatott felület jelenik meg.

Itt minden fontos információt megtudhatunk er-ről az ügyről. Láthatjuk, hogy mely feladatokatkell még végrehajtani a folyamatban, illetve az

74


eddig elvégzett task-ok történetét is szemügyrevehetjük. Hasznos lehetőség, hogy megjegyzése-ket fűzhetünk az ügyekhez a Comment feed rész-nél. Kattintsunk egy várakozó taskra, amire a7.5. ábra képernyője jön be. Az Assign to me

link segítségégével magunkhoz vehetjük a felada-tot (claim). Arra is mód van, hogy a Suspendlinkkel felfüggesszük azt, majd később Resume-mel folytassuk.

7.5. ábra. A kiválasztott várakozó feladat kezelése

7.6. ábra. Feladat hozzárendelés és prioritás

A 7.6. ábra a feladatokat kezelő ablak elsőharmadában, jobb oldalon lévő eszközsort mu-tatja. A kis piros ablaknyitást jelző ikon a task

Bonitában megtervezett és implementált kezelőGUI űrlapját hívja meg. Az Assign to me lehe-tővé teszi, hogy magunkhoz vagy valaki máshoz(forward) rendeljük a feladatot. A Priority-velaz ügy fontosságát emelhetjük vagy csökkenthet-jük. Amikor egy task több user-hez van ren-delve, akkor az mindenki Inbox-ában Pending-nek látszódik, azonban ha bárki arra jogosultmegcsinálja azt, akkor mindenki számára Comp-letted állapotra vált.

75


Az ügyek címkézése és egyéb jelölései

A case-ek (ügyek) lehetnek megcsillagozottak(Starred vagy Unstarred) és címkézettek (Labe-led). A csillag csak egy egyszerű megjelölése azesetnek. A kategória címkéket a process definiá-lása során vagy a UserXP-ben is létrehozhatjuk.Ezek 1-2 szavas rövid szövegek, ahol még szín-kódokat is megadhatunk a More → New Labellinknél (7.7. ábra).

7.7. ábra. A Címke létrehozása (Label)

Az Inbox-ban minden egyes sorhoz, azazcase-hez a következő információkat látjuk (7.3.ábra):

• Star (Csillag ): megjelöli az esetet.

• Label (Címke): az esetek kategórizálásáraszolgál, így az összes feladatunkat struktu-rálni tudjuk, ha akarjuk akkor csak a fel-cimkézetteket látjuk. A case-ekhez a cím-két a Labels → Apply link segítségével he-lyezhetjük el.

• *Name of Process followed by - #N (N):A process neve és a konkrét eset ügyirat-száma

• Egy színezett bullet pont : zöld → a step,amit el kell végeznünk, narancssárga → afelfüggesztett taszkok, szürke → a komp-lett, elvégzett feladatok

• Egy ember ikon: Feladata van a bejelent-kezett felhasználónak ezzel a sorral

• Priority (prioritás): Lásd a 7.6. ábrát!

• A step neve és keletkezésének dátuma

• A task kezelése egy külön ablakban ikon(7.6. ábra bal oldali kis piros ikonja)

A Dashboard

A munkafeladatok alakulásáról egy jó áttekin-tést ad a dashboard, aminek az egyik nézetétmutatja a 7.8. ábra. Érdemes rendszeresen né-zegetni, mert a munkafolyamatok optimalizálá-sához is jó ötleteket tud adni.

7.8. ábra. A case-ek dashboardja

A felhasználói profil karbantartása

7.9. ábra. A felhasználói profil beállítása

76


Egy új munkafolyamat indítása

A UserXP saját ügyek (egy-egy új munkafolya-mat) elindítását is támogatja a Start a case linksegítségével. Ezzel ez az egységes munkakörnye-zet tényleg egy komplett kollaborációs felülettélép elő.

7.10. ábra. Az Administrator nézete

A folyamat adminisztrátor nézete

Az adminisztrátor feladata, hogy a Bonita UserExperience egységes munkakörnyezet működésétfenntartsa, monitorozza, illetve gond esetén se-gítse a felhasználók mindennapi munkáját. Ami-kor ebben a szerepkörben használjuk a UserXPfelületet, akkor a 7.10. ábra funkcionalítása iselérhetővé válik.

A folyamatok adminisztrálása

A List of all processes funkcióval az összes folya-mat példányt nézegethetjük, külön élő és archi-vált workflow instance bontásban, amit a 7.11.ábra mutat. Vegyük észre, hogy itt van egy Ins-tall gomb is, ami lehetővé tesz a Bonita Studio-ban megtervezett és *.bar telepíthető file-kéntkiexportált processeket itt azonnal telepítsük is.A helyi file rendszerből tudjuk kiválasztani a kér-déses telepítendő bar file-t. Az Install gombtóljobbra van a More actions menü, aminek a kö-vetkező funkciói vannak:

• Open design: A kiválasztott processek tér-képét mutatja meg

• Delete all cases : Letörli az adott processügyeit

• Disable: Letiltja az adott process-t, denem törli

• Enable: Engedélyezi az adott process-t

• Archive: Archiválja a process-eket

• Remove: Törli a process-t az összes ügyé-vel együtt

Amennyiben egy process külső, egyedileg fej-lesztett alkalmazással rendelkezik (példa: .NET,GWT alapú), úgy annak az URL-jét is itt leheta process-hez rendelni. A List of all Processesform application értékei lehetnek: autogenera-ted form, local form application. Azt is testrelehet szabni, hogy a process hogyan nézzen ki azInbox bejegyzésben.

7.11. ábra. Folyamatok böngészése adminisztrátori nézetben

77


7.12. ábra. A taskok menedzselése

A taszkok adminisztrálása

A List of all cases link mutatja az egyes proce-sek case-eit. A 7.12. ábra Cancel gombja törli akijelölt ügyet és archiválja is azt. A Delete csaktörli. A step-ek színkódja a következő:

• Zöld: a step végrehajtásra vár

• Narancssárga: a step fel lett függesztve

• Kék: A step végrehajtás alatt van

• Szürke: A step végrehajtása befejeződött.

A More actions → Open design linken a processdiagram is megnézhető.

A kategóriák menedzselése

A kategóriákról a Bonita Studio ismertetésénélis esett szó, azonban ilyeneket az adminisztrátoris létrehozhat a UserXP Categories ablakában.Ezek olyan címkék, amiket szintén az Inbox-banlehet használni.

A felhasználók kezelése

A Bonita User Experience lehetővé teszi, hogyfelhasználókat (Users), Szerepköröket (Roles),Csoportokat (Groups), Helyetteseket (Delegees),Vezetőket (Managers) és csapattagokat (TeamMembers) definiáljunk és őket Actor Selectorok-hoz rendeljünk.

7.13. ábra. Felhasználók kezelése

A 7.13. ábra szerinti egyes beállítási lehető-ségek a következők:

• General : Az ábrán látható mezőket állít-hatjuk be. Vegyük észre, hogy mindenki-nek beállíthatjuk a vezetőjét (Manager) éshelyettesét (Delegee)

• Member of : Beállítható a user Role-ja ésGroup-ja (7.14. ábra)

• Professional és Personal contact infor-mációk : Néhány előre definiált adatleírómező, de az adminisztrátor új mezőket isvehet fel.

• User metadata: További leíró mezőket ve-hetünk fel ezzel a funkcióval.

78


7.14. ábra. A felhasználó szerepének és csoportjának beállítása

A Roles és Group fülön új szerepköröket éscsoportokat hozhatunk létre, régieket törölhe-tünk.

Riportok készítése

Az adminisztrátor különféle elemzéseket készít-het a rendszerről, amit mindenkinek javaslunktanulmányozni (7.15 és 7.16. ábrák).

7.15. ábra. Egy adminisztrátori riport

7.16. ábra. Report opció kiválasztása

79

Business Process Management Bonita - Konnektorok készítése

8. Bonita - Konnektorok készítése

A konnektorok biztosítják, hogy a Bonita munkafolyamatok integrálódhassanak a környezetükhöz.Ez egyaránt vonatkozik az input (amikor a munkafolyamat igényel valamilyen adatot) és output (amunkafolyamat küld egy másik rendszer számára információt) jellegű kommunikációra. Tekintettelarra, hogy sokféle információs rendszer létezik, rengeteg Bonita konnektor érhető el.

Miért szükségesek a konnektorok?

A konnektorok biztosítják, hogy a munkafolya-mat bizonyos pontjairól a külvilág rendszereivelkommunikálhassunk. A működés sémáját a 8.1.ábra mutatja. Amikor egy konnektort haszná-lunk, mindig össze kell rendelni a várt input pa-ramétereket a workflow által átadott konkrét ér-tékekkel, majd a konnektor lefut. A futási ered-ményt az output paraméterek tartalmazzák, ígyezeket is össze kell rendelni a process megfelelőbelső változóival, amelyek az eredmény értékeketát tudják venni. A konnektorok hiánya eseténa workflow alkalmazásunkat nem tudnánk másrendszerekkel integrálni, ami lehetetlenné tenné,hogy alkalmazásokat átívelő, más szolgáltatáso-kat is igénybe vevő (például SOA alapú) megol-dásokat építsünk fel.

8.1. ábra. A Konnektor séma

A konnektor osztály felépítése

A 8-1. Programlista egy TestConnector nevűkonnektor Java osztályának vázát mutatja, amit

a Bonita Studio Connector → New Connec-tor menüpontjából kiválasztható Connector va-rázsló segítségével generáltunk le. A célunk mostaz, hogy megértsük a konnektorok belső prog-ramszerkezetét, így nézzük meg ezt a kódot ala-posabban. A varázslóban azt mondtuk, hogy le-gyen 2 INPUT-ja a konnektornak, amit input1és input2 névre kereszteltünk és mindkettőre aString típust állítottuk be. Ezeket látjuk a 13.és 15. sorokban, illetve input lévén a 29-43 so-rok a setter metódusokat tartalmazzák. Ebbőlazt tanulhatjuk meg, hogy egy konnektor input-ját private belső változók reprezentálják, amiketbeállító metódusok érnek el és a Bonita GUI ezthasználja annak a felderítésére, hogy később mi-lyen bemenő adatokra számítson. A konnektorOUTPUT adataira az output1 (típus: String) ésoutput2 (típus: Long) neveket adtuk meg, azon-ban láthatóan a varázsló nem generál erre pri-vát változókat, viszont a 45-61 sorok közötti kódazt mutatja, hogy a getter metódusok biztosítvavannak, amögé természetesen akár változók isfelvehetőek. A konnektor class nevének a Test-Connector nevet adtuk, ami egy utódja lett aBonita ProcessConnector ősosztályának. A kon-nektorok emiatt az executeConnector() (17-21sorok) és validateValues() (23-27 sorok) metó-dusokat kell, hogy megvalósítsák. Amikor aztmondjuk, hogy használunk egy konnektort, ak-kor az azt jelenti, hogy annak egy konkrét osz-tálypéldányának az executeConnector() metódu-sát hívjuk meg, miközben az INPUT és OUT-PUT átvételét a már ismertetett setter és gettermetódusokkal valósítjuk meg. Egyszerű, szép éstiszta mechanizmus!

80


1 // 8−1. Programl i s ta : Egy t e s z t konnektor váz23 package org . c s . bonita . connector s ;45 import java . u t i l . L i s t ;67 import org . ow2 . bonita . connector . core . ConnectorError ;8 import org . ow2 . bonita . connector . core . ProcessConnector ;9

10 public class TestConnector extends ProcessConnector {1112 // DO NOT REMOVE NOR RENAME THIS FIELD13 private java . lang . S t r ing input2 ;14 // DO NOT REMOVE NOR RENAME THIS FIELD15 private java . lang . S t r ing input1 ;1617 @Override18 protected void executeConnector ( ) throws Exception {19 // TODO Auto−genera ted method s tub2021 }2223 @Override24 protected List<ConnectorError> va l ida t eVa lue s ( ) {25 // TODO Auto−genera ted method s tub26 return null ;27 }2829 /∗∗30 ∗ Se t t e r f o r input argument ’ input2 ’31 ∗ DO NOT REMOVE NOR RENAME THIS SETTER, un l e s s you a l s o change theå

r e l a t e d entry in the XML de s c r i p t o r f i l e32 ∗/33 public void se t Input2 ( java . lang . S t r ing input2 ) {34 this . input2 = input2 ;35 }3637 /∗∗38 ∗ Se t t e r f o r input argument ’ input1 ’39 ∗ DO NOT REMOVE NOR RENAME THIS SETTER, un l e s s you a l s o change theå

r e l a t e d entry in the XML de s c r i p t o r f i l e40 ∗/41 public void se t Input1 ( java . lang . S t r ing input1 ) {42 this . input1 = input1 ;43 }

81


4445 /∗∗46 ∗ Getter f o r output argument ’ output1 ’47 ∗ DO NOT REMOVE NOR RENAME THIS GETTER, un l e s s you a l s o change theå

r e l a t e d entry in the XML de s c r i p t o r f i l e48 ∗/49 public St r ing getOutput1 ( ) {50 // TODO Add re turn va lue f o r the output here51 return null ;52 }5354 /∗∗55 ∗ Getter f o r output argument ’ output2 ’56 ∗ DO NOT REMOVE NOR RENAME THIS GETTER, un l e s s you a l s o change theå

r e l a t e d entry in the XML de s c r i p t o r f i l e57 ∗/58 public Long getOutput2 ( ) {59 // TODO Add re turn va lue f o r the output here60 return null ;61 }6263 }

A Bonita beépített konnektorai

A Bonita számos beépített, előre elkészített kon-nektort tartalmaz, sőt a community kiegészítőkletöltési helyéről továbbiak is elérhetők és felte-lepíthetők a Bonita Studioba. A 4.3. ábrán márláttuk a legfontosabb konnektor kategóriákat,amelyeken belül konkrét konnektorok érhetőkel. A legfontosabb konnektorok használatánakrészletes leírását a Bonita Connectors Guide do-kumentum tartalmazza, azt érdemes megnézni,amikor egy-egy konkrét konnektor család vala-melyik konnektorát szeretnénk használni. Ittmost példaképpen megnézzük a Microsoft Sha-repoint és a SAP konnektorok használatát.

Sharepoint (SPS) konnektor

A Sharepoint konnektor kategória elérhető kon-nektorait a 8.2. ábra mutatja.

8.2. ábra. Sharepoint konnektorok

Itt a varázsló által kért input paraméterekjellemzően azok, amik a kérés kiszolgálásáhozszükségesek és a böngészőbe is beírtuk volna:

82


user és password, a kért erőforrás (file) URL-je.A példában (8.3. ábra) a Get items from a ListSPS konnektor input adatainak bekérését és azazt fogadó válasz (8.4. ábra) beállítását látjuk.Természetesen mindegyik SPS típusú konnektoregyedi inputokat is bekérhet, például a Create aFolder szolgáltatás a Parent URI -t (ide hozzuklétre a mappát) és a mappa nevét is igényli.

8.3. ábra. Sharepont lista konnektor - Input

8.4. ábra. Sharepont lista konnektor - Output

SAP konnektor

Az SAP az egyik legelterjedtebb ERP rendszer,így a vele való kommunikáció sokszor merül feligényként (8.5. ábra). Alapvetően 2 kommuni-kációs forma támogatott:

• az üzenet alapú SAP IDoc technológia

• a szinkron SAP RFC (Remote FunctionCall) függvények paraméterein keresztültörténő adatcsere

8.5. ábra. SAP konnektorok

Az SAP szerver felé való konnekciós beállítá-sokat a 8.6. ábra ablaka mutatja.

8.6. ábra. SAP connection konfiguráció

83


A megadható konnektor connection inputokértelmezése a következő:

• Server type: Ez lehet egy Application vagyMessage server

• Client : Az SAP kliens száma a bejelentke-zéskor

• User ID, Password és Language

• Host Name: SAP gépnév vagy IP cím

• System Number : SAP System Number

A fenti konfigurációkat névvel látjuk el és ígytudunk különféle SAP rendszerekre hivatkozni.Példaképpen nézzük meg, hogy egy RFC függ-vényt hívó konnektor példányt hogyan tudunkbeállítani! Ehhez válasszuk ki a Call a functionkonnektort. A meghívandó függvény neve: vbn(8.7. ábra).

8.7. ábra. Call a function

Az input függvény paraméterek megadásáta 8.8. ábra mutatja. Egy SAP függvény ex-port, import és tábla típusú paramétert tudátvenni, ezeket természetesen most a workflowbelső adatváltozóira kell leképezni konnektor hí-vás előtt.

8.8. ábra. Az input paraméterek megadása

A 8.9. ábra a függvény hívási eredmény fo-gadásának beállítását mutatja.

8.9. ábra. Az SAP függvényhívás outputja

Egy példa konnektor elkészítése

A Bonita konnektorok készségszintű használa-tát fontosnak gondoljuk, ezért befejezésül ebben

84


a pontban bemutatunk egy RSS Feed konnek-tort és azt is, hogy azt mi módon lehet egy tesztworkflow-ból meghívni.

A konnektor rövid specifikációja

Készítünk egy olyan konnektort, ami egy RSSFeed URL-ről visszaadja az RSS csatorna XMLválaszt. A feed-ek lehívására és kezelésére aROME nevű java könyvtárat (rome-1.0.jar) fog-juk használni, ami a népszerű jdom könyvtár se-gítségével kezeli az XML-t, így a jdom.jar file-tis hozzá kell adnunk a Bonita Studio dependen-cies listához, ez a külső Java osztályokra való hi-vatkozások feloldására szolgál. Ezt a 2 jar file-ta Bonita Studio Task Bar Extensions → Add/-Remove résznél tehetjük be a függőségek közé.Ezeket a jar-okat a mindenkori process DetailPaneljének Dependencies fülén is aktiválni kell(8.10. ábra). Az új konnektor class neve RSSRe-ader lesz. Egyetlen input paraméterrel fog ren-delkezni, ami egy URL tárolására képes Stringváltozó. Ugyancsak kell egy output paraméteris, ugyanis itt tároljuk majd az RSS Feed válaszbejegyzéseit.

8.10. ábra. A jar-ok aktíválása

Az RSS Feed konnektor elkészítése

Kezdjük el a konnektor implementálását! Vá-lasszuk ki a Connector → New Connector me-nüpontot, amire elindul a konnektor varázsló in-duló képernyője (8.11. ábra).

8.11. ábra. Konnektor varázsló

Nézzük meg a varázsló egyes megadandó me-zőinek a jelentését:

• Connector ID : A konnektor neve, ahogyazt a Bonita megismeri. Javasolt, hogy akonnektor class név legyen, azaz esetünk-ben RSSReader

• Description: A konnektor céljának rövidleírása

• Category : A konnektor kategóriája, mosta Syndication nevet adtuk. Ahogy láttuk aSAP és SPS konnektoroknál (ezek a kate-góriák), egy kategóriába tetszőlegesen sokkonnektor tartozhat. Ez a fogalom csak azeszközkészlet jó áttekinthetőségét szolgálja

• Icon: A konnektor vizuális jele (javasoltméret: 60x60 pixel)

• Class name: A konnektor class neve, ese-tünkben RSSReader

• Package: A konnektor class ebben aJava csomagban van, esetünkben ezorg.bonitasoft.connectors.rssreader

85


• Pages : A konnektor inputjának definiálása(lásd lentebb!)

• Outputs : A konnektor outputjának defini-álása (lásd lentebb!)

A Pages résznél több input adat is megadható,ha megnyomjuk a Create gombot. Ekkor a 8.12ábra ablaka jön be. Itt egyszere 2 dolog tör-ténik, ugyanis nem csak az input adatokat ha-tározzuk meg, hanem egyben kialakítjuk a bár-mely process-en belüli használathoz szükségesvarázsló GUI felületét is. Nézzük:

• Page ID : A varázsló ezen lapjának a neve,esetünkben: EnterURL

• Page Title: A lap címe: Retrieve an RSSor Atom feed

• Description: A Page Title alatt megjelenőrövid szöve: Enter the destination URL

• Widgets : Itt adhatjuk meg a varázsló ezenlapjához tartozó INPUT mezőket és azo-kat a widget-eket, amik a varázsló formjánmegjelennek ehhez a mezőhöz. Az itt meg-adott változók lesznek a generált konnek-tor Java class input adatai.

8.12. ábra. Az input mezők definiálása

Az egyes input változókat a Create gombramegjelenő ablak (8.13. ábra) segítségével adhat-juk meg:

• Field name: a most definiált input mezőneve (lehet ebből akármennyi). Esetünk-ben ez az url névre hallgat, hiszen egyURL inputot szeretnénk a konnektornakátadni.

• Mandatory : Ez deklarálja, hogy ez az in-put adat kötelező-e vagy sem. Esetünkbenkötelező.

• Widget : Az url változót a varászló ilyenvezérlővel fogja beolvasni, ez most egy TextWidget lesz.

• Data Type: Az input mező típusa, ez mostString (azaz Text) lesz.

8.13. ábra. Egy INPUT mező megadása

A 8.11. ábra Outputs részénél még a konnek-torunk OUTPUT adatait kell megadnunk, aholegy olyan ablak nyílik meg mely lehetővé teszi azoutput adatok meghatározását. Itt csak a mezőknevét (esetünkben ez itemList lesz) és típusait

86


kell megadnunk. Ezzel kész vagyunk, nyomjukmeg a Finish gombot, amire az RSSReader classcsontváza elkészül, azt egy megjelenő kódablak-ban editálhatjuk, aminek a végeredményét, azaz

a konnektor teljes kódját a 8-2 Programlista mu-tatja. Ezzel az RSS Feed konnektor fejlesztésévelis végeztünk, most nézzük meg annak a haszná-latát!

1 // 8−2 Programl i s ta : Az RSS Feed konnektor kódja23 package org . b on i t a s o f t . connector s . r s s r e ad e r ;45 import java . u t i l . ArrayList ;6 import java . u t i l . L i s t ;7 import java . net .URL;8 import910 import1112 import1314 import com . sun . synd i ca t i on . f e ed . synd . SyndEntryImpl ;1516 com . sun . synd i ca t i on . f e ed . synd . SyndFeed ;17 com . sun . synd i ca t i on . i o . SyndFeedInput ;18 com . sun . synd i ca t i on . i o . XmlReader ;19 import org . ow2 . bonita . connector . core . ConnectorError ;20 import org . ow2 . bonita . connector . core . ProcessConnector ;2122 public class RSSReader extends ProcessConnector23 {24 // DO NOT REMOVE NOR RENAME THIS FIELD25 private St r ing u r l ;26 private List<SyndEntryImpl> i t emsL i s t ;2728 @SuppressWarnings ( "unchecked" )29 @Override30 protected void executeConnector ( ) throws Exception31 {32 URL feedUr l = new URL( this . u r l ) ;33 SyndFeedInput input = new SyndFeedInput ( ) ;34 SyndFeed f eed = input . bu i ld (new XmlReader ( f e edUr l ) ) ;35 this . i t emsL i s t = feed . g e tEnt r i e s ( ) ;36 }3738 @Override39 protected List<ConnectorError> va l ida t eVa lue s ( )40 {41 List<ConnectorError> e r r o r s L i s t = new ArrayList<ConnectorError >() ;42 i f ( "" . equa l s ( u r l . tr im ( ) ) )43 {44 ConnectorError e r r o r = new ConnectorError ( " u r l " , new å

I l l ega lArgumentExcept ion ( "Url ␣ i s ␣empty" ) ) ;45 e r r o r s L i s t . add ( e r r o r ) ;

87


46 }47 return e r r o r s L i s t ;48 }4950 /∗∗51 ∗ Se t t e r f o r input argument ’ u r l ’52 ∗ DO NOT REMOVE NOR RENAME THIS SETTER, un l e s s you a l s o change the53 r e l a t e d entry in the XML de s c r i p t o r f i l e54 ∗/55 public void s e tUr l ( S t r ing u r l )56 {57 this . u r l = u r l ;58 }5960 /∗∗61 ∗ Getter f o r output argument ’ i t emsL i s t ’62 ∗ DO NOT RENAME NOR RENAME THIS GETTER, un l e s s you a l s o change the63 r e l a t e d entry in the XML de s c r i p t o r f i l e64 ∗/65 public List<SyndEntryImpl> ge t I t emsL i s t ( )66 {67 return this . i t emsL i s t ;68 }69 }

Egy tesztelő workflow elkészítése

8.14. ábra. Az RSSReader kipróbálása

Az RSSReader konnektor kipróbálásához készít-sünk egy egyszerű, 2 lépéses workflow-t (8.14.ábra)! Az alábbi elnevezéseket tettük:

• A Process Diagram neve: TutorialExample–RSS Feed

• A Pool neve: RSS Feed

• A 2 step neve: RSS Feed és Read results(mindkét esetben az Actor most az Initia-tor lesz)

8.15. ábra. Egy új RSSReader konnektor

88


A tanult módon a Pool, azaz a munkafolya-mat szintjére a konnektorral való kommunikációcéljára a következő adatokat definiáltuk:

• url (típus: Text): Ez tárolja az igényeltRSS Feed URL-t

• rssResult (típus: Java Object): Ide érkezikvissza a feed XML

Álljunk rá az RSS Feed taskra és a Detail Panel-en válasszuk ki a hozzátartozó Connectors fület,majd nyomjuk meg az Add gombot, amivel eh-hez a step-hez egy új konnektor instance készít-hető, mégpedig olyan adatokkal, amiket a 8.16.ábra mutat. Látható, hogy a konnektor hívá-sának az eseményét a finish event (a task elha-gyása) adja. A 8.16. ábra az ezután következőlépést mutatja, ahol meg kell adnunk, hogy akonnektor egyetlen url paramétere honnan fogjönni. Vegyük észre, hogy a Retrieve an RSS orAtom feed és Enter the destination URL szöve-gek a konnektor létrehozásakor lettek kitalálvaa Pages rész definiálásánál.

8.16. ábra. Az RSSReader url input innen jön

A Next gomb hatására a 8.17. ábra ablakajelenik meg, ahol a fed eredményét fogadó belsőworkflow változó jelölhető ki. Esetünkben a kon-nektor itemList paramétere az rssResult processváltozóba fogja helyezni az eredményt. Kattint-sunk a Finish gombra és ezzel elkészültünk azRSSReader konnektor példányunk használatá-nak beállításával.

8.17. ábra. Az RSSReader output mapping

A workflow kipróbálásához most készítünkegyszerű űrlapot a tanult módon mindkét tasklépéshez. Az Pool induló form-ra nincs szükség,ezért az Skip-eljük ki. Az url változó bekéréseaz első step-ben lesz, ennek form generáló kép-ernyőjét a 8.18. ábra mutatja. Célja az URLbekérése.

8.18. ábra. Az RSS feed step űrlapja

A Read result nevű 2. step űrlapjának gene-rálásakor az URL természetesen már nem kell,így vegyük ki az összes pipát a generálás előtt,azaz input mező nem marad a formon, helyettea Palette-ról tegyünk ki a generált űrlap vizu-ális tervére egy List Widget-et (Label nem kellhozzá, azt kapcsoljuk ki). Ekkor ennek a me-zőnek a hivatkozási neve ${field_List1} lesz. A

89


Groovy editorral fogjuk ezt az új Widget-et amegjelenítendő tartalommal feltölteni, amiben a8-3 Programlista scriptje segít. A konnektor ál-tal feltöltött rssResult értékei kerülnek kiírásra.A res listába megfelelő formátumú adat lesz,amit a List vezérlő megjelenít, hiszen ez lesz azadatforrása.// 8−3 Programl i s ta : Groovy s c r i p t

r e s = new ArrayList<Str ing >() ;r s sRe su l t . each{

r e s . add ( i t . g e tT i t l e ( ) + "␣ : ␣" + i t . getLink ( ) )}r e s

A workflow tesztelését a Run gombbal kezd-jük el! Az első form bekéri az URL-t, a következőpedig meg fogja jeleníteni a lekért feed tartalmát(8.19 és 8.20. ábrák).

8.19. ábra. Az RSSReader teszt workflow kipróbálása - input

8.20. ábra. Az RSSReader teszt workflow kipróbálása - az eredmény

90

Business Process Management A Bonita telepítése

9. A Bonita produktív környezet telepítése

A fejlesztés produktumát egy olyan környezetbe szeretnénk telepíteni, ami független a fejlesztőgépétől. A minőségbiztosítás általában 2-3 futtató szervert is megkövetel: teszt, minőségbiztosítási(QA) és produktív (éles) környezetek. Ebben a részben összefoglaljuk azokat a lépéseket, amik egyBonita futtató környezet kialakításához szükségesek.

9.1. ábra. JBoss és Bonita User Experience

Induló lépések

A Bonita futtató környezet telepítését mini-mum Java 6 környezetben javasoljuk meg-valósítani, ennek a leírását itt nem rész-letezzük. A http://www.bonitasoft.com/products/BPM_downloads helyről letölthető azIncludes BOS 5.5.1 and a JBoss 5.1.0 server,ami egy JBOSS alkalmazás szerver és a BonitaWorkflow Engine előre integrált, telepíthető cso-

magja. Tartalmazza a User Experience alkal-mazást is. A telepítés rendkívül egyszerű, vala-milyen erre a célra szánt könyvtárba (a továb-biakban ez a JBOSS_HOME ) kicsomagoljuk aletöltött zip file-t és ezzel egy fejlesztés céljárakiválóan alkalmas környezethez jutottunk. Pró-báljuk ki! Lepjünk be a JBOSS_HOME/binkönyvtárba és a run.sh scripttel indítsuk el (ha–b 0.0.0.0 opciót adjuk meg, akkor minden háló-zati interface-re hallgatózik) a JBOSS szervert.

91


Miután a szerver elindult (a konzolon látjuk astartup lépéseket) indítsunk el egy böngészőt,majd próbáljuk ki UserXP alkalmazást ezenaz URL-en: http://localhost:8080/bonita.Amennyiben bejön a 9.1. ábra login képernyője,úgy eddig mindent jól csináltunk. Próbáljunkbelépni admin user névvel, aminek a jelszava:bpm. A 9.2. ábra az admin user felhasználóinézetét mutatja. A UserXP sok nyelvet támo-gat, ahogy látható a magyar is közéjük tartozik.

Az egységes workflow munkakörnyezetünk mégmeglehetősen üres, hiszen csak most telepítet-tük fel. Jelenleg a beépített H2 adatbáziskezelővan a Bonita motor alatt, azonban ezt produktívkörnyezetben semmiképpen nem lehet ajánlani,ezért a következőkben bemutatjuk, hogy azt mi-lyen lépésekkel lehet lecserélni Oracle, MySQLvagy egyéb ismert és enterprise szintű RDBMS-sel.

9.2. ábra. UserXP - admin felhasználóval belépve

Az adatbáziskezelő beállítása

Két Bonita adatbázis létrehozása

A továbbiakban a MySQL segítségével ismer-tetjük azt a lépéssorozatot, ahogy a BonitaRDBMS-t be lehet állítani az eredeti H2 he-lyett. Amennyiben a JBOSS fut, úgy azt állít-suk le! A Bonita számára a következő 2 adat-bázis séma szükséges: bonita_journal és bo-

nita_history. Indítsuk el a mysql klienst (a szer-ver már megy):mysql −u root −pEnter password :

Hozzunk létre ebben a konzolban a 2 új adat-bázist:mysql> c r ea t e database bonita_journa l ;Query OK, 1 row a f f e c t e d (0 . 00 sec )

mysql> c r ea t e database boni ta_his tory ;Query OK, 1 row a f f e c t e d (0 . 00 sec )

92


Hozzuk létre az bonita user-t az adatbázisban(jelszó: bpm):CREATE USER ’ bonita ’@’ l o c a l ho s t ’ IDENTIFIED BYå

’bpm ’ ;

Adjunk az új bonita user-nek kapcsolódásijogot:mysql> grant usage on ∗ .∗ to bon i ta@loca lhos t å

i d e n t i f i e d by ’bpm ’ ;Query OK, 0 rows a f f e c t e d (0 . 00 sec )

Mindkét adatbázishoz adjunk teljes elérésijogot:mysql> grant a l l p r i v i l e g e s on bonita_journa lå

.∗ to bon i ta@loca lhos t ;Query OK, 0 rows a f f e c t e d (0 . 00 sec )

mysql> grant a l l p r i v i l e g e s on boni ta_his toryå.∗ to bon i ta@loca lhos t ;

Query OK, 0 rows a f f e c t e d (0 . 00 sec )

Ezután már bonita néven is beléphetünk azadatbázisba:

$ mysql −u bonita −p ’bpm’ bonita_journal

A Bonita konfigurációs file-ok beállítása

Van 2 properties file aJBOSS_HOME/bonita/server/default/conf

mappában:

• bonita_journal.properties és

• bonita_history.properties

A feladatunk most az lesz, hogy a H2 adatbá-zisokra vonatkozó bejegyzéseket MySQL-re cse-réljük ebben a 2 properties file-ban. Nézzük megmilyen cserékre lesz szükségünk a 2 db konfigu-rációs állományban:

# boni ta_journa l . p r op e r t i e s

# H2 Hibernate d i a l e c t# Ez v o l t :# h ibe rna te . d i a l e c t org . h i b e rna t e . d i a l e c t . H2Dialect# Ez l e s z :h ibernate . d i a l e c t org . h ibe rnate . d i a l e c t . MySQL5InnoDBDialect# Oracle ese tben ez lenne :#h ibe rna t e . d i a l e c t org . h i be rna t e . d i a l e c t . Orac le10gDia lec t

# Using an in t e r c e p t o r can change the database behaviour .# Ez v o l t :# boni ta . h i b e rna te . i n t e r c e p t o r org . ow2 . bon i ta . env . i n t e r c e p t o r . H2DescNul lF i r s t In tercep tor# Ez l e s z :bonita . h ibe rnate . i n t e r c e p t o r org . ow2 . bonita . env . i n t e r c e p t o r . MySQLDescNullFirstInterceptor

# boni ta_his tory . p r op e r t i e s

# H2 Hibernate d i a l e c t# Ez v o l t :# h ibe rna te . d i a l e c t org . h i b e rna t e . d i a l e c t . H2Dialect# Ez l e s z :h ibernate . d i a l e c t org . h ibe rnate . d i a l e c t . MySQL5InnoDBDialect# Oracle ese tben ez lenne :#h ibe rna t e . d i a l e c t org . h i be rna t e . d i a l e c t . Orac le10gDia lec t

# Using an in t e r c e p t o r can change the database behaviour .# Ez v o l t :# boni ta . h i b e rna te . i n t e r c e p t o r org . ow2 . bon i ta . env . i n t e r c e p t o r . H2DescNul lF i r s t In tercep tor# Ez l e s z :bonita . h ibe rnate . i n t e r c e p t o r org . ow2 . bonita . env . i n t e r c e p t o r . MySQLDescNullFirstInterceptor

93


Látható, hogy mindkét adatbázisra ugyan-azokat a cseréket kell elvégezni H2 → MySQLperzisztencia tár csere esetén. Mindkét konfigu-rációs file tartalmazza az Oracle, PostgreSQL ésMS SQL Server konfigurációt is, természetesenezek a bejegyzések ki vannak kommentelve.

Adatbázis DataSource létrehozása

A telepített JBOSS+Bonita csomag

JBOSS_HOME/docs / examples / j c a /mysql−ds . xml

példafájl egy példányát másoljuk aJBOSS_HOME/ s e rv e r / d e f au l t / deploy

helyre, amiről a JBOSS hot deploy módonképes az XML-ben definiált adatforrást telepí-teni a szerverre. Ezzel együtt a h2-ds.xml erő-forrás file-t távolítsuk el ebből a könyvtárból. Amysql-ds.xml file tartalmát a következőre szer-kesszük át:

<?xml version=" 1 .0 " encoding="UTF−8"?><datasource s>

<no−tx−datasource><jndi−name>bonita / d e f au l t / j ou rna l</ jndi−name><connect ion−u r l>jdbc :mysq l : // l o c a l h o s t : 3 3 0 6 / bonita_journa l</ connect ion−u r l><dr ive r−c l a s s>com . mysql . jdbc . Dr iver</ dr ive r−c l a s s><user−name>bonita</user−name><password>bpm</password>

<except ion−s o r t e r−c l a s s−name>org . j bo s s . r e s ou r c e . adapter . jdbc . vendor . MySQLExceptionSorter</åexcept ion−s o r t e r−c l a s s−name><metadata>

<type−mapping>mySQL</type−mapping></metadata>

</no−tx−datasource>

<no−tx−datasource><jndi−name>bonita / d e f au l t / h i s t o r y</ jndi−name><connect ion−u r l>jdbc :mysq l : // l o c a l h o s t : 3 3 0 6 / boni ta_his tory</ connect ion−u r l><dr ive r−c l a s s>com . mysql . jdbc . Dr iver</ dr ive r−c l a s s><user−name>bonita</user−name><password>bpm</password><except ion−s o r t e r−c l a s s−name>org . j bo s s . r e s ou r c e . adapter . jdbc . vendor . MySQLExceptionSorter</å

except ion−s o r t e r−c l a s s−name><metadata>

<type−mapping>mySQL</type−mapping></metadata>

</no−tx−datasource>

</ datasource s>

Amennyiben nincs meg a MySQL JDBCdriver, úgy az letölthető innen: http://dev.mysql.com/downloads/connector/j/. A jar driver file-t másoljuk aJBOSS_HOME/server/default/lib könyvtárba,az eredeti h2-1.2.139.jar file-t pedig töröljükonnan! Indítsuk el újra a JBOSS-t. Az új adat-bázisba automatikusan létrejön a 2 séma, majda szerver üzemkész állapota után nézzük meg,hogy a UserXP-t használni tudjuk-e? Amennyi-

ben igen, úgy az új adatbázisra való átállás si-keresen megtörtént.

Megjegyzések

Elképzelhető, hogy valaki nem a JBOSS+Bonitaintegrált csomagot szeretné használni. Ebben azesetben a JBOSS-t telepítse fel, majd a követ-kező lépéseket kell elvégeznie:

1. Töltsük le külön a Bonita Execution

94


Engine-t, majd az abban lévő .../bo-nita_client/libs és .../engine/libs map-pákban lévő összes jar file-t másoljuk aJBOSS_HOME/server/default/lib könyv-tárba.

2. Telepítsük fel a bonita.war webalkalmazást (amelyik nem tartal-mazza az execution engine-t), amia User Experience. A war file-t aJBOSS_HOME/server/default/deploymappába kell másolni.

3. Hasonlóan telepítsük az xcmis.war alkal-mazást, amiről később írunk (ez 2011.szeptemberétől része a Bonitának).

Környezeti változók beállítása

A környezeti változók a JBOSS+Bonitaintegrált csomagban helyesen be van-nak állítva (a konfigurációs file neve:JBOSS_HOME/bin/run.conf ), érdemes át-nézni, de nem kell rajta változtatni. .

A hitelesítés beállítása

A Bonita a szabványos JAAS alrendszert hasz-nálja, amiről részletesen az Informatikai Navigá-tor 3. számában írtunk. A Bonita 2 bejelentke-zési kontextust használ (LoginContext):

• BonitaAuth: A webes felülethez (UserXP)szükséges bejelentkezési kontextus

• BonitaStore: A Bonita Engine ebben a se-curity kontextusban szolgálja ki az ügyfe-leit (az előző kontextus ilyenkor az identi-tást továbbítani tudja ide)

A JBOSS_HOME/bonita/server/default/confmappában van 2 fontos konfigurációs XML file:

• login-config.xml

• bonita-server.xml

A login-config.xml tartalma a következő:<app l i c a t i on−po l i c y name="BonitaAuth"><authen t i c a t i on><log in−module code="org . ow2 . bonita . i d e n t i t y .å

auth . BonitaIdent ityLoginModule " f l a g="år equ i r ed "/>

</ authen t i c a t i on></ app l i c a t i on−po l i c y>

A BonitaIdentityLoginModule egy szabvá-nyos JAAS module class, aminek a login() metó-dusa úgy van implementálva, hogy a Credenti-als vizsgálata az authentication service-ben meg-adott AuthenticationService interface-szel ren-delkező objektumhoz van delegálva, amely konk-rét osztály beállítását a bonita-server.xml filetartalmazza:<!−− Desc r i p t i on : Implementation o f the å

au then t i c a t i on s e r v i c e . −−><authent i ca t i on−s e r v i c e name=’ authent i ca t i on−å

s e r v i c e ’ c l a s s=’ org . ow2 . bonita . s e r v i c e s .åimpl . DbAuthentication ’>

</ authent i ca t i on−s e r v i c e>

Alaphelyzetben DbAuthentication (imple-ments AuthenticationService) class van beál-lítva, de ezt le is cserélgetjük, ha nem a Bonitaadatbázissal szemben akarjuk ezt elvégezni, ha-nem például egy Active Directory-t szeretnénkhasználni. Ilyenkor az implementálandó inter-face egyszerű:pub l i c i n t e r f a c e Authent i ca t i onSe rv i c e {/∗∗∗ Check whether a user has admin p r i v i l e g e s orå

not∗ @param username the user ’ s username∗ @return true i f the user has admin å

p r i v i l e g e s , f a l s e o therw i se∗ @throws UserNotFoundException∗/boolean isUserAdmin ( St r ing username ) throws å

UserNotFoundException ;/∗∗∗ Check some user ’ s c r e d e n t i a l s∗ @param username the user ’ s username∗ @param password the user ’ s password∗ @return true i f the c r e d e n t i a l s are va l id , å

f a l s e o the rw i s e∗/boolean checkUserCredent ia l s ( S t r ing username , å

St r ing password ) ;}

Természetesen magát a BonitaIdentityLogin-Module class-t is lecserélhetjük.

95


Naplózás

A JBOSS naplózást aJBOSS_HOME/conf/logging.properties he-

lyen tudjuk beállítani, nézzük meg aJBOSS+Bonita csomag beállításait!

A CMIS eXo platform integrálása

Ez egy új elem a Bonita platformon, nem köte-lező a használata, de nagyon hasznos. A CMISjelentése: Content Management Interoperabi-lity Services, amiről itt olvashatunk többet:http://en.wikipedia.org/wiki/Content_Management_Interoperability_Services. AzxCMIS ennek egy Java platformon való meg-valósítása, a project webhelye: http://cmis.exoplatform.org/. Érdemes itt is körbenézni:http://exoplatform.org/company/public/website. Az xCIMS egy külön adatbázis sé-mát igényel, amit így hozhatunk létre:mysql> c r ea t e database xcmis ;Query OK, 1 row a f f e c t e d (0 . 00 sec )

mysql> grant a l l p r i v i l e g e s on xcmis .∗ to åbon i ta@loca lhos t ;

Query OK, 0 rows a f f e c t e d (0 . 00 sec )

A multitenancy támogatás

A multitenancy egy IT rendszer architectúra,ami úgy van kialakítva, hogy a különféle erőfor-rások (számítógépek, tárolók, hálózat, ...) egyszámírási felhőben (cloud computing) érhetőekel a telepített alkalmazás számára. Erről részle-tesen itt olvashatunk: http://en.wikipedia.org/wiki/Multitenancy. A Bonita támogatjaezt a megközelítést, ha nagyon különleges igé-nyekkel bíró környezetben szeretnénk használni.

A REST API telepítése

Ez szintén egy opcionális elem, beállítása nemkötelező. A Bonita pure Java vagy EJB felüle-ten képes a workflow motor szolgáltatásait elér-hetővé tenni. A REST webservice felületet egygyakrabban használjuk, mert egyszerűbb, mint aSOAP és ugyanolyan platformfüggetlen. Igényesetén a motor szolgáltatásai így is elérhetőek.Ehhez telepíteni kell a bonita-server-rest.war al-kalmazást (a szokásos módon másoljuk a warfile-t a JBOSS_HOME/server/default/deploymappába). Ezután a külső hitelesítéshez egyJAAS modul telepítése szükséges:

<?xml version=" 1 .0 "?><app l i c a t i on−po l i c y name="BonitaRESTServer">

<authen t i c a t i on><log in−module code="org . ow2 . bonita . i d e n t i t y . auth .å

BonitaRESTServerLoginModule" f l a g=" requ i r ed "><module−opt ion name=" l o g i n s ">r e s t u s e r</module−opt ion><module−opt ion name="passwords ">restbpm</module−opt ion><module−opt ion name=" r o l e s ">r e s t u s e r</module−opt ion>

</ log in−module></ authen t i c a t i on>

</ app l i c a t i on−po l i c y>

Szükség esetén a REST API használatánaktovábbi beállításait, illetve annak használatát aBonita webhelyén elolvashatjuk. Ez a UserXP il-

lesztéséből, HTTP kliens konfigurálásból és ma-gának az API-nak a használatából áll.

96

Business Process Management A folyamatszervezési módszertan áttekintése

10. A folyamatszervezési módszertan rövid áttekintése

Mielőtt egy munkafolyamat számítógépes automatizálásába kezdünk elemezési és tervezési felada-taink vannak, amik olyan üzleti igényekből keletkeznek, amit az 1. cikkben részletesen ismer-tettünk. Érdemes ismerni azokat a szervezési elveket és módszereket, amik a folyamatok építésetémában kialakultak és helyesnek bizonyultak. A számítógépes megoldást csak akkor érdemesmegtervezni, ha a folyamat célját és lezajlását ismerjük, illetve azt minden résztvevő elfogadja ésmagára nézve kötelezőnek tartja.

Ebben a cikkben természetesen nem vállal-kozhatunk egy teljes módszertani leírásra, azon-ban a tudnivalókat szeretnénk röviden összefog-lalni, illetve sok hivatkozást fogunk tenni más,részletesebb leírásokra. Mondanivalónkat a FO-LYAMATLEÍRÁST SEGÍTŐ MÓDSZERTANIAJÁNLÁS8 (továbbiakban: FSMA) című kiad-vány gondolatmenetére fűzzük fel, onnan sokgondolatot és ábrát kölcsönöztünk.

Az alapvető fogalmak és tudnivalók

A mindennapi életben folyamatnak nevezzük abizonyos cél elérését célzó tevékenységek soroza-tát. A folyamat általában erőforrásokat használ,melyek segítségével bemenő elemeket (inputot)kimenő elemekké (outputtá) alakít. A folyamatcélja általában valamilyen termék, résztermékvagy szolgáltatás létrehozása. Az IEEE –STD-610 szabvány (http://standards.ieee.org/)alapján folyamatnak nevezzük bizonyos céllal el-végzett lépések/tevékenységek sorozatát.

A szoftverfejlesztésben a megoldandó felada-tok mérete, komplexitása, a feladatok megol-dásában résztvevő csapatok mérete folyamato-san növekszik. Általában kicsi az esély arra,hogy egy feladatot egyetlen személy átlásson,a maga teljességében kezelni tudjon. Emiattfontossá vált a megoldás folyamatának megér-tése, pontos meghatározása, dokumentálása, in-tézményesítése. A szoftverfejlesztők körében

ezért már régóta elkezdődött a feladatok meg-oldásának modellezése és lehetőleg szabványokalkalmazása. Ismereteink alapján hosszútávona szolgáltatás-orientált architektúrák (SOA) ésfejlesztési módszerek elterjedésével kell számol-nunk.

10.1. ábra. A folyamatok korszerűsítése (FSMA)

Ne gondoljuk, hogy a folyamataink számátáltalában ismerjük és azokat fel tudjuk sorolni!Általában nem csak az a probléma, hogy egy-egy folyamatot nem ismerünk eléggé, hanemsokszor az is, hogy még maguknak a folyama-tok létezésének ismerete sem válik közösségi tu-dássá, azt esetleg csak néhány bennfentes is-meri. A szoftverfejlesztés és karbantartás folya-matai számára az ISO 12207 szabvány egységes

8Az Elektronikus közigazgatási keretrendszer kiadványa

97


fogalmi keretet hoz létre és konkrét folyamato-kat definiál (http://en.wikipedia.org/wiki/ISO_12207). A 10.1. ábra egy alapmodell, amiazt mutatja, hogy az IT milyen úton képes ki-építeni és módszeresen támogatni az üzleti folya-matokat. Ebben az írásban minket most az elsődoboz érdekel a legjobban, ezért azt a 10.2. áb-rán tovább részleteztük és a továbbiakban ezenábra egyes blokkjait tárgyaljuk meg.

10.2. ábra. Folyamatleírások készítése (FSMA)

A folyamatleírás tervezése

A 10.3. ábra a feltárási munka leírásának meg-tervezését mutatja. A felmérési célok meghatá-rozása során törekedjünk jól definiált, konkrét ésa lehetőségekhez mérten 1-2 kiemelt cél azono-sítására, melyek igény szerint priorizálhatóak ésalábonthatóak legyenek. Pontosan tisztázni kell,hogy mely területek folyamatainak vizsgálata afeladatunk. A résztvevők azonosítása és bevo-násának előkészítése alapvetően fontos, enélkülsemmi esélye a sikeres felmérésnek. Ezeket amunkákat projectben érdemes elvégezni, így aterv része kell legyen az idő és erőforrás tervezés

is.

10.3. ábra. A folyamatleírás tervezése (FSMA)

A helyzetfelmérés módszerei

10.4. ábra. Információ gyűjtés (FSMA)

A helyzetfelmérés igen információ igényes te-vékenység, aminek a célszerű lefolyását mu-

98


tatja a 10.4. ábra. Érdemes először a vo-natkozó jogszabályokat és belső szabályzatokatösszeszedni és áttanulmányozni, majd a továbbitárgybeli dokumentumokat beszerezni és azoktartalmát kielégítően megérteni. Ennyi előze-tes felkészülés után talán már bátran szervez-hetünk interjúkat is, ahol az apróbb részletekreis fényt lehet deríteni. Az interjúk típusairól ésaz arra való felkészülésről itt olvashatunk töb-bet: http://media.ektf.hu/levelezo/orai_anyagok/interju.pdf. A lényeg megértésébennéha sokat segít egy esettanulmány, ami az in-terjúk és dokumentumvizsgálat kombinációjábóljöhet létre. Az információgyűjtésről szóló mód-szertani ábránk lényeges része az elkészített fel-mérés dokumentum szakértőkkel való vélemé-nyeztetése. Ettől nem csak jobb lesz az anyag,de annak konszenzusosan elfogadott igazságtar-talma is jelentősen nőni fog. Ugyanakkor szak-értői véleményeket már a munka elején is fontosfelhasználni és beépíteni a leszállítandó doku-mentumba. Van néhány kiérlelt módszer, ahogyezeket a véleményeket hatékonyan össze tudjukszedni:

• Brainstorming (http://en.wikipedia.org/wiki/Brainstorming)

• Brainwriting (http://litemind.com/brainwriting/)

• Phillips 66 (http://en.wikipedia.org/wiki/Phillips_66)

Vannak még más csoportmunka módszerek is,nézzük át ezt a cikket: http://mmfk.nyf.hu/min/alap/52.htm.

A folyamatok megtervezése

A jelenlegi folyamatok megismerése után követ-kezik azok újratervezése és leírása.

Szöveges leírás

Itt a legősibb és elengedhetetlen eszköz a folya-matok szöveges leírása, amire az FSMA a követ-kező űrlap sablont javasolja, aminek a mezői ésazok tartalmának a magyarázata a következő:

• Folyamat hivatalos neve: Folyamat hiva-talos neve, amennyiben a név nem fedi lea folyamat célját a cél cellában részleteseb-ben ki kell fejteni.

• Cél : Opcionálisan tölthető cella, ha a névnem utal megfelelő mértékben a folyamatcéljára.

• Azonosító: A folyamatnak egy rövid ésegyértelmű megnevezése, amit a leírá-sokban referenciaként könnyen használha-tunk. Érdemes valamilyen kódrendszertbevezetni.

• Rövid név : A folyamat azonosítására al-kalmas, a gyakorlatban alkalmazott nemszükségképp hivatalos elnevezés

• Informatikai támogatás mértéke: A folya-mat végrehajtása lehet tisztán emberi te-vékenység, de tartalmazhat gépi informa-tikai támogatást is (szélső esetben az egészfolyamat támogatott). A támogatottságmértékét csak az éppen vizsgált folyamatraszámítjuk, az általa indított gyermek fo-lyamatokra nem.

• Tulajdonos : A folyamatot kidolgozó szer-vezet vagy személy A folyamat meglété-ért, végrehajtásáért felelős szervezet, intéz-mény megnevezése.

• Üzemeltető: Aki a tevékenységet végzi ésannak elvégzéséhez szükséges a feltételek-kel rendelkezik. Beírhatók még az üzemel-tető elérhetőségére vonatkozó adatok.

99


• Szakértő: A folyamat minden mozzanatátismerő szervezet, személy, akinek a folya-mattal kapcsolatos állásfoglalása mérték-adó.

• Verzió: Az aktuális verziószám.

• Létrehozás : Ezen leírás létrehozásának dá-tuma és időpontja.

• Módosítás : Ezen leírás módosításainak dá-tuma és időpontja.

• Folyamat leírása: A folyamat szövegesmegfogalmazása, terjedelme: 5-10 sor. Afolyamat alanyának jogi hatással bíró, jog-szabályokon, jogi normákon alapuló aka-ratnyilvánítása megvalósításához szüksé-ges tevékenység. A folyamatot egy a folya-maton kívülről származó indító eseménykezdeményezi. A folyamat lehet összetett,amikor a megvalósításhoz további folya-mat(ok) végrehajtásának kezdeményezéseszükséges.

• Indító esemény : A folyamat szempontjá-ból külső esemény, amely a folyamat egypéldányának létrejöttét és a folyamat meg-indulását eredményezi, ha az előfeltételekés kezdeti állapot ezt lehetővé teszik. Azesemény pillanatszerű, oszthatatlan tör-ténés. Eseménynek tekintendő valamelymegjelölt időpillanat elérkezése is. Az ese-ménynek lehetnek paraméterei. Példa: azesemény időpontja, az eseményt okozó sze-mély.

• Bemenetek : Az indítás pillanatában a fo-lyamatot indító által az induló folyamat-nak átadott dolgok (példák: termékek,ügyiratok, adatok).

• Előfeltétel, kezdeti állapot : Azon – folya-maton kívüli – dolgok (beleértve a folya-mat bemeneteit is) jellemzőire vonatkozó

korlátozások összessége, amelyeknek telje-sülnie kell az indító esemény bekövetkezté-nek pillanatában ahhoz, hogy a folyamatténylegesen meginduljon.

• Szokásos lépések : Ha a folyamattól elvárteredmények, utófeltételek kialakítása ér-dekében végzett tevékenység nem ragad-ható meg egyetlen mozzanatként (lépés-ként), akkor a tevékenységet lépések soka-ságaként definiálhatjuk. Egy lehetséges lé-pés egy újabb folyamat indítása. A folya-mat konkrét példányának végrehajtásakora lehetséges lépéssorozatok egy változatahajtódik végre. Ez a leírás a leggyakoribblépéssorozatot adja meg. (Példa folyamat:pénzfelvétel ATM-ből. Itt a sikeres esettekinthető szokásosnak) A Gyermek folya-matok a Szokásos lépéseknek azon részhal-maza, amelyet külön folyamatleíró laponelemzünk.

• Változatok : A lehetséges lépéssoroza-tok kevéssé gyakori változatainak leírása.(Példa folyamat: pénzfelvétel ATM-ből.Egy változat: a PIN kódot ismételten megkell adni, és a bankszámlán nincs elegendőpénz, ezért a pénzfelvétel meghiúsul)

• Termékek, kimenetek : Mindazon, a folya-mat végrehajtása során keletkezett dolgok(okiratok, adatok stb.) összessége, ame-lyek kimunkálása, létrehozása céljából zaj-lott le a folyamat. A termékek a folyamatindulása előtt nem léteztek, de a folyamatbefejeződését követően tovább léteznek.

• Utófeltétel, végállapot : Azon – folyamatonkívüli – dolgok jellemzőire vonatkozó kor-látozások összessége, amelyeknek teljesül-nie kell a folyamat befejeződésének pilla-natában. Mind a szokásos lefutás, mind aváltozatok esetére meghatározandó.

100


• Napi kérések : A folyamat napi indításai-nak száma átlagosan

• Csúcsterhelés : A folyamat napi indítása-inak maximális száma. A csúcsterhelésesidőszakok előfordulása, hosszúsága.

• Átlagos kiszolgálási idő: A folyamat teljeslefutásának szokásos ideje.

• Minimum kiszolgálási idő: A folyamat tel-jes lefutásának minimális ideje.

• Maximum kiszolgálás idő: A folyamat tel-jes lefutásának maximális ideje.

• Kapcsolatok : A Gyermek folyamatok aSzokásos lépéseknek azon részhalmaza,amelyet külön folyamatleíró lapon elem-zünk.

• Szülő folyamat : Azon folyamat(ok),amely(ek)nek a végrehajtása során a vizs-gált folyamat végrehajtását kezdeménye-zik.

• Gyermek folyamat : Azon folyamat(ok),amely(ek)nek végrehajtását a vizsgált fo-lyamat kezdeményezi.

• Jogszabályok : Azon jogszabályok, jogi nor-mák, előírások, amelyek a folyamattal, an-nak végrehajtásával kapcsolatosak, ame-lyek módosulása a folyamat módosításátokozza.

• Gazdasági vonatkozások : Azon szabá-lyok, előírások összessége, amelyek a fo-lyamat végrehajtásának gazdasági aspek-tusait meghatározzák. Példa: ki és hogyanfedezi a folyamat végrehajtása során felme-rülő költségeket (illetékeket)? Ha a folya-mat gazdasági, pénzügyi tevékenységeket,illetve erre való hivatkozásokat (büntetéskiszabása vagy segély, támogatása folyósí-tása) tartalmaz, akkor az milyen módon éskik között történik?

• Függőségek : Azok a folyamaton kívüli dol-gok, amelyek hatással lehetnek a folya-matra általában, és a leírás korábbi pont-jaiban nem szerepelnek.

• Megjegyzés : Tetszőleges, a folyamat meg-értését segítő szöveg.

A folyamatok modellezése

A szöveges leírás nagyon hasznos és szintemindig szükséges, azonban a műszaki pon-tosságú leíráshoz valamilyen ábrázoló, model-lező eszköz szükséges. Itt első helyen sze-retnénk az UML (és RUP módszertan) esz-közt megemlíteni, mint a modellezés alfáját ésómegáját. Kicsit részletesebben itt olvasha-tunk róla: http://hu.wikipedia.org/wiki/Unified_Modeling_Language . Aki részlete-sen is át akarja tekinteni ezt az eszközt, an-nak itt kell kezdenie a tanulmányozást: http://www.uml.org/. A folyamat modellezés szem-pontjából kiemelendő UML részek a következők:

• UML use case modellezés: http://en.wikipedia.org/wiki/Use_case Egy UseCase kinézetére példa: http://www.w3.org/egov/wiki/Use_Case_Template

• Activity diagram: Ez kifejezetten aworkflow leírásra tervezett eszköz, aBPMN előtt ezt használtuk a leggyak-rabban. Itt olvashatunk róla: http://en.wikipedia.org/wiki/Activity_diagram.

Manapság a folyamatok modellezésének első he-lyen használt eszköze a BPMN, amit a 3. cikk-ben részletesen ismertettünk. A BPMN és azUML modellek közös jellemzője, hogy fejlett in-formatikai programok vannak a támogatásukra,az egyes ábrákat sok megjegyzéssel és szöve-ges jellemzővel láthatjuk el. Még sok helyenhasználják az XPDL eszközt is: http://en.wikipedia.org/wiki/XPDL.

101


A folyamatok validálása

A folyamatok validáládát a 10.5. ábra modelljealapján szokás megtervezni és elvégezni.

10.5. ábra. A folyamatok helyessége (FSMA)

Konzisztencia vizsgálat

Folyamat inkonzisztencia alatt azt az állapototértjük, amikor egy folyamatleírásban vagy folya-matábrán önmagának vagy más folyamatoknakellentmondó információk szerepelnek. A kon-zisztencia fontossága és lényege az üzlet bármelyterületén abban áll, hogy egy üzleti folyamat-ról, az eddigi ismert gyakorlatokat, törvénysze-rűségeket visszatükröző letérképezést (folyamat-leírásokat) kell létrehozni, mely ezen folyama-tok elemeinek (későbbiekben egyre több folya-mat) értékét és helyét meghatározza. Kiküszö-bölve ezzel, hogy az üzletben ugyanazon szolgál-tatásra több egymásnak ellentmondó folyamatis létezhet. Az ellentmondás-mentesség csak ak-kor lehet biztos, ha minden adat és ezek keletke-zési módja pontosan dokumentált, illetve az egy-mással oksági kapcsolatba hozható adatok kap-

csolatrendszerét leíró táblázat adott, mely alap-ján a szakmai hibaelemzés elvégezhető. Inkon-zisztencia feltárására javasoljuk, hogy az azonosvagy hasonló területen felmérést végző csapatokmunkájuk eredményét mutassák be egymásnak.Kapcsolódó folyamatok, illetve folyamatok kap-csolódási pontjainál ajánlott a prezentációt kö-telező elemé tenni a felmérési folyamatban.

Redundancia vizsgálat

Redundancia több kapcsolódó, egymással kap-csolatban álló folyamat között gyakran megfi-gyelhető. A folyamatfelmérés és fejlesztés haté-kony eszköze a felesleges ismétlődések csökken-tésének. Egy folyamatleírás vagy folyamatábraredundáns, ha egy információ (feleslegesen) is-métlődik, többször előfordul benne. Redundan-cia figyelhető meg folyamatok között (külső) ésfolyamatelemek között (belső) is. A belső ismét-lődéseket a folyamatleírás készítés korai szaka-szában azonosíthatjuk, és lehetőségeinkhez mér-ten törekedjünk megszüntetésükre (ez a leírástkészítő személy/személyek feladata). A folya-matok közötti ismétlődések azonosítását és meg-szüntetését a felmérés egészét koordináló, támo-gató és ellenőrző csapat tudja elvégezni, illetvea felmérést végző csapatok együttes, céltudatosegyüttműködésével előzhető meg. Ezért fontos,hogy a csapatok egymás munkáját és eredmé-nyeit láthassák.

Mérések (KPI)

A mérések által olyan kulcsinformációkhoz jut-hatunk, melyek hozzásegítenek a folyamatok,objektumok fejlesztéséhez. A mérés segíti azösszefüggések megértését, ezért irányítani tud-juk az eseményeket. A termékeket/szolgálta-tásokat, elvégzett feladatokat értékelni tudjuk,össze tudjuk hasonlítani egymással, hogy a jö-vőben bekövetkező eseményeket minél pontosab-ban „meg tudjuk jósolni”. Gyakorlati tapasz-

102


talat, hogy a felmérést követően igény van fo-lyamatok, illetve a folyamatok teljesítményénekjavítására. Belátható, hogy mérőszámokra vanszükségünk (mert csak azt tudjuk javítani, amitmérni vagyunk képesek). Ezért fontos a felmé-rési szakaszban mérőszámok azonosítása, hasz-nálata. Egy adott folyamathoz többre is, kezdet-nek három mérési terület is elegendő az alapokmegteremtéséhez:

• gyorsaságra vonatkozó,

• költségre vonatkozó,

• minőségre vonatkozó mérőszámok és méré-sek.

Érdemes itt is átfutni a wiki leírást: http://en.wikipedia.org/wiki/Performance_indicator. Nagyon fontos, hogy a méréseket afolyamat kiegyensúlyozására is felhasználjuk. Azegyensúlyvesztés könnyen okozhat problémákat,például gyorsak vagyunk, de rossz a minőségünkés drágán állítjuk elő ). A mérés direkt vagy in-direkt módon végezhető. Egy attribútum direktmérése olyan mérés, mely nem függ semmilyenmás attribútum mérésétől (pl. hosszúság). Egyattribútum indirekt mérése olyan mérés, melymagába foglalja egy vagy több további attribú-tum mérését (pl. sűrűség = tömeg/térfogat). Azattribútumok megfelelő kiválasztása és ezekneka megfelelő metrikával való társítása komplexfeladat. A munkát nehezíti az a tény, hogy

nincsenek univerzálisan elfogadott modellek azattribútumok és a metrikák kiválasztására. Alétező modellek, szabványok és ajánlások kiindu-lópontként használhatóak, de csak a tapasztalatsegíthet igazán a mérések megfelelő módon valóvégrehajtásában. A jó metrika néhány kritéri-uma a következő:

• Objektivitás : Az eredményeknek szubjek-tív hatásoktól menteseknek kell lenniük.Nem szabad számítania annak, hogy kivégzi a mérést.

• Megbízhatóság : Az eredményeknek precí-zeknek és megismételőeknek kell lenniük.

• Érvényesség : A metrikának a megfelelő(helyes) jellemzőt kell mérnie.

• Szabványosítottság : A metrikának a meg-felelő (helyes) jellemzőt kell mérnie. Ametrikának egyértelműnek és összehason-lításra alkalmasnak kell lennie.

• Összehasonlíthatóság : A metrikánakösszehasonlíthatónak kell lennie más, ha-sonló kritériumú metrikákkal.

• Gazdaságosság : Az egyszerűbb, és ennél-fogva olcsóbb metrikák használata a jobb.

• Használhatóság : Egy metrika oka egyigény kell, hogy legyen, nem mérünk egytulajdonságot „pusztán kedvtelésből”.

10.6. ábra. Mérőszközök

103

Business Process Management A Groovy programozási nyelv rövid áttekintése

11. A Groovy programozási nyelv rövid áttekintése

A Groovy (magyarul: klassz) script nyelvet a Java kiegészítéseként hozták létre, hogy bizonyosfeladatokat sokkal agilisabban és hatékonyabban tudjunk elvégezni. Amikor egy rendszerbe csakkis kód darabkákat kell elhelyeznünk vagy egy prototípus megoldást szeretnénk létrehozni, ez ascript nyelv sokszor célravezetőbb. Erre jó példa a Bonita is, ahol több helyen ilyen scriptekbenlehet megfogalmazni a feladatot. Érdekes momentum, hogy egy Java program egyben egy érvényesGroovy program is. Innen indul a történet. A Groovy webhelye: http://groovy.codehaus.org/.

A Bonita használata során több helyen fel-bukkan a Groovy nyelv, ezért úgy érezzük ennekaz alapjaival is érdemes megismerkedni, amikora Bonitában fejlesztünk. Sokszor van lehetősé-günk egy Groovy kifejezés (expression) megadá-sára, de azt is megtanultuk, hogy a task lépésekegyik fajtája a Script Task, ahol viszont egy na-gyobb script is beírható. Ez a cikk annyit ta-nít meg a Groovy nyelvről, amennyit a betétscriptek írásához bőségesen elégnek ítélünk. Akia nyelv minden részletét ismerni akarja, annakajánljuk a nyelv webhelyét alaposan áttanulmá-nyozni.

A nyelv néhány érdekessége

A Groovy futtatja a Java kódot

A nyelv tervezői egy olyan script nyelvet készí-tettek, ami minden eddiginél jobban integráló-dik a Java nyelvhez és azt a JVM futtatja. AGroovy tekinthető a Java olyan kiterjesztésének,ami a script nyelvek előnyeivel ruházza azt fel.

Ez a törekvés egészen addig elment, hogy egytetszőleges Java program egyben egy érvényesGroovy program is. A kézikönyv csak ennyit ír:Nevezzük át a file java kiterjesztését groovy-ra ésmár megírtuk az első Groovy scriptünket. Eztigazolandó, elővettük az egyik régebbi Java tesztprogramunkat, amit a 11-1. Programlista tartal-maz. A működés egyszerű, az index.hu helyrőlletölti a 24 óra rovat feed-jét, amit XML-benmegjelenít. Ehhez a rome és jdom java könyv-tárakat hívtuk segítségül. A futtatás a 41. sorparancsára történik, a 45. sortól az eredményeleje látszódik. A programot eddig tiszta Javakörnyezetben használtuk, de a Groovy ezentúllehetővé teszi, hogy bármelyik scriptünk részelegyen. Mit csinál a program pontosan? A 24.sorban létrehozzuk a feedUrl objektumot, ami afeed URL-jét reprezentálja. A feed változóba in-nen olvassuk fel a byte-okat, ahova már a Synd-Feed osztálynak megfelelő formátumba kerülnek.A 28-35 sorok között egy egyszerű iterációval ki-írjuk a feed minden bejegyzését a képernyőre.

1 // 11−1. Programl is ta : A Java nyelv , mint Groovy program23 package org . cs . t e s t ;45 import com . sun . synd i ca t i on . f e ed . atom . Entry ;6 import com . sun . synd i ca t i on . f e ed . module . DCModuleImpl ;7 import com . sun . synd i ca t i on . f e ed . module . Module ;8 import com . sun . synd i ca t i on . f e ed . synd . SyndEntry ;9 import com . sun . synd i ca t i on . f e ed . synd . SyndFeed ;

10 import com . sun . synd i ca t i on . i o . SyndFeedInput ;11 import java . i o . InputStreamReader ;12 import java . net . MalformedURLException ;13 import java . net .URL;14 import java . u t i l . I t e r a t o r ;

104


15 import java . u t i l . L i s t ;1617 public class TestRSS18 {1920 public stat ic void main ( St r ing [ ] a rgs ) throws Exception21 {22 System . out . p r i n t l n ( " Sta r t ␣ f e ed . " ) ;2324 URL feedUr l = new URL("http :// index . hu/24 ora / r s s " ) ;25 SyndFeedInput input = new SyndFeedInput ( ) ;26 SyndFeed f eed = input . bu i ld (new InputStreamReader ( f e edUr l . openStream ( ) ) ) ;2728 L i s t l o = feed . g e tEnt r i e s ( ) ;29 for ( I t e r a t o r i t = l o . i t e r a t o r ( ) ; i t . hasNext ( ) ; )30 {31 SyndEntry e = ( SyndEntry ) i t . next ( ) ;32 System . out . p r i n t l n ( e . g e tT i t l e ( ) ) ;33 System . out . p r i n t l n ( e . g e tDe s c r i p t i on ( ) . getValue ( ) ) ;34 System . out . p r i n t l n ( e . getLink ( ) ) ;35 }36 }37 } // end c l a s s3839 Parancs :40 −−−−−−−−41 groovy −cp /home/ java /rome−r s s −1.0/rome−1.0 . j a r : / home/ java /jdom/ bu i ld /jdom . j a r RSSManager . groovy4243 Futás i eredmény ( r é s z l e t )44 −−−−−−−−−−−−−−−−−−−−−−−−−45 Star t f e ed .46 Britney Spears rákhúst adott gyereke inek az a l l e r g i á j u k e l l e n é r e47 A t e s t ő r e á l l í t j a mindezt , s z e r i n t e az énekesnő d i r e k t e t e t t e rákka l a gy e r e k e i t .48 http : //m. v e l v e t . hu/ b logok /gumicukor /2011/09/21/å

br i tney_spears_rakhust_adot t_gyereke inek_az_al l erg ia juk_e l l enere /49 I l y en keblek kompenzálják az Oktober fe s ten a sör káros ha t á s a i t50 A bajor nő i n é pv i s e l e t b ő l kibuggyanó mel lek a korsó sörök me l l e t t e l é g i zga tóak ahhoz , hogy å

külön g a l é r i á t s z en t e l j ünk nekik . A s ö r i v á s úgy i s c sökkent i a t e s z t o s z t e r on−k i v á l a s z t á s t , åúgyhogy k e l l valami , amitő l h e l y r e á l l az egyensú ly .

51 http : //m. v e l v e t . hu/ trend /2011/09/21/mellek_is_vannak_az_oktoberfesten_nem_csak_sor/52 Fegyver re l támadtak a Torony étterem egy ik vendégére53 Az i sme r e t l en k é t s z e r i s e l s ü t ö t t e a p i s z t o l y t , de az csak kattant a Zala megyei Cseszt regen .54 http : //m. index . hu/ bu l var /2011/09/21/ ketszer_is_meghuzta_a_ravaszt /55 Fegyveres konvojra támadt a t un é z i a i hadsereg56 Az összecsapásban a tun é z i a i haderő s z á r a z f ö l d i egységek me l l e t t h e l i k op t e r e k e t i s beve t e t t .57 http : //m. index . hu/ k u l f o l d / h i r e k /2011/09/21/ fegyveres_konvojra_tamadt_a_tuneziai_hadsereg/58 Péte r fy Bori a gye r ekéve l nyafog a Zöld Pardonért59 A mű−super 8−as f e l v é t e l e n a gye r ekéve l h intáz ik , és egyre köz e l ebb rő l és hangosabban nyafogja , å

hogy " s z e r e tnék ␣még␣a␣Zöld␣Pardonban␣ konce r t e zn i " .

A lista és map osztályok natív támogatása

Egy lista létrehozása egyszerű:

s ze repek = [ ’ Vezető ’ , ’ Utas ’ , ’ Busz ’ ]p r i n t l n jarmu

A jarmu változó egy 3 elemű listát fog tar-talmazni, ami a következő sor ki is nyomtat. Ajarmu[1], pedig a lista indexelt elérését mutatja.

Ezenfelül a létrejött jarmu objektum természe-tesen számos metódussal rendelkezik még. Amap objektum használata hasonlóan egyszerű:map = [ k1 : 5 , k2 : " Imre " , k3 : 24 ]p r i n t mapmap . putAt (" ku l c s " , 10 . 2 )p r i n t mapmap . putAt (" k2 " , "Alma")

A map egy kulcs-érték párok sorozata. Alétrehozásnál a k1, k2 és k3 a kulcsok, amik az

105


utána lévő értékek asszociatív elérését teszik le-hetővé. A 3. sorban egy új elemet is hozzá tu-dunk adni, azaz minden úgy működik ahogy aztmegszoktuk. Ennek megfelelően az 5. sor a k2kulcshoz tartozó Imre értéket Almára cseréli. Alisták és a map-ek műveleteit tanulmányozzuk aGroovy dokumentációban!

Kifejezések dinamikus kiértékelése

Sokszor jól jönne, ha egy stringben lévő kifeje-zést dinamikusan ki tudnánk értékelni. A pél-dánkban a kif változóba egy képletet írtunk be,amit az evaluate( kif ) ki is értékel és 91 jelenikmeg.x = 5k i f = "3 ∗ x ∗ x + 2 ∗ x + 6"p r i n t l n eva luate ( k i f )

Van olyan eset, amikor egy karaktersoro-zat makróhelyettesítésre van szükségünk, ami-nek ekkor ez a formátuma:x = 5k i f = "3 ∗ x ∗ x + 2 ∗ x + 6"p r i n t l n "A kép l e t : ${ k i f }"

Eredmény : A kép l e t : 3 ∗ x ∗ x + 2 ∗ x + 6

Esetünkben ekkor a kif értékével kicserélő-dött script jelenik meg.

A Zárványok támogatása

A Closures (bezáródás, zárvány) egy fontos részea Groovy nyelvnek, ugyanis ezzel több érdekesfeladatot egyszerűen meg tudunk oldani. Itt egyteljes Groovy kódrészletet egy változóhoz ren-delhetünk és ezt a kód darabkát bármikor le isfuttathatjuk. Nézzünk egy egyszerű példát! Akod változó egy összeadás kód darabkát végezel, aminek az input paraméterei az a és b. Anyíl a paraméterezés deklarálását választja el akódszegmenstől. A képernyőre 10 fog kiíródni.kod = { a , b −> a + b}p r i n t l n kod . c a l l (3 , 7)

Persze ennél összetettebb kódrészlet is lehet:

kod ={ a , b −>

c = a + b ;i f ( c > 10 ) p r i n t l n "Nagy szám"e l s e p r i n t l n "K i c s i szám"

}kod . c a l l (3 , 6)kod . c a l l (5 , 6)

A Closure segítségével meglévő osztályokhoztudunk új funkciót adni. Nézzük meg például akövetkező kódot:

St r ing . metaClass . e l soBetu = { betu −>i f ( betu == de l ega t e . sub s t r i ng (0 , 1 ) ){

re turn ":−)"}re turn de l e ga t e . sub s t r i ng (0 , 1 )

}

St r ing s t r = "Almafa " ;p r i n t l n s t r . e l soBetu ( "A" ) ;

Itt az ismert String osztályt egy elsoBetu()metódussal bővítjük, hasonló módon, ahogy aJavaScript-nél a prototype-ot használjuk. Aprogram most :-) jelet fog kiírni, mert a A betű-vel kezdődik a string objektumunk. A delegatekulcsszó egy hivatkozást ad vissza arra az ob-jektumra, amelyik a closure kódrészt magábanfoglalja. Még létezik a zárványok világában 2hasonló, automatikusan generált azonosító: this(a closure kódját befoglaló osztályra való hivat-kozás) és az owner (hasonló a delegate-hez, decsak olvasható).

Több soros String konstans megadása

A hosszabb stringek (például egy HTML kód)létrehozása nehézkes, ha a nyelv nem támo-gatja a többsoros karakterfüzérek létrehozását.A Groovy-ban ezt így kell megadni:

St r ing sorok = ’ ’ ’AAAAAABBBBBBBBBBBBBBCCCCCCCCC’ ’ ’

A használt nyelvi elem a 3 db ’ vagy „ jel.

106


Az XML építése

A nyelv rendelkezik néhány érdekes lehetőség-gel, amivel az XML adattartalmat lehet kezelni.Ilyen például a MarkupBuilder osztály, amivel akövetkező módon lehet XML-t építeni:

de f bu i l d e r = new groovy . xml . MarkupBuilder ( )bu i l d e r . book {

s z e r z o ’ Karl May’cim ’Winnetou ’j e l l emzok {

o l d a l ’420 ’bo r i t o ’ kemeny ’

}}

p r i n t l n bu i l d e r

Az eredmény :−−−−−−−−−−−−<book>

<szerzo>Karl May</szerzo><cim>Winnetou</cim><je l l emzok>

<olda l >420</o lda l><bor i to>kemeny</bor i to>

</je l l emzok></book>

OS parancs kiadása

Példaként szolgáljon az ls parancs használata!Látható, hogy a parancs outputja a text mezőbekerül, ezt írjuk ki a println paranccsal.

p r i n t l n " l s − l " . execute ( ) . t ex t

A Groovy nyelv

A fentiek néhány érdekes Groovy nyelvi elemetmutattak be, most röviden, de módszereseb-ben áttekintjük a nyelvet. A Groovy a teljesJava könyvtárat képes használni, maga a nyelvis olyan kódra fordul, amit a JVM futtat. Alang, util, net, io, BigInteger és BigDecimal,valamint a Groovy saját groovy.lang.* és gro-ovy.util.* csomagjai automatikusan importálód-nak.

A változók típusának deklarálása

Lehet, de nem kötelező a változók statikus típu-sát megadni. A következő kis kódrészletek mu-tatják mindkét használatot:// St r ing : h i á ny j e l é s i d é z ő j e l e k között i s å

l e h e ts t r 1 = "Alma"St r ing s t r 2 = "Körte"p r i n t l n s t r 1 ; p r i n t l n s t r 2

// i n ti 1 = 8in t i 2 = 5p r i n t l n i 1 ; p r i n t l n i 2 ;

// doubledouble d1 = 10 .6d2 = 10.88p r i n t l n d1 ; p r i n t l n d2 ;

// BigDecimalbd1 = 12.54Gp r i n t l n bd1BigDecimal bd2 = new java . math . BigDecimalå

( "23 . 15" ) ;p r i n t l n bd2

Amikor konstansokat (literálokat) írunk akódba, akkor a következő suffix-eket használhat-juk: Long=L, BigInteger=G, Integer=I, BigDe-cimal=G, Double=D, Float=F.

Operátorok

Az operátorok használata alapvetően a Javanyelvével egyezik. Példák:i 1 = 3 ; i 2 = 5 ; i = i 1 ∗ i 2 ;p r i n t l n i ;i += 5 ; p r i n t l n i ;x = 5 ; y = x ∗∗3 ; p r i n t l n y ;

Ugyanakkor találunk célszerű, új és hasznosoperátorokat. A hatványozást így is írhatjuk,azaz nem kell a Math.pow() metódust használni.// y = 2 x^3 + 5 x^2 − 3 x + 2de f x = 5 . 0 ;de f y = 2.0∗ x∗∗3 + 5.0∗ x∗∗2 − 3 .0∗ x + 2 .0

A Java rövidített if operátora is támogatott:// Ez 3−at fog k i i r n ii 1 = 5 ; i 2 = 3 ;i = i 1 < i2 ? i 1 : i 2p r i n t l n i ;

107


Szeretnénk kiemelni, hogy az == összeha-sonlító operátor nem úgy működik, mint a Ja-vaban, mert az a mutatott objektumokat ha-sonlítja össze (nem a hivatkozások referencia cí-meit):s = "Alma"r = "Körte"p r i n t l n s == r

Az Elvis operátor (Elvis smiley) egy új elem,ami az előző kód speciális esetét támogatja:i = 0// i==5 l e s z , mert a 0==f a l s ei = i ? : 5 ;

i = 223// i==i , azaz 223 l e s z , mert a 223==truei = i ? : 5 ;

//Magyarázat : mert így értendő :i = i ? i : 5 ;

// Másképpen , e z z e l analóg :i f ( i != 0) i = i e l s e i = 5

A kiértékelés helyén ilyenkor a 0 hamis, min-den más szám pedig az igaz értéket képviseli. AzElvis operátor lényege abból fakad, hogy túl sokolyan eset van, amikor egy változó értéke kellnekünk, de ha az null, akkor pedig egy defaultérték is megteszi:i f ( something != nu l l ) {

va l = something} e l s e {

va l = de fau l tVa lue}

// Egy konkrét esetben :de f rockenekes ;enekes = rockenekes ? : " E lv i s Pre s l ey "p r i n t l n enekes// Mivel a rockenekes még nul l , e z é r t az// eredmény E lv i s Pre s l ey l e s z .

Reguláris kifejezések

A match operátor (==~ ) azt vizsgálja, hogy aminta illik-e a vizsgált karaktersorozatra. Néz-zük az alábbi példát!// 0 vagy több ka r a k t e r r e l kezdődik , majd// f a l és 0 vagy több karakte r// Emiatt a t rue fog megje l enn ide f pattern = " .∗ f a l .∗"de f i l l i k = " f a l a t "

p r i n t l n i l l i k ==~ pattern

// Azonban i t t f a l s e az eredmény ,// mert 1 vagy több ka r a k t e r r e l kezdés t// í r e l ő a mintade f pattern = ".+ f a l .∗"de f i l l i k = " f a l a t "p r i n t l n i l l i k ==~ pattern

A find operátor (=~ ) azt vizsgálja, hogy egykaraktersorozatra a minta mennyi helyen illesz-kedik, majd létrehoz egy annyi indexű objektu-mot, aminek minden tagja az illeszkedett tény-leges karaktersorozat.matcher = "abaxabbaxabbba" =~ "ab∗a"p r i n t l n matcher [ 0 ]p r i n t l n matcher [ 1 ]p r i n t l n matcher [ 2 ]

Eredmény :abaabbaabbba

Ezenfelül a Java reguláris kifejezéseket támo-gató csomagja is használható, itt csak az azt tá-mogató operátorokat szerettük volna bemutatni.

Az if utasítás

Az elágazás szervezése megegyezik a Java nyel-vével. Példa:f = 8e = 0i f ( f == 8 ) {

e = 8 ;} e l s e {e = 1 ;}p r i n t l n e ;

Ciklusok szervezése

A klasszikus while ciklus természetesen része anyelvnek:i n t i = 0 ;whi l e ( i < 50 ){

p r i n t i++;}

Eredmény :012345678910111213141516171819

Az értékintervallumon futó ciklus már Gro-ovy specifikus lehetőség:

108


f o r ( i in 1 . . 1 0 ){

p r i n t i ;}

Eredmény :12345678910

A for ciklus a listán való iterálást is támo-gatja:f o r ( s in [ "Alma" , "Körte " , " S z i l v a " ] ){

p r i n t s + " " ;}

Eredmény :Alma Körte S z i l v a

Hasznos lehetőség, hogy a füzér karaktereinis végig tudunk lépdesni:s t r = "Alma a fa a l a t t . " ;f o r ( c in s t r ){

p r i n t c + "−";}

Eredmény :A−l−m−a− −a− −f−a− −a−l−a−t−t−.−

Az utolsó érdekes ciklusírási lehetőséget mu-tatja a következő kód.0 . s tep (10 , 2) { p r i n t " $ i t "}Eredmény :0 2 4 6 8

3 . t imes { p r i n t " $ i t "}Eredmény :0 1 2

A ciklus 0-tól indul és kettesével növekszik aciklusváltozó (hivatkozás rá: $it), amíg az 10-nél kisebb. A 2. példa a times() lehetőségethasználja.

Switch utasítás

A Groovy támogatja a Java switch utasítást, dekiterjeszti a használatát, azaz nem csak felsoro-lás típus lehet az ágakon, hanem string, reguláriskifejezés, lista vagy érték intervallum is, ahogy akövetkező példa ezt mind bemutatja:d = "almax"switch ( d ) {case 1 :

p r i n t l n " case 1"

break ;case "alma " :

p r i n t l n " case 2"break ;

case [ "alma " , 3 , "aaa" ] :p r i n t l n " case 3"break ;

case 1 . . 6 :p r i n t l n " case 4"break ;

case ~/a . ∗ / :p r i n t l n " case 5"break ;

}

Értékhalmazok (Ranges)

A for ciklusnál vagy a case utasítás ismertetésé-nél már volt szó erről a nyelvi elemről. Amikorleírjuk, hogy 2..7, akkor a 2, 3, ..., 7 értékekhalmazára kell gondolnunk. Használhatunk ka-raktereket is, például: ’a’..’h’. A példában be-mutattuk, hogy egy ilyen értékhalmazra elvégez-hetőek bizonyos előre definiált műveletek: elsőelem, utolsó elem, tartalmazás reláció.szamok = 1 . . 1 0 0 ;p r i n t l n szamok . from ;p r i n t l n szamok . to ;p r i n t l n szamok . conta in s (50) ;p r i n t l n szamok . conta in s (101) ;p r i n t l n 5 in szamok ;

NULL biztos hivatkozás

Van úgy, hogy egy objektum valamely metódu-sára vagy adatára kell hivatkoznunk, de ami-kor az null értékű, akkor NullPointerExcept-ion lesz. Ilyenkor mindig csinálhatunk egyobj==null vizsgálatot, de ettől hosszú lesz akód. A ?. operátort is használhatjuk a . operá-tor helyett, ekkor a tag hívása előtt a null vizs-gálat automatikusan megtörténik.St r ing s ;s . f i nd (" a ") ;

Eredmény : Nul lPo interExcept ion

Jav í tva : a ? . op e r á t o r r a l !S t r ing s ;s ? . f i nd (" a ") ;

109


Operátor overloading

Ellentétben a Java jelenlegi 7-es verziójával,a Groovy támogatja az operátor túlterhelést,ahogy azt a következő példa mutatja:de f today = new Date ( )de f tomorrow = today + 1de f yes te rday = today − 1p r i n t l n yesterday

p r i n t l n todayp r i n t l n tomorrowa s s e r t today . p lus (1 ) == tomorrowa s s e r t tomorrow . minus (1 ) == today

A Date class objektumaira használtuk a +és - műveleteket. Ezt azért tehetjük meg, merta megírtuk a Date osztályra a plus() és mi-nus() metódusokat. A következőkben felsorol-tuk, hogy melyik metódust kell megírni, ha amegfelelő operátor jelet szeretnénk használni.a + b : a . p lus (b)a − b : a . minus (b)a ∗ b : a . mult ip ly (b)a ∗∗ b : a . power (b)a / b : a . div (b)a % b : a .mod(b)a | b : a . or (b)a & b : a . and (b)a ^ b : a . xor (b)a++ or ++a : a . next ( )a−− or −−a : a . p rev ious ( )a [ b ] : a . getAt (b)a [ b ] = c : a . putAt (b , c )a << b : a . l e f t S h i f t (b)a >> b : a . r i g h t S h i f t (b)~a : a . b i twi seNegate ( )−a : a . negat ive ( )+a : a . p o s i t i v e ( )

Osztály nélküli metódus készítése

Készíthetünk olyan metódusokat, aminek nincsáltalunk megadott osztálya. Ez hasonlít aC/C++ nyelv függvényeihez:de f szamold (a , b){

re turn a + b ;}

p r i n t l n szamold (12 , 56) ;

Eredmény : 68

Osztályok létrehozása

Itt csak egy egyszerű példát szeretnénk bemu-tatni, akit ennél több érdekel, olvassa el a Gro-ovy webhelyén lévő dokumentációt:c l a s s MyClass{

de f f i rstName ;S t r ing lastName ;de f i n t kor ;S t r ing cim ;

de f S t r ing metodus1 ( par1 , par2 ){

de f name = par1 + " " + par2 ;r e turn name ;

}}

obj = new MyClass ( ) ;p r i n t obj . metodus1 (" Kiss " , " P i s ta ") ;

Eredmény : Kiss P i s ta

// ö r ök l é sc l a s s MyClassUtod extends MyClass{

de f S t r ing metodus1 ( par1 , par2 ){

de f name = par1 + "@" + par2 ;r e turn name ;

}}

obj = new MyClassUtod ( ) ;p r i n t obj . metodus1 (" Kiss " , " P i s ta ") ;

Eredmény : Kiss@Pista

Látható, hogy az öröklés támogatott. A Gro-ovy ismeri az interface-ek fogalmát is, hasonlóanaz implements kulcsszó használható.

Kivételkezelés

A kivételkezelés a Java nyelvhez hasonlóan törté-nik, de nem kötelező megadni a kivétel objektumtípusát:try{

openFi l e ( " n i n c s i l y e n f i l e " ) ;}catch ( ex ){

p r i n t l n "Nincs ␣ i l y e n ␣ f i l e ! "}

110


A dinamikus Java

Amikor Java nyelven programokat írunk lehető-ségünk van a Groovy beágyazott használatára.

Ezzel a Java dinamikus lehetőségekkel lesz fel-vértezve. A 11-2. Programlista ennek a haszná-latát mutatja be. A Test class getMyInt2() me-tódusát a Groovy scripten keresztül hívjuk meg.

1 // 11−2. Programl is ta : A Java−ba beágyazo t t Groovy23 package j a vaapp l i c a t i on5 ;45 import groovy . lang . Binding ;6 import groovy . lang . GroovyShel l ;78 /∗∗9 ∗

10 ∗ @author i n y i r i11 ∗/12 public class Test13 {14 public int a = 10 ;1516 public int getMyInt1 ( )17 {18 return 10 ;19 }2021 public int getMyInt2 ( )22 {23 return 20 ;24 }2526 public stat ic void main ( St r ing [ ] a rgs ) throws javax . s c r i p t . Sc r ip tExcept ion27 {28 System . out . p r i n t l n ( " Indul . . . " ) ;29 Test t e s t = new Test ( ) ;30 In t eg e r i = new I n t eg e r (2 ) ;31 Binding binding = new Binding ( ) ;32 binding . s e tVa r i ab l e ( " i " , t e s t ) ;33 GroovyShel l s h e l l = new GroovyShel l ( b inding ) ;34 s h e l l . eva luate ( "o␣=␣ i . getMyInt2 ( ) ␣+␣3" ) ;35 System . out . p r i n t l n ( ( ( In t eg e r ) b inding . ge tVar i ab l e ( "o" ) ) . t oS t r i ng ( ) ) ;3637 }38 }

A 33. sor GroovyShell típusú shell objek-tuma egy Groovy script futtatását képes elvé-gezni, miközben a Java programmal való in-put/output kommunikáció a binding objektumsegítségével oldható meg. A 32. sor setVari-able() metódusa állítja be az átadandó inputobjektumokat, majd a futtatást a 34. sorbantesszük meg. Itt az o változó kapja a scriptenbelül a Java metódus futási eredményét, amit a35. sor getVariable("o") hívással tudunk a Javakódba visszakérdezni.

A Groovy shell-ek és programok

A Groovy nyelvhez néhány segédprogram is tar-tozik, ezeket nézzük meg röviden!

A groovy parancs

Egy Groovy script egy groovy kiterjesztésű file-ban van, amit parancssorból ez a program tudfuttatni. Azt tudjuk, hogy a Groovy scriptet avégén a JVM futtatja, ezért minden kapcsoló éskörnyezeti változó itt is alkalmazható (például

111


hálózati proxy-val való JVM használat). A gro-ovy parancs egy shell script, ami a háttérből aJava nyelvet használja.

A groovy fordítóprogram

Van egy groovyc nevű compiler, amivel a .classfile-ok állíthatók elő, azaz ezzel előre le lehetJava byte kódra fordítani a groovy scriptjeinket.

Groovy shell

A groovysh parancsra a lenti text alapú konzolthasználhatjuk:i ny i r i@csdev1 :~ $ groovyshGroovy Sh e l l ( 1 . 7 . 4 , JVM: 1 . 6 . 0_22)Type ’ he lp ’ or ’ \h ’ for help .−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−groovy :000> a=5===> 5groovy :000> b=10===> 10groovy :000> a∗b===> 50groovy :000> qu i tiny i r i@csdev1 :~ $

Groovy konzol

A groovyConsole parancs elindítja a 11.1. ábránlátható interaktív konzolt, amiben hatékonyanlehet a Groovy nyelvet használni és megtanulni.

11.1. ábra. A grafikus groovyConsole

Groovy fejlesztőeszközök

A példaprogramokat NetBeans-ben készítettük,ami natív támogatást ad a Groovy-hoz, azazsemmilyen további plugin-ra nincs szükség. AzEclipse környezethez létezik egy Groovy plugin.

Üzleti szabályok

Amikor az üzleti folyamatok szabályait fogal-mazzuk meg, akkor észrevehető, hogy azok ál-talában 3 féle típusúak szoktak lenni:

• Valamilyen állítás igaz vagy hamis voltá-nak a kiszámítása

• Valamely érték(ek) kiszámítása és alkal-mazása

• A számítási módszerek (algoritmusok)megadása úgy, hogy közöttük dinamikusanis tudjunk váltani (például tavaly máskép-pen számoltuk az adót, mint idén)

A Groovy nyelvi tulajdonságai kiválóan támo-gatják ezt a megközelítést, ugyanis a script rész-letek a fenti típusú üzleti szabályokat le tudjákírni, miközben azokat a Bonita adatbázisábantudjuk tárolni. Mivel a Bonita ismeri a Groovy(és Java) nyelvet, ezért ez a lehetőség nagyonrugalmas megoldásokra ad megoldást, amikor aworkflow belső állapota fölötti szabályokat Gro-ovy script elemzi és számolja ki. Képzeljük el,hogy az üzleti szabályokat paraméterezhető Gro-ovy script részletek tárolják és ezeket a Bonitaakár hálózaton keresztül is képes elérni. Amikorki szeretnénk számolni, hogy valakire kell-e al-kalmazni egy szabályt egy konkrét workflow ese-tén, akkor annak belső állapota alapján paramé-terezve meghívjuk a scriptet. Ráadásul ezek azalgoritmusok a rendszeren kívül vannak és azo-kat kívülről is állíthatjuk.

112

Business Process Management Bonita - A folyamatok szimulációja

12. Bonita - A folyamatok szimulációja

Amikor elkészültünk egy workflow alkalmazással vagy éppen már egy ideje használjuk, gyakranfelmerül az igénye annak, hogy azt működés közben figyelhessük meg. Ez lehetővé teszi a szűk ke-resztmetszetek és optimalizálási lehetőségek megtalálását egyaránt. A Bonita támogatja a munka-folyamatok szimulációs lehetőségét, ami egy olyan tulajdonsága, amivel csak a legnagyobb hasonlóeszközök dicsekedhetnek.

Mi a szimuláció?

A Bonita Studio Detail Panelen létezik egy Si-mulation fül, ahol minden BPMN elemhez kü-lönféle adatokat és valószínűségeket rendelhe-tünk. A cél az, hogy a megtervezett munkafolya-mat működési körülményeit modellezni tudjuk.Ezek a következő inputok megadását jelentik:

• Minden BPMN elemre adatok és valószí-nűségek megadása

• A munkafolyamat által használt erőforrá-sok hozzárendelése.

• Különféle működési profilok meghatáro-zása

A Simulation → Run menüpont a fenti para-méterezés elvégzése után a munkafolyamatun-kat több alkalommal végigfuttatja a háttérben,majd erről egy elég részletes riport készül. Mirejó ez a riport? Lehetővé teszi, hogy elemez-zük a folyamatot, megnézzük, hogy hol vannaka szűk keresztmetszetek. Mely ágak lennénekkihagyhatóak? Jók-e a beállított üzleti szabá-lyok? Valamely kivételes ágra milyen gyakranmegy a workflow? A szimuláció tehát abban adsegítséget egy workflow fejlesztése során, hogya munkafolyamatunkat milyen módon érdemesúgy felépíteni, hogy annak működése hatékony,optimális és intuitív módon is megfelelő legyen.

A szimulációs input paraméterek

Folyamat szintű adatok

A 12.1. ábrán mutatott tartalom a medence ki-választása után érhető el és segítségével a szimu-láció folyamat szintű adatai adhatóak meg. Azábrán az Order Lifecycle a most kiválasztott me-dence, azaz process neve. Az Add... gombra egyúj adatot tudunk felvinni.

12.1. ábra. Pool szintű adatok

Ekkor az adatelemhez a következő adatokatlehet megadni a megjelenő dialógus ablakban:

• az adatelem neve (példa: acceptOrder)

• Milyen módon adjuk meg: egy kifejezéssel(Expression) vagy valószínűséggel (Proba-bility)

• Az adatelem típusa: Boolean, Literal vagyNumber

A 12.2. ábra egy új adatelem megadását mu-tatja. A Boolean jelen esetben most azt jelenti,

113


hogy az iterációk mennyi százalékánál lesz elfo-gadva a rendelés. A Literal vagy a Number pedigazt jelentené, hogy mekkora valószínűséggel ad-juk meg azt a szöveget vagy számot inputként.A lehetséges literál és a számértékeket emiattfelsoroljuk és mindegyik mellé egy valószínűségi%-ot írunk.

12.2. ábra. Példa Pool szintű adat

BPMN elem szintű adatok

Az elemek szintjén szimulációs adatokat a követ-kező komponenseknek adhatunk:

• task

• gateway

• transition

• event (kivéve a határeseményt)

A 12.3. ábrán kiválasztottuk a Pay taskot ésrámentünk a Simulation fülére.

12.3. ábra. Elemi szintű adatok

A következő értékeket adhatjuk meg:

• Outgoing transitions are exclusive: Ami-kor a taskból több TOKEN megy ki, akkora szimulációnak mindig egyet kell kiválasz-tania

• Task is contiguous : Akkor kell pipa, ha ataskot folyamatosan el kell végezni, azaznem szakíthatjuk meg. Ellenkező eseten,amikor nincs pipa, a task megszakítható,ha nem érhető el valamilyen erőforrás.

• Execution time (ExT ): A task végrehajtásiidőtartama

• Estimated Time (EsT ): A becsült vég-rehajtási időnövekmény százalékban, amiEsT=ExT+az itt megadott %.

• Maximum Time (MaxT ): Egy küszöbszámszázalékban, ami alatt a task végrehajtásakötelező. A MaxT=ExT+az itt megadott%.

A Data fülön az egyes BPMN elemekre szinténmegadhatóak adatok, hasonlóan a Pool szint-hez. A Resource (erőforrás) fül nagyon lényegesa szimuláció helyes beállításakor. A 12.4. ábrán1 darab tankautót adtunk meg, mint a feladatvégrehajtásához szükséges egyik erőforrás. Azbiztos mindenki számára világos, hogy egy stepvégrehajtásához általában több erőforrás szük-séges, amihez mennyiséget, egységdíjat is lehetrendelni. Megadható az az idősáv is, amikor egyfeladatot szabad csinálni. Például a tankautót abolt csak reggel 6 és 18 óra között tudja fogadni.Ezen erőforrások hiányában a taszk végrehajtásanem lehetséges. Amikor a szimulációról riportkészül, akkor ezek az adatok képezik majd azalapját a költség szemléletű elemzéseknek.

114


12.4. ábra. Erőforrások a szimulációhoz

Egy-egy workflow példány futásának fontosalakítója az átmenet (transition), aminek konfi-gurációjánál (12.5. ábra) azt kell meghatároz-nunk, hogy valamilyen kifejezés vagy valószínű-ség fogja-e eldönteni, hogy azon áthalad-e a TO-KEN.

12.5. ábra. Az átmenetek szimulációja

Erőforrások és profilok

A munkafolyamat megszervezésekor minden fel-adathoz erőforrást kell rendelni, ezt láttuk. Demekkora az összes erőforrás mennyiség maxi-muma, amit a kialakítandó workflow-hoz szeret-nénk rendelni? Persze az lenne a jó, ha ennélkisebb lenne a tényleges fogyasztás, de maxi-mum tényleg ennyi legyen. A 12.6. ábra ab-laka a Simulation → Manage Resources... me-nüpont kiválasztásával érhető el. Itt megadhat-juk a workflow számára elérhető összes erőfor-rást, esetünkben eddig csak hármat vettünk fel.Ezek azok a tételek, amiket a 12.4. ábrán ki isválaszthatunk.

12.6. ábra. Erőforrások a szimulációhoz

Amikor ezt az erőforrás készletet szerkeszteniakarjuk (Add... vagy Edit... gomb), akkor a12.7. ábra ablaka szolgál erre. Nézzük meg azegyes mezők jelentését:

• Quantity : A workflow számára elér-hető maximális erőforrás mennyisége.Amennyiben az Unlimited checkbox-t ki-pipáljuk, úgy ez végtelennek tekinthető.

• Target Quantity : Ez egy küszöb erőforrásmennyiség, amikor nem akarjuk a maxi-mumot elhasználni. Abban az esetben, hanem töltjük ki, az értéke a Quantity-velegyezik meg.

• Cost Unit : A költség egysége (HUF, $, €).

• Cost per use: A használat költsége.

• Time cost : A használat időegységre jutódíja (óradíj, percdíj).

115


12.7. ábra. Egy erőforrás adatainak megadása

Az erőforrások persze nem állnak mindenpillanatban a rendelkezésünkre, ezért, ahogy a12.8. ábra is mutatja, meg kell adnunk, hogyazok a héten mikor érhetőek el.

12.8. ábra. Az erőforrás elérhetősége

Mielőtt a szimulációt elindítanánk, még megkell adni az un. Load Pofile-t, azaz azt a kö-rülményt, amit a szimulációnál még figyelembeakarunk venni. Ebből többet is definiálhatunk(12.9. ábra), de a szimuláció mindig csak azegyik kiválasztásával fog történni.

12.9. ábra. Egy Load Profile a szimulációhoz

A példánkban egy five_a_day nevű profiltdefiniáltunk, aminek a részleteit a 12.10. ábramutatja. Az egyes mezők jelentése a következő:

• Name: Ez ennek a futási profilnak a neve.

• Injection periods : Az az időszak, amireműködtetni szeretnénk a workflow-t. Le-het több egymás mellett lévő időinterval-lumot is megadni az Add a period gomb-bal.

• Repartition type: Azt szabályozza, hogyegy workflow iteráció (azaz workflow pél-dány) hogyan fog indulni a megadott pe-rióduson belül. Két értéke lehet: CONS-TANT vagy DIRECT. Az első esetben aworkflow instance-ok állandó időközöketvéve fognak indulni, az adott periódusonbelül. A második lehetőség az, hogy min-den workflow példány egyidőben indul aszimuláció elején.

• Number of instances : A szimulációbanennyiszer kérjük a workflow-t lefuttatni.

116


12.10. ábra. A Load Profile szerkesztése

A szimuláció futtatása

A főmenü Run Simulation menüpontjának kivá-lasztásával a 12.11. ábrán látható ablak jön fel,amivel már indítható a szimuláció. A Processmező mögötti választéklista segítségével az ép-pen elérhető workflow-k közül választhatjuk ki,hogy melyiket szeretnénk most szimulálni. Aszimuláció eredménye mindig egy riport, ezérta Path to reports mezőben adható meg az amappa, ahova azt el szeretnénk készíttetni. ALoad Profile a már ismertetett szimulációs profilkiválasztását teszi lehetővé. A Timespan az azidőszak, amelyre a riportba bekerül.

12.11. ábra. A Szimuláció futtatása

A szimuláció lefutása után egy nagyobb ri-port jön létre, amiben több kalkulált számítás

és grafikon (példa: 12.12. ábra) is helyet kap.

12.12. ábra. A szimuláció eredmény riportja

Az elkészült riport főbb tartalmi elemei a kö-vetkezők:

• Load profile: Az iterációk száma

• Instances Execution Time: A végrehajtásideje (óra, nap)

• Time by Instance: A minimum, maxi-mum és átlagos végrehajtási idő az összesworkflow példányt tekintve.

• Instances Waiting Time: A várakozási,azaz inaktív idők összege

• Instances Cumulated Time: A folyamatpéldányok összes időszükséglete (végrehaj-tási+várakozási idők).

A folyamat minden egyes eleméhez ezek az adat-sorok lesznek kalkulálva:

• Instances Execution Time: Az összes pél-dány végrehajtási ideje

117


• Execution Time by Instance: Példányon-kénti végrehajtási idő

• Instances Waiting Time: Az összes pél-dány várakozási ideje

• Waiting Time by Instance: Példányon-kénti várakozási idő

Ezt követi a riportban az a rész, ami a munkafo-lyamatra vonatkozó erőforrás használatot soroljafel:

• Time Cost : Az erőforrás használatánakideje.

• Cost by Instance: Workflow példányon-kénti minimum, maximum és átlagosan el-fogyasztott költség mértéke.

• Total Resources Cost : Az összes elfogyasz-tott erőforrás költsége

• Time Utilization: Időfelhasználás

• Utilization by instance: A példányonkéntiidőfelhasználás minimuma, maximuma ésátlaga.

• Total Utilization: A teljes erőforrás fel-használás nagysága.

Egy szimuláció exportja, importja

A létrehozott erőforrások és profilok elmenthe-tők és ismét betölthetők, így ezeket akárhány-szor újrahaználhatjuk. Ehhez a Simulation fő-menüpont Export és Import menüpontjait hasz-nálhatjuk. A következő file típusokat tudjuk ittmenteni vagy betölteni:

• Profilok: *.loadprofile file-ok

• Erőforrások: *.simresource file-ok

12.13. ábra. A Bonita Community szolgáltatásai

118

Business Process Management A Workflow készítés 10 aranyszabálya

13. A BPM megközelítés 10 aranyszabálya

Amit ebben a rövid cikkben írunk, minden projektre igaz lehet. Mégis szeretnénk ismételtenkiemelni ezeket, mert a munkafolyamatok építése és automatizálása nem egyszerű feladat és sokszereplője van. A sikerre csak akkor számíthatunk, ha a 10 aranyszabályt is igyekszünk figyelembevenni. Az előkészítés, fejlesztés és működtetés során időnként érdemes ezekre gondolni, hogy vajonmost éppen sértünk-e meg ezek közül egyet vagy néhányat.

1. A valóságot modellezd!

Amikor egy vállalatnál elkezdjük a BPM alkal-mazását, kell egy olyan vezetői támogatás, amiezt az elhatározást helyzetbe hozza. Azonosí-tani kell azokat a benchmarkokat, amik segíte-nek felmérni az emberek jelenlegi feladatait, amilehetővé teszi annak a modellezését. Lényeges,hogy mindig azt modellezzük, amit a kollégákvégeznek és ne azt, ahogy mi elképzeljük. Ez amodell lehet grafikus, szöveges vagy a kettő keve-réke. Amikor ismerjük a jelenlegi folyamat(ok)modelljét és célját, utána lehet nekikezdeni a fo-lyamat újraépítésének. A munkahelyeken jelen-tős mennyiségű dokumentálatlan tudás is felhal-mozódik e-mail, chat, telefonhívások útján. ABPM alkalmas arra is, hogy ezen információkegy részét is a tudásbázis részévé tegyék.

2. Gondolj nagyra, indulj kicsivel!

Egy szervezet sok egymással összekapcsolódó fo-lyamattal rendelkezik, ezeket egyszerre nyilvánnem lehet, de lehet, hogy nem is érdemes auto-matizálni. Emiatt mindig csak valamely részfo-lyamattal érdemes foglalkozni, de itt is nagyonóvatosnak kell lennünk, gondosan meg kell ter-vezni, hogy nehogy valamilyen kapcsolódó folya-matot akadályozzon. Emiatt a fokozatos fino-mítások módszere kiváltképpen hasznos a BPMterületén. Kezdjük kicsivel és folyamatosan ha-ladjunk az elképzelt Big Picture felé. A ki-sebb feladatok haszna, hogy könnyebben mér-hető a hatása, emiatt a menedzsment is eldönt-

heti, hogy jó úton járunk-e. A tipikus első lé-pések a BPM felé a riportok, megrendelések ésegyéb adminisztratív feladatok területén szok-tak lenni. Ugyanakkor veszélyes lehet az a je-lenség, hogy senki sem lesz elragadtatva attól,ha a BPM alkalmazásakor olyan folyamatokatteszünk tökéletesebbé, amik jelentéktelenek.

3. Az összes érdekeltet vond be!

Vita szokott lenni arról, hogy egy BPM pro-jektnek ki legyen a gazdája. A folyamat üz-leti érintettjei vagy az IT? Az első érintetti köra BPM-ben egy üzleti eszközt lát, míg az ITegy technológiai lehetőséget az üzlet támogatá-sára. A harmadik szereplői kör az a közvetlenfelhasználói réteg, akik nem döntenek az irány-ról, de minden nap használják a folyamataikbanrendelkezésükre álló eszközöket. Az üzlet álta-lában jól ismeri a hozzájuk tartozó folyamato-kat, az IT pedig pedig képes azokat informati-kával támogatni, nem feltétlenül teljesen auto-matizált worklflow alkalmazással. A helyes úttehát az, ha mindhárom stakeholder körből állócsapat együttesen alakítja a BPM megoldásokat.Amikor valamelyik kimarad vagy túl későn kap-csolódik be, gyakorlatilag a projekt kudarcra vanítélve, de legalábbis jelentősen növelheti a pro-jekt tényleges leszállítási idejét. A BPM egyéb-ként sokkal inkább a fenti 3 csapat folyamatosés iteratív együttműködése, mint egy-egy nagyprojekt, ami után hosszú ideig nincs folytatás.

119

Business Process Management A Workflow készítés 10 aranyszabálya

4. Válaszd ki a megfelelő eszközt!

Rengeteg különféle BPM eszköz létezik, külön-féle ambíciókkal. A végső cél persze az, hogyvelük jobban lehessen az üzleti folyamatot végre-hajtatni, azok hatékonyabbak, átláthatóbbak ésjobban szabályozhatóak legyenek. Lényeges kér-dés, hogy egy ilyen eszköznek mekkora a TCO-ja, azaz egyáltalán megfizethető-e a cég számára.Az is kérdés, hogy mennyire hatékonyan leheta kiválasztott eszközzel új folyamatokat építeni,a régieket karbantartani. Amikor minden egyesúj workflow egy egyedi alkalmazásfejlesztést je-lent, akkor biztos rossz úton járunk. Amikor úgyérezzük, hogy építkezünk és a meglévő workflowmotor és annak egységes GUI munkakörnyezeteelégséges alapnak bizonyul, akkor talán sikerülta jó eszközt kiválasztani.

5. Válassz egy bajnokot vezetőnek!

A fejlesztés elején vagy még inkább előtt pró-báljunk egy befolyásos vezetőt vagy befolyásoskollégát találni, aki végigsegíti a projektet a ne-hézségeken, mint projektvezető. Fontos, hogy Őis azonosuljon a célkitűzésekkel, különben nemfogja akkora lelkesedéssel támogatni és inspirálniaz előrehaladást, illetve képviselni a projektet afelső vezetés felé. Ekkor számára ez csak egy át-lagos leszállítandó lesz. Cserébe elvárható a tel-jes őszinteség a projekt részéről és részére teljeskontrollt kell biztosítani. Szükség esetén beavat-kozik a projekt végrehajtási folyamatába, bizto-sítja a szükséges emberi és tárgyi feltételeket.

6. Állíts fel mérföldköveket!

Amikor egy cég elhatározza, hogy követi a BPMkoncepciót ijesztő azt úgy elképzelni, mint egyet-len nagy célt. A helyes út az, ha sok kisebbelérendő célt tűzünk ki magunk elé. Az 5. pont-ban említett bajnok vezetésével egy jól megala-pozott stratégia és business case készítése cél-szerű, amiben a következő 3 év tervei szerepel-nek, mint mérföldkövek. A következő év felada-

tait pontosan meg kell tervezni, míg a következőévekét középtávú célként kell kezelni.

7. Csináld gyorsan a leszállítandót!

Az út elején fontos, hogy a menedzsment gyor-san lásson sikereket, illetve a BPM megközelítésgazdasági hasznát. Az új igényekre való gyorsreagálás azért is fontos, hogy kitűnjön az, hogyez a megközelítés valóban gyorsabban elégíti kiaz üzlet igényeit, mintha azt hagyományos esz-közökkel tettük volna.

8. Ösztönözzünk együttműködésre!

A kommunikáció fontosságát már a 3. pontbanhangsúlyoztuk. Ehhez fontos olyan szabványoseszközöket is használni, ami tovább javítja azegyüttműködés színvonalát. A BPMN példáulremek eszköz, amit az üzleti kolléga és az in-formatikus is megért, emiatt segíti a közös mun-kát. A munkafolyamatok kiépítése természeténélfogva emberek együttműködésének kialakítása,amihez az első lépés, hogy őket is bevonjuk afejlesztés megfelelő szakaszaiba, így úgy érzik,hogy ami utána leszállításra került az az, amitŐk is szeretnének.

9. Mérjük az eredményeket!

A mérések célját, fontosságát a korábbi cikke-inkben is kiemeltük, fontosak a BPM sikereinekelérése szempontjából.

10. Használj profi szolgáltatásokat!

Időnként olyan részproblémák merülhetnek felegy-egy workflow implementálása során, amely-hez nincs meg a pillanatnyi szakértelem. Fon-tos, hogy ezeket ne magányos farkasként pró-báljuk megoldani, hanem valahonnan vegyünkprofesszionális támogatást (3rd level support),illetve valamilyen User Groupnak a tagjai le-gyünk.

120

Business Process Management Bonita - Tippek és Trükkök

14. Bonita - Tippek és Trükkök

Vannak olyan apró témák, amik nem illenek be egy-egy fejezetbe, de nagyon értékes kisebb na-gyobb gondolatokat, megoldásokat, ötleteket adnak. Az Informatikai Navigátor minden száma tar-talmazza ezt a rovatot, azonban most a kiadvány témájához illeszkedve csak a Bonitához kötődőtémákból válogattunk. Nem lehet 1 helyen mindent leírni, ezért a Navigátor következő számaibana Bonita Tippek és Trükkök folytatódni fog. Szeretnénk megkérni mindenkit, hogy küldje el öt-leteit, írásait, ami ebbe a rovatba bekerülhet. A cím ahova várjuk: [email protected]. Jólenne az érdeklődő kollégák csapatából egy egymást is ismerő, jó társaságot szervezni.

MySQL konnektor használata

A Bonita RowSet bemutatása

Elöljáróban hasznos lesz megismerni a BonitaRowSet class-t implementációjával (14-1. Prog-ramlista), mert ez fontos az RDBMS konnekto-rok használatánál. A konstruktor egy listákbólálló listát épít fel, ami a SQL ResultSet egy táb-lázatot reprezentálja. A 20. sor captions vál-tozója a select oszlopainak a neveit, míg a 21.sor a values eredménytábla adatait tartalmazza.Mindegyik érték Object típusként van tárolva. A

49-51 sorok közötti getValues() csak ezt a válto-zót adja vissza. A 91-102 sorok között lévő to-List() metódus egy olyan List<Object> típusraad vissza referenciát, amelyik az eredménytáblamegadott indexű oszlopának az értékeiből áll.Ez úgy értendő, hogy amennyiben N db sora vana select eredménytáblájának, úgy ez a lista Nelemű lesz. A 73-83 sorok közötti findColumn()feladata, hogy a tábla megadott oszlopának asorszámát (indexét) adja vissza, így az 59-65 so-rok között az oszlopnévre épülő toList() metódusmár könnyen adódik.

1 // 14−1. Programl i s ta : A Bonita RowSet c l a s s23 package org . b on i t a s o f t . connector s . database ;45 import java . i o . S e r i a l i z a b l e ;6 import java . s q l . Resu l tSet ;7 import java . s q l . ResultSetMetaData ;8 import java . s q l . SQLException ;9 import java . u t i l . ArrayList ;10 import java . u t i l . L i s t ;1112 /∗∗13 ∗ This c l a s s r ep r e s en t s a t a b l e o f data r ep r e s en t i n g a database r e s u l t s e t .14 ∗ @author Matthieu Cha f f o t t e15 ∗16 ∗/17 public class RowSet implements S e r i a l i z a b l e {1819 private stat ic f ina l long se r ia lVers ionUID = 6888083143926506575L ;20 private List<Str ing> capt i ons ;21 private List<List<Object>> va lues ;2223 RowSet ( Resu l tSet r e s u l t S e t ) throws SQLException {

121


24 capt i ons = new ArrayList<Str ing >() ;25 va lue s = new ArrayList<List<Object >>() ;26 i f ( r e s u l t S e t != null ) {27 ResultSetMetaData metaData = r e s u l t S e t . getMetaData ( ) ;28 int columns = metaData . getColumnCount ( ) ;29 for ( int i = 1 ; i <= columns ; i++) {30 St r ing columnName = metaData . getColumnName( i ) ;31 capt i ons . add (columnName) ;32 }33 while ( r e s u l t S e t . next ( ) ) {34 ArrayList<Object> row = new ArrayList<Object >() ;35 for ( int j = 1 ; j <= columns ; j++) {36 Object va lue = r e s u l t S e t . getObject ( j ) ;37 row . add ( value ) ;38 }39 va lue s . add ( row ) ;40 }41 }42 r e s u l t S e t . c l o s e ( ) ;43 }4445 /∗∗46 ∗ Gets a l l the va l u e s o f the RowSet47 ∗ @return the va l u e s o f the t a b l e48 ∗/49 public List<List<Object>> getValues ( ) {50 return va lue s ;51 }5253 /∗∗54 ∗ Converts the des igned column to a L i s t o b j e c t .55 ∗ @param column the column name56 ∗ @return a L i s t o b j e c t t h a t conta ins the va l u e s s t o r ed in the s p e c i f i e d å

column57 ∗ @throws SQLException i f an error occurs genera t ing the c o l l e c t i o n or an å

i n v a l i d column name i s prov ided58 ∗/59 public List<Object> toL i s t ( S t r ing columnName) throws SQLException {60 int column = findColumn (columnName) ;61 i f ( column > 0) {62 return t oL i s t ( column ) ;63 }64 return null ;65 }6667 /∗∗68 ∗ Gives the column index o f the g iven column name .69 ∗ @param columnName the name o f the column70 ∗ @return the column index o f the g iven column name71 ∗ @throws SQLException i f the RowSet o b j e c t does not conta in columnName72 ∗/73 public int findColumn ( St r ing columnName) throws SQLException {

122


74 try {75 int index = capt i ons . indexOf ( columnName) ;76 i f ( index == −1) {77 throw new SQLException ( columnName + "␣does ␣not␣ e x i s t " ) ;78 }79 return index + 1 ;80 } catch ( Exception e ) {81 throw new SQLException ( columnName + "␣does ␣not␣ e x i s t " ) ;82 }83 }8485 /∗∗86 ∗ Converts the des igned column to a L i s t o b j e c t .87 ∗ @param column the column number88 ∗ @return a L i s t o b j e c t t h a t conta ins the va l u e s s t o r ed in the s p e c i f i e d å

column89 ∗ @throws SQLException i f an error occurs genera t ing the c o l l e c t i o n or an å

i n v a l i d column id i s prov ided90 ∗/91 public List<Object> toL i s t ( int column ) throws SQLException {92 i f ( column < 1 | | column > capt i ons . s i z e ( ) ) {93 throw new SQLException ( " i n v a l i d ␣column␣ id : ␣" + column ) ;94 }95 List<Object> l i s t = new ArrayList<Object >() ;96 i f ( column > 0) {97 for ( L i s t<Object> row : va lue s ) {98 l i s t . add ( row . get ( column −1) ) ;99 }100 }101 return l i s t ;102 }103104 }

A mySQL konnektor konfigurálása

A konfigurálás beállítását a következő adatbázisparaméterek mellett fogjuk bemutatni:

• Az adatbázis neve: dbtestimre

• A használható jdbc string:jdbc:mysql://localhost:3306/dbtestimre

• A driver class: com.mysql.jdbc.Driver

• A select parancs: select * from testtable(lehet itt INSERT, UPDATE, DELETEis)

A testtable jelenleg 4 sorból áll, ezt fogjuk lekérnia konnektorral.

mysql > select * from testtable;+--------------+-------+------+| m1 | m2 | m3 |+--------------+-------+------+| Nyiri Imre | Imi | FF || Nyiri Imrus | Imrus | FF || Szabó Laci | Laci | FF || Kiss Julika | Juci | NN |+--------------+-------+------+4 rows in set (0.00 sec)

123


Készítettünk egy egyszerű 2 lépésesworkflow-t, aminek Step1 és Step2 taskjai van-nak. A mySQL konnektor példányunkat a Step1Finished eseményére fogjuk rákötni, ezért vá-lasszuk ki ezt a step-et és a Detail Panel-jén men-jünk a General → Connectors fülre, majd nyom-juk meg az Add... gombot. A bejött, konnekto-rokat tartalmazó dialógus ablakból válasszuk kia Database kategórián belül lévő MySQL kon-nektort, majd nyomjuk meg a Next gombot,amire a 14.1. ábra ablaka jön be. Itt látható,hogy a finish eseményre választottuk ki a kon-nektor lefutását.

14.1. ábra. Egy mySQL konnektor

A Next gombra a 14.2. ábra ablaka jelenikmeg, amint már ki is töltöttük. A Save connec-tor configuration... gombra el is mentettük ezt aconnection információ együttest, így a későbbi-ekben már nem kell újra megadnunk, ha ebbenaz adatbázisban akarunk legközelebb is dolgozni.

14.2. ábra. A mySQL adatbázis kapcsolat

Nyomjuk meg ismét a Next gombot, amire a14.3. ábra ablaka bukkan elő. Itt megadtuk azSQL select parancsunkat és megnyomtuk a TestConfiguration gombot, amire bejön a kis táblánkösszes sora. Itt egy Groovy script is megadható,ami összeállítja a lefuttatandó select parancsot.Például, ha egy Pool szintű sql változóban se-lect * from testtable van, akkor ide a ${sql} isírható. Mi még ennél is összetettebb megoldástalkalmaztunk itt, mert a Pool szintjére felvet-tünk 3 változót:

• select : ide kéri be az SQL select oszlopki-választási részét

• where: ide kéri a where feltétel stringjét

• sql : ide teszi, hogy milyen SQL utasítástkell végrehajtani

Esetünkben így a Groovy script egészen elemirészekből is össze tudja rakni az sql változó tar-talmát:i f ( s e l e c t==nu l l ) s e l e c t = " s e l e c t ∗ from å

t e s t t a b l e " ;i f ( where==nu l l ) where = "" ;s q l = s e l e c t + where

Eddig minden rendben van, menjünk isméttovább a Next gombbal!

124


14.3. ábra. A select utasítás és tesztelése

14.4. ábra. A konnektor kimenetének map-elése

A következő ablak (14.4. ábra) arra szolgál,hogy a konnektor visszatérő értékét megadjuk(ez az ábra Connector output mezője) és ezthozzárendeljük a Workflow egyik belső adatá-hoz (Destionation variable mező). A „+” gomb-bal több ilyen összerendelés is beállítható egyet-len konnektorfutásra. A Connector outputra vá-laszthattuk volna a megismert RowSet osztály-beli visszaadott objektum getValues() metódu-sát is, de mi most inkább a következő scriptetírtuk (ennek az első néhány karaktere látszik az1 soros beviteli mezőben):List<Object> x = rowSet . getValues ( )x . get 0

A script lekéri x -be visszatérés x.get 0, ez aPool szintű fogado (String típusú) változóba ke-rül és a Step2 formján meg is jelenítjük majd.

14.5. ábra. A Step1 task űrlapja

14.6. ábra. A Step2 task űrlapja

A Step1 lépéshez egy olyan formot generál-tunk (14.5. ábra), ami bekéri a select és whereértékeket. A Submit1 gombra lefut a konnektor(a finish event-re), amely összeállítja a fentiekalapján az sql medence változó tartalmát, lefut-tatja majd a fogado nevű változóhoz rendeli amapping szabály szerint az eredményt. A Step2lépés formja ((14.6. ábra)) megjeleníti, hogy mivolt azt összeállított sql, illetve az eredményt,azaz a fogado változó tartalmát.

Egy LDAP konnektor konfigurálása

Az LDAP konnektort egy olyan egyszerűworkflow-n próbáltuk ki, aminek csak Step1taskja van, így álljunk erre és válasszuk ki aConnectors fül Add... gombját, amelyre a 14.7.ábra ablaka jön be. Az enter event-re kötjük az

125


LDAP konnektor példányunkat. Nyomjuk mega Next gombot!

14.7. ábra. Egy új LDAP konnektor példány

A 14.8. ábra a varázsló következő ablakátmutatja, itt kell megadni az LDAP (vagy ActiveDirectory) szerver eléréséhez szükséges informá-ciókat, majd ismét nyomjunk Next gombot.

14.8. ábra. Az LDAP szerver paraméterei

A következő ablak (14.8. ábra) az LDAP-bólvaló lekérés megadását teszi lehetővé. A BaseDN adja meg, hogy melyik ágon keressünk, a

Filter pedig azt, hogy mit. Ezután ismételtenclick a Next gombra!

14.9. ábra. Az LDAP search paraméterei

Az utolsó lépés a már ismert mapping, amiaz LDAP eredményét most az adat nevű me-dence szintű változóhoz rendeli (14.10. ábra). AConnector output megint egy Groovy script lesz:adatok="AD= " ;Lis t<Object> l i s t = ldapAt t r i bu t eL i s t . get (0 ) ;

l i s t . each {adatok += i t ;

}re turn adatok ;

14.10. ábra. Konnektor mapping beállítása

Végül futtatva az alkalmazást a 14.11. ábra

126


tartalmát láthatjuk a Step1 taskhoz tartozó űr-lapon.

14.11. ábra. Az LDAP konnektor tesztelése

E-Mail bejelentés új feladatról

Sokszor igényként jelentkezik, hogy e-mailbenküldjük, ha valakinek új feladata van. Ez Bo-nitában egyszerű feladat, mert ilyenkor a taskenter eseményére egy e-mail konnektor-t kellrákonfigurálni. Az e-mail tartalma konfigurál-ható, ugyanis azt egy Groovy scripttel állíthat-juk össze. A többnyelvű esetet is kezelhetjük,ugyanis a Groovy ismeri a Java I18N mechaniz-musát, például a message bundle-t is. Az e-mailkonnektor használatának részleteit a ConnectorGuide tartalmazza. A következőkben rövidenazt írjuk le, hogy egy új task érkezéséről hogyanküldjünk e-mail, ami a taskra mutató linket és a

task nevét is tartalmazza. Szükséges előfeltéte-lek:

• kell egy vagy több SMTP e-mail account,ahova a levelet (leveleket) küldjük

• kell egy elérhet SMTP szerver, amin ke-resztül a levelet el tudjuk küldeni

• a levélküldőnek is kell egy postafiók

A felhasználót – akinek e-mail címe van – felve-hetjük a Bonita UserXP adatbázisába is: user,e-mail cím. Az e-mail konnektor számára meg-adandó input adatok (a példában a gmail-t hasz-náltuk):

• Host name és port (smtp.gmail.com)

• az SMTP user név és jelszó

• a feladó e-mail címe (from)

• a címzettek e-mail címe (to): A levél cím-zettjei kódrész implementálja

• A levél tárgya (subject): A taszk nevénekmegszerzése kódrész implementálja

• A levél szövege (body): A levél szövegekódrész implementálja

// A l e v é l c ím z e t t j e iimport org . ow2 . bonita . u t i l . Acce s so rUt i l

de f cand idate s = Acce s so rUt i l . getQueryRuntimeAPI ( ) . getTaskCandidates (åa c t i v i t y I n s t a n c e . getUUID ( ) )

de f to=""for ( user in cand idate s ) {

i f ( to !="" )to += " , "

// Ha az e−mail nem a Bonita User Experience−ben van táro l va , akkor// e z t a s o r t c s e r é l j ü k k i a meg f e l e l ő r eto += Acce s so rUt i l . get Ident i tyAPI ( ) . getUser ( user ) . getEmail ( )

}return to ’ ’

// A ta s z k nevének megszerzése

127


a c t i v i t y I n s t a n c e . getDynamicLabel ( )==null ? a c t i v i t y I n s t a n c e . g e tAct i v i tyLabe l ( ) :åa c t i v i t y I n s t a n c e . getDynamicLabel ( )

// A l e v é l s zövegeA new task has been as s i gned to you :

${ a c t i v i t y I n s t a n c e . getDynamicDescr ipt ion ( )==null ? a c t i v i t y I n s t a n c e .åg e tAc t i v i t yDe s c r i p t i on ( ) : a c t i v i t y I n s t a n c e . getDynamicDescr ipt ion ( ) ) }

Please c l i c k on next l i n k to perform your task :

${// A Bonita s z e r v e r t f u t t a t ó gép neve vagy IP címe

p r ov i d ed s c r i p t s . BonitaURLs . getStepURL ( " ip_address_of_your_computer" , "9090" ,åp ro c e s sDe f i n i t i on , a c t i v i t y I n s t a n c e )

}

}

Az LDAP alapú hitelesítés

A JBOSS+Bonita integrált szerveren használ-hatjuk az org.jboss.security.auth.spi.LdapExtLoginModulelogin modult, de esetleg kipróbálhatjuk az

Oracle (Sun) com.sun.security.auth.module.LdapLoginModuleosztályt is. A login-config.xml file-t a telepítés-ről írt cikkben már ismertettük, ennek egy le-hetséges tartalma, amikor az LDAP hitelesítéstszeretnénk használni:

<po l i c y><app l i c a t i on−po l i c y name="BonitaAuth">

<authen t i c a t i on><log in−module code="org . j bo s s . s e c u r i t y . auth . s p i . LdapExtLoginModule" f l a g="å

r equ i r ed "><module−opt ion name=" java . naming . prov ide r . u r l ">ldap : //å

your_ldap_server:389</module−opt ion><module−opt ion name=" java . naming . s e c u r i t y . au then t i c a t i on ">simple</module−å

opt ion><module−opt ion name="baseCtxDN">DC=domain ,DC=com</module−opt ion><module−opt ion name="bindDN">DOMAIN\ ldapbrowser</module−opt ion><module−opt ion name=" bindCredent ia l "><! [CDATA[ Yourpasswd ] ]></module−å

opt ion><module−opt ion name=" ba s eF i l t e r ">(sAMAccountName={0})</module−opt ion><module−opt ion name=" searchScope ">SUBTREE_SCOPE</module−opt ion><module−opt ion name="allowEmptyPasswords">f a l s e</module−opt ion><module−opt ion name="debug">true</module−opt ion><module−opt ion name="rolesCtxDN">DC=domain ,DC=com</module−opt ion><module−opt ion name=" r o l e F i l t e r ">(sAMAccountName={0})</module−opt ion><module−opt ion name=" ro l eAt t r ibute ID ">memberOf</module−opt ion><module−opt ion name=" ro leAttr ibute I sDN">true</module−opt ion><module−opt ion name=" roleNameAttributeID">cn</module−opt ion><module−opt ion name=" java . naming . r e f e r r a l ">f o l l ow</module−opt ion>

</ log in−module>

128


</ authen t i c a t i on></ app l i c a t i on−po l i c y><app l i c a t i on−po l i c y name="BonitaStore ">

<authen t i c a t i on><log in−module code="org . ow2 . bonita . i d e n t i t y . auth . BonitaRemoteLoginModule" å

f l a g=" requ i r ed "/><log in−module code="org . j bo s s . s e c u r i t y . ClientLoginModule " f l a g=" requ i r ed ">

<module−opt ion name="password−s t a ck ing ">useF i r s tPas s</module−opt ion></ log in−module>

</ authen t i c a t i on></ app l i c a t i on−po l i c y>

</ po l i c y>

A bonita-server.xml file-ban az AuthentionService class pedig így nézhet ki:package com . domain . bonita . auth ;

import org . ow2 . bonita . facade . except ion . UserNotFoundException ;import org . ow2 . bonita . s e r v i c e s . Authent i ca t i onSe rv i c e ;

public class SimpleLdapAuth implements Authent i ca t i onSe rv i c e{

private St r ing pers i s t enceServ i ceName ;

public SimpleLdapAuth ( St r ing pers i s t enceServ i ceName ){

super ( ) ;this . pe r s i s t enceServ i ceName = pers i s t enceServ i ceName ;

}

/∗∗∗ Determines i f the user shou ld have amdin acces se s to the bon i ta i n t e r f a c e∗ Let ’ s say t ha t Domain Admins have t ha t p r i v i l e g e∗/

public boolean isUserAdmin ( St r ing username ) throws UserNotFoundException{

i f ( username . equa l s ( "MyAdmin" ) ){

return true ;}else{

return fa lse ;}

}

/∗∗∗ @return always t rue . I f the LDAP reque s t f a i l e d be fore , i t doesn ’ t matter (?)∗ Necessary to implement i n t e r f a c e∗/

public boolean checkUserCredent ia l s ( S t r ing username , S t r ing password ){

return true ;}

}

Erről egy leírás itt olvasható: http://ironman.darthgibus.net/?p=57

129

Business Process Management A Bonita API használata

15. A Bonita API használata

Néha szükség lehet arra, hogy akár a Bonita Studio környezetét is elhagyva, közvetlenül progra-mozzuk a Bonita Execution Engine-t, azaz a Workflow motort. Miért? Ennek több oka is lehet.Valamilyen egyedi, akár vastag kliens alkalmazást szeretnénk készíteni valamelyik munkafolyamatGUI támogatásához. Persze az is lehetséges, hogy csak bizonyos adminisztratív vagy üzemeltetőifeladatok kívánják meg az API közvetlen használatát. Végül elképzelhető, hogy egy új újrahaszno-sítható Bonita komponenst szeretnénk elkészíteni. Az ilyen feladatokhoz szükséges tudást tekintiát ez a cikk.

A Bonita Tippek és Trükkök rész E-Mailbejelentés új feladatról megoldása kapcsán márbelepillanthattunk a Bonita API használatába,azt is megérthettük, hogy ennek ismerete időn-ként szükséges lehet. Ezen írás arra vállalko-zik, hogy segítse azokat a kezdőlépéseket, amiután önállóan is képesek leszünk az API hasz-nálatára. Röviden áttekintjük, hogy ez az APImilyen főbb részekből áll és hogyan érhető el,majd egy teljesen kidolgozott mintapéldán ke-resztül (egy egyedi web alkalmazás) alaposanbe is mutatjuk a használatát. A Bonita jelen-legi 5.5.2 verziójának API javadoc dokumentá-ciója itt érhető el: http://www.bonitasoft.org/docs/javadoc/bpm_engine/5.5/. Ezzela programozói interface-szel az Bonita Execu-tion Engine (más néven: Bonita Runtime) köz-vetlenül elérhető. A Runtime egy nagyon jólkonfigurálható motor, amit a BOS-5.5.2-JBoss-5.1.0.GA/bonita/server/default/conf/bonita-server.xml file segítségével valósít meg. Hasz-nálhatjuk valamilyen JEE környezetbe telepítve,de egy egyszerű Java programozói könyvtárkéntis (beágyazott használat).

A Bonita API áttekintése

A Bonita API egy objektum modellel (BonitaObject Model) rendelkezik, azaz a Runtime APIegy kényelmes, objektumorientált felületet biz-tosít számunkra, aminek alapvetően 2 része van:Definition Object Model és Runtime Object Mo-

del. Az első olyan osztályokból áll, amik a mun-kafolyamatok mintáit, míg a második az ezek-ből létrejött instance-ok absztrakcióját és eléré-sét szolgáltatja.

Definition Object Model

A Definition Object Model feladata, hogy aworkflow motorban lévő definíciókat tárolja.Erre jó példa a Process Model, azaz ami-kor egy munkafolyamatot megtervezünk BPMN-ben, akkor annak összetevőit és felépítését ilyenmodellben tároljuk. A folyamat példányok ezenminták alapján hozhatók létre. A root objek-tum ebben az objektum fában a ProcessDefini-tion Java class objektum példány. Technikailagez az objektum egy ProcessBuilder objektumothasználva épül fel. A ProcessDefinition osztályfontosabb adatmezői a következőek:

• uuid: A munkafolyamat leíró ProcessDefi-nition class egyedi azonosítója

• name: A process minta neve

• label : Egy címke, ami a ProcessDefinitionclass neve

• description: A munkafolyamat rövid le-írása

• version: A workflow terv verziója

• state: A workflow class 3 állapotban lehet.Enabled → Ekkor ebből a process mintából

130


process példány hozható létre, Disabled →letiltottuk, hogy új process instance jöjjönebből létre, Archived → a process archi-vált lett, amiatt ekkor sem hozható létreúj példány belőle

• deployedBy : A process telepítője és

• deployedDate: a telepítés dátuma

• undeployedBy : A process megszüntetője és

• undeployedDate: annak dátuma

• datafields : a process belső adatmezői

• participants : résztvevők

• activities : a processben lévő feladatok

• attachments : csatolmányok

• metadata: egyéb leíró adatok

A ProcessDefinition minden objektuma direkthivatkozást tartalmaz az uuid mezőre.

Runtime Object Model

A működés közbeni állapot reprezentálásáraszolgál, root objektuma egy ProcessInstance pél-dány. Itt reprezentálódnak az éppen végrehajtásalatt lévő vagy végrehajtott folyamat példányok.A legfontosabb mezői a következőek:

• instanceUUID : A munkafolyamat egyediazonosítója

• processUUID : A munkafolyamat Process-Definition osztályának egyedi azonosítója

• state: Egy munkafolyamat példány 4 kü-lönféle állapotban lehet. Started → a mun-kafolyamat elindult és van még hátra fel-adat, Finished → a munkafolyamat befe-jeződött, Canceled → a process Admin tö-rölte a munkafolyamatot, Aborted → vala-milyen belső hiba miatt leállt a munkafo-lyamat

• startedBy: A munkafolyamat elindítója

• startedDate: A workflow példány indításá-nak dátuma

• endedBy : A munkafolyamat lezárója

• endedDate: A folyamat végének időpontja

• activities: Tevékenységek

• variables : Változók

• attachments : Csatolmányok

• involvedUsers : Bevont felhasználók

• variableUpdates: Az utolsó állapotváltozás

• stateUpdates : Az állapot beállásának dá-tuma

Az objektumfa fontos része még az ActivityIns-tance, illetve amikor Humán taszk van, akkor aTaskInstance.

Az API elérési lehetőségei

A Bonita API a következő technológiákkal ér-hető el:

• Közvetlen Java alapú elérés : Ekkor ugyan-abban a Java gépben fut a Runtime és akliens program, így az API direktben is el-érhető.

• EJB 2 és EJB 3 technológiák : A BonitaRuntime mellé az alkalmazás szerverre te-lepíthető egy bonita.ear nevű JEE alkal-mazás, ami a 15-1. Programlista alapjánlátható (a nevek az ejb-name tag-ekből ol-vashatóak ki) ejb-jar.xml leíróval rendelke-zik. Ez azt jelenti, hogy ezek az EJB kom-ponensek a Runtime-mal együtt, ugyan-abba a JVM-be vannak telepítve, így azokelérik az API-t. Az EJB kliensek pedig azEJB objektumokon keresztül az engine-ttudják használni.

131


• REST webservice: A REST egy népszerűés platformfüggetlen webservice techno-lógia, ami a SOAP alternatívája (to-vábbi információ: http://en.wikipedia.org/wiki/Representational_state_

transfer). Az implementáció elérését atelepített bonita-server-rest.war web al-kalmazás biztosítja, ami a HTTP fölöttelérhetővé teszi ezzel a Bonita API-t.

1 // 15−1. Prog raml i s ta : bonita ear ejb−j a r . xml23 <?xml version=" 1.0 "?>4 <ejb−j a r xmlns=" ht tp : // java . sun . com/xml/ns/ javaee " xmlns :x s i=" ht tp : //www.w3 . org /2001/XMLSchema−i n s t ance " å

xs i : s chemaLocat ion=" ht tp : // java . sun . com/xml/ns/ javaee ␣ h t tp : // java . sun . com/xml/ns/ javaee / ejb−jar_3_0 . xsd" åversion=" 3.0 ">

5 <ent e rp r i s e−beans>6 <s e s s i o n>7 <ejb−name>commandAPIBean</ejb−name>8 <mapped−name>commandAPI</mapped−name>9 <bus iness−remote>org . ow2 . bonita . facade . i n t e r n a l .RemoteCommandAPI</ bus iness−remote>10 <ejb−c l a s s>org . ow2 . bonita . facade . e jb .CommandAPIBean</ejb−c l a s s>11 <se s s i on−type>S t a t e l e s s</ se s s i on−type>12 </ s e s s i o n>13 <s e s s i o n>14 <ejb−name>webAPIBean</ejb−name>15 <mapped−name>webAPI</mapped−name>16 <bus iness−remote>org . ow2 . bonita . facade . i n t e r n a l . RemoteWebAPI</ bus iness−remote>17 <ejb−c l a s s>org . ow2 . bonita . facade . e jb .WebAPIBean</ejb−c l a s s>18 <se s s i on−type>S t a t e l e s s</ se s s i on−type>19 </ s e s s i o n>20 <s e s s i o n>21 <ejb−name>identityAPIBean</ejb−name>22 <mapped−name>ident i tyAPI</mapped−name>23 <bus iness−remote>org . ow2 . bonita . facade . i n t e r n a l . RemoteIdentityAPI</ bus iness−remote>24 <ejb−c l a s s>org . ow2 . bonita . facade . e jb . IdentityAPIBean</ejb−c l a s s>25 <se s s i on−type>S t a t e l e s s</ se s s i on−type>26 </ s e s s i o n>27 <s e s s i o n>28 <ejb−name>runtimeAPIBean</ejb−name>29 <mapped−name>runtimeAPI</mapped−name>30 <bus iness−remote>org . ow2 . bonita . facade . i n t e r n a l . RemoteRuntimeAPI</ bus iness−remote>31 <ejb−c l a s s>org . ow2 . bonita . facade . e jb . RuntimeAPIBean</ejb−c l a s s>32 <se s s i on−type>S t a t e l e s s</ se s s i on−type>33 </ s e s s i o n>34 <s e s s i o n>35 <ejb−name>managementAPIBean</ejb−name>36 <mapped−name>managementAPI</mapped−name>37 <bus iness−remote>org . ow2 . bonita . facade . i n t e r n a l . RemoteManagementAPI</ bus iness−remote>38 <ejb−c l a s s>org . ow2 . bonita . facade . e jb . ManagementAPIBean</ejb−c l a s s>39 <se s s i on−type>S t a t e l e s s</ se s s i on−type>40 </ s e s s i o n>41 <s e s s i o n>42 <ejb−name>queryRuntimeAPIBean</ejb−name>43 <mapped−name>queryRuntimeAPI</mapped−name>44 <bus iness−remote>org . ow2 . bonita . facade . i n t e r n a l . RemoteQueryRuntimeAPI</ bus iness−remote>45 <ejb−c l a s s>org . ow2 . bonita . facade . e jb . QueryRuntimeAPIBean</ejb−c l a s s>46 <se s s i on−type>S t a t e l e s s</ se s s i on−type>47 </ s e s s i o n>48 <s e s s i o n>49 <ejb−name>queryDefinit ionAPIBean</ejb−name>50 <mapped−name>queryDef in i t ionAPI</mapped−name>51 <bus iness−remote>org . ow2 . bonita . facade . i n t e r n a l . RemoteQueryDefinitionAPI</ bus iness−remote>52 <ejb−c l a s s>org . ow2 . bonita . facade . e jb . QueryDefinitionAPIBean</ejb−c l a s s>53 <se s s i on−type>S t a t e l e s s</ se s s i on−type>54 </ s e s s i o n>55 <s e s s i o n>56 <ejb−name>bamAPIBean</ejb−name>57 <mapped−name>bamAPI</mapped−name>58 <bus iness−remote>org . ow2 . bonita . facade . i n t e r n a l .RemoteBAMAPI</ bus iness−remote>59 <ejb−c l a s s>org . ow2 . bonita . facade . e jb .BAMAPIBean</ejb−c l a s s>60 <se s s i on−type>S t a t e l e s s</ se s s i on−type>61 </ s e s s i o n>62 <s e s s i o n>63 <ejb−name>repairAPIBean</ejb−name>64 <mapped−name>repairAPI</mapped−name>65 <bus iness−remote>org . ow2 . bonita . facade . i n t e r n a l . RemoteRepairAPI</ bus iness−remote>66 <ejb−c l a s s>org . ow2 . bonita . facade . e jb . RepairAPIBean</ejb−c l a s s>67 <se s s i on−type>S t a t e l e s s</ se s s i on−type>68 </ s e s s i o n>69 </ en t e rp r i s e−beans>70 <in t e r c e p t o r s>71 <in t e r c ep t o r>72 <in t e r c ep to r−c l a s s>org . ow2 . bonita . facade . i n t e r c e p t o r . EJB3Interceptor</ in t e r c ep to r−c l a s s>73 <around−invoke>74 <method−name>per fo rmInte r cept i on</method−name>

132


75 </around−invoke>76 </ i n t e r c ep t o r>77 </ i n t e r c e p t o r s>78 <assembly−de s c r i p t o r>79 <in t e r c ep to r−binding>80 <ejb−name>∗</ejb−name>81 <in t e r c ep to r−c l a s s>org . ow2 . bonita . facade . i n t e r c e p t o r . EJB3Interceptor</ in t e r c ep to r−c l a s s>82 </ in t e r c ep to r−binding>83 <app l i ca t i on−except ion>84 <except ion−c l a s s>org . ow2 . bonita . u t i l . BonitaRuntimeException</ except ion−c l a s s>85 </ app l i ca t i on−except ion>86 <app l i ca t i on−except ion>87 <except ion−c l a s s>org . ow2 . bonita . facade . except ion . Bon i ta Interna lExcept ion</ except ion−c l a s s>88 </ app l i ca t i on−except ion>89 <app l i ca t i on−except ion>90 <except ion−c l a s s>org . ow2 . bonita . u t i l . AtomicArchiveException</ except ion−c l a s s>91 </ app l i ca t i on−except ion>92 <app l i ca t i on−except ion>93 <except ion−c l a s s>org . ow2 . bonita . facade . except ion . BonitaWrapperException</ except ion−c l a s s>94 </ app l i ca t i on−except ion>95 <app l i ca t i on−except ion>96 <except ion−c l a s s>org . ow2 . bonita . deployment . DeploymentRuntimeException</ except ion−c l a s s>97 </ app l i ca t i on−except ion>98 <app l i ca t i on−except ion>99 <except ion−c l a s s>org . ow2 . bonita . env . Inval idEnvironmentException</ except ion−c l a s s>100 </ app l i ca t i on−except ion>101 <app l i ca t i on−except ion>102 <except ion−c l a s s>org . ow2 . bonita . facade . except ion . Express ionEvaluat ionExcept ion</ except ion−c l a s s>103 </ app l i ca t i on−except ion>104 <app l i ca t i on−except ion>105 <except ion−c l a s s>org . ow2 . bonita . facade . except ion . HookInvocationException</ except ion−c l a s s>106 </ app l i ca t i on−except ion>107 <app l i ca t i on−except ion>108 <except ion−c l a s s>org . ow2 . bonita . facade . except ion . RoleMapperInvocationException</ except ion−c l a s s>109 </ app l i ca t i on−except ion>110 <app l i ca t i on−except ion>111 <except ion−c l a s s>org . ow2 . bonita . facade . except ion . Per formerAss ignInvocat ionExcept ion</ except ion−c l a s s>112 </ app l i ca t i on−except ion>113 <app l i ca t i on−except ion>114 <except ion−c l a s s>org . ow2 . bonita . facade . except ion . Mu l t i In s tant i a to r Invoca t i onExcept i on</ except ion−c l a s s>115 </ app l i ca t i on−except ion>116 <app l i ca t i on−except ion>117 <except ion−c l a s s>java . lang . I l l ega lArgumentExcept ion</ except ion−c l a s s>118 </ app l i ca t i on−except ion>119 <app l i ca t i on−except ion>120 <except ion−c l a s s>java . lang . I l l e g a l S t a t eEx c ep t i on</ except ion−c l a s s>121 </ app l i ca t i on−except ion>122 <app l i ca t i on−except ion>123 <except ion−c l a s s>org . ow2 . bonita . connector . core . desc . ConnectorDescriptorNotFoundException</ except ion−c l a s s>124 </ app l i ca t i on−except ion>125 </assembly−de s c r i p t o r>126 </ejb−j a r>

A Bonita API komponensei

Az API technikai használatát néhány jólátgondolt és egy-egy használati témakörtlefedő komponens valósítja meg, amik-hez egyetlen elérő osztályt biztosított:org.ow2.bonita.util.AccessorUtil class-t. Ez afő belépési pontja (main entry point) a BonitaAPI-nak.

A ManagementAPI komponens

A működési környezet kialakítását támogatja,azaz ezzel lehet telepíteni vagy visszamozgatniworkflow-kat, erőforrásokat, filtereket. Ezzela résszel lehet a futó process-eket menedzselni(példa: egy process törlése). További érdekes

lehetőség az új metaadatok felvétele az addMet-adata(key, value) metódussal.

A QueryDefinitionAPI komponens

A definíciós objektum modellre lehet lekérdezé-seket megfogalmazni, így arról értékes informá-ciók gyűjthetőek be. Példák:

• getProcesses()

• getProcess( processUUID )

• getProcessActivities( processUUID, activityName )

A RuntimeAPI komponens

A Runtime objektum modell vonatkozásábanírási (a workflow állapota változik) és olvasási

133


műveletek végzését is biztosítja. Példák:

• executeTask( taskUUID )

• assignTask( taskUUID, userId )

• instantiateProcess( processUUID )

• setProcessInstanceVariable( processInstanceUUID, varia-bleName, variableValue )

• deleteProcessInstance( processInstanceUUID )

A QueryRuntimeAPI komponens

A Runtime objektum modellre vonatkozó lekér-dezéseket támogatja. Példák:

• getProcessInstances()

• getActivityInstance( activityInstanceUUID )

• getTaskList( taskState )

• getVariable( activityInstanceUUID, variableName )

• getProcessInstanceVariable( processInstanceUUID, varia-bleName )

A RepairAPI komponens

A fejlettebb üzemeltetési, működtetési folyama-tokat támogatja. Példák:

• startExecution( processInstanceUUID, activityName )

• stopExecution( processInstanceUUID, activityName )

A CommandAPI komponens

Egy parancs API felület, amivel az engine szá-mára közvetlen utasításokat adhatunk. Példák:

• execute( command, processUUID )

• execute( command )

Az IdentityAPI komponens

A felhasználók kezelését megvalósító API modul.Példák:

• addUser( userName, password )

• addRole( roleName )

• getUsers()

• getUsersInRole( roleName )

A BAMAPI komponens

A Business Activity Monitoringot támogató le-kérdező API, amivel statisztikák és riportok iskészíthetőek az egyes munkafolyamatok műkö-déséről. Példák:

• getNumberOfOverdueSteps()

• getNumberOfOpenSteps()

• getNumberOfOpenStepsPerDay( startDate )

1 // 15−2. Programl i s ta : WEB−INF/ c l a s s e s / jaas−standard . c f g23 Bonita {4 org . ow2 . bonita . i d e n t i t y . auth . BonitaIdent ityLoginModule r equ i r ed ;5 org . ow2 . bonita . i d e n t i t y . auth . LocalStorageLoginModule r equ i r ed ;6 } ;78 BonitaAuth {9 org . ow2 . bonita . i d e n t i t y . auth . BonitaIdent ityLoginModule r equ i r ed ;10 } ;1112 BonitaStore {13 org . ow2 . bonita . i d e n t i t y . auth . LocalStorageLoginModule r equ i r ed ;14 } ;

134


Egy web alkalmazás és az API

A bemutatott példa web alkalmazás azt fogjamegtanítani nekünk, hogy a Bonita API-t ho-gyan érjük el, illetve néhány tipikus funkciót mi-lyen módon tudunk használni. Egyszerű JSPalapú programról van szó, ahol a kinézettel nemsokat törődtünk, a célunk az volt, hogy a forrás-program rövid legyen és lehetőleg csak azt mu-tassa be, hogy az API mit tud.

A használt hitelesítés és web.xml file

A 15-2. Programlista mutatja, hogy a hite-lesítéshez milyen tartalmú JAAS file-t (jaas-

standard.cfg) használtunk, illetve azt hova ér-demes elhelyezni. A Bonita által szállított alapLogin Modulokat konfiguráltuk be, amik az en-gine felé való hitelesítést biztosítják:

• BonitaIdentityLoginModule

• LocalStorageLoginModule

A 15-3. Programlista által mutatott web.xmlfile-t használja az alkalmazásunk, látható, hogyide semmilyen security információt nem tettünkbe, hiszen a JAAS-t akarjuk alkalmazni.

1 // 15−3. Prog raml i s t a : WEB−INF/web . xml23 <!DOCTYPE web−app PUBLIC4 "−//Sun␣Microsystems , ␣ Inc . //DTD␣Web␣Appl i ca t ion ␣ 2 .3//EN"5 " ht tp : // java . sun . com/dtd/web−app_2_3 . dtd" >67 <web−app>8 <disp lay−name>Bonita Appl i ca t ion</ di sp lay−name>910 <se s s i on−c on f i g>11 <se s s i on−t imeout>5</ se s s i on−t imeout>12 </ se s s i on−c on f i g>1314 <welcome− f i l e − l i s t id="WelcomeFileList ">15 <welcome− f i l e>index . j sp</welcome− f i l e>16 </welcome− f i l e − l i s t>1718 </web−app>

A bejelentkezés

A 15-3. Programlistán látható web.xml filewelcome-file tag-ja mutatja, hogy az alkalma-zásunk induló lapja a 15-4. Programlistán sze-replő index.jsp. Ez a lap egyszerű, a 15-27 sorokközött egy HTML form van, ami a username,password és submit gombokat tartalmazza és azactions/login.jsp akció van rákötve. Az msg pa-raméter a lap számára küldött információt hor-

dozza. A lap elején és végén a jsp:include egystandard fej (15-5. Programlista) és láblécet (15-6. Programlista) ad az oldalnak, de ez a példánkszempontjából nem is érdekes. Egyedül azt sze-retnénk csak megjegyezni, hogy itt azt a konven-ciót követtük, amit a Bonita is, amikor templatekinézetet vár tőlünk. Ami igazán izgalmas most,az az, hogy a username és password után mit csi-nál a login.jsp.

Nézzük is meg!

135


1 // 15−4. Programl i s ta : index . j sp f i l e tarta lma23 <%@page contentType=" text /html" pageEncoding="UTF−8"%>45 <%6 f i n a l String msg = reques t . getParameter ( "msg" ) ;7 %>8 <j sp : i n c lude page="header . html"/>9 <div align=’center ’>10 <h1>Bonita Appl i ca t ion</h1>11 <br><br>12 <%i f (msg != nu l l ) {%>13 <b><%=msg %></b><br><br>14 <%}%>15 <form name="form" method="get " action=" ac t i on s / l o g i n . j sp ">16 <table>17 <tr>18 <td align=" r i gh t ">Login</td>19 <td><input type=" text " name="username"></td>20 </ tr>21 <tr>22 <td align=" r i gh t ">Password</td>23 <td><input type="password" name="password"></td>24 </ tr>25 </ table>26 <input type="submit" name="Submit" value="Login" />27 </form>28 </div>29 <j sp : i n c lude page=" f o o t e r . html"/>

1 // 15−5. Programl i s ta : header . html f i l e tarta lma23 <!DOCTYPEHTML PUBLIC "−//W3C//DTD␣XHTML␣ 1 .0 ␣ S t r i c t //EN" "http ://www.w3 . org /TR/å

xhtml1/DTD/xhtml1−s t r i c t . dtd">4 <html dir=" l t r " xml : lang="en" xmlns="http ://www.w3 . org /1999/ xhtml" lang="en">5 <head>6 <meta http−equiv="Content−Type" content=" text /html ; ␣ cha r s e t=UTF−8å

"/>7 <meta name=" de s c r i p t i o n " content="Bonita ␣Forms␣Appl i ca t ion "/>8 <t i t l e>Bonita Appl i ca t ion</ t i t l e>9 <l ink href=" c s s /bonita_form_default . c s s " rel=" s t y l e s h e e t " type="å

t ex t / c s s "/>10 </head>11 <body class="bonita−body">12 <div id="bonita−pr i n c i pa l−conta iner−top"></div>13 <div id="bonita−pr i n c i pa l−conta iner−middle ">14 <div id="bonita−bonita−open−s o lu t i on−l ogo "></div>15 <div id="bonita−r i ght−corner−area ">16 <div id="bonita−i d e n t i f i c a t i o n −area ">17 <div id="bonita_logout_button" class="bonita_logout_button"><a å

href=" ac t i on s / logout . j sp ">Logout</a></div>

136


18 </div>19 </div>20 <div id="bonita_form">

1 // 15−6. Programl i s ta : f o o t e r . html f i l e tarta lma23 </div>4 </div>5 <div id="bonita−pr i n c i pa l−conta iner−bottom" class="bonita−f o o t e r "å

>Powered by BonitaSof t Team</div>6 </body>7 </html>

A login.jsp lap működése

Ez a jsp lap gyakorlatilag egy tiszta Java prog-ram (a kinézetét a 15.1. ábra mutatja), a 3-9 sorok között az importok vannak. A 13. és14. sorokban átvesszük az előző lapról kapottusername és password értékeket. A 17. sorbanegy erőforrásként töltjük be a jaas-standard.cfgfile-t, ami tényleg a CLASSPATH -on van, hi-szen a classes könyvtárba tettük. Sikeres eset-ben a jaasFile változó tartalmazza az erre a file-ra mutató URL-t. Mindez csak akkor fontos, haa BonitaConstants.JAAS_PROPERTY környe-zeti változó még nincs beállítva, amely esetbenez a 19. sorban megtörténik. A lényeg az, hogymire a 22. sorhoz érünk, ennek jó értékkel kellrendelkeznie, így az authLC security context-etebben a sorban létrehozhatjuk. A 23 és 24 sorlogin() és logout()-ja csak arra jó, hogy hibásbejelentkezés esetén egy exception tud dobódni,

így ha ezen túljutunk, akkor a BonitaAuth-talszemben sikeresen hitelesítettük magunkat. A26-27 sor storeLC security context-je a BonitaS-tore-ral szemben hitelesít, azonban a 30. sor lo-gout()-ja előtt egy nagyon fontos API művelet-hez szereztünk jogot, amennyiben idáig el tud-tunk jutni. Mi ez? A korábban már említettAccessorUtil class getManagementAPI() metó-dusával egy managementAPI példányt szerzünk(28. sor) és első dolgunk lesz (29. sor) annakmegvizsgálása, hogy van-e (az immár bejelent-kezett) a user-nek admin joga. A 32-33 sorok-ban a HTTP session-re rátesszük a bejelentke-zett user nevét és az admin jogosultság vizsgála-tának eredményét. A 35. sor az így előkészítettkörnyezetet használva a home.jsp-re irányít min-ket. Viszont hiba esetén (nem tudtunk bejelent-kezni) az index.jsp-re dob vissza az alkalmazás.Nézzük tehát a következő állomást, az home.jsplapot!

1 // 15−7. Programl i s ta : a c t i on s / l o g i n . j sp f i l e tarta lma23 <%@ page import="org . ow2 . bonita . u t i l . BonitaConstants " %>4 <%@ page import="org . ow2 . bonita . u t i l . Misc"%>5 <%@ page import="org . ow2 . bonita . u t i l . S impleCal lbackHandler "%>6 <%@ page import=" javax . s e c u r i t y . auth . l o g i n . LoginContext "%>7 <%@ page import=" java . net .URL"%>8 <%@ page import="org . ow2 . bonita . facade .ManagementAPI"%>9 <%@ page import="org . ow2 . bonita . u t i l . Acce s so rUt i l "%>1011 <%12 try {

137


13 f i n a l String username = reques t . getParameter ( "username" ) ;14 f i n a l String password = reques t . getParameter ( "password" ) ;1516 i f ( System . getProperty ( BonitaConstants .JAAS_PROPERTY) == nu l l ) {17 f i n a l URL j a a sF i l e = t h i s . g e tC la s s ( ) . getClassLoader ( ) . getResource ( " jaas−å

standard . c f g " ) ;18 i f ( j a a sF i l e != nu l l ) {19 System . se tProper ty ( BonitaConstants .JAAS_PROPERTY, j a a sF i l e . toURI ( ) . getPathå

( ) ) ;20 }21 }22 f i n a l LoginContext authLC = new LoginContext ( "BonitaAuth" , new å

SimpleCal lbackHandler ( username , password ) ) ;23 authLC . l o g i n ( ) ;24 authLC . logout ( ) ;2526 f i n a l LoginContext storeLC = new LoginContext ( "BonitaStore " , new å

SimpleCal lbackHandler ( username , password ) ) ;27 storeLC . l o g i n ( ) ;28 f i n a l ManagementAPI managementAPI = Acce s so rUt i l . getManagementAPI ( ) ;29 f i n a l Boolean isAdmin =new Boolean (managementAPI . isUserAdmin ( username ) ) ;30 storeLC . logout ( ) ;3132 reques t . g e tS e s s i on ( ) . s e tAt t r i bu t e ( "username" , username ) ;33 r eques t . g e tS e s s i on ( ) . s e tAt t r i bu t e ( " isadmin" , isAdmin ) ;3435 response . sendRedi rect ( " . . / home . j sp " ) ;36 } catch ( Exception e ) {37 e . pr intStackTrace ( ) ;38 Throwable t = e ;39 whi l e ( t . getCause ( ) != nu l l ) {40 t = t . getCause ( ) ;41 }42 f i n a l String msg = "Unable␣ to ␣ l o g i n : ␣" + t . getMessage ( ) ;43 re sponse . sendRedi rect ( " . . / index . j sp ?msg=" + msg) ;44 }45 %>

15.1. ábra. A login.jsp lap

A home.jsp lap működése

A lap kinézetét a 15.2. ábra mutatja, ami a 15-8. Programlista alapján állt elő. A 18. sorigcsak Java importok vannak. A 21-23 sorok kö-zött történik egy vizsgálat arra nézve, hogy azeddigiek beállították-e a user objektumot a httpsession-re. Amennyiben nem, úgy nincs jobbmegoldás, szolgáltatni kell a bejelentkeztetésrealkalmas index.jsp lapot. Sikeres továbblépésesetén azt is megvizsgáljuk, hogy most admin

138


joggal használják-e ezt az alkalmazást. A 33-35sorok között 3 üres listát hozunk létre: ready-TaskList, doneTaskList, enabledProcesses. Ha a37-38 sorok login() ellenőrzésén túl tudunk jutni,akkor az API-t használva feltöltjük ezeket a lis-tákat, majd a 47. sorban (logout()) kilépünk asecurity context-ből. A megszerzett információkmegjelenítéséről szól a lap további része, ezt lát-juk az ábrán is. Nem okoz itt már gondot, hogya logout() lefutott, hiszen az engine-től egyelőretöbb információt nem is várunk. Láthatjuk a39. sortól, ahogy a különféle API komponense-ket (esetünkben a QueryRuntimeAPI, QueryDe-finitionAPI) milyen egyszerűen el tudjuk érni éshasználni a prcess intsance-októl egészen a task-ok szintjéig lemenve. A továbbiakban ismerte-tett jsp lapok (intstances.jsp, processes.jsp, task-Details.jsp) a most felépített felületen lévő lin-kekről hívhatóak, nézzük meg őket is!

15.2. ábra. A home.jsp lap

1 // 15−8. Programl i s ta : home . j sp f i l e tarta lma23 <%@ page import=" javax . s e c u r i t y . auth . l o g i n . LoginContext "%>4 <%@ page import="org . ow2 . bonita . facade . QueryRuntimeAPI"%>5 <%@ page import="org . ow2 . bonita . l i g h t . L i gh tPro c e s sDe f i n i t i on "%>6 <%@page import="org . ow2 . bonita . facade . de f . majorElement . P r o c e s sDe f i n i t i on "%>7 <%@ page import="org . ow2 . bonita . facade . uuid . ProcessDef init ionUUID"%>8 <%@ page import="org . ow2 . bonita . u t i l . Acce s so rUt i l "%>9 <%@ page import="org . ow2 . bonita . u t i l . S impleCal lbackHandler "%>10 <%@page import=" java . u t i l . L i s t "%>11 <%@page import=" java . u t i l . Co l l e c t i o n s "%>12 <%@page import="org . ow2 . bonita . facade . runtime . Ac t i v i t yS ta t e "%>13 <%@page import="org . ow2 . bonita . l i g h t . LightTaskInstance "%>14 <%@page import=" java . u t i l . Co l l e c t i on "%>15 <%@page import="org . ow2 . bonita . facade . uuid . ActivityInstanceUUID"%>16 <%@page import="org . ow2 . bonita . facade . QueryDefinit ionAPI "%>17 <%@page import="org . ow2 . bonita . facade . de f . majorElement . P r o c e s sDe f i n i t i on .å

Proce s sState "%>18 <%@page import=" java . u t i l . Set "%>1920 <%21 f i n a l Object usernameObject = reques t . g e tS e s s i on ( ) . g e tAt t r ibute ( "username" ) ;22 i f ( usernameObject == nu l l ) {23 response . sendRedi rect ( " index . j sp " ) ;24 }25 f i n a l String username = (String ) usernameObject ;2627 f i n a l Object isAdminObject = reque s t . g e tS e s s i on ( ) . g e tAt t r ibute ( " isadmin" ) ;

139


28 f i n a l boolean isAdmin = isAdminObject != nu l l && ( ( Boolean ) isAdminObject ) .åbooleanValue ( ) ;

29 f i n a l String msg = reques t . getParameter ( "msg" ) ;303132 f i n a l i n t numberOfElementsToRetrive = 20 ;33 Co l l e c t i on<LightTaskInstance> readyTaskList = Co l l e c t i o n s . emptyList ( ) ;34 Co l l e c t i on<LightTaskInstance> doneTaskList = Co l l e c t i o n s . emptyList ( ) ;35 Set<L i gh tPro c e s sDe f i n i t i on> enab l edProce s se s = Co l l e c t i o n s . emptySet ( ) ;36 t ry {37 f i n a l LoginContext log inContext = new LoginContext ( "BonitaStore " , new å

SimpleCal lbackHandler ( username , "" ) ) ;38 log inContext . l o g i n ( ) ;39 f i n a l QueryRuntimeAPI queryRuntimeAPI = Acce s so rUt i l . getQueryRuntimeAPI ( ) ;40 f i n a l QueryDefinit ionAPI queryDef in i t ionAPI = Acce s so rUt i l .å

getQueryDef in it ionAPI ( ) ;4142 readyTaskList = queryRuntimeAPI . getL ightTaskLi s t ( Ac t i v i t yS ta t e .READY) ;43 doneTaskList = queryRuntimeAPI . getL ightTaskLi s t ( Ac t i v i t yS ta t e . FINISHED) ;4445 enab l edProce s se s = queryDef in i t ionAPI . g e tL i gh tProce s s e s ( P r o c e s sDe f i n i t i on .å

Proce s sState .ENABLED) ;4647 log inContext . l ogout ( ) ;48 } catch ( Exception e ) {49 e . pr intStackTrace ( ) ;50 Throwable t = e ;51 whi l e ( t . getCause ( ) != nu l l ) {52 t = t . getCause ( ) ;53 }54 f i n a l S t r ing errorMsg = "Error ␣whi l e ␣ l i s t i n g ␣ ta sk s : ␣" + t . getMessage ( ) ;55 re sponse . sendRedi rect ( " index . j sp ?msg=" + errorMsg ) ;56 }57 %>5859 <j sp : i n c lude page="header . html"/>6061 <br><br>62 <%i f (msg != nu l l ) {%>63 <b><%=msg %></b><br><br>64 <%}%>6566 <TABLE BORDER="1" CELLPADDING="10" WIDTH="600px">67 <CAPTION>Li s t o f ta sk s to perform</CAPTION>68 <TR>69 <TH>Name</TH>70 <TH>Process</TH>71 <TH>Actions</TH>72 </TR>7374 <%75 for ( LightTaskInstance task : readyTaskList ) {

140


76 f i n a l String label = task . getDynamicLabel ( ) != nu l l ? task . getDynamicLabel ( ) : åtask . g e tAct i v i tyLabe l ( ) ;

77 f i n a l String name = task . getActivityName ( ) ;78 f i n a l String d i sp l ay = label != nu l l ? label : name ;79 f i n a l ActivityInstanceUUID taskUUID = task . getUUID ( ) ;80 f i n a l ProcessDef init ionUUID processUUID = task . getProcessDef in i t ionUUID ( ) ;81 %>82 <TR>83 <TD><%=di sp l ay %></TD>84 <TD><%=processUUID %></TD>85 <TD><a href=" ta skDe t a i l s . j sp ?taskUUID=<%=taskUUID␣%>">Deta i l s</a></TD>86 </TR>87 <%}%>88 </TABLE>8990 <BR><BR>9192 <TABLE BORDER="1" CELLPADDING="10" WIDTH="600px">93 <CAPTION>Li s t o f done ta sk s</CAPTION>94 <TR>95 <TH>Name</TH>96 <TH>Process</TH>97 <TH>Actions</TH>98 </TR>99100 <%101 for ( LightTaskInstance task : doneTaskList ) {102 f i n a l String label = task . getDynamicLabel ( ) != nu l l ? task . getDynamicLabel ( ) : å

task . g e tAct i v i tyLabe l ( ) ;103 f i n a l String name = task . getActivityName ( ) ;104 f i n a l String d i sp l ay = label != nu l l ? label : name ;105 f i n a l ActivityInstanceUUID taskUUID = task . getUUID ( ) ;106 f i n a l ProcessDef init ionUUID processUUID = task . getProcessDef in i t ionUUID ( ) ;107 %>108 <TR>109 <TD><%=di sp l ay %></TD>110 <TD><%=processUUID %></TD>111 <TD><a href=" ta skDe t a i l s . j sp ?taskUUID=<%=taskUUID␣%>">Deta i l s</a></TD>112 </TR>113 <%}%>114 </TABLE>115 <BR><BR>116117 <TABLE BORDER="1" CELLPADDING="10" WIDTH="600px">118 <CAPTION>Li s t o f p r o c e s s e s</CAPTION>119 <TR>120 <TH>Name</TH>121 <TH>Vers ion</TH>122 <TH>Actions</TH>123 </TR>124125 <%

141


126 for ( L i gh tPro c e s sDe f i n i t i on proce s s : enab l edProce s se s ) {127 f i n a l ProcessDef init ionUUID processUUID = proce s s . getUUID ( ) ;128 %>129 <TR>130 <TD><%=proce s s . getLabe l ( ) %></TD>131 <TD align=" cente r "><%=proce s s . getVers ion ( ) %></TD>132 <TD>133 <a href=" ac t i on s / ap iCa l l . j s p ? ac t i on=c r ea t e In s t an c e&back=home&processUUID=<%=å

processUUID␣%>">Create a new in s tance</a> &nbsp ;134 </TD>135 </TR>136 <%}%>137 </TABLE>138139 <br><br>140 <%i f ( isAdmin ) {%>141 <a href=" pro c e s s e s . j sp ">Manage p r o c e s s e s</a> &nbsp ;142 <a href=" in s t an c e s . j sp ">Manage i n s t an c e s</a> &nbsp ;143 <%}%>144145 <j sp : i n c lude page=" f o o t e r . html"/>

Az apiCall.jsp lap szerepe

A további 3 funkcionális jsp lap ismertetése előttnézzük meg a actions/apiCall.jsp lapot, mert ezegy közös utility gyűjtemény a számukra, ezenkeresztül használják a Bonita API-t (15-9. Prog-ramlista). A 26. sorig a már ismert előkészítő so-rokat láthatjuk, azonban a 26-35 sorok között 2nagyon érdekes, általánosan is használható tech-nikát látunk, erre szeretnénk felhívni a figyelmet.A 26. sor back változója egy olyan jsp lap ne-vét tudja átvenni a kérést kezdeményező laptól,ahova az üzleti logika lefutása után a 167. sorbanvissza tudjuk irányítani a válaszlap küldést. Itttehát a működés az, hogy egy lap hívja ezt azapiCall.jsp lapot egy back paraméterrel, ahova

a választ vissza lehet redirect-álni, természete-sen az üzleti logika eredményével felszerelve. Amásik érdekesség, hogy a 31. sorban lekért ac-tion paraméter vezérli azt, hogy az apiCall.jsplap melyik részét kívánjuk használni. Az 52-54sorok között a már ismert módon bejelentkezünka security contex-be, hogy jogunk legyen az APIhasználatára. A sok lehetséges action közül ittmost nézzük az 56-62 sorok közötti archivePro-cess-t (a többit mindenki nézze meg, mert mind-egyikből sokat lehet tanulni). Az 58. sorból lát-ható, hogy ekkor egy processUUID paraméterreis számítunk a HTTP session-ről. A 60-61 sorok-ban a ManagementAPI segítségével archiváljukennek a processUUID azonosítójú processnek azadatait.

1 // 15−9. Programl i s ta : a c t i on s / ap iCa l l . j s p f i l e tarta lma23 <%@page import="org . ow2 . bonita . facade . uuid . ActivityInstanceUUID"%>4 <%@page import="org . ow2 . bonita . u t i l . Bus inessArchiveFactory "%>5 <%@page import="org . ow2 . bonita . facade . de f . majorElement . P r o c e s sDe f i n i t i on "%>6 <%@page import="org . ow2 . bonita . facade . de f . e lement . Bus inessArchive "%>7 <%@page import=" java . i o . FileNotFoundException"%>8 <%@page import=" java . i o . F i l e "%>

142


9 <%@page import="org . ow2 . bonita . facade . uuid . ProcessInstanceUUID"%>10 <%@page import="org . ow2 . bonita . facade . RuntimeAPI"%>11 <%@page import=" java . u t i l . HashSet"%>12 <%@page import=" java . u t i l . Set "%>13 <%@ page import=" javax . s e c u r i t y . auth . l o g i n . LoginContext "%>1415 <%@ page import="org . ow2 . bonita . facade .ManagementAPI"%>16 <%@ page import="org . ow2 . bonita . facade . uuid . ProcessDef init ionUUID"%>17 <%@ page import="org . ow2 . bonita . u t i l . Acce s so rUt i l "%>18 <%@ page import="org . ow2 . bonita . u t i l . S impleCal lbackHandler "%>1920 <%21 f i n a l Object isAdminObject = reque s t . g e tS e s s i on ( ) . g e tAt t r ibute ( " isadmin" ) ;22 boolean isAdmin = f a l s e ;23 i f ( isAdminObject != nu l l && ( ( Boolean ) isAdminObject ) . booleanValue ( ) ) {24 isAdmin = true ;25 }26 f i n a l String back = reques t . getParameter ( "back" ) ;27 i f ( back == nu l l ) {28 response . sendRedi rect ( " . . / home . j sp ?msg=No␣ return ␣page␣was␣ s p e c i f i e d " ) ;29 }3031 f i n a l String action = reques t . getParameter ( " ac t i on " ) ;3233 i f ( action == nu l l ) {34 response . sendRedi rect ( " . . / " + back + " . j sp ?msg=Null ␣ ac t i on " ) ;35 }36 f i n a l Set<String> adminOnlyActions = new HashSet<String>() ;37 adminOnlyActions . add ( " a r ch iveProce s s " ) ;38 adminOnlyActions . add ( " canc e l I n s t anc e " ) ;39 adminOnlyActions . add ( " d e l e t e I n s t an c e " ) ;40 adminOnlyActions . add ( " de l e t eP ro c e s s " ) ;41 adminOnlyActions . add ( " dep loyProcess " ) ;42 adminOnlyActions . add ( " d i s ab l eP ro c e s s " ) ;43 adminOnlyActions . add ( " enab leProces s " ) ;4445 i f ( ! isAdmin && adminOnlyActions . conta in s ( ac t i on ) ) {46 response . sendRedi rect ( " . . / home . j sp " ) ;47 }4849 St r ing msg = nu l l ;50 St r ing errorMsg = nu l l ;51 t ry {52 f i n a l S t r ing username = ( St r ing ) r eque s t . g e tS e s s i on ( ) . g e tAt t r ibute ( "username"å

) ;53 f i n a l LoginContext log inContext = new LoginContext ( "BonitaStore " , new å

SimpleCal lbackHandler ( username , "" ) ) ;54 log inContext . l o g i n ( ) ;5556 i f ( " a r ch iveProce s s " . equa l s ( ac t i on ) ) {5758 f i n a l S t r ing processUUID = reques t . getParameter ( "processUUID" ) ;

143


59 errorMsg = "Error ␣whi l e ␣ a r ch iv ing ␣ proce s s ␣with␣uuid␣" + processUUID ;60 f i n a l ManagementAPI managementAPI = Acce s so rUt i l . getManagementAPI ( ) ;61 managementAPI . a r ch ive (new ProcessDef init ionUUID ( processUUID ) ) ;62 msg = "Process ␣" + processUUID + "␣ s u c c e s s f u l l y ␣ arch ived . " ;6364 } e l s e i f ( " canc e l I n s t anc e " . equa l s ( a c t i on ) ) {6566 f i n a l S t r ing instanceUUID = reques t . getParameter ( " instanceUUID" ) ;67 errorMsg = "Error ␣whi l e ␣ canc e l i ng ␣ in s t anc e ␣with␣uuid␣" + instanceUUID ;68 f i n a l RuntimeAPI runtimeAPI = Acce s so rUt i l . getRuntimeAPI ( ) ;69 runtimeAPI . c ance lP roc e s s In s t anc e (new ProcessInstanceUUID ( instanceUUID ) ) ;70 msg = " Ins tance ␣" + instanceUUID + "␣was␣ s u c c e s s f u l l y ␣ cance l ed . " ;7172 } e l s e i f ( " c r e a t e In s t an c e " . equa l s ( ac t i on ) ) {7374 f i n a l S t r ing processUUID = reques t . getParameter ( "processUUID" ) ;75 errorMsg = "Error ␣whi l e ␣ c r e a t i n g ␣a␣new␣ in s t ance ␣ o f ␣ proce s s ␣with␣uuid␣" + å

processUUID ;76 f i n a l RuntimeAPI runtimeAPI = Acce s so rUt i l . getRuntimeAPI ( ) ;77 f i n a l ProcessInstanceUUID instanceUUID = runtimeAPI . i n s t an t i a t eP r o c e s s (new å

ProcessDef init ionUUID ( processUUID ) ) ;78 msg = "A␣new␣ in s tance ␣ o f ␣ proce s s ␣" + processUUID + "␣was␣ s u c c e s s f u l l y ␣å

c rea ted : ␣" + instanceUUID ;7980 } e l s e i f ( " d e l e t e I n s t an c e " . equa l s ( ac t i on ) ) {8182 f i n a l S t r ing instanceUUID = reques t . getParameter ( " instanceUUID" ) ;83 errorMsg = "Error ␣whi l e ␣ d e l e t e i n g ␣ in s t anc e ␣with␣uuid␣" + instanceUUID ;84 f i n a l RuntimeAPI runtimeAPI = Acce s so rUt i l . getRuntimeAPI ( ) ;85 runtimeAPI . d e l e t eP ro c e s s I n s t an c e (new ProcessInstanceUUID ( instanceUUID ) ) ;86 msg = " Ins tance ␣" + instanceUUID + "␣was␣ s u c c e s s f u l l y ␣ de l e t ed . " ;8788 } e l s e i f ( " d e l e t eP ro c e s s " . equa l s ( ac t i on ) ) {8990 f i n a l S t r ing processUUID = reques t . getParameter ( "processUUID" ) ;91 errorMsg = "Error ␣whi l e ␣ d e l e t i n g ␣ proce s s ␣with␣uuid␣" + processUUID ;92 f i n a l ManagementAPI managementAPI = Acce s so rUt i l . getManagementAPI ( ) ;93 managementAPI . d e l e t eP ro c e s s (new ProcessDef init ionUUID ( processUUID ) ) ;94 msg = "Process ␣" + processUUID + "␣ s u c c e s s f u l l y ␣ de l e t ed . " ;9596 } e l s e i f ( " dep loyProcess " . equa l s ( a c t i on ) ) {9798 f i n a l S t r ing ba rF i l e = reque s t . getParameter ( " ba rF i l e " ) ;99 errorMsg = "Error ␣whi l e ␣ dep loy ing ␣ f i l e ␣" + barF i l e ;100 f i n a l ManagementAPI managementAPI = Acce s so rUt i l . getManagementAPI ( ) ;101 f i n a l F i l e f i l e = new F i l e ( ba rF i l e ) ;102 i f ( ! f i l e . e x i s t s ( ) ) {103 throw new FileNotFoundException ( ba rF i l e ) ;104 }105 f i n a l Bus inessArchive bus ines sArch ive = Bus inessArchiveFactory .å

getBus ines sArch ive ( f i l e ) ;106 f i n a l P r o c e s sDe f i n i t i on proce s s = managementAPI . deploy ( bus ines sArch ive ) ;

144


107 msg = "Process ␣" + proce s s . getUUID ( ) + "␣ s u c c e s s f u l l y ␣ deployed . " ;108109 } e l s e i f ( " d i s ab l eP ro c e s s " . equa l s ( ac t i on ) ) {110111 f i n a l S t r ing processUUID = reques t . getParameter ( "processUUID" ) ;112 errorMsg = "Error ␣whi l e ␣ d i s a b e l i n g ␣ proce s s ␣with␣uuid␣" + processUUID ;113 f i n a l ManagementAPI managementAPI = Acce s so rUt i l . getManagementAPI ( ) ;114 managementAPI . d i s a b l e (new ProcessDef init ionUUID ( processUUID ) ) ;115 msg = "Process ␣" + processUUID + "␣ s u c c e s s f u l l y ␣ d i s ab l ed . " ;116117 } e l s e i f ( " enab l eProces s " . equa l s ( ac t i on ) ) {118119 f i n a l S t r ing processUUID = reques t . getParameter ( "processUUID" ) ;120 errorMsg = "Error ␣whi l e ␣ enabe l ing ␣ proce s s ␣with␣uuid␣" + processUUID ;121 f i n a l ManagementAPI managementAPI = Acce s so rUt i l . getManagementAPI ( ) ;122 managementAPI . enable (new ProcessDef init ionUUID ( processUUID ) ) ;123 msg = "Process ␣" + processUUID + "␣ s u c c e s s f u l l y ␣ enabled . " ;124125 } e l s e i f ( " executeTask " . equa l s ( ac t i on ) ) {126127 f i n a l S t r ing taskUUID = reques t . getParameter ( "taskUUID" ) ;128 errorMsg = "Error ␣whi l e ␣ execut ing ␣ task ␣with␣uuid␣" + taskUUID ;129 f i n a l RuntimeAPI runtimeAPI = Acce s so rUt i l . getRuntimeAPI ( ) ;130 runtimeAPI . executeTask (new ActivityInstanceUUID ( taskUUID) , t rue ) ;131 msg = "Task␣" + taskUUID + "␣was␣ s u c c e s s f u l l y ␣ executed . " ;132133 } e l s e i f ( " s e tAc t i v i t yVa r i ab l e " . equa l s ( ac t i on ) ) {134135 f i n a l S t r ing taskUUID = reques t . getParameter ( "taskUUID" ) ;136 f i n a l S t r ing variableName = reques t . getParameter ( "variableName" ) ;137 f i n a l S t r ing var iab l eVa lue = reques t . getParameter ( " var iab l eVa lue " ) ;138 errorMsg = "Error ␣whi l e ␣ updating ␣ va r i ab l e ␣with␣name␣" + variableName + "␣å

and␣ value ␣" + var iab l eVa lue + "␣on␣ task ␣" + taskUUID ;139 f i n a l RuntimeAPI runtimeAPI = Acce s so rUt i l . getRuntimeAPI ( ) ;140 runtimeAPI . s e tAc t i v i t y In s t an c eVa r i ab l e (new ActivityInstanceUUID ( taskUUID) , å

variableName , var iab l eVa lue ) ;141 msg = "Var iab le ␣" + variableName + "␣was␣ s u c c e s s f u l l y ␣updated␣with␣ value ␣" å

+ var iab l eVa lue + "␣on␣ task ␣" + taskUUID + " . " ;142143 } e l s e i f ( " s e tProc e s sVar i ab l e " . equa l s ( a c t i on ) ) {144145 f i n a l S t r ing instanceUUID = reques t . getParameter ( " instanceUUID" ) ;146 f i n a l S t r ing variableName = reques t . getParameter ( "variableName" ) ;147 f i n a l S t r ing var iab l eVa lue = reques t . getParameter ( " var iab l eVa lue " ) ;148 errorMsg = "Error ␣whi l e ␣ updating ␣ va r i ab l e ␣with␣name␣" + variableName + "␣å

and␣ value ␣" + var iab l eVa lue + "␣on␣ in s t anc e ␣" + instanceUUID ;149 f i n a l RuntimeAPI runtimeAPI = Acce s so rUt i l . getRuntimeAPI ( ) ;150 runtimeAPI . s e tPro c e s s In s t anc eVar i ab l e (new ProcessInstanceUUID ( instanceUUID )å

, variableName , var iab l eVa lue ) ;151 msg = "Var iab le ␣" + variableName + "␣was␣ s u c c e s s f u l l y ␣updated␣with␣ value ␣" å

+ var iab l eVa lue + "␣on␣ in s t ance ␣" + instanceUUID + " . " ;152

145


153 } e l s e {154 response . sendRedirect ( " . . / " + back + " . j sp ?msg=Unknown␣ ac t i on : ␣" + act i on ) ;155 }156157158 log inContext . l ogout ( ) ;159 } catch ( Exception e ) {160 e . pr intStackTrace ( ) ;161 Throwable t = e ;162 whi l e ( t . getCause ( ) != nu l l ) {163 t = t . getCause ( ) ;164 }165 msg = errorMsg + " : ␣" + t . getMessage ( ) ;166 }167 response . sendRedi rect ( " . . / " + back + " . j sp ?msg=" + msg) ;168 %>

1 // 15−10. Programl i s ta : a c t i on s / logout . j sp f i l e tarta lma23 <%4 reques t . g e tS e s s i on ( ) . removeAttr ibute ( "username" ) ;5 r eques t . g e tS e s s i on ( ) . removeAttr ibute ( " isadmin" ) ;6 re sponse . sendRedirect ( " . . / index . j sp " ) ;7 %>

A további jsp lapok

A web alkalmazás további lapjai különféle funk-ciókat biztosítanak a felhasználó számára:

• taskDetails.jsp (15-13. Programlista, 15.3.ábra): A kiválasztott feladat részleteit te-kinthetjük meg, illetve, ha a task aktív,akkor azt változtathatjuk is.

• processes.jsp (15-11. Programlista, 15.4.ábra): A folyamat mintákat tekinthetjükmeg, illetve itt új folyamatot is létrehozha-tunk, létezőt letilthatunk (azaz nem hoz-ható létre ebből új instance) vagy törölhe-tünk. Ez az oldal még egy új Bonita folya-mat (*.bar file) telepítését is támogatja.

• instances.jsp (15-12. Programlista, 15.5.ábra): A folyamat példányok böngészésétés menedzselését segíti.

15.3. ábra. A taskDetails.jsp lap kinézete

146


15.4. ábra. A processes.jsp lap kinézete 15.5. ábra. Az instances.jsp lap kinézete

1 // 15−11. Programl i s ta : p r o c e s s e s . j sp f i l e tarta lma23 <%@ page import=" javax . s e c u r i t y . auth . l o g i n . LoginContext "%>4 <%@ page import="org . ow2 . bonita . facade . QueryDefinit ionAPI "%>5 <%@ page import="org . ow2 . bonita . l i g h t . L i gh tPro c e s sDe f i n i t i on "%>6 <%@page import="org . ow2 . bonita . facade . de f . majorElement . P r o c e s sDe f i n i t i on "%>7 <%@ page import="org . ow2 . bonita . facade . uuid . ProcessDef init ionUUID"%>8 <%@ page import="org . ow2 . bonita . u t i l . Acce s so rUt i l "%>9 <%@ page import="org . ow2 . bonita . u t i l . S impleCal lbackHandler "%>10 <%@page import=" java . u t i l . L i s t "%>11 <%@page import=" java . u t i l . Co l l e c t i o n s "%>1213 <%14 f i n a l Object isAdmin = reques t . g e tS e s s i on ( ) . g e tAt t r ibute ( " isadmin" ) ;15 i f ( isAdmin == nu l l | | ! ( ( Boolean ) isAdmin ) . booleanValue ( ) ) {16 response . sendRedi rect ( "home . j sp " ) ;17 }1819 f i n a l String msg = reques t . getParameter ( "msg" ) ;2021 f i n a l i n t numberOfElementsToRetrive = 20 ;22 Lis t<L i gh tPro c e s sDe f i n i t i on> jou rna lP ro c e s s e s = Co l l e c t i o n s . emptyList ( ) ;23 L i s t<L i gh tPro c e s sDe f i n i t i on> h i s t o r yPro c e s s e s = Co l l e c t i o n s . emptyList ( ) ;24 t ry {25 f i n a l S t r ing username = ( St r ing ) r eques t . g e tS e s s i on ( ) . g e tAt t r ibute ( "username" ) ;26 f i n a l LoginContext log inContext = new LoginContext ( "BonitaStore " , new å

SimpleCal lbackHandler ( username , "" ) ) ;27 log inContext . l o g i n ( ) ;28 f i n a l QueryDefinit ionAPI journa lQueryDef in i t ionAPI = Acce s so rUt i l .å

147


getQueryDef in it ionAPI ( Acce s so rUt i l .QUERYLIST_JOURNAL_KEY) ;29 f i n a l QueryDefinit ionAPI hi s toryQueryDef in i t ionAPI = Acce s so rUt i l .å

getQueryDef in it ionAPI ( Acce s so rUt i l .QUERYLIST_HISTORY_KEY) ;3031 j ou rna lP ro c e s s e s = journa lQueryDef in i t ionAPI . g e tL i gh tProce s s e s (0 , å

numberOfElementsToRetrive ) ;32 h i s t o r yP ro c e s s e s = his toryQueryDef in i t ionAPI . g e tL i gh tProce s s e s (0 , å

numberOfElementsToRetrive ) ;3334 log inContext . l ogout ( ) ;35 } catch ( Exception e ) {36 e . pr intStackTrace ( ) ;37 Throwable t = e ;38 whi l e ( t . getCause ( ) != nu l l ) {39 t = t . getCause ( ) ;40 }41 f i n a l S t r ing errorMsg = "Error ␣whi l e ␣ l i s t i n g ␣ p r o c e s s e s : ␣" + t . getMessage ( ) ;42 re sponse . sendRedi rect ( "home . j sp ?msg=" + errorMsg ) ;43 }44 %>454647 <j sp : i n c lude page="header . html"/>48 <br><br>4950 <%i f (msg != nu l l ) {%>51 <b><%=msg %></b><br><br>52 <%}%>5354 <form name=’deploy ’ method=’get ’ action=’ ac t i on s / ap iCa l l . j sp ’><br>55 Path to . bar f i l e &nbsp ;56 <input type=’text ’ name=’barFi l e ’>57 <input type=’hidden ’ name=’back ’ value=’ proce s s e s ’>58 <input type=’hidden ’ name=’action ’ value=’deployProcess ’>59 <input type=’submit ’ name=’deploy ’ value=’Deploy ’ >60 </form>61 <br>62 <br>6364 <TABLE BORDER="1" CELLPADDING="10" WIDTH="600px">65 <CAPTION>Li s t o f j ou rna l p r o c e s s e s (max : <%=numberOfElementsToRetrive %>)</å

CAPTION>66 <TR>67 <TH>Name</TH>68 <TH>Vers ion</TH>69 <TH>Actions</TH>70 </TR>7172 <%73 for ( L i gh tPro c e s sDe f i n i t i on proce s s : j ou rna lP ro c e s s e s ) {74 f i n a l ProcessDef init ionUUID processUUID = proce s s . getUUID ( ) ;75 f i n a l P r o c e s sDe f i n i t i on . Proce s sSta te s t a t e = proce s s . g e tS ta t e ( ) ;

148


76 boolean isEnabled = true ;77 i f ( P r o c e s sDe f i n i t i on . Proce s sState .DISABLED. equa l s ( s t a t e ) ) {78 isEnabled = f a l s e ;79 }80 %>81 <TR>82 <TD><%=proce s s . getLabe l ( ) %></TD>83 <TD align=" cente r "><%=proce s s . getVers ion ( ) %></TD>84 <TD>85 <% i f ( i sEnabled ) { %>86 <a href=" ac t i on s / ap iCa l l . j s p ? ac t i on=c r ea t e In s t an c e&back=pro c e s s e s&processUUIDå

=<%=processUUID␣%>">Create a new in s tance</a>  &nbsp ;87 <a href=" ac t i on s / ap iCa l l . j s p ? ac t i on=d i s ab l eP ro c e s s&back=pro c e s s e s&processUUIDå

=<%=processUUID␣%>">Disab le</a>  &nbsp ;88 <%} e l s e {%>89 <a href=" ac t i on s / ap iCa l l . j s p ? ac t i on=enab leProces s&back=pro c e s s e s&processUUIDå

=<%=processUUID␣%>">Enable</a>  &nbsp ;90 <a href=" ac t i on s / ap iCa l l . j s p ? ac t i on=arch iveProce s s&back=pro c e s s e s&processUUIDå

=<%=processUUID␣%>">Archive</a>  &nbsp ;91 <%}%>92 <a href=" ac t i on s / ap iCa l l . j s p ? ac t i on=de l e t eP ro c e s s&back=pro c e s s e s&processUUIDå

=<%=processUUID␣%>">Delete</a>  &nbsp ;93 </TD>94 </TR>95 <%}%>96 </TABLE>9798 <br><br>99 <TABLE BORDER="1" CELLPADDING="10" WIDTH="600px">100 <CAPTION>Li s t o f h i s t o r y p r o c e s s e s (max : <%=numberOfElementsToRetrive %>)</å

CAPTION>101 <TR>102 <TH>Name</TH>103 <TH>Vers ion</TH>104 <TH>Actions</TH>105 </TR>106107 <%108 for ( L i gh tPro c e s sDe f i n i t i on proce s s : h i s t o r yPro c e s s e s ) {109 f i n a l ProcessDef init ionUUID processUUID = proce s s . getUUID ( ) ;110 %>111112 <TR>113 <TD><%=proce s s . getLabe l ( ) %></TD>114 <TD align=" cente r "><%=proce s s . getVers ion ( ) %></TD>115 <TD>116 <a href=" ac t i on s / ap iCa l l . j s p ? ac t i on=de l e t eP ro c e s s&back=pro c e s s e s&processUUID=<%=å

processUUID␣%>">Delete</a>  &nbsp ;117 </TD>118 </TR>119 <%}%>120 </TABLE>

149


121 <br><br>122 <a href="home . j sp ">Home</a> &nbsp ;123 <a href=" in s t an c e s . j sp ">Manage i n s t an c e s</a> &nbsp ;124125 <j sp : i n c lude page=" f o o t e r . html"/>

1 // 15−12. Programl i s ta : i n s t an c e s . j sp f i l e tarta lma23 <%@ page import=" javax . s e c u r i t y . auth . l o g i n . LoginContext "%>45 <%@ page import="org . ow2 . bonita . facade . QueryRuntimeAPI"%>6 <%@ page import="org . ow2 . bonita . l i g h t . L ightProce s s In s tance "%>7 <%@ page import="org . ow2 . bonita . facade . uuid . ProcessDef init ionUUID"%>8 <%@page import="org . ow2 . bonita . facade . uuid . ProcessInstanceUUID"%>9 <%@ page import="org . ow2 . bonita . u t i l . Acce s so rUt i l "%>10 <%@ page import="org . ow2 . bonita . u t i l . S impleCal lbackHandler "%>11 <%@page import=" java . u t i l . L i s t "%>12 <%@page import=" java . u t i l . Co l l e c t i o n s "%>1314 <%15 f i n a l Object isAdmin = reques t . g e tS e s s i on ( ) . g e tAt t r ibute ( " isadmin" ) ;16 i f ( isAdmin == nu l l | | ! ( ( Boolean ) isAdmin ) . booleanValue ( ) ) {17 response . sendRedi rect ( "home . j sp " ) ;18 }1920 f i n a l String msg = reques t . getParameter ( "msg" ) ;2122 f i n a l i n t numberOfElementsToRetrive = 20 ;23 Lis t<LightProce s s In s tance> j ou rna l I n s t an c e s = Co l l e c t i o n s . emptyList ( ) ;24 L i s t<LightProce s s In s tance> h i s t o r y I n s t an c e s = Co l l e c t i o n s . emptyList ( ) ;25 t ry {26 f i n a l S t r ing username = ( St r ing ) r eques t . g e tS e s s i on ( ) . g e tAt t r ibute ( "username" ) ;27 f i n a l LoginContext log inContext = new LoginContext ( "BonitaStore " , new å

SimpleCal lbackHandler ( username , "" ) ) ;28 log inContext . l o g i n ( ) ;29 f i n a l QueryRuntimeAPI journalQueryRuntimeAPI = Acce s so rUt i l . getQueryRuntimeAPI (å

Acce s so rUt i l .QUERYLIST_JOURNAL_KEY) ;30 f i n a l QueryRuntimeAPI historyQueryRuntimeAPI = Acce s so rUt i l . getQueryRuntimeAPI (å

Acce s so rUt i l .QUERYLIST_HISTORY_KEY) ;3132 j ou rna l I n s t an c e s = journalQueryRuntimeAPI . g e tL i gh tProc e s s In s t ance s (0 , å

numberOfElementsToRetrive ) ;33 h i s t o r y I n s t an c e s = historyQueryRuntimeAPI . g e tL i gh tProc e s s In s t ance s (0 , å

numberOfElementsToRetrive ) ;3435 log inContext . l ogout ( ) ;36 } catch ( Exception e ) {37 e . pr intStackTrace ( ) ;38 Throwable t = e ;39 whi l e ( t . getCause ( ) != nu l l ) {40 t = t . getCause ( ) ;

150


41 }42 f i n a l S t r ing errorMsg = "Error ␣whi l e ␣ l i s t i n g ␣ i n s t an c e s : ␣" + t . getMessage ( ) ;43 re sponse . sendRedi rect ( "home . j sp ?msg=" + errorMsg ) ;44 }45 %>46474849 <j sp : i n c lude page="header . html"/>5051 <br><br>5253 <%i f (msg != nu l l ) {%>54 <b><%=msg %></b><br><br>55 <%}%>5657 <TABLE BORDER="1" CELLPADDING="10" WIDTH="600px">58 <CAPTION>Li s t o f j ou rna l i n s t an c e s (max : <%=numberOfElementsToRetrive %>)</å

CAPTION>59 <TR>60 <TH>Name</TH>61 <TH>Vers ion</TH>62 <TH>Instance number</TH>63 <TH>Actions</TH>64 </TR>6566 <%67 for ( L ightProce s s In s tance in s t anc e : j ou rna l I n s t an c e s ) {68 f i n a l ProcessInstanceUUID instanceUUID = in s tance . getUUID ( ) ;69 f i n a l ProcessDef init ionUUID processUUID = in s tance . getProcessDef in i t ionUUID ( ) ;70 f i n a l String processName = processUUID . getProcessName ( ) ;71 f i n a l String proce s sVer s i on = processUUID . ge tProce s sVer s i on ( ) ;72 f i n a l long instanceNb = instanceUUID . getInstanceNb ( ) ;73 %>74 <TR>75 <TD><%=processName %></TD>76 <TD align=" cente r "><%=proce s sVer s i on %></TD>77 <TD align=" cente r "><%=instanceNb %></TD>78 <TD>79 <a href=" ac t i on s / ap iCa l l . j s p ? ac t i on=cance l I n s t anc e&back=in s t an c e s&instanceUUIDå

=<%=instanceUUID␣%>">Cancel</a>&nbsp ;80 <a href=" ac t i on s / ap iCa l l . j s p ? ac t i on=de l e t e I n s t an c e&back=in s t an c e s&instanceUUIDå

=<%=instanceUUID␣%>">Delete</a>&nbsp ;81 </TD>82 </TR>83 <%}%>84 </TABLE>8586 <br><br>87 <TABLE BORDER="1" CELLPADDING="10" WIDTH="600px">88 <CAPTION>Li s t o f h i s t o r y i n s t an c e s (max : <%=numberOfElementsToRetrive %>)</å

CAPTION>

151


89 <TR>90 <TH>Name</TH>91 <TH>Vers ion</TH>92 <TH>Instance number</TH>93 <TH>Actions</TH>94 </TR>95 <%96 for ( L ightProce s s In s tance in s t anc e : h i s t o r y I n s t an c e s ) {97 f i n a l ProcessInstanceUUID instanceUUID = in s tance . getUUID ( ) ;98 f i n a l ProcessDef init ionUUID processUUID = in s tance . getProcessDef in i t ionUUID ( ) ;99 f i n a l String processName = processUUID . getProcessName ( ) ;100 f i n a l String proce s sVer s i on = processUUID . ge tProce s sVer s i on ( ) ;101 f i n a l long instanceNb = instanceUUID . getInstanceNb ( ) ;102 %>103 <TR>104 <TD><%=processName %></TD>105 <TD align=" cente r "><%=proce s sVer s i on %></TD>106 <TD align=" cente r "><%=instanceNb %></TD>107 <TD>108 <a href=" ac t i on s / ap iCa l l . j s p ? ac t i on=de l e t e I n s t an c e&back=in s t an c e s&instanceUUIDå

=<%=instanceUUID␣%>">Delete</a>&nbsp ;109 </TD>110 </TR>111 <%}%>112 </TABLE>113114 <br><br>115 <a href="home . j sp ">Home</a> &nbsp ;116 <a href=" pro c e s s e s . j sp ">Manage p r o c e s s e s</a> &nbsp ;117118 <j sp : i n c lude page=" f o o t e r . html"/>

1 // 15−13. Programl i s ta : t a s kDe t a i l s . j sp f i l e tarta lma23 <%@page import="org . ow2 . bonita . facade . uuid . ActivityInstanceUUID"%>4 <%@ page import=" javax . s e c u r i t y . auth . l o g i n . LoginContext "%>5 <%@ page import="org . ow2 . bonita . facade . QueryRuntimeAPI"%>6 <%@ page import="org . ow2 . bonita . facade . uuid . ProcessInstanceUUID"%>7 <%@ page import="org . ow2 . bonita . u t i l . Acce s so rUt i l "%>8 <%@ page import="org . ow2 . bonita . u t i l . S impleCal lbackHandler "%>9 <%@page import="org . ow2 . bonita . facade . runtime . TaskInstance "%>10 <%@page import=" java . u t i l . Co l l e c t i o n s "%>11 <%@page import=" java . u t i l .Map"%>12 <%@page import="org . ow2 . bonita . facade . de f . majorElement . A c t i v i t yDe f i n i t i o n "%>13 <%@page import="org . ow2 . bonita . facade . QueryDefinit ionAPI "%>14 <%@page import=" java . u t i l . Set "%>15 <%@page import="org . ow2 . bonita . facade . de f . majorElement . DataF i e ldDe f in i t i on "%>16 <%@page import=" java . u t i l . HashMap"%>17 <%@page import="org . ow2 . bonita . facade . runtime . Ac t i v i t yS ta t e "%>1819 <%

152


20 f i n a l Object isAdminObject = reque s t . g e tS e s s i on ( ) . g e tAt t r ibute ( " isadmin" ) ;21 f i n a l boolean isAdmin = isAdminObject != nu l l && ( ( Boolean ) isAdminObject ) .å

booleanValue ( ) ;2223 f i n a l String taskUUID = reques t . getParameter ( "taskUUID" ) ;24 f i n a l String msg = reques t . getParameter ( "msg" ) ;25 TaskInstance task = nu l l ;26 ProcessInstanceUUID instanceUUID = nu l l ;27 Map<String , String> loca lDa ta f i e l d sType s = new HashMap<String , String>() ;28 Map<String , String> globa lData f i e ld sType s = new HashMap<String , String>() ;29 Map<String , Object> lo c a lVa r i a b l e s = Co l l e c t i o n s . emptyMap ( ) ;30 Map<String , Object> g loba lVa r i ab l e s = Co l l e c t i o n s . emptyMap ( ) ;31 St r ing cand idate s = "" ;32 boolean isReady = f a l s e ;3334 try {35 f i n a l S t r ing username = ( St r ing ) r eques t . g e tS e s s i on ( ) . g e tAt t r ibute ( "username" ) ;36 f i n a l LoginContext log inContext = new LoginContext ( "BonitaStore " , new å

SimpleCal lbackHandler ( username , "" ) ) ;37 log inContext . l o g i n ( ) ;3839 f i n a l ActivityInstanceUUID act iv i tyInstanceUUID = new ActivityInstanceUUID (å

taskUUID) ;40 instanceUUID = act iv i tyInstanceUUID . getProcessInstanceUUID ( ) ;4142 f i n a l QueryRuntimeAPI queryRuntimeAPI = Acce s so rUt i l . getQueryRuntimeAPI ( ) ;43 f i n a l QueryDefinit ionAPI queryDef in i t ionAPI = Acce s so rUt i l .å

getQueryDef in it ionAPI ( ) ;4445 task = queryRuntimeAPI . getTask ( act iv i tyInstanceUUID ) ;46 isReady = Act i v i t yS ta t e .READY. equa l s ( task . ge tS ta t e ( ) ) ;47 l o c a lVa r i a b l e s = task . getLastKnownVariableValues ( ) ;48 i f ( ! task . getTaskCandidates ( ) . isEmpty ( ) ) {49 f o r ( S t r ing candidate : task . getTaskCandidates ( ) ) {50 cand idate s += candidate + " , " ;51 }52 cand idate s = cand idate s . sub s t r i ng (0 , cand idates . l ength ( ) − 1) ;53 }5455 g l oba lVa r i ab l e s = queryRuntimeAPI . g e tProc e s s In s t anc eVar i ab l e s ( instanceUUID ) ;5657 f i n a l Ac t i v i t yDe f i n i t i o n a c t i v i t yD e f i n i t i o n = queryDef in i t ionAPI .å

ge tProc e s sAc t i v i t y ( instanceUUID . getProcessDef in i t ionUUID ( ) , åact iv i tyInstanceUUID . getActivityName ( ) ) ;

58 f i n a l Set<DataF i e ldDe f in i t i on> l o c a lD a t a f i e l d s = a c t i v i t yD e f i n i t i o n .ågetDataFie lds ( ) ;

59 f o r ( DataF i e ldDe f in i t i on da t aF i e l dDe f i n i t i on : l o c a lD a t a f i e l d s ) {60 l o ca lDa ta f i e l d sType s . put ( da t aF i e l dDe f i n i t i on . getName ( ) , d a t aF i e l dDe f i n i t i on .å

getDataTypeClassName ( ) ) ;61 }6263 f i n a l Set<DataF i e ldDe f in i t i on> g l ob a lDa t a f i e l d s = queryDef in i t ionAPI .å

153


getProces sDataFie lds ( a c t i v i t yD e f i n i t i o n . getProcessDef in i t ionUUID ( ) ) ;64 f o r ( DataF i e ldDe f in i t i on da t aF i e l dDe f i n i t i on : g l o b a lDa t a f i e l d s ) {65 g l oba lData f i e l d sType s . put ( da t aF i e l dDe f i n i t i on . getName ( ) , d a t aF i e l dDe f i n i t i on .å

getDataTypeClassName ( ) ) ;66 }6768 log inContext . l ogout ( ) ;69 } catch ( Exception e ) {70 e . pr intStackTrace ( ) ;71 Throwable t = e ;72 whi l e ( t . getCause ( ) != nu l l ) {73 t = t . getCause ( ) ;74 }75 f i n a l S t r ing errorMsg = "Error ␣whi l e ␣ g e t t i n g ␣ d e t a i l s ␣ o f ␣ task ␣with␣uuid␣" + å

taskUUID + " : ␣" + t . getMessage ( ) ;76 re sponse . sendRedi rect ( "home . j sp ?msg=" + errorMsg ) ;77 }78 %>798081 <j sp : i n c lude page="header . html"/>82 <br><br>8384 <%i f (msg != nu l l ) {%>85 <b><%=msg %></b><br><br>86 <%}%>8788 <TABLE BORDER="1" CELLPADDING="5" WIDTH="600px">89 <CAPTION>Task p r op e r t i e s</CAPTION>90 <TR>91 <TH>Name</TH>92 <TH>Value</TH>93 </TR>9495 <TR><TD>Name</TD><TD><%=task . getActivityName ( ) %></TD></TR>96 <TR><TD>Label</TD><TD><%=task . g e tAct i v i tyLabe l ( ) %></TD></TR>97 <TR><TD>Dynamic l a b e l</TD><TD><%=task . getDynamicLabel ( ) %></TD></TR>98 <TR><TD>Desc r ip t i on</TD><TD><%=task . g e tAc t i v i t yDe s c r i p t i on ( ) %></TD></TR>99 <TR><TD>Dynamic l a b e l</TD><TD><%=task . getDynamicDescr ipt ion ( ) %></TD></TR>100 <TR><TD>Creat ion date</TD><TD><%=task . getCreatedDate ( ) %></TD></TR>101 <TR><TD>Ready date</TD><TD><%=task . getReadyDate ( ) %></TD></TR>102 <TR><TD>Started date</TD><TD><%=task . getStartedDate ( ) %></TD></TR>103 <TR><TD>Started by</TD><TD><%=task . getStartedBy ( ) %></TD></TR>104 <TR><TD>Ended date</TD><TD><%=task . getEndedDate ( ) %></TD></TR>105 <TR><TD>Started by</TD><TD><%=task . getEndedBy ( ) %></TD></TR>106 <TR><TD>Expected end date</TD><TD><%=task . getExpectedEndDate ( ) %></TD></TR>107 <TR><TD>Pr i o r i t y</TD><TD><%=task . g e tP r i o r i t y ( ) %></TD></TR>108 <TR><TD>State</TD><TD><%=task . ge tS ta t e ( ) %></TD></TR>109 <TR><TD>Assigned user</TD><TD><%=task . getTaskUser ( ) %></TD></TR>110 <TR><TD>Candidates</TD><TD><%=cand idates %></TD></TR>111 <TR><TD>Task UUID</TD><TD><%=task . getUUID ( )%></TD></TR>112 <TR><TD>Proce s s In s tance UUID</TD><TD><%=task . getProcessInstanceUUID ( )%></TD></TR>

154


113 <TR><TD>Proc e s sDe f i n i t i on UUID</TD><TD><%=task . getProcessDef in i t ionUUID ( )%></TD><å/TR>

114 <TR><TD>Ac t i v i t yDe f i n i t i o n UUID</TD><TD><%=task . getAct iv i tyDef in i t ionUUID ( )%></TDå></TR>

115116 </TABLE>117118 <br><br>119 <TABLE BORDER="1" CELLPADDING="10" WIDTH="600px">120 <CAPTION>Li s t o f l o c a l v a r i a b l e s</CAPTION>121 <TR>122 <TH>Name</TH>123 <TH>Value</TH>124 <TH>Type</TH>125 <TH>Action</TH>126 </TR>127128 <%129 for (Map. Entry<String , Object> va r i ab l e : l o c a lVa r i a b l e s . entrySet ( ) ) {130 f i n a l S t r ing variableName = va r i ab l e . getKey ( ) ;131 f i n a l Object var iab l eVa lue = va r i ab l e . getValue ( ) ;132 f i n a l S t r ing type = lo ca lDa ta f i e l d sType s . get ( variableName ) ;133 %>134 <TR>135 <TD><%=variableName %></TD>136 <TD><%=var iab l eVa lue %></TD>137 <TD><%=type %></TD>138 <TD>139140 <%i f ( isReady ) {%>141 <form name=’updateVariable_local_<%=variableName %> ’ method=’get ’ a c t i on=’å

a c t i on s / ap iCa l l . j sp ’>142 <input type=’text ’ name=’var iab leValue ’>143 <input type=’hidden ’ name=’back ’ value=’home ’>144 <input type=’hidden ’ name=’variableName ’ value=’<%=variableName %>’>145 <input type=’hidden ’ name=’taskUUID ’ value=’<%=taskUUID %>’>146 <input type=’hidden ’ name=’action ’ value=’ s e tAc t i v i t yVar i ab l e ’>147 <input type=’submit ’ name=’update ’ value=’update ’ >148 </form>149 <%}%>150 </TD>151 </TR>152 <%}%>153 </TABLE>154155 <br><br>156 <TABLE BORDER="1" CELLPADDING="10" WIDTH="600px">157 <CAPTION>Li s t o f g l oba l v a r i a b l e s</CAPTION>158 <TR>159 <TH>Name</TH>160 <TH>Value</TH>161 <TH>Type</TH>

155


162 <TH>Action</TH>163 </TR>164 <%165 for (Map. Entry<String , Object> va r i ab l e : g l oba lVa r i ab l e s . entrySet ( ) ) {166 f i n a l S t r ing variableName = va r i ab l e . getKey ( ) ;167 f i n a l Object var iab l eVa lue = va r i ab l e . getValue ( ) ;168 f i n a l S t r ing type = g loba lData f i e l d sTypes . get ( variableName ) ;169 %>170 <TR>171 <TD><%=variableName %></TD>172 <TD><%=var iab l eVa lue %></TD>173 <TD><%=type %></TD>174 <TD>175 <%i f ( isReady ) {%>176 <form name=’updateVariable_global_<%=variableName %> ’ method=’get ’ a c t i on=’å

a c t i on s / ap iCa l l . j sp ’>177 <input type=’text ’ name=’var iab leValue ’>178 <input type=’hidden ’ name=’back ’ value=’home ’>179 <input type=’hidden ’ name=’variableName ’ value=’<%=variableName %>’>180 <input type=’hidden ’ name=’instanceUUID ’ value=’<%=instanceUUID %>’>181 <input type=’hidden ’ name=’action ’ value=’ se tProce s sVar i ab l e ’>182 <input type=’submit ’ name=’update ’ value=’update ’ >183 </form>184 <%}%>185 </TD>186 </TR>187188 <%}%>189 </TABLE>190 <br><br>191 <%i f ( isReady ) {%>192 <a href=" ac t i on s / ap iCa l l . j s p ? ac t i on=executeTask&back=home&taskUUID=<%=taskUUID␣å

%>">Execute t h i s task</a>&nbsp ;193 <%}%>194195196 <br><br>197 <a href="home . j sp ">Home</a> &nbsp ;198 <%i f ( isAdmin ) {%>199 <a href=" pro c e s s e s . j sp ">Manage p r o c e s s e s</a> &nbsp ;200 <a href=" in s t an c e s . j sp ">Manage i n s t an c e s</a> &nbsp ;201 <%}%>202203 <j sp : i n c lude page=" f o o t e r . html"/>

156