No title

Použití CASE/CABE pro řízení workflow ve firmě

Jan Jirovský Michal Juhás Autoři: Jan Krejčík

Ladislav Pelcl Jakub Zaplatílek Pro předmět:

CASE – Computer Aided Systems Engineering

Vyučující: Doc. Ing. Václav Řepa, CSc. Datum: 3. 5. 2007


1. 2.

3.

4.

5.

6.

Obsah Úvod .................................................................................................................................... 3

2.1.

Úvod ............................................................................................................................ 3

2.2.

Cíl práce ....................................................................................................................... 3

2.3.

Obecně o CASE ............................................................................................................. 3

2.4.

Druhy CASE .................................................................................................................. 5

2.5.

Přínosy vs. úskalí využití nástrojů CASE........................................................................... 6

2.6.

WORKFLOW.................................................................................................................. 7

2.7.

Procesní vs. funkční řízení .............................................................................................. 9

Standardy ............................................................................................................................12 3.1.

Úvod ...........................................................................................................................12

3.2.

BPMN ..........................................................................................................................15

3.3.

XPDL ...........................................................................................................................16

3.4.

Wf-XML .......................................................................................................................18

3.5.

ASAP rozšíření WF-XML 2.0 ...........................................................................................19

3.6.

Referenční model workflow ...........................................................................................20

Technologie .........................................................................................................................22 4.1.

Windows Workflow Foundation .....................................................................................22

4.2.

Web Services ...............................................................................................................22

4.3.

SOA.............................................................................................................................23

4.4.

BPEL............................................................................................................................23

Nástroje...............................................................................................................................27 5.1.

IBM Filenet Business Process Manager...........................................................................27

5.2.

SAP NetWeaver ............................................................................................................28

5.3.

BizTalk Server ..............................................................................................................33

5.4.

IBM WebSphere ...........................................................................................................47

5.5.

Sybase PowerDesigner..................................................................................................51

5.6.

ORACLE BPEL Process Manager.....................................................................................55

5.7.

Microsoft Visio..............................................................................................................58

5.8.

Soyatec eBPMN Designer ..............................................................................................63

5.9.

Enhydra JaWE ..............................................................................................................64

Zdroje..................................................................................................................................66

2/67


2.

Úvod

2.1. Úvod Žijeme v době, kdy se neustále zkracují obchodní cykly, svět se propojuje a nároky na softwarové systémy rostou rychlostí, kterou jsme si před několika lety ani nedokázali reálně představit. Vývoj software již dávno není doménou pouze hrstky individualit, ale celých vývojových týmů. A tento proces si již dnes nelze bez podpory počítačů dost dobře představit. Počítače a jejich podpora různým procesům se prosazuje i v dalších oblastech a právě jedna z nich je i tématem naší práce – Použití CASE/CABE pro řízení workflow ve firmě. Svou práci jsme rozdělili do několika dílčích částí. Nejprve se v úvodu pokusíme nastínit cíl naší práce a základní teoretická východiska a pojmový aparát, a dále se již blíže zaměříme na používané technologie, standardy a v závěrečné části se pokusíme shrnout přehled používaných nástrojů.

2.2. Cíl práce Cílem naší práce bylo v letošním semestru doplnit předchozí práce našich kolegů, kteří se stejným tématem zabývali již v minulých semestrech. Naší snahou bylo nejen v ucelené formě nastínit a popsat, jaké produkty a nástroje je možno nalézt na trhu, ale dále jsme se zaměřili též na používané technologie a standardy v dané oblasti. Možná trochu neskromně jsme si jako cíl stanovili i na základě výsledků předchozích prací podat komplexní přehled o stavu dané oblasti. Jen Vy můžete nyní posoudit, nakolik se nám tento smělý plán podařilo naplnit.

2.3. Obecně o CASE Od počátku vývoje software byla znatelná snaha o využití automatizovaných nástrojů, jejichž využití by tuto práci velmi usnadnilo. Původně byl zájem směřován hlavně na nástroje pro podporu programování jako jsou např. překladače, kompilery, assemblery atd… Postupem času se ale začali počítače stávat stále výkonnějšími a počítačové programy stále sofistikovanější. Především využívání interaktivních systému se sdílením času nastartovalo rozvoj editoru, debuggeru a analyzéru kódu. Postupem času se dalším vývojem z těchto aplikací vyvinuly robustní integrované CASE nástroje. V dnešní době vyvíjet jakýkoliv větší program, vést velký projekt, či navrhovat databázovou základnu je nemyslitelné bez pomoci CASE nástroje. Posláním CASE nástrojů je pomoci vývojáři, vedoucímu projektu, analytikovi, zkrátka komukoliv kdo participuje na projektu. Nezáleží jakou pozici zastáváte, opravdu komplexní CASE nástroj by měl při správném použití pomoci každému. Od dob, kdy se začínaly vyvíjet první softwarové aplikace, na ne bylo kladeno stále více požadavků, aplikace byly stále více robustnější a komplexnější, což vyvolalo potřebu automatizovaných nástrojů, které by zjednodušily fáze analýzy a návrhu těchto aplikací. S tímto souvisí i vznik disciplíny softwarového inženýrství, jakožto počítačové vědy zabývající se vývojem velkých aplikací. Ta zahrnuje nejen technické aspekty vytváření softwarových systému, ale i aspekty řízení, ekonomické aspekty a

3/67


aspekty kvality. Softwarové inženýrství představuje systematický a kvantifikovaný přístup k vývoji, provozování a údržbě software. Cílem této disciplíny je vytvářet tzv. užitečný software, což znamená software, který je dodán v termínu, pracuje bez chyb, je za stanovenou cenu a odpovídá požadavkům uživatelů. Zejména díky masovému vývoji aplikací jsou dnes i v této oblasti uplatňovány standardizované postupy. Nástroje dnes neodmyslitelně spojené se softwarovým inženýrstvím, které podporují vývoj software, se proto souhrnně označují termínem CASE. Zkratka CASE znamená Computer-Aided Software (nebo občas Systém) Engineering. CASE bývá casto definován jako: podpora procesu vývoje software, která je založena na

využití podpory počítačových prostředků, jejímž cílem je celkově zefektivnit celý proces vývoje software. Nástroje CASE jsou pak definovány jako: sada softwarových nástrojů podporujících určité

fáze vývoje informačního systému. Zkratka CASE vznikla na počátku osmdesátých let, kdy došlo ke shodě, že grafické prostředky pro znázornění datové základny (ve smyslu dat a jejich relací) a procesu zpracování dat se stanou významnou pomůckou při analýzách a návrzích informačních systémů. Od té doby začaly vznikat různé podpůrné nástroje nejen pro grafický návrh, ale i s možností vytvoření databáze o projektu, která obsahovala podrobnosti o datových prvcích a informačních procesech. CASE nástroje jsou dnes nabízeny v několika variantách. U většiny nástrojů je jádrem univerzální modelovací jazyk UML (Unified Modeling Language). Pokud se podíváme na CASE nástroj, první co uvidíme, je grafické rozhraní. Zde je možno modeloval nejrůznější typy diagramu, pro úplnost si zde uveďme alespoň ty nejběžnější: DFD diagramy, které dovolují provádět funkční analýzu; Class diagramy – pro modelování tříd; STD diagramy; procesní diagramy atd. Při používání CASE nástrojů při podpoře návrhu a vývoje softwarové aplikace či informačního systému je ovšem potřeba dodržovat určitá pravidla a postupy, které zaručí smysluplnost a efektivitu. Jedná se o metodiky, jakožto souhrny postupu a metod, které určují co, kdo a kdy se má řešit. Podpora metodiky prostředkem CASE vyžaduje především, aby tento prostředek pokrýval všechny fáze životního cyklu projektu. Je-li při tvorbě IS postupováno podle nějaké vybrané metodiky, pak je většinou její používání podpořeno adekvátním CASE systémem, který je nad metodikou takříkajíc „postaven“. Právě dostupnost CASE nástrojů byl a je často též rozhodující faktor, zda-li se metodika uchytí či nikoliv. Při výběru vhodné metodiky jsme bohužel občas omezeni nabídkou CASE nástrojů na trhu. Nutno zdůraznit, že zvlášť u tak rozsáhlých a komplexních systémů, jakými vyspělé CASE bezesporu jsou, se pod pojmem dostupnost skrývá další úskalí - nejde pouze o to CASE koupit, ale také nasadit, absolvovat školení a mít k dispozici kvalitní technickou podporu. Problém dostupnosti CASE prostředků je ovšem v poslední době řešen příchodem CASE systémů, které jsou do jisté míry na nástrojích uvažovaných metod nezávislé. Ty se často pod CASE "podsunou" v již předpřipravené podobě, tj. většinou jako množina zaměnitelných datových souborů. Takový popis vychází často z metamodelu, což je svým způsobem předpis, vytvořený právě pomocí výsledného produktu, který je popisován. V našem případě je popsána notace nástrojů objektových metod opět

4/67


pomocí této notace. Nutno podotknout, že CASE systémy založené na této filosofii se zdají být velkým příslibem do budoucna.

2.4. Druhy CASE V tomto odstavci uvedeme několik způsobů klasifikace nástrojů CASE dle: 1. interaktivity a. CASE nástroje, které jsou interaktivní ze své podstaty (např. nástroje podporující metodu návrhu) b. CASE nástroje, které nejsou interaktivní (tzv. vývojové nástroje - např. kompilery) 2. fáze projektu vývoje software, v níž jsou používány a. front-end CASE nástroje (využívány v dřívějších fázích projektu – např. nástroje na podporu návrhu) b. back-end CASE nástroje (využívány v pozdějších fázích projektu – např. nástroje podporující testování) 3. využití během celého životního cyklu software a. vertikální CASE nástroje (nástroje podporující jen dílčí krok životního cyklu software či dílčí oblast) b. horizontální CASE nástroje (nástroje podporující několik kroku životního cyklu software či více oblastí) 4. stupně integrace a. CASE tools (nástroje zabezpečující automatizovanou podporu libovolné úlohy životního cyklu software) b. CASE toolkits (soubor integrovaných softwarových nástrojů, který poskytuje částečnou či komplexní podporu jen v rámci jedné fáze životního cyklu software) c. CASE workbenches (množina integrovaných CASE tools nebo CASE toolkits, která poskytuje částečnou či komplexní podporu v minimálně dvou fázích životního cyklu software) d. I – CASE (představuje nejvyšší stupen integrace; propojení několika CASE tools, CASE toolkits a CASE workbenches) 5. fází životního cyklu informačního systému, v nichž jsou používány a. Pre CASE (podporuje činnosti předcházející vývoji IS – globální strategie) b. Upper CASE (podporuje tvorbu informační strategie a fázi analýzy) c. Middle CASE (podporuje tvorbu globálního a detailního návrhu IS) d. Lower CASE (podporuje fázi implementace) e. Post CASE (podporuje fázi uvedení IS do provozu, provoz, údržbu, reengineering)

5/67


Toto členění samozřejmě není kompletní, jeho cílem je pouze poukázat na širokou varietu CASE nástrojů, aby si pozorný čtenář udělal představu. Podrobně budou CASE nástroje vztahující se k řízení workflow rozebrány v závěrečné části této práce.

2.5. Přínosy vs. úskalí využití nástrojů CASE Využití nástrojů CASE s sebou samozřejmě přináší celou řadu výhod, pokusíme se zde shrnout ty nejpodstatnější. •

Vyšší produktivita práce Díky automatizaci práce, kterou s sebou využití CASE přináší, dochází k urychlení zpracování a tím

zvýšení produktivity práce (dle odhadů až zdvojnásobení). Samozřejmě obrovským

přínosem je též podpora práce několika vývojářů, respektive návrhářů, na projektu současně. •

Menší chybovost Využití nástrojů CASE s sebou přináší možnost průběžné kontroly, které vedou k lepšímu a rychlejšímu odstraňování chyb. Není potřeba asi dodávat, že čím dříve jsou chyby detekovány a odstraněny, tím nižší jsou náklady s tím spojené. Čím větší a robustnější systém, tím je identifikace chyb obtížnější a jejich odstraňování problematičtější a nákladnější.

•

Snadnější údržba a další vývoj výsledného produktu Výsledkem kvalitnějšího návrhu, dokonalejší analýzy, automatického generování kódu, automatizovaného testování a včasného odstranění chyb je vyšší kvalita celého systému. Díky generované dokumentace je též snadnější a tudíž i levnější údržba celého systému během jeho životního cyklu.

•

Kvalitnější dokumentace CASE nástroje umožňují snazší tvorbu dokumentace, která je navíc automaticky generována.

•

Větší participace uživatelů na vývoji produktu Využití CASE nástroje umožňuje (převážně díky srozumitelným diagramům) lepší možnost participace uživatelů na vývoji produktu, což vede ke zkrácení doby nutné k zaučení uživatelů v práci s novým systém.

Ačkoliv s sebou využití CASE nástrojů bezesporu přináší mnoho výhod, je potřeba zmínit též úskalí, na která lze při používání CASE nástroje narazit: •

Nevhodný výběr nástroje či jejich nevhodná kombinace Abychom díky využití CASE nástroji dosáhli úspory nákladu, je důležité dbát na správný výběr nástroje. Musíme především věnovat pozornost integraci nástrojů CASE a integraci dat přes všechny platformy a dále musíme mít na zřeteli možnost přechodu z jednoho nástroje CASE na jiný.

6/67


•

Vysoké pořizovací náklady Nástroje CASE nejsou levnou záležitostí. Při kalkulaci nákladu na jejich pořízení nesmíme opomenout zahrnout také náklady na potřebný hardware, software, školení zaměstnanců a v neposlední řadě také náklady na podporu. Teprve tyto celkové náklady porovnáváme s úsporami, které si od zavedení nástroje slibujeme.

•

Vysoké nároky na znalosti a dovednosti uživatelů Při zavádění CASE nástrojů musíme počítat se zvýšenými nároky na kvalitu a znalosti uživatelů. Pro správné používání je nutné si osvojit celou řadu technik, které jsou závislé na konkrétním typu nástroje.

2.6. WORKFLOW Pro workflow proces existuje velké množství popisů a definic, které se liší podle zpracovávané problematiky a použité technologie řešení. Definice workflow jsou od svého počátku spojeny s různými softwarovými kategoriemi, zahrnujícími elektronický mail, groupware, document imaging, document management nebo form processing. Cíl každé nové definice bychom mohli charakterizovat jako neustálou snahu o rozšiřování již tak elastických hranic definice tohoto termínu. Workflow můžeme velice obecně charakterizovat jako technologický nástroj, který umožňuje automatizovat obchodní procesy (Business Process Automation) a procesy řízení (Business Process Control). Ocitujeme-li obecně uznávanou definici The Workflow Management Coalition, pak: "Systém Workflow

Management je takový systém, který poskytuje procedurální automatizaci podnikového procesu řízením sledu pracovních činností a vyvolání příslušných lidských zdrojů a/nebo zdrojů informačních technologií přiřazených různým krokům činností." Zjednodušeně se tedy dá říci, že workflow je uzavřený podnikový proces nebo subproces zahrnující automatické činnosti systému i činnosti, jež potřebují interakci uživatelů. Definovali jsme si tedy workflow, ale nezodpovězenou otázkou zůstává, co si máme představit pod pojmem proces? Je to veškerá činnost ve firmě, která musí být organizována, řízena a

kontrolována. Jedná se tedy nejen o oběh dokumentů, ale v širším slova smyslu i o oběh informací a vzájemné vazby, pravomoci vyřízení, termíny atd. Jak se odlišuje procesní zpracování od běžné elektronické pošty nejlépe ukazuje obrázek 1.

7/67


Obrázek 1: Rozdíl mezi e-mailem a procesní komunikací

U procesů se setkáme s pojmy workflow a workgroup. Co je jejich obsahem, naznačují obrázky 2 a 3. Obrázky 2 a 3: Workgroup komunikace

Praxe ukazuje, že procesy ve společnostech mají zpravidla charakter několik základních typů, které lze znázornit pomocí následující tabulky:

8/67


Tabulka 1: Základní typy procesů

Proces - Strukturovaný Proces - Proměnlivý

Jednotlivý krok - Strukturovaný

Jednotlivý krok – Proměnlivý

Typ 1 - Workflow

Typ 2 - Workflow s ad-hoc změnami

Typ 3 - Workgroup se

Typ 4 - Workgroup s proměnlivými

standardizovanými elementy

pracovními kroky i průběhem

