Systémová integrace IS cestovní kanceláře pomocí MS BizTalk Server

Mendelova zemědělská a lesnická univerzita v Brně Provozně ekonomická fakulta

Systémová integrace IS cestovní kanceláře pomocí MS BizTalk Server Diplomová práce

Vedoucí práce: Ing. Petr Jedlička, Ph.D.

Josef Krejčíř

Brno 2009

Prohlašuji, že jsem diplomovou práci vypracoval samostatně s použitím literatury a zdrojů uvedených v seznamu.

V Brně dne 22. května 2009

....................................................

Za cenné rady, připomínky při vypracování této diplomové práce děkuji panu Ing. Petru Jedličkovi, Ph.D.

4

Abstract Krejčíř J. System integration IS of travel agency with MS BizTalk Server. Diploma thesis. Brno, 2009. This diploma thesis describes system integration possibilities for enterprise and service oriented companies, such as travel agency. This paper presents theory and principles analyzing and designing information systems and main integration methods. This work solve integration problem between travel agency and other business partners, such as companies, that are providing services from travel business are. Author use Microsoft BizTalk Server technology to implement this process, including data transformations, designing of data flow of business process and communications.

Abstrakt Krejčíř J. Systémová integrace IS cestovní kanceláře pomocí MS BizTalk Server. Diplomová práce. Brno, 2009. Tato diplomová práce popisuje možnosti systémové integrace pro podniky a společnosti poskytující služby, jako je cestovní kancelář. Práce prezentuje teorii a principy analýzy a návrhu informačních systémů a hlavní integrační metody. Práce řeší integrační problém mezi cestovní kanceláří a jejími obchodními partnery, společnostmi poskytující služby v oblasti cestovního ruchu. Autor v práci k implementaci procesů užívá technologii Microsoft BizTalk Server, zahrnující akce jako datové transformace, návrh datového toku obchodního procesu a komunikace.

5

OBSAH

Obsah 1 Úvod a cíl práce 1.1 Úvod do problematiky . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Cíl práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6 6 8

2 Přehled literatury

9

3 Definice pojmů 3.1 Informační systémy . . . . . . . . 3.2 Objektová analýza pomocí UML . 3.3 Systémová integrace . . . . . . . 3.4 Životní cyklus vývoje SW . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

4 Metodika 5 Analýza současného stavu 5.1 Představení společnosti . . . . . . 5.2 Organizační struktura . . . . . . 5.3 Analýza současného stavu . . . . 5.4 Objektová analýza pomocí UML .

10 10 13 16 22 25

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

27 27 28 29 31

6 Integrace pomocí Microsoft BizTalk Serveru 33 6.1 Použité technologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 6.2 MS BizTalk Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 7 Implementace systému

57

8 Nasazení a údržba systému

64

9 Trend do budoucna

67

10 Závěr

68

11 Literatura

69

Přílohy

71

A Ukázka designu orchestrace v BizTalku

72

B Ukázka mapování v BizTalku – TravelerInfo

73

C Ukázka mapování v BizTalku – Fulfillment

74

D Ukázka mapování v BizTalku – AirItinerary

75

1

ÚVOD A CÍL PRÁCE

1 1.1

6

Úvod a cíl práce Úvod do problematiky

V posledních několika letech došlo k velkým změnám ve sféře výroby, obchodu ale i správní oblasti. Tyto subjekty získávají velké množství informací, které je třeba nějakým způsobem zpracovat a uchovat. Díky zvýšené potřebě informací roste na významu nasazení informačních systémů. Převod původních informačních toků představovaných papírovými dokumenty, klasickou poštou a lidskou komunikací na computerizovaný informační systém je dnes podmínkou úspěchu na globalizovaných trzích, kde je vysoká konkurence. Toto je velmi náročné nejen finančně, ale i z hlediska lidských zdrojů. Většina firem zabývajících se tvorbou a customizací informačních systémů se stále potýká s nedostatkem kvalifikovaných pracovníků. Doposud si proto takové řešení mohli dovolit pouze velké podniky. S rozvojem internetu však výhody nasazení informačního systému poznali i menší a střední podniky či organizace. Na poli celosvětové počítačové sítě je obrovské množství možností jak zkvalitnit a zefektivnit nabídku podniků. Do popředí se dostává jev označovaný jako Long tail, kdy suma produktů nabízených malými firmami a poptávanými vždy úzkým okruhem zákazníků, může přesahovat velké množství nejčastějších produktů velkých firem. Tak se lze prosadit na trhu i s na první pohled bezvýznamným produktem. K tomu napomáhá především elektronický způsob prodeje, kdy je možné nabízet takřka neomezené množství produktů a služeb, přičemž jejich tvorba může začít až v okamžiku vytvoření objednávky. Trendem je rovněž zvýšení celkového množství prodejů se současným nutným snížením nákladů na jednotku prodané služby, či produktu. Je třeba prodávat služby, respektive produkty, které nejsou prakticky v naší nabídce, ale v případě vznesení požadavku klienta jsme schopni najít vhodného dodavatele a uskutečnit s ním transakci. S touto formou prodeje se lze setkat i u cestovních kanceláří, nabízejících forfaitové zájezdy, jejichž výsledná podoba je tvořena na základě přání klientů. Využití informačních a komunikačních technologií k zabezpečení chodu cestovní kanceláře je běžné nejen ve světě, ale i u nás a není již výsadou pouze největších hráčů na trhu. V současné době pozorujeme i v této oblasti zlepšující se uživatelské rozhraní a kvalitu aplikačního softwaru. Cestovní kanceláře využívají služeb výpočetní techniky k tvorbě zájezdů, rezervaci a objednávání, vedení účetnictví a komunikaci s úřady, obchodní korespondenci, propagaci a jako podporu při rozhodování vedení firmy. Toto lze spatřit u úspěšných cestovních kanceláří s uvědomělým vedením, které je vstřícné vůči zavádění inovací a moderních postupů. Stále se lze však setkat i s případy, kdy není činnost kanceláře téměř vůbec komputerizována a je odkázána na běžnou papírovou evidenci, popřípadě je nějaký typový aplikační software nasazen, ale není vhodně integrován a je spíše simultánním doplňkem ruční práce. Tato kombinace je snad úplně nejhorší, kdy jsou vynaloženy nemalé náklady na pořízení softwaru, ale kvůli nedostatečnému zaškolení obsluhy není nově nasazený informační systém vřele přivítán pracovníky a mnohdy lze i polemizovat nad zefektivněním produktivity

1.1

Úvod do problematiky

7

práce. Tomu lze předejít analýzou informačních toků ve firmě a volbou vhodného systému. Jednou z možností je využití systémové integrace stávajícího systému s webovými službami velkého poskytovatele služeb v oblasti cestovního ruchu.

1.2

1.2

Cíl práce

8

Cíl práce

Cílem práce je realizace integrace IS cestovní kanceláře s různorodými systémy obchodních partnerů. Jedním z dílčích cílů práce je vysvětlit základní pojmy z oblasti tvorby informačních systémů, jejich metody rozdělení a možné způsoby integrace IS. V další části bude zmíněn životní cyklus tvorby informačního systému. Jelikož součástí práce bude i implementace vybraných procesů, budou zmapovány nejdůležitější technologie tvorby integračních aplikací ve zvoleném integrační technologii. Součástí práce bude analýza cestovní kanceláře Travel 2002. Pro analýzu firmy je třeba představit společnost a zhodnotit aktuální stav. Po prozkoumání informačních toků v rámci firmy a jejího okolí je vhodné se pokusit u vybraných procesů nastínit možné inovace a vylepšení k zajištění efektivnějšího chodu kanceláře. Konkrétně se bude jednat o subsystém komunikace kanceláře s obchodními partnery, který není v současné době vhodně komputerizován a začleněn do IS firmy. Komunikace a výměna obchodních dokumentů probíhá zejména prostřednictvím emailu, což je velmi neefektivní a zároveň tento způsob komunikace nesplňuje základní atributy zabezpečení. Kancelář si potřebuje vyměňovat obchodní dokumenty s informačními systémy společností, které poskytují služby z oblasti cestovního ruchu. Tyto se zabývají vyhledáváním nejvhodnějších nabídek leteckých přepravců, autobusových dopravců, či agentur nabízejících ubytovací služby a objednáváním těchto služeb. Při své pracovní činnosti na projektu zabývající se systémovou integrací v softwarové společnosti jsem se setkal s komerčním produktem Microsoft Biztalk Server, stejně tak při svých osobních zájmových průzkumech v této oblasti i s nekomerčními alternativami jako jsou integrační technologie masstransit, camel, či servicemix. Tyto nejsou však pro profesionální integraci vhodné. Proto jsem zvolil technologii Microsoft BizTalk Server a podstatná část práce bude věnována problematice systémové integrace, elektronické výměně dokumentů pomocí normy EDI a jak tento integrační nástroj použít při inovaci subsystému komunikace s obchodními partnery cestovní kanceláře. Cestovní kancelář chce komunikovat s obchodním partnerem z oblasti poskytování služeb v cestovním ruchu, ale ten se nechce vzdát své dosavadní EDI komunikace. Ale zároveň obchodní partneři vyvíjejí určitý tlak na to, aby jim objednávky, faktury, vyúčtování, potvrzení a další b2b dokumenty chodili do jejich ERP systému přímo. Cílem je tedy realizovat vhodnou integrační aplikaci, která je schopna přetransformovat EDI zprávy a doručit je systému do ERP systému partnera, cestovní kanceláře. V závěru práce budou shrnuty dosažené výsledky.

2

2

PŘEHLED LITERATURY

9

Přehled literatury

Práce se zabývá tvorbou informačních systémů. Dobrým zdrojem zejména pro analýzu IS jsou skripta Projektování informačních systémů (Konečný, 1996). Pro objektovou analýzu jsem zvolil studium knihy Základy objektově orientovaného návrhu v UML (Page-Jones, 2001). Pro studium technik vývoje softwaru je zvolena publikace Agilní programování (Kadlec, 2004), zabývající se softwarovým inženýrstvím a metodikami vývoje. V části zabývající se systémovou integrací je řešená problematika, týkající se EDI, popsána v publikaci amerického autora The A to Z of EDI The comprehensive Guide to Electronic data interchange (Jilovec, 2006), kde autor popisuje smysl elektronické výměny dokumentů, prostředky, softwarové komponenty a normu EDI. Při realizaci samotné systémové integrace je problematika konkrétní zvolené technologie Microsoft BizTalk Server autor využívá výborné knihy Biztalk 2006 Recipes – A problem solution approach (Beckner, 2006), Pro EDI in BizTalk Server 2006 R2 Electronic Document Interchange Solutions (Beckner, 2007). V průběhu řešení práce budou jistě použity četné internetové zdroje, popřípadě další literatura, která bude citována v sekci literatura.

3

DEFINICE POJMŮ

3

10

Definice pojmů

Jelikož se celá práce zabývá informačními systémy a jejich integrací, je vhodné si definovat ze zkoumané oblasti některé pojmy. Nad otázkou, co je to informační systém, je třeba se zamyslet. V minulosti existovaly systémy s převážně ručním zpracováváním, které se podobaly dnešním informačním systémům, provozovaným pomocí výpočetní a komunikační techniky. Ve zkoumané problematice se často setkáváme s pojmem informace. V literatuře nalezneme mnoho definic, pro úplnost si jednu z nich, jak ji zajímavě definuje (Vodáček, 1997): informací rozumíme data, kterým jejich uživatel přisuzuje určitý význam a které uspokojují konkrétní objektivní informační potřebu svého příjemce. Nositelem informace jsou číselná data, text, obraz, případně další smyslové vjemy. Na rozdíl od dat (zvuků, obrázků apod.) nemůžeme informaci skladovat. Na druhé straně informace jako zdroj poznání jsou zdrojem obnovitelným, nevyčerpatelným. I když má informace nehmotný charekter, je vždy spojena s nějakým fyzickým pochodem, který ji nese. Pro naše účely považuji za nejvhodnější definici informačního systému uvedenou v (Molnár, Moderní metody řízení informačních systémů, 1992): Informační systém je soubor lidí, technických prostředků a metod(programů), zabezpečujících sběr, přenos, zpracování, uchování dat, za účelem prezentace informací pro potřeby uživatelů činných v systémech řízení. Úlohou informačního systému je sdělovat a poskytovat nejrůznější údaje a podklady k zefektivňování a usnadnění práce tak, aby byl kvalitní informační systém podporou co největšímu okruhu lidí. Podle toho, k jakému účelu se informační systémy využívají, lze tyto systémy dle Řepi V. (1999) seřadit do několika skupin:

3.1

Informační systémy

Transakční systémy TPS – Transaction Processing Systems jsou průkopníky klasických systémů pro dávkové zpracování, které měly částečně mechanizovat typické agendové úlohy, jako jsou fakturace, mzdy apod. K těmto systémům byla v minulosti přiřazena tzv. kategorie méně kvalifikovaných pracovníků, jejichž specializací bylo pouze zadávání vstupu do těchto systémů. Tuto situaci změnil progresivní nástup systémů on-line. U těchto transakčních systémů již musí být uživatelé vysoce kvalifikovaní pracovníci schopní soustavné práce a provádění odborných rozhodnutí korespondující s podnikovou strategií. Rychlý růst transakčních systémů měl i vývoj relačních databází, které se stali součástí systémů. Tímto způsobem je vytvořen integrující páteřní podnikový informační systém.

3.1


11

Systémy pro přímé řízení procesů Tento speciální typ transakčních systémů pracuje v online-realtime režimu (OLRT). Výhodou těchto systémů je prakticky minimální podíl vstupů a výstupů zpracovávaných prostřednictvím člověka. Základní jednotkou jsou numericky řízené stroje (NC), které jsou propojené s počítači a ty jim předávají potřebné instrukce NC programy. Tyto systémy snímají, kontrolují a plánují práci strojů a zařízení, řídí práci skladů zásob, výdej nářadí, manipulačního zařízení apod. Informační systémy pro řízení MIS – Management Information Systems jsou systémy určené pro vedené podniku. V nedávné minulosti se velmi pracně vytvářelo velké množství tištěných sestav, diagramů, detailních přehledů o hospodaření úseků, provozů a závodů. Uživatelé si v těchto tištěných sestavách vyhledávali pouze informace, které nezbytně potřebovali. V dnešní době se informace na papír tisknou v co nejmenší míře, protože jsou dobře dostupné v elektronické podobě a tisknou se jen výběrové adresní sestavy. Z transakčních systémů se vytváří pravidelné výstupy, které slouží pro potřeby MIS, provádějí tedy různá vyhodnocení, modelové agregace a aktuální výběry informací. Systémy pro podporu rozhodování DSS – Decission Support Systems mají provádět různé druhy analýzy dat a to bez náročného programování.Většinou se jedná o jednorázovou úlohu, která se jen minimálně opakuje a to ještě v proměnných podmínkách. Prakticky tyto systémy jsou výsledkem MIS a jsou doplněny propracovaným grafickým uživatelským rozhraním se sofistikovanými funkcemi. DSS jsou vhodné k podpoře taktického řízení, mohou však podporovat i strategické řízení. Útvarové systémy DS – Department Systems jsou součástí TPS a DSS a systémů pro zpracování dokumentů. Jejich rozsah je omezen na určité místo nebo útvar. Vhodné využití může být například ve zdravotnictví (laboratorní systém v nemocnicích). Charakter dat a jejich zpracování je v podstatě odlišný od ostatních dat a transakcí v podnikové sféře. Expertní systémy Tyto systémy jsou založeny na funkci jasných pravidel, která pomáhají nepříliš znalým a zkušeným pracovníkům řešit náročné úkoly často diagnostického charakteru. Hlavním cílem je poskytovat odborné znalosti, kterými disponuje jen několik velice zkušených pravovníků v podniku dalším spolupracovníkům. Znalosti jsou uloženy jako soubory pravidel oddělení v tzv. bázi znalostí. Je to soustava podmínek ve tvaru IF-THEN, které se postupně vyhodnocují v průběhu konzultací s uživatelem.

3.1


12

Systémy pro vrcholové řízení EIS – Executive Information System – slouží převážně vrcholovému vedení podniku a to především tím, že poskytuje informace z okolí podniku (odbyt, konkurence, banka apod.). Tyto systémy se vyznačují velikou mírou intuitivního ovládání a uživatelské přizpůsobivosti uživatelského ovládání. Strategické informační systémy – SIS Hlavním úkolem těchto aplikací je zvýšení konkurenceschopnosti podniku. Působí v oblasti okolí podniku a to převážně tržního prostředí. Jejich účinek musí být razantní, tzn. musí výrazně zvýšit produktivitu práce, zvýšit efektivnost podniku. SIS tedy nejsou podporou systémů řízení, ale jsou přímo spojeny s výrobou nebo službou a zásadně mění způsob organizace práce a organizace řízení podniku, popřípadě výrazně ovlivňuje tržní prostředí. Jednou z možností například v průmyslové oblasti může být zavedení automatických linek, zřízení elektronické výměny dokumentů mezi dodavatelem a odběretelem pomocí EDI v obchodní oblasti, v bankovním sektoru např. zavedením bankovních automatů.

3.2

Objektová analýza pomocí UML

3.2

13


