BD2226 Tietojärjestelmien integrointi - Johdanto EAI:hin. (Kiinnostaako koulutuksemme tai materiaalimme käyttäminen omassa opetuksessa? Älä epäröi tai älä käytä kysymättä, vaan ota rohkeasti yhteyttä - jarmo.talvivaara@pkamk.fi)

1. Pohjois-Karjalan ammattikorkeakoulu Tietojenkäsittelyn koulutusohjelma Jarmo Talvivaara jarmo.talvivaara@pkamk.fi BD2226 Organisaatioiden Tietojärjestelmien integrointi (5 op) Luento 3: Johdanto tietojärjestelmien integrointiin (osa 2)

2. Sisältöä Pari kertaavaa asiaa + termiä Integraation toteutuksessa tyyppillisesti tarvittavat perusratkaisut – ”big picture” ”Integraatioarkkitehtuuri” Mitä komponentteja tyypillisesti integraatioratkaisuissa vaaditaan? Lähdejärjestelmä (”lähdeinformaatio”) Kohdejärjestelmä (”tulosinformaatio”) Siirtokerrokset (transfer layers) Rajapinnat (interfaces) Valmiit adapterit ja muut matalan tason liitäntätyökalut Tiedon käsittely ja muuntaminen (processing and transformation) Kokonaisuuden hallinta (orchestration) Integroitujen järjestelmien monitorointi (monitoring)

3. Kertausta edellisen luennon integrointitavoista ”Miten integrointi toimikaan?” ml. integroinnin tavoitteet Mitä oli point-to-point - integrointi? Integrointitapoja, mm. Manuaalinen, käsintehtävä integrointi Siirtotiedostot Jaetut tietokannat Palvelukutsut ja muu viestinvälitys Muu tiedonsiirto järjestelmien välillä

4. Pari termiä taustatiedoksi - CSV CSV-siirtotiedostot, ”comma-separated values” Tekstitiedosto tiedon siirtämiseksi Tiedoston sisältö määrämittaista; tiedot eroteltu (”separated”) toisistaan ”kentiksi” sovitulla erotinmerkillä (puolipiste, kaksoispiste, sarkain, tms.) Esim. 1;tuote001;Näyttö;100kpl;120;euro 2;tuote002;Näppäimistö;17kpl;12.4;euro 3;tuote014;Hiiri;0kpl;10;euro 4;tuote009;Web-kamera;54kpl;41;euro 5;tuote154;Keskusyksikkö;23kpl;650.5;euro Pohdittavaa: miten CSV-tiedoston tiedosta TIEDETÄÄN (ei siis luulla..), mikä tieto tarkoittaa mitäkin?

5. Pari termiä taustatiedoksi - XML XML-muotoisia dokumentteja käytetään EAI:ssa (ja muuallakin) lukuisiin käyttötarkoituksiin esim. korvaamaan CSV-siirtotiedostot Siirtotiedoston tieto sijoitetaan XML-syntaksin mukaisesti tagien sisään Elementteihin: <hinta> 100 </hinta> Sekä attribuutteihin: <hinta valutta=”euro”>100</hinta>

6. Pari termiä taustatiedoksi - XML <tuotteet> <tuote id=”1”> <koodi>tuote001</koodi> <kuvaus>Näyttö</kuvaus> <saldo yksikko=”kpl”>100</saldo> <hinta valuutta=”euro”>120</hinta> </tuote> <tuote id=”2”> <koodi>tuote002</koodi> <kuvaus>Näppäimistö</kuvaus> <saldo yksikko=”kpl”>17</saldo> <hinta valuutta=”euro”>12.4</hinta> </tuote> </tuotteet> Pohdittavaa: selkeämpi vai sekavampi kuin CSV? Puuttuuko jotain CSV:n informaatiosta vai saadaanko itseasiassa ”kaupanpäällä” jotain lisää?

7. Miten järjestelmäintegraatiota? Tutustutaan tarkemmin mitä ao. kuvassa tapahtuu? Mitä osapuolia (näkyvien osien lisäksi) integraatio-arkkitehtuuriin tyypillisesti kuuluu? Malli pääosin sama sekä point-to-point- kuin ESB-tyyppisessä keskitetyssä integroinnissa ??? B A