Typ 1 je „klasický“ workflow proces – vše je pevně dáno, jasná pravidla hry pro jednotlivé pracovní kroky, výjimky se nevyskytují. Typ 2 je workflow proces, kdy může v určitém procentu případů nastat situace, která se z žádného podstatného hlediska nedotkne průběhu workflow, je však potřebná (např. konzultace uživatele, který se standardně průběhu neúčastní, spuštění tzv. subworkflow pro specifickou úlohu apod.). Typ 3 je proces ad-hoc, který využívá některé předdefinované postupy a je jej alespoň částečně možné předdefinovat. Typ 4 je proces ad-hoc, kde je nutno vše definovat individuálně Závěrem jeden příklad z praxe. Workflow může vypadat tak, že workflow engine generuje tzv. pracovní položky (workitems), které představují konkrétní dílčí kroky procesu. Mohou-li být provedeny automaticky, systém je provede, vyžadují-li interakci některého pracovníka, engine jej určí a zašle mu pracovní položku prostřednictvím elektronické pošty jako zprávu se zvláštními vlastnostmi. Zvláštní vlastnosti představuje především tzv. proveditelnost pracovní položky, což může být v praxi realizováno například spustitelnou přílohou. Ve své schránce si příslušný pracovník položku vyzvedne a zpracuje. Za pojmem zpracuje se skrývá spuštění spustitelné přílohy a provedení programu, který je přílohou reprezentován. Po zpracování engine vygeneruje další pracovní položku a předloží ji systému nebo dalšímu pracovníkovi. A to stále dokola, dokud není celý proces ukončen. Nezanedbatelnou vlastností workflow je jeho provázanost s organizační strukturou podniku. Ke každé pracovní položce vyžadující interakci musí workflow engine přiřadit zpracovatele. To může zpravidla provést několika způsoby od ad hoc přiřazení přes výběry ze speciálních tabulek a podobné částečně sofistikované postupy až po výběr podle pravidel vztahujících se k organizační struktuře. Ta může být jak běžně používaná, tak specielně vytvořená pro dané workflow. Navíc lze podle potřeby konkrétního oběhu měnit, komu bude položka zaslána. Např. v případě schvalování faktury lze podle výše částky zaslat požadavek na schválení nižší nebo vyšší schvalovací instanci.

2.7. Procesní vs. funkční řízení Závěrem této části se ještě velmi stručně zmíním ve světle předchozí subkapitoly o systému řízení společností. Současná dynamická doba staví podniky do situace, kdy jsou pod tlakem stále nových zákaznických požadavku, netrpělivého očekávání akcionářů, domácí i zahraniční konkurence a neustále se rozvíjejících informačních a komunikačních technologií. Snaha získat v tomto prostředí stabilnější pozici vedla mnohé podniky k přechodu od méně efektivního funkčního řízení k řízení procesnímu.

9/67


Pokud se ptáte, co to vlastně ten procesní přístup je, lze využít výstižnou formulaci, která zazněla na jedné konferenci: "Funkční přístup znamená namalovat obdélníčky s nápisem, co se v nich asi má dělat, najmout lidi, kteří o sobě říkají, že to umí ... a potom doufat, že se spolu nějak dohodnou. Procesní přístup je to, když se ví, co je nutno dělat pro uspokojení zákazníka a je jednoznačně definována kvalifikace, vstupy a informace, které jsou nutné pro každou činnost. Potom je snadné vybrat lidi, kteří umí to, co se po nich vyžaduje a budou to moci bez dohadování dělat." Východiskem pro procesní řízení je tedy zákaznická potřeba a její uspokojení produktem/službou. Každý produkt (výrobek nebo služba) vzniká určitým sledem činností, tedy procesem. Pro každodenní chod procesu pak podnik potřebuje odpovídající zdroje. Schématicky je vše znázorněno na obrázku níže. Obrázek 4: Procesní přístup k řízení společnosti

Procesnímu řízení je přizpůsoben i nový způsob zobrazování organizačních vztahů pomocí procesního (postupového) diagramu zahrnujícího všechny potřebné činnosti, vazby mezi nimi, jejich souslednost a zodpovědné pracovníky. Tento způsob organizování také zahrnuje všechny pracovníky, kteří se na procesech podílejí. Jsou stanoveny rozhodovací činnosti a pracovníci zodpovědní za jejich řešení. Řádná implementace procesního řízení pak muže podniku přinést tyto výhody: •

zvýšení rychlosti řízení a zkrácení doby odezvy na požadavky zákazníka

•

snížení potřeby řídící operativní práce, stanovení jednoznačných pravomocí a odpovědností

•

zvýšení výkonnosti podniku

•

možnost analyzování procesu a jejich zlepšování

•

splnění základní části požadavku norem řízení jakosti ISO 9000:2000

Procesní řízení se tak diametrálně odlišuje od řízení funkčního, které je vyjadřováno organizačním schématem. Organizování tímto funkčním způsobem řeší spíše otázku dělby práce v podniku, specializaci pracovníku a jejich kompetencí. Cílem podniku je samozřejmě všechny probíhající procesy provádět co možná nejefektivněji, s nejnižšími náklady a nejvyšším užitkem. Za tímto účelem je tedy nutné procesy měřit, monitorovat a na základe výsledku je pak modifikovat a optimalizovat. Právě tomuto má napomoci nasazení technologií a produktů, které budou popsány dále. Na závěr ještě pro zajímavost doplním postup zavádění procesního řízení (projektu změny), který je zjednodušeně uveden na obrázku 2.

10/67


Obrázek 5: Postup zavádění procesního řízení

11/67


3.

Standardy

3.1. Úvod Již v roce 2003 existovalo 10 sdružení pro tyto standardy, přitom 7 z nich se věnovalo standardům modelování. BPM (Business Process Modeling) a modelování workflow (WF) rozhodně nedostatkem standardů netrpí. Mezi nejdůležitější patří standard společnosti OASIS – BPEL, standardy BPML a BPMN od BPMI, různé choreografické standardy konsorcia W3C, referenční model od WfMC, MDA specifikace z dílny konsorcia OMG a ještě jednou od společnosti OASIS, tentokrát jazyk BPSS. Následující sekce jednotlivé společnosti a jejich standardy představuje. Prvním je Business Process Execution Language for Web Services (BPEL4WS), často zkracovaný jako BPEL. Tento standard nachází největší podporu ve velkých společnostech jako jsou IBM, Microsoft, Oracle, BEA a tím pádem má největší šanci válku standardů vyhrát. BPEL proces je webovou službou s připojenou definicí procesu v XML souboru. BPEL proces se může působit na ostatní procesy nebo se může naopak chovat podle ostatních procesů, jednodušeji řečeno BPEL proces může volat jinou webovou službu, nebo je naopak volán jako webová služba. BPEL je spustitelnou definicí procesní logiky, ale neumožňuje plně zpětné vykreslení přehledového procesního designu. Druhým standardem je Business Process Modeling Language (BPML), od organizace Business Process Modeling Initiative (BPMI), který je podobně jako BPEL založen na XML. Business Process Modeling Notation (BPMN), je další specifikací od BPMI – jde o grafickou sofistikovanou notaci pro znázornění procesu, která má být srozumitelná pro odborné útvary, procesní analytiky i vývojáře.. Významnou součástí této specifikace je zejména mapovanání na jazyk BPML – rival BPEL, což umožňuje vykonávání procesů designovaných pomocí BPMN na některém s BPEL enginů. Třetím standardem je Webservice Choreography, který je hlavním předmětem výzkumu světového konsorcia W3C. Webservice Choreography popisuje z globálního úhlu pohledu jak jsou služby uspořádány v řízeném pohledu trvalých vícenásobných účastníků. Tento globální pohled se liší od lokálního pohledu na proces v jazyce jako je BPEL. BPEL proces je procesem jednoho aktéra, kdežto u Choreography jde o model skupiny aktérů. Choreography Description Language (WS-CDL) je standard doporučený konsorciem W3C. Dalším v řadě je Workflow Management Coalition (WfMC), který publikuje BPM referenční model, jako set rozhraní pro různé části BPM architektury. V tomto referenčním modelu vystupuje služba ustanovená jako centrální, která vykonává procesy vytvořené pomocí designéru procesů. Přestože WfMC nespecifikuje standardní grafickou notaci, poskytuje exportovatelný XML formát zvaný XML Process Definition (XPDL). Proces vytvořený XPDL-vyhovujícím návrhovým nástrojem může běžet na WfMC enginu. XPDL je formát výměny grafické prezentace procesů, který navíc podporují všichni výrobci nástrojů pro BPM a hodí se tak i pro převod mezi různými notacemi procesních modelů.

12/67


Cílem pátého standardu – Model Driven Architecture (MDA) organizace Object Management Group (OMG) není vytvořit další jazyk pro procesy nebo rozhraní, ale rozvíjet abstraktní BPM modely, které vyhovují Model Driven architektuře. Myšlenkou MDA je sjednocení různorodých přístupů k danému softwarovému problému. Software má zdánlivě nespočetně mnoho typů modelů: relační modely, objektově orientované modely, business proces modely, a další. MDA akceptuje rozličnost těchto modelů, přitom poskytuje mechanismus jak mapovat různé typy modelů vzájemně na sebe. Klíčovou myšlenkou je postavit všechny modely na společném základu. Obrázek 6: Časová linie vývoje standardů

Dále v textu se také setkáme s pojmem webová služba a asynchronní webová služba. Domnívám se, že je nutné se zde blíže zmínit o tom co si pod tímto pojmem máme představit. Webová služba je aplikační komponenta přístupná přes standardní otevřený protokol, která k provádění distribuovaných výpočtů využívá tři základní principy. Není však bezpodmínečně nutné, aby webová služba použila všechny tyto principy. Například použití registrů služeb nemusí být klíčové pro fungování webových služeb.

13/67


•

1. Služba je dostupná přes standardní protokol Tento princip je nejčastěji realizován protokolem SOAP (Simple Object Access Protocol), který specifikuje formát zpráv, které si vyměňuje služba a konzument (ten, kdo používá webovou službu). Oproti původním technologiím jsou možnosti SOAP omezené, ale pro svou jednoduchost se dočkal celé řady implementací na rozličných platformách. SOAP byl navržen pro internet, přesto je nezávislý na přenosovém protokolu. Koncept struktury SOAP je obecný a je možné ho rozšířit pomocí hlaviček, které mohou obsahovat další metadata. Dnes bývá pro přenos SOAP zpráv nejběžněji používán protokol HTTP(S).

•

2. Služba nabízí popis svého rozhraní Webová služba nabízí dostatečný popis svého rozhraní, na základě kterého je kdokoliv schopen službu konzumovat. Popis rozhraní je realizován pomocí jazyka WSDL (Web Service Description Language), který zjednodušeně řečeno popisuje operace, vstupní a výstupní parametry webové služby. Pokud tedy chcete používat veřejně přístupnou webovou službu, potřebujete znát pouze její popis (WSDL) a URL adresu.

•

3. Služba je objevitelná Objevitelnost webové služby je realizována prostřednictvím registru UDDI (Universal Discovery Description and Integration), který představuje jakési zlaté stránky pro webové služby. V registru mohou být uloženy základní informace o službě, jejím rozhraní, vlastníkovi služby nebo například podmínkách. Registr by vám měl umožnit pomocí dotazů nalézt službu, která bude vyhovovat vašim požadavkům. Původní koncept UDDI jako veřejného registru plného referencí na webové služby se v praxi neujal, takže registry služeb dnes nacházejí uplatnění především ve velkých organizacích.

K již široce používaným standardům (XML, SOAP, WSDL, HTTP) přibyly konečně specifikace, které zreálnily využití webových služeb v praxi (např. WS-ReliableMessaging, WS-Addressing, WS-Security a další) a které dále rozšiřují syntaxi WSDL. Samotné WS však mají v podnikové praxi omezené využití. Reprezentují zpracování typu klient/server se všemi jeho nevýhodami. Termínem "samotné" je zde myšleno využití jen základních stavebních kamenů WS, tedy HTTP plus SOAP plus WSDL. Bez úložiště pro metadata webových služeb, bez nástrojů pro správu, monitorování, logování nebo orchestraci nemohou WS doznat celopodnikového využití. K volání webových služeb, lze použít jak synchronního, tak asynchronního režimu. Pokud je služba volána v synchronním režimu, čeká program na její dokončení a vrácení výsledků. Teprve potom pokračuje dále. Tento režim nemusí být ale vždy žádoucí. Může dojít ke ztrátě spojení a nebo může být komunikace pomalá. Potom je vhodné použít asynchronní režim. Ten lze použít pouze tehdy, pokud nejsou výsledky volání webové služby okamžitě nutné pro další průběh programu. Při asynchronním režimu dochází k voláním webové služby, ale program nečeká na její dokončení a okamžitě pokračuje v dalším průběhu. výsledky dokončené webové služby zjistí pomocí delegáta

14/67


(událostní metody, kontrolující, zda jsou již data k dispozici) a nebo opakováním vlastního testu na přítomnost požadovaných dat.

3.2. BPMN Standard BPMN (Business Process Modeling Notation), byl vyvinut, aby umožnil tvořit srozumitelné grafické znázornění business procesů. Tento standard byl vytvořen (verze 1.0 publikována v květnu 2004) skupinou BPMI (Business Process Management Initiative) a v roce 2006 standardizován konsorciem OMG (Object Management Group). Stěžejním úkolem bylo poskytnout notaci, která by byla čitelná pro všechny uživatele – od analytiků přes programátory až po takové uživatele, kteří budou procesy monitorovat a řídit. BPMN je také možné, díky jeho XML povaze, také využít pro generování dalších formátů (XPDL, BPEL, BPEL4WS). Díky tomu BPMN vytváří jakýsi most mezi business orientovanou analýzou a designem procesů a jejich implementací (IT orientace). Základem BPMN je takzvaný Business Process Diagram (BPD), který je založen na znázornění toku jednotlivých kroků procesu pomocí různých významových symbolů (elementů). Základními elementy jsou tyto: •

Objekty procesních vláken (Flow objects) o

Události

o

Činnosti

o

Brány

•

Propojovací objekty (Connection objects)

•

Kontexty objektů (Plovací dráhy, Swim lanes)

•

Artefakty (Artifacts)

Obrázek 7: Základní elementy BPMN

15/67


Ke každému základnímu elementu obsahuje BPMN mnoho dalších podřízených elementů, které vyjadřují další vlastnosti (například rozlišení druhů událostí, násobnost, opakovanost činností, druhy rozhodování, synchronizace, druhy propojení) Obrázek 8: Ukázka BPMN diagramu – eBPMN Designer (www.soyatec.com/ebpmn)

Jelikož bylo o tomto standardu napsáno již mnoho jiných dokumentů, odkážeme čtenáře pouze na jiný zdroj informací a budeme se dále věnovat jiným standardům. Tímto zdrojem jsou oficiální webové stránky http://www.bpmn.org/.

3.3. XPDL Standard XPDL je podle jeho tvůrců (WfMC – Workflow Management Coalition) široce používaným jazykem pro definici procesů. Jedná se o BPM standard, který je podporován širokým spektrem aplikací – ERP systémy, call centra, CRM systémy, Business Intelligence, Business Activity Monitoring (BAM), ECM, nástroje pro procesní modelování a simulaci procesů atd. Za tajemnou zkratkou XPDL se skrývá čtveřice slov: XML Process Definition Language, do češtiny přeložitelný jako Jazyk pro definici procesů založený na XML. První verze tohoto jazyka byla nazývána Workflow Process Definition Language (WPDL). Tato verze byla poprvé představena v roce 1998. Tento procesní meta-model obsahoval všechny klíčové části nutné pro automatizaci workflow. Ve stejném roce se objevily i první standardy založené na

16/67


jazyce XML. Pracovní skupina 1 tento standard přepracovala a představila ho již pod jménem XPDL (verze 1.0). XPDL 1.0 byla WfMC uznána v roce 2002, následně byl tento standard implementován do mnoha nástrojů, jako svůj výměnný formát. V roce 2004 se WfMC začala hlásit k BPMN (Business Process Modelling Notation), což je standard pro vizualizaci procesů. XPDL bylo rozšířeno tak, aby pomocí XML dokázalo popsat BPMN diagramy. Tato verze byla pak v říjnu 2005 standardizována jako XPDL 2.0. Tato verze je zpětně kompatibilní s původní verzí 1.0. XPDL se pro svůj původ v XML používá různými nástroji především jako výměnný formát. Jak bylo řečeno je implementován do mnoha nástrojů pro návrh a správu procesů. Existují však nástroje, které primárně používají právě formát XPDL. Představitelem je například open-source řešení od společnosti Enhydra (framework Enhydra Shark a editor Enhydra JaWE – Java Workflow Editor). Obrázek 9: Enhydra JaWE

Cílem XPDL je uchovávání a výměna procesních diagramů. Byl vytvořen s cílem umožnit jednomu nástroji modelovat procesní diagram a jinému tento diagram otevřít a editovat a dalšímu případně spustit procesní model atd. Aby nedošlo ke špatnému pochopení, ještě raději uvedu, že XPDL není spustitelným procesním jazykem jako je BPEL.

17/67


Celý standard je popsán pomocí DTD (Document Type Definition) nebo XML schématu (oboje standardy XML), ve kterých jsou definovány použitelné elementy, jejich atributy případně jejich povinnosti a násobnosti, v případě XML schématu i datové typy. Přesný popis obou dvou definic je na webu WfMC v těchto souborech: •

http://www.wfmc.org/standards/docs/TC-1025_10_xpdl_102502.pdf

•

http://www.wfmc.org/standards/docs/TC-1025_xpdl_2_2005-08-16.pdf

Někdy se také hovoří o hodnotovém řetězci BPMN – XPDL – BPEL. Tento řetězec začíná tvorbou procesního diagramu (BPMN). Tyto diagramy bývají uloženy jako XPDL soubory a nakonec jsou části procesu přeloženy do spustitelné formy (BPEL) – překlad se týká především těch částí, kde dochází k výměně datových zpráv a ne lidské interakci. Specifikaci formátu XPDL počítá s tím, že budou zprávy posílány mezi různými systémy. Proto jsou definovány tak, aby byli kompatibilní se standardem WSDL (Web Services Description Language). WSDL soubory se využívají pro definici formátu datových toků mezi jednotlivými komponentami servisně orientovaných architektur. Tyto zprávy jsou zasílány pomocí protokolu SOAP. WSDL jsou vlastně XML schémata, která popisují tvar těchto zpráv – jejich elementy, atributy atd.