UML V počátcích UML, stáli významní analytici (Grady Booch, James Rumbaugh, Ivar Jacobson), kteří stáli za zrodem již dosud používaných metod, které využili pro vytvoření úplné množiny nástrojů a prostředků nazývané UML (Unified Modelink Langage). V současné době je UML, sjednocujícím komunikačním nástrojem, jenž obsahuje diagramy, které dovolují modelování statiky i dynamiky systému. Nemluví se přímo o metodě, ale o množině nástrojů. Již nyní existují a také vznikají metody, které mají UML jako svou součást. Je vidět také možné snahy o zjednodušení diagramů, a to na vrub jednoduchosti. Jsou stále přijímány nejrůznější znalosti objektového modelování. Počátek objektového modelování lze zařadit (Page-Jones, 2001) do druhé poloviny osmdesátých let, kdy se prosazoval kromě objektového programování i kompletní objektový přístup v oblasti modelování IS. A v té době již začaly vznikat nejrůznější metody, kterých se do dnešní doby zrodilo velké množství. Některé z těchto se prosadily i v komerční sféře, část je využívána pouze svými tvůrci. Objektové modelování zaznamenalo pro okruh informačních technologií velký zlom. Tento způsob náhledu se diametrálně lišil od užívaného strukturovaného modelování. Úvaha analytiků strukturovaného modelování bylo částečně deformované od přirozeného náhledu na problém – systém. Celková představa o systému se prováděla na data používaná v systému a funkce, které je zpracovávají. Ve strukturovaném světě tedy neexistuje nic jiného než data a funkce. Když se podíváme na reálný svět, poznáme, že je tvořen objekty. Z toho plyne, že strukturovaná analýza vyžadovala z pohledu objektového modelování jeden zbytečný krok, kterým bylo převést objekty reálného světa na data a funkce. Tato transformace na data a funkce, ukazuje vybočení od přirozeného myšlení, které je objektové, abychom si to skutečně uvědomovali. Jak je možné charakterizovat objektové modelování? Především v jasně definované zkoumané oblasti (systému) najít správné objekty, popsat je a nalézt vzájemné vazby mezi objekty. Objekty a jazyk UML Hlavní podmínkou jazyka UML je dle (Arlow, 2007) předpoklad, že dovoluje modelování softwaru, či jiných systémů jako soubor spolupracujících objektů. Jakkoli je tato idea aplikována na modelu objektově orientovaných softwarových systémů, pracuje naprosto spolehlivě i na poli obchodních a podnikatelských procesů a jiných aplikacích. Nyní si představíme důležité vlastnosti objektů. Zapouzdření Zapouzdření (encapsulation) je seskupení souvisejících idejí do jedné jednotky, na kterou se lze následně odkazovat jediným názvem. Na zapouzdřenou jednotku se

3.2


14

můžeme dívat zvnějšku nebo zvnitřku. Výhodou dobrého zapouzdření je odstranění z veřejného pohledu mnoha podrobností,které lze sledovat v soukromém pohledu.Toto potlačení nabývá dvou forem: skrývání informací a skrývání implementací. Termín skrývání informací znamená, že informace v jednotce nelze postřehnout mimo tuto jednotku. Termín skrývání implementace znamená, že podrobnosti implementace v dané jednotce nelze postřehnout zvnějška. Skrývání informací a implementací Skrývání informací a implementací (information/implementation hiding) je využití zapouzdření k omezení externí viditelnosti určitých informací nebo implementačních rozhodnutí, která jsou pro strukturu zapouzdření interní. Identita objektu První vlastností práce s objekty, která překračuje koncepci ADT, je vlastnost klíčová. Každý objekt má svou vlastní identitu. Identita objektu (object identity) je vlastnost, podle které je možno každý objekt (bez ohledu na jeho třídu nebo aktuální stav) identifikovat a pracovat s ním jako se samostatnou softwarovou entitou. Zprávy Objekt požaduje od jiného objektu vykonání nějaké činnosti prostřednictvím zprávy. Mnoho zpráv také přenáší informace od jednoho objektu k druhému. Většina profesionálů považuje zprávy za nejdůležitější vlastnost práce s objekty. Zpráva je dopravní prostředek, aby objekt použil jednu ze svých metod. Třídy Třída je šablona, podle které se vytvářejí objekty (jejich instance). Každý objekt má stejnou strukturu a chování jako třída, jejichž je instancí. Patří-li objekt do třídy, pak říkáme, že je jeho instancí. Dědičnost Třídy mohou tvořit hierarchie (nebo správněji mřížky) dědičnosti s nadřízenými a podřízenými třídami.Dědičnost umožňuje objektům jedné třídy používat prvky její libovolné nadřízené třídy. Operace třídy lze selektivně předefinovávat (přepisovat) v podřízených třídách. Mnohotvarost Slovo polymorfizmus pochází ze dvou řeckých slov značících (mnoho a tvar). Něco polymorfního tedy může nabývat mnoho tvarů. Knihy o objektově orientovaném programování obsahují dvě definice mnohotvarosti. Mnohotvarost (polymorphism)

3.2


15

je prostředek,jehož pomocí může být jediný název operace nebo atributu definovat na základě více než jedné třídy a může nabývat různých implementací v každé z těchto tříd.Mnohotvarost je vlastnost, jejímž prostřednictvím může atribut nebo proměnná ukazovat (obsahovat identifikátor) na objekty různých tříd v různých okamžicích. Obecnost Obecnost (genericita) je taková konstrukce třídy, která umožňuje dodání jedné nebo více interně používaných tříd až za běhu aplikace (v okamžiku, kdy je vytvořena instance objektu třídy).

3.3

3.3

Systémová integrace

16


Systémová integrace je mladou disciplínou softwarového inženýrství. Vznikla jako reakce na aktuální problémy praxe. Podle Konečného je systémová integrace je proces tvorby integrovaného informačního systému, tj. proces cílevědomého propojení (v souladu s informační strategií podniku) všech komponent HW, SW, podnikových procesů a prostředí do fungujícího systému. Hlavní příčiny vzniku systémové integrace lze rozdělit do tří skupin (Konečný V., 2008): • rostoucí význam informací (vnitřních i z okolí) pro prosperitu podniku a s tím související masové nasazování informačních technologií, • rychlý vývoj informačních technologií (HW i SW), • vysoké nároky na kvalifikaci a praktické zkušenosti pracovníků vyvíjejících a provozujících IS a informační technologie. Jak dokazuje Konečný (2008, s. 14), aby se informační systém mohl projevit jako strategický faktor prosperity podniku, měl by splňovat následující požadavky: • Musí podporovat strategické cíle podniku. Nelze přijmout situaci, kdy strategickým cílem je rozšíření odbytu zatímco strategie informačního systému je prioritně zaměřena na řešení problémů např. z oblasti personální evidence. • Musí fungovat jako otevřený systém pochopitelný jak řešitelům, tak uživatelům. • Vedením podniku musí být chápán jako jedno z hlavních jmění podniku a nesmí být odtrženo od jeho budování a využívání. Význam integrace Důvody pro integraci podnikových aplikací jsou z velké míry determinovány ekonomickými faktory, podpořeny snahou o snižování nákladů v oblasti IT. Dle (Juřek, 2004) se jedná o tyto faktory: • Snaha o zachování investic – vychází z potřeby zachovat již existující aplikace, které mohou být i heterogenní a využít prostředků, které již byly vybudovány. • Úspora lidských zdrojů – nejednotné systémy skládající se z velkého počtu samostatných aplikací jsou náročné na obsluhu a zaškolení, stejně se snižuje množství chyb, produkovaných uživateli při běžné obsluze systému. • Kontrola nákladů – centralizace výpočetní techniky, veškerého vybavení a softwaru přináší značné úspory a lepší kontrolu nad smysluplností vynaložených prostředků, tento proces i umožňuje využít outsourcing u činností, které jsou pro firmu příliš složité, či neefektivní. • Požadavek rychlé implementace obchodních procesů – vysoký konkureční tlak a dynamicky se měnící legislativní rámec ve firemním či státním prostředí vyžaduje rychlé nasazování nových procesů a metodik do praxe. Pokud jsou aplikace vhodně integrovány, jsou inovace v této oblasti mnohem snazší. • Nutnost flexibilně reagovat na měnící se vnější podmínky – jedná se o změny tržního charakteru, ekonomických činitelů, politické změny a řada dalších. Je

3.3


17

zřejmé, že dobře integrovaný systém je schopen změny efektivně reflektovat a kontinuálně řešit. Pro naplnění těchto snah je třeba při procesu systémové integrace dodržovat určité principy, tak jak je v liteřatuře dokázáno (Konečný, 2008). Mezi základní patří princip komplexnosti, tzn. že IS musí být řešen jako komlexní systém, musí pokrývat všechny vnitropodnikové procesy a skládat se z řady různých komponent, ať už hardwarových, tak softwarových (základního, či aplikačního SW). Dále dodržujeme princip standardizace, při realizace dodržujeme mezinárodní normy a standardy a tím zaručujeme nezávislost a přenositelnost. IS by měl být rovněž vyvíjen na základě jednotné koncepce, někdy používáme pojem informační strategie, tzn. dodržování unifikované metodiky v souladu s hlavními cíly podniku, vedoucí k snadné modernizaci systému. Posledním pravidlem je disciplinovanost a k jeho naplnění dostačuje při tvorbě a provozu systému dodržovat stanovená pravidla (v provozním řádu) a to všemi uživateli systému. Integrace na datové úrovni Existuje specifický způsob integrace, který nebere ohled na existenci aplikací. Předpokladem je, že tyto aplikace fungují standartním způsobem, využívají relační databázi a obcházení aplikace a využití přímo datových zdrojů je velmi zajímavá myšlenka. Za tímto účelem lze s výhodou použít ETL procesy pro extrakci dat, replikace databází, import/export apod. Problém je však, pokud je užito více datových zdrojů se složitější strukturou tabulek, což je zpravidla vždy. Problémem může být i při nutnosti verzování pokaždé měnit schéma databáze, což je poměrně nekoncepční. Toto rešení se hodí zejména na systémy s velkým objemem dat, popřípadě duplicitním uložením dat a jednoduchou strukturou. Podmínkou je absence real-time zpracování a snížený požadavek na aktuálnost dat.

Obr. 1: Schéma integrace na úrovni uživatelského rozhraní, převzato (Juřek, 2004)

3.3


18

Integrace na úrovni uživatelského rozhraní Zde se jedná o naprosto opačný případ. Integrace by se dala popsat jako propojení uživatelských terminálů, či GUI. Prakticky se jedná o simulaci uživatele, který osbluhuje aplikaci a to automatizovaně. Tento postup je vhodný zejména u starších aplikací, ke kterým již nemáme k dispozici zdrojový kód, popřípadě již neexistuje výrobce aplikace. V tomto případě je to jediný možný způsob integrace aplikace a jak se vyhnout nákladnému ručnímu zadávání dat, nebo pouhé obsluze uživatelem. Lze se, zařadit i integraci aplikací ve webových portálech, kde však jde spíše o sjednocení uživatelského ovládání než o výměnu dat.

Obr. 2: Schéma integrace na úrovni uživatelského rozhraní, převzato (Juřek, 2004)

Integrace na úrovni obchodní logiky Tento způsob integrace spočívá ve vzájemném volání mezi objekty ve střední vrstvě aplikací. Jedná se vlastně o propojování aplikací navzájem. Zpočátku se můžeme domnívat, že tento způsob integrace je poměrně jednoduchý a systematický, jeho praktická realizace je však ztížena následujícími faktory: • přímý zásah do aplikace a s tím spojená složitá analýza kódu a dokumentace, popřípadě komunikace s dodavatelem • závislost integrovaných aplikací, způsobuje obtížnou dostupnost jednotlivých funkcí a jejich aktualizaci • syndrom N2 způsobuje problém, že přidání každé další integrující aplikace rozšiřuje počet možných vazeb mezi aplikacemi kvadraticky a tím dochází k stále větší pracnosti a náročnosti implementace • heterogenita souvisí s faktem, že doposud žádná technologie se nerošířila většinově, ale na trhu existuje několik paralerních samostatných technologíí způsobujících vzájemnou nekompatibilitu a následně dodatečné náklady na přemostění architektur, či konverze mezi technologiemi. Všechny způsoby integrace aplikací, které byly v předchozím textu změněny, vyžadují interní komponenty i každé aplikace, a to zejména na datové úrovni. Díky tomuto se stávají aplikace značně komplikované a této těsné vazbě se říká tight

3.3


19

Obr. 3: Schéma integrace na obchodní logiky, převzato (Juřek, 2004)

coupling . Moderní integrační koncepce se snaží o opačný přístup. Preferuje tak zvanou volnou vazbu (loose coupling), jejímž předpokladem je co nejmenší množství informací, které si aplikace mezi sebou sdílí. Tím lze zamezit odkrývání implementačních detailů jednotlivých aplikací. Tento přístup je znám pod pojmem architektura orientovaná na služby (Service Oriented Architecture, SOA). Tato architektura byla již použita firmou IBM při implementaci produktu MQSeries. S rozšířením XML a webových služeb došlo k znovu využití SOA.

3.3


20

Koncept SOA Koncept tohoto způsobu integrace je zobrazen na následujícím obrázku. Celá ar-

Obr. 4: Schéma integrace založené na službách, převzato (Juřek, 2004)

chitektura využívá určité rozhraní pro zpřístupnění služby, které používá specifický druh nadstavby nad obchodní logikou. Nevylučuje se však možnost použít servisní vrstvu přímo nad databází nebo lze využít pouze uživatelské rozhraní. Služba Služba (service) je dle (Juřek, 2004) součást programu, která implementuje logiku prostřednictvím kódu, spravuje svůj stav a komunikuje pomocí zpráv. Je řízena politikou a musí být dostupná po síti. Službou může být například zadání faktury do ERP systému popřípadě aktualizace dat v CRM systému, atd. Stav Důvodem proč existují služby stavů (state). Ty lze chápat jako informace které jsou základem všech aplikací. Pro ERP může být stavem list všech přijatých a vydaných faktur pohledávky, závazky, účetní kniha atd. Stav je aktualizován prostřednictvím interní logiky. Je nutné udržovat stav v konzistentním tvaru, a to prostřednictvím tzv. transakcí. Tyto musí být trvalé,odolné vůči nedeterminovatelných okolnostem jako může být např. výpadek proudu elektrického napětí. Úkolem služby je zpřístupnit části svého stavu externím subjektům popřípadě je pozměnit na základě požadavků, které přicházejí z vnějšího prostředí . Stav má interní přístup ke zdrojům informací a data která jsou přístupná mimo hranice systému jsou, považovaná pouze za jejich replikaci a nepracujeme jako s aktuálními údaji. Toto je velmi důležité a je třeba tento poznatek mít vždy na mysli. Zpráva Služby komunikují pomocí zpráv, což je nejdůležitější součástí integrace. Služba jako taková je prakticky definována pomocí zpráv, které přijímá nebo odesílá. Obsahem

3.3


21

zprávy musí být zcela jasný a standardní formát, který je předem definovaný a musí splňovat domluvené konvence. V dnešní době se nejčastěji používá standard XML a XSD, popřípadě EDI.

3.4

3.4

Životní cyklus vývoje SW

22


Práce se zabývá návrhem a vývojem softwarové integrace, který musí mít určitou formu, strukturu a využívat jednotnou koncepci. V oblasti integrace B2B aplikací se s výhodou využíva tradiční vodopádový model životního cyklu. Vodopádový model životního cyklu Hned na úvod je nutné poznamenat, že vodopádový model není metodikou vývoje softwaru. Vodopádový model je modelem životního cyklu vývoje softwarového produktu. A v tomto smyslu projekt implementovaný v prostředí MS BizTalk Server softwarovým produktem je. Vodopádový model existuje již od roku 1970 a je už v dnešní době poněkud zastaralý a je používán stále méně především proto, že pro rozsáhlé projekty je relativně nevhodný. Nicméně v prostředí tvorby projektů BizTalk je tento model dostačující. V době svého vzniku představoval vodopádový model naprostý převrat, revoluci v pohledu na vývoj softwaru. Tento model je dle (Kadlec, 2004) definován jako model procesu vývoje softwaru, v němž definice problému, specifikace požadavků, návrh a architektura, implementace, testování a provoz, jsou prováděny ve stanoveném pořadí s žádnými nebo minimálními iteracemi. Charakteristickým znakem je sekvenčnost jednotlivých fází, po skončení každé fáze je zahájena následující fáze; není možné aplikovat více fází najednou. Dále je charakterizován striktní posloupností kroků a fází. Nepředepisuje žádné iterace ani průběžné komunikace se zákazníkem. Vodopádový model je významným softwarověinženýrským mezníkem. Posloupnost kroků a fází je zobrazen na následujícím obrázku. Vodopádový model se skládá z následujících základních fází: 1. Definice problému 2. Analýza a specifikace požadavků 3. Návrh systému 4. Implementace systému 5. Testování 6. Integrace a testování systému 7. Provoz a údržba V modelu lze postupovat pouze po jednotlivých fázích. V první šesti fázích si vývojový tým ve spolupráci se zákazníkem vytváří návrh, implementaci a testové případy. Okruh těchto šesti fází se může pohybovat vždy o jednu fázi. Pokud ve fázi implementace zjistíme, že v návrhu je chyba, je možné se vrátit o jednu fázi zpět a provést potřebné úpravy. Po provedení nezbytných korekcí musí projít beze zbytku inovované dokumenty znovu schvalovacím procesem. Teprve když je produkt kompletní a řádně otestovaný, předáme ho zákazníkovi. Důležité však je, že v poslední fázi provozu a údržby se můžeme vrátit do kterékoliv z předchozích fází a uskutečňovat jakékoliv úpravy. Velkou nevýhodou je, že práce na dané etapě ve vodopádovém mohou začít až tehdy, pokud je předcházející etapa ukončená a veškeré její výstupy a produkty jsou zdokumentované a odsouhlasené.

3.4


23

Obr. 5: Struktura vodopádového modelu životního cyklu, převzato (Kadlec, 2004)

