Integrační nástroje a jejich vazba ke CASE a modelování vůbec

Integrační nástroje a jejich vazba ke CASE a modelování vůbec

Integrační nástroje a jejich vazba ke CASE a
modelování vůbec
SEMESTRÁLNÍ PRÁCE
Předmět:
Tým:
Xname:
4IT450
Jiří Sova, Michal Gürtner, Marek Dušek, Petr Kovář
xsovj06, xgurm01, xdusm16, xkovp16
Obsah
1.
Servisně orientovaná architektura..................................................................................... 4
1.1. Základní principy SOA .................................................................................................. 5
1.2. Přínosy SOA.................................................................................................................. 6
1.3. Referenční model SOA................................................................................................. 6
1.4. Enterprise Service Bus ................................................................................................. 7
1.5. Cesta k SOA a její milníky............................................................................................. 8
1.6. Zralostní model SOA MM (SOA Maturity Model)........................................................ 8
2. Business Process Execution Language ............................................................................. 10
2.1. Evoluce jazyka BPEL ................................................................................................... 10
2.2. BPEL proces................................................................................................................ 10
3. Společnost Progress Software a její přístup k SOA a integraci ........................................ 12
3.1. Představení Progress Software.................................................................................. 12
3.2. Proč právě Progress? ................................................................................................. 12
3.3. Produkty zaměřené na servisně orientovanou architekturu .................................... 13
4. Integrace, CASE a produkty společnosti IDS Scheer......................................................... 16
4.1. Představení IDS Scheer.............................................................................................. 16
4.2. Platforma ARIS ........................................................................................................... 16
4.3. Platforma ARIS, integrace a servisně orientovaná architektura ............................... 16
4.4. Platforma ARIS a modelovací standardy ................................................................... 17
5. Nástroje a přístupy společnosti Oracle ............................................................................ 19
5.1. Integrace dat.............................................................................................................. 19
Oracle Warehouse Builder ............................................................................................... 19
Oracle Data Integrator (ODI) ............................................................................................ 21
Oracle Data Hub ............................................................................................................... 21
5.2. Integrace aplikací (Oracle Integration)...................................................................... 22
Oracle Integration InterConnect ...................................................................................... 23
Oracle BPEL Process Manager.......................................................................................... 23
Oracle Integration B2B ..................................................................................................... 25
Oracle Integration BAM.................................................................................................... 27
6. IBM ................................................................................................................................... 28
6.1. Charakteristika produktů........................................................................................... 28
6.2. Websphere Business Modeler................................................................................... 31
6.3. Websphere Integration Developer............................................................................ 32
7. SAP NetWeaver ................................................................................................................ 34
7.1. Charakteristika produktu........................................................................................... 34
7.2. Architektura............................................................................................................... 35
7.3. ARIS for SAP NetWeaver............................................................................................ 36
Literatura.................................................................................................................................. 42
Úvod
Tato práce má za úkol charakterizovat integrační nástroje a jejich vazbu na CASE a
modelování. Nové trendy v oblasti integrace nás donutili popsat některé důležité standardy,
které hrají právě u integračních nástrojů významnou roli. Právě tímto popisem a
charakteristikou se bude zabývat první část této práce. Zřejmě nejdůležitějším standardem je
SOA (servisně orientovaná architektura) a právě jí bude věnována větší část. Samozřejmě
neopomeneme ani jazyk BPEL, což je hlavní standard při vytváření procesů. V první části
vidíme přínos oproti minulým pracím, jelikož SOA v té době nebyla tak hojně využívána.
V dalších částech práce jsme se již zaměřili na konkrétní produkty předních
společností v oblasti integrace. Produkty společností jsme vybírali jednak na základě
přednášek v rámci předmětu „CASE“ a také na základě přednášek předmětu „Integrace v
informačních systémech“. Samozřejmě není možné kompletně zmapovat trh integračních
nástrojů, a tak jsme se dle našich názorů rozhodli vybrat užší skupinu. Zvolili jsme tedy
následující společnosti a jejich nástroje:
• SAP
• IBM
• Oracle
• Progress
• IDS Sheer
Naším úkolem tedy bude popsat, jak dané firmy nahlížejí na integraci a jakými
nástroji ji podporují. V popisovaných produktech se pak zaměříme hlavně na modelování.
1. Servisně orientovaná architektura
Servisně orientovaná architektura, anglicky Service Oriented Architecture, zkráceně
SOA, je relativně mladý koncept pohledu na podnikový informační systém, který je
v současné době mezi systémovými integrátory stále hojněji skloňován a v poslední době
dokonce převládá názor, že do budoucna v podstatě systémová integrace nemá jinou
konkurenceschopnou alternativu.
SOA samotná není oborovým standardem a ze své podstaty jím ani být nemůže.
Podoba SOA architektury závisí na konkrétních implementacích produktů dodavatele řešení.
Ale jak mnozí odborníci již na začátku upozorňují, SOA není ani produkt sám o sobě, který by
podniky jednoduše zakoupily a implementovaly. Je to nové vidění integrovaného
podnikového informačního systému, nové paradigma, se kterým by měla přijít nová dimenze
kvality využívání informačního systému směrem k vyšším úsporám, vyšší efektivnosti,
flexibilnosti a s ní spojená rychlejší reakce na inovační potřebu, a snazšímu chápání co se
uvnitř systému děje skrze vyšší transparentnost SOA.
V rámci SOA v současné době dominují dvě technologie: Web Services (WS), tedy
webové služby, a Enterprise Service Bus (ESB), do českého jazyka asi nejvhodněji překládáno
jako podniková sběrnice služeb.
Služba jako základním stavebním elementem SOA.
Poskytuje svým klientům data nebo funkce na základě kontraktu (Vytvoř fakturu!, Ulož tato
data!). Není přitom důležité, v jakém jazyce je služba napsána, ani na jaké platformě je
služba provozována. Důležité je pouze rozhraní služby, informace kde lze službu nalézt a
popis jejího chování. Klientem služby může být podnikový informační systém, informační
systém mimo podnik nebo jiná služba. Pro vzájemnou, typicky asynchronní komunikaci slouží
značkovací jazyk XML. Služby se mohou spojovat do kompozitních služeb, využívajících více
služeb najednou, a dále do procesů. SOA mj. dokáže zhodnotit i původní (legacy) aplikace,
které „přetaví“ také na službu.
Obrázek 1: Před a po SOA (Sun Microsystems)
1.1.
Základní principy SOA
SOA stojí na následujících základních principech neboli pilířích:
• Volně vázané (loosely coupled)služby.
Volná vázanost služeb znamená, že služby jsou navzájem do velké míry nezávislé díky
generalizovanému rozhraní. Jinými slovy změna v jedné službě nevyžaduje změnu
v druhé.
• Služby jsou hrubozrnné (coarse grained).
Hrubozrnnost služeb znamená vyšší úroveň poskytované funkcionality. Na rozdíl od
jemnozrnných služeb, řešící funkcionalitu na nižší úrovni, např. dotaz do databáze.
• Služby jsou znovupoužitelné (reusable services).
• Služby mezi sebou komunikují asynchronně.
Služba po odeslání zprávy nečeká na odpověď a pokračuje ve zpracovávání. Jedná se
tedy o neblokující komunikaci.
• Důsledné využívání oborových standardů.
HTTP, XML, SOAP, WSDL, JBI, BPEL, …
• Existence úložiště metadat.
Věnujme se nyní některým principům podrobněji:
Znovupoužitelnost služeb
Podstatným rysem a velkou předností konceptu servisně orientované architektury je
znovupoužitelnost služeb. Teprve když se služby skutečně opakovaně používají, ukazuje se
síla konceptu SOA. Znovupoužitelnost je obvykle nahlížena jako žádoucí vedlejší efekt,
ukazující na dobře navrženou SOA architekturu. Snahou je, aby relativně hodně aplikací
používalo relativně málo služeb. Odhady společnosti Gartner uvádí, že dobře navržené SOA
podnikové informační systémy dosahují obvykle použitelnosti kolem 30 - 40%.
Úložiště metadat
Metadata Repository je velmi významným článkem v konceptu SOA. Úložiště
obsahuje dokumentaci pro provoz, ale i vývoj a testování služeb. Obsahuje informace o
rozhraní služeb, křížové reference, verze služeb a další potřebné informace. Implementace a
funkcionalita úložiště metadat se liší od výrobce k výrobci. Může být implementováno jako
UDDI (Universal Description, Discovery and Integration) server (registr). Podnik má obvykle
jedno úložiště, lze se setkat s federativním uspořádáním úložišť, je – li to pro podnik
výhodné.
SOA nejsou Web Services, Web Services nejsou SOA
Fundamentem SOA, jak už název napovídá, jsou služby. Je ale potřeba uvést na
pravou míru často se vyskytující omyl, totiž ten, že se ztotožňují pojmy SOA a Web Services.
Spojení SOA a Web Services je zřejmé, definici služby v SOA vyhovuje každá webová služba.
Ale ne každá služba musí být nutně webová. Může se stát, že v některých případech nebude
implementace služby jako webové služby vhodná a použije se např. Enterprise Service Bus.
1.2.
Přínosy SOA
Mezi hlavní přínosy servisně orientované architektury patří:
• Snížení nákladů na vývoj a integraci.
• Rychlá adopce změn.
• Zefektivnění díky znovupoužitelnosti.
• Zprůhlednění informačního systému a zjednodušení jeho správy.
• Možně využití a nové zhodnocení původních (legacy) aplikací.
• Podnikání v reálném čase.
1.3.
Referenční model SOA
Existuje velké množství referenčních modelů pro SOA. Každá konzultační či
softwarová firma zabývající se SOA má obvykle i svůj definovaný více či méně rozdílný
referenční model. Vybíráme velmi názorný referenční model odborníka na SOA Jindřicha
Štumpfa ze společnosti Progress Software:
Obrázek 2: SOA referenční model (Jindřich Štumpf)
Model čteme z levého dolního rohu do pravého horního. Zcela vlevo je zobrazeno
úložiště metadat, zcela vpravo SOA Governance pro řízení SOA. Odspodu nahoru
prostupujeme jednotlivými vrstvami architektury od technologické vrstvy až po podnikové
procesy poskládané ze služeb.
1.4.
Enterprise Service Bus
Enterprise Service Bus by se do českého jazyka nejvhodněji přeložil jako sběrnice
podnikových služeb. Umožňuje
„realizovat a koordinovat interakci podnikových aplikací a procesů. Mezi její hlavní
přednosti patří schopnost technologicky podporovat podnikání v reálném čase (Real Time
Enterprise), velká flexibilita při implementací změn a schopnost inkrementálního a
distribuovaného nasazení. Zároveň jde o nízkonákladovou (low-end) alternativu komplexních
sad integračních brokerů, která sice nabízí o něco méně funkcionality, zato však jednodušeji a
za méně peněz.“ (1)
„ESB kombinuje několik relativně samostatných technologií. Tou aplikačně nejspodnější
vrstvou je messaging. Ten tvoří komunikační páteř, která fyzicky manipuluje se zprávami či
dokumenty a je řízena pravidly definovanými ve vrstvách vyšších (směrování apod.).“ (2)
Mezi hlavní funkcionality ESB patří:
• Zasílání zpráv v různých modelech,
• směrování zpráv, dle adresy nebo obsahu,
• záruka doručení zpráv,
• logování a auditování,
• administrace a monitorování,
• zajišťování bezpečnosti,
• podporuje distribuované prostředí,
• nástroje pro definici procesů a orchestraci služeb,
• nástroje pro zpracování a transformaci dat.
Obrázek 3: Enterprise Service Bus (IBM)
1.5.
Cesta k SOA a její milníky
Společnost ZapThink, zabývající se servisně orientovaným poradenstvím, vytvořila
SOA Implementation Roadmap, cestovní mapu, která velmi dobře charakterizuje cestu
podniku k SOA architektuře. Tuto cestu dělí pět milníků:
1. Point-to-point integrace.
V této fázi tvoří podnikový informační systém heterogenní systémy s proprietálním
rozhraním.
2. Volně vázané služby.
Vytváří se governance framework.
3. Spolehlivé a dohledatelné služby.
V této fázi se implementuje SOA metamodel.
4. Znovupoužitelné služby, které se dají skládat.
Vytváření servisně orientovaných procesů.
5. Enterprise SOA.
Dynamicky dohledatelné služby, servisně orientovaný podnik.
1.6.
Zralostní model SOA MM (SOA Maturity Model)
Model SOA MM představuje jakousi argumentační pomůcku pro komunikaci mezi IT a
businessem v podniku. Byl vytvořen společností Sonic Software a jejich partnery a zobrazuje
pozitivní dopady do businessu podniku v jednotlivých fázích implementace SOA. Model není
konečný a slouží i jako návrh k dalším diskusím:
„This New SOA Maturity Model provides a framework for discussion between IT and
business users about the applicability and benefits of SOA in an organization across five
levels of adoption maturity. The goal of its authors is not only to provide a means for
organizations to benchmark current implementations, but to offer a source of inspiration as
IT leaders visualize a path to successfully advance the value of SOA for their organizations.“
(3)
Obrázek 4: SOA Maturity Model s pozitivními dopady v jednotlivých úrovních (Progress Sonic)
Kdy SOA nemusí být vhodná
Situace, kdy SOA není přínosem, definuje Jindřich Štumpf ze společnosti Progress
Software takto:
•
•
•
•
IT prostředí je homogenní.
IT prostředí zůstává neměnné.
Čas zpracování je pro můj byznys nerozhodující.
Těsné svázání (špagety) je pro mě výhodou.(4)
Budoucnost SOA v podání analytických firem
• Yankee Group odhaduje, že 75% firem plánuje rozsáhlé investice do SOA.
• Forrester odhaduje, že koncept SOA může snížit náklady IT projektu o 30% a více.
• Gartner se domnívá, že 60% podniků uvažuje o nasazení SOA pro své nové, pro
podnik kritické aplikace.
2. Business Process Execution Language
Business Process Execution Language (BPEL) je jazyk pro specifikaci chování procesů,
jak se ostatně můžeme dočíst hned v úvodu jeho standardu v aktuální verzi WS-BPEL v2.0
z 11. dubna 2007:
„This document defines a language for specifying business process behavior based on Web
Services. This language is called Web Services Business Process Execution Language
(abbreviated to WS-BPEL in the rest of this document). Processes in WS-BPEL export and
import functionality by using Web Service interfaces exclusively. “(5)
2.1.
Evoluce jazyka BPEL
Jazyk BPEL vznikl kombinací dvou workflow jazyků – WSFL (Web Services Flow
Language) od IBM a jazyku XLANG od Microsoft. Po sloučení těchto jazyků se standardizace
ujalo sdružení OASIS, které nejprve vedlo BPEL pod označením BPEL4WS (BPEL for Web
Services), toto označení později změnilo na současné WS-BPEL.
Aktivitou několika předních firem v oboru v současné době spatřila světlo světa i
specifikace BPEL4People a WS-Human Task, která zahrnuje do procesů modelovaných
jazykem BPEL i lidskou interakci.
2.2.
BPEL proces
„A BPEL process specifies the exact order in which participating Web services should be
invoked, either sequentially or in parallel. With BPEL, you can express conditional behaviors.
For example, an invocation of a Web service can depend on the value of a previous
invocation. You can also construct loops, declare variables, copy and assign values, define
fault handlers, and so on. By combining all these constructs, you can define complex business
processes in an algorithmic manner. In fact, because business processes are essentially
graphs of activities, it might be useful to express them using Unified Modeling Language
(UML) activity diagrams. “(6)
Jak uvádí samotná specifikace jazyka WS-BPEL, BPEL proces specifikuje řád, ve kterém
jsou služby sekvenčně či paralelně spouštěny. Umožňuje specifikovat podmínky, cykly,
deklarovat proměnné, přiřazovat těmto proměnným hodnoty, ošetřovat výjimky a další.
Doporučováno je grafické vyjádření BPEL procesu, tj. BPEL proces vhodným způsobem
vizualizovat. Obvykle se tak děje buď v notaci UML či podobným způsobem obvykle v rámci
komplexního řešení CASE nástrojů v portfoliu produktů společností tímto se zabývajících.
S BPEL se lze setkat skutečně v řadě řešení, pro příklad uveďme Oracle BPEL Process
Manager, Microsoft BizTalk, IBM WebSphere Business Integration Server, BEA WebLogic a
řada dalších.
Abstraktní a vykonatelné procesy
Jazyk BPEL umožňuje specifikovat procesy ve dvou podobách:
„The basic concepts of WS-BPEL can be applied in one of two ways, Abstract or Executable.
A WS-BPEL Abstract Process is a partially specified process that is not intended to be
executed and that must be explicitly declared as ‘abstract’. Whereas Executable Processes
are fully specified and thus can be executed, an Abstract Process may hide some of the
required concrete operational details expressed by an Executable artifact. “(6)
Abstraktní proces je částečně specifikovaný proces bez interních detailů, který není
určen pro bezprostřední vykonání. Specifikuje vnější chování procesu, tj. výměnu zpráv mezi
zúčastněnými stranami.
Vykonatelný proces je naopak plně specifikovaný a je určen pro vykonání BPEL
enginem.
Uveďme si příklad vizualizace BPEL procesu. Proces popisuje zajištění letenky pro
služební cestu zaměstnance, kdy se posuzuje nabídka dvou společností a vybere se
výhodnější letenka:
Obrázek 5: Vizualizace BPEL procesu (Oracle)
3. Společnost Progress Software a její přístup k SOA a integraci
3.1.
Představení Progress Software
Americká společnost Progress Software byla založena v roce 1981 pod názvem Data
Language Corporation a na Progress Software Corporation byla přejmenována v roce 1987.
Zaměstnává 1600 v 90 zemích světa. Svojí pobočku má i v České republice. Její produkty jsou
využívány ve více než 60 tisících organizacích.
Progress poskytuje aplikační vybavení pro vývoj, integraci a management
podnikových aplikací a mj. silně podporuje servisně orientovanou architekturu. Orientaci
Progressu na SOA umocnilo získání společnosti Actional Corporation v roce 2006, která
poskytuje software pro management SOA.
3.2.
Proč právě Progress?
Progress v průzkumech
Silnou pozici Progressu v oblasti SOA potvrzují i průzkumy společnosti Gartner či
Forrester. V gartnerovském průzkumu „Magic Quadrant for Integrated SOA Governance
Technology Sets, 2007“ zabývajícím se mírou podpory SOA v produktech společností
Progress zaujímá místo mezi lídry trhu:
Obrázek 6 : Magic Quadrant for Integrated SOA Governance Technology Sets, 2007 (Gartner)
Gartner v textové části průzkumu dodává:
• „Progress has reinvented itself with the Sonic ESB.
• Acquisition of Actional gave users the oportunity to have an out-of-the-box, well
governed solution and further distinguishes Progress.
• Weak marketing of Actional products allowed competitors SOA Software and Amber
Point to rise to prominence in policy management and administration.
• In 2006, linkage in the messaging and marketing of Actional and Sonic caused market
confusion and trepidation about Progress technologies in a heterogeneous
environment.
• Progress must better position Actional as a general-purpose governance solution,
with or without Sonic. “ (7)
Forrester v průzkumu „The Forrester Wave: Standalone SOA and Web Services
Management Solutions, Q4 2007“ řadí Progress zcela na špičku společností zabývajících se
SOA.
Obrázek 7 : The Forrester Wave: Standalone SOA and Web Services Management Solutions, Q4 2007
3.3.
Produkty zaměřené na servisně orientovanou architekturu –
Progress SOA Portfolio
Obrázek 8 : Real World SOA (Progress Software)
Jak už obrázek napovídá, Progress SOA Portfolio zahrnuje tyto produkty pokrývající
tyto oblasti SOA:
•
•
•
•
•
•
•
•
Enterpise Service Bus: Sonic ESB
Enterprise Messaging: Sonic MQ
SOA Management: Actional SOA Management
Datová interoperabilita: DataXtend Semantic Integrator
Komplexní procesing událostí (Complex Event Processing): Apama
Business Process Management
Registry/Repository
Integrace mainframu do SOA (Mainframe Integration): Shadow
Jak již bylo zmíněno dříve Progress získáním společnosti Actional získává i řešení pro
SOA Governance. Řešení vizualizuje aktuální provoz SOA pomocí agentů přítomných
v každém nodu a podávajících hlášení do centra. Můžeme tak sledovat výměnu zpráv aktuální zatížení a řadu dalších analýz:
Obrázek 9: SOA Governance (Progress Actional)
4. Integrace, CASE a produkty společnosti IDS Scheer
4.1.
Představení IDS Scheer
Německá společnost IDS Scheer je předním dodavatelem BPM (Business Process
Management) software. Její zakladatel Prof. Dr. August Wilhelm Scheer stál přímo u počátků
BPM.
Vlajkovou lodí společnosti je sada produktů pod názvem ARIS Platform for Business
Excellence, integrované portfolio řešení pro strategii, návrh, implementaci a řízení
podnikových procesů. V této platformě různých řešení nalezneme i nástroje pro informační
systém, který se vydává cestou SOA.
IDS Scheer významně spolupracuje např. se společnostmi Microsoft, Oracle a SAP pro
které svá řešení dotváří dle jejich požadavků. Zvláště pro SAP je určena řada nástrojů
z platformy ARIS.
4.2.
Platforma ARIS
Řešení platformy ARIS je děleno do čtyř základních částí, tzv. modulů, které kopírují
fáze projektu zavádění informačních systémů v podání IDS Scheer:
• ARIS Strategy Platform, sloužící pro tvorbu strategie, vytváření celopodnikového
systému Balanced Scorecards, zjišťování nákladů na procesní plánování apod.
• ARIS Design Platform, pokrývající oblast modelování, optimalizaci, simulaci, publikaci
podnikových procesů a řízení podnikové architektury.
• ARIS Implementation Platform. Implementační platforma, zde nacházíme nástroje
pro servisně orientovanou architekturu, resp. její vývoj. Ale také nástroje pro
procesní inženýring software, export podnikových procesů do prostředí SAP
NetWeaver apod.
• ARIS Controlling Platform je platforma pro monitoring stávajících procesů.
Vzhledem k tématu práce budeme dále sledovat podrobnosti především modulu ARIS
Implementation Platform, kde se skrývají nástroje pro podporu integrace a SOA.
4.3.
Platforma ARIS, integrace a servisně orientovaná
architektura
Modul ARIS Implementation Platform přímo obsahuje nástroj pro modelování a
podporu servisně orientované architektury ARIS SOA Architect. Nástroj navrhuje SOA
architekturu na základě procesů probíhajících v podniku, tedy jsme u procesu jako základu
SOA. Modelování procesů se děje na standardu EPC. Nástroj umožňuje identifikovat službu
pomocí své funkcionality ARIS Service Browser. Správnou identifikací by mělo být zajištěno i
opakované používání služeb, což je jak známo žádoucí vedlejší efekt SOA. ARIS SOA Architect
umožňuje odvodit spustitelné BPEL procesy z modelových procesů EPC. Takto vyexportovaný
proces je spustitelný na různých platformách. ARIS SOA Architect též vytváří centralizovanou
SOA repository.
Vůbec celé řešení pro SOA IDS Scheer zastřešuje pod názvem ARIS Solution for
Business-Driven SOA Management, které obsahuje aplikační scénáře pro architekturu,
orchestraci služeb, vývoj služeb a aplikací a práci s procesy.
Obrázek 10: ARIS SOA Designer (IDS Scheer)
4.4.
Platforma ARIS a modelovací standardy
IDS Scheer ve své platformě ARIS již tradičně podporuje řadu modelovacích
standardů. Jedná se zejména o standardy:
• EPC (Event Driven Process Chain – řetězec procesů řízený událostmi). Přední
průmyslový standard pro modelování procesů.
• BPMN (Business Process Modeling Notation). Hojně užívaný standard pro modelování
procesů.
• UML (Unified Modeling Language). Standard se širokým použitím, jeho základnou je
softwarové inženýrství.
• BPEL (Business Process Execution Language). Standard pro definování chování
procesů, o kterém šířeji pojednává jedna z kapitol této práce.
• WSDL (Web Services Description Language). Standard pro popis rozhraní webových
služeb.
5. Nástroje a přístupy společnosti Oracle
5.1.
Integrace dat
Existuje velké množství různých metod a produktů dostupných na trhu, které se
integrací dat a aplikací zabývají. V následující kapitole jsou popsány produkty a koncepce
řešení nabízené společností Oracle.
Oracle Warehouse Builder
Oracle Warehouse Builder (OWB) je primárním nástrojem společnosti Oracle pro ETL
procesy. V současné době je obsažen přímo v základní instalaci Oracle databáze1. Tento
nástroj není zaměřen pouze na oblast ETL a datových skladů, nabízí funkcionalitu pro vizuální
modelování datových objektů, správu metadat, hromadný upload dat, řízení datové kvality,
podpora SOA architektury, využití data miningu pro obohacování stávajících dat aj. OWB lze
připojit k téměř všem datovým strukturám, databázím i aplikacím a to nejen těm, které
pocházejí z rodiny produktů Oracle. Právě díky nativní podpoře všech zdrojů je OWB dobrým
nástrojem pro integraci. Podpora SOA architektury umožňuje napojení se k obrovskému
množství služeb a plnit nejrůznější cílové zdroje a aplikace2.
Hlavní funkcionalita:
•
Vizuální modelování, návrh datových toků a transformací
•
Integrované nástroje pro kontrolu datové kvality
•
Generování SQL a PL/SQL kódu jednotlivých mapování
•
Možnost znovupoužití definovaných mapování
•
Správa celého životního cyklu dat, audit dat, uchovávání historie
•
Možnosti využití datové pumpy, transportních tablespaces
Téměř každá organizace nebo společnost má implementován systém ERP nebo CRM
popř. nějaké další. Existence těchto systémů vyvolává potřebu sdílení jejich dat s ostatními
systémy nebo datovými sklady. OWB obsahuje přímé konektory k nejvýznamnějším
výrobcům těchto systémů (např. pro SAP, PeopleSoft, Siebel, Oracle eBusiness Suite).
1
Standardně od verze databáze Oracle 11g
2
Oracle Warehouse Builder – Statement of Direction, October 2006. Oracle Corporation.
http://www.oracle.com/technology/products/warehouse/pdf/TWP_BIDW_OWB_Roadmap_1006.pdf
Obrovskou výhodou těchto konektorů je, že jejich prostřednictvím OWB rozumí daným
metadatům a tím do značné míry zjednodušuje proces extrakce dat. SAP konektor dokonce
rozumí proprietárnímu jazyku ABAP, který SAP používá pro hromadnou manipulaci s daty.
Příklad transformace a přenosu dat z aplikace SAP do cílového skladu Oracle:
1. inicializace mapování (z OWB nebo automaticky procesem v rámci aplikace
SAP)
2. OWB zavolá jazyk ABAP (SAP), případně požadovaný kód mapování nahraje na
server SAP
3. ABAP podle daného mapování extrahuje data a uloží je na dohodnuté místo
k sobě na serveru do plochého souboru
4. OWB stáhne vygenerovaný soubor přes FTP protokol
5. SQL loader zavolaný OWB nahraje data do cílové databáze
Všechny tyto kroky jsou z pohledu vývojáře pouze jedním komplexnějším mapováním
v OWB, které je provedeno v jeho grafickém prostředí s využitím několika průvodců3.
Grafické prostředí s rozpracovaným mapováním z více zdrojových tabulek do jediné cílové je
vidět na obrázku 11.
Obrázek 11 Mapování dat v prostředí OWB 10g R2
3
Oracle Warehouse Builder 10gR2 – Integrating Packaged Applications Data, June 2006. Oracle Corporation.
Oracle Data Integrator (ODI)
Produkt Oracle Data Integrator je v mnohém podobný Oracle Warehouse Builderu.
Společnost Oracle považuje OWB za nástroj pro vývoj, zatímco ODI je pro ni hlavně
nástrojem pro integraci. ODI pochází z rodiny produktů Oracle Fusion Middleware. Má tedy
blíže k SOA přístupu k integraci aplikací4.
Oracle Data Hub
S integrací dat souvisí problémy datové kvality, ale i samotné správy dat a jejich
významu. Tuto problematiku řeší Oracle s pomocí produktů Master Data Management
(MDM) – Oracle Data Hub. Pro všechny společnosti bez ohledu na průmyslová odvětví, ve
kterých se pohybují, je nutné udržet a sdílet stejný význam dat. Tento účel zabezpečují
následující součásti Oracle Data Hub:
•
•
•
Customer Hub
o komplexní řešení celého životního cyklu zákaznických dat od získání
a obohacování po dolování znalostí z nich dostupných
Product Hub
o centralizace dat o produktech ze všech podnikových aplikací
a oddělení
Hyperion DRM
o důraz na finanční a analytická data, pomoc při akvizicích apod.
Graficky vyjádřený pohled společnosti Oracle na tuto problematiku jako na soubor
specifických oblastí je zobrazen na obrázku 12. Důvod, proč se o těchto produktech
zmiňujeme v této práci, je prostý – pro úplnou a úspěšnou integraci dat a aplikací je nutná
jejich kontrola a správná interpretace. Mnohé společnosti používající např. ODI mohou dojít
do fáze, kdy je množství dat a ETL vývojářů již tak vysoké, že je potřeba nějaké zastřešující
řešení – Oracle Data Hub, který zajistí opravdu jednotný pohled na napříč celou organizací.
Základem je zpravidla vytvoření nového identifikátoru pro danou entitu a jeho sdílení všemi
propojenými systémy. Tímto způsobem lze zajistit další funkcionalitu a další možnosti, např.
uchovávání
historických
dat,
implementace
nejrůznějších
a předpřipravená integrace do nástrojů Bussiness Intelligence.
4
Oracle Data Integrator – Technical Overview, December 2006. Oracle Corporation.
bezpečnostních
politik
Chyba! Nenalezen zdroj odkazů.
5.2.
Integrace aplikací (Oracle Integration)
Integrace aplikací pomocí produktů Oracle probíhá v zásadě podle níže uvedeného
schématu s rozdílem třetí vrstvy (sloupce), kde místo množiny řešení Integration B2B lze
využít např. Integration Interconnect. Tyto přístupy jsou popsány podrobněji dále v této
kapitole.
Podstatnou součástí je BPEL Process Manager, který umožňuje vizuálně definovat
procesy – základ – obchodní logiku, kterou lze implementovat různě, dle aktuálních
podmínek a stávajících technologií a aplikací, které používají obchodní partneři.
Obrázek 123 Integrace produkty Oracle
Oracle Integration InterConnect
Základním kamenem integrace v rámci Oracle Integration Interconnect je Enterprise
Service Bus (ESB), který umožňuje rychlé zpřístupnění služeb a aplikací ve společnosti5.
Služby mohou být založeny na SOA architektuře nebo na pomocí tzv. Event Driven
Architecture (EDA).
Principem integrace je zpřístupnění služeb nebo definování událostí, které iniciují
komunikaci mezi dvěma nebo více aplikacemi. ESB shromažďuje na jednom místě metadata
o dostupných službách nebo událostech6.
Nástrojem pro design a nasazení je Oracle JDeveloper, který umožňuje v povedeném
grafickém prostředí způsobem drag & drop spolu s různými průvodci definovat, propojovat a
nasazovat služby do ostrého provozu, navrhovat jejich posloupnosti a registrovat je do ESB.
Obsahuje rovněž WSDL editor webových služeb nebo editor XML schémat podle standardu
XML Schema.
Oracle BPEL Process Manager
Oracle BPEL Process Manager a jeho komponenty BPEL Designer, BPEL Server a BPEL
Console je nástroj pro návrh, nasazení a správu procesů s využitím jazyka BPEL (Business
5
Oracle Application Server 10g – Integration. Dostupné na
http://www.oracle.com/technology/products/integration/pdf/Oracle_Integration_Whitepaper.pdf
6
Oracle Application Server 10g – Integration Interconnect. Dostupné na
http://www.oracle.com/technology/products/integration/esb/pdf/wp_interconnect_v10_1_2.pdf
Process Execution Language). Hlavní devizou tohoto produktu je zpřehlednění, rozdělení,
ladění a zjednodušený vývoj procesů, a to nejen obchodních, ale např. i těch integračních.
Jazyk BPEL
Podobně jako dotazovací jazyk SQL změnil a ovlivnil vývoj databázových systémů a
cestu jak z nich získávat strukturovaná data nebo tak jako (x)HTML standardizovalo cestu
k zobrazení milionů webových stránek na internetu, tak je jazyk BPEL silným prostředkem
pro vyjádření, zápis a spouštění procesů nejen v oblasti webových služeb. Společným
jmenovatelem těchto jazyků je jejich nezávislost a to jak k různým operačním systémům tak i
výrobcům technologií a softwarového vybavení. Některé nástroje pracují s upravenou verzí
jazyka BPEL a vzdalují se tak původní myšlence. Oracle BPEL Process Manager však využívá
přesné definice jazyka BPEL, tak jak jej definovala organizace OASIS7 a zajišťuje stoprocentní
přenositelnost bez dodatečných úprav.
BPEL Server
Samotný BPEL Process Manager může běžet i na jiném aplikačním serveru než na
serveru Oracle a není nutné jeho propojení s Oracle databází, ačkoli to přináší jisté výhody.
BPEL Designer
Povedené grafické prostředí produktu BPEL Designer nabízí uživateli příjemnou cestu
k efektivnímu modelování procesů. Je implementován s využitím standardizovaného jazyka
BPEL jako součást vývojářského nástroje Oracle Jdeveloper.
Vestavěné integrační komponenty ulehčují vývojářům vytváření procesů, jejichž cílem
je např. propojení dat z různých aplikací. Tyto komponenty jsou dostupné ve standardní
paletě nástrojů a vývojáři tak mohou velice jednoduše např. zpřístupnit obsah databázové
tabulky přes webovou službu, jejíž rozhraní je automaticky vytvořeno. Lze tak integrovat
např. webové aplikace vytvořené v PHP s jejich protějšky běžícími v Oracle Portalu.
Zpřístupněním operace select nad danou datovou tabulkou prostřednictvím webové služby,
tak lze docílit např. toho, aby zákazník dostal shodnou informaci, např. o počtu nějakého
druhu zboží zbylého na centrálním skladu firmy. Jak již bylo naznačeno dříve, produkty jako
7
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel
je OWB nebo ODI také podporují webové služby, soustředí se však spíše jen na datovou
úroveň zatímco BPEL je již prostředkem, který lze přímo začlenit do aplikační architektury.
Oracle Integration B2B
Oracle E-commerce Gateway
Oracle E-commerce Gateway je standardizovaný přístup k integraci mezi externími
aplikacemi a produktem Oracle E-Business Suite8. E-Business Suite je informační systém –
aplikace složená z různých modulů podporujících chod a řízení podniku. Je to jedna
z nejznámějších aplikací společnosti Oracle a její cena je poměrně vysoká9.
Integrace s aplikacemi třetích stran je prováděna v rámci produktu E-commerce
Gateway na základě formátu pro výměnu dat EDI. Tento standard je v praxi i přes některá
úskalí stále hojně používán a to hlavně v některých průmyslových odvětvích, např.
v automobilovém průmyslu. E-commerce Gateway je s E-Business Suite integrován tak, že
Obrázek 14 schéma integrace E-Business Suite a EDI
8
E-Business Suite Tools and Technology [online]. Dostupné na
http://www.oracle.com/technology/products/applications/ebs/index.html (navštíveno 15.4.2008)
9
standardní cena (bez možné slevy) je k 16.11.2007 $ 2 000,-- na uživatele
přijímá nebo generuje soubory ASCII ve formátu EDI, které jsou pak překladačem třetí strany
mapovány10. Schéma, viz obrázek 14, ukazuje jak je systém E-Business Suite propojen přes
formát EDI k obchodním partnerům.
Oracle E-commerce Gateway obsahuje předdefinované transakce klíčových
obchodních dokumentů. Spolu s určením obchodního partnera a povolením uskutečnění
transakcí v testovacím nebo produkčním módu je lze v krátké době po implementaci začít
používat v reálném provozu. Předdefinované transakce lze upravovat a přizpůsobovat
specifickým požadavkům zákazníků. Nastavit lze jednorázové transakce, skupiny transakcí
nebo celý obchodní proces. Transakce jsou zpravidla konfigurovány ve spojení s dalšími
moduly produktu E-Business Suite. Například s Oracle Purchasing, Supplier Scheduling,
Purchase Orders nebo Payables.
Integrační prostředí může být nastaveno na několika různých úrovních. Kontrola dat a
procesů je uskutečněna na úrovni systému, transakce nebo obchodního partnera. Lze
nastavovat strukturu a způsob jakým se data validují a mapují a jak se celý proces chová.
Podstatnou součástí E-commerce Gateway jsou meta-data. Obsahují data o obchodních
partnerech, transformacích a validačních pravidlech, na jejichž základě běží nastavené
procesy. Pokud je potřeba změnit proces stačí aktualizovat meta-data a tím se změní
i procesy a to bez nutnosti měnit programový kód a přerušit tak běh aplikace11.
Řešení případných problémů a výjimek je prováděno v rámci modulu, který svým
stromovým charakterem usnadňuje hledání příčin nestandardního chování. Po vyřešení
výjimky lze transakci obnovit a zavést ji zpět do procesu.
Hlavními přednostmi E-commerce Gateway je propojení s Oracle databází využitelné
pro generování odchozích a importování příchozích zpráv, přiřazení obchodního partnera
vytvořeného v Oracle E-Business Suite, možnost automatického zrušení procesů, kde vznikla
chyba a odesílání zpráv pomocí různých protokolů12. Výhodou Oracle E-commerce Gateway
je také uživatelské prostředí, které je podobné pro všechny propojené moduly, dialogy a
obrazovky řešení výjimek a je typické pro produkty Oracle.
10
Oracle XML Gateway User’s Guide. Oracle Corporation. Release 11i, October 2001, str. 30.
11
Oracle E-Commerce Gateway 11i. Oracle Corporation. September 2004, str. 5.
12
SMTP, HTTP(s), SOAP
Oracle XML Gateway
Tento produkt je podobný Oracle E-commerce Gateway. Hlavním rozdílem je
posílání dat a obchodních zpráv ve formátu XML. XML zprávy posílané přes XML Gateway
jsou stejně jako EDI transakce elektronické zprávy definované určitým standardem. Na
základě různých obchodních událostí jsou tyto zprávy generovány a přijímány. V produktu je
integrován XML Parser zajišťující, že zprávy jsou well-formed a validní13.
Oracle Integration BAM
Tento produkt je jakousi střechou nad zmíněnými možnostmi integrace v rámci
produktů Oracle. Slouží k monitorování obchodních aktivit napříč společností a jejími
partnery. Shromažďuje informace o událostech procházejících všemi integračními
komponentami (Interconnect, BPEL Process Manager, B2B Integration). Z těchto informací
generuje a KPIs, které jsou důležité pro monitorování chodu společnosti z pohledu
vrcholových manažerů a managementu společnosti.
Prostředí BAM je velice podobné s Business Intelligence portálem. Lze nadefinovat
různé typy diagramů a podpůrných tabulek obsahujících podrobnější data.
13
Oracle XML Gateway 11i. Oracle Corporation. September 2004, str. 5.
6. IBM
Firma IBM je jedním z předních hráčů na trhu s integračními nástroji. Jedná se o
dynamickou firmu, která se stále přizpůsobuje nejnovějším trendům. Není tedy
překvapením, že nabídka zahrnuje i produkty orientující se na SOA (servisně orientovaná
architektura). V úvodní kapitole jsme se dozvěděli, že SOA představuje hlavní a velmi
využívaný přístup pro integraci. IBM se snaží, co nejvíce SOA využívat a také podporovat.
Obrázek 15 Smart SOA od IBM
Důkazem tomu je zavedení architektury Smart SOA, která ze, jak již název vypovídá, ze SOA
vychází a která se snaží co nejvíce tento přístup přiblížit veřejnosti.
Celý koncept Smart SOA (8), jak lze vidět na obrázku 15, je rozdělen do čtyř bloků.
Základní styl zajišťuje větší agilitu v konkrétních obchodních oblastech daného oddělení. Styl
komplexního rozšíření zajišťuje optimalizaci a inovaci napříč komplexními podnikovými
procesy, které zahrnují osoby, procesy a informace. Styl transformace implementuje inovaci
podnikového modelu pro podporu vašeho globálně integrovaného podniku a styl dynamické
adaptace je ideál budoucnosti spočívající v automatickém sledování a reagování na síly trhu
bez lidského zásahu, který je v současnosti nezbytný. IBM se však nesoustředí pouze na teorii
okolo servisně orientované architektury, ale snaží se také tento koncept podporovat svými
produkty. Jednotlivé produkty představím v následujících kapitolách.
6.1.
Charakteristika produktů
Obrázek 16 Cyklus vývoje a integrace informačního systému
Společnost IBM podporuje svými produkty celý cyklus vývoje a také integrace
informačního systému. Tento cyklus je zobrazen na obrázku 16. Základní skupinou produktů,
které zabezpečují právě vývoj a integraci je rodina produktů Websphere. Jedná se o
komplexní sadu, která umožňuje profesionální zajištění všech fází cyklu. První fáze je
označena jako analýza. V ní je nutné popsat stávající systém, z tohoto popisu pak vycházejí
další fáze. Analýza je zajištěna produktem Websphere Business Modeler. V další fázi pak
přichází na řadu již design budoucího stavu. V této části je opět kladen důraz na modelování
jednotlivých komponent, a tak je zde využit opět Websphere Business Modeler. Výsledné
modely je možné exportovat do různých formátů, toho je také využito při další fázi. Při
implementaci jednotlivých komponent se totiž vychází právě z těchto modelů a IBM se snaží
co nejvíce zjednodušit a zefektivnit práci analytiků a vývojářů. Websphere Integration
Developer, který je zde používán, je schopen vytvořené modely importovat a dále s nimi
pracovat. Takovéto komunikace je využito především u vývoje informačního systému, kde
základ vývoje tvoří procesy. O komunikaci mezi těmito produkty a o dalších podrobnostech
budu psát dále. Pokud máme jednotlivé komponenty namodelovány a poté i
naimplementovány, pak potřebujeme něco, co zajistí jejich chod. I na tuto část existuje
v rodině produktů Websphere nástroj – Websphere Process Server. Jedná se o komplexní
platformu, která umožňuje integraci procesů. Websphere Process Server je založen na
architektuře SCA (Service Component Architecture) (9), která udává standardy pro aplikace
vyvíjené v souladu se SOA. SCA byla vyvíjena několika firmami (IBM, BEA, SAP, Oracle, atd.)
tak, aby byla zajištěna kompatibilita mezi jednotlivými prostředími. Není překvapením, že i
zde je kladen důraz na komunikaci s ostatními produkty Websphere. Důkazem může být i
možnost importování modelů z Websphere Business Modeleru. Kromě standardních funkcí,
jako je deployment procesů a jejich administrace, poskytuje Process Server také možnost
integrace aplikací B2B nebo integrace systému ERP. Jestliže jsou procesy implementované a
běží na serveru, pak se určitě hodí další produkt od firmy IBM – Websphere Business
Monitor (11). Tento nástroj poskytuje širokou škálu možností, jak monitorovat podnikové
procesy. Nejvíce Business Monitor ocení vedení podniku, které tak získá dokonalou kontrolu
nad svými procesy. Umožňuje jim to zejména monitoring procesů v reálném čase nebo
schopnost monitorovat a analyzovat výkonnost daných procesů. Nástroj k tomu poskytuje
Obrázek 13 Nástroje společnosti IBM používané při vývoji a integraci
možnost stanovení KPI (key performance indicators – klíčové ukazatele), jež jsou poté
porovnávány se strategickými cíli, které jsou podporovány právě procesy. Vedení podniku
jistě také ocení různé možnosti zobrazení výsledků monitoringu. Na začátku jsem mluvil o
cyklu, tak není divu, že zde není konec. Celý fungující systém je postaven opět na začátek a
může se začít s novým modelováním a analýzou. Můžeme tedy říci, že vývoj může
pokračovat neustále a společnost IBM se snaží co nejvíce usnadnit celou tuto cestu. Abych
byl úplný tak integraci a vývoj nezajišťují jen výše zmíněné aplikace, ale i jiné nástroje, jejichž
důležitost je různá. Malý přehled těchto nástrojů je zobrazen na obrázku 17.
V dalších částech bych se chtěl zaměřit na nástroje, které jsou spjaté s CASE
(computer-aided software engineering).
6.2.
Websphere Business Modeler (10)
Jak jsem již psal v minulé kapitole, Websphere Business Modeler slouží hlavně
k analýze a modelování informačních systémů. Tento software nabízí komplexní a uživatelsky
přívětivé schopnosti modelování business procesů. Jeho úlohou je hlavně efektivní
modelování procesů a tvorba komplexních procesních modelů. Stejně jako u jiných
podobných nástrojů poskytuje i možnost simulace. Celkově vzato Modeler nabízí statickou i
dynamickou simulaci na základě různých ukazatelů, okamžité vyhodnocování změny včetně
možnosti porovnávání výsledků formou reportů. Samozřejmě je zde i podpora centrálního
úložiště (repository), kam je možné přistupovat i pomocí webového prohlížeče.
Již jsem také psal o spolupráci s jinými produkty firmy IBM. Právě na komunikaci
nástrojů IBM hodně lpí. Důkazem toho může být například spolupráce s rodinou produktů
Lotus nebo s produkty FileNet (DMS – document management system). Pokud však
Obrázek 18 Ukázka nástroje Websphere Business Modeleru
hovoříme o integrace, mnohem důležitější je komunikace s Websphere Business Monitorem
a Websphere Integration Developerem. V prvním případě se jedná o monitoring
namodelovaných výstupů. Spolupráce s Integration Developerem je pro integraci
podstatnější. Vytvořené modely procesů je možné právě v tomto nástroji importovat a dále
s nimi pracovat. To je dáno vesměs striktním dodržováním standardů ze strany IBM. Tento
nástroj je označován jako „most“ mezi businessem a IT, což právě dokazuje tento odstavec.
Jestliže jsem zmínil standardy, pak hlavním standardem ve smyslu procesní integrace
je notace BPMN. Jsou zde sice odlišnosti oproti původní notaci BPMN, ale základ tvoří právě
tento standard. Ukázku procesu vytvořeného ve Websphere Business Modeleru můžete
vidět na obrázku 18. Druhou klíčovou specifikací pro Modeler je bezesporu XPDL (XML
Process Definition Language). Jak již název napovídá XPDL je založeno na standardu XML,
konkrétně vytváří XML schéma pro uložení namodelovaných business procesů. Právě
modeler je schopen modely exportovat do tohoto formátu. Tato schopnost je právě klíčová a
díky ní je možné pracovat s vytvořenými modely v ostatních aplikacích. Samozřejmostí je i
podpora dalších standardů, jakými jsou například UML (Unified Modeling Language) nebo
FDL (Flow Definition Language).
V současné době existují dvě verze tohoto softwaru. Tou základní je edice Basic, která
obsahuje základní nástroje pro modelování procesů. Druhou verzí je edice Advanced, která je
nadstavbou prvně jmenované verze. Oproti ní však nabízí možnost statické a dynamické
simulace. Celé toto pak doplňuje Websphere Business Modeler Publishing Server, který
vytváří repository modelů. Pomocí tohoto nástroje je zajištěno sdílení veškerých dat.
6.3.
Websphere Integration Developer (12)
Websphere Integration Developer je oproti Modeleru zaměřen již na konkrétní
implementaci procesů. Oba tyto nástroje mají společné IDE, na kterém jsou postaveny.
Konkrétně se jedná o prostředí Eclipse, které bylo vyvíjeno právě společností IBM a které
bylo posléze i uvolněno jako open source nástroj. Vývojáři a lidé pohybující se okolo tvorby
softwaru jistě vědí, že Eclipse je převážně určeno pro programovací jazyk Java. Není tedy
divu, že vývoj a integrace v nástrojích Websphere je právě orientováno na Javu. Praxe
ukázala, že Java je velmi vhodný programovací jazyk v této oblasti, důkazem toho jsou i
nástroje jiných firem.
Nejvýznamnější roli v tomto nástroji bezpochyby hraje standard BPEL (Business
Process Execution Language). BPEL je nejpoužívanějším standardem v oblasti vývoje a
integrace procesů. Integration Developer konkrétně využívá novější verzi standardu – WSBPEL. Samozřejmě BPEL není jediným standardem, a tak se můžeme často setkat i se
standardy jakými jsou například SOAP, WSDL, JMS (Java Message Service), EJB (Enterprise
Java Beans) atd. Integration Developer je často dodáván i s Websphere Process Serverem,
což je i logické, jelikož oba se vzájemně doplňují.
Jak již bylo psáno dříve, SOA neznamená využití pouze webových služeb. IBM tuto
skutečnost bere v potaz, a tak webové služby v procesu mohou být nahrazeny například EJB,
které budou volané přes JMS (nemusí zde být využit SOAP používaný právě u webových
služeb). Velmi významnou roli v Integration Developeru hrají i tzv. human tasky. Jde vlastně o
prvek, kdy je proces nucen interagovat s člověkem. Představme si například proces
objednání zboží. Během tohoto procesu zákazník musí zadat své identifikační údaje. Proces
se tedy dostane do stavu vyčkávání na akci uživatele. Pokud člověk akci dokončí, proces
může pokračovat dále.
Měl jsem možnost si tento software „osahat“. IBM udává, že se jedná o „easy-to-use“
nástroj, kde člověk může i se základními znalostmi programování vytvořit vlastní proces.
V tomto musím dát marketingovým specialistům z IBM za pravdu. Jedná se víceméně o
grafický nástroj a člověk opravdu může vytvořit proces, aniž by napsal řádek kódu. IBM také
poskytuje velké množství návodů a jiných elektronických zdrojů, které značně usnadňují
práci. V nedávné době vyšla i nová verze Developeru (konkrétně 6.1) posouvající tento
nástroj o krok dále. Z nových funkcí bych zejména vypíchl integrované testování.
7. SAP NetWeaver
7.1.
Charakteristika produktu14
Komplexní integrační a aplikační platforma SAP NetWeaver dokáže využít existující IT
infrastrukturu a transformovat ji do platformy umožňující pružně a rychle plánovat, vytvářet,
implementovat a spouštět nové obchodní strategie a procesy. Tato platforma poskytne
příležitost pro inovaci procesů v rámci celé organizace, využitím stávajících systémů a snížení
celkových nákladů na vlastnictví (TCO - Total Cost of Ownership) IT infrastruktury.
SAP NetWeaver sjednocuje integrační technologie do společné platformy a obsahuje
množství standardně dodávaného obsahu – předkonfigurovaných integračních scénářů. SAP
NetWeaver je postaven na průmyslových standardech a je kompatibilní s hlavními
technologickými platformami současnosti, jako jsou Java 2 Enterprise Edition (J2EE);
Microsoft .NET; nebo IBM WebSphere.
Tato platforma je technologickým základem aplikací mySAP Business Suite,
kompozitních aplikací SAP xApps, partnerských řešení a aplikací vyvinutých na míru včetně
kombinovaných aplikací - poskytuje tu nejlepší cestu k integraci všech SAP i non-SAP řešení a
systémů. Podporuje také Enterprise Services Architecture, přehled metod pro obchodní
řešení orientovaná na služby.
Obrázek 19 SAP NetWeaver - schéma
14
Převzato z [14]
Ve zkratce, SAP NetWeaver je jednotnou technologickou platformou a základem
všech aplikací a řešení společnosti SAP.
7.2.
Architektura15
Komponenty
SAP NetWeaver Application Server (WebAS) – klíčová komponenta, vývojová a
provozní platforma založená na standardech, podporuje webové služby, představuje
provozní prostředí pro všechna řešení společnosti SAP, umožňuje propojení
existujících technologických řešení do řešení založeného na webových službách
SAP NetWeaver Business Inteligence (BI) – umožňuje integrovat data z různých
zdrojů a transformovat je do prakticky využitelných informací pro business
rozhodování
SAP NetWeaver Exchange Infrastructure (XI) – komponenta pro integraci procesů,
poskytuje otevřené integrační technologie, které podporují procesní integraci aplikací
SAP NetWeaver Master Data Management (MDM) – zabezpečuje konzistenci
kmenových dat napříč systémem a jejich distribuci napříč podnikovými aplikacemi
SAP NetWeaver Mobile – poskytuje prostředky vzdálený přístup k podnikovým
aplikacím s využitím mobilních zařízení
SAP NetWeaver Enterprise Portal – zahrnuje kompletní infrastrukturu podnikového
portálu, poskytuje informace a aplikace uživatelům dle rolí, které zastávají, obsahuje
nástroje pro podporu spolupráce
SAP Auto-ID Infrastructure – poskytuje prostředky pro integraci automaticky
snímajících zařízení (Bluetooth zařízení, čtečky čárových kódů, snímače ID karet
apod.)
SAP NetWeaver Identity Manager – poskytuje přístupy a možnosti typické pro
konkrétní business, vytváří nové příležitosti pro integraci business procesů, pomáhá
integrovat systém v heterogenním IT prostředí
Nástroje
Adaptive Computing Controller – centrální bod kontroly určení a optimalizace
počítačových zdrojů
SAP NetWeaver Composition Environment – prostředí pro design, rozmístění a běh
aplikací, které vyhovují ESA (Enterprise Service-oriented Architecture)
SAP NetWeaver Developer Studio – prostředí pro vývoj J2EE aplikací
SAP NetWeaver Visual Composer – usnadňuje vytváření portálového obsahu a
analytických aplikací prostřednictvím visuálního rozhraní
15
Převzato z [13]
SAP Solution Manager – podporuje řízení aplikací, umožňuje implementovat,
provozovat, monitorovat a spravovat komponenty konkrétního řešení
Obrázek 20 ESA - schéma
Spolupracující aplikace
ARIS for SAP NetWeaver – poskytuje nástroje pro management business procesů
(BPM)
SAP Conversion Agent by Itemfield – připojuje se k SAP NetWeaver XI adapter
frameworku za účelem transformace semistrukturovaných či nestrukturovaných dat
(COBOL, ACORD apod.) nebo dokumentů (jako Microsoft Word nebo Adobe PDF)
7.3.
ARIS for SAP NetWeaver
Charakteristika16
ARIS for SAP NetWeaver spolu s podrobným metodickým postupem ARIS Value
Engineering for SAP (AVE for SAP) poskytují procedurální modely, metody, technologie a
referenční obsah, který umožní efektivní způsob jak implementovat podnikové procesy v
informačním systému SAP. Dlouholetá intenzivní spolupráce a strategické partnerství mezi
IDS Scheer a SAP AG je zárukou těsné integrace obou řešení.
Nástroj ARIS for SAP NetWeaver umožňuje organizacím definovat požadavky na své
podnikové informační systémy z procesní perspektivy. Obousměrné rozhraní mezi ARIS a SAP
Solution Manager dovoluje využívat dostupné referenční modely SAP.
16
Převzato z [15]
Procesní modely tak firmě slouží jako významná rozhodovací základna. Zajišťují, aby
bylo možné požadované procesy v systému SAP realizovat. Speciální rozhraní BPEL k SAP XI
umožňuje End-to-End-integraci stávajících IT systémů.
Hlavní přínosy:
Procesně orientovaná specifikace a analýza požadavků včetně následného „business
blue-print“
Doladění a usměrnění komplexních End-to-End-podnikových procesů pomocí
referenčních procesů SAP s využitím ARIS, SAP Solution Manager a SAP XI
Transparentní dokumentace a komunikace implementovaných procesů
prostřednictvím integrované metody ARIS
Testování založené na End-to-End-procesu
Provádění tréninků a školení SAP na bázi požadavků definovaných v systému ARIS
Opakované použití procesních modelů SAP pro další aplikační scénáře (ITArchitecture Management, projekty SOA, projekty řízení rizika a Complianceprojekty atd.)
Integrace SAP Solution Manager a SAP NetWeaver Exchange Infrastructure (XI)
Architektura
Produkt tvořený ve spolupráci společností ARIS (modelovací nástroj) SAP (integrační
platforma) lze rozdělit na 3 základní úrovně – modely:
Model procesní architektury (kdo dělá co, s kým a v jakém pořadí) – určuje
management, kritické procesy
Model procesní konfigurace (konkrétní rozložení procesů na kroky) – synchronizace
se SAP SM (blue-print)
Model procesní realizace (napříč aplikacemi) - SAP XI
Obrázek 21 ARIS for SAP Netweaver – schéma – 3 modely
Model procesní architektury
Nejvyšší abstraktní úroveň, sestavována byznys managementem, bez nutnosti
hlubších technických znalostí (notace UML). Jeho smyslem je grafické znázornění
vysokoúrovňových procesů uvnitř společnosti a jejich úprava za účelem optimalizace a
odhalení kritických míst procesů tak, aby co nejefektivněji naplňovaly podnikové cíle (tj.
určení, kdo dělá co, s kým a v jakém pořadí). Výstup tvoří procesní diagramy uložené ve
vícejazyčném repositáři, umožňujícím automatické generování dokumentace a schémat pro
byznys implementaci či školení personálu.
Klíčovým faktorem pro úspěšné zavedení modelovaných scénářů, procesů a dílčích
kroků je kvalitní a škálovatelná IT implementace, která musí být dostatečně adaptabilní na
změny byznys požadavků v závislosti na vývoji trhu.
Model procesní konfigurace
Zahrnuje bezztrátovou transformaci procesů na aplikační vrstvu, ať už rozložením na
jednotlivé kroky či celé mySAP scénáře, napříč všemi komponentami SAP Business Suite. To
je zajištěno obousměrnou synchronizací mezi nadstavbou ARIS for SAP NW a SAP Solution
Manažerem, resp. sestavení detailních blue-print schémat. Jinými slovy se jedná o realizaci
úzkého propojení mezi globálními procesy a konkrétní SAP implementací.
Obrázek 22 ARIS for NW – ukázka procesního modelu
Obrázek 23 ARIS for NW – ukázka synchronizace s aplikací SAP Solution Manager
Model procesní realizace
Nejnižší úroveň, kdy jsou jednotlivé procesy (popsané v notaci BPEL) vykonávány
aplikací SAP XI, resp. jejím běhovým prostředím Integration Server. SAP platforma
Obrázek 23 ARIS for NW – ukázka exekučního modelu
automaticky zajišťuje propojení mezi-aplikačních a mezi-systémových procesů, jejich
seskupování a orchestraci.
Závěr
Přínos této práce je zejména v částečném zmapování trhu s integračními nástroji.
Práce neměla za úkol vybrat ten nejlepší nástroj, spíše cílem bylo uvést jednotlivé možnosti
tak, aby uživatel byl schopen sám si daný produkt zhodnotit. U jednotlivých nástrojů jsme
zejména zaměřili na vazbu na modelování a CASE, což bylo i předpokladem. Dalším přínosem
může být i přiblížení architektury SOA, která se v dnešní době stále více prosazuje a je, dá se
říci, hlavní metodikou v oblasti integrace. SOA tedy hraje významnou roli v těchto nástrojích,
a tak jsme se zaměřili i na to, jak dané produkty architekturu podporují.
Společným prvkem pro všechny nástroje je jazyk BPEL, který slouží ke specifikování
chování business procesů. Integrace a vývoj informačních systémů je právě zaměřen zejména
na podnikové procesy. Samozřejmě každá z výše uvedených společností používá odlišné
standardy a také je jinak implementují ve svých nástrojích. Cílem tedy bylo vypíchnout a
zdůraznit tyto standardy.
Nástroje jsou často distribuovány v celých balících nebo, chcete-li, rodinách produktů,
příkladem může být rodina IBM Websphere nebo SAP NetWeaver. Tyto balíky poskytují
uživatelům komplexní řešení v oblasti integrace od analýzy stávajícího systému, vytvoření
modelu nového systému až po jeho implementaci a deployment.
Literatura
1. Štumpf, Jindřich. „Enterprise Service Bus“. Computerworld, číslo 17. 2006
2. Štumpf, Jindřich. „Podniková sběrnice služeb“. 2006. Progress Software. 1. květen
2008 <
http://www.progress.com/progress_software/worldwide_sites/cz/docs/soa/070913
g.pdf>
3. „SOA Maturity Model“. Progress Sonic. 1. květen 2008 <
http://www.sonicsoftware.com/solutions/service_oriented_architecture/soa_maturi
ty_model/>
4. Štumpf, Jindřich. „Kdy pro vás SOA není přínosem“. 18. březen 2008. SOA Blog. 1.
květen 2008 < http://soablogjst.blogspot.com/2007/03/kdy-pro-vs-nen-pro-vs-soapnosem.html >
5. „Web Services Business Process Execution Language Version 2.0“. 11. duben 2007.
OASIS Standard. 5. prosinec 2007
<http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.pdf>
6. Juric, Matjaz B. „A Hands-on Introduction to BPEL“. Oracle Technology Network. 5.
prosinec 2007
<http://www.oracle.com/technology/pub/articles/matjaz_bpel1.html>
7. Kenney L. Frank, Plummer Daryl C. „Magic Quadrant for Integrated SOA Governance
Technology Sets, 2007“ Gartner RAS Core Research. 31. prosinec 2007
8. Smart SOA. Od jednoduchého ke složitému. 19. prosinec 2007 <http://www306.ibm.com/software/cz/soa/launch/>
9. Service Component Architecture. 19. prosinec 2007
<http://www.osoa.org/display/Main/Service+Component+Architecture+Home>
10. WebSphere Business Modeler Advanced. 19. Prosinec 2007 <http://www306.ibm.com/software/integration/wbimodeler/advanced/features/?S_CMP=rnav>
11. WebSphere Business Monitor. 19. Prosinec 2007 <http://www306.ibm.com/software/integration/wbimonitor/>
12. WebSphere Integration Developer. 19. Prosinec 2007 <http://www306.ibm.com/software/integration/wid/about/?S_CMP=rnav>
13. BENONI D. et.al.: Integrační nástroje a jejich vazba ke CASE a modelování vůbec
[online] Jan 2008
<http://www.panrepa.org/CASE/zima2007/integrace_CASE_zima2007.pdf>
[9.5.2008]
14. SAP: SAP NetWeaver: Poskytuje pevný základ pro pružnější inovaci vašich procesů
[online] 2006 <http://www.sap.com/cz/platform/netweaver/index.epx> [9.5.2008]
15. IDS Scheer: ARIS for SAP NetWeaver [online] <http://www.idsscheer.cz/cz/Software/ARIS_Software/ARIS_for_SAP_Netweaver/34711.html>
[9.5.2008]
16. IDS Scheer: White Paper ARIS for SAP NetWeaver [online] Oct 2006 <http://www.idsscheer.cz/set/3849/ARIS_for_SAP_NetWeaver_WP_en_2006-10.pdf > [9.5.2008]