3.4. Wf-XML Standard jazyka Wf-XML je rozšířený interface, který umožňuje komunikovat mezi WfMS (Workflow Management Systems) a externími službami. Rozhraní vytváří procesy a jejich instance pracující s asynchronními (požadavek/odpověď) protokoly. Dnešním trendem je XML-driven workflow, tedy takový systém, který si o zpracovávaných datech dokáže zjistit potřebné informace sám (automatizované), nebo mu jsou tyto informace přiřazeny pro zadávání (manuální) – a podle nich pak automaticky pobíhá vlastní zpracování tiskových dat. Wf-XML 2.0, od WfMC, propojuje možnosti BPM a modelování workflow. Business proces engine je speciální typ asynchronní služby. Průběh takové služby je znázorněn takto: spuštěna, ke službě jsou přiřazeni lidé, služba je dokončena v určitý čas. Některé BPMS mají integrovány různé konektory, ať již obecné, nebo vytvořené pro konkrétní software. Rozhraní na vyšší úrovni představuje integrace na úrovni samotných BPMS. Pod tím si lze představit schopnost jednoho BPMS zavolat v rámci svého procesu subproces jiného BPMS. Standardy definující komunikační jazyk pro tato volání jsou především Wf-XML , AWSP, WSDL. Workflow XML (Wf-XML) rozhraní umožňuje vybrané službě komunikovat za účelem rozdělení jednoho procesu jiným. Na následujícím obrázku je WfMC model zobrazen:

18/67


Obrázek 10: Model WfMC

Detailní popis Wf-XML najdete na: http://www.wfmc.org/standards/docs/WfXML20-200410c.pdf

3.5. ASAP rozšíření WF-XML 2.0 Společnost OASIS vyvinula komunikační protokol ASAP (Asynchronous Service Access Protocol) za použití technologie SOAP (Simple Object Access Protocol) a standardu Wf-XML. ASAP nabízí možnost jak spustit, monitorovat a ovládat asynchronní webové služby. Důležité je, že všechny tyto operace lze provádět vzdáleně. Dva BPM systémy mohou zasílat zprávy, koordinovat aktivity nebo kontrolovat stav procesu do té doby než je dosaženo požadovaného cíle. ASAP rozšiřuje Wf-XML tím, že přidal možnost obdržet definici procesu a monitorovat současný stav právě běžící instance procesu. ASAP je webový protokol, který je používán k přístupu k určité službě, které může dokončení trvat poněkud déle. Jiné protokoly nejlépe pracují v případě, kdy služba dokáže odpovědět na podnět maximálně do dvou vteřin. ASAP je vhodné použít v případě, že proces trvá v rozmezí od jedné minuty až do několika měsíců. Tato služba může být buď plně automatická, manuální nebo i kombinovaná. Právě tato schopnost pracovat se službami automatizovanými nebo manuálními činí ASAP vhodným protokolem pro B2B a vnitropodnikové služby. ASAP ustanovil, že je zapotřebí standardní protokol pro připojení a práci s asynchronními službami a je jedno jestli jsou implementovány jako procesní enginy nebo ne. Právě Wf-XML nabízí možnost, jak propojit procesně orientované nástroje. Pomocí tohoto modifikovaného jazyka mají nástroje možnost rozpoznat a modelovat definice procesů a to i vzdáleně. Detailní popis protokolu najdete na URL: http://www.oasis-open.org/committees/download.php/4902/ASAP-Wf-XML%20Cookbook.pdf

19/67


3.6. Referenční model workflow WfMC vytvořila při své činnosti kromě standardů jako XPDL také tzv. Referenční model workflow (Workflow Reference Model, rok 1993), který složí jako návod (či schéma) pro popis společních rysů modelovaných procesů. Z následujícího schématu je vidět rozdělení problematiky do několika dílčích oblastí. Obrázek 11: Referenční model workflow

Tyto oblasti jsou následující: •

Definice procesu

•

Jádro workflow

•

Napojení na jádro jiného workflow

•

Klientské aplikace

•

Volané aplikace

•

Administrační a monitorovací nástroje

Model by měl přispět k zlepšení vzájemné kompatibility různých implementací v rozličných systémech. Všechny systémy pro podporu workflow obsahují množství vlastních komponent, které spolu interagují. Aby byla zajištěna spolupráce různých systémů od různých výrobců, bylo potřeba vytvořit standardizované rozhraní a výměnný formát dat mezi systémy. Na schématu jsou vidět hlavní komponenty workflow architektury a rozhraní mezi nimi. Referenční model pak tyto komponenty dále rozvádí a specifikuje.

20/67


Jádro workflow je obklopeno rozhraními, které jsou označovány jako WAPI (Workflow Application Programming Interface). Celkem bylo definováno pět rozhraní, které byly původně specifikovány na business úrovni (bylo řečeno, co má rozhraní dělat, čeho dosáhnout pomocí business pravidel). Tato specifikace byla krátce nato následována detailním abstraktním popisem a nakonec byla většina rozhraní popsána na závazné implementační rovině. Tabulka 2: Přehled rozhraní uvnitř Referenčního modelu První rozhraní (interface 1) Jádro ↔ Definice procesu

Výměna dat definice procesu mezi nástroji BPR, workflow systémy a databázemi definic procesů

Druhé rozhraní (interface 2) Jádro ↔ Klientské aplikace

Integrace klientských aplikací s různými workflow systémy. Podpora pro přenositelnost či znovupoužitelnost klientských aplikací.

Třetí rozhraní (interface 3) Jádro ↔ Volané aplikace

Integrace s aplikacemi třetích stran. Implementace nakonec postupně vedla k zavedení Wf-XML (verze 2) přes SOAP.

Čtvrté rozhraní (interface 4) Jádro ↔ Jiný systém

Komunikace dvou workflow systémů.

Páté rozhraní (interface 5) Jádro ↔ Administrační nástroje

Umožnit sledování, audit a administraci workflow uvnitř systému.

Komunikace mezi jednotlivými složkami Referenčního modelu je vlastně zabezpečena voláním funkcí jednotlivých rozhraní mezi těmito komponentami. Především čtvrté rozhraní pak přímo nabádá k využití SOA (servisně orientovaná architektura), což je implementováno jako Wf-XML přes SOAP (jeden z protokolů SOA využívající XML jako výměnného formátu).

21/67


4.

Technologie V nasledujúcom texte rozoberieme najčastejšie sa vyskytujúce technológie – Windows Workflow

Foundation, Web Services, architektúru SOA a zameriame sa predovšetkým na BPEL.

4.1. Windows Workflow Foundation Technologie Windows Workflow Foundation doplňuje .NET Framework skupinou workflow orientovaných komponent, které umožní vývojářům definovat, zkompilovat, spustit instanci, ladit a sledovat workflow. Windows Workflow Foundation spolu s Windows Presentation Foundation a Windows Communication Foundation tvoří nové .NET framework. Windows Workflow Foundation umožňuje programům, aby byly vyjádřeny jako deklarativní, dlouhotrvající procesy – workflow. Narozdíl od tradičních Microsoft .NET Framework programů, na workflow založené programy jsou typicky specifikovány v deklarativním Extensible Application Markup Language (XAML) dokumentu, který specifikuje strukturu programu v termínech doménově specifických aktivit. Tyto aktivity jsou pak implementovány v tradičních CLR (Common Language Runtime) programovacích jazycích jako je C# nebo Visual Basic.

4.2. Web Services Web Services je technologie, která umožňuje aplikacím komunikovat nezávisle na programovacím jazyku a platformě. Je definován interface pro výměnu dat a zpráv prostřednictvím standardizovaných XML dokumentů. Používané protokoly jsou založeny na XML a popisují, jakým způsobem se data mezi službami vyměňují a formát těchto dat. Koncept webových služeb spojuje princip komponentního programování a internetových technologií. Komponentní programování je založeno na faktu, že aplikace využívá funkcionalitu komponenty bez toho aby znala implementační detaily. Komponenta pouze zveřejní svůj interface, který se nemění v průběhu životního cyklu komponenty. V případě webových služeb je interface zveřejněn v internetovém prostředí. Komponenty poskytují sadu metod, které jsou přístupné přes jasně definovaný protokol prostřednictvím počítačové sítě. Aby byla zaručena skutečná platformní i jazyková nezávislost, pro jakýkoliv popis jakýchkoli dat je používán jazyk XML. Webové služby pracují nad abstraktními modely, takže je možné dynamicky popisovat data, datové struktury a formáty – webové služby jsou „samo popisné“. To dává vývojářům mnohem větší možnosti. Webové služby zpravidla implementují určitou funkčnost. Z jednotlivých služeb je možné vytvářet další – kompozitní webové služby, vytvářet workflow a business procesy. Současně WS svým konceptem překonávají mentální bariéru mezi vývojáři a manažery, protože na pojmu služba se dokážou shodnout, lépe komunikovat a vyjádřit obsah (funkčnost) služby. Webové služby umožňují komunikovat navzájem nezávisle na platformě a programovacím jazyku a přizpůsobit existující aplikace novým požadavkům. Proces publikace služby, její vyhledání a připojení je realizováno následujícími protokoly:

22/67


•

Vyhledání služby - service discovery

•

Přenos služby - na principu HTTP

•

Popis služby - service description

•

XML komunikace - XML messaging

Pro webové služby jsou podstatné tři protokoly: •

UDDI (Universal Description, Discovery and Integration) představuje katalog dostupných webových služeb (obdoba Zlatých stránek).

•

WSDL (Web Service Description Language) popisuje, jakým způsobem je možné se službou komunikovat, jaké metody je možné volat a jejich parametry, popis formátu dat a datových struktur.

•

SOAP (Simple Object Access Protocol) je určen k výměně zpráv mezi webovými službami.

4.3. SOA SOA představuje zcela nový přístup k vývoji software, nikoliv technologii samotnou. Základním pravidlem této architektury je distribuce dat a služeb. Koncept se opírá o tvorbu takové softwarové architektury, která se skládá z volně pospojovaných, nezávislých aplikačních služeb, a svou podstatou se snaží o dokonalejší naplnění uživatelských potřeb. Tento koncept však není vázán na konkrétní integrační technologii – kromě dominujících technologií lze tedy použít i standardy CORBA či DCOM. Služby pracují jako autonomní aplikace. Aplikační služba je tedy samostatná komponenta, která přijímá požadavky a vrací odezvy skrze definované rozhraní. Typicky je toto rozhraní tvořeno webovými službami, z čehož plyne technologická nezávislost služby a možnost rozptýlení služeb po síti. „Poskládání“ těchto služeb tak, aby implementovaly firemní proces, nazýváme orchestrací. Zorchestrované služby poté plní funkci aplikační logiky, která zpracovává data. Jazyky jako BPEL či WS-coordination jdou ještě dále, protože tvoří metody jak přímo popsat firemní workflow a na základě tohoto popisu umožňují služby efektivně zorchestrovat. Jazyk BPEL bude více představen níže. Na vývojáře tento koncept klade nové požadavky v podobě změny úhlu pohledu. Jde zejména o návrh takových služeb, které jsou dostatečně obecné, snadno znovu použitelné a pro koncového uživatele přínosné.

4.4. BPEL Business Process Execution Language (BPEL) pochádza z dieľne konzorcia IBM, BEA Systems a Microsoftu. Kombinuje a zároveň nahrádza WebServices Flow Language od IBM a špecifikáciu XLANG od Microsoftu. BPEL obsahuje orchestračnú zložku, ktorá popisuje internú alebo externú výmenu informácií. Zaoberá sa predovšetkým funkčnými aspektami business procesov – koordináciou asynchrónnych procesov medzi službami. Prečo je BPEL dôležitý vo firmách? Webové služby sú skvelou technológiou, avšak bez účinného prepojenia na business procesy. Prepojenie aplikácií využívajúcich webové služby prostredníctvom

23/67


BPEL zvyšuje efektívnosť týchto systémov, pretože BPEL firme umožňuje rýchlo sa prispôsobiť novým požiadavkám či už modifikáciou existujúcich alebo vytvorením nových procesů. BPEL je jazyk založený na štandarde jazyka XML. Ten umožňuje popísať vonkajšie alebo vnútorné podnikové procesy, ktoré sú poprepájané webovými službami. Webové služby vďaka BPEL vytvárajú jedno ucelené “business solution”. BPEL otvára softwareovým programátorom novú cestu pri vytváraní podnikových systémov, pretože im umožňuje popísať podnikové procesy. Opísanie logiky a ovládania webových služieb participujúcich na procese je umožnené “gramatikou” založenou na jazyku XML. Táto môže byť interpretovaná a spustená orchestracným jadrom (engineom) BPEL. Tento engine koordinuje všetky aktivity v procese a kontroluje správnosť chodu systému v prípade, ak dôjde k chybe. BPEL je teda určitým rozšírením jazyka XML a špecifikácie webových služieb. BPEL špecifikácia definuje syntax a sémantiku jazyka BPEL, ktorý obsahuje množstvo entít na modelovanie procesných tokov. Umožňuje napríklad podmienené vetvenie, paralelný tok procesov, vytváranie podprocesov, spájanie procesov a ďalšie vymoženosti. Mnohé vývojové nástroje zahŕňajú webové služby v štandardnej výbave. Existujú však aj jednoduché, jednoúčelové nástroje na vytvorenie a správu business procesov pomocou BPEL, ako napríklad Trade Manager od spoločnosti SoftCare. Ak organizácia využíva webové služby, alebo plánuje ich zavedenie, dobrý nástroj na vytváranie a správu výsledných procesov je takmer nevyhnutnosťou.

4.4.1.

Modifikovat software podle procesů

Kvalitní firemní procesy jsou základem úspěchu, málokdy jsou však podporovány informačními systémy od začátku do konce. Dosud převládá nasazení monolitických informačních systémů, které jsou vytvořeny tak, aby vyhovovaly co největší skupině společností. I když jsou tyto systémy upraveny pro potřeby konkrétního zákazníka a případně propojeny s ostatními aplikacemi, vždy je problém přesně pokrýt specifika zákazníka. Přitom právě specifika zákazníka mohou být konkurenční výhodou na trhu. Implementovaný monolitický systém navíc odpovídá potřebám společnosti v okamžiku nasazení, ale firemní procesy se mění velmi často z různých důvodu. Právě tato implementace změn je zdlouhavá a finančně náročná. Pro zrychlení procesu implementace změn a usnadnění pokrytí celých firemních procesů byl vyvinut koncept SOA (Service Oriented Architecture), který spolu s BPEL (Business Processing Execution Language) a EDA (Event Driven Architecture) umožňuje vytvořit pružný informační sytém podporující firemní procesy od začátku do konce.

4.4.2. Ciele BPELu Jazyk BPEL si kladie za cieľ nasledujúce body: •

definovanie business procesov, ktoré sú v interakcii s externými entitami prosterdníctvom webových služieb. Táto komunikácia sa uskutočňuje jazykom WSDL 1.1

•

definovanie business procesov použitím jazyka na báze XML. Nedefinuje grafickú reprezentáciu procesov

24/67


•

definuje niekoľko konceptov orchestrálnych webových služieb, ktoré sú určené na použitie v rámci interných aj externých pohľadov na business procesy

•

obsahuje funkcie na manupuláciu s dátami, ktoré sú potrebné pri definovaní určitých procesov

•

podporuje jednotný mechanizmus vytvárania a rušenia inštancií procesov a ich jednoduchý životný cyklus

•

definuje dlhodobý transakčný model, ktorý je založený na zabehaných technikách

•

používa webové služby ako základný model na dekompozíciu procesov

•

je založený na webových štandardoch v maximálnej možnej miere.

4.4.3. Jazyk BPEL Služby je potrebné pospájať a automatizovať tak, aby zodpovedali konkrétnym podnikovým procesom. Tento postup označujeme termínom „orchestrácia služieb“. Štandardom na spájanie viacerých synchrónnych a asynchrónnych služieb do toku procesov je práve BPEL. Je to orchestrálny jazyk, nie choreografický, čo znamená, že popisuje koordináciu a management komplexných informačných systémov. Tento jazyk je základom pre nástroj Oracle BPEL Process Manager. Procesy je možné modelovať graficky, v intuitívnom a užívateľsky priateľskom prostredí Jdevelopera. Oracle BPEL Proces Manager je robustný systém na vykonávanie procesného toku. Poskytuje vysokú dostupnosť aj pre dlhotrvajúce procesy. Jeho súčasťou sú nástroje na administráciu, monitorovanie a ladenie procesov. Na sledovanie behu procesov a ich analýzu slúži Oracle Business Activity Monitoring (BAM). Na základe jeho výstupov v prehľadnej grafickej podobe je možné zefektívňovať a optimalizovať podnikové procesy.

4.4.4. Čo BPEL nedokáže? Jazyk BPEL si nedokáže poradiť s: •

interakciou s lokálnymi objektami Javy alebo C#

•

interakciou s relačnými databázemi

•

interakciou s uživateľom (neexistuje žiadna abstrakcia pre uživateľov, skupiny alebo role)

•

neexistujúcim špecifickým modelom pre meranie, reporting alebo management

•