Fáze definice problému Ve fázi definice problému je prvořadým úkolem záměr zákazníka. Cílem je navštívit zákazníka a snažit se pochopit, v čem mu systém zjednoduší práci. Předmětem tohoto jednání je rovněž vysvětlit zákazníkovi, jak B2B integrace funguje, jaké zahrnuje různé kroky, role a působnosti. Důležité je rovněž zjistit přesné zaměření projektu a jeho rozsah. Výstupem této úvodní fáze je obvykle dokument Úvodní studie. Součástí úvodní studie je i hrubý popis nároků požadovaných na systém, nejde však specifikaci. Analýza a specifikace požadavků Úkolem je podrobně prozkoumat, co přesně a systematicky by měl systém dělat.Popis požadavků by měl být zpracován exaktně, pomocí přesných termínů, taktéž ověřitelných formulací a vyčíslitelných charakteristik. Výsledkem analýzy je dokument Specifikace požadavků. Na tento dokument jsou kladeny vysoké nároky, především na jeho strukturu, formu, obsah i způsob vyjádření.Dokonce existuje několik standardů pro psaní specifikací požadavků (např. standard IEEE 830-1998). Fáze návrhu a vytváření architektury V prvé fázi je prvořadým úkolem projít specifikaci požadavků a na jejím základě navrhnout takovou architekturu systému, která bude nejhodnější pro daný projekt. Architekturou je například představa rozdělení aplikace do modulů, do vrstev, ale

3.4


24

taktéž zvolit nejvhodnější technologii a vývojové prostředí. Výstupem fáze návrhu je kompletní architektura systému, tedy rozbor a popis modulů a jejich významu, stanovení způsobu komunikace mezi moduly, rozbor dělení systému na podprogramy, popis získávání a uchování dat (formáty vstupních a výstupních souborů), definitivní stanovení technologii. Fáze implementace systému Ve fázi implementace stojí před vývojovým týmem naprogramování aplikace tak, aby zákazník byl plně spokojen. Z hlediska metodik je zcela podřadné, jaký programovací jazyk/vývojový nástroj je k implementaci použit. Takováto rozhodnutí jsou převážně v kompetenci vývojového týmu a většina metodik v tomto směru nepřináší velká omezení. Pro vývoj aplikací v BizTalk Severu se užívá integrované vývojové prostředí Microsoft Visual Studio, do něhož se BizTalk doinstalovává jako balíček. Vývoj zahrnuje tvorbu transformačních map, schémat, datových kanálů a transformací atd. Fáze integrace a testování systému Fáze testování by měla zajistit, aby aplikace fungovala bezchybně a aby vytvářela to, co od ní zákazník požaduje. Tato fáze zahrnuje otestování všech fází vývoje v závislosti na integračním implementačním procesu. Technologická stránka z praktického hlediska bude dále rozebrána v kapitole Nasazení a údržba systému. Fáze provozu a údržby Finální projekt je provozován v produkčním prostředí a zahrnuje monitoring procesů a kontrolu statusu doručení u dokumentů, kontrolu chodu serveru a deployement aktualizací kódů projektu. Monitoring je vykonáván hlavně z toho důvodu, že obchodní partneři často vyžadují doručení určitých typů dokumentů ve specifikovaném čase. Pokud tento časový interval není dodržen, ať už z technických důvodů, nebo kvůli nevalidním datům, mohou zde nastat silně negativní dopady na obchodní procesy. Proto musí být dohled nad chodem serveru periodicky naplánován. Výhody a silné stránky Vodopádový model je ideální pro řízení. Z hlediska vedení firmy (projektu, týmu) jsou jasně dány všechny dokumenty a výstupy, všechny produkty a relativně snadno lze stanovit rámcový harmonogram. Vodopádný model vnáší do procesu vývoje disciplínu: vývoj postupuje systematicky od jedné fáze k další. Tento model požaduje, aby po ukončení každé fáze byla dodána její úplná dokumentace.

4

4

METODIKA

25

Metodika

Tato práce řeší potřebu integrace IS cestovní kanceláře Travel 2002 s informačními systémy obchodních partnerů, poskytovateli služeb z oblasti cestovního ruchu. V úvodu samotná práce uvede autor do problematiky seznámení s pojmy z oblasti návrhu a tvorby informačních systémů, a zejména jejich systémové integrace. Analýza současného stavu bude vypracována objektovým způsobem. Význam objektového způsobu návrhu spatřuji v obrovském potenciálu modelovacího jazyka UML. Nejedná se totiž pouze o množinu symbolů, schopných graficky reprezentovat navrhovaný systém, ale lze jím kompletně obsáhnout aplikační logiku. Existují totiž integrovaná vývojová prostředí pro různé objektově orientované jazyky, schopné provádět návrh aplikace graficky pomocí UML a okamžitě generovat zdrojový kód, který je samozřejmě neúplný. A naopak editace zdrojového kódu se okamžitě projeví v návrhovém modelu. Tento způsob agilního vývoje aplikací je tedy velmi efektivní. Autor zvolí vhodné diagramy pro deskriptivní popis aktuální situace. V hodnocení současného stavu budou zmapovány informace, které prostřednictvím IS firma získává nebo poskytuje. Budou členěny z hlediska obsahu, formy (tištěná/elektronická) a periodicity získávání. Součástí bude představení firmy reprezentované základními údaji a oborem činnosti, včetně organizační struktury. Objektová analýza informačních toků v CK bude zahrnovat proces inovace subystému komunikace s obchodními partnery pomocí systémové integrace. Budou zvoleny diagramy BPM – Business Process Modeling pro vyjádření současného stavu spolu se slovním popisem a dále use case diagram s všemi aktuálními firemními procesy a návrhem další inovace procesu komunikace s obchodními partnery. Hlubší analýza bude provedena až v rámci samotné práce, využitím konkrétní technolie BizTalk, který obsahuje výkonný nástroj pro business management operace založený na XLANG, který spadá do kategorie standardů BPEL. V samotné vlastní práci – Integraci pomocí BizTalk Serveru – budou popsány použité technologie. V úvodu bude zmíněna technologie z obchodního a technického hlediska, kde cílem bude představit možnosti vytváření a výměny obchodních informací pomocí struktur XML. Práce bude obsahovat analýzu možností komerčního vývojového nástroje Microsoft BizTalk Server, který je určený k integraci skupiny i heterogenních aplikací a prostředí v jeden funkční celek. Tento systém umožňuje promptně vyvinout rozhraní, které je schopno propojit různé komunikující systémy bez nutnosti naprogramování specifického interface na míru. Tento systém používá pro všechny datové přenosy kód jazyka XML. Přijímá a vytváří také další formáty, z nichž je pravděpodobně nejpozoruhodnější rozhraní EDI (Electronic Data Interchange). Všechny tyto technologie budou v práci podrobně popsány a zmapovány pro užití v prostředí integrace konkrétní cestovní kanceláře. Podstatou integrace bude implementace procesu odeslání požadavku na dostupnost letů a rezervačního požadavku. Tyto zprávy budou splňovat XML standard Open Travel Alliance, které budou proudit z a do cestovní kanceláře, která bude využívat služeb společností Sabre a Amadeus, které vyhledávají, objednávají

4

METODIKA

26

služby leteckých a cestovních společností. Největší část integrace bude provedena na straně společnosti Amadeus, přičemž tyto integrační služby jsou řešeny formou outsourcingu. Společnost Amadeus si přeje automatizovat proces objednávání letenek, ale disponuje staršími EDI technologiemi, které budou naším integračním řešením vhodně zakomponovány tak, aby byla schopna vyhovět standardům XML OTA. Toto bude dosaženo transformacemi dat v BizTalku, návrhem obchodního procesu pomocí orchestrace a zajištěním asynchronní komunikace.

5

ANALÝZA SOUČASNÉHO STAVU

5 5.1

27

Analýza současného stavu Představení společnosti

Cestovní kancelář Travel 2002 byla založena v roce 1992, jako právní forma byla vybrána společnost s ručením omezeným. Firma v tuto chvíli zaměstnává cca 17 zaměstnanců. V období sezóny, tj. červen až srpen se počet zaměstnanců rozšiřuje většinou o 3 brigádníky. Pracovní doba je pondělí až pátek od 9,00 do 18,00 hodin. Cestovní kancelář sídlí v Brně a má pobočku ve Strážnici. Předmětem činnosti je provozování cestovní kanceláře a s tím spojené poskytování zájezdů po ČR a do zahraničí. Cestovní kancelář poskytuje svým klientům nejen individuální pobyty, ale také nabízí hromadné zájezdy, odborné kurzy, školení a jiné vzdělávací akce, určené především pro školy a mládežnická zařízení, zaměstnanecké kolektivy a další. Mimo jiné provádí průvodcovskou činnost. Svým portfoliem služeb usiluje vyjít vstříc co nejpočetnějšímu okruhu zákazníků. Z tohoto důvodu i tato cestovní kancelář využívá dnes již obvyklý systém provizního zprostředkovatelského prodeje, který je realizován na základě uzavření smlouvy s ostatními cestovními kancelářemi či cestovními agenturami. Cestovní kancelář má oproti agentuře ze zákona výhodu, že může nabízet vlastní zájezdy delší než 1 den. V případě prodeje zájezdu u smluvního prodejce, odvádí cestovní kancelář část zisku zprostředkovateli jako provizi. Jelikož je v dnešní době na trhu cestovních kanceláří nepřeberné množství, chce CK Travel 2002 zaujmout potencionální zákazníky nízkými cenami zájezdů a odpovídající nabídkou doplňkových služeb. Ve své nabídce zájezdů má často navštěvované destinace jako jsou Bulharsko, Turecko, Řecko, Španělsko a Chorvatsko. V zimních měsících se společnost orientuje na destinace zejména z alpských zemí, jako jsou Rakousko, Itálie, Francie, Švýcarsko. Za stěžejní činnosti cestovní kanceláře Travel 2002 považujeme: 1. Obchodní činnost – jedná se zejména o přímý prodej vlastních zájezdů v sídle v Brně a na pobočce ve Strážnici. 2. Kooperace s obchodními partnery – na základě sjednaných smluv s partnerskými CK nabízí jejich zájezdy svým klientům, či naopak nabízí svá volná místa partnerským kancelářím a agenturám. 3. Účetnictví – zahrnuje finanční a manažerské účetnictví spojené se zhodnocením efektivnosti provozu CK, její rentability a eventuelně výhledu do budoucna. Patří sem veškeré zabezpečení personálního charakteru zaměstnanců (mzdy, sociální a zdravotní pojištění), tak i evidence doplňkových služeb klientů jako je cestovní a úrazové pojištění, bezhotovostní platby, vyřízení víz apod.

5.2

5.2

Organizační struktura

28

Organizační struktura

Na následujícím obrázku si prezentujeme organizační strukturu cestovní kanceláře.

Obr. 6: Organizační struktura cestovní kanceláře

5.3

5.3

Analýza současného stavu

29


V tuto chvíli využívá cestovní kancelář komerční mySAP s Travel Agent adaptérem. Jedná se o dvouvrstvou aplikaci, skládající se ze serveru a klienta, který běží na koncových stanicích, připojených k serveru přes síť Internet. Tak jsou připojeny i klientské stanice v Strážnici. Počítače připojeny k síti internet rovněž za účelem realizace elektronické pošty a zpracování interních marketingových analýz nabídky konkurenčních cestovních kanceláří, které prezentují svoji aktuální nabídku ve formě dynamické webové prezentace. Komunikace sídla cestovní kanceláře se svou pobočkou a provizními partnery, jejichž celkový počet se blíží hodnotě 150, je realizována především prostřednictvím IS Prodis, dále operativně telefonicky, elektronickou poštou a faxem. Tento informační systém je určen pro několik skupin uživatelů. Na prvním místě je to osoba alespoň s minimálním IT vzděláním schopná provádět úkony v roli správce systému, webmastera a správce DB. Výstupní informace systému jsou určeny jednak pro zaměstnance, tak i pro majitele firmy a účetní oddělení (ekonomické výkazy a statistiky). Podle charakteru dat rozlišujeme 3 úrovně přístupu k datům: • Informace zpřístupněné zaměstnancům CK a provizním partnerům prostřednictvím intranetu • Online informace o nabízených zájezdech pro širokou veřejnost přístupné přes WWW • Tištěné papírové katalogy (vydávané každoročně, zpracované externí firmou a distribuované stálým klientům, na prodejní místa a provizním partnerům) Z hlediska orientace informací které systém cestovní kanceláře ovlivňují a nebo vyvolávají reakci, rozlišujeme vstupy a výstupy systému, které lze podrobněji klasifikovat, pro jaký účel jsou využity a kým jsou zpracovávány. Vstupy • Informace o destinacích – geografické, historické a politické údaje, podnebí, klima, průměrné teploty – pravidelně v časových intervalech několikrát do roka – tištěná média (cestovatelská periodika, průvodci, atd.), internet, údaje obchodních partnerů • Údaje o klientech – osobní a kontaktní údaje – získání vyplněním papírového formuláře, registrací na webu, zadání pracovníkem CK do IS, popř. nahlášení telefonicky, faxem obchodním partnerem • Informace obchodních partnerů – ceny za nabízené služby, volná kapacita služeb – jednou ročně při tvorbě katalogů – získání dat telefonicky, emailem, poštou, faxem, WWW • Informace o konkurenci

5.3


30

– stejný rozsah jako u obchodních partnerů – navíc statistické ročenky, dotazování, marketingový výzkum • Informace o trhu – nejdůležitější ekonomické ukazatele jako je výše inflace, cenová hladina – průběžně, i několikrát za měsíc – internet, statistické ročenky • Výsledky prováděných průzkumů – statistická analýza klientských požadavků – periodicita náhodně (záleží na rozhodnutí vedení firmy) – zdrojem jsou ankety, webové formuláře, návratové dotazníky, telefonický průzkum, osobní kontakt na obchodním místě, či marketingové prezentaci Výstupy • Rozsah nabízených služeb a cen – informace o zájezdech, alternativách dopravy, ubytování a doplňkových službách a jejich cenách – publikovány ve formě internetového a tištěného katalogu – aktualizace několikrát ročně, rozsah tisku katalogu závisí na výsledku marketingového odhadu potenciálního okruhu klientů • Informace poskytované obchodním partnerům – provizní podmínky, podíl ze zisku, stanovení formy spolupráce, plnění, odhadnutí počtu míst – telefonicky, emailem, poštou, faxem, WWW – vždy aktuální, dle smluvních podmínek a počtu kontraktů • Doplňkové služby – vyřízení víz, pojištění, doprovodný program – vydávání propagačních materiálů (brožurky, vizitky, booklety atd.) • Materiály v tištěné podobě – export průvodce, mapy, programů a dalších reportů – především v papírové formě, částečně i v e-podobě na WWW – periodicita – vždy několik dní před plánovaným odjezdem • Údaje finančního charakteru – účetní materiály (vydané faktury, objednávky, pokladní doklad, výpisy z BÚ) – účetní uzávěrka jednou ročně – elektronické i tištěné, k dispozici vedení, kopie pro FÚ, archivace • Statistika – vytíženost zájezdů, počet klientů, atraktivita nabízených zájezdů, spokojenost klientů – periodicita – pravidelně (podle aktuální poptávky vedení firmy)

5.4

5.4


31


Současný stav je zobrazen BPM digramem a diagramem aktivity, který ukazuje proces rezervací zájezdů klientem na pobočce. V BPM diagramu vidíme, že je systém celé kanceláře autonomní bez propojení na externí systémy. V use case diagramu jsou zobrazeny základní činnosti, které byly doposud prováděny v kanceláři a to je: • vkládání zájezdů • editace zájezdů • prohlížení, mazání rezervací • zpracování objednávek • příprava statistických dat Integrací bude celý koncept rozšířen o subsystém komunikace s obchodními partnery.

Obr. 7: Business Process Management diagram

5.4


32

Use case model Následující diagram zobrazuje use case diagram, na kterém jsou názorně vyjádřeny hlavní činnosti v rámci cestovní kanceláře a jaké procesy budeme integrovat.

Obr. 8: Use case model CK

6

INTEGRACE POMOCÍ MICROSOFT BIZTALK SERVERU

6 6.1

33

Integrace pomocí Microsoft BizTalk Serveru Použité technologie