8. Kolme päätehtävää Integraatioympäristön vastuulle voidaan ajatella kuuluvan seuraavat kolme eri päätehtävää Tiedonsiirto eri järjestelmien välillä (transfer) Lähettäminen lähdejärjestelmästä (A) Tallentaminen kohdejärjestelmään (B) Tarvittavat tiedonkäsittelyn ja muunnoksen toimenpiteet siirron aikana (transform) Esim. lähdejärjestelmän välittämän tiedon muuttaminen kohdejärjestelmään sopivaan muotoon Kokonaisuuden hallinta (orchestration) Vaiheiden 1-2 valvonta ja hallinta A B 1-2-3

9. Integraatioarkkitehtuurin osia Katsaus tyypillisen integrointiarkkitehtuurin/- ympäristön eri osiin, niiden tehtäviin ja vastuisiin Lähdejärjestelmät (”lähdeinformaatio”), kohdejärjestelmät (”tulosinformaatio”) Siirtokerros (transfer layer) Rajapinnat (interfaces), valmiit adapterit ja muut matalan tason liitäntätyökalut Tiedon käsittely ja muuntaminen (processing and transformation) Kokonaisuuden hallinta (orchestration) Integroidun kokonaisuuden seuranta (monitoring)

10. Integraatioarkkitehtuurin osia #1 Integraatiossa mukana olevat osapuolet Lähdejärjestelmät, kohdejärjestelmät Lähdejärjestelmä: järjestelmä, josta tiedot luetaan/välitetään Kohdejärjestelmä: järjestelmä, johon tiedot luetaan/vastaanotetaan Vuorovaikutus voi olla toki molemminpuolista Tällöin molemmat osapuolet sekä lähde- että kohdejärjestelmiä Yleistyvä malli – tavoitteena järjestelmien mahdollisimman joustava vuorovaikutus HUOM! Lähtökohta: järjestelmät eivät kykene autonomisesti ja hallitusti integroitumaan toisiin järjestelmiin!! Ainakaan ilman erillisiä integrointi-toimintoja 1 1 A B

11. Integraatioarkkitehtuurin osia #1 Lähde- ja kohdejärjestelmät voivat olla periaatteessa millaisia järjestelmiä tahansa Eri käyttöjärjestelmissä ajettavia sovelluksia tai muita palveluita, laitteita, jne. Alustoina esim. Windows, Linux, Solaris, Mac, sulautetut, keskuskone, jne Tehty eri ohjelmointikielillä: Java, PHP, C, C++, .NET-kielet, COBOL, konekieli, jne. Erilaisia tiedontallennus-ominaisuuksia: muisti, tiedostot, tietokannat, jne. Erilaisia tiedonvälitys-rajapintoja: ei mitään, tiedostojärjestelmät, verkkosanomat, palvelukutsut, jne. 1 1 A B

12. Integraatioarkkitehtuurin osia #2 Siirtokerros / -alusta tiedon välittämiseksi (transfer) osapuolelta toiselle Tarjoaa teknisen alustan tiedon siirtämisen järjestelmästä toiseen Sekä fyysinen, että looginen siirtotie (esim. LAN, Internet) HUOM! Järjestelmät voivat olla eri alustoilla => siirrosta ei välttämättä voi huolehtia pelkästään lähde- tai kohdejärjestelmän alusta Voi toimia useamman kuin yhden integraatioratkaisun siirtotienä Yleensä osa organisaation it-infrastruktuuria 2 A B

13. Integraatioarkkitehtuurin osia #2 Siirtokerros Tekniikoina yleensä tiedostojärjestelmä-pohjainen tai TCP/IP –protokolliin perustuvat siirtopalvelut Tiedostopohjaiset: esim. paikalliset siirtotiedostot tai FTP Suljetut/järjestelmäkohtaiset: esim. COM/DCOM, CORBA HTTP ja HTTPS-yleistymässä: esim. SOAP Messaging: sanomanvälitys (esim. JMS) 2 A B

14. Integraatioarkkitehtuurin osia #2 Synkroninen tiedonsiirto: esim. palvelukutsut (COM/DCOM, CORBA/RMI, SOAP/WS) Asynkroninen tiedonsiirto: esim. sanomajonot Java/JMS, .NET/MSMQ, middlewaret Siirtokerros siirtää tiedon, ei itsessään lue dataa lähdesovelluksesta eikä huolehdi tiedon tallentamisesta kohdesovellukseen Ts. ”käy paketin kuistilta ja vie vastaanottajan kynnykselle” => Loppumetreistä huolehtivat rajapinnat 2 A B