neexistujúcou explicitnou podporou transformácií

•

neexistujúcou explicitnou podporou ďalších protokolov a iných služieb ako webové služby

Táto funkcionalita nie je a ani nebola cieľom autorov pri tvorbe špecifikácie BPELu. Vzhľadom k potrebám a požiadavkám praxe však muselo množstvo poskytovateľov BPEL niektoré zo spomínaných vlastností doplniť.

4.4.5. Generovanie BPEL a WSDL Nasledujúci obrázok znázorňuje UML class model jedného BPML procesu:

25/67


Obrázek 12: UML class model jedného BPML procesu

Chovanie tejto triedy je možné popísať, resp. modelovať tzv. activity diagramom. Vývojové nástroje, ako napr. Eclipse, obsahujú pluginy umožňujúce transformovať UML diagramy do BPEL. Ide o vygenerovanie množstva súborov, medzi nimi sú aj .BPEL a .WSDL súbory. Takto vygenerované súbory by mali byť pripravené na spustenie (ide o spustiteľné súbory). Užívateľovi by mal postačiť Apache Tomcat, ktorý dokáže z takto vygerovaných súborov zobraziť čitateľnú stránku, viď nasledujúci obrázok. Obrázek 13: Apache Tomcat

Po kliknutí na “Continue deployment” je nutné vložiť (uploadovať) všetky súbory obsahujúce rozdielne role v procese. Vidíme, že generovanie BPEL a WSDL je pomerne jednoduché.

26/67


5.

Nástroje

5.1. IBM Filenet Business Process Manager Filenet BPM platformy Filenet P8 je produktem, který v nezávislých studiích patří mezi nejsilnější. Původně dokumentačně orientovaný, dnes výrazně integrační. Celý balík dlouhodobě staví na platformě J2EE a představuje prakticky první workflow produkt. Od začátku určuje trendy v oblasti process management, což částečně vysvětluje skutečnost, že ne vždy plně respektuje standardy diktované autoritami. Filenet musí vznikající výzvy řešit dříve, než je definuje standard. Výsledkem je, že sice normy plně nedodržuje, ale na druhou stranu disponuje rozhraními, s jejichž pomocí se domluví se všemi významnými hráči na trhu. Balík má rozsáhlé integrační možnosti a obsahuje i nástroj pro tvorbu ad-hoc procesů (viz snímek dole). Návrh procesů je realizován v okně webového prohlížeče s podporou Javy. Balík však obsahuje i podporu COM/SOAP integračních možností a event-driven interakcí. P8 BPM samozřejmě nativně spolupracuje s ostatními produkty společnosti – Content Manager a Web Site Manager. Mezi další přednosti patří: •

Verze procesů a jejich jednoduchá administrace

•

Sledování, analýza a simulace procesů

•

Znovupoužitelné definice procesu

•

Grafický design a modelování procesů

•

100% webově založený

•

Drag and drop integrace webových služeb

Obrázek 14: Filenet Process Designer

27/67


IBM Filenet Business Process Manager Podpora BPEL Podpora dalších standardů Podporované platformy

Cena

bez nativní podpory J2EE, JSR 168, LDAP, SOAP, SSL, XML, WSDL, XML, WebDAV, WS, SMTP, HTTP, BPEL Aplikační servery: • BEA Weblogic • IBM WebSphere • Sun Java System • Oracle • JBoss • Apache Tomcat Databáze: • IBM DB2 • Microsoft SQL Server • Oracle Adresářové služby • Microsoft Active Directory • Novell • eDirectory • Sun Java Systém Operační systémy • Microsoft Windows • Sun Solária • IBM AIX • HP HP-UX • Red Hat Linux enterprise konfigurace 125 až 420 tis. USD

5.2. SAP NetWeaver SAP NetWeaver je aplikační a integrační platforma založená na otevřených standardech. Je technologickou základnou pro balík firemních aplikací mySAP Business Suite, pro kompozitní aplikace SAP xApps a pro jiná obecná nebo odvětvově orientovaná řešení společnosti SAP. SAP NetWeaver vytváří rovněž technologickou bázi nově navržené architektury společnosti SAP pojmenované Enterprise Services Architecture, která slouží jako předloha pro řešení založená na využití webových služeb. SAP NetWeaver sjednocuje všechny integrační technologie do jediné platformy. Technologické komponenty nejsou dodávány samy o sobě, společnost SAP je dodává se širokým standardním obsahem, který významně zjednodušuje proces jejich uvedení do provozu. Platforma SAP NetWeaver je postavena na bázi otevřených standardů, plně spolupracuje s jinými běžně používanými technologickými platformami, jako jsou Java 2 Platform, Enterprise Edition (J2EE), Microsoft .NET a IBM WebSphere.

28/67


Obrázek 15: Tři úrovně integrace v rámci platformy SAP NetWeaver: integrace pracovníků, integrace informací, integrace procesů

5.2.1.

Základní komponenty SAP NetWeaver

SAP NetWeaver je univerzální technologickou platformou. Zahrnuje následující technologické komponenty: •

SAP NetWeaver Application Server je vývojová a provozní platforma založená na otevřených standardech, která podporuje webové služby, vytváří provozní prostředí pro všechna řešení společnosti SAP a umožňuje vývoj s využitím klíčových technologií, jako jsou J2EE a ABAP. Na bázi SAP Web Application Server lze rychle vyvíjet a provozovat dynamické firemní aplikace podporující mezipodnikovou kooperaci.

•

SAP NetWeaver Portal zahrnuje kompletní infrastrukturu podnikového portálu, nástroje pro řízení znalostí a aplikace pro podporu týmové spolupráce. Bezpečným způsobem zpřístupňuje zaměstnancům, partnerům, zákazníků a jiným komunitám v ekosystému společnosti klíčové informace a aplikace, pracuje s konceptem uživatelských rolí. Unifikace aplikací a informací v prostředí portálu umožňuje společnostem identifikovat a řešit problémy rychleji, efektivněji, s nižšími

29/67


náklady a tím vytvářet měřitelné přínosy a strategické výhody. SAP NetWeaver Portal zahrnuje nástroje pro správu portálu, řízení znalostí a řízení spolupráce. Využívá aplikační server SAP NetWeaver Application Server. •

SAP NetWeaver Business Intelligence usnadňuje identifikaci, integraci a analýzu obchodních dat pocházejících z různých zdrojů, transformuje

data

do

informací,

podporuje

proaktivní

jednání.

Umožňuje

provádět

informovaná rozhodnutí a realizovat včas efektivní opatření vedoucí k úspěchu na trhu. •

SAP NetWeaver Exchange Infrastructure obsahuje otevřené integrační technologie poskytující procesní integraci firemních aplikací jak od společnosti SAP, tak od jiných dodavatelů, integraci uvnitř i přes hranice společnosti. Obsahuje integrační broker a podporuje komplexní řízení obchodních procesů i v případech, kdy je proces podporován prostřednictvím více firemních aplikací. Využívá aplikační server SAP NetWeaver Application Server.

•

• SAP NetWeaver Mobile umožňuje vývoj a provoz řešení pro pracovníky v terénu. Jedná se o univerzální, zabezpečenou platformu, která podporuje širokou škálu mobilních zařízení a umožňuje práci jak v režimu, kdy je zařízení připojené k centrálnímu systému, tak v režimu, kdy je zařízení odpojené. Podporuje vícekanálový přístup (RF technologie, mobilní GSM techonologie, hlasový vstup, atd.), uživatel tak má k dispozici veškeré potřebné informace bez ohledu na místo, kde se nachází. Otevírá firemní aplikace mobilním uživatelům při využití existujících systémů a procesů a zároveň snižuje náklady na vlastnictví. Využívá aplikační server SAP NetWeaver Application Server.

•

SAP NetWeaver Master Data Management zajišťuje harmonizaci a konzistenci dat ve společnostech s heterogenním informačním systémem. Umožňuje ukládání, aktualizaci a konsolidaci kmenových dat, která jsou využívána nezávislými aplikacemi instalovanými v různých lokalitách. Rovněž zajišťuje konzistentní distribuci kmenových dat do všech aplikací a systémů IT infrastruktury. Společnosti mohou z existujících dat vytěžit maximum užitečných informací, významně zkvalitnit rozhodovací procesy, to vše při současné významné redukci nákladů na zajištění kvality dat. Díky využívání efektivních nástrojů pro zabezpečení konzistence dat v informačním systému dochází rovněž ke snížení nákladů na údržbu IT.

•

SAP Composite Application Framework je základem pro vývoj třídy moderních kompozitních podnikových aplikací. Využívá SAP NetWeaver pro zapouzdření funkcí již instalovaných aplikací a systémů do podoby komponent

30/67


a služeb. Vytvořené komponenty a služby umožňuje popsat pomocí metadat a poskytuje nástroje pro jejich zakomponování a propojení do nově vytvářených kompozitních aplikací. Aplikační návrhář má rovněž k dispozici soubor nástrojů pro modelování objektů, služeb, procesů a uživatelského rozhraní, má možnost pracovat s předlohami. Kompozitní aplikace jsou vytvářeny konfigurací komponent a služeb, eliminována je potřeba programátorských prací. •

SAP NetWeaver Developer Studio SAP NetWeaver Developer Studio je komponentou určenou pro podporu vývoje zákaznických aplikací. Nabízí vývojářům přístup k distribuovanému vývojovému a provoznímu prostředí, umožňuje vývoj podnikových aplikací v J2EE (Java 2 Platform, Standard Edition), Je charakteristické řadou vlastností, které usnadňují vývoj robustních podnikových aplikací – přístupem k repositáři, podporou centralizované definice datových typů, progresivní podporou v oblasti vývoje uživatelských rozhraní a podporou fázového vývoje (řízení verzí, transporty verzí a podobně). SAP NetWeaver Developer Studio zahrnuje editory a „čaroděje“ umožňující rychle vytvářet typické komponenty aplikací vyvinutých v J2EE, jako jsou např. JSP stránky, servlety, session beans, entity beans a další.

5.2.2. SAP NetWeaver Exchange Infrastructure V souvislosti s BPM je zřejmě nejdůležitější komponentou SAP NetWeaver Exchange Infrastructure (SAP XI). Jedná se o otevřenou integrační technologii, která poskytuje procesní integraci firemních aplikací (SAP i non-SAP) uvnitř podniku i za hranicemi společnosti. Obsahuje integrační broker a podporuje komplexní řízení obchodních procesů i v případech, kdy je proces podporovaný prostřednictvím více firemních aplikací. Využívá aplikační server SAP NetWeaver Application Server. Komponenta SAP NetWeaver Exchange Infrastructure (SAP XI) vytváří základní prostředí pro integracipodnikových procesů. Umožňuje vzájemně propojovat systémy od různých dodavatelů (SAP i třetích stran), v různých verzích, vyvinutých v různých programovacích jazycích (Java, ABAP a dalších) a podobně. SAP NetWeaver Exchange Infrastructure je založena na otevřené architektuře, podporuje otevřené standardy (např. XML, Java apod.) a poskytuje klíčové služby, které jsou požadovány pro integraci procesů v prostředí složeném z nestejnorodých a komplexních systémů. Jedná se mj. o služby: •

návrh a modelování zpráv XML, transformace zpráv XML a integrace tzv. meziaplikačních procesů (tj. procesů, které jsou podporovány ze strany několika aplikací informačního systému),

•

konfigurace pro řízení kolaborativních procesů (procesů spolupráce mezi obchodními partnery) a předávání zpráv,

•

prostředí pro řízení zpracování zpráv a řízení meziaplikačních procesů, adaptérové platformy (Adapter Engine), umožňující zapojení adaptérů integrovaných aplikací.

31/67


Obrázek 16: Nástroj Integration Builder

Obrázek 17: Modelování procesu v prostředí komponenty SAP NetWeaver Exchange Infrastructure

SAP NetWeaver Podpora BPEL Podpora dalších standardů Podporované platformy

nativní podpora J2EE, JSR 168, WSRP UDDI, SOAP, XML, XSLT, XML Encryption, digitální podpisy, LDAP, SAML Spolupráce: • Lotus Domino, Lotus Sametime Informace: • Microsoft Content Management Server

32/67


• SQL Server Analysis Services • Microsoft Office, Microsoft Exchange Server Procesy: • IBM WebSphere Business Integrator Aplikační platformy: • Visual Studio.NET • SAP .NET Connector • SAP Java Connector N/A

Cena

5.3. BizTalk Server Cílem software firmy Microsoft s názvem BizTalk Server (v několika verzích – poslední verze BizTalk Server 2006) je snadná integrace interních podnikových aplikací, bezpečné spojení s obchodními partnery přes internet a automatizaci komplexních obchodních procesů realizovaných organizacemi. Můžeme říci, že cílem tvůrců je umožnit řešit co největší škálu problémů integrace a to jak uvnitř organizace, tak vně do sítě internet. Tohoto je dosaženo prostřednictvím podpory mnoha přenosových protokolů a formátů. Díky tomuto umožňuje BizTalk Server využít investice do stávajících aplikací a díky technologiím založeným na jazyku XML je začlenit do nových technologií elektronického obchodování. Již od verze BizTalk Server 2000 je možné využívat vyspělé nástroje určené ke zvyšování produktivity, jež umožňující podnikovým administrátorům IT, vývojářům a analytikům pracovat ve společném prostředí. Novější verze BizTalk Serveru – BizTalk Server 2002, 2004 a 2006 – dále pokračuje rozšiřování podpory funkcí dostupných v předchozí verzi, ale navíc přináší další vylepšení stávajících služeb a funkcionality. Rozšíření funkcionality se dotýká i oblastí spjatých se správou a administrací BizTalk Serveru – především v oblasti monitorování a zavádění, kde jsou využívány služby poskytované produkty Microsoft Operations Manager a Microsoft Application Center. BizTalk Server využívá čtyři základních SQL Server databáze jako datového úložiště pro data a informace týkající se realizovaných transakcí, správy systému a předávaných dokumentů. Přestože předchozí text mnohé vypovídá, zdůrazněme, že BizTalk server v sobě integruje funkcionalitu pro podporu mnoha oblastí spjatých s integrací aplikací a přenosu dat v rámci organizace, mimo organizaci a s podporou řízení kompletních distribuovaných obchodních procesů. BizTalk může pro nás vytvářet přínos v těchto oblastech: 1. Podpora Enterprise Application Integration (EAI) a Business-to-Business elektronického obchodování. BizTalk Server integruje technologie, které nám umožňují rychle a efektivně realizovat řešení v oblasti EAI (Enterprise Application Integration) a B2B (Business-to-Business) integrace aplikací. Napomoci nám v tom může řada integrovaných nástrojů a nativní podpora jazyka XML pro výměnu dat a podpora mnoha dalších formátů typu EDI (electronic data interchange), EDIFACT, „flat“ soubor apod. Transport dokumentů mezi jednotlivými aplikacemi nebo organizacemi je umožněn podporou transportních protokolů typu HTTP, HTTPS, SMTP komponent typu Message Queuing, Množství adaptérů, které jsou v systému

33/67


BizTalk implementovány vytváří prostředí snadnou integraci produktů a technologií jak v rámci organizace, tak mezi organizacemi a obchodními partnery navzájem. 2. Podpora návrhu, vytváření a provádění dynamických distribuovaných obchodních procesů. Snahou všech podniků by mělo být rychle reagovat na požadavky zákazníků a na hrozby od konkurence. Snaží se proto maximalizovat rychlost implementace a úprav. Velkou výhodu BizTalk Serveru spatřujeme v poskytování vizuálního a vývojového prostředí pro návrh a vytváření dynamických distribuovaných procesů. Toto vizuální prostředí umožňuje analytikům navrhnout průběh procesu a vývojářům takto navržené procesy integrovat pomocí technologických přístupů s aplikacemi. Obchodní transakce, probíhající mezi jednotlivými aplikacemi a obchodními partnery, jsou plně automaticky řízeny takto navrženými procesy. Technologie pokročilé instrumentace obchodního procesu (Business Process Orchestration) v produktech

BizTalk

Server

tak

umožňují

rychle

definovat,

navrhovat

a

nasazovat

automatizované obchodní procesy přemosťující programy, technologie, platformy a obchodní partnery. 3. Bezpečnost, spolehlivost a dostupnost poskytovaných služeb. BizTalk Server využívá bezpečnostních prvků operačního systému Windows 2003 pro zajištění bezpečné komunikace a výměny dat mezi obchodními partnery v prostředí internetu. BizTalk Server podporuje PKI (Public Key Infrastructure) infrastrukturu, využití digitálních certifikátů, elektronického podpisu, šifrování, S/MIME a další bezpečnostní produkty třetích stran. Ve spolupráci s dalšími produkty Microsoft Operation Manager a Microsoft Application Center je zajištěna dostatečná škálovatelnost BizTalk Serveru dle potřeb integračních projektů až do dimenze serverových farem. Součástí je také sada nástrojů a služeb zajišťuje odesílání, přijímání, ukládání dokumentů do fronty ke zpracování synchronním nebo asynchronním způsobem a vytváření a přenos potvrzenek o doručení předávaných dokumentů. BizTalk Server pak umožňuje efektivní a spolehlivé sledování a monitorování výměny dokumentů. 4. Založeno na standardech. BizTalk Server obsahuje a využívá mnoha celosvětově využívaných standardů. Jedná se především o standard XML (eXtensible Markup Language), XSLT (XSL Transformation), SOAP (Simple Object Access Protocol) a dalších průmyslových standardů.