XML z obchodního hlediska Tato diplomová práce je především zaměřena na používání XML pro elektronické obchodní transakce business-to-business. Díky podstatě XML, která nabízí možnost transakcí popisujících sama sebe, se tento jazyk výtečně hodí pro elektronický obchod. V této souvislosti lze hovořit o proudu, který na jedné straně transakce, bude přečten, interpretován a poté smazán. Technologie XML také umožňuje spravovat datové objekty trvalejšího rázu, například tradiční dokumenty. Poskytovatelé obsahu jsou ty firmy, které poskytují informace spotřebního rázu pro své zákazníky nebo potencionální zákazníky. Ekonomický tlak na tyto poskytovatele je nutí zkoumat způsob, jakým své informační objekty spravují. V minulosti bylo možné zveřejňovat informační obsah v podobě tištěných dokumentů. Není možné pominout fakt, že papír a jeho pozdější náhražky (textové soubory, soubory PDF) mají určitá omezení. Dokument není ve skutečnosti aktuální informací. Dokument je pouze jedno možné vyjádření informace, patřičně zformátovaný, a proto je papír vhodný pro šíření obsahu.Na počátku devadesátých let nastoupil CD-ROM. Papírový dokument nebylo možné pouze umístit na CD-ROM, protože veřejnost od elektronických dokumentů očekávala vyšší hodnotu než jen obyčejné kopírování obsahu. Požadovali například v textu vyhledávat určité textové řetězce nebo klíčová slova, taktéž prohledávání jen určité části CD-ROM. Dále internet zvýšil naše požadavky na objem informací. Webová prezentace, která hodlá zaujmout potencionální zákazníky by měla na svých stránkách nabízet alespoň tolik informací, kolik si zákazníci požadují vidět. Takové sídlo je cíleně zaměřeno na zákazníky, jde tedy o sídlo typu B2C. Vytvoření takového sídla je však silně závislá na schopnosti majitele zajistit potřebné informace v použitelném stavu, a to od všech poskytovatelů těchto údajů. Prostředí, v němž mají probíhat obdobné transakce business-to-business, je obvykle ideálním kandidátem na nasazení technologie BizTalk a elektronické výměny dokumentů. Dalším aspektem XML a elektronického obchodu je vzájemná důvěra. XML může nabídnout také určité úrovně zabezpečení, protože údaje o obchodní operaci mohou být zasílány přímo se správou.Dokumenty XML jsou obvykle vytvářeny obdobným způsobem v nějaké aplikaci, která přímo převádí údaje do tohoto formátu. Dokument XML obsahuje všechny informace potřebné pro provedení určité transakce. Tento čerstvě vygenerovaný dokument je aplikací odeslán našemu obchodnímu partnerovi ve formátu XML, jehož syntaxe je většinou zcela odlišná než syntaxe původní aplikace, která ho vytvořila. Aplikace běžící u našeho partnera obdrží proud XML.Tomuto proudu rovněž nerozumí, proto si ho nejdříve musí přeložit do nativního jazyka a teprve pak může přijatý dokument zpracovat. Potom se však už nejedná o dokument XML. Data obsažená v tomto dokumentu budou uložena v cílovém systému,přitom jednotlivé složky celku budou určeny pomocí značek XML.

6.1

Použité technologie

34

Díky svému otevřenému statusu je XML funkční na libovolné platformě a s libovolným programovacím jazykem. Výhodou XML je to, že vám umožňuje oddělit vlastní data od procesů, které s těmito daty pracují. Bez problémů můžete data XML funkční na libovolné platformě a s libovolným programovacím jazykem. Výhodou XML je to, že vám umožňuje oddělit vlastní data od procesů, které s těmito daty pracují. Bez problémů můžete data XML vytvářet a číst i v Microsoft Visual Basicu, Microsoft Visual C++, Perlu, nebo dokonce i Cobolu. Na rozdíl od HTML, které má pevně danou sadu značek, vám XML umožňuje pružně vytvářet značky podle vlastní potřeby.Jednotlivé složky dat můžeme pojmenovat podle libosti. Jednotlivé tagy (značky) XML budou obvykle vyjadřovat reálná data. Budeme-li zpracovávat a přesouvat data uložená například v textových souborech, musíte si vytvořit vlastní syntaxi a pravidla pro načtení obsahu souboru. Pokud budete používat XML, tato starost odpadá. Musíte pouze vytvořit takový dokument XML, který je sémantický a syntakticky správný a poté pomocí analyzátoru načíst jeho obsah a vypreparovat z něj vlastní data. Na trhu je početné množství analyzátorů, včetně toho, který je dodáván přímo s Microsoft Internet Explorerem, a obvykle jsou nabízeny zdarma. EDI (Electronic Document Interchange) Dle (Jilovec, 1993) je EDI definováno jako komunikace mezi počítači prostřednictvím obchodních dokumentů ve standardizovaném formátu mezi dvěma společnostmi. I když je EDI spíše technickou záležitostí, je to v podstatě obchodní iniciativa. Prvopočátkem elektronické výměny dokumentů je specifikace EDI (Electronic Document Interchange). Výměna obchodních dokumentů v elektronické podobě začíná v první polovině sedmdesátých let 20. století. Tato iniciativa byla propagována mnoha odvětvími, jako jsou dopravní, prodejní, obchodní či průmyslová odvětví, za účelem zvýšení kvality služeb poskytovaných zákazníkům a nabídnout úspory nákladů z dlouhodobého hlediska. Mezi nejznámější průkopníky EDI koncepce patří například firmy Sears nebo Kmart. Tyto firmy vlastnily tisíce skladů a obchodovaly se stovkami dodavatelů, důsledkem toho byly velké stohy papírových dokumentů. Bylo zcela jasné, že tyto záplavy papíru negativně ovlivňovaly produktivitu práce, a proto se začali objevovat první metody jak komunikovat elektronickou cestou. K tomu, aby s těmito giganty mohli komunikovat jejich dodavatelé bezpapírovou formou, museli si vyvinout a udržovat rozhraní uzpůsobené pro každého elektronického partnera samostatně. Došlo tak k náhradě klasických dokumentů jako jsou nákupní příkazy, objednávky, faktury, které jsou v EDI představovány svými ekvivalenty a počítačově zpracovatelnými zprávami. Hlavní překážkou užití u menších firem jsou implementační náročnost, náklady na komunikaci, která se nejčastěji realizuje prostřednictvím veřejných datových sítí s přidanou hodnotou (VAN – value-added network). VAN operátoři si většinou účtují určitou částku za přenesený znak v EDI zprávě a rámcově se tyto částky pohybují okolo 3 centů USD za znak. Tyto výdaje jsou obecně vzato příliš vysoké pro společnosti, které nevyužívají velká množství EDI transakcí.

6.1


35

