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
6. Juric, Matjaz B. „A Hands-on Introduction to BPEL“. Oracle Technology Network. 5. prosinec 2007 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 9. Service Component Architecture. 19. prosinec 2007 10. WebSphere Business Modeler Advanced. 19. Prosinec 2007 11. WebSphere Business Monitor. 19. Prosinec 2007 12. WebSphere Integration Developer. 19. Prosinec 2007 13. BENONI D. et.al.: Integrační nástroje a jejich vazba ke CASE a modelování vůbec [online] Jan 2008 [9.5.2008] 14. SAP: SAP NetWeaver: Poskytuje pevný základ pro pružnější inovaci vašich procesů [online] 2006 [9.5.2008] 15. IDS Scheer: ARIS for SAP NetWeaver [online] [9.5.2008] 16. IDS Scheer: White Paper ARIS for SAP NetWeaver [online] Oct 2006 [9.5.2008]