5.3.1.

Architektura BizTalk Serveru

Architektura BizTalk nám nabízí velké množství nástrojů, služeb a široké technologické možnosti pro vytváření EAI a B2B integračních řešení. Jednotlivé komponenty architektury jsou uvedeny na následujícím schématu. Jak je ve výše uvedeném schématu architektury BizTalk Serveru vidět, můžeme produkt sám o obě rozdělit do několika logických jednotek. Každá z takto definovaných oblastí je využívána pro jiné účely a může být jinak zaměřena. Síla produktu BizTalk Server je pak ve

34/67


společném využití těchto jednotlivých komponent a dalších prvků, které tento produkt uživatelům nabízí. Obrázek 18: Schéma BizTalk Serveru

Softwarové požadavky Pro úspěšnou realizaci instalace produktu BizTalk Server je nutné nejprve provést instalaci některých dalších softwarových komponent, které jsou nezbytné pro správné fungování BizTalk Serveru. Sem patří vhodný operační systém – Windows ve verzi Server, atd. Přesné požadavky pro jednotlivé verze BizTalk Serveru je možné dohledat v příslušných dokumentacích nebo na webových stránkách firmy Microsoft. Pro verzi 2006 jsou požadavky následující: 5. Windows Server 2003 Za upozornění stojí, že BizTalk Server 2006 využívá prvků IIS 6.0, MSMQ (Microsoft Message Queuing) a infrastruktury PKI, které jsou dostupné již s verzemi serverového operačního systému Windows 2000 a vyšší a jejich součást je naprosto samozřejmá u Windows Server 2003.

35/67


6. SQL Server 2000 BizTalk Server využívá datových zdrojů jako úložiště dat potřebných jak pro správu systému, tak dat, které jsou mezi jednotlivými aplikacemi nebo organizacemi vyměňovány. 7. Visio Vývojové nástroje BizTalk Severu 2006 zaměřené na návrh a vytváření distribuovaných procesů jsou založeny na prostředí aplikace Microsoft Visio. Tento nástroj využívá jak uživatelského prostředí této aplikace, tak engine běžícího na pozadí.

5.3.2. Databáze BizTalk Server Výše jsem psali, že systém BizTalk využívá čtyři základní databáze, které jsou nezbytné pro zajištění funkcionality BizTalk Serveru. Nyní je zkusíme popsat trochu detailněji. V rámci instalačního procesu volíme jednotlivé komponenty, které budou instalovány. Pokud se rozhodneme o instalaci BizTalk Messaging Services i BizTalk Orchestration Services (obojí bude popsáno v dalších částech dokumentu), jsou během instalačního procesu vytvořeny čtyři databáze: •

•

tři z těchto databází jsou vytvořeny pro potřeby Messaging Services: o

BizTalk Messaging databáze (InterchangeBTM)

o

Tracking databáze (InterchangeDTA)

o

Shared Queue databáze (InterchangeSQ)

jedna pro potřeby Orchestration Services: o

Orchestration Persistence databáze (XLANG)

BizTalk Messaging databáze Obsahem této databáze jsou informace o konfiguraci BizTalk Serveru a rovněž informace, které jsou vytvářeny pomocí nástroje BizTalk Messaging Manager. Příkladem mohou být metadata popisující konfigurace vytvořených Messaging Object jako jsou kanály, messaging porty a organizace. Dle dostupné dokumentace můžeme říci, že se jedná o nejdůležitější databázi, a proto je doporučeno velmi dobře zvážit jakékoliv přesouvání této databáze z jednoho databázového serveru na druhý. Tracking databáze Tato databáze je využívána pro ukládání informací napomáhajících sledování a monitorování dokumentů vyměňovaných mezi aplikacemi nebo obchodními partnery. V databázi jsou ukládány celé instance vyměňovaných dokumentů. Shared Queue databáze Smyslem této databáze je sloužit jako sdílená databáze pro ukládání informací o průběhu zpracování dokumentů, které jsou předmětem výměny mezi aplikacemi a obchodními partnery. Tato databáze je využívána pro všechny BizTalk Servery v rámci jedné BizTalk Server skupiny. V případě, že tedy dojde k výpadku jednoho z BizTalk Serverů, druhý BizTalk Server může dále pokračovat ve zpracování dokumentu.

36/67


Orchestration Persistence databáze (XLANG) Tato databáze je základní databází pro BizTalk Orchestration Services a pro BizTalk Orchestration Designer. V databázi jsou ukládány informace o stavu procesů, tedy například procesech, které byly dehydratovány.

5.3.3. Nástroje BizTalk Serveru 2006 BizTalk Server přináší nástroje, které nám umožňují konfigurovat a spravovat messaging a orchestration services, zajišťovat administraci BizTalk Serveru, sledovat a monitorovat posílané dokumenty, vytvářet XML schéma a transformační mapy jednoho formátu dokumentu do druhého. Některé z nástrojů využívají integrace s dalšími aplikacemi a společně tak poskytují vizuální vývojové prostředí určené pro návrh, vytváření a realizaci komplexních dynamických procesů. Tyto nástroje jsou využívány jak administrátory IT, tak vývojáři a analytiky organizace. BizTalk Editor BizTalk Editor je jedním ze dvou základních XML nástrojů integrovaných v rámci BizTalk Serveru, které slouží k vytváření XML specifikací a transformačních map. BizTalk Mapper Druhým XML nástrojem integrovaným v rámci BizTalk Serveru je BizTalk Mapper. Jedná se o nástroj sloužící k vytváření transformačních map založených na standardu XSLT (XSL Transformation). Tyto transformační mapy slouží k transformaci dat (dokumentů) z jednoho formátu do jiného formátu nebo k transformaci z jedné struktury dokumentu do jiné struktury dokumentu. BizTalk Orchestration Designer BizTalk Orchestration Designer je nástroj pro návrh a implementaci dynamických procesů, které mohou řídit proces výměny dokumentů mezi aplikacemi a obchodními partnery. Jedná se o jeden z nejsilnějších nástrojů, které jsou součástí BizTalk Serveru a který v sobě spojuje prostředí pro návrh procesů spolu s prostředím pro technologickou implementaci těchto procesů. Tento nástroj umožňuje vytvářet XLANG Schedule, ve kterých definované procesy probíhají. Velkou výhodou BizTalk Serveru a především pak jeho části Orchestration Services je podpora dlouhotrvající procesů. Vlastní prostředí BizTalk Orchestration Designeru je založeno na produktu Microsoft Visio. BizTalk Messaging Manager Tento nástroj slouží pro správu a konfiguraci objektů jedné z klíčových komponent BizTalk Serveru – BizTalk Messaging Services. Nástroj sám o sobě je webová aplikace vytvořená pomocí technologie ASP a provozovaná v rámci webového serveru IIS 6.0. Jeho pomocí můžeme přes grafické uživatelské rozhraní přistupovat a konfigurovat jednotlivé objekty Messaging Services, kterými jsou například: •

Messaging Port (port)

•

Channel (kanál)

•

Organization (organizace)

•

Distribution List (distribuční seznam)

37/67


•

Document Definition (specifikace dokumentů)

•

Envelopes (obálky)

BizTalk Server Administration BizTak Server Administration je nástroj, založený na standardní MMC (Microsoft Management Console) konzoli. Nástroj umožňuje spravovat jak samotný BizTalk Sever, tak skupiny BizTalk Serverů, BizTalk Server fronty a Receive Function. Součástí nástroje je i integrovaný „Prohlížeč událostí“ Event Viewer, pro snadnější řešení neočekávaných stavů a problémů s produktem BizTalk Server. BizTalk Document Tracking Jedná se o nástroj založený na webovém rozhraní, který je úzce spjat s BizTalk Tracking databází, nazývanou také Data Tracking Activity (DTA) databáze. Již víme, že tato databáze patří mezi databáze BizTalk Serveru, které jsou velmi často využívány a u nichž lze předpokládat rapidní nárůst velikosti spravovaných dat. Tato databáze je dále sdílena v rámci skupiny BizTalk Serverů. Ukládání dat do tracking

databáze

není

samozřejmostí.

Ukládání

jak

obecných,

tak

specifických

údajů

o

zpracovávaných a vyměňovaných dokumentech musíme definovat v průběhu vytváření BizTalk Server Groups nebo v průběhu vytváření BizTalk Messaging objektů. Tento nástroj nám poskytuje grafické uživatelské rozhraní pro vytváření dotazů nad DTA databází a zobrazování výsledků těchto dotazů. SEED Wizard Jedná se o nástroj, jehož cílem je usnadnit realizaci integrace nás s našimi obchodními partnery. Nástroj nám a našim obchodním partnerům, kteří využívají BizTalk Server, umožňuje celkem jednoduše vytvořit, otestovat a zrealizovat nezbytná nastavení a infrastrukturu pro vzájemnou integraci. Pomocí tohoto průvodce, vytvoříme speciální balíček – SEED Package, jenž obsahuje jméno organizace, která balíček vytváří, testovací a produkční URL odkaz pro předání dokumentu ke zpracování BizTalk Serverem naší organizace a ukázkovou specifikaci a XML instanci některého obchodního dokumentu.

38/67


Obrázek 19: SEED Package v BizTalk Serveru

Služby BizTalk Serveru Pokud bychom měli shrnout, co je cílem BizTalk Messaging Services, mohli bychom k tomuto využít následující schéma znázorňující jejich architekturu. Na obrázku můžeme vidět, že Messaging Services se skládají z následujících komponent: •

Receive function

•

Custom Preprocesors – zajišťuje zpracování dokumentů ještě před tím, než jsou předány ke zpracování BizTalk Serveru. Aplikují se v rámci konfigurace Receive Function.

•

Transportní protokoly

•

Konfigurovatelné objekty Messaging Services

•

Parsers and Serializers – překlad dokumentů na vstupu z nativní formy do XML a dokumentů na výstupu do nativní formy z XML

•

Podpora spolehlivého doručení dokumentů – Reliable Messaging

•

Podpora bezpečné výměny dokumentů

Smyslem Messaging Services je převzít dokument, předávaný zdrojovou aplikací nebo organizací k dalšímu zpracování, zajistit jeho správné zpracování a předat zpracovaný dokument cílové aplikaci nebo obchodnímu partnerovi. Během tohoto procesu je prováděna sadu úkolů, které využívají komponent o kterých jsme psali výše a které zahrnují překlad dokumentů z jejich nativního formátu do formátu XML (který je nutný pro zpracování BizTalk Serverem), ověření správnosti a všech náležitostí přijímaného dokumentu proti definované specifikaci (schéma) dokumentu, transformaci dokumentu z jednoho formátu (struktury) do jiné, překlad dokumentů na výstupu z formátu XML do formátu požadovaného cílovou aplikací a zajistit transport tohoto dokumentu cílové aplikaci nebo organizaci.

39/67


Obrázek 20: Schéma BizTalk Messaging Services

Receive Function Jedná se o grafické rozhraní umožňující provést postoupení dokumentu ke zpracování BizTalk Serveru. Dokumenty mohou být ke zpracování BizTalk Serverem postoupeny v zásadě dvěma způsoby: Prvním způsobem je programátorský způsob využití metod Submit a SubmitSyn, které náleží do Interchange rozhraní. Tento způsob je využíván především u aplikací podporujících COM rozhraní. V závislosti na zvolené metodě dochází k postoupení dokumentu buď synchronním nebo asynchronním způsobem. Druhý způsob představují Receive Functions, tedy předpřipravené grafické uživatelské rozhraní, které je dostupné v rámci nástroje BizTalk Administration. Využití Receive Function je výhodné

40/67


například v případě, kdy integrovaná aplikace nepodporuje COM rozhraní. BizTalk Server zahrnuje tři typy Receive Functions: •

File

•

Message Queuing

•

HTTP

V případě, že využijeme Receive Functions, jsou dokumenty ke zpracování předávány vždy asynchronním způsobem. Pokud tedy námi vytvářené řešení vyžaduje synchronní způsob komunikace, musíme využít metody SubmitSync. Vzhledem k tomu, co jsme nyní napsali je jasné, že Receive Functions nelze pro tyto účely využít. Transport Services BizTalk Server podporuje velké množství transportních protokolů a služeb pro přenos dokumentů mezi aplikacemi nebo přes internet mezi organizacemi. Mezi nejčastěji využívané transportní služby patří: •

HTTP

•

HTTPS

•

SMTP

•

Message Queuing

•

File

•

AIC (Application Integration Component)

5.3.4. BizTalk Orchestration Services Podíváme-li se na oblast Enterprise Application Integration a B2B integrace pozorněji, zjistíme, že vlastní integrace probíhá ve dvou základních rovinách. První rovinou je infrastruktura na komunikační úrovní, která zajišťuje efektivní výměnu obchodních dokumentů mezi jednotlivými obchodními jednotkami a aplikacemi. Tato infrastruktura musí odrážet nejenom vlastní výměnu dokumentů, ale také oblasti ověření správnosti dokumentů, transformaci mezi jednotlivými formáty, transformaci schémat dokumentů a spolehlivou a hlavně bezpečnou možnost doručení dokumentů. Tuto integrační rovinu, dle dostupné literatury, pokrývají BizTalk Server Messaging Services. Silná a dobře zajištěná komunikační infrastruktura sama o sobě však není při realizaci integračních řešení dostatečná. Každý obchodní dokument, který je předáván mezi jednotlivými aplikacemi nebo obchodními partnery, je součástí nějakého komplexního obchodního procesu. V oblasti návrhu a řízení komplexních procesů v procesu EAI nebo B2B integrace můžeme spatřovat právě onu druhou zmiňovanou rovinu integračních řešení. Na jedné straně tedy vidíme potřebu, ba dokonce nutnost, jednotlivé obchodní procesy řídit, na straně druhé je však pravdou, že není jednoduché obchodní procesy popsat a implementovat jednoznačným způsobem. Automatizované obchodní procesy jsou často implementovány za pomocí vytváření proprietárních řešení, jež jsou často založeny na komponentovém přístupu a dalším využití programování pro spojení

41/67


celého řešení do jednoho fungujícího bloku, který reprezentuje vlastní proces. Tento přístup však přináší některé nevýhody: •

Řešení založená na proprietárních aplikacích a kódu jsou často neflexibilní, především pak při nutnosti aplikaci nebo kód změnit.

•

Obchodní procesy, a především ty obchodní procesy, které se týkají obchodních partnerů za hranicemi organizace, mohou být realizovány několik dní, týdnů, měsíců. Realizace takové aplikace podporující dlouhotrvající procesy je časově náročná a vyžaduje velké množství programování.

•

Proprietární kód využívaný pro automatizaci procesů je tradičně velmi problematický a časově náročný.

BizTalk Orchestration Services poskytují nástroje a služby pro vytváření a implementaci procesů. Návrh procesů a jejich implementace Při návrhu, vytváření a implementaci obchodních procesů BizTalk Server Orchestration Services poskytují vizuální návrhové prostředí, které slouží jak pro návrh procesů, tak pro technologickou implementaci těchto procesů. Sledování a řízení stavu procesů V rámci systému můžeme předpokládat, že dochází k realizace několika desítek, stovek nebo tisíců transakcí – instancí obchodních procesů. Často pak potřebujeme zjistit, v jakém stavu se právě proces nachází, případně potřebujeme řešit nenadálý problém. Pomocí nástrojů BizTalk Serveru dokážeme sledovat stav jednotlivých instancí procesů, včetně jejich stavů a monitorovat tak aktuální stav. Pro účely sledování a řízení stavu procesů se využívá nástrojů XLANG Event Monitor a BizTalk Document Tracking. Podpora dlouhotrvajících obchodních transakcí Jednotlivé obchodní transakce, které jsou realizovány mezi obchodními partnery nebo aplikacemi, nejsou standardně realizovány v jednom okamžiku a mohou trvat až několik dní či týdnů. BizTalk Server Orchestration Services umožňují efektivně tyto „dlouhotrvající“ transakce vytvářet a řídit. Vlastnosti transakcí je možné popsat pomocí známé zkratky ACID •

Atomicity - Transakce je jakási jednotka práce. Transakce jsou vždy realizovány jako celek. Nelze realizovat pouze část.

•

Consistency - Data, jež jsou předmětem transakce, byla konzistentní před její realizací a musí být konzistentní i po realizaci této transakce.

•

Isolation - Realizace jedné transakce je oddělena od realizace druhé transakce. Jedna transakce nesmí modifikovat nebo měnit data, která jsou modifikována jinou transakcí.

•

Durability - Trvanlivost a odolnost transakcí.

Z těchto vlastností transakce můžeme odvodit, probíhají obecně v jednom okamžiku a vlastní realizaci transakce lze vyjádřit „buď všechno nebo nic“.

42/67


