BPM prakticky

8. část: Business Rules I.

2008-08-02T17:20:00.006+02:00

Petr Vašíček, IBA CZ

V nadcházejících dvou dílech se budeme zabývat tzv. business rules (též business pravidla nebo pravidla podnikání). V prvním z těchto dvou článků si stanovíme úsek v našem modelovém příkladě, který budeme transformovat na business pravidlo. Podíváme se také, jaké nástroje můžeme se zvoleným běhovým prostředím použít a vybereme z nich vhodného kandidáta podle našich potřeb.

Úvod do Business Rules

Business rules neboli pravidla podnikání jsou deklarativně definované příkazy tvaru „JESTLIŽE je splněna určitá podmínka TAK udělej určenou akci“. V nejčastěji uváděném příkladě se určuje míra slevy podle platební historie či typu zákazníka, pravidla je však možno použít v zásadě jakémkoliv případě, kde je potřeba nějaké rozhodnutí, ať již jde o pravidlo validační (jsou vstupní údaje validní?) či transformační (pokud vyhovují zadané podmínce, proveď následující operaci).

Business pravidla jsou typicky seskupována do množin (Business Ruleset). Například pro proces příjímání nového zaměstnance a rozhodování o typu HW, který mu bude přidělen, může množina pravidel (ruleset) obsahovat pravidla jako „pokud je administrativní pracovník, dostane pracovní stanici“, „pokud je programátor a zároveň jeho pozice je senior developer, dostane notebook“ apod.

Business pravidla tedy pokrývají určitá rozhodnutí, jež jsou součástí procesu. Business procesy se čas od času mohou měnit – ať již na základě požadavku na faktickou změnu v procesu, či jeho optimalizací na základě výsledků monitorování. Tento proces (návrh změny, validace, aktualizace modelu, implementace, testování, nasazení) však bývá poměrně zdlouhavý, přitom business pravidla jsou dynamičtější než samotný proces a v určitých případech se jejich zadání může měnit velice často. Namísto jejich deklarace přímo v procesu se tedy vyplatí uchovávat je v externím repozitáři, ke kterému proces přistupuje prostřednictvím nějakého nástroje. Ten umožňuje přijmout vstupní data, načíst z repozitáře příslušná pravidla, ty vyhodnotit a výsledek zaslat zpět. Tento nástroj se nazývá Business Rules Engine (BRE).

Ilustrace 1: Architektura BRMS

Pro integraci v SOA je potřeba aby Business Rules Engine umožňoval vystavit business pravidla jako webové služby a nepostradatelná je i webová administrace, jež umožní okamžitou změnu pravidel a je přehledná i pro netechnické pracovníky. Tento pokročilejší systém se nazývá BRMS (Business Rules Management systém) a bývá obvykle součástí pokročilejších BPMS.

Trendem při modelování business procesu je právě transformovat všechna místa, jež by mohla být předmětem změny, do business pravidel. To umožní flexibilní změnu chování procesu bez nutnosti jeho znovunasazení. Samotná změna pravidla pak obnáší pouze přenastavení potřebných parametrů a nasazení pravidla, což je obvykle záležitostí jednoho kliknutí. Změna se projeví okamžitě a všechny instance procesů, co od té chvíle projdou rozhodovacím bodem, se budou řídit novým nastavením.

Pravidla pracují s různými objekty a atributy, které se vyskytují v business procesu a je obvykle možné navázat je i na okolní prostředí, jako datum, čas, dny v týdnu, organizační struktura ve firmě apod.

Limit schvalování žádosti

Vraťme se nyní k našemu příkladu schvalování žádostí a zaměřme se na okamžik rozhodování, kdy se podle ceny objednávky určí, zda ji bude po technickém oddělení schvalovat i finanční ředitel. Prahová hodnota (tzv. threshold) je nastavena na 40.000 Kč. Tato hodnota může typicky být předmětem změny. Finanční ředitel bude chtít například nastavit, že chce schvalovat již objednávky nad 20 tisíc Kč. Nebo naopak může (například díky monitorování) vyjít najevo, že poměrně velká část objednávek se pohybuje těsně nad hranicí 40 tisíc Kč. V takovém případě může finanční ředitel naznat, že při zvýšení limitu na 45 tisíc Kč dojde k výraznému snížení jeho práce na objednávkách a také zrychlení procesu schvalování objednávek. Přitom riziko, že firma nevhodně vydá prostředky pro nákup zboží, vzroste jen nepatrně.

Ilustrace 2: Výsek BPMN diagramu s rozhodováním o ceně objednávky

Hraniční hodnota ceny objednávky může tedy být často se měnící veličina v našem procesu. Pokud bychom chtěli tuto hodnotu změnit, museli bychom otevřít vývojové prostředí, příslušný BPEL projekt, provést změnu v BPEL kódu, validovat jeho správnost a provést deploy do běhového prostředí. To s sebou nese riziko chybně provedené změny, problémy při znovunasazení procesu či nekompatibilitu s již běžícími instancemi staré verze procesu. Navíc to není typ úkonu, který očekáváme u netechnického pracovníka. Řešením tedy bude umístit rozhodovací bod mimo proces a transformovat jej do business pravidla, což umožní jeho flexibilní změnu v reálném čase.

Výběr vhodného nástroje

Do našeho BPMS můžeme integrovat takřka jakýkoliv systém pro správu business pravidel, otázkou je pouze kolik úsilí chceme na tuto integraci vynaložit. I kdybychom vzali jednoduchý engine, který bude schopen vyhodnocovat pravidla na základě nějakého vstupu, není nijak velký problém napsat pro něj vlastní prezentační vrstvu a konektory pro webové služby, aby mohl pravidla využívat i proces zapsaný v jazyce WS-BPEL. Nic nebrání ani vytvoření vlastního BRE. Rozhodně je však lepší vzít nějaký již osvědčený produkt, kterých je na poli open source několik.

OpenRules

Jedním z těchto je OpenRules, jenž používá jako základní nástroj pro zadávání dat Excel. Jedná se o jednoduché prostředí s krátkou dobou potřebnou pro jeho zvládnutí. Pravidla jsou v OpenRules definována v rozhodovacích tabulkách, jenž jsou dobře zpracované a přehledné, nicméně problém může nastat se specifikací komplexnějších pravidel. Rovněž není zajištěna podpora databází, tu je třeba si případně doimplementovat. Také absence webového rozhraní by vyžadovala větší pracnost při integraci v našem řešení.

OpenLexicon

Dalším, a velmi populárním, open source nástrojem pro řízení business pravidel je OpenLexicon. Ten poskytuje přehledné webové rozhraní pro správu pravidel a jejich množin, zorientuje se v něm poměrně snadno i netechnický uživatel. Upravení pravidla má okamžitou platnost bez nutnosti rekompilace, což bývá často považováno za stěžejní funkci. Co se týče využití systému pro externí aplikaci, nabízí OpenLexicon přístup přes webovou službu.

Drools

Jako poslední variantu si uvedeme Drools, což je nástroj pro business pravidla od Jboss. Drools poskytuje pokročilý editor pravidel na bázi Eclipse, nabízí ovšem i velice dobře vypadající webové rozhraní pro editaci a tvorbu nových pravidel. Webová aplikace je doporučena k nasazení na JBoss AS, ale fungovat by měla na kterémkoliv aplikačním serveru či servletovém kontejneru. Největším problémem Drools při nasazení do SOA architektury je problematičtější vystavování pravidel jako webových služeb. To je třeba nyní dělat manuálně, automatické vystavení webové služby pro nové pravidlo je plánováno do budoucna.
Vhodné varianty z tohoto krátkého přehledu jsou dvě. Jednou z nich je OpenLexicon, jehož použití si ovšem necháme na pokračování seriálu s Intalio BPMS a zvolíme druhou možnost, kterou je Drools. To má o něco přívětivější uživatelské rozhraní, jediné co budeme muset řešit navíc je jakýsi prostředník, který jednotlivá pravidla zpřístupní přes operace webové služby. To z důvodu, abychom mohli k pravidlům přistupovat z BPEL procesu. Vytvoření tohoto prostředníka ale není nic složitého, navíc získáme lepší kontrolu nad komunikací s BRMS, můžeme operaci volat pouze s parametry, které budeme opravdu potřebovat apod.

Ilustrace 3: Ukázka prostředí Drools BRMS

Implementaci tohoto „prostředníka“ detailně popisovat nebudeme, jedná se o jednoduchou webovou službu, která jednoduše přijme vstup s parametry pro dané pravidlo, získá od Drools balíček s tímto pravidlem a pomocí jednoduché funkce, kterou Drools poskytuje, pravidlo s příslušnými vstupními hodnotami vyhodnotí a výsledek vrátí jako odpověď.

V příštím díle

V následujícím díle si ukážeme, jak vytvořit ve zvoleném nástroji požadované pravidlo a jak nástroj pro podporu business rules do systému zakomponovat, abychom mohli toto pravidlo používat. Jak se změna v reálném čase provádí ukážeme opět pomocí přehledného video screencastu. Podíváme se také, jak lze přizpůsobit vizuální stránku editace pravidel do již existující enterprise aplikace.

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

2008-06-20T14:11:00.004+02:00

Petr Vašíček, IBA CZ

V tomto díle si ukážeme, jak proces, jež jsme implementovali v posledním díle, otestovat a jaké možnosti skýtá jeho ladění (debugging). Dále představíme webovou aplikaci, pomocí které může uživatel s procesem interagovat. Projdeme si také různé scénáře životního cyklu objednávky a vysvětlíme si, jaké události při nich v procesu probíhají.

