Transcription
View metadata, citation and similar papers at core.ac.ukbrought to you byCOREprovided by DSpace at VSB Technical University of OstravaVŠB – Technická univerzita OstravaFakulta elektrotechniky a informatikyKatedra informatikyAbsolvování individuální odborné praxeIndividual Professional Practice in the Company2013Lukáš Satin
Prohlášení studentaProhlašuji, že jsem tuto bakalářskou práci vypracoval samostatně.Uvedl jsem všechny literární prameny a publikace, ze kterých jsem čerpal.Dne: 4.4.2013
PoděkováníRád bych poděkoval týmu ComC za cenné rady v průběhu mé praxe a také RNDr. ElišceOchodkové, Ph.D. za odbornou pomoc a konzultaci při vytváření této bakalářské práce.
AbstraktCílem této bakalářské práce je popsat průběh mé praxe ve firmě Tieto Czech s.r.o. se zaměřením napopis řešení zadaných úkolů. Pracoval jsem na pozici Software Developer v oblasti Nordic ProductPortfolio. Produkty v tomto portfoliu jsou založeny na technologiích Microsoftu. V první části jepopsáno odborné zaměření firmy Tieto Czech s.r.o. a mé pracovní zařazení. Druhá část popisujesoftwarovou architekturu systému. Část třetí pak úkoly, které jsem během praxe řešil. Poslední část sevěnuje zhodnocení dosažených výsledků odborné praxe a zkušeností, které mi tato praxe přinesla.Klíčová slovaTieto, .NET Framework, Microsoft BizTalk, systémová integrace, integrace podnikových aplikacíAbstractThe aim of this bachelor thesis is to describe my experience during the individual professional practicein Tieto Czech s.r.o. Company. My position was a Software Developer in Nordic Product Portfolio.The actual products in this portfolio are based on Microsoft technologies. In the first chapter, Tietocompany and my competence as a Software Developer is described. The second chapter providessome theoretical background required to perform my tasks. The third chapter describes actual tasks Iwas performing during the professional practice. Finally, the last chapter provides a conclusion andbenefits of my work.Key wordsTieto, .NET Framework, Microsoft BizTalk, system integrations, enterprise application integration
Seznam použitých symbolů, zkratek a mmunication CenterEnterprise Application IntegrationEvent Driven ArchitectureEnterprise Service BusExtract, Transform & LoadNordic Product PortfolioRepresentational State TransferService Oriented ArchitectureSimple Object Access ProtocolUtility Business IntegrationsExtensible Markup LanguageXML Schema Definition
Obsah1 Úvod.12 Odborné zaměření firmy.22.1 Tieto Czech s.r.o.22.2 Mé pracovní zařazení.23 Architektura projektu.33.1 Integrace systémů a podnikových aplikací.33.2 Propojení heterogenních systémů na transportní vrstvě.33.3 Druhy systémových integrací.64 Průběh praxe a řešené úkoly.74.1 ComC.74.2 UBI.85 Teoretické znalosti získané během studia uplatněné v průběhu odborné praxe.106 Znalosti a dovednosti scházející studentovi v průběhu odborné praxe.117 Dosažené výsledky v průběhu odborné praxe a její celkové zhodnocení.128 Použitá literatura.13
1 ÚvodTéma mé bakalářské práce jsem si zvolil na základě předchozí zkušenosti se společností Tieto Czechs.r.o., kdy jsem roku 2011 absolvoval kurz Tieto IT Academy – Java & Software development. Spolu spracovním prostředím mě zaujaly především agilní metodiky vývoje. Po zaslání životopisu jsem bylkontaktován a pozván na přijímací pohovor k výběru na odbornou praxi. Na praxi jsem nastoupil vlistopadu 2012. Byl jsem zařazen do týmu podílejícím se na vývoji v oblasti Nordic Product Portfolio.Produkty NPP jsou vyvíjeny na technologiích firmy Microsoft. Jedná se zejména o C# .NETFramework a Microsoft BizTalk.V této práci, rozdělené do čtyř částí, budu popisovat průběh mé praxe v Tieto Czech s.r.o. Vprvní části představím společnost a mé pracovní zařazení. Druhá část popisuje architekturu systému.Část třetí pak úkoly řešené v rámci praxe. Poslední část obsahuje zhodnocení dosažených výsledků azkušeností získaných během praxe.1
2 Odborné zaměření firmy2.1 Tieto Czech s.r.o.Tieto je největší severoevropský dodavatel IT služeb, který poskytuje komplexní služby pro soukromýi veřejný sektor. Společnost Tieto byla založena roku 1968 se sídlem v Helsinkách. Nyní zaměstnává17 000 expertů a působí ve více než dvaceti zemích světa. Čisté tržby společnosti činí 1,8 miliard eurza rok. Akcie firmy jsou obchodovány na burze NASDAQ OMX v Helsinkách a Stockholmu. Roku2001 společnost Tieto vstoupila také do České republiky a roku 2004 otevřela své softwarové centrumv Ostravě. V dnešní době, kdy se počet zaměstnanců společnosti pohybuje okolo 1900, je jedním znejvětších zaměstnavatelů v České republice a největším zaměstnavatelem v Moravskoslezském kraji.Z hlediska počtu kmenových zaměstnanců je česká pobočka třetí největší pobočkou Tieto korporacena světě. První dvě místa zaujímají mateřské země Finsko a Švédsko [1].2.2 Mé pracovní zařazeníVe společnosti jsem vykonával praxi na pozici software developer v týmu ComC, později UBI. Obatýmy řeší integraci a komunikaci produktů v rámci NPP a také produktů třetích stran. Tým ComCvyvíjí produkt se stejným názvem, který slouží jako integrační platforma NPP a je vyvíjen v C# pod.NET Frameworkem. Tým UBI vyvíjí rovněž integrační platformu, ale založenou na MicrosoftBizTalk Server 2010. ComC je interní produkt Tieto a historicky je zastoupen nejvíce ve Finsku. Vostatních zemích se nyní začíná více prosazovat platforma BizTalk, která slouží ke stejnému účelu.Zákazník má však v druhém případě svobodnější volbu ohledně subdodavatelů, protože BizTalk jeprodukt Microsoftu, který lze zakoupit i samostatně.2
3 Architektura projektuProjekt, jehož jsem byl součástí, se zabývá především systémovou integrací a integrací podnikovýchaplikací. S rostoucím počtem různých aplikací používaných v IT společnostech je kladen větší důrazna jejich vzájemnou integraci. Hlavní motivací je koordinovaná komunikace jednotlivých systémůnejen v rámci podniku, ale také mezi různými společnostmi. Produkty samotné nemusí splňovatveškeré požadavky zákazníka. Teprve vhodné propojení těchto produktů začne přinášet určitouhodnotu.3.1 Integrace systémů a podnikových aplikacíSystémovou integraci lze definovat jako [2]:1. Technické propojování heterogenních systémů na nejrůznějších úrovních (hardware,protokoly, databázové systémy atd.);2. Řešení jednoho konkrétního IS/IT projektu, přičemž systémovou integrací rozumímeoptimální sladění projektového a právního přístupu tak, aby bylo dosaženo cílů projektu;3. Dlouhodobý koordinovaný proces řešení IS/IT projektů vycházející ze strategického záměruzákazníka s cílem plnit jeho vyvíjející se požadavky na řízení procesů v organizaci;4. Dlouhodobý koordinovaný proces řešení všech podnikových projektů (nejen IS/IT) s cílemnaplňovat strategický záměr zákaznické organizace.Integrace podnikových aplikací (EAI) je proces koordinované komunikace a propojení softwarovýchsystémů v podniku. Většinou se jedná o snahu napojení zastaralých (legacy) aplikací a databází nanová rozhraní nebo kompletní modernizaci podnikové infrastruktury. Důraz je kladen nadistribuovanou, multiplatformní komunikaci a spolupráci s webovými službami. EAI k naplnění cílůvyužívá prostředky jako objektově-orientované programování, komunikace pomocí standardizovanéhoXML formátu nebo distribuce zpráv pomocí agregace dat do fronty událostí [3].3.2 Propojení heterogenních systémů na transportní vrstvěSložitost integrace závisí na počtu systémů. Nejjednodušším případem je propojení dvouheterogenních systémů pomocí transportní vrstvy, která bude zasílat zprávy pouze ze zdrojového docílového umístění. Řada scénářů ale vyžaduje propojení více než dvou aplikací. U reálných projektů,kdy je integrováno například 10 aplikací, je zapotřebí vytvořit 45 až 90 propojení. Při malém počtuaplikací lze snadno přehlédnout, že se zde jedná o exponenciální nárůst počtu spojů (viz obrázek 3.1).Z hlediska závislosti aplikací jedné na druhé představuje toto těsnou vazbu [4].3
Propojení systémů v integrační vrstvě může mít vazbu těsnou nebo volnou. Těsná vazba senazývá případ, kdy jsou jednotlivé systémy propojeny přímo a naprosto libovolně. Vzniká takkomplexní struktura, která je těžko spravovatelná. Naproti tomu vazba volná představuje ideální stav,kdy počet spojů nenarůstá exponenciálně a jednotlivé komponenty lze zaměnit. Jedním znejdůležitějších pravidel správného objektově orientovaného programování je zásada programováníproti rozhraní a ne proti implementaci. Nedodržení těchto zásad vede k návrhu s těsnou vazbou, cožpředstavuje ukázka Point-to-Point topologie na obrázku 3.2.Mnohem lépe je na tom topologie Hub & Spoke (Obrázek 3.3), kdy uprostřed je umístěncentrální hub zajišťující veškerou komunikaci a obsahující v sobě veškerá rozhraní, takže zdrojovýsystém nemusí znát rozhraní cílového systému a naopak. Tato topologie představuje již vazbu volnou a4
výrazně snižuje počet propojení mezi komponentami. Umožňuje též snadné monitorováníkomunikace. Nevýhodou je, že tento centrální hub je nejkritičtějším místem celé infrastruktury jak zpohledu výkonu, tak z pohledu spolehlivosti.Nejmodernější poznatky z oboru představují sběrnicovou topologii Enterprise Service Bus(Obrázek 3.4). Jedná se o distribuované řešení, které má více přípojných bodů. Komunikace mezisystémy je standardizovaná pomocí kanonického XML formátu. Veškerý provoz je třeba tedy převéstdo tohoto specifického XML formátu obsahujícího rovněž XSD schéma pro validaci datových typů.Následně lze již použít řadu generických komponent pro transformaci dat a ušetřit tak čas, který by bylpotřeba k ruční implementaci těchto komponent. Sběrnice jsou založeny na systému předávání zpráv(message-oriented middleware), což poskytuje volnou vazbu mezi komponentami. Komunikujícísystémy nemusí být funkční ve stejnou dobu, protože tyto zprávy se ukládají do samostatné databáze.5
3.3 Druhy systémových integracíJednotlivé druhy se liší použitými návrhovými vzory a technologiemi. Pro různé účely jsou vhodnérůzné typy integrací. Servisně orientovaná architektura (SOA)Integrace pomocí služeb slouží nejčastěji k integraci systémů s uživatelským rozhraním nebopro integraci procesů běžících v reálném čase. Typický případ použití je synchronní volání sodpovědí. Komunikace systémů probíhá v reálném čase s důrazem na rychlost odezvy [5]. Událostmi řízená architektura (Event Driver Architecture, EDA)Tento typ integrace je vhodný pro jednosměrný přenos zpráv mezi systémy a synchronizacedat v reálném čase. Klíčové je doručení událostí i systémům, které nejsou v danou chvíli online [6]. Datová integrace (Extract-Transform-Load, ETL)Datová integrace řeší zejména pravidelný přenos dat, jejich transformaci a následné uložení[7]. Mezi základní funkcionalitu patří nástroje k monitorování průběhu a výsledku zpracovánívelkého objemu dat. Tyto úlohy probíhají často v pravidelných dávkách (např. 1 denně).Komplexní firemní infrastruktura v praxi vyžaduje správnou implementaci všech tří, výše uvedených,druhů. Modernější řešení tak funguje například na principu SOA-EDA, kdy EDA rozšiřuje původníSOA architekturu právě o používání událostí. Bez událostí by bylo potřeba neustále v cyklukontrolovat změny jednotlivých stavů, což zbytečně zatěžuje procesor a snižuje výkon.6
4 Průběh praxe a řešené úkolyPřed nástupem na samotnou praxi jsem absolvoval dvoudenní školení spolu s nově přijatýmizaměstnanci firmy. Hlavní náplní byly základní informace o společnosti a vnitřních procesech.Součástí byl též písemný test z anglického jazyka sloužící k rozdělení do skupin pro další rozvojjazykových prostředků. Vzhledem k dosažené úrovni C1 [8] by pro mě největším přínosem bylyhodiny s rodilým mluvčím se zaměřením na správnou výslovnost a slovní zásobu.První den na odborné praxi jsem dostal počítač a veškeré potřebné zázemí k výkonu praxe.Line manager mě provedl po celém patře a alespoň zběžně jsem poznal členy ostatních týmu. Má cestaskončila u týmu ComC, který zajišťuje integraci a optimální komunikaci mezi jednotlivými produktyNPP. Zde jsem dostal úvodní školení týkající se mého zařazení v týmu a konkrétní podoby softwarovéarchitektury ComC. S teoretickými znalostmi z předchozí kapitoly a konkrétní implementací ComCjsem již mohl začít vykonávat první úkoly.4.1 ComCNež jsem mohl začít řešit každodenní úkoly z plánovacího software, musel jsem vykonat praktickécvičení v podobě doprogramování C# kódu pro definici komponenty v konkrétní integraci. Tatokomponenta měla načíst data ze SOAP webové služby a výsledek uložit do XML souboru na disku. Poimplementaci a otestování komponenty ve vývojovém prostředí Visual Studio 2010 bylo dalšímúkolem nasazení této integrace na testovací klon reálného zákazníkova prostředí. Konkrétní prostředímůže obsahovat např. čtyři virtuální stroje Windows Server 2008 R2, přičemž na každém běží jináaplikace. Dohromady toto modulární řešení tvoří jeden celek přinášející zákazníkovi určitou hodnotu.Důležitou vlastností je náhrada jakékoliv komponenty v systémové integraci. Jednotlivé firmy zrůzných zemí jsou totiž napojeny na různá rozhraní svých subdodavatelů. Splněním tohoto úkolu jsemsi vyzkoušel integraci Hub & Spoke architektury v praxi.Po vykonání praktického cvičení v podobě první implementace jsem se začal účastnit denníchScrum meetingů, kde mi byly přidělovány úkoly dle aktuálních priorit. Ať už se jednalo o zjištěnípříčiny a následné odstranění závady v konkrétní integraci pro určitého zákazníka nebo jen úpravainterního dokumentu, postup byl vždy stejný. Práce probíhala dle metodiky Scrum, což znamená, žezadání úkolu obsahovalo: User Story (US)Obsahuje popis problému v podobě jedné či více vět běžnou řečí. Odpovídá na otázky: Kdo?Co? Proč?7
Definition of Done (DoD)Seznam dílčích úkolů včetně časové náročnosti, které vedou k úspěšnému řešení. Častozahrnuje i revizi řešení s jiným členem týmu či týmové mini školení. Acceptance Criteria (AC)Popis, co musí být splněno pro uzavření úkolu. Oproti User Story je zde již odborněji popsánstav popisující fungující situaci.Pokud byl v software nějaký defekt, jednalo se o úkol typu Problem report. Po analýze zadání jsem vplánovacím software vytvořil dílčí úkoly, kdy se vždy jednalo o trojici Investigation, Fix a Test.Nejprve jsem analyzoval problém a zjistil za jakých podmínek nastane nefunkční stav čivýjimka. Souběžně s tímto jsem musel kontaktovat část týmu sídlící ve Finsku a zjistit do které verzemá jít případná oprava. Podrobnosti jsem zaznamenal do dílčího úkolu Investigation a ten pak vplánovacím software uzavřel. Poté jsem mohl přejít k samotné opravě problému, což v sobě zpravidlazahrnovalo C# a XML kód. Poslední dílčí úkol s názvem Test měl již na starost kolega tester. V tétodobě byl kód otestován ve vývojovém prostředí a většinou také na testovacím klonu v případěvirtuálního stroje. Tester toto otestoval ještě důkladněji a na jiném testovacím klonu s databází jinéhozákazníka.Členy týmu jsem se snažil obtěžovat co nejméně, protože měli kromě podobné práce ještěřadu administrativních procesů. Během mé praxe přecházeli někteří členové týmu do týmu UBI, takžejsem tušil, že mě tento přechod také bude čekat.4.2 UBIKoncem mé praxe jsem měl možnost zaznamenat přechod z týmu ComC do týmu UBI. Zde se mihodila již praktická znalost jednotlivých rozhraní a integrací z předchozích úkolů. Tým UBIimplementuje totožnou funkcionalitu, jen místo interního Tieto produktu je použit produkt MicrosoftBizTalk. Hlavní výhoda tohoto řešení představuje možnost zákazníka objednat si BizTalk konzultaci čiimplementaci u různých subdodavatelů. Architektura tohoto projektu není již Hub & Spoke, ale jednáse o plnohodnotný Enterprise Service Bus se širokými možnostmi pro audit a business reporting.Téměř nic se zde již neimplementuje v C#. K vývoji slouží rovněž Visual Studio. Jednotlivé procesy vintegraci se zde ale definují graficky, což vede k lepší abstrakci zdrojového kódu na business procesy.Tato skutečnost by měla vést ke zlepšení komunikace mezi IT odborníky a vyšším managementem,který definuje své potřeby a business procesy.8
Aktuální práce se zaměřuje především na převod stávajících integrací do Microsoft Biztalk.Nejvýhodnější je použít již předpřipravené generické komponenty pro transformaci nebo posloupnostdílčích operací definovaných v grafickém editoru ve Visual Studiu. Toto ovšem nelze vždy, někdy jepotřeba doprogramovat část C# kódu či skriptu a zapouzdřit danou část jako komponentu. Ideální jepřidat popisný název, aby hned ze schématu orchestrace šlo poznat, co daný kód provádí. Ukázkatakového příkladu je k vidění na obrázku 4.1.Obrázek 4.1: Grafický editor BizTalk orchestrací ve Visual Studio 2010 [9]9
5 Teoretické znalosti získané během studia uplatněné vprůběhu odborné praxeBěhem studia jsem již implementoval ESB architekturu v Javě, což se mi u této odborné praxe velicehodilo. Z vyučovaných předmětů považuji v tomto případě za nejvíce přínosné předměty Architekturatechnologie .NET a Databázové a informační systémy. Získal jsem především praktické zkušenosti sprací ve vícečlenném týmu. Někdy bylo potřeba analyzovat problém s členy ostatních týmů, zejménapokud se jednalo o integraci s ostatními produkty Tieto a změnu v aplikačním rozhraní nějaké služby.Za nejpřínosnější vlastnost považuji systematický a logicky správný postup při řešení dílčích úloh, cožse neobejde bez teoretických základů objektově orientovaného programování. Samotná znalost teorie,ale nestačí. Je potřeba vše prakticky vyzkoušet ještě před ostrou implementací pro zákazníka. Časvždy dané řešení prověří a odkryje případné nedostatky plynoucí z neustále se měnících požadavků.10
6 Znalosti a dovednosti scházející studentovi v průběhuodborné praxeVzhledem ke skutečnosti, že programuji od dětství a od svých 15-ti let realizuji praxi v různýchfirmách ve formě dohody o provedení práce, jsem neměl při vykonávání této odborné praxe žádnéproblémy. Musel jsem se seznámit hlavně s konkrétním schématem databáze a konkrétní implementacídané architektury.11
7 Dosažené výsledky v průběhu odborné praxe a jejícelkové zhodnoceníOdbornou praxi hodnotím jako velice přínosnou. Získal jsem praktické zkušenosti s prací vmezinárodním týmu, kde komunikace v angličtině probíhá denně. Jsem rád, že jsem zde byl také vdobě, kdy se přecházelo na novou integrační platformu Microsoft Biztalk a měl jsem možnost získatzkušenosti v obou týmech ComC/UBI. Snažil jsem se vždy být součástí týmu a pomáhat v podoběvolné kapacity pro plnění úloh.12
8 Použitá literatura[1][2][3][4][5][6][7][8][9]TIETO. Informace o Tieto [online]. 2013 [cit. 2013-03-27]. Dostupné z:http://www.tieto.cz/o-nasHABÁŇ, Jaromír a Petr SODOMKA. Systems integration 2004: 12th internationalconference, Prague, Czech Republic, June 14-15, 2004 : proceedings [online]. Ed. 1.Praha: Vysoká škola ekonomická, 2004 [cit. 2013-03-27]. 584 s. ISBN 80-245-0701-3.Dostupné z: emu.pdf. D - Článek ve sborníku. Vysoká škola ekonomickáv Praze.What is EAI (enterprise application integration)?. In: EAI (enterprise applicationintegration) [online]. 2007 [cit. 2013-03-28]. Dostupné YE, Doug. Loosely Coupled: The Missing Pieces of Web Services [online]. 2003 [cit.2013-03-28]. Dostupné z: I, Brayan. Business Benefits of SOA [online]. University of Applied Science ofNorthwestern Switzerland, School of Business, 2009 [cit. 2013-03-27]. Dostupné ault.htmMICHELSON, Brenda. Event-Driven Architecture Overview. In: Event-DrivenArchitecture Overview [online]. Patricia Seybold Group, 2006 [cit. 2013-03-27]. DOI:10.1571/bda2-2-06cc. Dostupné z: itecture-overview/Data Movement Patterns. Data Movement Patterns [online]. 2003 [cit. 2013-03-28].Dostupné z: spxCommon European Framework of Reference. Common European Framework ofReference [online]. 2008 [cit. 2013-03-31]. Dostupné CEFR/C1Tutorial 1: Enterprise Application Integration. Tutorial 1: Enterprise ApplicationIntegration [online]. 2009 [cit. 2013-04-03]. Dostupné z: v bts.10%29.aspx13
Tieto, .NET Framework, Microsoft BizTalk, system integrations, enterprise application integration. . EDA Event Driven Architecture ESB Enterprise Service Bus ETL Extract, Transform & Load NPP Nordic Product Portfolio REST Representational State Transfer SOA Service Oriented Architecture SOAP Simple Object Access Protocol UBI Utility Business .