Pokud si však vzpomeneme, co bylo napsáno před několika řádky, tak na obchodních transakcích realizovaných v prostředí BizTalk Serveru, vidíme, že jejich realizace a dokončení je často závislé na odezvě obchodního partnera nebo aplikace na druhé straně. Takovýchto transakcí pak můžeme mít tisíce a pokud by všechny využívaly systémových prostředků v jeden okamžik, bylo by to výkonově pro náš systém velmi náročné. Orchestration Services provádějí sledování všech realizovaných transakcí a v případě, že transakce setrvává v nečinnosti více než definovaný časový interval (např. 200 vteřin), dojde k operaci zvané rehydratation – tj. transakce je zmrazena ve stávajícím stavu a je uložena do databáze (Orchestration Persistent Database). V okamžiku, kdy transakce pokračuje např. obchodní partner odpověděl, je provedena dehydratation – tj. transakce je rozmrazena (obnovena z databáze) a pokračuje ve využívání systémových prostředků pro realizaci dalšího kroku. Optimalizace výkonu, vysoká dostupnost, škálovatelnost Stejně jako u jiných informačních systémů je možné i u BizTalk Serveru provádět škálování tj. zvyšování výkonu systému dvěma základními způsoby. Prvním je škálování nahoru tzv. scale up. Tento způsob spočívá v posilování HW konfigurace jednoho serveru tak, že zvyšujeme objem operační paměti, přidáváme procesory případně měníme jednotlivé HW komponenty za výkonnější. Druhým způsobem je škálování přes více serverů tzv. scale out. Tento způsob spočívá v rozkládání zátěže na více serverů, přičemž služby a transakce, které byly realizovány jedním serverem jsou nyní realizovány několika servery. Tento druhý způsob je nejčastěji využíván pro optimalizaci výkonu BizTalk Serveru. Doplnění základních pojmů a koncepce V dokumentaci k BizTalk Serveru se často objevuje pojem „Integrační broker“ (jako celek uveden na následujícím obrázku). Pro něj platí, že má škálovatelnou architekturu pro zpracování procházejících zpráv. Toto uspořádání zajišťuje tři základní funkce – přijetí zprávy, uložení zprávy do trvalého úložiště a doručení zprávy.

43/67


Obrázek 21: Schéma „integračního brokeru“ v BizTalk Serveru

Message box Message box je relační databází SQL serveru, která je používána jako trvalé úložiště všech zpráv procházejících systémem. V případě požadavku na extrémně vysokou škálovatelnost je možné mít více oddělených databází message box (což je výhodné pro zkrácení doby odezvy atp.). Použití relační databáze pro uložení stavu zpráv a procesů je velmi výhodné, neboť může plně využít samozřejmé vlastnosti databázového stroje – vysokou stabilitu a výkon, možnost transakčních operací nad daty, robustní zálohování a obnovu, technologie pro vysokou dostupnost (clustering), auditing a řadu dalších funkcí. Adaptér Integrační broker komunikuje s integrovanými aplikacemi či službami prostřednictvím tzv. adaptérů. Adaptér je prvek spojující integrační broker s integrovanými aplikacemi. Adaptéry lze rozdělit do tří skupin: •

Aplikační adaptéry (vertikální) spojují integrační broker s vybranou konkrétní aplikací (např. SAP, Siebel, PeopleSoft, Nision, Great Plains). Pokud aplikace implementuje nestandardní rozhraní (např. SAP rozhraní BAPI), potom adaptér obsahuje technické prostředky pro komunikaci s aplikací.

44/67


•

Technologické adaptéry (horizontální) spojují integrační broker s okolím prostřednictvím technologie nezávislé na konkrétní aplikaci (např. webové služby, souborový systém, SMTP, TCP/IP, LU 6.2, MQSeries, FTP). Tyto adaptéry jsou zpravidla jednodušší a tudíž vyžadují větší konfigurační úsilí na straně brokeru i integrované aplikace.

•

Datové adaptéry jsou na pomezí mezi aplikačními a technologickými adaptéry. Umožňují integračnímu brokeru komunikovat přímo s databází (např. MS SQL, Oracle, DB2). Tyto adaptéry umožňují pohodlný způsob přístupu k datům v operačních databázích, vhodné jsou například pro udržování informací o stavu integrovaných procesů, workflow mimo aplikace apod.

Pipeline Pro přijetí a odeslání se využívá koncepce tzv. proudového zpracování zprávy pomocí tzv. pipeline. Pipeline slouží ke zpracování přijaté zprávy před jejím uložením do message boxu anebo před odesláním po vyjmutí správy z message boxu (pracuje tedy na obou stranách message boxu, je-li to třeba). Je složena z posloupnosti jednotlivých etap ve zpracování zprávy (stage) jako je např. dekódování, dešifrování či kontrola digitálního podpisu. V každé etapě je možné zařadit žádnou, jednu nebo více komponent prodanou etapu. Zpráva pak prochází postupně těmito komponentami, přičemž každá komponenta může zprávu modifikovat (např. dešifrovací komponenta), vyvolat chybu (např. komponenta kontrolující správnost příchozí zprávy) nebo zapisovat do kontextu zprávy vlastnosti pro účely jejich pozdějšího vyhledávání nebo dalšího směrování. Receive port Port pro přijetí zprávy (receive port) slouží pro převzetí zprávy integračním brokerem. Jde o řekněme logickou adresu, přes kterou jsou zprávy doručovány. Tato logická (virtuální) adresa slouží vyšším vrstvám integračního brokeru ke kategorizaci zpráv a k řízení jejich dalšího zpracování. Porty pro přijetí mohou být dvojího druhu – bez odpovědi na přijatou zprávu (one-way) nebo s odpovědí (request-response), přičemž adaptér nemusí nutně podporovat oba způsoby. Receive location Řekli jsme, že port pro doručení je pouhou logickou adresou pro doručení. Skutečná zpráva musí být doručena nějakým konkrétním fyzickým způsobem prostřednictvím určitého konkrétního adaptéru na tzv. receive location. Dle dostupné literatury jsou třemi nejdůležitějšími vlastnostmi každého receive location použitý adaptér, adresa závislá na zvoleném adaptéru (např. pro FILE adaptér je adresou cesta ke složce, která je monitorována) a pipeline použitá pro zpracování přijaté zprávy. Send port Send port neboli port pro odeslání slouží pro doručení zprávy cílové službě nebo příjemci. Port plní i zde funkci logické adresy a jeho hlavními vlastnostmi jsou pipeline pro zpracování odesílané zprávy, primární transport a někdy též sekundární (náhradní) transport. Transport je pak definován především

45/67


použitým adaptérem, adresou pro doručení a parametry pro opakování případného neúspěšného přenosu. Obdobně jako porty pro přijetí, i porty pro odeslání mohou být dvojího druhu – s čekáním na odpověď (solicit-response) anebo bez odpovědi (one-way), daný adaptér opět nemusí podporovat oba způsoby. V literatuře je uváděn i další způsob dělení portů a to na porty statické a dynamické. Zatímco statické porty doručí zprávu vždy na předdefinovanou adresu, dynamické porty nemají pevně stanovenou cílovou adresu. Adresa je totiž přiřazena až při zpracování zprávy. Dostupné adaptéry a technologie Adaptéry lze dále rozdělit podle jejich původu a dostupnosti. Aplikační adaptéry buď dodává výrobce aplikace (např. Siebel) nebo firma specializovaná na výrobu adaptérů (pure play adapter vendor, např. iWay) a v případě SAPu nabízí komerční adaptér též Microsoft. Technologické a datové adaptéry jsou zpravidla dodávány specializovanými firmami, Microsoft nabízí ke stažení adaptér pro IBM MQSeries a osm technologických adaptérů najdete přímo „v krabici“ BizTalk V BizTalk jsou například následující adaptéry: •

SOAP adaptér

•

MSMQT adaptér

•

FILE

•

HTTP

•

SMTP

•

FTP

•

SQL adaptér

•

EDI

Enterprise Single Sign-On Jedním z problémů, které vzniká při integraci v různorodém prostředí je často existence mnoha různých přihlašovacích systémů a bezpečnostních domén. Není výjimkou, že uživatel má až desítky jmen a hesel do různých interních systémů, přičemž tato situace je velkou zátěží pro administrátory, uživatele i rozpočet IT oddělení. Naproti tomu v ideálním stavu by uživatel měl mít pouze jedno jediné primární jméno a heslo, které by bylo klíčem ke všem interním systémům, ale změna interních systémů za účelem používání jiných autentizačních schémat je bohužel většinou utopií. V této situaci je částečným řešením technologie Enterprise Single Sign-on (ESSO). Jde o důmyslné kryptografické řešení, jehož základem je databáze sekundárních přihlašovacích informací zašifrovaných symetrickou šifrou (tzv. master secret), takže v případě zcizení databáze jsou přihlašovací informace v ní uložené relativně bezcenné. V této databázi jsou definovány tzv. přidružené aplikace (affiliate application) a pro tyto aplikace je pak jednotlivému účtu nebo skupině uživatelů z domény uloženo šifrované jméno a heslo. Graficky je tato problematika vykreslena na následujícím obrázku. Postup použití ESSO v BizTalku. Na počátku je zpráva doručena adaptéru autentizovaným způsobem. Podporuje-li adaptér ESSO, požádá SSO server o vydání takzvaného tiketu pro SSO. Tento

46/67


tiket je přiložen ke zprávě jako jedna z jeho vlastností, takže je uložen do message boxu a provází zprávu po celou dobu jejího zpracování. Pokud je při odesílání použit adaptér podporující se zapnutou podporou a nastavenou hodnotou přidružené aplikace, předloží SSO serveru tiket přidaný ke zprávě a na jeho základě získá příslušné namapované přihlašovací informace pro cílovou aplikaci. Tyto informace pak odesílající adaptér použije pro komunikaci s cílovou aplikací. Obrázek 22: Fungování ESSO v BizTalk Serveru

Tento mechanismus samozřejmě předpokládá určitou důvěru v kvalitu a prověřenost používaných adaptérů, která by ovšem v provozním prostředí měla být samozřejmostí.

Microsoft BizTalk Server 2006 Podpora BPEL Podpora dalších standardů Podporované platformy Cena

nativní podpora RFID, .NET, EDI, XML, WSDL, SOAP, SMTP, http, FTP, POP3 Windows, další přes adaptéry 8500 USD za CPU

5.4. IBM WebSphere Rodina produktů IBM WebSphere představuje základní infrastrukturní software pro e-business. Umožňuje realizovat libovolný typ internetového řešení, jako jsou intranetové a internetové aplikace, portálová a e-commerce řešení, multikanálová řešení pro zařízení typu mobilních telefonů a PDA, B2B

47/67


řešení a mnoho dalšího. Jedná se o ideální platformou pro podniky, které chtějí provozovat úspěšný ebusiness. Mezi hlavní výhody IBM WebSphere patří otevřenost – je založena na Javě (J2EE), XML a WebServices, modularita – možnost skládat komplexní řešení z jednotlivých IBM produktů, škálovatelnost a cenová dostupnost – produkty WebSphere jsou dostupné v různých edicích a pro všechny zákaznické segmenty. Jedním z nejdůležitějších rysů rodiny IBM WebSphere je, že se jedná o multiplatformní řešení, které je možno provozovat na platformách Linux, Windows, UNIX, iSeries a zSeries. S ohledem na zaměření práce se zaměříme především na následující nástroje z široké produktové rodiny IBM WebSphere: •

WebSphere Application Server přední aplikační platforma založená na technologiích J2EE (Java 2 Enterprise Edition) a webových služeb (Web Services). Představuje kvalitní řešení pro provozování dynamických podnikových řešení pro business „on demand“. Plně podporuje Software Development Kit for Java Technology Edition (SDK 1.4) – klient i server, což umožňuje podnikům vytvářet sofistikovanější e-business aplikace založené na technologii Java v kratším čase a s nižšími náklady. WebSphere Application Server poskytuje podporu třetí generace pro standardy webových služeb, a podniky tak mohou dosáhnout vyššího stupně integrace s klíčovými obchodními partnery, dodavateli a zákazníky. Komponenta Advanced Performance Advisors pomáhá nastavit klíčové parametry WebSphere Application Serveru, a umožňuje tak dosahovat maximálního výkonu.

•

WebSphere Extended Deployment přináší doplňky k WebSphere Application Server Network Deployment, který poskytuje vysoce dynamické a výkonné prostředí pro Websphere aplikace. Tyto doplňky Vám pomohou s optimalizací a využíváním vašich aplikací, a tak zvýšit jakost Vámi nabízených služeb.

•

WebSphere MQ Workflow softwarový nástroj pro správu obchodních procesů (BPM – Business Process Management) podniku umožňující podnikům plně kontrolovat stávající podnikové procesy a zajišťovat jejich integritu. Umožňuje vysokou míru automatizace obchodních procesů, čímž podniky získávají schopnost flexibilněji a agilněji reagovat na změnu tržních podmínek. Websphere MQ Workflow umožňuje podnikům zahrnout aplikační systémy a uživatele do řízeného prostředí obchodních

procesů

implementovaného

jako

součást

hodnotového

řešení

integrace

celopodnikových aplikací (EAI – Enterprise Application Integration), B2B řešení a řešení pro správu obchodních procesů.

48/67


•

WebSphere Business Integration Modeler nástroj pro návrh a testování složitých podnikových procesů. Poskytuje vrcholovému managementu přehled o důležitých událostech a aktivitách a umožňuje mu flexibilně reagovat na změny tržních podmínek. Klíčové podnikové procesy jsou uchovávány na jediném místě, čímž je zajištěna jejich aktuálnost a konzistence. Díky jednoduchému grafickému rozhraní umožňuje nástroj WebSphere Business Integration Modeler snadno navrhovat nové a upravovat již existující podnikové procesy. Možnosti simulace různých podnikových scénářů pomáhají odhalit chyby a možné problémy dříve, než dojde k implementaci procesu.

•

WebSphere Business Integration Server na otevřených standardech založená integrační platforma příští generace umožňující podnikům snadno integrovat existující IT zdroje, čímž pomáhá maximalizovat návratnost podnikových investic do IT. Umožňuje snadno vytvářet znovupoužitelné Java aplikace nebo aplikace typu webových služeb (Web Services). WebSphere Business Integration Server Foundation pomáhá zvýšit efektivitu vývoje aplikací při současné minimalizaci nákladů na vývoj, implementaci a administraci IT systému.

5.4.1.

Produkty IBM podporující SOA

Pro modelování architektur SOA nabízí IBM snadno použitelný nástroj WebSphere Business Modeler, který umožňuje modelovat a navrhovat procesní tok před samotným nasazením a doplňuje modelovací funkce nástroje Rational Software Architect. Pro vytváření a implementaci podnikových procesů postavených na architektuře SOA oznamuje IBM vývojový nástroj WebSphere Integration Developer, který je postaven na nástroji Eclipse. WebSphere Integration Developer umožňuje vývojářům složených aplikací zobrazovat existující informační technologie jako služby, které lze snadno propojovat do ucelených podnikových procesů. IBM také uvolnilo novou verzi nástroje Rational Application Developer, který pomůže při sestavování architektur orientovaných na služby. Na pomoc se zaváděním architektur SOA nabízí IBM produkt WebSphere Enterprise Service Bus (ESB). WebSphere ESB dále posiluje současné možnosti IBM ESB v oblasti propojení a integrace webových aplikací a služeb. Pro vyspělou funkčnost ESB uvádí IBM novou verzi nástroje WebSphere Message Broker, který zajišťuje univerzální konektivitu a transformaci dat pro aplikace bez ohledu na to, jestli vyhovují standardům. Další novinkou pro implementace SOA je WebSphere Process Server, software založený na otevřených standardech a na technologii WebSphere ESB, který pomáhá zjednodušit integraci podnikových procesů mezi lidmi, systémy, zákazníky a obchodními partnery. WebSphere Process Server zkracuje dobu, snižuje náklady a odstraňuje rizika spojená s integračními projekty, neboť zjednodušuje pohyb informací mezi aplikacemi na základě podnikových pravidel.

49/67


Pro správu architektur SOA také IBM oznamuje vylepšení produktu WebSphere Business Monitor. Nový software pomáhá monitorovat výkonnost podnikových procesů a sledovat klíčové výkonnostní ukazatele. Tivoli později v tomto měsíci oznámí nový řídící software pro složené aplikace, který bude zákazníkům pomáhat spravovat a zajišťovat výkon a dostupnost řešení založených na architektuře SOA.

5.4.2. WebSphere Business Modeler Produktové nástroje WebSphere Business Modeler pomáhají organizacím plně vizualizovat, pochopit a zdokumentovat jejich business procesy. Značných přínosů může být dosaženo pomocí kolaborativní funkcionality, kdy tým expertů na danou problematiku napomáhá jasnějšímu definování business modelů a odstranění neefektivností. Lze modelovat business procesy, pro neustálou optimalizaci je následně rozvíjet, monitorovat a volit akce podle KPI, poplachů a triggerů. Business procesy se tak stávají blíže spojené se strategickými cíly společnosti. Jedná se o nástroj pro vizuální návrh, testování a simulaci složitých podnikových procesů. Poskytuje vrcholovému managementu přehled o důležitých událostech a aktivitách a umožňuje mu flexibilně reagovat na změny tržních podmínek. Klíčové podnikové procesy jsou uchovávány na jediném místě, čímž je zajištěna jejich aktuálnost a konzistence. Díky jednoduchému grafickému rozhraní umožňuje nástroj WebSphere Business Integration Modeler snadno navrhovat nové a upravovat již existující podnikové procesy. Možnosti simulace různých podnikových scénářů pomáhají odhalit chyby a možné problémy dříve, než dojdek implementaci procesu. WebSphere Business Integration Modeler pomáhá: •

rychle upravovat existující nebo navrhovat nové procesy v závislosti na změně potřeb podniku

•