15. Integraatioarkkitehtuurin osia #3 Rajapinnat (interfaces) Siirtokerros välittää tiedot eri osapuolten välillä => tiedon lähettäminen/vastaanottaminen hoidettava järjestelmäkohtaisesti Ratkaisuna rajapinnat, jotka hoitavat järjestelmäkohtaisen tiedon käsittelyn, lähettämisen ja vastaanottamisen Järjestelmän ”pistoke”, jolla siirtokerrokseen otetaan yhteys Rajapinta ei ole täten välttämättä tiukka, standardin mukainen liittymä, vaan mikä tahansa I/O-toiminto, jolla tiedon välitys järjestelmästä ulos ja järjestelmästä sisään voidaan hoitaa Lähettäminen ja vastaanottaminen voi tapahtua toisistaan poikkeavin keinoin (esim. ulos = siirtotiedosto, sisään = palvelukutsu) 3 3 A B

16. Integraatioarkkitehtuurin osia #3 Rajapinnat Voivat olla lähde- tai kohdejärjestelmään sisäänrakennettu ominaisuuksia (siirtotiedostot, viestintä- tai palvelukutsurajapinta, jne.) Voi olla asennettava lisäkomponentti tai itse tehty liittymä Yhdessä järjestelmässä voi olla > 1 rajapintaa esim. yksinkertainen: siirtotiedostot, monipuolisempi: palvelukutsu) Haaste: osasta järjestelmistä puuttuu kokonaan! Rajapintojen selvittäminen ja käytön opiskeleminen yleensä yksi integrointi-työn perustehtävistä Rajapintojen avoimmuuden ja dokumentoinnin merkitys!! 3 3 A B

17. Integraatioarkkitehtuurin osia #3 Rajapinnat määrittävät järjestelmästä ulos-sisään-siirrettävän tiedon Järjestelmien väliset sanomat (binääri, EDI, XML, palvelupyynnöt, messaging, muut) Vaihdettava tieto (siirtotiedostot, muu replikointidata) Siirrettävän tiedon oltava rajapintaan yhtensopivaa Tästä huolehdittava vähintään kahdessa pisteessä: lähdejärjestelmä->siirtokerros sekä siirtokerros->kohdejärjestelmä Hajautetun ympäristön vuoksi alkuunpääsy ja testaaminen haasteellista 3 3 A B

18. Integraatioarkkitehtuurin osia #3 Järjestelmien rajapinnat toimivat yleensä yhteistyössä konnektorien ja adapterien kanssa Konnektori (connector): integraatio-ympäristön komponentti, joka mahdollistaa siirtokerroksen ja sovelluksen välisen yhteydenoton Adapteri (adapter): komponentti, joka sovittaa kaksi erilaista osapuolta yhteen (esim. siirtotiedosto <-> palvelukutsu) Joskus rajapintojen, konnektorien ja adapterien ero voi olla vaikea huomata Esim. toteutettu ja ”putkitettu” saman työkalun sisällä (Konnektoreista ja adaptereista enemmän seuraavissa moduuleissa, myös työkalu case:jen yhteydessä) 3 3 A B

19. Integraatioarkkitehtuurin osia #4 Tiedon käsittely ja muuntaminen (transformation) Lähes poikkeuksetta: lähde- ja kohdejärjestelmät poikkeavat toisistaan tiedon lähetys ja vastaanotto-toiminnot, tiedon muoto, merkistöt, viestien kieli, tiedosto-vai-palvelukutsu, jne esim. tieto lähetetään järjestelmästä ”A” perinteisenä CSV-siirtotiedostona, mutta järjestelmä ”B” pystyy lukemaan vain XML-muotoisia? Toisinsanoen: RAJAPINNAT EIVÄT LÄHESKÄÄN AINA YHTEENSOPIVIA!! (auts!) Järjestelmät eivät pysty suoraan viestimään ”yhteismitallisesti” Mm. tästä kyse alussa mainitussa ”järjestelmät eivät oletuksena kykene autonomiseen ja hallittuun tiedonsiirtoon” - näkökulmassa ? ? ? ? CSV XML A B

20. Integraatioarkkitehtuurin osia #4 Tiedon käsittely ja muuntaminen (transformation) ”Epäyhteensopivien rajapintojen” voidaan ajatella olevan arkipäivää EAIssa => tästä haasteesta huolehtiminen on yksi keskeinen integraatio-alustojen vastuu Eri rajapinnat, eri viestimuodot, jne. yhteensovittaminen Ratkaisu: annetaan molempien osapuolten (lähde- ja kohdejärjestelmän) elää ”omaa elämäänsä” => Huolehditaan siirron aikana tiedon käsittelystä ja muunnoksesta tarvittavaan muotoon => integraatio-alustaan tarvitaan osa, joka huolehtii tiedon käsittelystä ja muuntamisesta (transformation) 4 IN OUT A B