Testování procesu

Abychom mohli proces otestovat, musíme jej nejprve nasadit na server. Jak již bylo popsáno dříve, BPEL modul je přidán do tzv. kompozitní aplikace (souhrný projekt, skládající se z jednoho či více modulů), která je následně nasazena do běhového prostředí. Pro založení aplikace vybereme v prostředí NetBeans „New Project -> Service Oriented Architecture -> Composite Application“, zvolíme název (například „OrderingCA“) a dokončíme. Do kompozitní aplikace vložíme hotový BPEL modul pomocí „Add JBI Module...“, vše ostatní se již provede za nás. Z kontextového menu projektu pak vybereme „Deploy“ pro nasazení na aplikační server Glassfish. Pokud nechcete kompozitní aplikaci vytvářet, můžete si ji jako kompletní projekt stáhnout z této adresy. Jsou v ní obsaženy i všechny testy, bude ovšem zřejmě nutné specifikovat v nastavení cestu k umístění BPEL modulu, pokud nebudou oba projekty ve stejném adresáři.

Nyní již můžeme vytvořit testy. Proces má celkem tři vstupní operace, budou nám tedy stačit tři testy. V každém z nich definujeme vstup do dané operace pomocí SOAP zpráv v XML formátu a požadovaný výstup, podle kterého se zkontroluje skutečný výstup, který nám testovaná operace vrátí. Pokud se výstupy shodují, je test vyhodnocen jako úspěšný. Musíme mít však na paměti, že u operace, která nám pokaždé vrátí jinou zprávu (například naše operace createOrder vrací identifikátor nově založené objednávky, který je pochopitelně vždy jiný), se výstupy shodovat nebudou a výsledek operace tak musíme zkontrolovat sami.
Při vytvoření testu je připravena vstupní zpráva, do které doplníme požadované hodnoty. Při testování operace createOrder vyplníme identifikátor osoby, která objednávku zakládá, identifikátor položky a kvantitu. Příklad vyplněné vstupní zprávy lze vidět na následujícím obrázku:

Pokud tento test spustíme, je vytvořena objednávka na zboží s identifikátorem „1“ - notebook. Objednatelem je v tomto případě Jan Novák (identifikátor „1“ v tabulce uživatelů) a zboží je objednáno v množství dvou kusů. Odpověď na tuto zprávu obsahuje jediný parametr, a to sice identifikátor nově vytvořené objednávky. Výstupní SOAP zpráva tedy vypadá takto:

Podobně vytvoříme testy i na zbylé dvě operace, techDecide a findirDecide. V obou případech vyplníme ve vstupní zprávě identifikátor objednávky a typ rozhodnutí (approve/decline) a ve výstupní zprávě je pouze příznak zpracování požadavku, pravdivostní hodnota „true“. Otestování jednoho scénáře procesu tak může vypadat následovně:

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

Ladění procesu

Ladění procesu (tzv. debugging) nám poskytne cenné informace o běhu procesu a umožňuje jednoduše vystopovat a lokalizovat chyby, které v něm nastávají. Pomocí debuggingu můžeme proces postupně „odkrokovat“ a zjistit jak se chová, kterou větví prochází apod. Rovněž máme přístup k proměnným, které jsou v procesu použity a můžeme sledovat, jak se v nich mění hodnoty po provedení různých akcí.

Ilustrace 1: Ladění BPEL procesu v NetBeans IDE

V prostředí NetBeans můžeme ladění využít, pokud jsme nastartovali server v debuggovacím módu a připojili BPEL debugger (pomocí „Attach debugger“). Do procesu zaznačíme body přerušení (tzv. breakpoints), na kterých se nám proces automaticky zastaví. Při spuštění procesu, ať už testováním nebo standardní cestou přes klientskou aplikaci, je pak umožněno jeho ladění. Pokud proces projde bodem přerušení, je jeho tok pozastaven dokud uživatel neprovede nějakou akci. Touto akcí může být pokračování běhu (resume) nebo posunutí k dalšímu kroku (step). V okamžiku, kdy je proces přerušen jej můžeme podle potřeby zkoumat, např. prohlížet hodnoty v proměnných. To je zvláště přínosné při testování (i neúplného) procesu, lokalizaci chyb a podobných činnostech.

Klientská aplikace

Poslední ze základních komponent systému, která nám chybí, je klientská aplikace. Ta podle zásad SOA přistupuje k funkcionalitě backendu a procesu přes webové služby. Ve skutečnosti aplikace nepozná, zda se za webovou službou skrývá BPEL, modul v Javě nebo jinak zapsaná business logika. Díky tomu je například možné zaměnit implementaci služby za jinou, aniž bychom museli provádět rozsáhlejší změny v klientské aplikaci (tedy za předpokladu, že zachováme rozhraní této služby). Klientská aplikace může být buďto desktopová (tlustý klient) nebo častěji webová (tenký klient). Díky univerzálnímu přístupu přes webové služby může být naprogramována v libovolném jazyce. Vhodným řešením pro firemní webovou aplikaci postavenou na principech BPM a SOA může být například portál.

Nyní se vraťme k našemu příkladu. Abyste si proces založení objednávky mohli vyzkoušet v praxi, připravili jsme pro vás jednoduchou webovou aplikaci, jež využívá webové služby vystavené procesem a backendem. Stáhnout si ji můžete opět z této adresy. Při instalaci postupujte podobně jako v případě backendového modulu – ve webové administrační konzoli vyberete záložku Web Applications, zvolte Deploy, zadejte cestu k souboru OrderingWeb.war a potvrďte.

Aplikace umožňuje proklikat základní scénáře s vytvořením objednávky a následným schválením či zamítnutím uživatele systému z technického oddělení, popřípadě finančním ředitelem, pokud je objednávka na zboží nad 40.000 a projde prvním schvalovacím krokem. Při provedení nějaké akce je zavolána webová služba, kterou implementuje BPEL, je provedena sekvence činností definovaných v procesu a je zaslána odpověď zpět klientovi. Jak práce s webovou aplikací probíhá a co se děje během ní v procesu je názorně zachyceno na videu, které můžete shlédnout na této adrese.

Ilustrace 2: Náhled video prezentace webové aplikace

V systému jsou připraveni tři uživatelé:

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

Na videu probíhá scénář, kdy uživatel Jan Novák objedná 6 ks LCD monitorů o celkové ceně 60.000 Kč. Následně se přihlásí do systému Jiří Technik jako zástupce technického oddělení. V seznamu objednávek ke schválení vidí novou objednávku a nechá ji schválit. Proces pak postupuje přes rozhodovací bod, kdy je cena objednávky porovnána s částkou 40.000 Kč. Jelikož je objednávka dražší, je předána k rozhodnutí finančnímu řediteli. Ten se přihlásí, nechá objednávku schválit a tím je objednávka označena za schválenou.

Scénáře běhu procesu

Pojďme se nyní podívat blíže na to, co probíhá v životním cyklu procesu. V následující tabulce můžete vidět posloupnost operací které probíhají v jednotlivých komponentách systému při výše popsaném scénáři. Každá komponenta vlevo vždy volá operaci komponenty v tabulce napravo od ní. V závorce za popisem akce je uveden název této operace:

Uvažujme nyní odlišný scénář – technické oddělení ve druhém kroku objednávku zamítne. Posloupnost operací je tedy stejná až do kroku č. 6. V sedmém kroku vyhodnotí proces objednávku jako zamítnutou a proběhne tedy posloupnost kroků:

7. BPEL: Vyhodnocení rozhodnutí – zamítnuto
8. BPEL: Změna stavu objednávky na DISPPROVED (setOrderState)
9. Backend: Nastavení stavu objednávky v DB

Nyní si vezmeme ještě třetí variantu scénáře – objednávka je pouze na 3 ks LCD monitorů a její celková cena je tedy 30.000 Kč. Posloupnost bude nyní stejná jako v prvním případě až do kroku č. 9, po kterém dojde k odlišnému vyhodnocení podmínky, týkající se ceny objednávky. Posloupnost kroků tedy proběhne následovně:
10. BPEL: Vyhodnocení ceny objednávky – pod 40.000 Kč
11. BPEL: Změna stavu objednávky na APPROVED (setOrderState)
12. Backend: Nastavení stavu objednávky v DB

V příštím díle

Příště se budeme zabývat tzv. business rules (též business pravidla nebo pravidla podnikání). Podíváme se, jaké nástroje například můžeme se zvoleným běhovým prostředím použít a ukážeme si, jak nástroj pro podporu business rules do systému zakomponovat. Součástí bude opět krátké video, které ukáže změnu pravidla v našem procesu a to, jak se změna při procházení scénáře projeví.

6. část: Implementace procesu v BPEL

2008-05-23T11:58:00.004+02:00

Petr Vašíček, IBA CZ

V tomto díle si nejprve představíme backendovou část aplikace, která obsahuje funkcionalitu pro práci s objednávkami. Ukážeme si pro představu diagram tříd a rozhraní webové služby, kterou tento modul poskytuje. Uvedeme instrukce pro stažení a deploy backendového modulu na aplikační server, abychom webovou službu mohli využít z business procesu.