jasně a přehledně definovat obchodní procesy a zjednodušit jejich sdílení

•

optimalizovat obchodní procesy a zvyšovat efektivitu předávání informací uvnitř podniku

•

integrovat procesy, informace a aplikace

Nástroj je poskytován ve čtyřech variantách: •

Basic méně finančně náročná edice poskytující základní modelovací funkce pro zachycení dat podnikových oddělení a jednotlivců, pokud nevyžadují veškeré schopnosti edice WebSphere Business Modeler Advanced.

•

Advanced překlenuje mezeru mezi business linií a IT, poskytuje robustní funkčnost procesního modelování, podnikového modelování, modelování esenciálních dat a artefaktů, organizačního modelování, modelování zdrojů, časové přímky a modelování lokací či analýzy business procesů.

50/67


•

Publishing Server poskytuje schopnost publikovat modely business procesů Portlet-based serverům, kde několik expertů na danou problematiku může současně sledovat a posuzovat informace pomocí běžného internetového prohlížeče.

•

Monitor monitoruje business procesy v reálném čase, poskytuje visuální obraz jejich stavu a společně s poplachy a upozorněními klíčovým uživatelům umožňuje neustálé zlepšování business procesů.

IBM WebSphere Business Modeler Podpora BPEL Podpora dalších standardů Podporované platformy Cena

nativní podpora UML, FDL, WSDL, XML, J2EE Windows N/A

5.5. Sybase PowerDesigner PowerDesigner je CASE nástroj, který komplexně pokrývající všechny aspekty rozvoje podniku. Obsahuje nástroje pro obchodně orientovanou procesní analýzu, která umožní identifikovat klíčová místa a funkce podniku jako takového a nabízí také plně integrované prostředí pro datovou a objektovou analýzu informačních systémů. Přitom plně podporuje zavedené přístupy a metodologie jako je Unified Modeling Language (UML) nebo dvouúrovňový návrh databáze. PowerDesigner je nástrojem pro návrh informačních systémů protože umožňuje v rámci jediného prostředí identifikovat důležité obchodní aktivity podniku a zachytit jejich odraz v aplikacích a databázích pomocí datových a objektových modelů. Obchodní analytik tak může navrhnout efektivnější fungování podniku v modelu podnikových procesů a předat takto specifikované zadání do IT oddělení k vytvoření informačních systémů podporujících tyto nové procesy v podniku. Při návrhu požadovaných aplikací může datový analytik tak vytvářet entity v datovém modelu a sledovat jejich závislost na objektech a třídách v navrhované aplikaci získaných z objektového modelu systému. Hladká spolupráce při návrhu datové a aplikační stránky systému v rámci jediného CASE nástroje s jednotným uživatelským prostředím se pak odrazí v rychlém a bezproblémovém vývoji.

5.5.1.

Základní charakteristiky PowerDesigner

Modelování podnikových procesů Model podnikových procesů poskytuje efektivní nástroj pro analýzu fungování podniku, který není zatížen odkazem informačních technologií. Model podnikových procesů je v PowerDesigneru zaměřen na obchodní analytiky a manažery. Tedy na pracovníky, kteří se velmi dobře orientují v problematice daného podniku, ale slovník programátorů je jim cizí. PowerDesigner nabízí manažerům a obchodním analytikům snadno uchopitelné prostředí, ve kterém mohou jednoduše modelovat lepší

51/67


fungování podniku případně i zdokumentovat stávající stav. Model podnikových procesů lze pak použít pro tvorbu vnitropodnikových předpisů a norem nebo přímo jako zadání pro vývojáře aplikací. Navíc lze tento procesní model použít pro konfiguraci produktů pro vnitropodnikovou integraci aplikací (EAI) a pro systémy pro automatickou komunikaci s obchodními partnery (B2B). Datové modelování PowerDesigner těží za své bohaté tradice nejefektivnějšího nástroje pro návrh databází. Tvorba databázových schémat je založena na plnohodnotné koncepci dvouúrovňového návrhu schématu databáze. PowerDesigner umožňuje pomocí konceptuálního datového modelu (CDM) návrh abstraktních datových struktur (Entit) a vztahů mezi nimi v ER diagramech – to vše pomocí osvědčených metod. Konceptuální datový model tak představuje platformově nezávislé datové schéma projektovaného systému které je oproštěno od všech implementačních úprav. Datový analytik se tak může soustředit přímo na vlastní obchodní data systému a nikoliv na způsob jejich uložení v konkrétním databázovém serveru. Fyzický datový model (PDM) tvoří v PowerDesigneru druhou složkou datového modelování. Fyzický datový model je na rozdíl od konceptuálního modelu již určen pro konkrétní databázový server, kterých PowerDesigner podporuje více jak 35. Právě v tomto modelu má datový analytik možnost navrhovat indexy, provádět denormalizaci či specifikovat další speciální nastavení pro cílovou databázovou platformu. PowerDesigner tak umožňuje optimalizovat výsledné databázové schéma konkrétní databázi a přitom zajisti aby výsledná aplikace podporovala více databázových platforem. PowerDesigner umožňuje snadný přechod mezi obecným, platformově nezávislým, konceptuálním modelem a fyzickým datovým modelem optimalizovaným pro konkrétní databázi. Při generování fyzického modelu provede PowerDesigner překlady datových typů, M:N relací, klíčů a dalších součástí modelu do jejich ekvivalentů v cílové databázové platformě. PowerDesigner také podporuje zpětnou konsolidaci fyzického do konceptuálního datového modelu a umožňuje jednoduše porovnávat jednotlivé modely mezi sebou a tak udržovat a vyvíjet aplikace podporující více databázových serverů. Posledním doplňkem datového modelování v PowerDesigneru je podpora datových skladů. Všechny edice PowerDesigneru umožňují v rámci fyzického datového modelu vytvářet i multidimenzionální datové modely a pracovat s hvězdicovými a vločkovými schématy. PowerDesigner také umožňuje provádět mapování mezi zdrojovými a cílovými databázovými objekty a tak vytvářet dokumentaci pro nasazení a konfiguraci nástrojů pro extrakci, transformaci a plnění datových skladů. Objektové modelování Podpora objektového modelování v PowerDesigneru je založena na osvědčené metodologii Unified Modeling Languge (UML). Diagramy uživatelských scénářů (Use Case) dostupné v rámci objektového modelu systému umožňují specifikovat požadované chování aplikace na nejvyšší úrovni abstrakce. Pomocí sekvenčních diagramů a diagramů aktivit pak aplikační analytik může identifikovat obchodní objekty v aplikaci a funkce, které mají vykonávat.

52/67


Výsledkem těchto diagramů je sada tříd včetně identifikace jejich atributů a metod. Jádrem objektového modelu v PowerDesigneru je samotný diagram tříd. V tomto diagramu lze definovat závislosti a další vztahy mezi jednotlivými třídami obdobně jako v případě konceptuálního nebo fyzického datového modelu. PowerDesigner samozřejmě umožňuje synchronizaci tohoto klíčového diagramu objektového modelu systému s datovými modely a tak udržovat konzistenci mezi datovou a aplikační stránkou vyvíjeného systému. Diagram tříd je tedy obdobou fyzického datového modelu pro aplikační stránku systému a stejně jako fyzický datový model umožňuje diagram tříd generování zdrojového kódu a zpětnou analýzu aplikací (hierarchií objektů, analýzu jejich funkcí a atributů) pro celou řadu objektových platforem jako jsou prostředí PowerBuilder, Java, C++, C#, XML, WSDL, CORBA nebo VisualBasic. Java 2 Enterprise Edition PowerDesigner přináší novou dimenzi do vývoje distribuovaných Java aplikací podle normy Java 2 Enterprise Edition. Díky těsné vazbě mezi datovým a objektovým modelem umožňuje PowerDesigner specifikovat i objektově relační mapování - vazbu mezi tabulkami ve fyzickém datovém modelu a třídami v diagramu tříd v objektovém modelu. Toto objektově relační mapování lze následně využít pro automatickou konfiguraci kontejnerem řízené perzistence (Container Managed Persistence, CMP) Entity Enterprise Java Bean komponent v J2EE 1.3 kompatibilních aplikačních serverech. Vedle kontejnerové perzistence umožňuje PowerDesigner také modelovat Enterprise Java Bean komponenty jako takové. PowerDesigner dokáže korektně vytvořit všechny součásti EJB komponenty – od home, remote a local rozhraní, přes bean třídu až k deployment deskriptorům – a obsahuje mechanismy pro udržení konzistence výchozího modelu tříd a dalších objektových diagramů s diagramem komponent. Porovnávání modelů Jádro návrhu informačního systému v PowerDesigneru spočívá v konceptuálním a fyzickém datovém modelu a diagramu tříd z objektového modelu aplikace. PowerDesigner zajišťuje konzistenci všech součástí vyvíjené aplikace (modelů) pomocí pokročilé možnosti porovnávání a slučování jednotlivých modelů. Možnost porovnat datový a objektový model mezi sebou dává analytikům do ruky silný nástroj, pomocí kterého mohou identifikovat provedené změny v jedné součásti vyvíjeného systému, například v datovém modelu, a implementovat je odpovídajícím způsobem do modelu objektového. Tím PowerDesigner zajistí aby navrhovaná aplikace odpovídala své databázi. Generování a zpětná analýza aplikací a databází V rámci fyzického datového modelu a diagramu tříd v objektovém modelu umožňuje PowerDesigner generování základů navrhované aplikace. Z fyzického datového modelu lze získat Data Definition Language (DDL) skripty pro vytvoření všech tabulek, pohledů, indexů, uživatelských datových typů, triggerů a dalších součástí schéma databáze navrhovaného systému. A to vždy přesně podle možností cílového databázového serveru kterých PowerDesigner podporuje více jak 35 nejrůznějších verzí všech rozšířených dodavatelů.

53/67


Obdobně i objektový model, respektive jeho diagram tříd – PowerDesigner podporuje generování zdrojového kódu pro mnoho objektově orientovaných vývojových prostředí včetně jazyka Java, PowerBuilder, C++, C#, VisualBasic nebo komponentového modelu CORBA (IDL soubory). PowerDesigner také umožňuje vytvářet i schéma a definice XML dokumentů k danému objektovému modelu a tak umožnit hladké zapojení navrhované aplikace do eCommerce systémů. Vedle samotného generování databázových skriptů a zdrojového kódu aplikace dokáže PowerDesigner provádět i zpětnou analýzu (reverse engeneering) databází a aplikací.PowerDesigner se může připojit pomocí ODBC rozhraní na existující databázi nebo přečíst její DDL skripty a vytvořit odpovídající fyzický datový model – včetně tabulek, indexů, referenční integrity a dalších součástí databázového schéma. Tuto vlastnost PowerDesigneru spolu s možností generování dokumentace a porovnáváním modelů obzvláště ocení databázoví administrátoři protože v PowerDesigneru naleznou nedocenitelný nástroj pro sledování a dokumentaci změn ve spravované databázi. Kvalitní dokumentace – základ úspěchu Jedním z kritických faktorů úspěchu vývoje aplikace je schopnost udržet informace o navrhovaném systému nejen v podobě prostého výpisu zdrojového kódu, ale i v podobě poznámek a anotací k jednotlivým objektům, entitám či vazbám. PowerDesigner poskytuje široké dokumentační možnosti pro zachycení informací o projektu na libovolné úrovni podrobnosti - od databázových nastavení až po informace o jednotlivých atributech třídy v objektovém modelu. Pokročilý dokumentační generátor PowerDesigneru umožňuje sestavovat z předpřipravených součástí jako je seznam tabulek nebo detailní popis relace dokumentové šablony pro různé varianty generovaných reportů. Vývojový tým tak může udržovat obecné šablony k různým účelům - programátorskou dokumentaci pro vývojový tým, databázovou dokumentaci pro administrátora databázového serveru, dokumentaci aplikačních rozhraní jako přílohu manuálů a další typy reportů. Generování dokumentace pomocí takto vytvořených šablon udrží jednotný vzhled a obsah v dokumentaci všech projektů vývojového týmu a následně se odrazí i v jeho vyšší efektivitě. Repository – podpora týmové práce Pří vývoji rozsáhlejšího informačního systému obvykle pracuje na jeho návrhu celý tým analytiků. Pro koordinaci a zvýšení efektivity jejich práce slouží v PowerDesigneru modul MetaWorks který slouží jako společné úložiště (repository) modelů projektu pro všechny členy vývojového týmu. MetaWorks umožňuje vedoucímu projektu přiřazovat jednotlivým členům vývojového týmu přístupová práva k jednotlivým modelům – součástem projektu – uloženým v PowerDesigner repository v SQL databázi. Pro potřeby repository je k produktu PowerDesigner přiložena omezená licence databáze Adaptive Server Anywhere a lze použít libovolnou databázi s ODBC rozhraním. Vedle řízení přístupu k jednotlivým součástem projektu plní PowerDesigner repository ještě důležitou funkci verzování modelů. Repository automaticky sleduje vývoj každého jednotlivého modelu v čase a uchovává jeho předchozí varianty. V okamžiku kdy dojde například k objevení nové chyby v současné verzi aplikace, lze porovnat její model s modelem dřívější, bezchybné aplikace a tak identifikovat příčiny zjištěné chyby. Verzování modelů, které v PowerDesigneru umožňuje i větvení

54/67


vývoje, má v sobě zakomponován také mechanismus zamykání jednotlivých částí modelu se kterými pracují ostatní členové vývojového týmu a tak zabraňuje situaci, kdy s jedním modelem navrhované aplikace pracují dva analytici, kteří si navzájem přepisují svoji práci. Business Process Architect PowerDesigner Business Process Architect umožňuje obchodním (ne-IT) analytikům zachytit procesy v organizaci a předat je IT oddělení k jejich IT analýze a převedení do vyvíjených systémů. Vedle zajištění shody obchodního zadání s vyvíjenou aplikací lze Business Process Architect použít také k popisu obecných procesů v podniku, jejich optimalizaci a pro podporu business process reengineeringu. Umožňuje tvorbu nových datových objektů a informačních toků mezi podnikovými procesy. Lze propojit procesní model s konceptuálním datovým modelem a objektově orientovaným modelem. Pomocí průvodce mohou být data importována a exportována mezi jednotlivými modely. Umožňuje vytvářet CRUD matrice, popisující vztahy mezi procesy a zdroji. CRUD zabezpečují všechny operace, které procesy provádějí se zdroji. To umožňuje sledovat, jak procesy se zdroji pracují, a pomáhá udržet kontrolu reálnosti modelu. Organizační jednotky jsou znázorňovány v diagramech jako „swimlines“. To umožňuje graficky reprezentovat vztahy mezi objekty BPM a organizačními jednotkami. Sybase PowerDesigner Podpora BPEL Podpora dalších standardů Podporované platformy

Cena

ano UML, J2EE, .NET, XML, Web Services Operační systém: • Windows Databáze: • Sybase • Microsoft • Informix • Oracle • IBM PowerDesigner 11 Physical Architekt cca. 45 tis. Kč včetně DPH

5.6. ORACLE BPEL Process Manager Oracle se snaží prosadit na poli BPM pomocí nástroje BPEL Process Manager. Akvizicí společnosti Collaxa, která byla průkopníkem v oblasti SOA a BPM tak Oracle získal potřebné know-how. Oracle BPEL Process Manager (dále BPEL-PM) je nástroj, pomocí kterého lze navrhovat, provozovat, monitorovat a analyzovat procesy na bázi standardu pro oblast podnikových procesů – BPEL. BPEL-PM je nativní implementací BPEL standardu, který nabízí grafický editor pro práci s BPEL procesy a škálovatelné, vysoce dostupné provozní prostředí. Toto prostředí umožňuje mimo jiné ucelený monitoring jednotlivých procesů, jejich vyhodnocování a případný debuging. Nativní podpora BPEL je velmi přínosná, protože vzhledem k tomu že BPEL je všeobecně uznávaný standard, tak pomocí BPELPM lze navrhovat přenosné a na jiných platformách použitelné procesy.

55/67


BPEL-PM běží na řadě aplikačních serverů firmy Oracle, ale není na ně vázán; nabízí podporu libovolného J2EE aplikačního serveru včetně JBoss a WebSphere. Podporuje rovněž pokročilé BPEL funkce jako je asynchronní předávání zpráv a kompenzaci transakcí (ošetření chyb a výjimek). BPELPM také umožňuje tzv. dehydrataci procesu, v případě dlouhotrvající transakce, uložením do persistentního úložiště a následnou rehydrataci procesu po dokončení takové transakce. Díky JCA (Java Connector Architecture) adaptérům rovněž umožňuje rozšiřování svého záběru i nad rámec samotného sladění webových služeb. BPEL Process Manager nabízí mnoho možností. Základní části tohoto řešení jsou BPEL designer, BPEL Console, zabudované integrační služby, služby workflow a BPEL server. BPEL designer nabízí intuitivní grafické uživatelské rozhraní pro návrh procesů. Jak již byl zmíněno BPEL-PM má nativní podporu standardu BPEL, takže vytvořené procesy jsou stoprocentně přenosné. BPEL Console poskytuje web rozhraní pro řízení, administraci a monitorování procesů nasazených na BPEL serveru. Umožňuje sledovat i historii proběhlých procesů. BPEL-PM dodává i mnoho integračních služeb. Zajímavá je i možnost zahrnutí lidského workflow, managementu úkolů atd. BPEL server pak představuje prostředí pro vykonávání navržených BPEL procesů. Následující přehled shrnuje základní charakteristiky řešení: Obrázek 23: BPEL Process Manager