21. Integraatioarkkitehtuurin osia #4 Tiedon käsittely ja muuntaminen Saadaan siirretyt tiedot järjestelmien vaatimaan muotoon Yhdistelmät voivat olla helpostikin varsin eksoottisia Sanomista dokumenteiksi ja päinvastoin CSV-siirtotiedostosta XML-dataksi, SOAP-kutsuksi tai ODBC/SQL-tietokantapäivitykseksi Muutama kymmenen vaihtoehtoa lisää ja päinvastoin Voidaan yhdistellä tietoja useasta eri lähteestä! Täydentää ja rikastaa tietoa (sirpaledata -> informaatioksi) Jälleen kerran vastuu-kysymys: ilman tätä arkkitehtuurin osaa – kuka tästä huolehtisi (puolueettomasti)? 4 IN OUT A B

22. Integraatioarkkitehtuurin osia #4käsittely ja muunnos - esimerkkejä? 4 B OUT A IN XML-dokumentti CSV-siirto-tiedosto C OUT IN ODBC tietokanta-yhteys CSV-siirto-tiedosto E OUT IN SOAP/ Web Services-kutsu D JDBC-tietokanta-yhteys jne…

23. Integraatioarkkitehtuurin osia #5 Integraation hallinta (orchestration) Ts. integraatioratkaisun osa, joka huolehtii ”kokonaisuudesta” Vastaa mm. integraatiossa tapahtuvasta tiedon siirrosta Mistä? (lähdejärjestelmän tunteminen) Miten? (käsittely ja muunnokset) Minne? (kohdejärjestelmän tunteminen) Ts. prosessien hallittu käynnistäminen, kontrollointi ja päättäminen Myös virhetilanteiden käsittely, jne? Käytetään yleensä termiä ”orchestration” HALLINTA (orkestrointi) 5 A B

24. Integraatioarkkitehtuurin osia #5 Monissa integrointituotteissa ”peruspakettiin” kuuluu osat tiedon siirrost ja rajapinnoista/adaptereista tiedon käsittelyyn ja siirtoon Kaikissa ei kattavia orkestrointi-työkaluja tai valmiuksia hallita kokonaisuutta Esim. ainoastaan integraatioprosessien käynnistys Orkestraatio ei pakollinen osa yksinkertaisissa point-to-point-ratkaisuissa, mutta … vähänkään laajemmissa kokonaisuuksissa välttämättömyys Monissa työkaluissa (esim. Biztalk ja vastaavat) orkestraation yhtenä tärkeänä käyttöliittymänä prosessinäkymä! 5 HALLINTA (orkestrointi) A B

25. Integraatioarkkitehtuurin osia #5 Samalla orkestrointi-hallinta-ratkaisulla voidaan tyypillisesti hallita useita integrointi-ratkaisuja Hallitaan todellakin kokonaisuutta Prosessinäkökulma! Yhdessä prosessissa voi olla tarve integroida Useita eri järjestelmiä –prosessin eri vaiheissa! HALLINTA (orkestrointi) A C D B

26. Integraatioarkkitehtuurin osia #6 Integraatio-prosessien seuranta, mittaus ja arviointi BAM – Business Activity Monitoring Kerätään systemaattisesti tietoa integraatiokokonaisuudesta; onnistuneet/epäonnistuneet toiminnot, vasteajat, jne. Esim. integroidun kokonaisuuden tuottamaa liiketoimintatietoa prosesseista Tähän ei välttämättä päästäisi käsiksi irrallisia järjestelmiä käyttämällä 6 BAM - monitorointi HALLINTA A B

27. Integraatioarkkitehtuurin osia #6 Kuten orkestroinnin kohdalla, myöskään BAM-piirteitä eivät läheskään kaikki työkalut sisällä (vaatii yleensä erillisen ratkaisun) Keskitetyn ratkaisun edut ilmenee myös monitoroinnissa: samalla ratkaisulla voidaan tyypillisesti seurata useita integrointi-ratkaisuja => seurataan kokonaisuutta Myös tässä prosessinäkökulma! Monitorointi A C D B

28. Kerrataan kokonaisuus Lähde- ja kohdejärjestelmät Siirtokerros Rajapinnat Tiedon käsittely ja muunnos Hallinta (orkestrointi) Seuranta (monitorointi) 6 BAM - monitorointi 5 HALLINTA 4 1 A B 1 2 3 3