Ve druhé části rozdělíme BPMN proces založení objednávky do několika úseků, které následně převedeme do jazyka BPEL. Nebudeme se zabývat přílišnými detaily při implementaci procesu ani si uvádět návod jak přesně tento konkrétní proces v prostředí NetBeans „naklikat“, místo toho nastíníme obecný postup při tvorbě BPEL dokumentu z BPMN modelu, jak vše napojit na webové služby a úspěšně nasadit a spustit v aplikačním serveru. BPEL modul i kompozitní aplikaci samozřejmě nabídneme ke stažení, abyste si mohli příklad vyzkoušet v praxi.

Tento díl je již hodně o IT, BPEL a programování v Java EE. Podle ohlasů na předchozí díly se dá očekávat, že mu část čtenářů nebude rozumět (hlavně vyhranění „procesáři“), takže nevěšte hlavu a berte to jako ilustraci toho, co se v IT musí udělat, než se BPMN „omalovánce“ vdechne život.

Objednávkový modul

Backendová část naší aplikace bude implementována pomocí Enterprise Java Beans 3.0, tedy standardu pro vývoj distribuovaných aplikací v jazyce Java. V projektu budeme pracovat se čtyřmi entitními beany (v praxi databázovými tabulkami). Nyní si uvedeme o jaké půjde a jaké vlastnosti (sloupce tabulky) budou kromě identifikátoru (primárního klíče) mít:

UserEntity – uživatel systému; u něj budeme z důvodu jednoduchost evidovat pouze jeho jméno a množinu jeho rolí, ve skutečném systému by byla řada vlastností samozřejmě daleko širší.
RoleEntity – uživatelská role; má název (např. „Technické oddělení“), unikátní textový identifikátor („tech“) a množinu uživatelů, jež do této role spadají. Každý uživatel může mít žádnou, jednu nebo více těchto rolí.
ItemEntity – položka katalogu; vedeme u ní název a cenu. U ceny budeme pro zjednodušení počítat, že jde vždy o jednu měnu, v našem případě koruny.
OrderEntity – objednávka; budeme u ní evidovat položku ke které se vztahuje a její kvantitu, datum založení, stav (nová, schválená, zamítnutá), uživatele, který ji objednal a roli, která v daném okamžiku rozhoduje o schválení. Jedna objednávka bude v našem případě pouze na jednu položku s možností vzít více kusů (tedy kvantita větší než 1).

Ilustrace 1: Diagram tříd objednávkového modulu

Při určení rozhraní webové služby, kterou bude modul poskytovat můžeme vycházet z potřeb business procesu a webové aplikace. Když se podíváme na BPMN diagram vidíme tři typy akcí jež proces volá na backendu – uložení objednávky, nastavení role k posuzování objednávky a označení stavu objednávky. Kromě těchto tří metod budeme ve webové službě potřebovat implementovat i metody pro webovou aplikaci – získání informací o uživateli, položce a objednávce, získání seznamu všech uživatelů, položek a objednávek a seznam objednávek podle zakladatele a schvalovatele. Místo entit bude modul vracet tzv. data transfer objekty (DTO), jenž budou mít veškeré vlastnosti, které budeme u entit ve webové aplikaci potřebovat. V rozhraní webové služby se tedy budou nacházet následující operace:

Ilustrace 2: Rozhraní webové služby objednávkového modulu

Nyní si popíšeme, jak provést deploy modulu na aplikační server. Nejprve si stáhněte z této adresy distribuční Java archív OrderingModule.jar. Pro jeho nasazení na server nejprve server spusťte z prostředí NetBeans aplikační server Glassfish (Services -> Servers -> Glassfish V2 -> Start). Následně otevřete administrační konzoli serveru (na adrese http:/localhost:4848/, přihlašovací údaje admin / adminadmin), na pravé straně vyberte z nabídky Applications -> EJB Modules a v hlavní části webové stránky zvolte „Deploy“. V části „Location“ vyberte umístění staženého Java archívu a zvolte „OK“.