Proces náhrady papírových dokumentů jejich elektronickou podobou je realizováním prostřednictvím několika kroků: • zvýšení přesnosti snížením manuálního zpracování člověkem • snížení časové náročnosti při přenosu zpráv • zlepšení kvality služeb zákazníkům • celkové snížení celkových nákladů Americkou alternativou k EDI je norma X12. Koncem sedmdesátých let začal výbor, složený z představitelů dopravního sektoru, vlády a výrobců počítačů, pracovat na vývoji metody na vylepšení a standardizaci elektronického obchodu. American National Standards (ANSI) autorizoval Accredited Standards Committee (ASC) X12 v roce 1979. Jeho prvořadým úkolem bylo vytvoření jednotného standardu pro elektronickou výměnu obchodních dokumentů. X12 byl prvním z několika standardních formátů pro elektronický obchod. Tato krátká historie ukazuje dvojí tvář standardů – musí být dostatečně všeobecné, aby byly přijaty na široké bázi, ale zároveň natolik konkrétní, aby byly užitečné. Problémy v oblasti EDI během posledního čtvrtstoletí (dlouhá doba vývoje, nejrůznější požadavky ze stran různých firem, obtížná široce použitelná implementace by měly být ponaučením pro všechny, kdo pracují na výměnných standardech používajících XML. Skupina XML/EDI vyvíjí více volně dostupných verzí specifikací EDI s cílem přesvědčit tradiční uživatele EDI k přechodu na XML. Nejde o osamocenou skupinu. Ke stejnému cíli směřuje více iniciativ – všem jde o vytvoření univerzálního způsobu jak obchodovat s jinými subjekty s využitím XML jako syntaxe pro definici dat. Dalším cílovým standardem, který rozhodně stojí za zmínku, je iniciativa ebXML. V této zkratce znaky představují – electronic business. EbXML je vyvíjeno organizacemi United Nations/CEFACT a Organization for the Advancement of Structuret Information Standards (OASIS). Účelem ebXML je použití sady standardních objektů XML pro zajištění mezinárodního obchodu a vývoj technického systému, který umožní používat XML pro výměnu všech dat týkajících se elektronického obchodu. Mezi další normy, tentokrát již v rámci jednotlivých odvětví, patří dle (Travis, 2000) specifikace Financial Information Exchange (FIX) pro zabezpečenou výměnu informací, HL7 pro zasílání lékařských záznamů, ACORD pro výměnu informací o pojištění majetku a o vzniklých nehodách, J2008 pro automobilový průmysl a mnoho dalších. Všechny využívají XML jako základní syntaxi celé specifikace. Struktura EDI dokumentu EDI standard je vybudován na konceptu datových elementů, segmentů a kódů. Každá zpráva standardu EDI dodržuje standartní strukturu segmentů. Tento základ znázorňuje následující obrázek, který autor převzal z (EDI Tutorial, 2009). • Komunikační transportní protokol – je metoda která koordinuje komunikaci mezi dvěma počítači

6.1


36

Obr. 9: Struktura EDI, převzato EDI Tutorial, 2009

• ISA Interchange Control Header – to je standardní segment v EDI, který označuje začátek výměny dat. Obsahuje identifikace spojení odesilatele, příjemce a další pole nutná k interpretaci přicházející zprávy • GS Functional Group Header – je segment který označuje začátek funkční skupiny. Obsahuje skupinu typ identifikátor skupiny odesilatel a příjemce a verze užitého standardu • ST Transaction Set Header – označuje začátek transakce • Data segments – je prostřední jednotkou informace ve zprávě. Obsahuje data. • SE Transaction Set Marks – označuje konec transakce • GE Functional Group Tralier – tento označuje konec funkční skupiny, obsahuje ten samý identifikátor asociované funkční skupiny hlavičky a číslo transakce • GE – označuje začátek transakce Technologie XML XML je standart navržený konsorciem W3C (World Wide Web Consortium). Toto sdružení se věnuje vytváření a správě základních technologií Internetu. Zkratka XML znamená eXtensible Markup Language, jedná se tedy o jazyk značkovací. XML je vlastně sada pravidel (syntaxe) pro značkování dat. Syntaxe je kompaktní, dostatečně malá a schopná vytvářet standardy, a v tom je právě její hodnota. Chcete-li se zapojit do nějaké obchodní transakce, musíte komunikovat přímo se svými obchodními partnery. XML obsahuje syntaxi pro přímou a přesně definovatelnou komunikaci, protože identifikuje každou část informací, nutných pro dokončení celé operace.

6.1


37

V elektronickém dokumentu značkováním rozumíme kód, uložený spolu s textem, který v sobě ukládá informace potřebné pro elektronické zpracování. Patří sem například názvy fontů, tučnost písma u formátů, využívajících procedurální značkování, jako je rtf, či tex. Kdežto u XML, značkování učuje strukturu dokumentu. XML je jazyk samopopisný, využívající obecné kódování, který označí význam jednotlivých částí textu a ne jeho vzhled. Obrovskou výhodou XML je jeho rozšiřitelnost, protože nemá žádné předdefinované tagy a je možné si vytvořit tagy podle svých potřeb. Samozřejmě XML není v historii prvním značkovacím jazykem. Předcházelo mu SGML, což je vnitřní standart, ze kterého vychází XML, tak i HTML. SGML Jazyk SGML dále rozšiřuje obecné kódování. Rovněž je mezinárodním standardem, vyhlášeným organizací ISO (International Standard Organisation). SGML má dle Marchala B. (2000) oproti obecnému kódování dvě přídavné charakteristiky: • Značky popisují strukturu dokumentu, ne však jeho vzhled. • Značkování se podřizuje modelu, který se podobá schématu databáze. Díky tomu může být zpracováno aplikací, nebo uloženo do databáze. Jazyk SGML je opravdu hodně obecný, umožňuje definici vlastních značkovacích jazyků pomocí tzv. definic typu dokumentu DTD. Má rovněž velké množství volitelných parametrů. Ale komplexnost standardu SGML způsobilo zpomalení využití v praxi. SGML bylo podporováno americkým ministerstvem obrany, které od svých dodavatelů vyžadovalo dokumentaci právě ve formátu SGML. Bylo to z důvodu použitelnosti tohoto formátu z hlediska dlouhého časového období. Nejznámější aplikací SGML je jazyk HTML, který se od poloviny 90. let používal pro tvorbu webových stránek, získal si velkou oblibu díky svojí jednoduchosti. Postupně ale jeho obliba klesala, jelikož se ukázalo, že pevná skupina značek, které HTML používá, už nestačí. V případě SGML se ukázalo, že se v praxi používá jen část z jeho možností a právě z této podmnožiny vznikl jazyk XML. XLink a XPointer Jedním z příkladů standardů, které řeší potřeby lepšího zpracování dokumentů XML, je standard pro vytváření odkazů (propojení). XML vyjadřuje informace pomocí hierarchických vazeb. Element může mít své potomky (dětské elementy) atd. struktura dokumentu XML však popisuje jen tento model. Některé datové struktury nemají žádné hierarchické vazby – objekt může být vázán i na jiný objekt, který je umístěn zcela někde jinde. Takový typ vazby musí být vyjádřen spíše odkazem, nikoli vztahem rodič – dítě. Pracovní koncepty konsorcia W3C nabízí dvě standardní možnosti, jak vyjádřit vazby: XLink a XPointer. XLink umožňuje inline, pomocí kterých je možné načítat části různých dokumentů přímo do aktuálního dokumentu. Tímto způsobem je možné vytvořit stránku skládající se ze samých odkazů, aniž by to bylo v prohlížeči vidět. XPointer je doplňkem XLink, umožňuje odkazovat jen na

6.1


38

část dokumentu, pokud není třeba výchozí odkaz na celý dokument. Adresa URL odkazovala na určité místo v dokumentu. Uvedení záložky v odkazu však znamená jen to, že se po načtení celé stránky prohlížeč automaticky posune na místo za touto záložkou. Syntaxe jazyka XPointer dovoluje adresovat jen část stránky, a to mnohem jemněji a přesněji, než jak to dokáže HREF v HTML. Pomocí Pointer můžeme například v odkazu XLink určit, aby byly staženy jen určité odstavce označené kapitoly. Syntaxe XML Dokument XML může být dle (Travis, 2000) buď správně strukturovaný nebo platný. Správně strukturovaný dokument dodržuje množství pravidel, která jsou podrobně popsána ve specifikaci XML. Dokument XML je platný tehdy, jestliže má přidruženu deklaraci typu dokumentu a pokud vyhovuje všem omezením, která jsou v ní určena. Shrneme si nejčastější pravidla pro správně strukturované dokumenty XML: • každý element musí mít počáteční a ukončovací tag • dokument musí mít jeden jedinečný kořenový element • v názvech elementů a atributů se rozlišují malá a velká písmena • elementy musí být správně zanořeny (nemohou se překrývat) • určité znaky musí být vypuštěny nebo nahrazeny skupinou jiných znaků • hodnoty atributů musí být v uvozovkách • prázdné elementy mají speciální podobu a tu musí dodržet Správně strukturovaný dokument XML začíná volitelnou deklarací XML, která říká analyzátoru, že jde o dokument XML. Deklarace může obsahovat i další informace pro analyzátor o povaze datového proudu XML. Konkrétní deklarace vypadá následujícím způsobem: Za atributem version může následovat deklarace použitého kódování. Deklarace kódování udává znakovou sadu, ve které byl dokument vytvořen. Dokumenty XML jsou standardně psány v Unicode, buď osmibitovém (UTF-8) nebo šestnáctibitovém (UTF-16) kódování. Deklarace samostatného dokumentu následuje za údajem o kódování. Vypadá takhle: Standalone="yes" Hodnota této deklarace může být yes nebo no. Hodnota yes říká analyzátoru, že všechno, co o dokumentu potřebujeme vědět, je obsaženo v jeho datovém proudu, který následuje za deklarací. Znamená to tedy, že nikde nejsou určeny žádné externí entity a že žádný atribut nemá stanovenu v extrémním schématu výchozí hodnotu. Hodnota no znamená, že aplikace, která s dokumentem pracuje, možná bude muset prozkoumat nějaké vnější zdroje informací, aby mohla dokončit analýzu dokumentu. Deklarace XML musí být ve správně strukturovaném dokumentu umístěna na jeho začátku a stejně jako zbytek XML rozlišuje mezi malými a velkými písmeny. Celý dokument je sestaven z textu a značkování. Značkování se skládá z ohraničených

6.1


39

značek (tagů), které popisují data uvnitř dokumentu. Element je datový objekt, musíme jej v dokumentu identifikovat názvem, který popisuje daný typ dat. Pomocí tagů určujeme začátek a konec elementu. Element v dokumentu musí začínat počátečním tagem a končit odpovídajícím ukončovacím tagem (/). Data mezi nimi jsou obsahem elementu.Každý dokument XML musí mít jeden jedinečný kořenový element, tzv. root element. Jakmile je pro tento element nalezen jeho ukončovací tag, je dokument ukončen. Názvy elementů a atributů XML rozlišují malá a velká písmena. Elementy ve správně strukturovaném dokumentu musí dodržet řádnou stromovou strukturu.Značkování a obsah dokumentu je schopen analyzátor vzájemně od sebe oddělit pomocí určitých znaků, které při své analýze hledá. Pokud potřebujeme tyto znaky použít v obsahu dokumentu a nechceme, aby je analyzátor považoval za značkování, je třeba použít odkazy na entity, což jsou řetězce znaků, které analyzátor přečte a přeloží je do jiného znaku. Atributy V některých případech samotný název elementu nestačí. Elementy XML můžeme blíže určit nebo popsat pomocí jejich atributů. Atributy obsahují dodatečné informace o elementu. Zapisují se jako název – hodnota do počátečního tagu elementu. Vlastnosti, které jsme si doposud popsali, se týkaly správně strukturovaného dokumentu. Validní dokument má přidruženu deklaraci typu dokumentu a vyhovuje všem jeho omezením. Deklarace typu dokumentu oznamuje analyzátoru, kde najde sadu pravidel, vůči kterým musí celý dokument prověřit. Je určena struktura členů určité třídy dokumentů. Tomuto popisu struktury se říká schéma. Jedním možným je DTD. Tento formát schématu byl převzat ze SGML a zbaven všech volitelných prvků a dále prvků, které ztěžovaly jeho zavádění. Schémata Schéma popisuje strukturu sady informací. XML 1.0 specifikuje jako schéma DTD (document type definition). DTD je relikvie z dob SGLM a jako taková nemá vestavěný moderní prostředky pro zpracování dat. DTD je skvělou pomůckou pro vyjádření struktury textových dokumentů typu technické manuály, plány obratu, učební knihy. Ale v případě přenosu databázových dat v reálném čase nebo obchodních dokumentů mezi smluvními partnery v prostředí elektronického obchodu se projevují určitá omezení DTD. Krátce po té, co pracovní skupina konsorcia W3C dokončila práci nedoporučením XML 1.0, vznesly některé skupiny návrhy na vypracování syntaxe schémat, které by rozšifrovaly možnosti DTD. Mezi tyto návrhy patřily XML Data, DDML(Dokument Definition Markup Language, SOX (Schéma for Object-oriented XML Data, DDML (Document Content Description for XML). Dalším možným popisem struktury XML dokumentu jsou dle (Kosek, 2000) XML schémata, které vynikají úplností podporovaných typů dat. Obsahují základní datové typy, ze kterých se odvozují další typy, popřípadě si definujeme vlastní typy. Tyto datové typy mají navíc výhodu oproti datovým typům v DTD, že typ lze užít

6.1


40

i pro obsah elementu a ne jen pro jeho atributy. Významná síla schémat spočívá v možnosti definice vlastních datových typů. Nově vytvořený typ se definuje odvozením z některého již existujícího.Je možné souběžně aplikovat různá integritní omezení, třeba minimální maximální délka, výčet přípustných hodnot apod. Datatype elementu se definuje pomocí jednoduchého datového typu. Integritní omezení mají poměrně rozsáhlé možnosti. Mohou například zahrnovat výčet povolených hodnot, kde je možnost vytvoření omezení na základě regulárního výrazu. Definice elementů Syntaxe schémat je založena na XML. Jméno elementu je přitom určeno pomocí atributu name a typ pomocí atributu type. <element name="jméno"type="string"/> Tento definovaný element smí obsahovat pouze data typu string – tedy text. Obsahovat další elementy již nemůže. U kteréhokoliv elementu můžeme specifikovat, kolikrát se v daném místě může opakovat. Minimální a maximální počet výskytů lze určit pomocí parametrů: minOccurs, maxOccurs. Každé B2B odvětví má sadu schémat, které využívá ke vzájemné komunikaci mezi jednotlivými členy daného odvětví. Cestovní společnosti mají standardu pro sloučení informací například o volných pokojích a letovém řádu. V našem technologickém konceptu však využíváme nového standardu UNICORN. Struktura může být zcela odlišná od nákupního příkazu vytvořeného nákladním dopravcem a společností letecké dopravy. Přestože všechny tyto příkazy obsahují stejné základní informace, je jejich struktura jiná. Tento přístup se zcela odlišuje od tradičního přístupu EDI, jenž vyžaduje, aby faktura měla jednotnou strukturu. Tou se musíme řídit bez ohledu na to, jaké informace potřebujeme i náš partner k tomu, abychom mohli transakci úspěšně uzavřít. Jmenné prostory Jmenné prostory udávají procesoru XML místo, kde jsou uložena strukturální pravidla (schéma), která má použít na obsah dokumentu. Deklarace jmenného prostoru odkazuje na zdroj obsahující schéma, které popisuje dokument. Jmenné prostory nabízejí možnost, jak rozlišit různé elementy se stejným názvem v rámci jednoho dokumentu. Kolizi názvů zabráníme tak, že v úvodní části dokumentu deklarujeme dva jmenné prostory, které odkazují na dvě různé schémata popisující strukturu zdrojových dokumentů. Ke každému elementu pak přidáme příslušnou předponu, kterou máme určenu v deklaraci. Tímto způsobem jednoduše vyřešíme konflikt dvou stejných názvů různých elementů.Jestliže v názvech elementů používáme předponu, můžeme v seznamu vytvořit různá pravidla pro každý z nich, a také aplikace může tyto elementy zpracovat nezávisle na sobě.

6.1


41

XSLT Během vývoje standardu XSL se zjistilo, že transformace dokumentů může mít velký význam i v případě, že dokument nebude zobrazen. Proto část XSL týkající se převodu dokumentů byla vyňata a vytvořen nový standard XSLT (XSL Transformations). Tento standart je doporučením konsorcia W3C a jedná se o nástroj pro obecné transformace, použitelný v mnoha situacích. Pojem transakce označuje změnu dokumentu XML na jiný dokument a určuje vizuální vzhled dokumentu na nějakém zařízení. Pro převod dokumentu XML do formátu HTML, případně jedné struktury XML do jiné, můžeme použít styly XSL. Transformace jsou užitečným nástrojem například v situacích, kdy firma interně používá jedno schéma a její dodavatelé zase jiné: pak díky XSL můžeme převést doručené dokumenty dodavatelů do interního schématu naší firmy. Vlastní data dokumentu se obvykle nemění, ale v případě potřeby je možné skriptem změnit i je. Dále konsorcium W3C vydalo část XSL týkající se syntaxe porovnávání řetězců a vytvořilo z něj specifikaci XPath. Ta zajišťuje způsob popisu struktury zdrojového dokumentu, aby ho bylo možné převést do dokumentu jiného. Formátování objektů a transformace dokumentů XML Při formátování dokumentu načítá XML, kterému se říká výsledný strom. Tento výsledný strom používá formátovací jmenný prostor, v němž jsou stovky elementů a atributů, popisujících způsob zobrazení dokumentu. Ve výsledném stromu je na příklad určeno, jestli konkrétní textový objekt bude zobrazen tučným písmem nebo kurzivou, černou nebo červenou barvou, jako samostatný blok nebo inline blok. Výsledný strom však neobsahuje žádné speciální instrukce pro konkrétní typografický jazyk. Instrukce jsou provedeny v dalším kroku XSL, při interpretaci formátovacích objektů. Výsledný strom je načten do překladače formátovacích objektů, který postupně překládá jednotlivé elementy a atributy do výstupního typografického kódu pro konkrétní zařízení. Schopnost XSL provádět transformace dokumentů je velmi výkonným nástrojem, umožňujícím lehce převádět dokumenty XML z jednoho schématu do jiného. Microsoft BizTalk Sever obsahuje nástroj BizTalk Mapper, který zjednodušuje vytváření stylů XSLT pro automatické provádění těchto transformací, jestliže dostáváme dokumenty od různých obchodních partnerů a jestliže jim odesíláme nějaké dokumenty vytvořené v našem systému. XSLT pracuje bezprostředně se vstupem XML, přičemž vytváří výstupní dokument XML s požadovanou strukturou. XSLT můžeme v prostředí technologie BizTalk považovat za mapovací funkci, která propouje určité prvky vstupu s jinými prvky výstupu.

6.2

6.2

MS BizTalk Server

42

MS BizTalk Server

S vývojem BizTalku je spojena firma Microsoft a od počátku bylo hlavním smyslem vyřešit problém výměny obchodních dokumentů mezi obchodními partnery zapojenými do elektronického řetězce dodávek, což je jednou z konkurenčních výhod. Toto se označuje SCM (Supply Chain Management). Díky SCM dochází k snížení času potřebného na dodání zboží zákazníkovi a zvýšení spolehlivosti celé dodávky. Jak je již v liteřatuře zmíněno (Basl, 2002), klasický dodavatelský řetězec byl v podstatě lineární a spočíval v realizaci základní vazby: dodavatel → výrobce → distributor → prodejce → zákazník Tok zboží směřoval zleva doprava a tok informací a zároveň finančních prostředků, tzn. plateb za uskutečněné dodávky výrobků a služeb, probíhal opačným směrem. dodavatel ← výrobce ← distributor ← prodejce zákazník V dnešní době se ale podniky na bázi internetových služeb propojují do složitějších celků, kde je hlavním účelem nabídnout rychleji a efektivněji konkurenceschopný produkt požadované kvality. Mnoho aktivit je ve fimách outsourcováno, využívají se služby specializovaných firem s potřebnými technologiemi a know-how. Řetězec již není lineární, ale zahrnuje více subjektů, jak vidíme na následujícím obrázku.

Obr. 10: Struktura dodavatelského řetězce na bázi internetu

SCM (Supply Chain Management) – řízení dodavatelských řetězců či sítí – jedná se o souhrn nástrojů a procesů, které slouží k optimalizaci řízení a k maximální efektivitě provozu všech elementů celého dodavatelského řetězce s ohledem

6.2

43

MS BizTalk Server

na koncového zákazníka. Tyto systémy jsou typickým příkladem vzájemného propojení dodavatelů s odběrateli zboží, či služeb, jehož prostřednictvím mohou obchodní partneři spolupracovat. SCM není proces spojený až s komputerizací v pondnicích a vznikem internetových technologií. Řízení logistických procesů v podnicích má již svoji historii, tak jak zajímavě popsal M.L. Fox a autor (Basl, 2002) rozlišuje pět vývojových fází: • První fáze souvisí s problémem snižování nákladů v rámci lokálního zlepšování na úrovni nezávislých oddělení a útvarů podniku. • Druhá fáze konsoliduje mezifunkční týmy. Do popředí se dostává zvýšení spolehlivosti plnění celých zakázek a zákaznického servisu. Měřítkem je včasné dodání zboží, či služeb. • Třetí fáze se soustředí na integraci v podniku a schopnost plnění zakázek. Vetšina činností s tím související obstarává ERP systém. Dbá se na celkové náklady, které jsou vynaloženy na včasné plnění objednávky. V současné době je tato fáze v podnicích nejrozšířenější, na vzestupu je rovněž podpora prostřednictvím podnikových intranetů. • Čtvrtá fáze představuje rozšířený dodavatelský řetězec, ve kterém na principu výměny dat prostřednictvím EDI nebo internetu, dochází ke zvýšení vzájemné komunikace mezi podniky za účelem snížení času a nákladů na realizaci. Do procesu návrhu a implementace řešení komunikace EDI se zapojuje i zákazník. • Pátá fáze představuje pružné uspořádání partnerů v rámci sítě s rekonfigurovatelnými procesy. V této fázi jsou využívané všechny možné technologie výpočetní a komunikační techniky. Tab. 1: Nabídka SCM produktů na českém trhu. Zdroj Basl, Velkoborovský/IDG, 2001 Název produktu

www adresa

Název firmy

APO, mySAP SCM www.sap.com SAP iBaan Supply Chain Planner www.baan.com Baan Company Intentia www.intentia.com Intentia J. D Edwards www.jdedwards J. D Edwards NetWORKS www.manugistics.com Manugistics MSO www.mso-concept.de MSO Concept OPT Solution Suite www.stg.co.uk STG Oracle www.oracle.com Oracle Preactor www.cimcentre.com Preactor Internatinal SCT Fygir www.sct.com SCT S-Plan www.greycon.com Greycon SyteAPS www.frontstep.com Frontstep/Symix Z výše uvedeného je názorně vidět, jak je konkrétní technologie jakou BizTalk je úzce spjata s konceptem informačního systému. Budeme-li se dále zabývat BizTal-

6.2

MS BizTalk Server

44

kem na technické úrovni, rád bych analyzoval možnosti tohoto vývojového nástroje. Jak jsem již zmínil, hlavním posláním BizTalku je výměna obchodních dokumentů. Tento proces je vyžadován elektronickými obchody. Častěji je pojem elektronický obchod chápán ve smyslu obchodník-spotřebitel (business-to-consumer, B2C). Toto je však pouze jedna část elektronického obchodu. Velmi významné jsou transakce, které probíhají mezi jednotlivými firmami. Každý obchodník má zájem o snížení nákladů na prodej, usiluje o využití technologií, které těchto úspor dosáhnou. Když se podaří snížit náklady u jednoho druhu zboží, či poskytované služby jen o pár procent, není to až tak významné. Ale v rámci velkoodběratelů a velkého počtu transakcí, to již smysl má. Nelze opomenout rovněž to, že i výroba zcela jednoduchého výrobku zahrnuje mnoho transakcí. Výrobce nakupuje materiál od několika dodavatelů a různé druhy, používá různé přepravní společnosti, různé marketingové strategie a zprostředkovatele. Všechny tyto aspekty rapidně navyšují celkový nutný počet transakcí. Když si představíme, že každou tuto transakci musí někdo zaplatit, je naprosto zřejmé, ze i minimální úspora dílčí transakce se podstatným způsobem promítne do ceny výrobku, či služby. Tyto transakce se tedy dotýkají především oblasti business-to-business obchodu B2B. BizTalk Server je určen pro převod dat a integraci aplikací a používá se k výměně obchodních údajů. Využitím jazyka XML umožňuje řídit vztahy s obchodními partnery napříč spektrem všech odvětví, stejně tak jako mezi různými obchodními systémy bez ohledu na použitou platformu, operační systém nebo relevantní technologii. Tento server poskytuje standardní bránu pro odesílání a přijímání dokumentů po síti Internet a zajišťuje integritu dat, stejně tak bezpečnost jejich doručení. Funkčnost serveru BizTalk zahrnuje schopnost přijímat příchozí dokumenty, analyzovat je a určovat jejich formát, extrahovat klíčové identifikátory, určovat pravidla zpracování, doručovat dokumenty na příslušná místa určení. Součástí jsou také komponenty pro mapování dat, nástroje pro definici struktury obchodních dokumentů (schémat), tak i pro převody dat mezi těmito dokumenty pomocí jazyka XSLT. Tento server v sobě slučuje funkci několika služeb, umožňující sjednotit obchodní dokumenty, které právě ve svém systému používáme. Také poskytuje několik nových součástí, jenž můžeme využívat jak ve správě svých dat a k výměně informací. Obsahuje také komponenty určené pro správu a údržbu serveru. Tento systém obsahuje právě ty funkce, které jsou potřebné pro činnosti serveru, navrženého – na úrovni obchodního dokumentu – k integraci naší kanceláře s kancelářemi obchodních partnerů. Princip aplikace BizTalk Hlavním předpokladem je, že každý obchodní partner je povinen používat stejnou strukturu dokumentů jako mi. Tuto koncepci dodržíme určením společné sady elementů pro určité objekty, ale zároveň by měla poskytovat dostatečnou pružnost. Její zásluhou se partneři rychleji dohodnou, které z nich budou prakticky používat.

6.2

MS BizTalk Server

45

Transakce B2B V této části si ukážeme realizaci obchodních operací B2B pomocí BizTalk. Tato konkrétní událost vyžaduje odeslat danému dodavateli objednávku. Jednou z procedur, v rámci naší firmy, je vyplnění formuláře žádosti o objednávku, obsahující pole s potřebnými údaji, kterou zpracuje příslušný pracovník. Jedná se o interní dokument, sloužící pro komunikaci mezi jednotlivými pobočkami naší kanceláře. Dokument BizTalk je prakticky utvořen ze dvou dokumentů. Jeden z těchto dokumentů nahrazuje klasickou obálku, druhý zase obsah dokumentu uvnitř obálky. Zásluhou jmenných prostorů a schémat XML můžeme vytvářet virtuální obálky a virtuální dokumenty uvnitř nich. Když nějaká firma dostane dokumenty XML, server BizTalk jej přečte a zkontroluje jeho údaje. Nejdříve podle Party určí, kdo skutečně má dokument obdržet. Následně rozloží zbývající položky, aby mohl zapsat objednávku do příslušné databáze doručených objednávek. Nakonec server převezme objednávku a předá ji aplikaci, která zajistí její další zpracování. Toto všechno již probíhá způsobem, podle aplikace, kterou firma ve skutečnosti používá. Server, který dokument přijal, musí poslat zpět potvrzení o doručení zprávy. Komponenty architekury BizTalk BizTalk je z hlediska Windows aplikací služba jako každá jiná, která běží na pozadí a vykonává svoji činnost. Hotový projekt v Biz Talku se ve Visual Studiu překládá do knihovny DLL, která se nazývá Assembly. Assembly představuje celou aplikaci a obsahuje všechny jejich součásti a při instalaci se celá umístí na server (v produkčním prostředí). Při instalaci na server se všechny součásti systému uloží do GAC (Global Assembly Cache), přenáší se i orchestrace, které je nutné manuálně spustit. Proběhne rovněž generace předem konfigurovaných portů, které jsou napojeny na orchestrace. Instance nové orchestrace může vzniknout buď spuštěním na vstupním portu nebo voláním z jiné orchestrace. Pokaždé však přijímá vstupní zprávu, ať už se jedná o asynchronní, či synchronní přenos dat po ukončení běhu orchestrace je jí instance zakončena a proběhne také uvolnění paměťového prostoru, stejně tak záznamu v databázi. Pokud dojde k nějaké chybě v příběhu orchestrace, dojde k jejímu pozastavení (suspend) tento stav lze ošetřit v BizTalk administraci a problém analyzovat vyřešit a dále jej nechat pokračovat či ukončit. Mapování Základem integračních projektů je potřeba výměny dat. Pokud systém vyžaduje přijímat data, musít být v obvyklém formátu, nebo musí existovat způsob jak přetransformvat data z jednoho systému do druhého. Původně mapování pokrývalo mnoho komponent a entit, jako je databázová vrstva, nebo dokonce publikační systémy a systémy konzumující zprávy. Pokud došlo k rozšíření systému, mnoho komponent, které byly součástí integrace musely být kustomizovány. Integrační aplikace, obzvláště BizTalk Server umožňuje centralizované a dobře organizované zajištění tran-

6.2

MS BizTalk Server

46

Obr. 11: Architektura platformy BizTalk Server

formací dat a poskytuje spoustu podpůrných nástrojů při vývoji transformačního procesu – mapování. Výměna dat vyžaduje, že všechny zúčastněné systémy používají běžný způsob, jakým jsou data interpretována nebo běžný způsob mapování z jednoho systému do druhého. Právě pro to nabízí BizTalk mnoho přístupů, nejvýznamnější je BizTalk Mapper, což je grafické rozhraní určené k vývoji transformací dat mezi různými počty schémat různorodých systémů nebo entit. Tyto mapy obsahují nezbytnou business logiku pro transformaci dat do formátu, který cílový systém vyžaduje. Je vhodné, aby business logika a transformace byly uloženy na bázi integrační vrstvy, která má schopnost mít k dipozici data. V tomto případě integrační vrstva může data konzumovat a manipulovat s nimi do potřebného formátu. Nositelem pravidel a business logiky nutných k transformacím jsou BizTalk mapy a orchestrace. Je dobré jednotlivé mapy vhodně organizovat do konkrétních řešení, jelikož v případě změny dochází k uprávám minimálního počtu komponent (mapovacích součástí, XSLT skriptů). Další systémy mohou být přidány do integrace bez nutnosti změny předešlých součástí. BizTalk mapper je užíván k mapování XML zpráv do alternativních formátů založený na transformaci a překladu. Je kompletně založen na XSLT, ale uživatele odstiňuje od komplexních XSLT transformací poskytnutím grafického rozhraní k usnadnění samotných transformací. Součástí jsou tzv. functoidy, zajišťující deterministické transformace. Jedná se o grafické reprezentace algorytmických prvků a strukur. V případě, když vývojář narazí na syntaktickou restrikci, či omezení ze strany implementačního rozhraní, můžeme potřebnou logiku zapsat přímo jako XSLT skript, popřípadě C#. Transformace definované v mapě mohou být jednoduché, jako jsou kopírování jména a adresy z jednoho dokumentu do druhého. Tyto kopie dat lze vyjádřit pomocí linků, které jsou v BizTalk mapperu prezentovány jako

6.2

MS BizTalk Server

47

čáry spojující příslušné elementy ze zdrojového schématu správným elementem do cílového schématu. Více komplexnější transformace lze řešit pomocí tzv. funktoidů. Funktoid je kus kódu. V BizTalku je představován grafickým symbolem a lze jej napojit pomocí čar a editací atributů lze nastavit příslušnou transformaci. Jelikož při klasických algoritmických úlohách se stále opakují jedny a tytéž konstrukce. Za tímto účelem máme k dispozici v BizTalku četné zabudované funktoidy, které jsou prezentovány grafickými symboly. Tyto funktoidy jsou seskupeny do následujících kategorií: • matematické funktoidy – vykonávají operace jako je sčítání, násobení, dělení, ukládání výsledků do polí atd. • konverzní funktoidy – konvertují numerické hodnoty do jejich znakových sad a atd. • kumulativní funktoidy – slouží pro výpočet měrných hodnot součtů popřípadě další • databázové funktoidy – slouží k přístupu k datům uloženým v databázích. Vývojář si pro často opakované úkoly může utvořit svoji vlastní funktoidy v programovacím jazyce .NET. Obchodní procesy Posílání zpráv mezi různými aplikacemi je nezbytnou součástí řešení problémů v BizTalku. Ve většině případů to však není jediným úkolem. Hlavním cílem BizTalk je definice a tvorba obchodních procesů. Toto je umožněno dvěma technologiemi a to jsou, orchestrace a Definice obchodních pravidel. Orchestrace Obchodní procesy lze definovat přímo v programovacích jazycích jako je C nebo .NET. Nicméně tvorba, údržba a řízení takto komplexního obchodního procesu v konvečních programovacích jazycích je poměrně složité. Nastává zde také problém, že obchodní logice většinou programátoři a vývojáři příliš nerozumí a naopak manažeři a vedoucí pracovníci zase nerozumí do hloubky technickým záležitostem. Právě proto BizTalk umožňuje definici obchodních pravidel pomocí GUI. To umožňuje rychlejší vývoj celého obchodního procesu, jeho rychlejší pochopení, vysvětlení a případné změny. Orchestrace je mechanismus, který zajišťuje sehrání akcí a odpovědí na události, či součástí služeb, které pracují společně za účelem podpory obchodních procesů. Každá orchestrace se sestává z více instancí skládající se z jedné nebo více transakcí, které mohou být dále vnořovány. Běžně se rovněž můžeme odkazovat z jedné orchestrace na jinou, popřípadě spuštění další orchestrace plánovat nějakou událostí např. triggrem v databázi dosažením nějakého data atd. Orchestrace v podstatě představuje průvodce objektově orientovaným, komponentně a na služby orientovaným programováním aplikací. Umožňuje prezentovat, komunikovat a udržovat komplexní transakce jakož to vizuálně navrhovat datové toky. Návrh orchestrace

6.2

MS BizTalk Server

48

spočívá v řízení datových toků a propojování pomocí obrazců. Mezi nejdůležitější obrazce patří: • přijímání zprávy – obsahuje filtr, který přesně specifikuje, jaká zpráva by měla být přijata a může být také nakonfigurován pro zpuštění nové instance další orchestrace, když ta konkrétní zpráva přijde. • posílání – umožňuje orchestraci odeslat zprávu • port – definuje jak jsou zprávy přenášeny. Každá instance portu je napojena na obrazce přijímání a odesílání • větvení – reprezentuje konstrukcí IF-THEN-ELSE, která umožňuje vykonávat různé úkoly založené na logické podmínce • opakování – umožňuje vykonávání opakované akce dokud je podmínka splněna • konstrukce zprávy – umožňuje vytvoření zprávy • transformace – umožňuje přenos informace z jednoho dokumentu do druhého a jeho transformací pomocí vyvolání mapy • paralelní akce – umožňuje zpětně kvalifikaci mnohonásobných operací, které mají být vykonány i v sekvencích. Další akce která následuje za touto akcí může být vyvolána jen tehdy, pokud jsou výchozí parametry akce ukončeny. • zanoření – umožňuje seskupit operace do transakcí a definovaných výjimek pro ošetření chyb. • přiřazení zprávy – umožňuje přiřazení hodnoty do proměnné orchestrace. Tyto hodnoty mohou být uloženy jako stav užívaný v orchestraci stejně tak jako zpráva nebo znakový řetězec. Jakmile je celá orchestrace navržena, je tato reprezentace obchodních pravidel konvertována do Microsoft InterMediate Language (MSIL), které užívá .NET běžné jazykové prostředí. Lze také definovat další konstrukce pomocí volání objektu COM. Messagebox BizTalk messagebox je jedna z nejdůležitějších databázových komponent BizTalk serveru. Jakmile je zpráva vložena do messageboxu, Biz Talk připojí dodatečné informace, tzv. kontext do zprávy. Kontext obsahuje informace jako je název portu kde byla zpráva přijata, ID zprávy (každý kus přijatých dat má unikátní ID) informace jedinečná pro adaptér a zdali se jedná o XML data, v tomto případě také namespace těchto XML dat. Messagebox také ukládá vykonané orchestrace. Celá architektura messageboxu je založena na databázi SQL serveru 2005 a prakticky jsou v ní uloženy veškeré tabulky integračního řešení a veškeré zprávy komunikujících obchodních partnerů. Umožnit přístup k údajům v této databázi je úlohou integračních služeb, ale proces získávání informací z dat je předmětem celého procesu BI.

6.2

MS BizTalk Server

49

Business Intelligence Business Inteligence je dle (Lacko, 2006) proces transformace dat na informace a převod těchto informací na znalosti. Jinými slovy, cílem Business Inteligence je konvertovat velké objemy dat na znalosti, vyžadované koncovými uživateli. Data obvykle sbíráme a shromažďujeme nejen kvůli archivaci, ale velmi často potřebujeme z dat v databázích získat užitečné informace, které později můžeme využít například v procesu rozhodování. Pod pojmem užitečná informace (Lacko, 2001) nerozumíme jen nějaký konkrétní záznam či množinu záznamů. Často potřebujeme sledovat trend nějaké veličiny, například při obchodování s obchodními partnery. Jindy zase potřebujeme vyhodnotit poměrně rozsáhlý a složitý soubor dat. Proto se do popředí dostává OLAP (Online Analytical Processing), Data Mining (dolování dat) a Data Warehouse (datové sklady). Podle komplexnosti zpracování výstupů můžeme analýzy rozdělit do třech kategorií: • jednoduché výpisy – data, která jsou výsledkem analýz, se zobrazí ve formě textového výpisu či formou tabulky • grafické zobrazení – v tomto případě se data zobrazí formou grafu, který může být zobrazený dvojrozměrně (2D) nebo třírozměrně (3D). Podle typu použitých grafických zobrazovacích prostředků můžeme navrhovat sloupcové grafy, koláčové grafy apod. • vizualizace dat – prakticky každá množina dat poskytuje informace k popisu nějakého objektu, jevu, časové závislosti atd. Na základě těchto zákonitostí můžeme zdokonalit grafické zobrazení výsledků analýzy V mnohých starších řešeních je architektura BI procesů budována poměrně chaoticky buď metodou velkého třesku, popřípadě neustálým doděláváním nových výstupů dat. Data jsou i po prvotní konsolidaci do datového skladu umístěna v různých typech zdrojů, v relačních databázích nebo kostkách. U takového způsobu ukládání dat docházelo velmi často k duplicitám. Například podklady pro vytvoření dimenzí jsou jednak v relační, vysoce normalizované produkční OLTP databázi, ale i v datovém skladu, kde jsou už částečně vyextrahovaná data v tabulkách faktů a dimenzí. Duplicitní byla nejen data, ale i modely. Jeden model slouží pro datový sklad, jiný pro OLAP, jiný pro generování reportů prostřednictvím reportovacích služeb. Business rules Návrhář orchestrací spolu s BizTalk mapovacím nástrojem jsou efektivním způsobem jak definovat obchodní procesy a používat obchodní pravidla. Někdy je užitečné, mít způsob jak předchozí pravidla měnit. K umožnění této akce poskytuje BizTalk nástroj nazvaný business rule composer, který umožňuje obchodně orientovaným uživatelům přímo vytvářet a modifikovat množinu obchodních pravidel. Tyto pravidla jsou vytvořeny a volány přímo. Tato technologie je zejména užitečná z toho důvodu, že vývojář musí nejdříve navrhnout orchestraci i modifikovat jednotlivé konstrukty, po té celou aplikaci vytvořit, nainstalovat, popřípadě modifikovat. Jakmile

6.2

MS BizTalk Server

50

jsou jednou pravidla vytvořena, není možné je posléze měnit. Toto však business rules umožňuje, pozdější modifikace však lze provádět bez rekompilace nebo restartování systému, či jiných podstatných zásahů. Jediné co je třeba, je změnit vyžadované pravidlo a nastavit novou množinu těchto pravidel. Efekt je okamžitý. Tyto pravidla mohou být upravovány manažery a ostatními zainteresovanými osobami v oblasti obchodu a není nutný zásah vývojáře či jiného technicky zdatného uživatele. Pokud chceme vytvořit obchodní pravidla, nejdříve je nutné definovat slovník pro specifikace pravidel. Každý výraz ve slovníku poskytuje uživatelsky přívětivý název pro nějakou informaci. Každý z těchto výrazů může být nastaven na určitou konstantu, nebo může být mapován na konkrétní element či atribut z nějakého XML schématu. Jakmile máme vytvořeny slovníky dále je třeba vytvořit policy (metody), které používají slovníky. Každá metoda může obsahovat jeden nebo více obchodních pravidel. Pravidla užívají výrazy definované ve slovnících spolu s logickými operátory. Obchodní pravidlo může definovat, jak hodnoty obsažené přijímaném XML dokumentu by měly ovlivnit hodnoty vytvářené ve výstupním dokumentu, který posíláme. Spolehlivé doručování pomocí přenosového protokolu Nejjednodušší možností je HTTP. Vyskytuje se totiž všude a prakticky všechny bezpečnostní brány na celém světě propouštějí volání ve vrstvě HTTP bez jakýchkoli problémů. Není však možné se domnívat, že naši dodavatelé budou mít šanci přijímat požadavky prostřednictvím tohoto protokolu. Pro některé obchodní partnery může být přenášení prostého textu prostřednictvím HTTP velice nepříjemné. Jedno z těchto možných alternativ k protokolu HTTP je protokol FTP (File Transfer Protocol), který požaduje uživatelské ID a heslo. Taková přihlašovací vrstva snižuje riziko příjmu neplatných nebo podvržených zpráv. V případě, že naši obchodní partneři neprovozují svoji infrastrukturu na serverech FTP, s velkou pravděpodobností budou chtít využít možností elektronické pošty. Server BizTalk by měl být schopen odesílat zprávy cestou protokolu SMTP (Simple Mail Transport Protocol). Tyto servery jsou vyprojektovány tak, aby předávaly zprávy elektronické pošty po celé síti Internet. Největším problémem HTTP, FTP, ale i SMTP je to, že nejsou standardně šifrovány. Transport dokumentů EDI dokumenty mohou být směrovány mezi obchodními partnery jako souborové přenosy, přílohy imailů, nebo FTP. Nejběžnější způsobem jedné z přenosu přes sítě VAN operátorů, popřípadě zabezpečených FTP, nebo přímá komunikace s partnery prostřednictvím šifrovaného protokolu AS2.

6.2

MS BizTalk Server

51

VAN VAN operátoři poskytují mnoho služeb, jednou z nejdůležitějších je dle (Beckner, 2007) směrování a kontrola validace dokumentů mezi obchodními partnery. Všechny dokumenty posílané přes VAN operátory jsou trasovány a veškerá historie transakcí je ukládána do databáze, ke které je možno přistupovat pomocí webového rozhraní. Obchodní partner pošle dokument VAN operátorovi, který jej nasměruje dle odpovídajícího příjemce, který je uložen v obsahu hlavičky zprávy. Pokud nelze příjemce určit, nebo jsou data přijata operátorem nekorektně, operátor tyto data označí jako špatná a zastaví zpracování. V závislosti specifikace požadavků na doručování dokumentů, může být VAN architektura implementována jako FTP server, který je organizován pomocí přihlašovacích údajů a je rozdělen tzv. mailboxy. Jednotliví partneři se mohou přihlašovat a vytvářet zde soubory, organizovat je atd. Jak jsme již poznamenali, každý VAN operátor disponuje určitým webovým rozhraním, které umožňuje obchodním partnerům se přihlásit a detailně si prohlížet trasování dokumentů, včetně detailů o uskutečněných transakcích a zda-li byla transakce úspěšně dokončena. V opačném případě lze dohledat konkrétní chybu a na základě této chyby ji řešit s daným obchodním partnerem. Tyto výpisy slouží jako důkazní prostředek při vyjednávání s partnery za účelem zjištění nebo prokázání příčiny nedoručení dokumentu. To znamená, když na celé trase vznikla od odesílatele nějaká chyba, ale ani jeden z partnerů se k této chybě nehlásí. Díky tomuto nástroji lze lokaci chyby identifikovat a zdokumentovat ji pro obchodního partnera, což je v obchodní praxi velmi důležité. Zabezpečení pomocí AS2 V mnohých B2B prostředích, kde není nutné zabezpečovat komunikaci pomocí VAN operátorů lze s výhodou využít přímou komunikaci na základě AS2 protokolu. AS2 je dle (Beckner, 2007) bezpečný přenos dokumentů používající S/MIME přes HTTPS. Funkcionalita AS2 závisí na kombinaci HTTP adaptéru, AS2 pipeliny, nastavení párty a Windows úložiště pro certifikáty. V souvislosti s AS2 protokolem zmíníme základy zabezpečení systému EDI. Rozlišujeme tyto základní aspekty: • ochrana soukromí – zajišťujeme ji zašifrováním zpráv mezi partnery • ověřování – ověřování lze realizovat prostřednictvím digitálního podpisu, který umožňuje zjistit totožnost příjemce i odesilatele • integrita – je zajištěna pomocí kontroly algoritmu HASH v podepsané zprávě příjemce, tato zpráva se navrátí • absence odmítnutí – doručení každé zprávy je potvrzeno odpovědí Tok pracovních operací Po přijetí dokumentu BizTalk musí dojít k určitým událostem. Na prvním místě je třeba rozložit dokument na různé části tak, aby aplikace mohla zjistit, o jaký druh

6.2

MS BizTalk Server

52

jde. Aplikace musí získat přístup k informacím, uloženým v polích kontextových proměnných. Směr komunikace Dokumenty BizTalk lze generovat celý den. V případě uzavření dohody s některými obchodními partnery mohu stanovit, že dokumenty budou odesílány v transakcích jen jedenkrát týdně v určenou hodinu, nebo jen určité dny v měsíci. Server BizTalk je schopen doručení samostatných dokumentů BizTalk označit. Vyžaduje-li to obchodní vztah, měl by také dokázat odesílat dokumenty obchodním partnerům v dávkách. Zasílání zpráv Zprávy můžeme svým obchodním partnerům odesílat několika způsoby, buď pomocí synchronní nebo asynchronní komunikace. Jakmile tuto zprávu zhotovíme, musíme ji vložit do obálky charakteristické pro daný typ transportu, abychom ji mohli odeslat. Server BizTalk by měl usnadňovat odesílání zpráv v synchronním režimu. V režimu synchronní komunikace odesílá server dokument jinému serveru BizTalk a čeká na odezvu. To je nejvýznamnější požadavek a jedná se o primitivní způsob odesílání zpráv. Naše aplikace může však odesílat desítky, či stovky dokonce tisíce zpráv. Je neefektivní zajišťovat potvrzení okamžitě, lépe je mít možnost asynchronního odesílání zpráv. Pod názvem zasílání zpráv (messaging) chápeme zasílání zpráv mezi počítači. Zpráva XML může mít podobu balíčku obsahujícího obchodní data, jako je faktura, objednávka popřípadě lékařský záznam. Může také být požadavkem na určitý typ služby, kterou vzdálený počítač poskytuje. Zasílání zpráv je výborným prostředkem pro tento typ komunikace, protože XML pro tvorbu struktury předávaných informací v podobě zpráv nezávislých na konkrétním systému. Nespoléhá se na žádné datové formáty, dostupné pouze v určitých prostředích, ani na volání objektů těchto prostředí. Posílání zpráv je hlavní funkcionalitou zajišťovanou prostřednictvím BizTalk Serveru. Dle (Beckner, 2006) mohou být rozděleny do 2 kategorií, příjímané zprávy a odesílané zprávy. Vyjmenujme si následující seznam objektů zahrnutých do procesu příjímání zpráv: Receive location – umožňuje vyvolání zprávy ze specifického umístění jako jsou přijímací adaptéry (častěji užíváme přímo anglický ekvivalent receive adapters) a přijímací pipeliny. • Receive adaptéry – definují umístění a metody přijímání zpráv (existují souborový adaptér, MSMQ, SQL a další) • Receive pipeliny – umožňují dekódování, disasemblování a validaci zprávy oproti schématu. Rovnež umožňují rozpoznání party. Vlastní naprogramované pipeliny mohou rovněž obsahovat vlastní logiku vyžadovanou potřebami zákazníka.

6.2

MS BizTalk Server

53

Adaptéry Souborový adaptér – umožňuje čtení a zápis souborů do Windows souborového systému. Velmi často se stává, že aplikace přistupují k souborovému systému i přes to, že je sdílen vzdáleně po síti. HTTP adaptér – umožňuje posílání a příjem informací prostřednictvím webových služeb v BizTalk serveru, což umožňuje v jednom adaptéru nastavit více URL adres, které umožňují poslat data více partnerům v případě jejich kopií. SMTP adaptér – umožňuje posílání zpráv užitím SMTP protokolu. Pro identifikace příjemce se používá standardní e-mailová adresa. SQL adaptér – adaptér umožňuje čtení a zápis informací z SQL Server databáze. FTP adaptér – adaptér umožňuje výměnu souborů mezi BizTalk a FTP servery. Pipeliny Proces zpracování zpráv začíná v BizTalku v komponentách nazývaných pipeliny, výstupní dokumenty se zpracovávají prostřednictvím přijímací pipeliny, zatímco výstupní dokumenty jdou přes odesílací pipelinu. Celé jádro BizTalk je založeno výhradně na technologii XML. Proto je třeba zabezpečit, aby v případě vstupních dokumentů, které jsou v jiném formátu než XML, například EDI, byly přeloženy pomocí vhodné komponenty pipeliny do XML tvaru. Další komponentou, která může být použita v pipelinách je rozpoznávání odesílatele, či příjemce. Toho lze využít u integračních projektů s více samostatnými partnery, ale v našem případě se toto směrování děje pomocí předem nastavených parametrů, takže tato komponenta není použita. Pokud vývojář má nějaký specifický požadavek na příjem dat, je možné si vyvinout speciální komponentu v .NET technologii a začlenit ji do projektu. Nejdůležitější komponenty užívané v pipelinách jsou: • dekódovací komponenta – umožňuje dekódovat MIME, nebo jiné zabezpečené formáty, které nám jsou posílány například pomocí elektronické pošty • disassembler komponenty – jako je disassembler pro soubory s plochou strukturou, které umožňují tyto soubory překonvertovat do tvaru. Tyto soubory mají poziční uspořádání, kdy každý záznam má stejnou délku spolu se strukturou, nebo obsahují určitý oddělovač, separující jednotlivé záznamy v souboru • XML disassembler – parsuje vstupní zprávy, které jsou již v XML tvaru • validační komponenta – zajišťuje otestování, zda je zpráva validní Receive porty – seskupují jednu nebo více receive lokací a definují transformaci nebo mapování té konkrétní zprávy přijaté receive portem. Řazení do front BizTalk má také možnost zařazovat zprávy do front, aby se mohl plynule přemísťovat k další úloze. Vzdálené řazení do front je velice praktické, protože přemísťuje zpracování detailů přenosu na specializovaný server. Požaduje však bezchybný mechanismus, kterým by bylo možné odeslat stavové informace zpátky na server

6.2

MS BizTalk Server

54

BizTalk. Tímto mechanizmem je například produkt MQ od firmy IBM. MQ – zajišťuje spolehlivou a osvědčenou páteřní komunikaci pro SOA, umožňuje transport dat pro více účelů. MQSeries podporuje mnoho platforem. Umožňuje programům komunikovat navzájem napříč počítačovými sítěmi s odlišnými komponenty jako jsou procesory, subsystémy, operační systém a komunikační protokoly. MQSeries využívá konzistentní aplikační programové rozhraní na všech platformách. Obrázek ukazuje hlavní části MQSeries běhu aplikace. Program volá MQ API, což je Message Queu Interface (MQI). Zpráva se sestává ze 2 částí: • data která jsou posílána jedním programem druhému • popis zprávy nebo hlavička zprávy Popisovač zprávy identifikuje zprávu pomocí Message ID a obsahuje kontrolní informace, taktéž nazývané atributy, jako jsou typ zprávy, datum vypršení platnosti, korelační ID, priorita a název fronty pro odpověď. Zprávy mohou mít velikost do 4 MB nebo 100 MB, v závislosti na použité verzi MQSeries. MQSeries podporují maximální délku zprávy 100 MB, proto je nutné při návrhu systému s tout restrikcí počítat. Trasování dokumentů a sledování aktivity V prostředí řazení zpráv front je velice potřebné, aby se v případě problému dostala příslušná informace zpátky na server. Jestliže se stane a přenos dat bude přerušen, server musí být informován. Jedině tak je možné pokusit se o opětovné odeslání dat, popřípadě stornování transakce. Je také požadováno, aby obsluha měla možnost informovat se na stav příslušné zprávy a tak získat statistické informace o procesech. Server BizTalk obsahuje důsledně propracované informace o testování transakcí, jako jsou: • určování, zda byl dokument doručen úspěšně doručen • dotazování na trasovací databáze na dokument, obchodního partnera nebo aktivitu přidělování časových razítek Všechna tato data by měla být dostupná po celou dobu životnosti dokumentu. Chceme-li však tvořit dodatečné sestavy nebo zprávy o transakcích nebo uplatňovat jakékoli pozdější nároky, vztahující se k transakci, měli bychom je umět uchovávat též později. Tyto funkce jsou zajištěny pomocí nástroje HAT. HAT Toto uživatelské rozhraní trasuje tok dokumentů a monitoruje jejich aktivity během jejich zpracování na serveru. Je určeno pro dvě hlavní skupiny uživatelů: obchodní analytiky a správce systému. Obchodní analytici používají trasování dokumentů a jejich aktivit monitorování, analyzování a vytváření interních obchodních strategií. Zásluhou strategie vyhledávání a ukládání důležitých, uživatelsky definovatelných informací, mohou systémoví analytici sledovat a analyzovat vyčerpávající informace o obchodních operacích. Správci systému tento mechanismus využívají k definování

6.2

MS BizTalk Server

55

rozsahu trasování dat, stanovují možnosti protokolování a nastavení údržby a v neposlední řadě analyzují metody odstraňování problémů. Pokud potřebujeme si vypsat určitou selekci odeslaných, či přijatých zpráv, lze tuto selekci provést pomocí tvorby SQL dotazu, který nám vybere potřebné správy. Nsáleduje příklad dotazu, který vypíše všechny přijaté zprávy za posledních 24 hodin. declare @Timestamp as datetime set @Timestamp = GETUTCDATE() - 1 declare @Receive as nvarchar (100), @Send as nvarchar(100) SELECT @Receive = strStatus FROM [dbo].[dta_MessageStatus] WHERE nMessageStatusId=0 SELECT @Send = strStatus FROM [dbo].[dta_MessageStatus] WHERE nMessageStatusId=1 SELECT [MessageInstance/SchemaName], [Event/Direction], dateadd(minute, @UtcOffsetMin, [Event/Timestamp]) as [Timestamp], [Event/Adapter], [Event/URL], [Event/DecryptionCertificate], [Event/Signature], [ServiceInstance/InstanceID], [ServiceInstance/ActivityID], [MessageInstance/InstanceID], [Event/EventID], [MessageInstance/PartCount], [MessageInstance/Size], [Event/Party], [Event/Port] FROM dbo.dtav_MessageFacts mf WITH (READPAST) WHERE [Event/Direction] = @Send AND [Event/Timestamp] > @Timestamp AND [MessageInstance/InstanceID] in ( SELECT mioe.uidMessageInstanceId FROM dbo.dta_MessageInOutEvents mioe WITH (READPAST) GROUP BY mioe.uidMessageInstanceId HAVING count (distinct cast (mioe.uidActivityId as varchar(36))) = 1 AND min((mioe.nStatus-1)*(mioe.nStatus-1)) = 0 AND min(mioe.dtTimestamp) > @Timestamp ) ORDER BY [Event/Timestamp] desc

6.2

MS BizTalk Server

56

Dalším nástrojem je BizTalk Administration Console je modul programu MMC (Microsoft Management Console), který se používá ke správě a údržbě serveru nebo skupiny serverů. S použitím této aplikace lze tvořit hosty, přiřadit je na konkrétní fyzický stroj (PC, server), spouštět a zastavovat ochestrace, sledovat nedoručené zprávy, prohlážet jejich obsah atd. BAM Vzhledem k tomu, že je technologie BizTalk navržena ke správě obchodních vztahů, měl by být server BizTalk a jeho činnost v rukou obchodníků, nikoliv informatiků. To znamená, že by měly být jak všechny aspekty navazování a vytváření obchodních vztahů, tak všechny aspekty mapování dokumentů dostupné obchodníkům užívajícím systém, a to i přes to, že tito uživatelé nemusí být nutně programátoři. Při implementaci serveru BizTalk je nutné zohlednit mnoho aspektů integrace. Týká se to v podstatě každé části programového kódu, jenž jakýmkoli způsobem ovlivňuje chod starších aplikací. Informatici by se měli zcela podílet na vytváření uživatelského rozhraní nebo úponů, které integrují starší systémy. Nepředpokládá se, že budeme volat programátora k vytvoření každého nového obchodního vztahu s novým zákazníkem. Vlastníci obchodních procesů by měli být schopni založit a udržovat obchodní vztahy, zjišťovat vstupní a výstupní převody dokumentů, upravovat datové struktury (pokud tyto změny neovlivní chod celého systému) a generovat zprávy a sestavy bez ohledu na aktuální stav systému, nebo zájmy obchodních vztahů. Takový systém musí být dosažitelný též pro vzdálené uživatele. Proto tito uživatelé musí mít k němu zabezpečený přístup BAM.

7

7

IMPLEMENTACE SYSTÉMU

57

Implementace systému

Integrace systému spočívá v implementaci procesu odeslání požadavku na dostupnost letů (Air availability request) a rezervačního požadavku (Booking Request). Za typ zprávy byl zvolen standard OTA (Open Travel Alliance) vyměňovaný z a do cestovní kanceláře Travel 2002, která je v roli prostředníka mezi velkým poskytovatelem služeb z oblasti cestovního ruchu – společností AMADEUS a společností SABRE, zabývající se vyhledáváním nabídek cestovních, leteckých společností. Tato společnost je schopná v koncovým zákazníků nalézt nejvhodnější let, který splňuje naše požadavky a to za nejlepší cenu. SABRE využívá webové služby, konkrétně kombinaci SOA a XML, které umožňují přístup do sítě SABRE. Tyto XML služby splňují právě standard OTA. Koncový zákazník (cestovní kancelář Travel 2002) si u společnosti SABRE zřídila účet, pro poskytování těchto služeb.

Obr. 12: Architektura integrovaného systému

ESB je široce rozšířena v oblasti implementace podnikové infrastruktury, umož-

7


58

ňující použití webových technologií SOA. Je to soubor architektonických vzorů, založený na tradičních podnikových integracích, střední vrstvě orientované na přenos zprávy, .NET, integrace hostitelských systémů. Tato technologie se skládá z několika spolupracujících komponent, které podporují a implementují podnikové prostředí pro výměnu dat. Společnosti jako AMADEUS, si přejí automatizovat systémy na objednávání letenek, vyměňujícími EDI zprávy s jejich externími partnery a musí vyhovět požadavkům standardu OTA pro cestovní kanceláře za účelem úspěšné výměny těchto zpráv. Tyto společnosti používají komputerizované systémy již několik desetiletí a stále si chtějí tyto tradiční systémy zachovat a integrovat je s novými technologiemi a standardy. Systémy založené na EDI standardech jsou stále rozšířené, jelikož EDI je více flexibilní a dle některých odborníků i lepší než XML. Problémem však je, že EDI integrace není tak adaptabilní jako použití technologie XML, tudíž malé společnosti které jsou v roli dodavatelů společnostem středním, či velkým si ji většinou nemohou dovolit. Stejně je tomu tak i u naší cestovní kanceláře, která chce komunikovat s leaderem AMADEUS z oblasti cestovního ruchu, který stále používá zaběhlé standardy EDI, ale nemůžeme zajistit přímou integraci EDI na svojí straně, ale použít integraci EDI na straně AMADEUS. Obecně vzato však i tyto společnosti postupně přecházejí na modernější XML, ale děje se tak velmi pozvolna, na základě jejich aktuálních potřeb ale mezitím užívají přemostění technologií v podobě integrace EDI versus XML. Komunikace EDI do BizTalku je přímá přes VAN operátora. Celý obchodní proces, který integrujeme, je představována centralizovaným procesem objednávání letenek, který je vždy řešen právě s jednou cestovní kanceláří. Cestovní kancelář si přeje shromáždit informace o dostupnosti letenek pro prodej svým zákazníkům a zpětně objednat vhodný let. Veškerá výměna informací se děje prostřednictvím standardu UNICORN, což je podmnožina UN/EDIFACT standardu specializující se na plnění požadavků v oblasti cestovního a turistického průmyslu. Prvním cílem naší integrace je zajistit posílání XML zprávy standardu OTA (Request) do společnosti AMADEUS a přeložit jejich korespondující odpověď zpět do formátu UNICORN EDI. Tato společnost si přeje rozšířit jejich existující integrační architekturu tak, aby jejich partneři mohli jednoduše komunikovat přes rozhraní jejich EDI systému. Rozšíření jejich stávající hierarchie služeb pomocí BizTalk technologie umožňuje vyřešit EDI integrační požadavky. Následující diagram prezentuje, jak této iniciativy lze dosáhnout. Celá komunikace začíná na UNICORN (EDI) Receive Pipeline komponentě, viz. následující obrázek. Máme k dispozici UNICORN – Request, což je požadavek, který přijímá BizTalk. Tento Request posílá AMADEUS v EDI formátu cestovní agentuře, která je schopna však přijímat jen OTA XML standard ve svém IS, kterým je my SAP (Travel Agency Client). Proto musí Amadeus transformovat UNICORN EDI na OTA XML. Amadeus disponují svým ESB (Enterprise Service Bus) řešením (upro-

7


59

Obr. 13: UNICORN Přijímací pipeline

střed je ESB pipeline sběrnice, napojené na původní systémy + BizTalk), který je rozšířen o architekturu BizTalk, jelikož BizTalk je schopen bez problému zajišťovat webové služby, včetně SOA. Nicméně BizTalk je jediná komponenta architektury, který může komunikovat v EDI formátu, může být napojen na všechny koncové společnosti využívající EDI jako je Amadeus. K tomu, abychom byli schopni přeložit UNICORN EDI zprávu do její relevantní OTA reprezentace, potřebujeme mít definováno XML schéma pro každý typ zprávy, které se této transformace účastní. V případě OTA toto požadované schéma již existuje a je k dispozici organizací OTA. Pro UNICORN potřebujeme vytvořit XML schéma, které reprezentuje typ UNICORN zprávy ve formátu XML. BizTalk rozkládá, nebo skládá UNICORN EDI textově založené zprávy, nebo soubory s plochou strukturou do XML mezistupňového formátu pro další zpracování jako je překlad. Jakmile je definován typ zprávy, zpráva musí být přeložena z jednoho typu zprávy do druhého. BizTalk umožňuje tuto transformaci pomocí mapovacího nástroje BizTalk mapper. V případě datového toku pro air enquiry request, vydáme UNICORN AIENRQ request zprávu, kterou může BizTalk přeložit do relevantní FS OTA AirAvailRQ zprávy. Tato zpráva obsahuje požadavek, na dostupné lety, které

7


60

Obr. 14: UNICORN AIENRQ XML Schéma

jsou k dispozici. Tato přeložená zpráva je dále poslána cestovnímu agentovi, který zašle více specifickou žádost do sítě SABRE. Amadeus rovněž zpracuje FS OTA AirAvailRS (Response) odpověď, která už specifikuje o jaký let máme zájem. FS OTA AirAvailRS je opět přeložena BizTalkem do relevantní UNICORN AIENRS zprávy a přeposlána do páteřního EDI systému. Problém může nastat, když si představíme, že zpráva s odpovědí (Response) může být přijata v jakémkoliv následném čase od odeslání požadavku (Request Message) a nemusí být nutně v pořadí, v jaké byly tyto požadavky vydány. Zpracování zpráv musí být řízeno k zajištění potřeb pro naše specifické obchodní aktivity. BizTalk nabízí výkonnou platformu pro business management operace založeném na XLANG, který je podobný ostatním business processing standardům jako je například BPEL. Následující orchestrace vyjadřuje celý data flow a jak je implementován. Jelikož je struktura značně graficky rozsáhlá a složitá, bude proces popsán dále na bázi dekompozice. Je nutné si uvědomit, že se nejedná o prezentační a dokumentační záležitost, jako je UML, ale o implementaci. Proto obrázek celé orchestrace ještě jednou přikládám v příloze A práce, za účelem lepší čitelnosti ve větším formátu zobrazení. Začátek orchestrace je nahoře, konec a dole a mezi tím jsou umístěny jednotlivé

7


61

Obr. 15: Diagram mapování BizTalk AIENRQ to AirAvailRQ

symboly akcí (shapes). Na levém a pravém okraji jsou vstupní a výstupní porty, které jsou napojeny na přijímací a odesílací pipeliny. Uprostřed je vlastní tělo orchestrace, obsahující samotnou logiku. Obsahuje paralelní akci, která jako celek zajišťuje asynchronní komunikaci a naslouchání odpovědi. Obchodní proces tedy začíná přijímacím (Receive) modulem, který přijímá EDI UNICORN zprávu. Tento modul je nastaven jako aktivní a tím spouští celou instanci orchestrace. V našem obchodním procesu ale potřebujeme mít zajištěno více způsobů, jak zprávy přijímat, či odesílat. Proto máme více portů, které orchestrace sleduje. Toho je dosaženo použitím modulu Listen v levé větvi orchestrace, kterou vidíme na následujícím obrázku. Tato orchestrace dále volá pomocnou orchestraci, zajišťující komunikaci se společností Sabre, a to prostřednictvím webových služeb. Agregace asynchronních zpráv je běžným způsobem, jak umožnit požadavek, kdy vícenásobně vydané zprávy s žádostmi a vícenásobné odpovědi jsou agregovány a napojeny zpět na jejich původní žádosti. Toto je úkolem pravé strany orchestrace, jak prezentujeme na následujícím obrázku.

7


Obr. 16: Orchestrace, celá struktura integrace

Obr. 17: Orchestrace, levá část, zpracování OTA XML zpráv

62

7


Obr. 18: Pomocná orchestrace – Komunikace pomocí webových služeb

Obr. 19: Orchestrace – Agregace asynchronních zpráv

63

8

8

NASAZENÍ A ÚDRŽBA SYSTÉMU

64

Nasazení a údržba systému

Jakmile je systém vyvinut a připraven pro použití, je třeba nejprve otestovat jeho funkčnost. První fáze otestování lze provést již ve fázi lokálního vývoje na development prostředí ve Visual Studiu, kde se orientujeme na otestování funkčnosti mapy, dále lze ladit XSLT skripty pomocí věstavěného výkonného debuggeru. Úplnnost vyvinutého cyklu, představují datový tok mezi jednotlivými subjekty obchodního procesu, je však možno otestovat až nasimulováním tohoto procesu, které se děje v tzv. Quality Assurance prostředí, ve zkratce QA. Tento proces vyžaduje koordinaci pověřené osoby, tzv. koordinátora, který většinou celý integrační projekt zadává a ve fázi otestovaní zajišťuje komunikaci a nastavení konfigurací se všemi zúčastněnými stranami. Je třeba zajistit konfiguraci datových kanálů, připravit zákazníky, provést komunikaci s VAN operátory a nastavit příslušné komunikační cesty pro přenos zpráv, ať už se jedná o EDI, či XML. Koordinátor rovněž zajišťuje testovací data, pokud jsou k dispozici. Výstupem této fáze je kompletní test projektu v prostředí QA (Quality Assurance). Na základě korektně provedených testů, lze aplikaci naistalovat na tzv. Produkční prosředí, které je určené výhradně pro ostrý provoz a testy se zde dělají jen výjimečně, a to s velkým uvážením. Testování aplikací Testování aplikací v BizTalku představují dva procesy, testování mapy a druhý je testování datového proudu, respektive funkčnosti datového proudu. K testování mapy je nutné mít připravenu testovací instanci, testovací data zhodnotit výsledek výstupu s očekávaným obsahem výstupu, abychom tímto potvrdili funkcionalitu správnost celé mapy. Testování i datového proudu završí zpracování správy, završí cyklus zpracování zprávy, který začíná od doručení, správnou konfigurací partnera BizTalk směrování podpisu zprávy až po správný výstup EDI. Parametry při testování mapy se nastavují ve vlastnostech mapy ve vývojovém prostředí. Jako vstupní instanci i pro testování mapy použijeme konkrétní soubor, který jsme si připravili a dále je třeba nastavit typ dat,pomocí kterých testujeme. To znamená, jestli se jedná o SML data nebo nějakou Flat File datovou strukturu. Mapy, které transformují zprávy EDI, potřebují EDI prezentovány v XML v podobě. Jestliže nemáme k dispozici mezistupní XML zprávu, která je výstupem z EDI ASEMBLERU, je nezbytné provést tzv. zpracování EDI zprávy BizTalk mezistupňovou EDI vygenerovat. Generická aplikace, pro převod EDI do XML, by měla být nakonfigurována pro použití FILE adaptéru a standardní Microsoft Pipeliny. Výsledkem tohoto procesu je mezistupní EDI XML správa která je dostupná v nástroji nazvaném HAT. Použitím HAT, je možno si zvolit libovolnou selekci zpráv, ať už se jedná o zprávy přijaté či odeslané. Tuto selekci provést pomocí tvorby SQL dotazu, který nám vybere potřebné zprávy. Pokud potřebujeme testovací instanci, která se skládá z více částí, je třeba ji složit z potřebných komponent.

8


65

Škálovatelnost V dnešní době by měly být škálovatelné všechny systémy. Dobrým výchozím bodem je postavení našeho systému na infrastruktuře škálovatelného transportního protokolu, jakým je například HTTP. Umístění obchodní logiky do střední vrstvy, k níž je možno získat přístup interně prostřednictvím intranetu a klientské vrstvy, je další způsob, jak z pohledu vnitřního uživatele škálovatelnost systému zajistit. Server BizTalk by měl být schopen ošetřit očekávaný počet denních transakcí vynásobený růstovým faktorem. Jestliže však plánujeme dopředu, neměli bychom se zaměřovat na počet společností, s nimiž obchodujeme dnes, ale spíše na potenciální počet společností, s nimiž budeme obchodovat v budoucnosti. Bereme-li v úvahu rychlý rozvoj sítě WWW v krátkém časovém úseku, pro který byla dostupná, lze si snadno domyslet, jak může vypadat předpokládaný nárůst počtů elektronických informací mezi obchodními systémy (B2B). Malé náklady na používání technologií XML a BizTalk – ve srovnání s náklady a složitostí tradiční elektronické výměny dat (EDI) – jsou předzvěstí, že i mi budeme v budoucnu ke komunikaci s většinou současných obchodních partnerů využívat technologii elektronického doručování zpráv, která bude postavena na standardech nezávislých na platformě, jakými jsou XML a BizTalk. Vzhledem k velice nízkým nákladům na elektronické transakce budeme pravděpodobně taktéž schopni navazovat vztahy s více obchodními partnery. Přínos a ekonomické zhodnocení systému Jakýkoliv integrovaný IS by měl být dostatečně pružný na to, aby mohl vyhovět rozdílným požadavkům různých obchodních partnerů. Měl by být schopen přizpůsobit se měnícím se podmínkám. Pokud třeba náš současný zákazník s námi momentálně komunikuje prostřednictvím dokumentů EDI a rozhodne se pro schéma průmyslového standardu XML, měli bychom být schopni měnit svůj systém tak, aby tomuto požadavku vyhověl bez nutnosti obnovování partnerské smlouvy. Veškerá historie daného zákazníka zůstane neporušena; změní se pouze způsob komunikace. Systém by měl dokázat ošetřit všechny budoucí obchodní změny. Měl by být natolik operativní, aby mohl udržovat informace o dvou zákaznických společnostech, které se později sloučí, stejně tak jako o jedné společnosti, která se náhled rozdělí. Musí být schopen ošetřit také splynutí nebo spojení společnosti nebo, co je pravděpodobnější, změny organizační struktury. Návratnost investice Použitím firmy Amadeus a integrováním s vlastním SAP systémem můžeme ušetřit třetinu cestovních nákladů. Návratnost investice a efektivnost využití tohoto řešení je díky těmto faktorům: • SOA – integrace systému SAP se systémem Amadeus využití webových služeb • automatizace – veškeré procesy jsou automatizovány a jsou redukovány nepřímé náklady generované podporou konzultanty administrátory a dalšími

8


66

• tvorba pravidel – mnohých úspor lze dosáhnout díky nastavení obchodních pravidel, kdy si přímo provádíme restrikci na požadovaný produkt, tzn. v našem případě omezení na finanční náročnost letu (minimální, maximální cena), požadovaná lokalita, oblast, přestupní uzly popř. preferované letecké společnosti či další faktory jimiž vhodnou kombinací lze ušetřit nemalé finanční prostředky • lepší možnosti vyjednávání – díky obrovským možnostem statistické analýzy a reportování v systému SAP, máme vždy pod kontrolou veškeré souhrnné údaje za určité období. Můžeme provádět analýzy nejčastějších destinací, finanční analýzy atd. Díky výsledkům sběru těchto informací lze prostřednictvím systému Amadeus žádat obchodní partnery o slevy, diskonty při vyjednávání.

9

9

TREND DO BUDOUCNA

67

Trend do budoucna

Mezi hlavní trendy v oblasti integrace se v posledních letech dostává přesun od dávkově orientovaného zpracování na více efektivnější výměnu dat online. Dochází rovněž k replikaci dat v reálném čase mezi heterogenními aplikacemi. Samotný proces zpřístupnění systému a aplikací pro samotnou integraci již není v současné době tak nutné. Děje se tak v případě, kdy integrujeme již zastaralé aplikace, ke kterým nelze zajistit vhodnou konkrétní implementaci z důvodu absence jakékoliv dokumentace, či možné komunikace s tvůrcem původního softwaru. Dalším trendem je tzv. P2P integrace, tj. komunikace každý s každým. Nepříjemnou skutečností této architektury jsou však vysoké náklady. Vhodnější je použití centralizované IT architektury a dosáhnout stavu, kdy integrující prvek provede sjednocení těchto aplikací. Díky tomu dosáhneme vyšší použitelnosti i lepší využitelnosti daného řešení. Tento koncept je představován architekturou SOA, která významným způsobem napomáhá ke zvýšení flexibility IT. Je dobré poznamenat, že využití SOA není omezeno pouze na implementaci prostřednictvím webové služby, jelikož www architektura není nutnou podmínkou. Zhruba od roku 2000 se v oblasti elektronické výměny dat obrovským způsobem rozšířila technologie XML. V této době většina analytiků a dodavatelů IT služeb, předpovídala této technologii obrovský rozmach v závislosti na ústupu technologie EDI. Toto se však nestalo i přes to, že provoz veškerých XML B2B aplikací podstatně narostl, nedošlo k úplnému vytlačení obchodních automatizovaných procesů na bázi EDI. Ve skutečnosti, pokud se podíváme na studii agentury FORESTERRESEARCH, technologie EDI má stále vedoucí postavení v oblasti B2B, dokonce reprezentuje 80-90 % celkového objemu a vzrůstá každoročně cca o 3 až 5 procent. Webové portály však většinou komunikují s partnery, kteří nepoužívají EDI. Pokud firmy chtějí nadále používat EDI, což je dle (Forrester Research, 2006) 45 %, je třeba toto řešení zaintegrovat a v praxi vidíme, že se tak děje čím dál více.

10

10

ZÁVĚR

68

Závěr

Pro zhodnocení výsledků práce vycházíme z cílů a předpokladů, které jsme si stanovili. V práci byl splněn zásadní cíl, a to je realizace integrace IS cestovní kanceláře s heterogenními systémy obchodních partnerů. V práci byla prezentována analýza, architekutura koncepce, technická realizace včetně implementace. Za účelem splnění dílčích cílů si autor nastudoval rozsáhlou problematiku systémové integrace a elektronické výměny dat EDI včetně mnoha norem, postupů a technologického know how, které autor získal v praxi. Toto osvojení teoretických znalostí a zvýšení zkušeností při realizace řešení bude možné zužitkovat při pracovních projektech zákazníků. Nutno rovněž podotknout, že řešená problematika není u nás u odborné veřejnosti až tak rozšířená, obzvláště její technická realizace. Není aktuálně podrobně v literatuře zmapována a bylo nutné pracovat zejména s cizojazyčnou literaturou. Úspory nákladů díky realizaci jsou rovněž hmatatelné a tyto faktory v práci byly zmíněny. Toto ocení nejvíce koncoví zákazníci – klienti. Práce také ověřila použitelnost nových technologií, jako je BiTalk a vhodnost nasazení pro integraci. V případě hodnocení dostupných integračních řešení je při výběru toho nejlepšího pro konkrétní oblast využití důležité stanovit vztah mezi kvalitou spolu s efektivností a dobou, během které se může změnit užitná hodnota v porovnání s konkurenty. Potřebujume odhadnout časový úsek, během kterého se nám podaří naši finanční investici či úsilí amortizovat. V oblasti rozhodování při nákupu a vývoji informačních technologií můžeme mít napaměti i tzv. Moorovo pravidlo, které říká, že komplexnost nejlepšího integrovaného obvodu na trhu (který udává nejvyšší úroveň výkonu v daném okamžiku dostupného výpočetního systému) se každých 18 měsíců zdvojnásobí. Toto pravidlo spolehlivě platí již několik desetiletí a můžeme je zcela evidentně aplikovat i v oblasti integrace IS, kde díky tomuto předpokladu je i pro laika patrná neustále se zvyšující komplexnost a složitost integrovaných systémů. Dá se tedy stále do budoucna předpokládat, že integrační platformy, jako je ta, kterou jsem v práci představil z teoretického a praktického hlediska, bude mít stále svoje smysluplné uplatnění.

11

11

LITERATURA

69

Literatura

ARLOW, J. NEUSTADT, I. UML2 a unifikovaný proces vývoje aplikací. Brno. Computer Press, 2007. ISBN 978-80-251-1503-9. Basl, J. Podnikové informační systémy. Přehled nabídky ERP produktů Praha: IDG, 2001. Businessworld č. 3/2001, ISSN 1213-1709. Beckner, M. Biztalk 2006 Recipes - A problem solution approach New York: Apress, 2006. 558 s. ISBN 978-1-59059-711-8. Beckner, M. Pro EDI in BizTalk Server 2006 R2 Electronic Document Interchange Solutions New York: Apress, 2007. 185 s. ISBN 978-1590599358. Jilovec, N. The A to Z of EDI The comprehensive Guide to Electronic data interchange New York: Computer Applications Specialists, 1993. 250 s. ISBN 1-884322-18-2. Juday J. An Introduction to BizTalk 2006 R2 Development. Dostupné na: www.developer.com/xml/article.php/3733521 Dokument ve formátu HTML. [cit. 2009-26-4]. Juřek, M. Moderní integrace aplikací. Praha. Microsoft s.r.o. 2004. Kadlec, V. Agilní programování Brno. Computer Press, 2004. 278 s. ISBN 80-251-0342-0. Konečný, V. Projektování informačních systémů. Brno. Provozně ekonomická fakulta MZLU v Brně, 1996. ISBN 80-7157-241-1. Konečný, V. Integrované informační systémy. Dostupné na: http://akela.mendelu.cz/konecny/isdoc.zip Dokument ve formátu DOC. [cit. 2009-25-1]. Lacko, L. Web a databáze Brno: Computer Press, 2001. 270 s. ISBN 80-722-6555-5. Lacko, L. Business Inteligence v SQL Serveru 2005 Brno: Computer Press, 2006. 391 s. ISBN 80-251-1110-5. Molnár Z. Moderní metody řízení informačních systémů Praha. Grada Publishing, 1992. ISBN 80-85623-07-2. Page-Jones, M. Základy objektově orientovaného návrhu v UML Praha. Grada Publishing, 2001. 365 s. ISBN 80-247-0210-X. Řepa, V. Analýza a návrh informačních systémů Praha: Ekopress, 1999. 403 s. ISBN 80-86119-13-0. Tohamy, N. Ranking Supply Chain Management Tools And Services. Dostupné na: http://www.oracle.com/corporate/analyst/reports/entapps/scm/ forrester-ranking-scm.pdf Dokument ve formátu PDF. [cit. 2009-17-5]. Travis B. E XML a SOAP Programování serverů BizTalk. Praha: Computer Press, 2000. 419 s. ISBN 80-7226-303-X. společnost VAN EasyLink EDI Tutorial. Dostupné na: http://www.icc.net/enUS/oc/icc.net/Resources/

11

LITERATURA

70

EDITutorial/EDIMessage.html Dokument ve formátu HTML. [cit. 2009-13-2]. Vodáček, L. - Rosický, A. Informační management. Poslání, pojetí a aplikace Praha. Management Press, 1997. ISBN 80-85943-35-2.

Přílohy

A

A

UKÁZKA DESIGNU ORCHESTRACE V BIZTALKU

Ukázka designu orchestrace v BizTalku

Obr. 20: Orchestrace, celá struktura integrace

72

B

B

UKÁZKA MAPOVÁNÍ V BIZTALKU – TRAVELERINFO

73

Ukázka mapování v BizTalku – TravelerInfo

Obr. 21: Mapování BizTalk AIBFT to AirBookingRequest - Informace o přepravované osobě

C

C

UKÁZKA MAPOVÁNÍ V BIZTALKU – FULFILLMENT

Ukázka mapování v BizTalku – Fulfillment

Obr. 22: Mapování BizTalk AIBFT to AirBookingRequest - Zaplacení

74

D

D

UKÁZKA MAPOVÁNÍ V BIZTALKU – AIRITINERARY

Ukázka mapování v BizTalku – AirItinerary

Obr. 23: Mapování BizTalk AIBFT to AirBookingRequest - Cesta

75

Systémová integrace IS cestovní kanceláře pomocí MS BizTalk Server

Recommend Documents