BPEL Designer • nativní podpora BPEL • jednoduché modelování procesů pomocí drag-and-drop

56/67


• UDDI a WSIL browser • automatické mapování • integrované adaptéry a workflow průvodci • jednoduché vytvoření a nasazení procesu

Obrázek 24: BPEL Designer

BPEL Console •

visuální monitorování procesu

•

audit

•

BPEL debbuger

•

administrace procesu za běhu

•

vylaďování výkonnosti

Zabudované integrační služby •

email a messaging

•

JCA 1.5 konektivita

•

adaptéry

•

databázový adapter

•

XSLT a XQUERY

57/67


Workflow služby •

zadávání úkolů a směrování

•

vícenásobné workflow scénáře

•

seznam úkolů a upozornění

BPEL Server •

synchronní a asynchronní zprávy

•

dehydratace

•

řízení chyb a výjimek

•

správa verzí

•

silná podpora XML dokumentů

•

vysoký výkon

ORACLE BPEL Process Manager Podpora BPEL Podpora dalších standardů Podporované platformy

Cena

nativní podpora XML, XQuery, XPath, WS, SOAP, WSDL, JCA, JMS, SMTP, HTTP Aplikační servery: • Oracle AS • JBoss • BEAWebLogic • IBM WebSphere Databáze: • Oracle DB • Oracle Lite • MS SQL cca. 40 tis. USD

5.7. Microsoft Visio Microsoft Visio je aplikace pro tvorbu diagramů, s níž můžete vytvářet obchodní a technické diagramy, ve kterých jsou dokumentovány a uspořádány složité plány, procesy a systémy. Aplikace patří do rodiny programů Microsoft Office, její poslední verze je 2007. Diagramy vytvořené v aplikaci Visio umožňují jasně, stručně a efektivně vizuálně vytvářet, spravovat a předávat informace tak, jak by to pouze s využitím textu a čísel nebylo možné. Pomocí přímé synchronizace diagramů se zdroji dat automatizuje aplikace Visio vizualizaci dat. Poskytuje tak aktuální diagramy a navíc lze mechanismy aktualizace přizpůsobit potřebám každé organizace. Tato aplikace je k dispozici ve verzích Standard a Professional a obsahuje nové typy diagramů, galerií a šablon spolu s běžnými typy diagramů, jež podporují základní systémy kontroly kvality, standardy Six Sigma, ISO 9000 a TQM. Snadná dokumentace a analýza obchodních procesů, umožní zákazníkům lépe porozumět provozu organizace a následně zvýšit její efektivitu. Aplikace Visio je součástí řešení Microsoft Office System. Díky tomu bude možné nové funkce dynamicky propojovat při využití formátu XML. Tím se z dokumentů aplikace Visio stávají inteligentní

58/67


klienti, které bude možné integrovat s aplikacemi určenými pro konkrétní činnost podnikání a využít je ke sledování obchodních dat v reálném čase. Získání další obchodní hodnoty pro společnost Organizace mohou přicházet o své zisky a ztrácet obchodní příležitosti z důvodu neefektivních obchodních procesů nebo obtížnému porozumění provozu organizace v rámci hlavní činnosti. Správa obchodních procesů umožňuje společnostem snížit náklady a zvýšit efektivitu, protože zajišťuje přehlednou dokumentaci aktuálních procesů, jež jsou později vyhodnoceny a v případě potřeby vylepšeny. První krok správy obchodních procesů představuje grafická identifikace obchodních procesů a analýza dat, podle nichž mohou manažeři a zaměstnanci určit, ve kterých oblastech je možné zvýšit efektivitu. V aplikaci Visio jsou pro tento rozhodující krok k dispozici nové diagramy obchodních procesů, šablony a nástroje, jako například konceptuální grafy, stromové struktury pro rozhodování, vývojové diagramy, schémata procesů a procedur, časová schémata a schémata činností. Pomocí všech uvedených funkcí mohou zákazníci vytvořit osnovu obchodních procesů a dokumentovat a zároveň obvyklým způsobem graficky znázornit obchodní činnosti za účelem analýzy a popisu komplexních systémů. „Automatizace a tok dat obchodních procesů vyžaduje v konečné fázi zapojení mnoha složek organizace, chcete-li zajistit slibovaný výsledek,“ uvedla Sandra Rogers, ředitelka výzkumu webových služeb a softwaru pro integraci společnosti IDC. „Aplikace Visio představuje produkt vyvinutý pro vytváření vztahů mezi informacemi a modelování workflow v převážně grafickém kontextu. V této podobě by měla oslovovat členy týmu definujícího obchodní procesy, kteří jsou více orientováni na obchodní činnosti.“ Snadné pochopení koncepcí, procesů a vztahů S aplikací Visio můžete snadno vytvářet obchodní a technické diagramy, které vám pomohou při vytváření, organizování nebo lepším pochopení složitých plánů, procesů a systémů. Diagramy můžete snadno sestavovat přetahováním předem definovaných symbolů Microsoft SmartShapes. Pro účely vytváření obchodních a technických diagramů můžete používat nástroje, které byly přímo navrženy pro jednotlivé profesionální disciplíny. Z existujících dat lze generovat běžné typy diagramů. K dispozici je také kontextová nápověda a šablony pro konkrétní úkoly, které jsou pravidelně aktualizovány z webu. Integrace s Windows Server Systém Při vývoji aplikace Visio se společnost Microsoft zaměřila na dvě různé oblasti: vytvoření aplikace schopné integrace s podnikovými systémy a návrat k základnímu účelu aplikace jako nástroje určeného zejména pro vytváření diagramů. Výsledkem je sada výkonnějších a flexibilnějších nástrojů aplikace Visio, která přináší nové možnosti využití diagramů aplikace. Kromě toho, že aplikace využívá formát XML a webové služby založené na formátu XML, lze ji navíc zcela integrovat s ostatními aplikacemi sady Microsoft Office a s aplikacemi systému Windows

59/67


Server System, včetně systému Windows Server™ 2003 s produkty Windows SharePoint, Microsoft BizTalk Server a Microsoft SQL Server. Specifické podnikové potřeby můžete řešit začleněním aplikace Visio do výkonného softwaru připojeného k platformě Microsoft .NET. Ovládací prvky aplikace Visio pro kreslení je možné vkládat do obchodních aplikací, které jsou založeny na softwaru připojeném k platformě .NET nebo na operačním systému Microsoft Windows. Nová řešení zefektivňují vytváření diagramů databází a softwaru a rozšiřují podporu vývojářských nástrojů společnosti Microsoft. Je možné provádět zpětnou analýzu existujících aplikací a navrhovat nové aplikace. Lze ji přitom integrovat do původního systému jako rozšiřitelnou platformu pro vývoj s novými funkcemi určenými k vytváření řešení inteligentního klienta, pomocí nichž je možné z uvedených systémů získávat informace v reálném čase. Společnost Microsoft nabízí za účelem podpory uvedených funkcí několik prostředků, které jsou určeny podnikovým vývojářům a obchodním partnerům. Jedná se například o ovládací prvky ActiveX, sadu pro vývojáře softwaru a nový nástroj pro vývojáře Shape Studio, který usnadňuje vývojářské procesy při vytváření obrazců s vysokou úrovní kvality. Tímto způsobem mohou být inteligentní klienti upraveni tak, aby vyhovovali téměř všem potřebám podnikání. K předávání plánů, informací a systémů můžete využít grafické znázornění – Integrovaná podpora počítačů Tablet PC umožňuje procházet, upravovat a komentovat diagramy, i když nejste u pracovního stolu. Pomocí digitálního pera můžete vkládat do diagramů komentáře, formátovat, měnit velikost nebo otáčet prvky diagramů a připojovat k nim položky zadané digitálním perem. Záznamy zadané pomocí digitálního pera můžete převést na základní geometrii nebo text. Diagramy z aplikace Visio můžete publikovat do pracovního prostoru na portálovém serveru Microsoft SharePoint, můžete je také exportovat pomocí formátu SVG (Scalable Vector Graphics) nebo aktualizované funkce Uložit jako webovou stránku. Vytváření diagramů softwarových aplikací Pomocí celé řady typů diagramů založených na jazyce UML (Unified Modeling Language) a jiných obecných metodologií můžete vytvářet diagramy softwarových projektů. Zpětnou analýzou projektů vývojového prostředí Microsoft Visual Studio můžete dokonce vytvářet diagramy tříd jazyka UML.

60/67


Obrázek 25: UML v Microsoft Visio

Vytváření diagramů schémat databází Pro navrhované schéma databáze můžete vytvářet diagramy vztahů jednotlivých entit. Chcete-li vytvářet diagramy schémat existujících systémů, můžete provést zpětnou analýzu běžných databází typu klient-server, včetně databází SQL Server, IBM, Oracle a dalších.

61/67


Obrázek 26: Návrh databáze v Microsoft Visio

Vytváření business diagramů Visio podporuje využití vizualizace procesů k vyjádření workflow, plánování a spravování vztahů napříč oddělením v organizaci. Plánování, design, implementace a komunikace výsledků business procesů spolu s dokumentací zahrnují SAP, ISO a Six Sigma. Takto lze vytvářet událostmi řízené procesní diagramy (EPC – event-driven process), rozbory pomocí stromu poruch (fault tree analysis), základní i náročnější diagramy toků (DFD), sufitní diagramy a workflow diagramy. V oblasti IT najdeme ve verzi 2007 novinku, podporu standardů ITIL, usnadňující tak návrh IT infrastruktury.

62/67


Obrázek 27: Business Process, EPC diagram

Vytváření podrobných map webových serverů Pomocí průvodce pro vytváření map webových serverů můžete vytvářet mapy existujících serverů sítí Internet a intranet a odstraňovat problémy s těmito servery. Můžete pracovat s tvary zastupujícími stránky ve formátu HTML, aplety v jazyce Java, multimédia, obrázky a další prvky na serverech. ORACLE BPEL Process Manager Podpora BPEL Podpora dalších standardů Podporované platformy

ano UML, XML, .NET, Web Services, ODX, ITIL • Exchange Server • MS SQL, IBM, Oracle • Visual Studio .NET • BizTalk Server • Windows Server Visio Standard 2007 od 260 USD, Professional od 560 USD

Cena

5.8. Soyatec eBPMN Designer Jedním z nástrojů, založených na standardu BPMN 1.0, je eBPMN Designer od firmy Soyatec. Ačkoliv je v současné době teprve v beta-verzi, nabízí řadu zajímavých funkcí: •

nastavení grafické podoby jednotlivých elementů

•

kontrola konektivity pro Sequence Flow, Message Flow a asociace podle specifikace BPMN zabraňuje sémanticky nesprávnému použití, umožňuje naopak „přepojovat“ spojení různých elementů

•

k aktivitám mohou být připojovány různé okrajové elementy – časové, chybové

63/67


•

logický pohled ve stylu Průzkumníka Windows, rozdělený na modely, účastníky a procesy

•

použití sub-procesů (možnost detailního návrhu)

Obrázek 28: Pohled na model ve stylu Průzkumníka – eBPMN Designer

Soyatec eBPMN Designer Podpora BPEL Podpora dalších standardů Podporované platformy

Cena

v budoucnu UML, BPMN Operační systémy • MS Windows • Linux • Mac OS X • AIX • Solaris 8 • HP-UX beta verze zdarma

5.9. Enhydra JaWE Enhydra JaWE je prvním open-source Java grafickým editorem pro návrh workflow procesů v souladu se specifikacemi WfMC a podporujícím jako nativní formát XPDL. Je možné ho použít pro editaci či prohlížení jakéhokoliv XPDL souboru (v souladu se specifikacemi WfMC XPDL) a nepoužívá žádné proprietární doplňky. Mezi podporované vlastnosti patří:

64/67


•

validace sémantiky

•

podpora Wf-XML

•

zobrazení odkazujících komponent u kteréhokoliv elementu XPDL

•

možnost Undo/Redo a zrušení změn v každém okamžiku

•

zvýraznění syntaxe pro XPDL elementy

•

možnost ukládání XPDL do databáze

Unikátní možností tohoto editoru je tedy editace formátu XPDL přísně dle specifikace – což umožňuje například editaci výstupů z aplikací jiných výrobců. Obrázek 29: Pohled na zdrojové XPDL – Enhydra JaWE

Enhydra JaWE Podpora BPEL Podpora dalších standardů Podporované platformy Cena

bez nativní podpory WfMC XPDL nezávislé (Java) open source

65/67


6.

Zdroje 1.

Jakub Albrecht, Ondřej Čuka, Martin Navrkal, Tomáš Faran, Milan Kovařík, Miloš Maryška, David Mišurec, Tomáš Trávníček, Použití CASE/CABE pro řízení workflow ve firmě.

2.

Miroslav Tětek, Integrace workflow a kontent managementu, http://casopis.systemonline.cz/

3.

Miroslav Tětek, Změnové řízení, http://casopis.systemonline.cz/

4.

Martin Kotyza, Od workflow po webflow, http://casopis.systemonline.cz/

5.

Radim Vaněk, Jak úspěšně implementovat procesní řízení, http://casopis.systemonline.cz/

6.

Jiří Malý, Procesní řízení jako zdroj efektivity, http://casopis.systemonline.cz/

7.

Milan Brabec, Jak se liší ECM a BPM ?, http://casopis.systemonline.cz/

8.

Radim Vaněk, ECM zrychluje a automatizuje procesy, http://casopis.systemonline.cz/

9.

Antonín Carda, Renáta Kunstová, Workflow, Nástroj managera pro řízení podnikových procesů; 2. rozšířené vydání, Grada Publishing: 2004.

10. Jindřich Štumpf, Webové služby a XML, http://casopis.systemonline.cz/5770-webove-sluzby-axml.htm 11. Keith D. Swenson, Sameer Pradhan, Mike D. Gilger, Wf-XML 2.0, http://www.wfmc.org/standards/docs/WfXML20-200410c.pdf 12. Layna Fischer, BPM and Workflow Standards, AIIM E - Doc Magazine. Silver Spring: Mar/Apr 2006.; str. 60 13. Nathaniel Palmer, The BPM Standards Landscape, AIIM E - Doc Magazine. Silver Spring: Mar/Apr 2007.; str. 40 14. Jindřich Štumpf, Proč SOA nemá alternativu, http://casopis.systemonline.cz/5771-proc-soanema-alternativu.htm 15. Stephen A. White, Introduction to BPMN, http://www.bpmn.org/Documents/Introduction%20to%20BPMN.pdf 16. Stephen A. White, Process Modeling Notations and Workflow Patterns, http://www.bpmn.org/Documents/Notations%20and%20Workflow%20Patterns.pdf 17. OMG, Business Process Modeling Notation Specification, http://www.bpmn.org/Documents/OMG%20Final%20Adopted%20BPMN%2010%20Spec%2006-02-01.pdf 18. Nathaniel Palmer, Understanding the BPMNXPDL-BPEL Value Chain, http://www.wfmc.org/documents/palmer.BIJ.nov-dec06.pdf 19. David Hollingsworth, The Workflow Reference Model 10 Years On, http://www.wfmc.org/standards/docs/Ref_Model_10_years_on_Hollingsworth.pdf 20. Workflow Management Coalition, The Workflow Reference Model, http://www.wfmc.org/standards/docs/tc003v11.pdf 21. Workflow Management Coalition, Workflow Process Definition Interface – XML Process Definition Language (1.0), http://www.wfmc.org/standards/docs/TC1025_10_xpdl_102502.pdf 22. Workflow Management Coalition, Process Definition Interface – XML Process Definition Language (2.0), http://www.wfmc.org/standards/docs/TC-1025_xpdl_2_2005-10-03.pdf 23. Keith Swenson, The BPMN-XPDL-BPEL value chain, http://kswenson.wordpress.com/2006/05/26/bpmn-xpdl-and-bpel/

66/67


24. Keith Mantell, From UML to BPEL, http://www128.ibm.com/developerworks/webservices/library/ws-uml2bpel/ 25. Marián Kuna, Service Oriented Architecture, http://www.efocus.sk/index.jsp?cl_id=98 26. ITsystems, http://www.itsys.cz/solutionsAction.do?type=show&comeId=7 27. Paul Brown, Maciej Szefler, BPEL for Programmers and Architects, http://www.bptrends.com/publicationfiles/BPEL4ProgArchies.pdf 28. Michael Cobban, What is BPEL and why is it so important to my business?, http://www.softcare.com/whitepapers/wp_whatis_bpel.php 29. http://kore.fi.muni.cz:5080/wiki/index.php/DP:xdancing#BPEL4WS 30. SAP, http://www.sap.com/ 31. IBM, http://www.ibm.com/ 32. IBM FileNet, http://www.filenet.com/ 33. Microsoft, http://www.microsoft.com/ 34. Sybase, http://www.sybase.com/ 35. Oracle, http://www.oracle.com/ 36. Enhydra, http://www.enhydra.org/ 37. Soyatec, http://www.soyatec.com/ 38. http://www.wfmc.org/ 39. http://www.bpmi.org/ 40. http://www.bpmn.org/ 41. http://www.omg.org/ 42. http://www.procesy.cz/ 43. http://www.enhydra.org/

67/67

No title

Recommend Documents