V současné chvíli by již měly být v databázi připravené tabulky pro jednotlivé entity. V záložce Services v prostředí NetBeans vyberte „Databases“, nalezněte databázi s názvem sample (název zdroje „jdbc:derby://localhost:1527/sample“ a z kontextového menu zvolte „Connect...“. V záložce „Tables“ můžete zkontrolovat existenci tabulek ITEMENTITY, ORDERENTITY, ROLEENTITY, USERENTITY, a USERENTITY_ROLEENTITY. Nyní ještě potřebujeme naplnit tabulku rolí, uživatelů a položek testovacími údaji. Stáhněte si z této adresy sql skript pro naplnění těchto tabulek. Po kliknutí pravým tlačítkem na databázi sample vyberte „Execute Command...“, do textového pole vložte obsah staženého souboru create.sql a spusťte příkaz ikonkou se zelenou šipkou v pravé horní části obrazovky. Po provedení příkazu by měly být tabulky naplněny, což můžete zkontrolovat zvolením „View Data...“ v kontextových nabídkách jednotlivých tabulek.

Jako poslední zkontrolujeme správné nasazení webové služby modulu. Otevřeme v prohlížeči adresu http://localhost:8080/OrderWSService/OrderWS?wsdl a měli bychom uvidět definici webové služby ve formátu XML, včetně definice všech operací, které jsme si uvedli výše. Nyní je tedy ze strany backendového modulu vše připraveno a můžeme začít s implementací samotného procesu.

Implementace procesu

Jako předlohu pro tvorbu BPEL dokumentu si vezmeme proces namodelovaný pomocí notace BPMN ze 4. dílu. Rozdělíme si jej do tří částí, které budeme postupně převádět do implementační formy. První úsek jsme již částečně naimplementovali minule, pouze jsme vynechali vazbu na webovou službu backendu. Proces bude mít celkem tři vstupy, to znamená, že webová služba, která bude představovat rozhraní procesu, bude mít tři operace – vytvoření objednávky (createOrder), rozhodnutí technického oddělení (techDecide) a rozhodnutí finančního ředitele (findirDecide).

Ilustrace 3: BPMN proces rozdělený na jednotlivé části

Po vytvoření BPEL modulu a BPEL procesu v něm je třeba vytvořit WSDL soubor, jež slouží k popisu webové služby procesu a který bude definovat zmíněné tři operace, dále pak XSD soubor, jenž popisuje použité datové typy. Postup tvorby těchto souborů si uvádět nebudeme, budou ale k dispozici hotové spolu s celým projektem. Nyní již zbývá pouze naimportovat WSDL a XSD soubor k webové službě backendu. Z kontextové nabídky BPEL projektu vybereme New -> Other a pak z kategorie XML zvolíme External WSDL Document(s) a stiskneme tlačítko „Next“. Do textového boxu zkopírujeme adresu, na které se nachází definice webové služby objednávkového modulu, tedy http://localhost:8080/OrderWSService/OrderWS?wsdl a stiskneme „Finish“.

Nyní již máme v projektu všechny potřebné soubory a k začátku implementace procesu nám chybí pouze vytvořit v BPEL dokumentu odkazy na obě použité webové služby, tedy partner linky. Otevřeme tedy (příp. vytvoříme) soubor startOrder.bpel a do okna, které se otevře, přetáhneme oba WSDL soubory, tedy startOrder.wsdl a OrderWS.wsdl. První partner link můžeme pojmenovat například „Interface“ (rozhraní procesu) a druhý „OrderModule“ (webová služba objednávkového modulu).

První část

První část je v obrázku ohraničen červenou čárou. Proces je odstartován přijetím požadavku na vytvoření objednávky, tedy v BPMN objekt Start Message Event. V BPELu je alternativou k tomuto objektu aktivita Receive, tu tedy umístíme na začátek procesu a navážeme ji na operaci createOrder v partner linku Interface. Následně musí proces provést dvě aktivity – vytvořit objednávku (uložit ji do databáze) a nastavit jako schvalovatele technické oddělení. Tyto aktivity, tedy vyvolání webových služeb, lze v BPELu realizovat pomocí objektu Invoke. První task (nazveme jej „Create“) zavolá operaci createOrder v partner linku OrderModule a předá ji data, která zaslal uživatel. Druhá pak volá operaci setApprover a té předá unikátní textový identifikátor dané role, tedy v našem případě „tech“. Nakonec vrátíme uživateli odpověď, jež obsahuje ID nově vytvořené objednávky. To provedeme pomocí BPEL aktivity Reply. Pro manipulaci s proměnnými využijeme dvou aktivit typu Assign – AssignOrderDetails a AssigntTechApprover. Jak vypadá první část lze vidět na následujícím obrázku:

Ilustrace 4: První část BPEL procesu

Druhá část

V druhé části procesu zpracujeme rozhodnutí technického oddělení a na jeho základě označíme objednávku za schválenou či zamítnutou. Rozhodování finančního ředitele si necháme až do poslední části. V BPMN modelu je na začátku druhého úseku objekt typu Message Intermediate Event, který mapujeme do aktivity Receive (pojmenujeme „ReceiveTechDecision“) a spojíme jí s operací techDecide v partner linku Interface. To znamená, že pokud webový klient zavolá tuto operaci a proces čeká v aktivitě ReceiveTechDecision, tak bude přijata zaslaná zpráva (obsahující identifikátor objednávky a rozhodnutí technického oddělení) a proces bude pokračovat dále.

Nyní budeme chtít uživateli vrátit zprávu (operace techDecide je typu request – response), to učiníme opět pomocí aktivity Reply a obsahem této zprávy bude pouze pravdivostní hodnota „true“. Dále následuje v BPMN diagramu Data-based Exclusive Decision, tedy rozhodnutí na základě dat, jež je v BPELu zastoupeno aktivitou If. Tu tedy vložíme do procesu a pomocí BPEL mapperu (editor pro přiřazení proměnných) navolíme podmínku pro první větev rozhodování. Můžeme využít vizuálních prvků a pomocí nich navolit podmínku „ReceiveTechDecision.type = approve“ tak, jak je to vidět na následujícím obrázku:

Ilustrace 5: Rozhodnutí technického oddělení

Pokud tedy technické oddělení objednávku schválilo, proces projde první větví, v opačném případě druhou. Podle toho musíme označit objednávku za schválenou či zamítnutou. Do první větve tedy umístíme aktivitu AssignApproved a do druhé AssignDeclined, ve kterých přiřadíme příslušný konečný stav objednávky. V BPMN diagramu máme označení objednávky za schválenou či zamítnutou ve dvou aktivitách, po nichž následuje konec procesu (End Event). Při převodu do BPELu můžeme buďto ponechat obě aktivity zvlášť (jedna Invoke aktivita v každé větvi), nebo je sloučit do jedné (jeden Invoke po sloučení větví), s tím, že v jednotlivých větvích přiřadíme příznak schválení či zamítnutí do vstupní zprávy volané operace webové služby backendu SetOrderState. My zvolíme druhou možnost a pod sloučení větví přidáme Invoke aktivitu SetFinalOrderState, která zavolá příslušnou operaci v objednávkovém modulu a nechá změnit stav objednávky podle předchozího určení. Druhá část je tedy hotova, pokračování implementovaného procesu opět můžete vidět na obrázku.

Ilustrace 6: Druhá část BPEL procesu

Třetí část

Nyní by byl proces kompletní, pokud bychom chtěli, aby o objednávce rozhodovalo pouze technické oddělení. Proces tedy upravíme tak, aby v určitém případě musel rozhodovat i finanční ředitel. Poslední část procesu je v BPMN modelu ohraničena zelenou čárou. Prvním elementem je rozhodování podle částky, což už víme, že je v BPELu realizováno pomocí aktivity If. Nejprve ovšem musíme cenu objednávky zjistit. Jelikož je v objednávce pouze jeden druh zboží, získáme informace o něm včetně ceny zavoláním operace GetItemDTO ve webové službě backendu. Tato operace nám vrátí cenu objednané položky, kterou znásobíme objednanou kvantitou (tu zadal uživatel při vytváření objednávky) a tak získáme celkovou cenu objednávky. Vyvolání zmíněné operace i rozhodovací prvek vložíme do té větve, která značí případ, kdy objednávka byla schválena technickým oddělením (ve druhé větvi ponecháme pouze aktivitu AssignDeclined). Celkovou cenu objednávky porovnáme s částkou 40.000, čímž se nám proces rozdělí do dvou větví – když je částka větší a když je stejná nebo menší. Následující obrázek ukazuje, jak vypadá výraz, podle kterého se vyhodnocuje rozhodnutí o ceně objednávky:

Ilustrace 7: Rozhodnutí podle ceny objednávky

Zbytek procesu si již popíšeme stručně, jelikož rozhodnutí finančního ředitele je obdobou předchozího rozhodnutí technického oddělení. Nejprve tedy nastavíme objednávku k posouzení vyvoláním operace setApprover a čekáme na přijetí rozhodnutí v Receive aktivitě na operaci findirDecide. Následně provedeme obdobné rozhodnutí podle schválení či zamítnutí objednávky, jako v předchozím případě. Pozor si musíme dát na to, aby v každém z možných průchodů procesem (celkem jsou čtyři) byl správně určen konečný stav objednávky. Následující obrázek ukazuje kompletní proces implementovaný v jazyce BPEL tak, jak jej umožňuje vizualizovat BPEL designer v prostředí NetBeans IDE. Kompletní projekt, který obsahuje veškeré potřebné soubory, si můžete stáhnout z této adresy.

Ilustrace 8: Kompletní BPEL proces

V příštím díle

Příště si ukážeme, jak implementovaný proces otestovat a jaké možnosti skýtá jeho ladění (debugging). Dále představíme webovou aplikaci, pomocí které může uživatel s procesem interagovat. Projdeme si také různé scénáře životního cyklu objednávky a vysvětlíme si, jaké události při nich v procesu probíhají.

5. část: Tvorba BPEL modulu

2008-04-15T22:08:00.010+02:00

Petr Vašíček, IBA CZ

V tomto díle si povíme něco o jazyce BPEL a začneme modelovat proces založení objednávky, jež jsme modelovali v díle minulém. Rovněž tedy poprvé použijeme vývojové prostředí NetBeans a ukážeme si, jak v něm založit BPEL projekt a jakým způsobem jej nasadit na server.

O jazyce BPEL uvedeme pouze základní informace a budeme se spíše soustředit na samotné modelování procesu. V článku také nabídneme odkazy na materiály, které mohou poskytnout podrobnější informace či přímo specifikaci jazyka BPEL včetně přesného popisu jeho jednotlivých elementů. Uvedeme i odkazy na tutoriály k NetBeans IDE, na jehož podrobnější popis by rovněž nebylo v seriálu místo.

Úvod do jazyka BPEL

WS-BPEL, celým názvem Web Services – Business Process Executional Language (výslovnost uváděna jako „bipple“ či „B-pel“), je jazyk na bázi XML (eXtensible Markup Language), jež slouží pro zápis business procesů na vykonatelné úrovni. Proces implementovaný pomocí BPEL je nasazen do běhového prostředí, které je schopno jej interpretovat. Tímto prostředím může být buďto samostatný procesní server, modul v aplikačním serveru apod. V našem případě jde o plug-in (tzv. service engine) do implementace podnikové sběrnice OpenESB, kterou v našem prostředí použijeme. Komponenta má název WS-BPEL Service Engine a nasazení implementovaných business procesů lze provádět pohodlně přímo z vývojového prostředí NetBeans, které budeme používat.

Hlavní funkcí BPELu je orchestrace webových služeb, tedy řízení souhry funkcionality, kterou nabízí backendová část systému, či více systémů. Tato funkcionalita je dekomponována do operací, jež je možné volat přes webovou službu. Na druhé straně BPEL sám stojí za webovou službou, která definuje jeho rozhraní, tj. vstupní operace. Pro každý vstup do procesu (v BPMN objekt Start / Intermediate MessageEvent) je tedy ve webové službě, která popisuje rozhraní BPELu, jedna operace. Dá se tedy říci, že BPEL implementuje webovou službu. Přitom aplikace, která webovou službu používá, neví, zda se za ní skrývá proces, či zda je implementována např. EJB modulem. BPEL je rovněž nezávislý na platformě, implementace pro něj existují na platformě Java EE, .NET a jiných platformách. Proces implementovaný v jazyce BPEL pomocí jednoho nástroje by také mělo být možné přenést a spustit v nástroji jiném. Někteří výrobci BPMS ale používají svá vlastní rozšíření jazyka BPEL, která tuto přenositelnost zněmožňují.

První verze jazyka BPEL, pojmenovaného jako BPEL4WS, vznikla v červenci 2002 a spojila myšlenku jazyků WSFL od IBM a XLANG od spol. Microsoft. Kromě těchto dvou společností se na původním návrhu podílela i BEA. V květnu 2003 byl revidovaný návrh předložen organizaci pro rozvoj strukturovaných informačních standardů OASIS a BPEL4WS ve verzi 1.1 si začal získávat velkou podporu na poli modelování procesů. Jen o něco později byl uveden další jazyk pro definování spustitelných procesů, BPML 1.0, ten ale zejména díky silné podpoře pro konkurenční BPEL ze strany velkých hráčů na trhu neuspěl. Dnes není takřka využíván, přestože oproti BPELu toho má více co nabídnout (řeší např. business pravidla, lidskou interakci s procesem apod.). Současná verze 2.0 byla představena v prosinci 2005 a ratifikována v dubnu 2007 a nese již pozměněný název WS-BPEL 2.0. Oproti předchozí verzi představuje několik nových BPEL aktivit, přejmenovává některé existující a obsahuje několik dalších menších změn.

Struktura BPEL dokumentu

NetBeans IDE, stejně jako většina ostatních BPEL návrhářů, poskytuje grafické uživatelské rozhraní pro modelování procesu v jazyce BPEL. Je tedy možné celý proces „naklikat“ a kódem procesu se nezabývat. Čas od času je ovšem zapotřebí nahlédnout do XML kódu a provést nějaké úpravy, zejména při řešení chyb. Kromě toho nění úplně od věci se v procesu zapsaném v jazyce BPEL orientovat, a proto si krátce představíme strukturu BPEL dokumentu.

Základní struktura dokumentu je zobrazena na následujícím obrázku. Kořenový element {process} (pozor - u všech elementů jde o ostré závorky <...> - na tomto webu je pouze nejsme schopni s příslušnými elementy zobrazit) zahrnuje všechny ostatní XML elementy. Pomocí atributů tohoto elementů určíme název procesu a jmenné prostory (namespaces). Následuje element {import}, kterým definujeme odkazy na použité externí soubory, typicky popisovače webové služby, WSDL dokumenty. Pomocí elementů {partnerlink} specifikujeme účastníky procesu, tedy kromě WS rozhraní samotného procesu i WS modulů, které použijeme. Následuje definice proměnných v elementu {variables} a korelačních množin pomocí {correlationsets}. Pak se již nachází hlavní sekvence událostí, obsažená v XML elementu {sequence}, do které již umísťujeme BPEL aktivity, specifikující tok procesu.

BPEL aktivity

Objekty, které v jazyce BPEL reprezentují události či defunují tok procesu, se nazývají BPEL aktivity. Aktivitami se tedy neoznačuje pouze nějaká činnost, jako tomu je v BPMN, nýbrž všechny elementy jazyka, jež značí nějakou akci či strukturu procesu. Následující výčet zahrnuje deset nejčastěji používaných BPEL aktivit.

Základní aktivity (basic activities):
Receive - zastaví proces a čeká na příchod specifikované zprávy
Reply - zašle zprávu jako odpověď na dříve přijatou zprávu
Invoke - vyvolá WS operaci typu one-way nebo request-response
Assign - manipulace s proměnnými
Exit - okamžitě ukončí vykonávání instance business procesu

Strukturované aktivity (structured activities):
Sequence - obsahuje aktivity, jež jsou spouštěny sekvenčně
Flow - obsahuje aktivity, jež jsou spouštěny paralelně
If-else - vybere jednu větev podle pravdivostního výrazu
Pick - zastaví proces a čeká na příchod první z více definovaných událostí
While - obsažené aktivity jsou opakovány, dokud platí určitý predikát

Pro získání více informací o těchto a ostatních BPEL aktivitách, lze doporučit tyto zdroje:

Specifikace WS-BPEL 2.0
Guide to BPEL
BPEL Activities

NetBeans BPEL a CA projekt

Nyní se dostáváme k samotnému vytvoření našeho projektu. K tomu budeme potřebovat vývojové prostředí NetBeans IDE. Pokud jej máte nainstalováno (odkaz ke stažení jsme uvedli ve druhém díle), můžete jej nyní spustit. Základní informace o tomto nástroji včetně několika jednoduchých tutoriálů lze najít zde.

Nejprve založíme v NetBeans projekt, který bude obsahovat implementovaný proces a soubory, popisující účastníky procesu, tedy definice datových typů (soubory XSD) a popisovače webových služeb (soubory WSDL). Z nabídky zvolíme File -> New Project -> Service Oriented Architecture -> BPEL Module, jako název projektu zvolíme „OrderingBPEL“, vybereme umístění a dokončíme tlačítkem „Finish“. Máme tedy vytvořený BPEL modul, ve kterém budeme mít samotný proces a k němu přidružené soubory.

Druhým projektem, který budeme potřebovat, je kompozitní aplikace. Tato aplikace je souhrný projekt, skládající se z jednoho či více JBI modulů. BPEL modul je právě příkladem JBI modulu. Kompozitní aplikace s jedním či více moduly je pak nasazena na JBI server, v našem případě do OpenESB. Kompozitní aplikaci vytvoříme z File -> New Project -> Service Oriented Architecture -> Composite Application, jako jméno nastavíme OrderingCA. Pro přidání JBI modulu klikneme pravým tlačítkem myši na kořenový uzel nově vytvořeného projektu a vybereme „Add JBI Module“. Vybereme adresář, ve kterém máme BPEL modul a tvorba kompozitní aplikace je hotova. Až budeme mít hotový BPEL projekt, provedeme pak jednoduše deploy kompozitní aplikace na server pomocí „Deploy“ v kontextové nabídce projektu.

Účelem seriálu ovšem není návod pro modelování v BPEL, nebudeme si tedy uvádět jak vytvářet XSD a WSDL soubory, ani se dopodrobna zabývat postupem a přesným nastavením při tvorbě BPEL dokumentu. Spíše se budeme snažit ukázat, jak obecně modelování probíhá a jak funguje nasazení a vykonání procesu. Pro zájemce u návod tvorby BPELu v NetBeans můžeme doporučit následující tutoriály:

Dev Guide to the BPEL Designer
Hello World Composite Application
Developing Synchronous Process

Implementace první části procesu

Nyní si vytvoříme první krok procesu založení objednávky. Nebudeme v této chvíli ještě využívat webovou službu backendového modulu, tu zapojíme až v příštím díle. Předpokládáme, že již máme vytvořen XSD a WSDL soubor pro náš proces. Rozhraní procesu tvoří tři operace, z nichž zatím implementujeme tu první, a to sice createOrder. Do procesu vložíme aktivity Receive a Reply a spojíme je s touto operací. Mezi ně vložíme aktivitu Assign a v ní přiřadíme do návratové proměnné aktivity Reply zatím testovací hodnotu „123“.

Nyní máme hotový testovací BPEL a můžeme nasadit kompozitní aplikaci na server. V projektu OrderingCA zvolíme „Deploy“ a v záložce Services -> Servers -> Glassfish V2 -> JBI ->Service Assemblies můžeme zkontrolovat, že aplikace OrderingCA je skutečně nasazená na serveru.

Když jsme nasadili proces na server, můžeme otestovat vstupní operaci createOrder. Podle návodu na netbeans.org vytvoříme v kompozitní aplikaci test case a pro tuto operaci a spustíme jej volbou „Run“ v kontextové nabídce testu. V uložené SOAP odpovědi „Output.xml“ můžeme zkontrolovat, že v elementu newOrderId se opravdu nachází hodnota „123“.

V příštím díle

Příště si nejprve představíme backendovou část aplikace, která obsahuje funkcionalitu pro práci s objednávkami. Pak pomocí NetBeans dotvoříme zbytek procesu a napojíme ho na webovou službu objednávkového modulu. Hotový proces pak otestujeme. Všechny tři vytvořené NetBeans projekty – BPEL modul, kompozitní aplikaci i objednávkový backend - umístíme ke stažení, abyste si mohli příklad sami vyzkoušet i bez nutnosti modelování procesu podle našeho návodu.

4. část: Modelování procesu

2008-03-27T12:44:00.008+01:00

Petr Vašíček, IBA CZ

Minule jsme si představili grafickou notaci BPMN, jež je de facto standardem pro modelování business procesů, a uvedli jsme si nejčastěji používané elementy této notace včetně jejich vysvětlení na jednoduchém příkladu. V tomto díle budeme již modelovat proces popsaný v druhé části našeho seriálu. Začneme tvorbou modelu na vysoké úrovni a budeme dále zpřesňovat subproces znázorňující založení objednávky. Cílem bude uvést model do tvaru, který bude převeditelný do jazyka pro popis procesů na vykonatelné úrovni, v našem případě do jazyka BPEL (Business Process Executional Language).

Každý proces je možné vyjádřit různými typy diagramů a s různou mírou přesnosti podle toho, k jakému účelu bude sloužit. Jinak vypadá diagram, sloužící k hrubému náhledu na proces, a jinak diagram, jenž bude předlohou pro implementaci procesu v jazyce BPEL.

Neexistuje žádná specifická metodika, se kterou je BPMN spjato a která by popisovala, jakým způsobem se mají procesy modelovat a jakým postupem modely zpřesňovat. Obvyklé je však začít u modelu procesu na vysoké úrovni, tedy sekvenci subprocesů, a následně modelovat tyto jednotlivé subprocesy. Nejprve lze vytvořit hrubý model subprocesu a pak jej dále zjemňovat, přidávat aktivity, uspořádávat elementy do plaveckých drah atd.

V tomto díle se pokusíme nastínit jeden z možných způsobů, kterým toho lze docílit. Zopakujme tedy, že našim cílem bude vyjádřit proces ve tvaru, ve kterém ho budeme moci co nejsnáze převést do spustitelné podoby, tedy implementovat v jazyce BPEL. U minulého dílu seriálu se rozvinula zajímavá diskuze zejména ohledně názvosloví aktivit a událostí a bude určitě přínosem, pokud se i tentokrát podělíte o svoje názory a zkušenosti.

Tvorba high-level modelu

Diagram procesu na vysoké úrovni, tzv. high-level diagram, je zobrazen jako sekvence subprocesů. Jak bylo napsáno v minulém díle, subproces je aktivita, pod kterou se skrývá samostatný proces se svým počátkem a koncem. Tento subproces je zinicializován z high-level procesu v okamžiku, kdy do něj vstoupí tok procesu. Poté, co subproces skončí, pokračuje high-level proces sekvenčním tokem, vedoucím z grafického objektu, značícího subproces.

V našem seriálu se budeme věnovat pouze jednomu samostatnému procesu (Založit objednávku), jenž již nebude dekomponován na další subprocesy. Nyní se ale podívejme, jak by mohl vypadat high-level proces, kde Založit objednávku je jedním ze subprocesů:

Proces začíná požadavkem na vytvoření objednávky a následuje první subproces, Založit objednávku. Výsledkem tohoto subprocesu je mimo jiné to, zda byla objednávka schválena či nikoliv. Pokud byla zamítnuta, high-level proces je ukončen, v opačném případě pokračuje dál třemi zaznačenými subprocesy.

Modelování subprocesu

Soustřeďme se nyní na samostatný proces Založit objednávku. Ten začne požadavkem na vytvoření objednávky od Objednatele. Touto událostí by odstartoval uvedený high-level proces, my ji ale budeme chtít přesunout do procesu Založit objednávku, abychom ten mohli později implementovat jako samostatný proces bez implementování high-level procesu.

Budeme se tedy držet popisu, který jsme uvedli ve druhém díle seriálu. Po vytvoření objednávky probíhá její posouzení technickým oddělením. Pokud ji schválí, dojde k rozhodnutí podle ceny objednávky. V případě, že je nižší než 40.000 Kč, je objednávka přímo schválena, v opačném případě je navíc předána ke schválení finančnímu řediteli. Budeme nyní modelovat jen hrubý diagram procesu a využijeme tedy pouze základních grafických elementů notace BPMN – startovních a ukončovacích událostí, aktivit, rozhodovací brány a sekvenčního toku.

Uspořádání aktivit do plaveckých drah

V procesu vystupují tři aktoři – Objednatel, Technické oddělení a Finanční ředitel. Nyní budeme chtít uspořádat aktivity v procesu tak, abychom z diagramu mohli určit, kdo v něm provádí jakou činnost. K tomuto účelů slouží plavecké dráhy (swimlanes). Vytvoříme tedy jeden pool (v diagramu je pouze jeden proces), ten můžeme pojmenovat např. workflow, tedy „tok práce“. V něm vytvoříme plaveckou dráhu pro každého aktora, v diagramu tak budeme mít jeden pool, rozdělený na tři plavecké dráhy.

Zahrnutí systémových akcí do procesu

Naším cílem je převést proces na nižší úroveň, abychom jej mohli později snáze implementovat. Budeme tedy chtít zpřesnit proces zobrazení aktivit, jenž ukazují interakci s backendovou částí systému, v našem případě tedy např. modulem pro správu objednávek. Pokud uživatel vytvoří objednávku, budeme ji chtít zřejmě v systému uložit. Pokud je objednávka předána ke schválení nějaké roli, budeme to u ní chtít zachytit. A pokud je objednávka schválena či zamítnuta, chceme tento příznak u objednávky nastavit. Do diagramu přidáme novou plaveckou dráhu – Objednávkový modul. V ní vytvoříme zmíněné systémové akce (můžeme označit jako Service Task).

Vyjádření spustitelného procesu

Podívejme se nyní, jakým způsobem je proces „umístěn“ ve vyvíjeném systému. V prvním díle seriálu můžete na druhém obrázku vidět, že BPM vrstva se nachází mezi backendovou a prezentační vrstvou. Na následujícím obrázku jsou vybrány komponenty, na kterých můžeme vidět jakým způsobem proces interaguje se zbytkem systému. Uprostřed vidíme schéma nějakého procesu. Z jedné strany k němu přistupuje webová aplikace, tedy uživatelé. Na straně druhé proces komunikuje s moduly systému a využívá jejich funkcionality.

Nyní tedy potřebujeme proces dostat do tvaru, kdy bude na jedné straně komunikovat s uživateli a na straně druhé s backendovými moduly systému. Protože BPEL neumí řešit lidskou interakci s procesem, budou veškeré lidské akce „vytknuty“ z procesu a každá taková akce bude v procesu zaznačena přijmutím zprávy (message start/intermediate event) od účastníka procesu reprezentujícího právě lidské uživatele systému.

V procesu tak budeme mít tři účastíky, reprezentované třemi pooly – Uživatelé, Objednávkový modul a samotný proces, u něhož však nebudeme ohraničení poolu zobrazovat. První dva zmíněné pooly budou typu „blackbox“, nebude v nich tedy zobrazen jejich vlastní proces, pouze komunikace s hlavním procesem.

Vidíme, že takto vyjádřený proces skutečně interaguje na jedné straně s uživateli a na druhé s backendovou částí systému. Jeho rozhraní tvoří tři operace – vytvoření objednávky, rozhodnutí technického oddělení a rozhodnutí finančního ředitele. Tyto tři operace budou volány uživateli z webové aplikace. Na druhé straně proces volá rozhraní objednávkového modulu, jenž musí nabízet minimálně tři operace – vytvoření objednávky, nastavení schvalovatele a změnu stavu objednávky.

Takto specifikovaný proces již můžeme poměrně snadno převést do spustitelné podoby jeho implementací v nějakém jazyce pro popis vykonatelných procesů. V našem případě tedy do jazyka WS-BPEL. Proces bychom mohli ještě dále zpřesňovat, typicky odchytáváním výjimek a zaznačením chybového toku, specifikováním vypršení limitu (timeout) při čekání na rozhodnutí apod., ale pro jednoduchost již necháme proces v této formě.

V příštím díle

V příštím díle si představíme standard pro zápis spustitelných procesů, XML jazyk BPEL, ve kterém budeme dnes namodelovaný proces implementovat. Budeme poprvé pracovat s vývojovým nástrojem NetBeans a ukážeme si, jakým způsobem v něm lze implementovat navržený proces a ten pak nasadit do běhového prostředí (v našem případě BPEL engine v platformě OpenESB).

3. část: Úvod do BPMN

2008-03-18T20:13:00.009+01:00

Petr Vašíček, IBA CZ

V minulém díle jsme si popsali proces založení objednávky, který budeme v rámci seriálu modelovat a implementovat. Ještě před tím si však představíme notaci BPMN, ve které bude modelování probíhat. Tento článek můžete brát jako takový jemný úvod do této notace. Komplexnější pohled na BPMN a detailnější návod pro modelování v něm by vystačil na samostatný seriál, proto si v dnešním díle uvedeme alespoň jeho základy. Závěrem uvedeme několik odkazů na dokumenty, ze kterých je možno získat podrobnější znalosti.

Pár slov o BPMN
Business Process Modeling Notation (BPMN) je grafická notace (soubor grafických objektů a pravidel, podle nichž mohou být mezi sebou spojovány), která slouží k modelování procesů. Za jejím vznikem stojí iniciativa BPMI (Business Process Management Initiative), jejímž primárním cílem bylo v tomto případě vytvořit notaci, která bude čitelná všemi účastníky životního cyklu procesu (business analytici, techničtí vývojáři, analytici monitorující procesy atd.). Díky BPMN se úspěšně podařilo zmenšit komunikační mezeru mezi návrhem a implementací procesu a díky desítkám nástrojů, které jej používají, se stalo de facto standardem pro modelování procesů.

Dalším cílem BPMI bylo představit notaci, jež bude na jednu stranu jednoduchá na pochopení a používání, na druhé straně ale nabídne možnost modelovat i komplexní business procesy. Důležité bylo rovněž definovat převod mezi návrhem procesu v BPMN a jeho implementací v BPEL, BPML, či jiném jazyce pro spouštění procesů. BPMN definuje, jak převádět jednotlivé elementy a sekvence těchto elementů do jazyka BPEL. Je tedy možné (manuálně) model procesu do jeho spustitelné podoby převést. Díky poměrné volnosti modelování v BPMN není možné vygenerovat BPEL automaticky, některé BPMS nástroje však tuto funkci nabízejí, a to za cenu určitých omezení při samotném modelování procesu.

V současné chvíli je BPMN ve verzi 1.1, jež byla formálně přijata v lednu 2008. Daleko používanější ovšem zůstává verze 1.0 (únor 2006), která se od novější verze liší pouze v několika kosmetických změnách. Verze 2.0, která by měla přinést zásadnější změny, je očekávána koncem roku 2008 či spíše během roku 2009.

BPMN definuje jediný diagram, tzv. Business Process Diagram (BPD). Ten je tvořen sítí grafických objektů, zejména aktivitami a zobrazením toku informací mezi nimi. Jednotlivé grafické objekty jsou od sebe dobře odlišené, což přispívá k přehlednosti diagramu. Jasně dány jsou tvary těchto objektů, které je třeba dodržovat, je ovšem možné volit pro ně vlastní barvy, například z odlišovacích účelů. V určitých případech lze použít v diagramu i vlastní grafický objekt, ten se však nesmí překrývat s žádným již existujícím a rovněž by neměl ovlivňovat samotný tok procesu, pouze jej upřesňovat, či poskytovat nějaké dodatečné informace.

Grafické elementy
Business Process Diagram obsahuje čtyři základní druhy grafických elementů, jež se ještě dále dělí na další podtypy. Nejastěji používané druhy ilustruje následující obrázek:

Následuje výpis základních informací o jednotlivých typech grafických objektů:

Flow Objects (Tokové objekty)
Objekty, které souvisí s tokem informací v procesu.

Event (Událost)

značí se kroužkem
přímo ovlivňují tok procesu
události, jimiž proces začne, skončí, či které nastanou v jeho průběhu

Activity (Aktivita)

obdélník s kulatými rohy
znázorňuje činnost či práci
může být buďto atomická (tzv. Task) nebo v sobě může obsahovat samostatný proces, pak se tato aktivita nazývá subprocesem

Gateway (Brána)

značí se čtvercem či kosočtvercem, stojícím na špici
označuje rozbíhání či souběh toků procesu, např. rozhodování či paralelní zpracování

Connecting Objects (Spojovací objekty)
Objekty, které slouží k spojení tokových objektů navzájem či s artefakty.

Sequence Flow (Sekvenční tok)

nepřerušovaná čára s vyplněnou šipkou
určuje sekvenci (pořadí) aktivit

Message Flow (Tok zpráv)

přerušovaná čára s prázdnou šipkou
znázorňuje tok zpráv mezi dvěma účastníky procesu

Association (Asociace)

přerušovaná čára
umožňuje spojit objekt s nějakou dodatečnou informací

Artifacts (Artefakty)
Značí nějaké upřesňující informace pro proces, nemají vliv na jeho tok.

Data Object (Datový objekt)

značí se obdelníkem s přehnutým rohem (list papíru)
reprezentuje data, se kterými pracují aktivity

Group (Seskupení)

obdélník kreslený přerušovanou čárou
seskupení aktivit za analytických či dokumentačních důvodů

Annotation (Poznámka)

text, jenž je spojen asociací s jiným grafickým objektem
poskytuje dodatečnou textovou informace

Swimlanes (Plavecké dráhy)
Slouží k zobrazení účastníků procesu či uspořádání činnosti v procesu např. podle rolí.

Pool

ohraničuje proces, v jeho záhlaví je název poolu
reprezentuje účastníka procesu
v rámci jednoho poolu se nachází právě jeden samostatný proces
komunikace mezi pooly probíhá pomocí zpráv (message flow)

Lane (Dráha)

podčást poolu
slouží k uspořádání a kategorizaci aktivit
může značit např. role, oddělení či funkce organizace
komunikace mezi dráhami probíhá pomocí sekvenčního toku (sequence flow)

Příklad Business process diagramu

Uveďme příklad procesu jednoduchého aukčního systému. Tok informací v tomto procesu je následující. Nejprve proběhne registrace položky do aukce. Pokud je položka v aukci, může být koupena buďto s okamžitou platností kdykoliv během trvání aukce (tzv. „Buy It Now“), nebo může aukce skončit po určené době. V tom případě je vydražena, pokud byl učiněn alespoň jeden příhoz. V případě, že položka byla vydražena (buďto „Buy It Now“ nebo přihazováním), čeká systém na přijetí platby. Pokud platba přijde do sedmi dní, nechá systém zaslat koupené zboží a proces je ukončen. Pokud položka nebyla vydražena či výherce do sedmi dní nezaplatil, je buď znovu registrována do aukce, nebo je proces ukončen (podle nastavení aukční položky).

Na obrázku můžete vidět, jak by zadaný proces mohl vypadat. Není to samozřejmě jediný možný model tohoto procesu, BPMN poskytuje poměrně velkou volnost při modelování, takže existuje více možností, jak navrhnout stejný proces pomocí této notace.

Nyní si popíšeme tok v procesu tak, jak jej vidíte na uvedeném obrázku. Začátek procesu je zaznačen zeleným kroužkem. Odtud míří tok procesu do aktivity, jež značí registraci položky do aukce. Poté, co je položka registrována začne běžet aukce. Během ní mohou proběhnout dvě události – buďto někdo koupí položku hned (příjem zprávy „Koupeno hned“), nebo dříve dojde ke skončení aukce vypršením stanovené doby (časová událost typu „Timer“). Je tedy použito rozhodnutí na základě události a proces bude pokračovat větví, ve které nastane událost jako první. Pokud jako první nastane konec aukce, je třeba rozlišit, zda existují na položku nějaké příhozy. Jestli ano, míří tok procesu k čekání na přijetí platby stejně jako v případě, že někdo koupil položku již před skončením aukce díky možnosti „Buy It Now“. K aktivitě „Přijmout platbu“ je připojena událost „Timer“ s popisem „7 dní“. Tím je řečeno, že pokud proces setrvá v této aktivitě sedm dní, bude jeho tok směřovat větví, jež vybíhá z této události. Pokud je do sedmi dní platba přijata, je zboží zasláno výherci aukce – aktivita „Zaslat zboží“ - a proces končí. Pokud položka nebyla koupena nebo platba nedorazila, tok procesu bude ústit do grafického objektu znázorňujícího rozhodnutí na základě informace (tedy jestli má být zboží nasazeno znovu do aukce). Pokud má být položka znovu registrována, míří tok procesu na začátek do první aktivity, v opačném případě proces spěje do ukončovací události (červený kroužek) a je zastaven.

Závěrem

Účelem tohoto dílu bylo poskytnout jemný úvod do grafické notace Business Process Modeling Notation, kterou budeme používat pro modelování procesu v příštím díle. Uvedli jsme základní informace o této notaci a krátce představili její nejčastěji používané grafické elementy. Na závěr jsme si ukázali jednoduchý proces, na kterém můžeme vidět v praxi některé z grafických objektů. K hlubšímu pochopení, jak tyto objekty používat, a vůbec k lepšímu pochopení konceptu modelování v BPMN můžeme doporučit následující dokumenty:

2. část: Nástroje a vzorový proces

2008-02-27T21:00:00.003+01:00

Petr Vašíček, IBA CZ

V tomto díle se podíváme na konkrétní nástroje, které budeme v průběhu seriálu používat, a dozvíme se, jakým způsobem je lze získat. Dále si představíme jednoduchý vzorový proces, se kterým budeme v následujících dílech pracovat. Popíšeme si jeho průběh, účastníky (aktory), kteří v něm vystupují, a pro lepší představu o systému jako celku též zmíníme základní informace o backend a frontend části aplikace.

Použité nástroje

Jako první bude v seriálu představena platforma složená z nástrojů vyvinutých společností Sun Microsystems - OpenESB, NetBeans a aplikační server GlassFish:

OpenESB – podniková sběrnice služeb, jejíž součásti je i běhové prostředí pro BPEL.
NetBeans – vývojové prostředí; budeme v něm modelovat proces ve spustitelném jazyce BPEL a nasazovat jej do běhového prostředí; kromě toho lze pomocí něj vyvíjet i jiné typy java projektů (webové a desktopové aplikace, moduly atp.).
GlassFish – aplikační server, ve kterém běží OpenESB a frontendová i backendová část naší aplikace.
Business Process Visual Architect – návrhář procesů z dílny Visual Paradigm (komerční software – viz dále); budeme v něm zakreslovat procesy pomocí grafické notace BPMN.

V našem vzorovém projektu použijeme komunikační infrastrukturu OpenESB, na níž budeme postupně stavět BPMS infrastrukturu. OpenESB je implementací JBI (integrační standard specifikovaný v JSR-208 - více informací) a umožňuje přidávat další funkční celky v podobě JBI pluginů, čímž nám usnadní budování kompletního BPMS řešení. Jedním z důležitých pluginů je právě i WS-BPEL Service Engine pro spouštění procesů zapsaných v jazyce BPEL. Dalším může být například komponenta pro business pravidla či workflow.

Obrázek 1: Architektura JBI

OpenESB je dobře provázána s vývojovým prostředím NetBeans, ve kterém lze snadno modelovat procesy v jazyce BPEL a sestavovat kompozitní aplikace, sloužící k provázání komponent nasazovaných do ESB. Současně je možné pomocí NetBeans vytvářet backend i frontend vyvíjeného systému, což zmenšuje počet nástrojů nutných k jeho vývoji a unifikuje vývojářské prostředí. NetBeans lze spolu s aplikační serverem GlassFish a OpenESB stáhnout jako bundle (společně distribuovaný balík), což zjednodušuje jeho instalaci, konfiguraci a také použití.

Pro modelování procesu v grafické notaci BPMN budeme používat nástroj Business Process Visual Architect, který není sice zdarma, nicméně jeho cena je poměrně nízká. Navíc existuje možnost stáhnout si jej na zkoušku po dobu 30 dní, což pro náš účel postačí. Díky jednoduchosti notace BPMN existují i volně dostupné kreslítka, umožňující modelovat BPMN procesy, nicméně nedosahují kvalit BP-VA.

Vývojové prostředí NetBeans 6.0.1 včetně aplikačního serveru GlassFish obsahujícího i OpenESB lze stáhnout zde. Vyberte poslední download (all – 195 MB).

Pro běh IDE i serveru je třeba mít nainstaováno Java JDK, nejlépe ve verzi 5.0. To je možné získat zde, konkrétně doporučujeme vybrat „JDK 6 Update 4“.

Nástroj Business Process Visual Architect od Visual Paradigm, ve kterém budeme modelovat proces, můžete stáhnout zdarma na této adrese. Na této stránce je potřeba vlevo nahoře kliknout na odkaz „Get a FREE copy“, zaregistrovat se, stáhnout produkt a nechat si na zadanou emailovou adresu zaslat soubor s licencí.

Ukázkový proces

Jak jsme již předeslali v úvodu seriálu, budeme celý životní cyklus BPM demonstrovat na jednom konkrétním procesu.

Pro modelování jsme vybrali jednoduchý a názorný proces, který si každý bude moci snadno představit, a to sice proces vytváření a schválení objednávky. Při návrhu tohoto procesu jsme nekladli přílišný důraz na realizmus procesu co se týče samotných požadavků, ani zda je proces správně navržen z pohledu analytického, ale spíše na jeho jednoznačnost, přehlednost a jednoduchou technickou proveditelnost. Záměrná trivialita procesu usnadní vysvětlování jednotlivých aspektů při jeho modelování a rovněž umožní věnovat se podrobně celému procesu. Tento proces budeme v této podobě používat s drobnými úpravami nebo obměnami až do konce seriálu.

Implementaci tohoto procesu budeme realizovat ve středně velké (fiktivní) firmě. Tato firma již má definován proces pro vytvoření objednávky a prvním krokem v jeho životním cyklu bude jeho namodelování business analytikem. V procesu vystupují tři role:

Objednatel provádí zadání objednávky do systému (ve firmě je učeno několik lidí, kteří mohou tuto roli zastávat a tedy vytvářet objednávky),
Technické oddělení, které tvoří pracovníci, jejichž úkolem je posoudit vhodnost objednaného zboží,
Finanční ředitel rozhoduje o dražších nákupech ve firmě

Proces začíná vytvořením objednávky a končí jejím schválením či zamítnutím. V případě schválení je objednávka předána k objednání. To už je předmětem navazujícího procesu, o kterém budeme předpokládat, že je již namodelován a funkční, a nebudeme se jím podrobněji zabývat.

Obrázek 2: Modelový proces

Proces je tedy iniciován akcí Objednatele, který založí objednávku v systému, uvede druh zboží, kvantitu a důvod objednávky (business reason). Objednávka je následně předána technickému oddělení ke schválení. To ji posoudí (zda není zboží již zastaralé, zda je vhodné pro požadovaný účel apod.) a rozhodne o jejím schválení. Pokud technické oddělení objednávku nezamítne (s uvedeným důvodem), proces pokračuje do rozhodovacího okamžiku, ve kterém se rozvětví podle ceny objednaných položek. Pokud je vyšší či rovna 40.000 Kč, musí ji schválit Finanční ředitel, v opačném případě je schválena automaticky. Po schválení je objednávka označena jako připravená k objednání (přebírá ji Nákupčí). Proces je pro představu zachycen v uvedeném BPMN diagramu, význam jednotlivých grafických elementů a postup k detailnějšímu modelu bude ukázán v příštím díle.

Nyní ještě krátce popíšeme prezentační vrstvu (frontend) a vrstvu business logiky (backend), se kterými bude proces v interakci. Frontend podobných systému tvoří často portálové řešení, v našem případě si ale vystačíme s jednoduchou webovou aplikací, jež bude umožňovat přihlášení uživatele a podle jeho role mu nabídne možnost vytvořit objednávku, sledovat založené objednávky a vyjádřit se k objednávce, která byla přiřazena ke schválení tomuto uživateli. Aplikace poskytne formuláře pro provedení všech interakcí s procesem. Samotná business logika, která zpracovává požadavky a pracuje s databází, je obsažena v EJB modulu, jenž je nasazen v aplikačním serveru GlassFish. K tomuto modulu lze přistupovat přes rozhraní webových služeb, a to jak z procesu, tak přímo z webové aplikace.

V příštím díle

V příštím díle budeme modelovat představený proces v nástroji Business Process Visual Architect. Ukážeme si, jak přistoupit k návrhu celého procesu a jak jej realizovat, včetně jemného úvodu do grafické notace BPMN. Srovnáme také úrovně, na kterých lze proces modelovat. Výsledkem příštího dílu či možná dvou bude kompletní návrh procesu v BPMN, podle kterého bude proces následně převeden do XML jazyka BPEL.

1. část: Proč BPM s open source nástroji

2008-02-01T23:15:00.003+01:00

Petr Vašíček, IBA CZ

Seriál je koncipován jako „end2end“ průřez celou problematikou. V jednotlivých dílech představí jednoduchý a názorný proces, na kterém bude ilustrován celý životní cyklus BPM, počínaje návrhem, nasazením (včetně integrace s backendovou a frontendovou částí aplikace) až po samotné sledování procesu a vyhodnocování jeho efektivity. Na základě získaných výsledků provedeme návrh vhodných úprav a následnou optimalizaci neefektivní části procesu. Seriál rovněž nastíní možnosti využití pravidel podnikání a řízení lidské interakce s procesem.

Obrázek 1: Životní cyklus BPM

Pro realizaci a optimalizaci procesu použijeme populární open-source platformy: kombinaci OpenESB + NetBeans a Intalio BPMS. Díky otevřenější povaze těchto nástrojů k BPM technikám může čtenář získat lepší povědomí o technologické stránce jednotlivých standardů a technologií než v případě komplexních komerčních řešení. Seriál současně představuje vhodnou cestu k zavedení BPM pro menší podniky, pro které jsou důležité nízké počáteční náklady a rychlé osvojení nových technologií. To jim může usnadnit případný pozdější přechod na pokročilejší komerční platformy.

Účelem seriálu není představit plně fukční a okamžitě použitelné řešení, ale spíše ukázat, že cesta k němu může vést i přes volně dostupné open-source nástroje. Pokud firma o zavedení BPM uvažuje, může seriál využít jako základ pro odstartování pilotního projektu. I proto budou články koncipovány hlavně jako praktický návod pro realizování modelového procesu s minimálními teoretickými „vsuvkami“. Předpokládáme, že frekvence jednotlivých článků bude 1-2 díly za měsíc a obsahová náplň seriálu se bude přizpůsobovat ohlasu čtenářů portálu.

Trochu teorie o BPMS

Systémy pro Business Process Management poskytují podporu pro modelování a optimalizaci business procesů v organizacích. Obsahují nástroje po pokrytí celého životního cyklu procesu - od analýzy a návrhu procesu až po jeho spouštění a monitorování. Procesy jsou navrhovány prostřednictvím grafických modelovacích jazyků, mezi nimiž se prosadila notace BPMN (Business Process Modeling Notation), de facto standard pro modelování business procesů (neznamená to ale, že by BPMN podporovaly všechny nástroje).

Mezi hlavní výhody BPMN patří čitelnost a přehlednost, což během tvorby procesu umožňuje každému (management, analytici, vývojáři) snadnou orientaci. Modely jsou poté (automaticky) převedeny do spustitelné podoby, většinou do XML jazyka BPEL (Business Process Executional Language). Po nasazení procesů na procesní server je umožněno procesy monitorovat a omezeně i zasahovat do jejich běhu.

Obrázek 2: BPMS komponenty

Nástroje pro BPM 1. 0 byly koncipovány spíše jako soubor menších komponent pro dílčí oblasti procesního modelování (návrh, spouštění), kdežto BPMS druhé generace již zahrnuje celý životní cyklus procesu a poskytuje celistvé nástroje s přívětivým uživatelským rozhraním.

Každý BPMS by měl minimálně obsahovat návrhář procesů, prostředí pro jejich spouštění, monitoring a podporu pro workflow (dlouho trvající procesy s lidskou interakcí) včetně potřebného uživatelského rozhraní (Human Task Management). Velice důležitá je podpora Business Rules, čili pravidel podnikání uložených vně procesu (databáze, XML, Excel, skriptovací jazyk), která se používají pro validační a rozhodovací akce v jeho průběhu.

Pokročilější BPMS počítají s BAM (Business Activity Monitoring) a udržováním verzí dokumentů vázajících se k procesům. Plné BPMS již vypadají jako kompletní ESB (sběrnice služeb), na níž jsou všechny komponenty napojeny, obsahují BI nástroj pro zpracování výsledků z BAM, repozitář metadat a další komponenty.

Na rozdíl od komerčních nástrojů nejsou open-source BPM platformy jednolitým komplexním nástrojem, ale buďto souborem nezávislých komponent, nebo sice jeden celistvě se tvářící nástroj, ale s omezenou funkcionalitou v porovnání s placenými alternativami. Nízké počáteční náklady jsou u těchto řešení vyváženy větším úsilím při prvotním osvojení. Je třeba zvolit a správně nastavit odpovídající technické prostředí, provést průzkum funkcí vybraného nástroje a ty, které neposkytuje, si případně doimplementovat. Vývojáři a procesní specialisté, kteří s nástrojem pracují, nejsou také tolik odstíněni od BPM technologií, musí lépe rozumět jejich principům a standardům v oblasti modelování obchodních procesů. To ale může být i výhodou a přispět k lepšímu pochopení těchto technologií, zvlášt při počátečním seznamování s BPM.

V příštím díle

se podíváme na konkrétní nástroje, jež budeme v seriálu používat a představíme si ukázkový proces, na kterém budeme BPM postupy a technologie demonstrovat.

O společnosti IBA CZ

2008-01-31T00:23:00.000+01:00

IBA CZ je outsourcingová softwarová společnost, která se specializuje na zakázkový vývoj software s využitím moderních technologii Java EE, portálů, BI, BPM a dalších.

Společnost IBA CZ je vývojovým centrem nadnárodní koporace IBA Group, které se specializuje na zakázkový vývoj software s využitím moderních technologií jako jsou Java EE, enterprise portály, BI, BPM a další. IBA CZ nabízí zejména outsourcingové služby v oblasti vývoje, údržby, podpory a migrace software. Kromě toho též nabízí konzultační, školicí a logistické služby v IT a v neposlední řadě se zabývá i prodejem vývojových nástrojů IBM Rational. IBA CZ byla založena v roce 1999, má pobočky v Praze a Brně a na konci roku 2007 dosáhla počtu cca 70 zaměstnanců.

Hlavní předností IBA CZ je možnost zapojit do lokálních projektových týmů offshore speciliaty z dalších vývojových center a tak zákazníkům nabídnout široké portfolio technologií, silné personální zázemí pro malé i velké projekty a optimální cenové podmnínky.

V oblasti BPM společnost IBA CZ vyvíjí procesně orientovanou portálovou platformu KUBIKI, která je postavena na opensource technologích Sun Glassfish, OpenESB a Liferay. KUBIKI jsou určeny nejen pro velké korporace, ale i pro společnosti v segmentu SME, kterým umožňují implementovat finančne dostupné moderní procesní prostředí. Vyladěná kombiace servisně-orientované architektury, procesní vrstvy a podnikového portálu snižuje náklady na intgerační nebo migrační projekty Zákazník dostává jednoduché, robustní, otevřené a plně standardizované BPMS prostředí, které může postupně rozšiřovat.

IBA Group patří mezi významné dodavatele na poli globálního outsourcingu. Díky počtu téměř 2000 vývojářů realizuje se svými zákazníky ve třiceti zemích offshore i nearhore projekty zaměřené především na IBM technologie (Lotus, WebSphere), mainframe, e-business, SAP a další.

Kontakty na IBA CZ

Jan Valdman
tel. 251 050 160

Jan Pavlovič
tel. 533 432 443