Avointen integrointiratkaisujen hyödyntäminen, toteuttaminen ja testaus

Transkriptio

1 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 5 STUDIES AND REPORTS OF THE PLUGIT PROJECT 5 Juha Mykkänen, Tanja Toroi, Harri Karhunen, Hannu Virkanen, Heli Mäki, Marko Sormunen, Juha Rannanheimo, Mika Tuomainen Avointen integrointiratkaisujen hyödyntäminen, toteuttaminen ja testaus KUOPION YLIOPISTO SAVONIA-AMMATTIKORKEAKOULU KUOPIO 2004

2 Tekijät: Juha Mykkänen (toim., luvut 1, 2, 3.2, ) Heli Mäki (luvut 4.1, 5.1, 5.2) Hannu Virkanen (luku 3) Marko Sormunen (luvut 5.3, 5.4, 6.1) HIS-tutkimusyksikkö, Tietotekniikkakeskus Kuopion yliopisto Tanja Toroi (luku 3) Harri Karhunen (luku 3) Tietojenkäsittelytieteen laitos Kuopion yliopisto Juha Rannanheimo (luku 6.3) Mika Tuomainen (luvut 6.2, 3.2) Savonia Business Savonia-ammattikorkeakoulu Myynti: Tietotekniikkakeskus / kanslia Kuopion yliopisto puh tike@uku.fi ISBN (koko teos) ISBN X (osa 5) ISBN (PDF) Kopijyvä Oy, Kuopio 2004

3 Mykkänen, Juha; Toroi, Tanja; Karhunen, Harri; Virkanen, Hannu; Mäki, Heli; Sormunen, Marko; Rannanheimo, Juha; Tuomainen, Mika. Avointen integrointiratkaisujen hyödyntäminen, toteuttaminen ja testaus. PlugIT-hankkeen selvityksiä ja raportteja s ISBN (koko teos) ISBN X (osa 5) ISBN (PDF) Tiivistelmä Tämä raportti sisältää avointen integrointiratkaisujen hyödyntämiseen, toteutukseen ja testaukseen liittyviä menetelmiä, kokemuksia ja esimerkkejä. Erityisesti PlugIT-hankkeessa kehitettyjen avointen integrointimääritysten hyödyntäminen toteutuksissa erilaisiin ohjelmistoihin on tarkastelun kohteena, mutta sisältö on sovellettavissa myös muiden integrointiratkaisujen yhteydessä. Katettuja kokonaisuuksia ovat avointen määritysten hyödyntäminen suhteessa ohjelmistoihin ja ohjelmistotuotteisiin, ohjelmistojen testaus ja toteutettujen integrointiratkaisujen määritysten mukaisuus sekä eri tekniikoilla toteutetut referenssitoteutukset ja niiden sovelluskohtaiset ratkaisut. Nämä kokonaisuudet antavat malleja ja esimerkkejä seikoista, joita integrointiratkaisujen hankinta- ja toteutusvaiheessa on otettava huomioon. Raportin eri osissa ja toteutuksissa on hyödynnetty PlugIT-hankkeessa tuotettuja integrointimäärityksiä, jotka on julkaistu raporteissa Työpöytäintegraation avoimet sovellusrajapinnat, Terveydenhuollon avoimet sovellusrajapinnat - yhteiset perusratkaisut, Terveydenhuollon avoimet sovellusrajapinnat koodistorajapinnat, Terveydenhuollon avoimet sovellusrajapinnat - käyttäjä- ja käyttöoikeusrajapinnat ja Terveydenhuollon avoimet sovellusrajapinnat - potilasrajapinnat. Raportti liittyy kiinteästi muihin PlugIT-hankkeen integraatioon ja toteutuksiin liittyviin tuotoksiin, erityisesti Terveydenhuollon sovellusintegraatioratkaisujen määrittely -menetelmiin ja toteutusten osalta Component and Service Technology Families -tekniikkaselvitykseen sekä Ohjelmistotuotannon välineselvitys - näkökulmia terveydenhuollon ohjelmistoyrityksen välinesalkun kokoamiseen -raporttiin. Yleinen kymmenluokittelu UDK: 681.3, 006 Asiasanat (YSA): systeemityö, terveydenhuolto, tietojärjestelmät, tietokannat, tiedonhallinta, tiedonhallintajärjestelmät, tietoteollisuus, ohjelmointi Medical Subject Headings (MeSH): software, information systems, medical informatics, database management systems, hospital information systems

4

5 Esipuhe Tämä selvitys on tehty PlugIT-hankkeessa vuosina Selvityksen tavoitteena on dokumentoida hankkeessa kehitettyjä avointen integrointiratkaisujen hyödyntämiseen, toteutukseen ja testaukseen liittyviä menetelmiä, kokemuksia ja esimerkkejä. Selvitys on erityisesti suunnattu integrointiratkaisujen toteutukseen ja käyttöönottoon osallistuville sovellusten tuottajille ja terveydenhuollon tietohallinnon ammattilaisille, mutta sen sisältämät seikat ovat hyödyllisiä myös ratkaisujen määrittelyyn ja standardointiin osallistuville. PlugIT-hanketta ovat rahoittaneet ja siihen ovat osallistuneet TEKES, Mawell konserni, Medimaker Oy Ltd, Medici Data Oy, Mediweb Oy, Mylab Oy, Tietoenator Oyj, WM-data Novo Oyj, Atkos Oy, BEA Systems Oy, Commit; Oy, Enfo Oy, Fujitsu Services Oy, General Electric Healthcare CIS EMEA, Mediconsult Oy, Microsoft Oy, Oracle Finland Oy, Helsingin ja Uudenmaan sairaanhoitopiirin kuntayhtymä, Pirkanmaan sairaanhoitopiirin kuntayhtymä, Pohjois-Savon sairaanhoitopiirin kuntayhtymä, Pohjois-Pohjanmaan sairaanhoitopiirin kuntayhtymä, Satakunnan sairaanhoitopiirin kuntayhtymä, Varsinais-Suomen sairaanhoitopiirin kuntayhtymä, Kuopion kaupungin sosiaali- ja terveyskeskus sekä Siilinjärven ja Maaningan terveydenhuollon kuntayhtymä. Tekijät kiittävät kaikkia toteutus- ja määritystyöhön osallistuneita. Kiitämme myös projektiin osallistuvien yritysten ja sairaaloiden edustajia ideoista, näkökulmista ja kehitysehdotuksista. Kuopiossa 30. elokuuta 2004 Tekijät

6

7 Sisällys 1 JOHDANTO JA TAUSTA PlugIT-projekti Dokumentin sisältö AVOINTEN INTEGROINTIMÄÄRITYSTEN HYÖDYNTÄMINEN Avoimen integrointimäärittelyn suhde ohjelmistotuotteeseen Avoimen määrityksen hyödyntämisen vaiheet Sovelluksen tarpeet ja integrointimäärityksessä kuvattu ratkaisu Tekniikkariippumaton ratkaisu sovelluksen kannalta Liittymätekniikan sovitus sovellukseen Toteutus ja testaus Paikallinen sovitus Käyttöönotto INTEGROINTITOTEUTUKSEN TESTAUS JA MÄÄRITTELYJEN MUKAISUUS Yleistä ohjelmistotestauksesta Testauksen tarkoitus Testauksen hallinta Virheluokitus Testausmenetelmät PlugIT-leima Yleistä PlugIT-leimasta Prosessin vaiheet Toimenpiteet Esimerkkejä kontekstinhallintapalvelimen testitapauksista Testauspöytäkirja Yhteenveto KONTEKSTINHALLINTA-ESIMERKIT Kontekstinhallinnan.NET-asiakassovellus Potilas-luokka Login-luokka Haku-luokka Tietokanta Metodit kontekstipalvelun käyttämiseksi Eri vaiheissa tehdyt ratkaisut Olemassa olevan Musti-tekniikkaa käyttävän Delphi-sovelluksen liittäminen kontekstinhallintaan Kontekstihallinnan linkitys sovelluksen toimintoihin Tekniset ratkaisut ja toteutuskohtaiset seikat Muita toteutuksessa huomioitavia seikkoja Kontekstipalvelun referenssitoteutus Toteutuksen suhde rajapintamäärittelyihin Toteutuskohtaiset ominaisuudet Kontekstipalvelutoteutusten testaussovellus...41

8 5 YDINPALVELU-ESIMERKIT CoreServiceDemo Käyttäjä-, Käyttöoikeus- ja Potilaspalveluiden.NETtoteutus CoreServiceDemo.aspx-luokka Global.asax-luokka AuthenticateUser-luokka UserIdentifyProfile-luokka UserProfileAccess-luokka PatientIdentifyProfile-luokka PatientProfileAccess-luokka AuthorizationAccess-luokka Checker-luokka DatabaseConnector-luokka Tietokanta Eri vaiheissa tehdyt ratkaisut PatientCoreClientDemo Käyttäjä- ja Potilaspalveluiden.NET-asiakassovellus Vaatimukset ydinpalvelutoteutuksille Setup.xml-tiedosto Lomakeluokat Apuluokat Eri vaiheissa tehdyt ratkaisut Käyttäjä-, Käyttöoikeus- ja Potilaspalveluiden Java-toteutus Yleistä Java-toteutuksesta HTTP-kuuntelija AuthenticateUser- AuthorizationAccess-, IdentifyProfile- ja ProfileAccesspalvelut Tietokanta Java-toteutuksen lokitiedot Eri vaiheissa tehdyt ratkaisut Java-toteutuksen demoasiakassovellus Käyttöliittymä Sovelluslogiikka Eri vaiheissa tehdyt ratkaisut MUITA TOTEUTUSKOKEMUKSIA Java-demo Simple PIDS määrityksestä Demon tarkoitus Toiminnallisuus Tekniset valinnat IdentifyPerson-rajapinnan metodit ProfileAccess-rajapinnan metodit Muut PIDS-palvelut CCOW-yhteensopivuuden liittäminen sovellukseen käyttäen Vergence SDK:ta Vergence SDK Toteutuksen osat CCOW yhteensopivuuden liittämisen perusvaiheet Kokemukset Vergence SDK:n käytöstä...72

9 6.3 Esimerkki: Patologian pyyntö ja vastaus Integraation tarve ja vaatimukset Liittymämäärittelyt Integraation toteutus Yhteenveto LÄHTEET...76

10

11 1 JOHDANTO JA TAUSTA 1.1 PlugIT-projekti PlugIT-projekti on vuosina toteutettu valtakunnallinen Tekes-rahoitteinen tutkimus- ja kehittämishanke, joka tuottaa avoimia ohjelmistorajapintojen määrityksiä sekä niihin liittyviä menetelmiä ja osaamista terveydenhuollon ohjelmistoyrityksille ja niiden asiakkaille. Hankkeen tavoitteena on tukea terveydenhuollon palvelutoimintaa ohjelmistotuotannon palveluketjun kautta, paremmin integroituvien ohjelmistokokonaisuuksien avulla (PlugIT 2004). Tutkimuksen sekä rajapintojen määrittelyn ovat toteuttaneet neljä Kuopion Centekin yksikköä yhteistyössä 15 ohjelmistoyritystä, kuusi sairaanhoitopiiriä (mukaan lukien kaikki yliopistolliset sairaanhoitopiirit) sekä yksi kahden kunnan terveydenhuollon kuntayhtymä. 1.2 Dokumentin sisältö Tämä raportti kokoaa PlugIT-hankkeen kokemuksia ja menetelmiä, jotka liittyvät integrointimääritysten hyödyntämiseen ja erilaisten integrointiratkaisujen toteuttamiseen sovellusohjelmistoihin. Raportissa kuvataan myös menetelmiä tuotettujen ratkaisujen testaukseen, kun tarkoituksena on varmistua siitä että ratkaisu on integrointimääritysten mukainen. Raportti sisältää myös kuvauksia hankkeessa toteutetuista ja siihen liittyvistä referenssitoteutuksista ja niiden toteuttamisessa käytettyjen välineiden käyttökokemuksia. Erityisesti dokumentin lukujen 2 ja 3 sisältöjä (määritysten hyödyntäminen, määritysten mukaisuuden testaus) voidaan soveltaa myös muihin kuin PlugIThankkeen kohteena olleisiin integrointimäärityksiin. Selvitys liittyy läheisesti raporttiin Terveydenhuollon sovellusintegraation määrittely (Mykkänen ym. 2004a), jossa kuvataan integrointiratkaisujen määrittelyä, mutta vain lyhyesti sivutaan toteutuksia sovelluksiin. Erityisesti kyseisen selvityksen luvut Yleiskuva integrointimäärittelyistä, Integrointiprojektin dokumentit ja 6 Liittymän toteutuksen kuvaus ovat olennaisia tämän dokumentin kannalta. Tämän raportin lisäksi myös edellä mainitun raportin luvussa 8.2 Integraatioratkaisujen määrittely ja toteutus kuvataan kootusti PlugIT-hankkeen kokemuksia, jotka liittyvät myös määritysten hyödyntämiseen ja toteutuksiin. Useat kuvattavista toteutuksista perustuvat tekniikoihin, joista lisätietoja löytyy mm. tekniikkaselvityksessä (Mykkänen ym. 2004b) ja on toteutettu välineillä joita kuvataan välineselvityksessä (Karvinen ym. 2004). Tämän dokumentin luvussa 2 kuvataan yleisesti avointen integrointi- ja rajapintamäärittelyjen hyödyntämistä, määritysten suhdetta ohjelmistotuotteeseen sekä hyödyntämisen vaiheita etenkin lähteessä (Mykkänen ym. 2004a) esitetyn integrointiprosessin ja uudelleenkäytettävien integraation määrittelydokumenttien kannalta. Luvussa 3 käsitellään ohjelmiston testausta suhteessa integrointimäärityksiin ja esitellään PlugIT-hankkeessa käytetty leimausprosessi, jonka avulla on tutkittu sovellusten integrointimäärittelyjen mukaisuutta. Luvussa 4 esitellään PlugIT-hankkeen työpöytäintegraatio-määrittelykohteeseen (Tuomainen ym. 2004) liittyviä toteutuksia ja niissä saatuja kokemuksia. AVOINTEN INTEGROINTIRATKAISUJEN HYÖDYNTÄMINEN, TOTEUTTAMINEN JA TESTAUS 11

12 Luvussa 5 esitellään PlugIT-hankkeessa määriteltyihin sovellusten yhteisiin ydinpalveluihin (Sormunen ym. 2004a-b, Rannanheimo ym. 2004, Mykkänen ym. 2004c) liittyviä toteutuksia ja niissä saatuja kokemuksia. Muiden PlugIT-hankkeessa tuotettujen toteutusten tuloksia ja kokemuksia on koottu lukuun PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 5

13 2 AVOINTEN INTEGROINTIMÄÄRITYSTEN HYÖDYNTÄMINEN Avoimissa integrointimäärittelyissä, kuten PlugIT-projektin tuottamissa liittymämäärittelyissä, kuvataan ohjelmistotuotteiden integroinnissa hyödynnettäviä ratkaisuja. Näiden ratkaisujen käyttöönottamiseksi etenkin olemassa olevissa tuotteissa on itse rajapintamäärittelyn lisäksi ratkaistava joukko tuote- ja toteutuskohtaisia seikkoja. Tässä luvussa kuvataan ja havainnollistetaan sitä, kuinka avointa liittymämäärittelyä voidaan hyödyntää integroinnissa. Avoimia rajapintamäärittelyitä voidaan hyödyntää mm. tuotetoteutuksissa, tarjouspyynnöissä ja tarjouksissa. Tämä raportti keskittyy määritysten hyödyntämiseen toteutuksissa sovelluksiin. 2.1 Avoimen integrointimäärittelyn suhde ohjelmistotuotteeseen Tuotetoteutuksissa liittymämäärittelyjä voidaan hyödyntää kahdella perusstrategialla: määrittelyn mukainen rajapinta rakennetaan osaksi tuotetta, jonka jälkeen se on osa ohjelmiston tuoteominaisuuksia ja voidaan ottaa nopeasti käyttöön eri integrointitilanteissa, määrittelyn mukainen rajapinta rakennetaan asiakkaan tekemän tilauksen perusteella ja yhteistyössä liittymän vastapuolen kanssa. Myös jälkimmäisessä tavassa toteutus voidaan lisätä ohjelmiston tuoteominaisuudeksi, mutta kahdenväliset avoimen määrittelyn lisäksi tehdyt ratkaisut voivat vaikeuttaa ratkaisun uudelleenkäyttöä. Se, kumpi hyödyntämistapa on kyseessä, voi vaikuttaa siihen, miten ja missä järjestyksessä määritysten hyödyntämisessä eri asioita ratkaistaan. Luvussa 2.2, jossa käsitellään hyödyntämisen vaiheita tarkemmin, on mainittu eroja eri hyödyntämistapojen välillä. PlugIT-projektissa on määritelty useita dokumentointitasoja, joita kaikkia voidaan hyödyntää suhteessa ohjelmistotuotteeseen. Näitä tasoja ovat (Mykkänen ym. 2004a): Integrointivaatimukset, Tekniikkariippumattomat liittymämäärittelyt, Tekniset liittymämäärittelyt ja Liittymän toteutuksen kuvaus. Avointa Integrointivaatimukset -dokumenttia voidaan hyödyntää siten, että tuotteeseen tehtävät toteutukset vastaava dokumentissa kuvattuja vaatimuksia. Jos toteutuksessa nojaudutaan pelkkään Integrointivaatimukset-dokumenttiin, ei eri tuotteiden välille synny automaattisesti yhteentoimivaa ratkaisua (vaatimuksiin voidaan vastata eri tavoin eri tuotteissa), mutta saadaan toteutettua esitettyihin vaatimuksiin vastaava ohjelmisto. Tekniikkariippumattomat liittymämäärittelyt -tason dokumenttia soveltamalla eri tuotteisiin voidaan saada sisällöllisesti ja toiminnallisesti yhteensopivia toteutuksia. Käytännössä tämä taso helpottaa eri tuotteisiin toteutettujen rajapintojen yhteensovitusta siten, että eri sovellusten rajapinnoissa on samansisältöiset toiminnot ja tiedot, ja rakennetaan vain sovittimia tai eri tekniikoiden AVOINTEN INTEGROINTIRATKAISUJEN HYÖDYNTÄMINEN, TOTEUTTAMINEN JA TESTAUS 13

14 välisille rajapinnoille. Kyseessä ei kuitenkaan vielä ole taso, jolla eri tuotteet suoraan toimivat yhdessä. PlugIT-projektin integrointimäärittelyissä samasta Tekniikkariippumattomasta määrittelystä voidaan tuottaa useita Teknisiä liittymämäärittelyitä. Teknisen määrittelyn pohjalta sovelluksiin toteutetut rajapinnat toimivat yhdessä, jolloin sovellusten integrointi rajapinnan avulla on nopeaa ja suoraviivaista. Suuri osa integroinnin kysymyksistä on ratkaistu kun on päästy teknisten liittymien tasolle, ja jäljellä olevat tuote- tai toteutuskohtaiset seikat voidaan dokumentoida esimerkiksi Liittymän toteutuksen kuvaus-mallin mukaisesti. Toteutuksen kuvaus on osa tuotedokumentaatiota, jossa kuvataan integrointiratkaisuun liittyvät toteutuskohtaiset seikat, kuten sovelluksen tai ratkaisun alustavaatimukset, ratkaisun tuomat lisäpiirteet tai vaatimukset ja tarvittava paikallisten asetusten tekeminen esim. asennuksen yhteydessä. Samasta teknisestä määrittelystä eri tuotteisiin toteutettujen ratkaisujen yhteentoimivuus on saavutettavissa huomattavasti helpommin kuin ylemmän tason määrittelyistä toteutettujen ratkaisujen toimivuus. Tällaisissa tapauksissa eri tuotteissa on valmiina toiminnallisesti yhteensopivat ja myös samoja teknisiä ratkaisuja hyödyntävät rajapinnat, ja tapauskohtaisesti päätettäväksi jäävät määrityksissä toteutuskohtaisiksi jätetyt seikat sekä paikalliset vaatimukset. Tämän dokumentin loppuosassa keskitytään eri liittymämääritysten (varsinkin Teknisten liittymämäärittelyjen) hyödyntämiseen ja toteutusten kuvausten hyödyntämiseen ja tuottamiseen. Monissa integrointitilanteissa Teknisen liittymämäärityksen mukainen rajapinta rakennetaan suoraan osaksi sovelluksia. Jos toteutusten uudelleenkäyttöä halutaan parantaa, käytännön toteutusratkaisuna voi myös olla komponentti, adapteri, kirjasto tai sovitin, joka on yhteydessä teknisen liittymämäärittelyn mukaisella tekniikalla muihin integroinnin osapuoliin, mutta joka tarjoaa sovelluksen tekijälle vastaavan rajapinnan sovellukseen tekemiseen muutenkin käytetyllä tekniikalla. Esimerkki tällaisesta ratkaisusta on kontekstinhallintatuotteen toimittajan tarjoama komponentti kontekstiin liittyville sovelluksille, joka on yhteydessä kontekstinhallintaan httpkontekstimäärittelyn mukaisella tekniikalla, mutta joka tarjoaa suoraan käytettävään kehitysvälineeseen integroituvan komponentti- tai kirjastorajapinnan palveluun liittyvän sovelluksen kehittäjälle. 2.2 Avoimen määrityksen hyödyntämisen vaiheet Tämä osio keskittyy siihen, kuinka avointa teknisen ratkaisun sisältävää integrointimääritystä voidaan hyödyntää tuotteessa ja pyrkii listaamaan seikkoja, jotka on otettava huomioon itse integrointimäärityksen lisäksi integroinnin toteuttamisessa ja sen dokumentoinnissa. Osiossa hahmotellaan vaiheet, jotka käydään läpi sovelluksessa, jonka integrointiratkaisussa halutaan hyödyntää ulkoista integrointimäärittelyä tai -standardia. Vaiheita voi soveltaa hyvin eri tyyppisten standardien ja määritysten kannalta (esim. myös Tekniikkariippumattomat määrittelyt, Integrointivaatimukset ja viitestandardit), mutta tässä kiinnitetään erityisesti huomiota PlugIT-projektin teknisten määrittelyjen hyödyntämiseen. Osio keskittyy yhden sovelluksen kannalta tapahtuvaan valmiin määrityksen arviointiin. Jos kyseessä on muunlainen integrointitilanne, voidaan soveltaa suoraan myös raportissa (Mykkänen ym. 2004a) kuvattua prosessia. Jos integrointitilanteessa tunnetaan tarkasti käyttöympäristön ja vastinsovelluksen paikalliset vaatimukset ja ratkaisut, otetaan myös nämä vaatimukset huomioon eri vaiheissa. Avoimet ja tapauskohtaiset ratkaisut kannattaa kuitenkin erottaa toisistaan, jotta oma integroinnin toteutus toimisi standardin mukaisesti myös myöhemmin vastaan tulevissa integrointitilanteissa. Raportissa (Mykkänen ym. 2004d) on esitetty malli, jolla voidaan arvioida seikkoja, joihin jokin tietty standardi tai integrointimääritys ottaa kantaa, ja mitkä seikat on ratkaistava lisämääritysten tai toteutuskohtaisten käytäntöjen avulla. 14 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 5

15 2.2.1 Sovelluksen tarpeet ja integrointimäärityksessä kuvattu ratkaisu Avoimet integrointimäärittelyt vastaavat tiettyihin yleisiin integrointivaatimuksiin, jotka on joko kuvattu avointen määrittelyjen Integrointivaatimukset-osiossa, määrittelyn johdannossa (soveltamisalue, scope) tai käyvät ilmi määrittelyn sisältämistä toiminnoista ja tiedoista. kuvataan käsillä oleva integrointitilanne tai sovelluksessa oleva integrointitarve, tarkastetaan, mihin vaatimuksiin integrointimääritys vastaa, ja mikä on omassa tuotteessa tilanne ja osa, jossa määritystä sovelletaan, tarkastetaan, onko määrityksestä useita versioita ja päätetään, mitä versiota halutaan hyödyntää (levinneisyys, tuotteiden saatavuus, määrityksen kattavuus), tai onko tulossa uusi versio, joka vastaa nykyversioita paremmin tarvetta Tekniikkariippumaton ratkaisu sovelluksen kannalta Integrointimäärityksessä on usein määritelty erilaisia rooleja (esim. rajapinnan tarjoaja ja hyödyntäjä), tietoja ja toimintoja, jotka on toteutettava kun määritys otetaan sovelluksessa käyttöön. Toteutuskohtaisesti voidaan myös varautua siihen, ettei palvelu vastaa tai ole lainkaan käytössä käyttöympäristössä. Tunnistetaan, mikä määrityksessä mainittu sovellusrooli (esim. palvelun käyttäjä tai tarjoaja) oma sovellus on, ja mitä rajapintakutsuja tai toteutuksia tarvitaan. Tarkistetaan, sisältääkö oma sovellus valmiiksi tarvitut tiedot tai toiminnot, mitä lisäyksiä tai muutoksia tai mitä asioita sisältävä adapteri sovellukseen tarvitaan. Päätetään, mihin kohtiin ja toimintoihin omassa sovelluksessa integrointirajapintakutsut rakennetaan. Päätetään, varaudutaanko (konfiguroimalla) siihen, ettei integrointirajapintaa käytetä jossain tilanteessa (esim. asennuksissa, joissa vastapuolta ei ole saatavilla). Jos tietyn standardin tekniikkariippumaton Liittymätekniikan sovitus sovellukseen Kun integrointiratkaisun rooli ja sisältö on selvitetty, on myös teknisen tason kysymykset ratkaistava oman sovelluksen kannalta. Tutkitaan, onko omassa sovelluksessa jo käytetty tekniikoita, jotka ovat määrityksessä liittymätekniikoina. Tällöin voidaan yleensä helposti hyödyntää jo aiemmin tehtyjä sovelluksen osia. Päätetään, millä välineillä omassa kehitysympäristössä ja sovelluksissa luodaan liittymätekniikan mukaiset rajapinnat. Jos omassa kehitysympäristössä ei ole valmiina liittymätekniikoita tukevia osia tai niiden käytöstä ei ole kokemuksia, voidaan välinetäydennystä ja ohjeita etsiä mm. määritysten tuottajilta tai jos integroinnin vastakappale tunnetaan, tämän sovelluksen tekijöiltä. Esimerkkejä: PlugIT-projekti on tuottanut välineselvityksen (Karvinen ym. 2004), jossa on lueteltu ja arvioitu myös integrointiratkaisujen toteuttamiseen soveltuvia välineitä ja välineistöjä (luku 8) ja integroinnissa käytettävien välineiden valinnassa huomioitavia seikkoja (luku 3.5). Määritysten tekijöillä on usein niiden kokeiluun käytettyjä välineitä, ja tarjolla voi myös olla koulutusta ja tukipalveluita määritysten hyödyntämiseen. Mm. PlugIT-projektin työntekijät ovat olleet projektin aikana käytettävissä osapuolten sovelluksiin liittyvässä neuvonnassa ja sovittaessa myös toteutuksissa. Myös Suomen HL7-yhdistys on tarjonnut integroinnin tukitoimintoja ja koulutusta tukemiinsa määrityksiin. AVOINTEN INTEGROINTIRATKAISUJEN HYÖDYNTÄMINEN, TOTEUTTAMINEN JA TESTAUS 15

16 Integrointipalveluja tarjoavat sovellukset voivat tarjota (varsinaisen teknisen rajapinnan piilottavia) adaptereita eri tekniikoilla, joista jotkin ovat sovelluksen omalla tekniikalla helpommin käyttöönotettavissa kuin uudella teknisellä. Esimerkki tästä on PlugIT-projektin http-pohjaisen kontekstihallinnan kutsut piilottava DLL-kirjasto, joka saadaan liitettyä erilaisiin Windowsalustalla toimiviin sovelluksiin ilman http-liikenteestä huolehtimista sovelluksen tasolla. Vastaavia adaptereita voi rakentaa sovelluksiin myös itse. Tällöin adapteri on tarvittaessa suoraan käytettävissä useissa eri sovelluksissa Toteutus ja testaus Kun integrointitoteutuksen rajapinnat, sisältö ja tekniikat on selvitetty oman sovelluksen kannalta, on aika siirtyä ratkaisun toteutukseen sovelluksessa. Tässä vaiheessa on ratkaistava seikat, joita ei ole lyöty lukkoon integrointimäärityksessä: Integrointimäärityksessä on usein mainittu asioita, jotka ratkaistaan toteutuskohtaisesti. Nämä kohdat määrityksestä ja se kuinka sovellukseen tehty toteutus vastaa niihin, on ratkaistava ennen toteutusta. Tämän lisäksi toteutukselle on usein yleisiä vaatimuksia (esim. palvelun tulee voida palvella useita yhtäaikaisia käyttäjiä, sillä voi olla tietyt suorituskyky- tai vasteaikavaatimukset, lisäturvallisuusvaatimuksia kuten liikenteen salaus, tai tarvetta pystyä konfiguroimaan joitain toteutuksen piirteitä (turvallisuus, palvelun löytäminen, paikalliset ja tarvittaessa käyttöönotettavat lisäpiirteet). Tyypillisiä sovelluksiin tapahtuvan toteutuksen vaihtoehtoja: Jos saatavilla on integrointimäärityksen pohjalta tehtyjä referenssitoteutuksia, ne sisältävät usein valmiita malleja vastaavien ratkaisujen tuottamiseksi. Vaikka referenssitoteutus olisi tehty eri tekniikalla (esim. eri ohjelmointikielellä) kuin oma sovellus, niissä ratkaistut seikat on yleensä ratkaistava myös omassa sovelluksessa. Esimerkiksi PlugIT-projektiin liittyviä rajapintojen esimerkkitoteutuksia kuvataan tämän dokumentin myöhemmissä luvuissa ja niitä on ollut saatavilla projektin web-sivujen kautta projektin osapuolille (kunkin määrityksen yhteydessä on mainittu mahdollisia esimerkkejä ja toteutuksia). Palvelua tai rajapintaa hyödyntäville sovelluksille voi olla tarjolla valmiita välineitä, jotka sopivat omaan kehitysympäristöön (ks. edellinen kohta). Rajapinnan toteuttavien sovellusten dokumentaatiossa voi myös olla esimerkkejä tai esimerkkikoodia palvelun hyödyntämisestä. Esimerkki standardikohtaisesta välinepaketista on esitetty lähteessä (Komulainen, Tuomainen 2002) ja sen käyttökokemuksia luvussa 6.2. Ulkoisilla kirjastoilla tai adaptereilla (esim. palvelun tarjoajan tarjoamat adapterit eri tekniikoille) tapahtuva ratkaisun liittäminen omaan sovellukseen. Itse ohjelmoimalla suoraan tapahtuva toteutus tarvitaan, ellei muita sopivia välineitä tai malleja ole saatavilla. Itse toteutettavan integrointiratkaisun toteutus sovellukseen kannattaa usein tehdä omana kokonaisuutenaan tai omana moduulina / kirjastona / adapterina, jolloin sen uudelleenkäyttö muissa omissa sovelluksissa on helpompaa. Integrointiratkaisuun liittyvät toteutuskohtaiset asiat on syytä dokumentoida huolellisesti. Ratkaisun käyttöönoton kannalta dokumentoitavia seikkoja on listattu Toteutuksen kuvaus-mallissa (Mykkänen ym.2004a), jota voidaan käyttää näiden seikkojen kuvauksen pohjana. Toteutuksen kuvauksesta tulisi käydä ilmi (tarkempi runko edellä mainitussa dokumentissa): Toteutuksessa käytettävien toteutuskohtaisesti valittujen ratkaisujen ja välineiden aiheuttamat vaatimukset sovelluksen tuotantoympäristölle. 16 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 5

17 Toteutetun ratkaisun käyttöönotossa ja asentamisessa tarvittavat toimenpiteet (ohjeet) Ylemmän tason (esim. teknisissä liittymämäärittelyissä) toteutuskohtaisiksi jätettyjen asioiden ratkaisut tehdyssä toteutuksessa Se, miten toteutus vastaa toteutuksille asetettuihin toiminnallisiin ja varsinkin ei-toiminnallisiin integrointivaatimuksiin Ennen käyttöönottoa sovellus on testattava huolellisesti. Testausta varten voi olla saatavilla erityisiä välineitä, testipalveluita tai valmiita testimäärittelyitä (testitapaukset, raporttipohjat). Sovellus voidaan joissain tapauksissa myös sertifioida (varmistaa ulkoisella osapuolella että sovellus toimii integrointimäärityksen mukaisesti), jos tällaisia palveluita on saatavilla. PlugIT-projektissa on kehitetty käytäntöä myös määrittelyjen mukaisuuden testausta varten, joka voi toimia pohjana sertifioinnille (ks. luku 3). Jos toteutuksista saatuja kokemuksia ja lisätarpeita kerätään järjestelmällisesti, voidaan kehittää integrointiprosessia myöhempiä projekteja varten. Toteutuskokemukset ja määrityksissä havaitut aukot ovat erittäin arvokkaita myös määritysten tekijöille ja standardointiorganisaatioille määritysten uusia versioita varten Paikallinen sovitus Suurin osa integroinnin kannalta ratkaistavista asioista tulisi pyrkiä joko sisällyttämään avoimiin integrointimäärityksiin ( integrointiprofiilit, integrointiratkaisut ) tai vakioimaan tuote- ja sovelluskohtaisesti. Toisinaan kuitenkin jää joitakin seikkoja, jotka on sovittava paikallisten (käyttöympäristön tai vastinkappaleena toimivan sovelluksen) vaatimusten ja ratkaisujen mukaisesti. Oman integrointitoteutuksen uudelleenkäyttöä eri ympäristöissä helpottaa, jos nämä ratkaisut voidaan erottaa avoimesta integrointiratkaisusta tai parametroida toteutuksissa. Jos tiedetään, mikä on omaan sovelluksen tehdyn integrointiratkaisun vastinkappale (esim. palvelua tarjoava sovellus), pitäisi erityisesti tarkistaa: Onko vastinkappaleen Toteutuksen kuvaus -dokumentissa (ks. luku 2.2.4), käyttöönotto-ohjeissa tai muussa dokumentaatiossa asioita, jotka vaikuttavat toteutukseen tai sovitukseen (vaadittavat lisäpiirteet, toteutuskohtaiset käytännöt). Onko vastinkappale sertifioitu (määrityksen mukainen), jolloin voidaan varmemmin luottaa siihen että se toimii täsmälleen integrointimäärityksen tai standardin mukaisesti. Sovelluksen sertifikaatissa tai conformance statement -lausunnossa on mainittava, mitkä määrityksen roolit ja rajapinnat on toteutettu. Käyttöönottoon liittyen voi lisäksi olla paikallisia vaatimuksia, joihin ei vastata liittymämäärittelyssä: Näiden vaatimusten toteutuksessa voidaan käyttää usein muita määrityksiä tai määritellä paikallinen tai tuotekohtainen integrointiratkaisu. Tämä ratkaisu voidaan toteuttaa samalla kuin avoin integrointiratkaisu, mutta se on syytä erottaa selkeästi avoimesta ratkaisusta. Integrointiratkaisujen määrittelyyn PlugIT-projektissa kehitetty menetelmä (Mykkänen ym. 2004a) on käytettävissä myös tällaisissa tilanteissa. Ympäristökohtaisesti saatetaan joutua tekemään poikkeamia avoimen määrittelyn mukaisiin malleihin. Tällöin tuotettu ratkaisu ei enää toimi yhteen puhtaasti avoimen määrittelyn pohjalta muiden sovellusten kanssa. Esimerkkejä tällaisista ratkaisuista ovat esim. paikallisen henkilötunnisteen käyttö määrityksessä käytetyn henkilötunnuksen sijaan. Samaan ratkaisuun osallistuvissa sovelluksissa on sovittava yhteisesti tällaisista poikkeamista, ja usein voidaan tarjota lisäksi standardin mukainen toteutus. AVOINTEN INTEGROINTIRATKAISUJEN HYÖDYNTÄMINEN, TOTEUTTAMINEN JA TESTAUS 17

18 2.2.6 Käyttöönotto Paikallisten vaatimusten lisäksi toisen toimittajan tai asiakkaan tietohallinnon kanssa selvitettäviä yksityiskohtia ovat erityisesti käyttöönottoon, koulutukseen ja versiointiin liittyvät asiat ja vastuut sekä järjestelmien tukemassa toiminnassa tapahtuvien muutosten järjestäminen (ks. myös Saranummi, Tolppanen 2003): Asennus- ja konfigurointiohjeet voivat olla ohjeistettuina esim. Toteutuksen kuvaus-dokumentin tyyppisesti tuotteen omassa dokumentaatiossa. Toteutetun integrointiratkaisun käyttöönoton ei pitäisi vaatia asennusohjeiden lisäksi muuta koulutusta käyttöympäristössä. Tuotekohtaiseen käyttäjä- tai ylläpitäjäkoulutukseen voidaan tietenkin lisätä myös integrointiratkaisuita käsitteleviä osia. Integrointiratkaisu on testattava paitsi toteutuksen tai sertifioinnin yhteydessä, myös lopullisessa käyttöympäristössä, ja se voi liittyä myös esimerkiksi asiakkaan hyväksymistestaukseen. Uusien versioiden käyttöönotossa on huolehdittava erityisesti siitä, että edellisiin versioihin tehdyt integrointiratkaisut toimivat muiden (vanhempaa versiota käyttäneiden) sovellusten kanssa (regressiotestaus), että rajapinnan muuttuessa versioiden käyttöönotto yhdenaikaistetaan, tai siirtymävaiheessa tuetaan sekä vanhaa että uutta integrointiratkaisua. 18 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 5

19 3 INTEGROINTITOTEUTUKSEN TESTAUS JA MÄÄRITTELYJEN MUKAISUUS Tämä luku kuvaa integrointitestauksen käsitteitä testauksen suorittamiseksi sekä antaa kuvan toimenpiteistä, joita on vaadittu sekä nk. PlugIT-leimaa hakevalta yritykseltä ja leiman myöntäjältä. PlugIT-leiman hakemisesta on luotu hallinnollisesti kevyt prosessi (nopea ja tuotetaan vähän dokumentteja), mutta määrittelyjen mukaisuuden testauksen osuus on silti kattavaa. PlugIT-leimaa ja PlugIT-määrittelyjen mukaisuuden testausta tarvitaan, koska tällä tavoin varmistutaan, että toteutukset/tuotteet ovat liittymien osalta määrittelyjen mukaisia ja määrittelystä löytyvien seikkojen osalta keskenään yhteensopivia. Luvussa käydään ensin läpi perusteita ohjelmistojen ja rajapintojen testaamiseksi sekä testauksen hallinnassa ja virheluokittelussa hyödyllisiä seikkoja. Sitten esitellään PlugiIT-hankkeessa rajapintojen testaukseen kehitetyn nk. PlugIT-leiman myöntämismenettelyn eri vaiheet ja annetaan esimerkkejä rajapintojen testauksessa käytetyistä testitapauksista ja testauspöytäkirjasta. 3.1 Yleistä ohjelmistotestauksesta Testauksen tarkoitus Testauksen avulla pyritään todistamaan ohjelman toiminta oikeaksi ts. ohjelmalle annetut syötteet saavat aikaan odotetut tulokset. Testaus on osa laadunvarmistusta, jossa tavoitteena on tuotteen verifiointi ja validointi. Verifioinnissa todennetaan onko tuote tehty oikein. Validoinnin tarkoituksena on todeta, onko tuote kelvollinen aiottuun tarkoitukseen eli toteuttaako se asetetut vaatimukset. Ohjelmistotestauksessa testaus-toimenpiteitä kuvataan usein ns. V-mallin pohjalta. Testaus kohdistuu ohjelmiston eri tasoille V-mallin rakeisuuden mukaisesti. Yksikkötestauksessa tutkitaan kooditasolla ohjelmistomoduulien oikeellisuutta. Integraatiotestauksen tarkoituksena on tutkia alisysteemien ominaisuuksia. Alisysteemi koostuu joukosta ohjelmistomoduuleita, joiden keskinäistä vuorovaikutusta tutkitaan. Testaus keskittyy moduulien ja niiden rajapintojen yhteistoiminnallisuuden tutkimiseen ja oikeellisuuden varmistamiseen. Systeemitestauksessa testataan koko systeemin toiminnallisuus olettaen, että ainakin tärkeimmät elementit ohjelmistosta on jo testattu. Systeemi koostuu esim. laitteistosta, ohjelmistosta, tietokannoista, ulkoisista laitteista ja ohjelmistoista (Paakki 2000). PlugIT-projektissa ei kuitenkaan ole testattu moduulien yhteentoimivuutta vaan eri toimittajilta tulevien sovellusten välistä integraatiota. Jos V-mallia sovelletaan tällaiseen integrointiin, yksikkötestaus vastaa sovellusten toimittajien omaa tuotetestausta, integrointitestaus PlugIT-leiman myöntämisprosessia ja systeemitestaus lopullisessa käyttöympäristössä tuoteryppään testaamista. Kaikki nämä testaustoimenpiteet ovat tarpeen sovellusten käyttöönoton ja integroinnin yhteydessä Testauksen hallinta Jotta testauksesta olisi hyötyä, on se kyettävä toteuttamaan suunnitelmallisesti. Tämä tarkoittaa sitä, että testaus on suoritettava systemaattisesti ja testauksessa käytetyt testitapaukset on valittava suunnitelmallisesti. Huonosti suunniteltu ja epämääräisten tai sattumanvaraisesti valittujen testitapausten avulla testattu ohjelma voi olla jopa huonompi kuin kokonaan testaamaton tuote, koska tällöin tes- AVOINTEN INTEGROINTIRATKAISUJEN HYÖDYNTÄMINEN, TOTEUTTAMINEN JA TESTAUS 19

20 taus ei kata koko tuotetta ja havaittujen virheiden korjaustoimenpiteet voivat synnyttää uusia ennalta arvaamattomia virheitä. On erittäin tärkeää pyrkiä siihen, että testaus on kattavaa eli kaikki ohjelman eri haarat on käyty mahdollisimman kattavasti läpi (Toroi ym. 2002). Testauksen tulee olla suunniteltu, määritelty ja raportoitu. Testaustulosten tulee vaikuttaa tuotteeseen koko sen elinkaaren aikana. Testaustoiminta alkaa suunnittelun alkaessa ja jatkuu läpi koko tuotteen eliniän. Suunnitelmallisessa testausprosessissa tuotetaan yleensä seuraavat minimidokumentit (Paakki 2000): Testaussuunnitelma (test plan), jossa kuvataan testauksen tarkoitus, tavoitteet, resurssit, aikataulu. Testitapausten määrittely (test-case specification) dokumentissa testitapauksista kuvataan syötteet ja tarvittavat tietokannat, tiedostot, yms., odotetut tulokset, ympäristön tarpeet sekä riippuvuudet muista testitapauksista. Esimerkkejä testitapauksista integrointimääritykselle löytyy luvusta Virheraportti (test-incident report) dokumentoi testausprosessin aikana havaitut virheet. Virheiden luokittelussa voidaan käyttää esim. luvun mukaista luokittelua. Testiraportti, ks. alla. Testiraportti sisältää yksityiskohtaisen kuvauksen testauksesta. Siinä kuvataan, mitä on testattu ja mitkä ovat todelliset tulokset verrattuna odotettuihin tuloksiin, konfiguraatio (minkä kanssa ja millä asetuksilla on testattu) sekä testausympäristö. Lisäksi testausraportissa kuvataan jokaisen testitapauksen läpimeno (pass/fail). Alla on testiraportin esimerkkirunko: 1. Yhteenveto: Kuvaa, mitä on testattu (tuote, versio), testiympäristö, konfiguraatio ja viittaukset muihin dokumentteihin (esim. testisuunnitelma, testitapaus-määrittely, virheraportti ja testilokit) 2. Muutokset: Kuvaa kaikki muutokset ja poikkeamat suunnitelmista 3. Kattavuusarviointi: Arvioi testauksen kattavuutta suunnitelmiin verrattuna 4. Yhteenveto tuloksista: Kuvaa vastaan tulleet ongelmat ja ratkaisemattomat ongelmat 5. Arviointi: Kuvataan testitapausten läpimeno (pass/fail) 6. Toiminnot: Yhteenveto suurimmista testaustoiminnoista 7. Hyväksyntä: Määrittelee, kuka hyväksyy tämän dokumentin (ja koko testaus vaiheen) Virheluokitus Virheistä täytyy raportoida sen luokka, vakavuus ja tyyppi. Virheen luokkana voi olla puuttuva toiminta, väärä toiminta tai ylimääräinen toiminta. Virheet voivat olla vakavuudeltaan eri asteisia. Jaloten (Jalote 1999) mukaan virhe on kriittinen, jos se vaikuttaa ohjelmiston aikatauluun. Kriittinen virhe voi myös estää käyttäjää käyttämästä ohjelmaa eteenpäin. Jos ohjelmassa esiintyy samantyyppinen virhe useassa moduulissa, on kyse suuresta virheestä. Silloin koko ohjelmaa joudutaan korjaamaan. Näin käy, jos ei esimerkiksi noudateta ohjelmointistandardeja. Suuri virhe voi myös estää käyttäjää etenemästä normaalilla tavalla, mutta käyttäjä voi kuitenkin edetä kiertoteitse. Pieni virhe on yksinäinen virhe, joka ei estä käyttäjän toimintaa, mutta se aiheuttaa epämukavuutta. Kosmeettinen virhe ei vaikuta mitenkään käyttäjän toiminnan etenemiseen. Se voi olla esimerkiksi esteettinen virhe tai kirjoitusvirhe käyttäjälle lähetetyssä viestissä. Testauksessa löytyvät tilanteet voidaan jakaa esim. seuraaviin virhetyyppeihin: datavirhe, dokumentointivirhe, rajapintavirhe, input/output-virhe, logiikkavirhe, syntaksivirhe, virhe toiminnallisuudessa, ihmisistä johtuva tekijä, ongelmia ylläpidettävyydessä, huono suorituskyky, standardin noudattamattomuus, virhe testitapauksessa, virhe testisuunnitelmassa, virheellinen testiympäristö, sekä muu virhe. 20 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 5

21 Jalote määrittelee virhetyypit seuraavasti: Looginen virhe: Looginen virhe aiheuttaa ohjelman virheellisen toiminnan. Looginen virhe voi olla esim. toistolauseen lopetusehdossa tai virhe voi aiheutua virheellisestä ohjelman määrittelystä. Dokumentointistandardissa oleva virhe: Yrityksillä on yleensä tietyt standardit, joiden mukaan ohjelmia kirjoitetaan. Jos standardeja ei noudateta, on toisten kirjoittamia ohjelmia vaikea lukea. Koodin toisto: Käytetään samaa koodilohkoa useassa eri paikassa. Toistettavasta koodista pitäisi tehdä aliohjelma, jota voidaan kutsua useasta eri paikasta. Käyttöliittymävirheet: Käyttöliittymä ei toimi odotetulla tavalla. Ihmiset tottuvat tiettyyn toimintalogiikkaan ja olettavat, että ohjelmat toimivat sen mukaisesti. Virheet suorituskyvyssä: Ohjelman suorituskyky on huono ja vasteajat ovat suuret. Ohjelmassa voi esiintyä myös muistinhallintaan liittyviä ongelmia. Uudelleenkäytettävyys: Ohjelmakoodia ei voida käyttää uudelleen. Tämä voi johtua esimerkiksi siitä, että toisen kirjoittamaa ohjelmakoodia ei ymmärretä. Analyysi- ja suunnitteluvirheet: Ohjelman suunnittelussa syntyvät virheet. Johdonmukaisuus: Ohjelma ei toimi johdonmukaisesti ohjelman jokaisessa vaiheessa. Jäljitettävyys: Ohjelman virheitä ei pystytä jäljittämään koodista. Siirrettävyys: Ohjelmakoodi on riippuvainen käyttöliittymästä eikä sitä pystytä siirtämään alustalta toiseen Testausmenetelmät Ohjelmiston testaus voidaan luokitella testattavan koodin näkyvyyden suhteen. Mustalaatikkotestauksessa (black-box) testaaja näkee ohjelmistosta ainoastaan sen tarjoamat rajapinnat tai käyttöliittymän. Harmaalaatikkotestauksessa (grey-box) joitakin piirteitä ohjelmiston rakenteesta (esim. vuokaaviot) on paljastettu testaajalle. Lasilaatikkotestauksessa (white-box) koko ohjelmisto lähdekoodeineen ja sen dokumentaatio ovat testaajan käytettävissä MUSTALAATIKKOTESTAUS Koska mustalaatikkotestauksessa ei pystytä näkemään ohjelmiston rakennetta, keskittyy testaus ohjelmiston käyttäytymiseen ts. siihen, kuinka se käyttäytyy, kun sille syötetään jokin arvo. Ohjelma tarjoaa rajapintansa kautta tietynlaisen syöteavaruuden (input space). Kaikkia syöteavaruuden syötteitä on mahdotonta testata kattavasti, koska aika ja resurssit ovat testauksessa rajalliset. Siksi syöteavaruus on kyettävä tutkimaan ja jakamaan järkevästi osajoukkoihin eli ekvivalenssiluokkiin (equivalence classes), joita kutakin voidaan tarkastella erikseen. Ekvivalenssiluokat pyritään muodostamaan siten, että jokainen syöte tietyssä ekvivalenssiluokassa suorittaa tietyn ohjelmapolun. Laittomille syötteille muodostetaan omat luokkansa. Kussakin luokassa syötteiden käyttäytymisen tulee olla samanlaista. Esim. kuntakoodia kysyttäessä ekvivalenssiluokat voisivat ohjelman toteutuksesta riippuen olla seuraavat: kelvollinen luokka (määrittelyalue ): kokonaisluvut väliltä (esim. 297 = Kuopio) kelvottomat luokat (määrittelyalueen ulkopuoliset syötteet): < 100 > 999 negatiiviset luvut laittomat luokat (eri tyyppiä kysytyn parametrin kanssa): merkkijono. AVOINTEN INTEGROINTIRATKAISUJEN HYÖDYNTÄMINEN, TOTEUTTAMINEN JA TESTAUS 21

22 Testitapaukset valitaan siten, että jokaisesta luokasta valitaan yksi tai muutama arvo testaukseen. Kustakin luokasta valitaan arvo, joka edustaa luokkaa. Käytännössä yhden arvon valitseminen ei riitä, vaan joudutaan tutkimaan ohjelman käyttäytymistä myös syötteiden raja-arvojen kohdalla. Tutkimuksissa on havaittu, että ohjelmat generoivat virheitä yleisimmin syötteistä, jotka ovat lähellä raja-arvoja kuin syötteistä, jotka ovat keskellä luokkaa. Raja-arvoanalyysin (boundary value analysis) avulla tutkitaan lähellä rajaa (tyypillisesti raja-arvo 1, raja-arvo, raja-arvo + 1) annettujen syötteiden antamia palautteita. Ongelmallisia ovat erityisesti avoimet rajat (open do-main) (esim. 0<A<5: sallitut arvot 1,,4) (Paakki 2000). Omana tyyppinään voidaan esitellä vielä käyttöliittymän testaus. Käyttöliittymätestaus on osa järjestelmä- ja hyväksymistestausta. Tällöin tutkitaan kuinka käyttöliittymä käyttäytyy eri tilanteissa ja kuinka käyttäytyminen vastaa odotettua tulosta. Käyttöliittymätestaukseen on apuvälineitä, joiden avulla testitilanne voidaan nauhoittaa ja tarkastella sitä myöhemmin, esim. regressiotestauksen yhteydessä LASILAATIKKOTESTAUS Lasilaatikkotestauksessa keskitytään koodin toiminnan seuraamiseen. Koodi ja sen rakenne ovat testaajan käytettävissä. Lasilaatikkotestaus on ohjelmistosuunnittelijan ja ohjelmoijan menetelmä koodin oikeellisuuden toteamiseksi. Se ei sovellu ohjelmistojen ja niiden rajapintojen testaukseen sovelluksissa, joiden lähdekoodia ei ole saatavilla. Testauksessa tutkitaan ohjelmistoa ja erityisesti siinä suoritettujen lauseiden ja lauseille ja parametreille annettavien ehtojen toteutumista. Ohjelma pyritään testaamaan mahdollisimman kattavasti. Erilaisia kattavuuskriteerejä ovat esim. seuraavat (Paakki 2000): lausekattavuus (statement coverage) päätöskattavuus (branch decision coverage) ehtokattavuus (condition coverage) moniehtokattavuus (multicondition coverage) polkukattavuus (path coverage) JÄRJESTELMIEN VÄLINEN INTEGROINTITESTAUS Eri valmistajien ohjelmistojen yhteistoiminnallisuuden testaus tapahtuu mustalaatikkotestauksena, koska käytettävissä ei ole toisen valmistajan koodia vaan ainoastaan ohjelmistojen välinen rajapinta. Tällöin voidaan puhua integrointitestauksesta, jossa elementteinä ovat toisiinsa liittyvät systeemit. Integrointitestauksen tarkoituksena on varmistaa, että yhteisesti sovitut rajapinnat ovat käytettävissä ohjelmien välillä. Integrointitestauksessa rajapintaa tutkitaan valittujen testitapausten avulla. Testauksen tavoitteena on varmistua, että rajapinta käyttäytyy oikein, kun sille annetaan syöte. Integrointitestaus ei tutki sitä, ovatko saadut syötteet sisällöllisesti järkeviä, vaan ainoastaan onko ohjelman syötteelle generoima vastaus odotusten mukainen. Tämä tarkoittaa sitä, että jos jollakin syötteen arvolla on odotettavissa virhe eli poikkeus, se myös generoituu vastaukseen tai jos pyydetään toimittamaan esim. potilaan tiedot, ne myös saadaan. Ohjelmistotoimittajan on testattava kunkin ohjelman rajapinnan takana oleva toiminnallisuus ja sen oikeellisuus ennen järjestelmien välistä integrointitestausta. 22 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 5

23 3.2 PlugIT-leima Yleistä PlugIT-leimasta PlugIT-leima myönnetään tuotteelle (tuotteen versiolle), joka on PlugITrajapintamääritysdokumentin mukainen. Leima on merkki siitä, että tuote on läpäissyt avoimen integrointimäärityksen mukaisuutta testaavat testit ja että tuotetta on kokeiltu yhdessä toisen samaa määritystä hyödyntävän ohjelmiston kanssa. Leima on myös merkki siitä, että tuotteen dokumentaatio (esim. asennus- ja käyttöönotto-ohjeistus) sisältää riittävät tiedot integrointiratkaisun käyttöönottamiseksi. Leiman myöntäjänä on toiminut PlugIT-projekti eikä sitä saa automaattisesti toteutusten ja ilmoitusten perusteella. Määrittelyjen mukaisuuden testaus ei poista toimittajan ja asiakkaan vastuuta tuotteen normaalista järjestelmä- ja integraatiotestauksesta. PlugIT-leiman hakijalla säilyy tuotevastuu. Määrittelyjen mukaisuuden testaus varmistaa, että rajapinta toimii testatussa ympäristössä, testatuilla syötteillä. Leimaa voi käyttää tuotteiden dokumentaatiossa ja markkinoinnissa tai vaatia tarjouspyynnöissä. Leiman mallina on käytetty mm. luvun 3.1 mustalaatikkotestauksessa tarvittavia tietoja, eri standardien ja määritysten Conformance statement-osioita ja IHE:n (Integrating Healthcare Enterprise) Connectathon-käytäntöä, (ks. Mykkänen ym. 2004a, luku 1.3.3; HIMSS, RSNA 2002). Myönnetyt leimat ja niihin liittyvät testaustiedot on PlugIT-hankkeessa julkistettu hankkeen wwwsivuilla. Leima sisältää seuraavat tiedot: Tuote ja tuotteen versio, jolle leima on annettu Leima annetaan vain kyseiselle toteutuksen versiolle, se ei siirry automaattisesti seuraavien toteutusten versioihin Jos integrointiratkaisun sisältävää moduulia, jota on käytetty leimatussa tuotteessa, käytetään (sellaisenaan) uusissa tuoteversioissa, uusi versio ei saa automaattisesti leimaa, koska integrointiratkaisun toimivuus riippuu usein sisällöstä ohjelmiston muiden (mahdollisesti muuttuneiden) osien kanssa. Määrittelyn versio ja taso, johon toteutus pohjautuu Mille ominaisuuksille leimaa haetaan; toteuttaja voi esim. määritellä, mille tasoille se hakee leimaa, jos ko. määritysdokumentti sisältää useita tasoja (conformance levels) Mikä määrityksessä mainittu rooli (esim. palvelua tarjoava tai käyttävä sovellus) on tuotteen osalta toteutettu Leiman tiedot (myöntöpäivämäärä jne.) PlugIT-leimoja on myönnetty vain Tekninen liittymämäärittely (ks. Mykkänen ym. 2004a) dokumenttitasolta tehdyille integroinnin toteutuksille, koska vasta saman teknisen rajapinnan toteuttavat ohjelmistot toimivat yhdessä suoraan, ilman eri tekniikoiden vaatimaa sovitustyötä. Leimaa on järkevää myöntää ja hakea tuotteelle lähinnä suhteessa hyväksyttyyn määritykseen (tai luonnoksen pohjalta, joka on menossa hyväksyttäväksi), ks. myös kuva 3.1. Leiman antamista varten on määritelty kevyt määrittelyjen mukaisuudesta varmistumisprosessi (luku 3.2.2), jonka tavoitteena on edesauttaa testauksen yhdenmukaisuutta ja toistettavuutta, ja olla riittävän kattava leiman käyttämiseksi määrittelyjen mukaisuudesta varmistumiseen myös asiakkaille. AVOINTEN INTEGROINTIRATKAISUJEN HYÖDYNTÄMINEN, TOTEUTTAMINEN JA TESTAUS 23

24 3.2.2 Prosessin vaiheet Haettaessa leimaa on kuvattava: Mille hakijan ohjelmistoversiolle leimaa haetaan. Mille ja minkä tasoisille rajapinnoille hyväksyntää haetaan. Kenelle leima tai tieto tarvittavista lisätoimenpiteistä toimitetaan. Leiman myöntämisprosessi koostuu neljästä vaiheesta: 1. Haettavan sovelluksen toteuttamat rajapinnat noudattavat testattavaa määritystä. Hakijan on toimitettava Toteutuksen kuvaus dokumentti leiman myöntäjälle (ks. luku ) 2. Hakija suorittaa ohjelmistotestauksen leiman myöntäjän toimittamalla ja omalla testiaineistollaan, pyrkimyksenä varmistaa ratkaisun toimivuus omassa tuotteessaan ja varmistua myös siitä että ratkaisu on määrityksen mukainen. 3. Leiman myöntäjä suorittaa lisätestausta käyttäen hyväksi esimerkiksi referenssitoteutuksia tai testausohjelmistoa tuotteen ja määritysten yhteensopivuuden varmistamiseksi erikseen sovittavassa, esim. hakijan osoittamassa ympäristössä. Testauksesta tuotetaan testauspöytäkirja, josta käy ilmi ohjelmistokohtaiset asetukset ja erityispiirteet, suoritetun testin tiedot sekä testitapaukset operaatioittain. Hakijan tulee olla varautunut siihen, että myöntäjä esittää mahdollisia lisäkysymyksiä ohjelmistosta. 4. Myöntäjä myöntää leiman ja toimittaa sen toimittajan nimeämälle yhteyshenkilölle Toimenpiteet Leimausmenettelyn toimenpiteet tarkemmalla tasolla: 1. Ilmoitus toteutuksesta ja Toteutuksen kuvaus: tarkoitus: avoimen integrointiratkaisun toteutusilmoitus Tämän jälkeen voidaan ilmoittaa että integrointiratkaisu on toteutettu tuotteeseen, mutta tämä vaihe ei ole varsinainen leima (leima tarkoittaa että toteutus on määrittelyjen mukainen ja on läpäissyt avoimen integrointimäärityksen mukaisuutta testaavat testit), ks. kuva 3.1. Toteutuksen kuvaus-dokumentin avulla (Mykkänen ym. 2004a) tarkastetaan onko määritellyt ominaisuudet (rajapinnat, metodit jne.) toteutettu tuotteeseen. Ilmoitetaan, mille määritykselle (ja määrityksen tasoille), mille tuotteelle ja tuoteversiolle leimaa haetaan. Toteutuksen kuvaus saadaan määrittelyjen toteutuksen sovellukseen rakentaneelta osapuolelta. Se on osa tuotedokumentaatiota ja toimitetaan leiman myöntäjälle tai on julkisesti saatavilla esim. toimittajan kautta. Toteutuksen kuvaus-dokumentin sisältö ks. (luku 2.2.4, Mykkänen ym. 2004a), malli dokumentin sisällöstä dokumentin muoto vapaa, tuote/toimittajakohtainen ei sisäisen toteutuksen yksityiskohtia, vaan yhteentoimivuuteen, integrointiin ja käyttöönottoon liittyvät tuotekohtaiset seikat: minkä määrityksen, määritysversion ja minkä määritysten tasojen toteutus on kyseessä miten toteutus vastaa toteutuskohtaisiksi määrityksissä jätettyihin vaatimuksiin ja kohtiin toteutuskohtaiset lisäykset, tarkennukset ja laajennukset avoimiin määrityksiin, poikkeamat (perusteluineen) ja toteutuskohtaiset rajoitteet toteutuksen vaatimukset tekniselle ympäristölle 24 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 5

25 käyttöönotto, asennus, integrointia varten asetusten tekeminen ja konfigurointi ylläpito, uudet versiot, tukipalvelut, yhteystiedot mahdollisesti käyttöesimerkkejä. 2. Leiman hakijan suorittama toteutettujen määrittelyjen testaaminen tarkoitus: määrittelyjen mukaisuuden varmistaminen, mahdolliset korjaukset tuotteeseen ennen leiman lyöntiä Toteuttaja testaa omaa toteutustaan leiman myöntäjältä saatavilla testitapauksilla (esimerkkejä luvussa 3.2.4) sekä oman ohjelmiston kannalta olennaisilla testeillä. Tulokset voidaan dokumentoida testausraporttiin, joka toimitetaan myöntäjälle, mutta tätä ei ole vaadittu PlugIT-leimauskäytännössä. Leiman kannalta on olennaista testata vain rajapintamäärittelyjen osalta, ei koko toteutusta, tuotteeseen tehtyjä lisäominaisuuksia ym., mutta saman testauksen yhteydessä hakija voi luonnollisesti suorittaa myös toteutuskohtaisten piirteiden testausta. Palaute määrittelyjen tekijöille toteutuksista ja niiden testauksesta toivottavaa määritysten jatkokehityksen kannalta. Testauksessa voi olla mahdollista käyttää myös saatavilla olevia referenssitoteutuksia (esim. leiman myöntäjän tai standardoijan tuottamia). Myöntäjälle mahdollisesti toimitettua testiraporttia ei laiteta julkisesti saataville, sitä käytetään pohjana leiman antamiselle. Testiraportin sisältö (ks. luku 3.1.2) 3. Leiman myöntäjän suorittama testaus tarkoitus: täydentää ja varmistaa toteuttajan tekemää testausta, varmistua ratkaisun toimivuudesta ja avoimuudesta käytännössä. Viimeinen vaihe, jonka perusteella leima myönnetään Läpäistystä leimaustestauksesta tuotetaan testauspöytäkirja, joka sisältää yhteenvedon suoritetuista testeistä ja niiden läpäisystä. Pöytäkirja noudattaa testausraportin sisältörunkoa. Leiman myöntäjällä on mahdollisuus testata, esim. palvelutoteutusta referenssitoteutusasiakassovelluksella. Myös tämä vaihe on pakollinen leiman kokeiltu puolueettomasti eri toteutusten yhteentoimivuutta merkityksen saavuttamiseksi Testauksen toteutus käytännössä: palvelua käyttävän sovelluksen testaaminen palvelun referenssitoteutuksella tai erillisellä testisovelluksella palvelua tarjoavan sovelluksen testaaminen palvelua käyttävän sovelluksen referenssitoteutuksella tai erillisellä testisovelluksella testausympäristönä toimittajan osoittama ympäristö (tuotekehitys- tai käyttöympäristö) tai erikseen sovittaessa esim. laboratorioympäristö tai testausta varten pystytetty ympäristö mahdollista testata myös yhteentoimivuutta jo leiman saaneen tuotteen kanssa ei välttämättä kaikkien tai samojen testitapausten läpikäyntiä kuin vaiheessa 2 tarkastellaan myös dokumentaation riittävyys integrointiratkaisun käyttöönottamiseksi. Yksityiskohtaiset testiraportit eivät ole välttämättä julkisia, vaan pelkästään testaajan ja toteuttajan käytössä, mutta läpi menneestä testauksesta on PlugIT-hankkeessa julkistettu testauspöytäkirja (yhteenveto), josta näkyvät suoritetut testit ja niiden läpäisy (ks. luku 3.2.5). Tuloksena on myönnetty (julkinen) leima tai kehitysehdotukset toteutukselle tai sen dokumentaatiolle. AVOINTEN INTEGROINTIRATKAISUJEN HYÖDYNTÄMINEN, TOTEUTTAMINEN JA TESTAUS 25

26 Määrittelydok umentti Luonnos uusi versio hyväksyminen Hyväksytty julkistus julkistus Julkinen uusi versio toteutus toteutus toteutus Toteutettu uusi versio (Saatavilla) määrittelyn toteutus testaus, tarkastus Määrittelyä noudattava Ohjelmisto Leima Määrittelyjen mukaisuudesta varmistuminen Kuva 3.1. Ohjelmiston (alla) suhde määrittelydokumentteihin (yllä), ja määrittelyjen mukaisuudesta varmistuminen PlugIT-hankkeessa Esimerkkejä kontekstinhallintapalvelimen testitapauksista Seuraavassa esitellään muutama esimerkki kontekstinhallintapalvelimen testitapauksista (lisää esimerkkejä ks. Virkanen ym. 2004a). Esimerkit pohjautuvat Minimitason kontekstinhallinnan määrittely -dokumentin versioon 1 (Tuomainen 2003). Aluksi testataan muutama yleinen kontekstinhallinnan toimenpide: kontekstiin liittyminen, arvon asettaminen kontekstiin sekä arvon hakeminen kontekstista. Seuraavaksi testataan tyypillinen virhetilanne, jossa istunnon tunnistamiseen käytettyä kuponkia käytetään kontekstista poistumisen jälkeen. Lopuksi on vielä usean sovelluksen toimintoketjua havainnollistava esimerkki, jossa kaksi client-sovellusta liittyvät yhtä aikaa samaan kontekstipalveluun eri työasemista. Testitapaukset on taulukoitu siten, että niistä kerrotaan yleisen kuvauksen lisäksi esiehdot, syöte ja tulos sekä menikö testi läpi vai ei. Syöte on annettu URL-muodossa, joka soveltuu kyseisten rajapintojen testaukseen. Testauksessa osa arvoista täytyy parametrisoida testiajokohtaisesti, esim. IP-osoite ja monet sallittujen parametrien arvoista. Osalla testisyötteistä voi lisäksi olla arvoja, jotka saadaan vasta tiettyjen operaatioiden suorituksen tuloksena (esimerkissä participant- Coupon-parametri). Tällaisia syötteitä ei tietenkään voida lyödä lukkoon testimateriaalissa. Esimerkistä käy ilmi mm. se, että joissakin tapauksissa (kuten kontekstipalvelussa) on syytä dokumentoida tarkasti esiehdot, esim. missä järjestyksessä eri operaatioita kutsutaan. Joissakin testauksissa (tilattomat palvelut) eri operaatioita voitaisiin sen sijaan kutsua vapaassa järjestyksessä. 26 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 5

27 JoinCommonContext Taulukko 3.1. Kontekstipalvelun testitapauksia. Kuvaus: Esiehto: Input: Output: Pass/Fail: Kontekstiin liittyminen. Sovelluksen nimi tulee olla sallittu ja samalla sovellusnimellä ei ole kirjauduttu kontekstinhallintaan. text&applicationname=loginmaster participantcoupon= SetItemValues Kuvaus: Esiehto: Input: Output: Pass/Fail: Yhden arvon asetus kontekstiin Sovellus on liittynyt kontekstiin, itemin nimi sallittu toteutuksessa, participantcoupon on liittymisestä saatu cipantcoupon= &itemnames=patient.id.nationalidnumber&itemvalues= XXXX Tyhjä GetItemValues Kuvaus: Esiehto: Input: Output: Pass/Fail: Haetaan itemin arvo kontekstista. Sovellus on liittynyt kontekstiin, haettava item on asetettu, participantcoupon on liittymisestä saatu. cipantcoupon= &itemnames=patient.id.nationalidnumber itemvalues=patient.id.nationalidnumber XXXX Kupongin käyttö kontekstista poistumisen jälkeen. Kuvaus: Esiehto: Input: Output: Pass/Fail: Kupongin käyttö poistumisen jälkeen. Sovellus on poistunut kontekstista, participantcoupon on vanhentunut. cipantcoupon= &itemnames=patient.id.nationalidnumber esim. exception=generalfailure&exceptionmessage=yleinen virhe AVOINTEN INTEGROINTIRATKAISUJEN HYÖDYNTÄMINEN, TOTEUTTAMINEN JA TESTAUS 27

28 Kaksi client-sovellusta yhtä aikaa samaan kontekstipalveluun eri työasemista. Kuvaus: Esiehto: Input: Sovellus 1: Input: Sovellus 1: Input: Sovellus 2: Input: Sovellus 2: Input: Sovellus 1: Output: Sovellus 1: Pass/Fail: Kaksi client-sovellusta yhtä aikaa samaan kontekstipalveluun eri työasemista. Itemin nimi sallittu toteutuksessa. ontext&applicationname=loginmaster (join) ticipantcoupon= &itemnames=patient.id.nationalidnumber&item- Values= ZZZZ (set) ontextwithip&applicationname=loginmaster&hostaddress= (join, HUOM eri ip) ticipantcoupon= &itemnames=patient.id.nationalidnumber&item- Values= ABC (set, HUOM eri ip) ticipantcoupon= &itemnames=patient.id.nationalidnumber itemvalues=patient.id.nationalidnumber ZZZZ (=Sovellus 1 set) Testauspöytäkirja Testauspöytäkirjassa kuvataan suoritetun testin tiedot, ohjelmistokohtaiset asetukset ja erityispiirteet sekä suoritetut testitapaukset operaatioittain määritykseen verrattuna. Suoritetun testin tiedoissa kuvataan toimittajan ilmoittamat tiedot testatusta tuotteesta ja versiosta, testattu rajapinta ja sen versio, sovelluksen rooli integrointiratkaisussa sekä testaajat ja testauspäivämäärä. Toimittajan ilmoittamia ohjelmistokohtaisia asetuksia, joita kannattaa huomioida kontekstinhallinnan integraatiossa, jossa osapuolena on testattu sovellus ovat esim. seuraavat: Mitkä itemnamet ovat sallittuja User.Id.Logon asetuksen periaate (mikä sovellus on nk. luotettu sovellus) sallitut sovellusten nimet, rajoitukset, parametrisointi (app1, app2, appn) http content type (sisään, ulos) merkistö (sisään, ulos) palvelun osoite parametrien sisältöjen muodon oikeellisuuden tarkastus liittyvien sovellusten lukumäärä (työasema/palvelukohtainen) asennus ja asennusohjeet Lisäksi ilmoitetaan, jos on jotain erityishuomioita, joita pitää ottaa huomioon integrointiratkaisua käyttöönotettaessa (esim. erilaiset tulkinnat, jos määrityksissä on tulkinnanvaraa). Testitapaukset kuvataan samalla periaatteella kuin kappaleessa Testitapausten suoritus (kutsut ja paluuarvot) on kirjoitettu lokitiedostoon testaavan sovelluksen toimesta ja niiden avulla testien suoritusta voidaan tarkastella myös jälkikäteen. Lokitiedostot eivät ole julkisia. 28 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 5

29 Taulukko 3.2 Esimerkki JoinCommonContext-metodin testauspöytäkirjamerkinnästä. Kuvaus: Kontekstiin liittyminen. Esiehto: Sovelluksen nimi tulee olla sallittu. Input: loki: txt, rivit: 1-7 Output: loki: txt, rivit: 8-11 Huomioita: Pass/Fail: Pass Yhteenveto PlugIT-hankkeen leimausmenettelyn tavoitteena on ollut, että leiman myöntämisprosessi on kevyt ja nopea prosessi ja toisaalta prosessissa varmistetaan, että ohjelmisto täyttää rajapintojen osalta hankkeelle ja sen tuotoksille asetetut määrittelyjen mukaisuus- ja avoimuusvaatimukset. Tässä dokumentissa kuvattua määrittelyjen mukaisuudesta varmistumisprosessia kehitetään edelleen mm. Tekesille ehdotetussa jatkohankkeessa (AVOINTA-hanke), ja sitä voidaan soveltaa myös muiden kuin PlugIT-projektin määrittelyjen mukaisuudesta varmistumisessa. AVOINTEN INTEGROINTIRATKAISUJEN HYÖDYNTÄMINEN, TOTEUTTAMINEN JA TESTAUS 29

30 4 KONTEKSTINHALLINTA-ESIMERKIT PlugIT-hankkeessa on tuotettu avoimia rajapintamäärityksiä työpöytäintegraatiota varten kontekstinhallinnan rajapintojen avulla. Kyseessä on käyttäjälähtöinen integraatio, jonka avulla pyritään parantamaan usean yhtä aikaa loppukäyttäjän työasemalla auki olevan sovelluksen käytettävyyttä. Kontekstinhallintaratkaisujen avulla voidaan saavuttaa mm. kertakirjautuminen sovelluksiin sekä käyttäjän kannalta automaattinen tai helppo siirtyminen samaan potilaaseen tai muuhun käsiteltävänä olevaan asiaan eri sovelluksissa. Kontekstinhallintaratkaisut eivät poista esimerkiksi sovelluksissa sijaitsevaa päällekkäistä tietoa, mutta helpottavat ja tehostavat merkittävästi käyttötilanteita, joissa sama käyttäjä käyttää useita sovelluksia yhtä aikaa tai tietyn tehtävän hoitamiseen. PlugIT-hankkeen kontekstinhallintaratkaisussa on sovellettu HL7:n CCOW-standardia ja määritelty yksinkertainen hajautettu kontekstipalvelu, johon eri tekniikoilla toteutetut tietyllä käyttäjän työasemalla sijaitsevat (esim. Windows- ja web-pohjaiset) sovellukset on helppo liittää. Määritelty ratkaisu kuvataan tarkasti raportissa (Tuomainen ym. 2004). Tässä luvussa esitellään kyseisen määrityksen pohjalta tehtyjä toteutuksia, joilla havainnollistetaan palveluiden hyödyntämistä, toteutusta ja testausta eri sovelluksissa. Tässä esiteltävien toteutusten lisäksi hankkeessa tuotettiin esimerkki kontekstipalveluun liittymisestä Java- ja JSPtekniikoilla toteutetusta web-sovelluksesta, jota kuvataan luvussa Kontekstinhallinnan.NET-asiakassovellus Tässä esimerkissä käsitellään PlugIT-kontekstihallinnan määrityksen mukaista integrointiratkaisua. Esimerkki sisältää tilanteen, jossa Visual Studio.NET-välineillä (ks. Karvinen ym. 2004) tehty sovellus liitetään ulkoiseen, määrittelyn mukaiseen kontekstinhallintapalveluun siten, että sovellukseen saadaan käyttäjä- ja potilaskontekstin tahdistus muiden samalla työasemalla toimivien ja samaa kontekstipalvelua käyttävien sovellusten kanssa. Kontekstinhallinnan.NET-asiakassovellusta (Mäki 2004a) käytetään potilaiden tietojen hakemiseen ja muokkaamiseen. Sovellus on toteutettu Microsoft Visual Studio.NET 2003 sovelluskehittimellä. Käytetty ohjelmointikieli on C# ja sovelluksen tyyppi Windows Application. Sovellus käyttää MS Access tietokantaa ja ODBC-tietokantarajapintaa. Sovellusta voidaan käyttää Minimitason kontekstinhallinnan määrittely Versio 1.0 määrittelyn (Tuomainen 2003) minimitoteutuksen mukaisen kontekstipalvelun kanssa tai ilman sitä. Sovelluksen käyttöä voidaan myös jatkaa ilman kontekstipalvelua, jos se lakkaa vastaamasta kesken sovelluksen suorituksen. Sovellus sisältää tiedostot Testi1.exe ja Kontekstipalvelu.txt. Testi1.exe on itse sovellus ja Kontekstipalvelu.txt sisältää kontekstipalvelun käyttämistä varten asetettavat tiedot. Sovelluksen parametreiksi asetettavat tiedot ovat kontekstipalvelun URL-osoite sekä nimi, jota sovellus käyttää liittyessään kontekstipalveluun (esim. LoginMaster). Sovelluksessa on kolme lomaketta: päälomake sekä kirjautumis- ja hakulomakkeet (kuva 4.1). Kirjautumislomakkeella käyttäjä kirjautuu sovellukseen. Päälomakkeella käyttäjä voi katsella ja muokata potilaan tietoja. Päälomakkeelta käyttäjä voi myös siirtyä hakulomakkeelle, jossa voi hakea listan potilaista erilaisilla hakuehdoilla ja valita hakutuloksista potilaan käsiteltäväksi päälo- 30 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 5

31 makkeella. Päälomakkeelta (tai kirjautumislomakkeelta) käyttäjä voi myös poistua sovelluksesta. Sovelluksessa on kolme lomakeluokkaa: Potilas, Login ja Haku, jotka toteuttavat lomakkeet. Päälomake Kirjautumislomake Hakulomake Kuva 4.1. Kontekstinhallinnan.NET-asiakassovelluksen lomakkeiden viittaussuhteet Sovellus vaatii käyttäjän sisäänkirjautumisen, jos sovellus ei voi liittyä kontekstiin tai kontekstiin ei ole asetettu käyttäjää. Käyttäjien ja potilaiden tiedot ovat sovelluksen omassa tietokannassa. Sovelluksesta on dokumentoitu tarkasti.net-välineillä tehdyn toteutuksen yksityiskohdat malliksi vastaavien tai vastaavan tyyppisten integrointiratkaisujen toteuttamiseksi (Mäki 2004a), ja tuotettu lisäksi myös erillinen käyttöönoton ja sovelluskohtaiset ominaisuudet dokumentoiva Toteutuksen kuvaus dokumentti (Mäki 2004b) Potilas-luokka Luokka Potilas toteuttaa sovelluksen päälomakkeen, jolla käyttäjä voi katsella ja muokata potilaan tietoja. Tämä luokka sisältää lomakkeen toiminnot toteuttavien metodien lisäksi sovelluksen Mainmetodin, metodit kontekstipalvelun käyttämiseksi (ks. luku 4.1.5) sekä kaksi apumetodia. Kuva 4.2. Kontekstinhallinnan.NET-asiakassovelluksen päälomake Sovelluksen käynnistyessä Main-metodissa liitetään sovellus kontekstipalvelun kontekstiin (join- CommonContext-metodi) ja tarkistetaan kontekstipalvelusta kontekstiin asetettu käyttäjä (getitem- Values-metodi). Jos käyttäjä on asetettu kontekstiin (kirjautunut jo jollakin muulla sovelluksella kontekstiin), kirjautumista sovellukseen ei vaadita ja sovelluksen käyttö alkaa suoraan päälomakkeella. Jos käyttäjää ei ole asetettu kontekstiin tai kontekstiin asetettua käyttäjää ei löydy sovelluk- AVOINTEN INTEGROINTIRATKAISUJEN HYÖDYNTÄMINEN, TOTEUTTAMINEN JA TESTAUS 31

32 sen omasta tietokannasta, avataan kirjautumislomake. Kirjautumisen jälkeen sovelluksen käyttö jatkuu päälomakkeella. Jos sovellusta käytetään luotettuna sovelluksena, ks. Minimitason kontekstinhallinnan määrittely Versio 1.0 (Tuomainen 2003), se asettaa kontekstipalvelun käyttäjäkontekstiin kirjautumislomakkeella kirjautuneen käyttäjän (käyttäjätunnuksen). Tässä sovelluksessa käyttäjäkontekstin asetukseen käytetään Kuopion yliopiston kontekstipalvelun referenssitoteutuksen käyttämää tapaa (SetItemValues-operaatiota, jonka toteuttaa tässä sovelluksessa setitemvalues-metodi). Jos potilas on asetettu kontekstiin (getitemvalues-metodi) lomakkeelle tultaessa (esim. sisäänkirjautumisen jälkeen tai toisesta sovelluksesta siirryttäessä), kyseisen potilaan tiedot haetaan tietokannasta päälomakkeelle. Potilas voidaan myös hakea hakulomakkeella. Jos potilas valittiin hakulomakkeella, sovellus asettaa valitun potilaan kontekstipalvelun potilaskontekstiin (setitemvalues-metodi) ja hakee hänen tietonsa tietokannasta päälomakkeelle. Sovelluksesta poistuttaessa poistutaan myös kontekstipalvelun kontekstista (leavecommon- Context-metodi). Apumetodit Potilas-luokassa on kaksi apumetodia. Metodi haekontekstipalvelujasovellus lukee Kontekstipalvelu.txt-tiedostosta kontekstipalvelun URL-osoitteen ja kontekstipalvelua kutsuvan sovelluksen nimen. Metodi haepotilaslomakkeelle hakee potilaan tiedot henkilötunnuksen perusteella päälomakkeelle tietokannasta Login-luokka Luokka Login toteuttaa sovelluksen kirjautumislomakkeen, jolla käyttäjä voi kirjautua sovellukseen antamalla käyttäjätunnuksen ja salasanan. Kuva 4.3. Kontekstinhallinnan.NET-asiakassovelluksen kirjautumislomake Haku-luokka Luokka Haku toteuttaa sovelluksen hakulomakkeen, jolla voidaan hakea potilaita tietokannasta ja valita heistä yksi käsiteltäväksi päälomakkeella. Haku voidaan suorittaa ilman hakuehtoja, tai hakuehtoina voidaan käyttää henkilötunnusta, sukunimeä tai etu- ja sukunimeä. Etu- ja sukunimen kanssa voidaan käyttää myös merkkijonon korvaavaa %-merkkiä korvaamaan osa merkkijonosta, esim. %lain%. 32 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 5

33 Kuva 4.4. Kontekstinhallinnan.NET-asiakassovelluksen hakulomake Tietokanta Kontekstinhallinnan.NET-asiakassovellus käyttää omaa MS Access tietokantaa, joka sisältää tietokantataulut Henkilotiedot ja Kayttaja. Tietokantataulujen kentät on esitelty kuvassa 4.5. Tietokantataulujen avainkentät ovat lihavoituina. Kuva 4.5. Kontekstinhallinnan.NET-asiakassovelluksen tietokannan tietokantataulut AVOINTEN INTEGROINTIRATKAISUJEN HYÖDYNTÄMINEN, TOTEUTTAMINEN JA TESTAUS 33

34 4.1.5 Metodit kontekstipalvelun käyttämiseksi Potilas-luokassa on kontekstinhallintapalvelun käyttämiseksi viisi metodia: joincommoncontext liittää sovelluksen kontekstiin. Se saa parametrina sovelluksen nimen ja palauttaa kontekstipalvelulta saamansa kupongin. leavecommoncontext poistaa sovelluksen kontekstista. Se saa parametrina kupongin eikä palauta mitään. setitemvalues asettaa käyttäjän ja/tai potilaan kontekstiin. Se saa parametrina kupongin sekä asetettavien tietojen nimet ja arvot, eikä palauta mitään. getitemvalues hakee kontekstiin asetetun käyttäjän ja/tai potilaan. Se saa parametrina haettavien tietojen nimet ja palauttaa kontekstipalvelulta saamansa tietojen nimiä vastaavat tietojen arvot. contactcontext hoitaa yhteyden kontekstipalveluun ja sitä käyttävät muut neljä metodia, joita puolestaan kutsutaan sovelluksen eri vaiheissa. Se saa parametrina merkkijonon, joka sisältää http-kutsussa käytettävän metodi- ja parametriosan, ja palauttaa http-kutsun vastauksen merkkijonona. Http-kutsujen metodi- ja parametriosa muodostetaan joincommoncontext-, leavecommoncontext-, setitemvalues- tai getitemvalues-metodissa. Http-kutsu luodaan contactcontext-metodissa seuraavasti: (HttpWebRequest)WebRequest. Create(this.kontekstipalvelu + parameters), jossa this.kontekstipalvelu on Potilasluokan muuttujaan tallennettu kontekstipalvelun osoite ja parameters parametrina saatu httpkutsun metodi- ja parametriosa. Metodi contactcontext lukee Http-kutsun HttpWebResponse-tyyppisen vastauksen ja palauttaa sen merkkijonoksi muunnettuna. Metodit joincommoncontext, leavecommoncontext, setitemvalues tai getitemvalues tarkistavat sisältääkö paluuarvona saatu merkkijono virheilmoitusta. Jos se sisältää virheilmoituksen, metodi näyttää sen MessageBox:lla. Lisäksi joincommoncontext palauttaa tyhjän merkkijonon ja getitemvalues-metodi tyhjän merkkijonolistan. Jos merkkijono ei sisällä virheilmoitusta, join- CommonContext-metodi palauttaa merkkijonon (kupongin) ja getitemvalues-metodi merkkijonolistan (pyydetyt arvot), joka on muodostettu vastauksesta käyttämällä erotinmerkkinä -merkkiä ja valitsemalla vain arvo-osat. Esimerkki: sovelluksen liittäminen kontekstiin Sovellus liitetään kontekstiin kutsumalla joincommoncontext-metodia. Sille annetaan parametrina sovelluksen nimi (esim. LoginMaster) ja se palauttaa kontekstipalvelulta saamansa kupongin. Yhteyden hoitamiseksi kontekstipalveluun se käyttää contactcontext-metodia. Metodi joincommoncontext kutsuu contactcontext-metodia käyttämällä parametrina merkkijonoa?interface=contextmanager&method=joincommoncontext&applicationname=, jonka perään on liitetty parametrina saatu sovelluksen nimi (esim. LoginMaster). Metodi contactcontext luo Http-kutsun seuraavasti: (HttpWebRequest)WebRequest. Create(this.kontekstipalvelu + parameters), jossa this.kontekstipalvelu on Potilas luokan muuttujaan tallennettu kontekstipalvelun osoite ja parameters contactcontext-metodin parametrina saama http-kutsun metodi- ja parametriosa. Http-kutsun sisällön tyypiksi asetetaan text/plain. Http-kutsun HttpWebResponse-tyyppinen vastaus muutetaan tavu kerrallaan merkkijonoksi ja palautetaan saatu merkkijono. Jos merkkijono alkaa tekstillä exception, joincommoncontext-metodi tulostaa virheilmoituksen MessageBox:lla (kontekstipalvelun palauttama exceptionmessage) ja palauttaa tyhjän merkkijonon. Muussa tapauksessa joincommoncontext-metodi palauttaa contactcontext-metodilta paluuarvona saadun merkkijonon (kupongin). 34 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 5

35 Metodin joincommoncontext paluuarvo on String-tyyppinen minimitason kontekstinhallinnan määrityksestä (ks. Tuomainen 2003) poiketen, koska http-viestit kulkevat merkkimuotoisena eikä ole toteutuksen kannalta merkityksellistä muuttaa kontekstipalvelulta saatua merkkimuotoista vastausta long-tyyppiseksi Eri vaiheissa tehdyt ratkaisut Luvun 2.2 (Avoimen määrityksen hyödyntämisen vaiheet) kannalta kontekstihallinnan.netasiakassovelluksessa on tehty seuraavat ratkaisut: Sovelluksen tarpeet ja integrointimäärityksessä kuvattu ratkaisu Sovellus on kontekstipalvelua käyttävä asiakassovellus Kontekstinhallinnan määrittelystä versiota 1.0 Sovellus käyttää ContextManager-rajapinnan operaatioita JoinCommonContext ja Leave- CommonContext sekä ContextData-rajapinnan operaatioita SetItemValues ja GetItemValues. Tekniikkariippumaton ratkaisu sovelluksen kannalta Sovellus liitetään kontekstiin sovellusta käynnistettäessä. Kontekstiin asetettu käyttäjä haetaan sovelluksen käynnistämisen yhteydessä sovelluksen kontekstiin liittämisen jälkeen. Käyttäjältä vaaditaan kirjautuminen jos käyttäjää ei ole asetettu kontekstiin. Käyttäjä asetetaan kontekstiin käyttäjän kirjauduttua onnistuneesti sovellukseen, jos kirjautumista tarvitaan. Kontekstiin asetettu potilas haetaan käyttäjän kirjauduttua sovellukseen (tai kontekstiin on jo asetettu käyttäjä) ja, kun sovellukseen siirrytään myöhemmin takaisin toisesta sovelluksesta. Potilas asetetaan kontekstiin, kun sovelluksessa on valittu käsiteltävä potilas. Sovellusta voidaan käyttää myös ilman kontekstipalvelua. Sovelluksen käyttöä voidaan jatkaa, vaikka kontekstipalvelu lakkaisi vastaamasta. Sovellus poistetaan kontekstista sovelluksen lopettamisen yhteydessä. Liittymätekniikan sovitus sovellukseen Kontekstipalvelua käytetään sovelluksessa kutsumalla metodeita joincommoncontext, leavecommoncontext, setitemvalues ja getitemvalues, jotka käyttävät metodia contact- Context yhteyden hoitamiseen kontekstipalveluun (ks. luku 4.1.5). contactcontextmetodissa on hyödynnetty.net-välineiden System.Net-kirjaston metodeita, joilla httpyhteys palveluun hoidetaan. Toteutuskohtaiset seikat ja testaus Toteutuskohtaisesti on toteutettu myös käyttäjän asettaminen kontekstiin SetItemValuesoperaatiolla käyttäen parametrina annettavan tiedon nimeä (itemnames) User.Id.Logon, jota käytetty kontekstipalvelun toteutus tukee. Toteutus luottaa siihen, että GetItemValues-operaatiota käytettäessä paluuarvon sisältämät nimi-arvoparit ovat nimen mukaan samassa järjestyksessä kuin parametrina annetut nimet. Http-viestien sisällössä käytetään text/plain -tyyppiä. Erillistä leimaustestausta ei suoriteta, vaan sovellusta testataan toteutuksen yhteydessä kontekstipalvelun referenssitoteutuksen kanssa. AVOINTEN INTEGROINTIRATKAISUJEN HYÖDYNTÄMINEN, TOTEUTTAMINEN JA TESTAUS 35

36 Paikallinen sovitus Kontekstipalvelu.txt-tiedostoon asetetaan käytettävän kontekstipalvelun URL-osoite sekä nimi, jota sovellus käyttää liittyessään kontekstipalveluun. Voisi olla tarpeen toteuttaa myös mahdollisuus määrätä, yrittääkö sovellus asettaa käyttäjäkontekstin sisäänkirjauksen jälkeen (ellei jokin muu sovellus ole asettanut käyttäjäkontekstia). Nykyisellään jos sisäänkirjausta tarvitaan, sovellus yrittää aina asettaa käyttäjäkontekstin. Käyttöönotto Asennus- ja konfigurointiohjeet löytyvät Toteutuksen kuvaus, Kontekstipalvelun MS Visual Studio.NET asiakassovellus, versio 1.0 -dokumentista (Mäki 2004b). 4.2 Olemassa olevan Musti-tekniikkaa käyttävän Delphisovelluksen liittäminen kontekstinhallintaan Kontekstipalvelun (Tuomainen 2004) testaamiseksi ja sovellusten liitettävyyden kokeilemiseksi kontekstipalvelu liitettiin FixIT-välineistössä (FixIT 2004) käytettyyn demosovellukseen, jolla käsitellään yksinkertaistettuja laboratoriotutkimus-, tulos-, yksikkö- ja henkilötietoja. Sovelluksen tarpeina kontekstipalvelun osalta oli saada aikaan kertakirjautuminen muiden samalla työasemalla toimivien sovellusten kanssa (siten, että jokin muu sovellus asettaa käyttäjäkontekstin) sekä henkilötietoja käsiteltäessä potilaskontekstin tahdistus muiden sovellusten kanssa. PlugIT:in kontekstinhallintamäärityksessä kuvatuilla rajapinnoilla voidaan toteuttaa nämä vaatimukset. Demosovellus on siis kontekstipalvelua hyödyntävä (sen rajapintoja kutsuva) sovellus kontekstinhallintamäärityksen kannalta Kontekstihallinnan linkitys sovelluksen toimintoihin Käyttäjäkontekstin osalta tekniikkariippumaton ratkaisu sovelluksen kannalta sisältää ennen sisäänkirjausta kontekstiin liittymisen (JoinCommonContext) ja kyselyn siitä, onko kontekstiin jo kirjautunut käyttäjä (GetItemValues). Jos käyttäjä on kirjautunut sisään (kontekstinhallinnassa on käyttäjätieto), on tässä sovelluksessa liitettävä kontekstiin kirjattu käyttäjä sovelluksen käyttäjäkannassa olevaan käyttäjään ja käynnistettävä sovellus tänä käyttäjänä. Demosovelluksen käyttäjä on määritelty Musti-järjestelmissä käytettynä Kernel-käyttäjänä. Käytännössä siis eri sovelluksilla on erilliset käyttäjätiedot. Ratkaisuna käyttäjätunnusten vastaavuuden määrittelyyn demosovellukseen rakennettiin oppiva integraatio : Jos kontekstipalvelussa ei ole käyttäjää, sovellus näyttää normaalisti omat sisäänkirjauslomakkeet Jos kontekstipalvelussa on käyttäjä, jonka Kernel-tunnusta ja salasanaa sovellus ei tiedä, kysytään käyttäjältä ensimmäisen käynnistyksen yhteydessä tunnus ja salasana, jotka sovellus sisäisesti liittää kontekstipalvelun kyseiseen käyttäjätunnukseen (ja tallettaa ne salattuina myöhempää käyttöä varten). Myöhemmissä sovelluksen käynnistyksissä tilanteissa, joissa käyttäjä, jonka Kernel-tunnus ja salasana on paikallisesti talletettu palautuu kontekstipalvelusta, käytetään sovelluksen omassa sisäänkirjauksessa talletettuja tunnuksia ja salasanoja, ja sisäänkirjauslomaketta ei näytetä. Oppivan integraation lisäksi käyttäjätunnusten synkronointi ja kertakirjaus voitaisiin toteuttaa muillakin tavoilla, joista mm. Mapping agent -ratkaisua on kuvattu kontekstihallinnan määritysdokumentissa. 36 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 5

37 Kuva 4.6. FixIT-demosovelluksen sisäänkirjautumisikkuna. Henkilö- (potilas)kontekstin osalta demosovelluksen tekniikkariippumaton ratkaisu perustuu määrityksen mukaiseen henkilötunnuksen käyttöön. Tämä vaatii demosovelluksen tietokantaan muutoksen, koska yksinkertaistettu henkilötietokanta ei sisältänyt henkilötunnuksia. Jos sovellus on liittynyt kontekstiin, henkilölomakkeelle siirtymisen yhteydessä tarkistetaan, onko kontekstissa valittua henkilöä (GetItemValues). Jos kontekstissa on henkilö, siirrytään suoraan kyseiseen henkilöön. Sama tarkistus tehdään, jos sovelluksen henkilölomake on (jätetty) auki, ja sovellukseen siirrytään (takaisin) toisesta sovelluksesta. Sovellus ei siis sisällä kontekstinhallintamäärityksessä mainittua tahdistuspainiketta henkilön tahdistukseen, vaan käyttäjän kannalta käsiteltävänä oleva henkilö tulee henkilötietojen käsittelylomakkeelle automaattisesti (olettaen, että ko. henkilö löytyy sovelluksen henkilötietokannasta). Kun sovelluksessa siirrytään haun tai navigointioperaation (ensimmäinen, seuraava jne.) seurauksena toiseen henkilöön, sovellus päivittää nykyisen henkilön kontekstipalveluun (SetItemValues). Demosovelluksen sulkemisen yhteydessä se poistuu kontekstista (LeaveCommonContext). Kuva 4.7. FixIT-demosovelluksen henkilötietolomake Tekniset ratkaisut ja toteutuskohtaiset seikat Liittymätekniikan osalta demosovelluksessa ei oltu aikaisemmin käytetty kontekstinhallinnan teknisen määrittelyn http-tekniikkaa. Tekniseen toteutukseen käytettiin kehitysvälineeseen (Delphi) saatavilla olevaa Indy (Internet Direct)-komponenttikirjastoa. Kirjaston IdHTTP-komponenttia käytettiin http-kutsujen tekemiseen kontekstipalvelimelle. Toteutuksessa kontekstipalvelun kutsumiseen rakennettiin erillinen moduuli (unit), johon koottiin sekä http-yhteyskomponentit, tarvittavien http-kutsujen ja niiden paluuarvojen purkaminen AVOINTEN INTEGROINTIRATKAISUJEN HYÖDYNTÄMINEN, TOTEUTTAMINEN JA TESTAUS 37

38 että operaatiot, joilla kontekstikutsuja tehdään sovelluksen muista moduuleista. Tämä ratkaisu mahdollistaa myös kyseisen moduulin jatkokehityksen yleiskäyttöiseksi kirjastoksi, joka on hyödynnettävissä DLL-rajapinnan kautta myös muissa sovelluksissa sekä muillakin kuin Delphi-välineellä tuotetuissa sovelluksissa. Moduuliin rakennettiin myös erityiset kutsut kontekstipalvelun palauttamien mahdollisten virhetilanteiden tarkempien tietojen hakua varten (moduulin operaatiokutsut palauttavat vain yksinkertaisen tiedon siitä, onnistuiko operaatio vai ei). Kontekstinhallintaan liittymiseen käytetty moduuli sisältää seuraavat metodit (kontekstihallintamäärityksen mukaisia kutsuja tekevät operaatiot on kursivoitu): InitCtxt: kontekstipalvelun osoitteen asettaminen CleanCtxt: http-yhteyksien ja asetusten nollaus JoinCommonContext: sovelluksen liittyminen kontekstipalveluun LeaveCommonContext: sovelluksen poistuminen kontekstipalvelusta SetItemValues: subjektin asettaminen kontekstipalveluun GetItemValues: subjektin hakeminen kontekstipalvelusta GoGet: yhteydenotto kontekstipalvelimeen GetError: virhetilanteen kaikkien tietojen palauttaminen GetErrorMsg: virhetilanteen viestin palauttaminen Kontekstihallintamäärityksessä on lihavoitujen operaatioiden lisäksi määritelty JoinCommonContextWithIp operaatio, jolla sovellus liittyy kontekstiin välittäen parametrina myös käyttäjän työaseman IP-osoitteen. Tätä operaatiota ei kuitenkaan ole toteutettu demosovellukseen, koska oletetaan että palvelin saa sovelluksen IP-osoitteen sille tulevasta http-kutsusta. Jos rakennettaisiin esim. web-palvelinsovellusta (tai kontekstipalvelu sijaitsisi osoitteessa jossa se ei näe asiakassovellusten oikeita IP-osoitteita), pitäisi myös tämä operaatio toteuttaa. Sovelluskohtaisesti demosovelluksen toteutettiin kutsumiseen käytetyn moduulin lisäksi: Kontekstiin liittymisessä käytetty sovelluksen nimi. Kontekstipalvelu voi toteuttaa toiminnallisuuden, jolla vain tietyillä sallituilla nimillä liittyvät sovellukset saavat liittyä kontekstiin. Kontekstiin liittymisessä saadun kupongin säilytys suorituksen ajan (käytetään kontekstipalvelun kaikkiin kutsuihin). Kertakirjauksen toimintalogiikka (ks. yllä), sovelluksen käyttäjätunnuksen ja salasanan vastaavuus kontekstinhallinnan yleiseen käyttäjätunnukseen, ja sovelluksen tunnuksen ja salasanan haku, talletus ja salaus. Sovelluksen kirjautuminen käyttää oletusarvoisesti RPC Brokerväliohjelmiston sisäänkirjausta, johon ei helposti pysty kirjoittamaan sovelluskohtaista toiminnallisuutta. Tätä sovellusta varten käytettiinkin aiemmin kehitettyä mekanismia, jolla sovelluksiin luodaan sovelluskohtainen sisäänkirjauslomake. Henkilökontekstin tahdistukseen (henkilölomakkeen avaukseen ja sovelluksen aktivointiin, kun henkilölomake on avattuna) ja asettamiseen (henkilön haun tai siirtymisen jälkeen) käytettyjen operaatioiden kutsut. Kontekstipalvelun osoitteen välittäminen sovellukselle (paikallisen asetustiedoston avulla). Kontekstipalvelun palauttamien virheiden käsittely: strategiaksi valittiin palvelun palauttamien virheilmoitusten näyttäminen käyttäjälle, jos kontekstipalveluun on saatu yhteys. Jos palveluun ei saada yhteyttä (tai sen osoitetta ei ole asetettu), sovellus toimii ilman kontekstipalvelua (ja näyttämättä ilmoituksia käyttäjälle). Sovellusta testattiin kontekstipalvelun referenssitoteutuksen kanssa ja mm. yhdessä kohdan 4.1.NET-sovelluksen kanssa. Testauksen pohjalta saatiin karsittua sovelluksesta mm. peräkkäisiä kontekstipalvelun GetItemValues-kutsuja sekä korjattua toiminnallisuus tilanteessa, jossa sovelluksen henkilölomakkeelle siirrytään toisesta sovelluksesta (lomakkeen OnActivate tapahtumaa ei kutsuta 38 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 5

39 Delphi-sovelluksen lomakkeilla automaattisesti tässä tilanteessa, joten vastaava toiminnallisuus oli liitettävä lomakkeen suorituksen ajaksi sovellustason OnActivate-tapahtumaan). Paikallista sovitusta edellä kuvatun kontekstipalvelun osoitteen välittämisen lisäksi ei ollut tarpeen tehdä. Jos sovellus otettaisiin käyttöön (esim. lisättäisiin myös työpöytäintegraatiopiirteineen osaksi FixIT-välinepakettia), dokumentoitaisiin integrointiratkaisun alustavaatimukset ja konfigurointi kontekstipalvelun osalta, ja mahdollisiin käyttöohjeisiin lisättäisiin ohjeet ja kuvaus integroinnista käyttäjän näkökulmasta. Sovellus toimii myös ilman yhteyttä kontekstipalveluun Muita toteutuksessa huomioitavia seikkoja Mahdollisia lisänäkökulmia, joihin tässä luvussa kuvattujen asioiden lisäksi kannattaa kiinnittää huomiota kontekstipalveluihin liittyvien sovellusten toteutuksissa: Sovelluksen asennus- ja käyttöönotto-ohjeissa on kuvattava, mitä integrointiratkaisujen (kuten kontekstipalvelun) käyttöönotto sovelluksessa vaatii. Demosovelluksessa on vain asetettava paikallisesti osoite kontekstipalvelulle jota käytetään, mutta myös muita paikallisia asetuksia voi olla tarpeen tehdä. Voi olla tarpeen rakentaa kontekstiin liittyessä käytetystä sovelluksen nimestä paikallisesti parametroitava. Kontekstipalvelu voi toteuttaa toiminnallisuuden, jolla vain tietyillä sallituilla nimillä liittyvät sovellukset saavat liittyä kontekstiin, mutta tämä ei ole vaadittu piirre kontekstipalveluissa. Myös muut tavat kuin tässä kuvattu oppiva integraatio ovat mahdollisia kertakirjauksen toteuttamiseksi. Jos kertakirjauksessa käytetään paikallista varastoa käyttäjätunnusten ja salasanojen talletukseen, on huolehdittava tietojen salauksesta tai siitä etteivät ne ole vapaasti kaikkien nähtävissä ja luettavissa. Käyttäjän vaihtuminen kontekstipalvelussa voi aiheuttaa lisätarkistustarpeita kontekstiin liittyviin sovelluksiin. On tarkastettava tai paikallisesti sovittava, voiko käyttäjä vaihtua kontekstipalvelussa kesken istunnon ja kuinka sovellusten tulee toimia tällaisessa tilanteessa. Voi olla tarpeen estää kontekstin mukaiseen henkilöön siirtyminen tietyissä tilanteissa, vaikka kontekstista löytyisikin eri henkilö kuin sovelluksessa on sillä hetkellä valittuna. Demosovelluksessa tällainen tilanne voisi olla esim. siirtyminen henkilölomakkeelle tilanteessa, jossa ollaan toisaalla käsittelemäässä juuri tiettyä henkilöä. On myös mahdollista tehdä potilaan tahdistus vain käyttäjän painaman napin kautta, mikä on yleistä varsinkin web-sovelluksissa, joissa sovelluksen aktivoinnin havaitseminen on hankalampaa kuin työasemasovelluksissa. Sovelluksiin voidaan myös rakentaa mukana tai ei mukana kontekstissa -valintamahdollisuus, kuten on kuvattu esim. CCOW-standardissa, jolloin käyttäjä voi valita synkronoituuko sovellus automaattisesti valittuun potilaaseen vai ei. On valittava, kuinka kontekstipalvelun palauttamia virheitä käsitellään ja mm. näytetäänkö niitä lainkaan käyttäjälle. Demosovelluksessa strategiaksi valittiin palvelun palauttamien virheilmoitusten näyttäminen käyttäjälle, jos kontekstipalveluun on saatu yhteys. Jos palveluun ei saada yhteyttä (tai sen osoitetta ei ole asetettu), sovellus toimii ilman kontekstipalvelua (eikä näytä ilmoituksia käyttäjälle). Kuten demosovellus, myös muut sovellukset kannattaa rakentaa toimimaan myös ilman yhteyttä kontekstipalveluun, ellei ole varmaa että ympäristössä, jossa sovellusta käytetään on kontekstipalvelu käytössä. AVOINTEN INTEGROINTIRATKAISUJEN HYÖDYNTÄMINEN, TOTEUTTAMINEN JA TESTAUS 39

40 4.3 Kontekstipalvelun referenssitoteutus Tässä luvussa esitellään lyhyesti PlugIT-hankkeen ulkopuolella toteutetun, mutta hankkeessa taustamateriaalina käytetyn kontekstipalvelimen toteutuksessa tehtyjä ratkaisuja. Kontekstipalvelinta on käytetty muiden referenssitoteutusten kanssa ja hyödynnetty hankkeen pilotoinnissa. Sen rajattu versio on ollut projektin osapuolten saatavilla kokeiluja varten ja sitä on käytetty myös kontekstipalveluiden esittelyyn ja havainnollistamiseen. Tämän luvun tavoitteena on erityisesti havainnollistaa Toteutuksen kuvaus -dokumenttiin tulevia seikkoja sekä tyypillisiä toteutuskohtaisia lisäyksiä ja lisärajoitteita avoimiin integrointiratkaisuihin. Kontekstipalvelun toteutuksessa käytettiin samoja välineitä ja välinepaketteja kuin kohdan 4.2 demosovelluksessa. Kuva 4.8. Kontekstipalvelimen suorituksenaikainen näkymä Toteutuksen suhde rajapintamäärittelyihin Kontekstipalvelu on siis verkossa toimiva palvelinsovellus, jonka avulla voidaan toteuttaa kontekstin jakamiseen perustuvaa työpöytäintegraatiota palveluun liittyneiden sovellusten välillä. Palvelimen toteutus noudattaa pääosin PlugIT-projektin hyväksyttyä määritystä "Minimitason kontekstinhallinnan määrittely, Versio 1". Kontekstihallinnan toimintaperiaate ja palvelun sekä osallistuvien sovellusten vastuut selviävät ko. määrityksestä. Palvelin toteuttaa kontekstinhallinnan http-keskustelija- ja palvelutoteutus-osat sekä kontekstihallintamäärityksen ContextManager- ja ContextData-rajapinnat. Se vastaa määrityksessä kontekstipalvelulle esitettyihin vaatimuksiin. Toteutuksessa tehtiin kuitenkin yksi poikkeus määritysdokumenttiin: määrityksen mukaisesti käyttäjäsubjektia ei turvallisuussyistä saa asettaa minimitoteutuksen SetItemValues-metodilla. Tässä toteutuksessa asetus tällä mekanismilla on kuitenkin mahdollistettu tietyllä paikallisesti parametroitavalla nimellä, jotta toteutusta voi helposti käyttää myös käyttäjäkontekstin ja kertakirjauksen esittelyssä. Tällä nimellä kontekstiin liittynyt sovellus saa vaihtaa käyttäjäsubjektin, muut 40 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 5

41 eivät. Käytännössä tämä ei ole riittävä tapa käyttäjäkontekstin suojaamiseen, ja käyttäjäkontekstin asetus voidaan myös estää tai kehittää sitä varten vaihtoehtoisia mekanismeja Toteutuskohtaiset ominaisuudet Palvelin toteuttaa määrityksessä mainittujen rajapintojen lisäksi seuraavat ominaisuudet (joista osa on mainittu määrityksessä, osa on hyödyllisiksi nähtyjä piirteitä toteutettavassa palvelussa): Palvelu tukee hajautettua käyttöä ja useita yhtäaikaisia käyttäjiä siten, että kunkin käyttäjän kontekstia hallitaan omana kokonaisuutenaan. Palveluun siis voidaan ottaa yhteyttä useista eri käyttäjien työasema- ja web-sovelluksista. Työaseman tunnistaminen IP-osoitteen avulla, kaikki samasta osoitteesta (tai sama IP-osoite parametrina) liittyvät sovellukset kuuluvat samaan kontekstiin Kontekstihallintamäärityksessä mainittujen kontekstien (käyttäjä ja potilas, User.Id.Logon ja Patient.Id.NationalIdNumber) lisäksi vapaasti määriteltäviä kontekstien subjekteja (laajennettavuus) Mahdollisuus seurata sovellusten yhteydenottoja palveluun, niiden suorittamia operaatioita ja tuottamia virheitä sekä kirjoittaa niitä lokitiedostoihin (esim. palveluun liittyvien sovellusten testausta varten) Mahdollisuus muuttaa http-porttia, jonka kautta palvelua käytetään Mahdollisuus käyttää palvelua myös ilman verkkoyhteyttä (mm. paikalliseen kokeiluun ja esittelyyn soveltuva localhost-käyttö) Mahdollisuus sallia vain nimettyjen sovellusten liittyminen kontekstipalveluun Käyttämättömien kontekstien aikakatkaisu (käyttämättömät kontekstit siivotaan määriteltävän ajan kuluttua, esim. sovellukset, jotka ovat sulkeutuneet virhetilanteen seurauksena katkaisematta yhteyttä kontekstipalveluun voivat jättää kontekstin voimaan ) Mahdollisuus määritellä kullekin työasemalle (käyttäjälle) maksimilukumäärä kontekstiin liittyviä sovelluksia Mahdollisuus sallia tai kieltää usean saman nimisen sovelluksen liittyminen kontekstiin yhdelle työasemalle (käyttäjälle) SSL-salattu https-yhteys, http-protokollan mukainen tunnistautuminen sekä evästeillä tapahtuva sessionhallinta kokeiluasteella, ei rutiinikäyttöön Näiden ominaisuuksien hallintaan toteutukseen rakennettiin yksinkertainen konfigurointitiedosto, jonka avulla palvelimen näitä ominaisuuksia muutetaan. Lisäksi palvelimen Toteutuksen kuvaus -dokumentissa annettiin käyttösuosituksia kutsujen tekemisen muodosta ja hyödyntämisestä kokeiluissa ja pilotoinnissa. Se sisälsi myös palvelimen asennusohjeen ja ohjeet edellä kuvattujen asetusten muuttamiseen, esimerkin kutsujen tekemisestä palveluun ja palvelun palauttamat suomenkieliset virheilmoitukset (avoimessa määrityksessä määriteltiin vain virhekoodit ja virheilmoitusten käyttäminen oli määritelty vapaaehtoiseksi). 4.4 Kontekstipalvelutoteutusten testaussovellus Toteutettujen Kontekstipalvelinten kokeilua ja testausta varten PlugIT-hankkeeseen liittyen toteutettiin sovellus, jonka avulla voidaan testata manuaalisesti rajapintamääritysten mukaisia kontekstipalvelimia. Sovelluksella otetaan yhteyttä määrättyyn kontekstipalvelimeen, ja sillä voidaan testata ko. palvelimen palauttamia vastauksia erilaisilla (kelvollisilla ja epäkelvoilla) syötteillä. AVOINTEN INTEGROINTIRATKAISUJEN HYÖDYNTÄMINEN, TOTEUTTAMINEN JA TESTAUS 41

42 Sovellus käyttää http-yhteyttä integrointimäärittelyn mukaisesti. Se lähettää http-kutsut text/plain-sisältötyyppiä käyttäen ja olettaa vastausten tulevan samalla sisältötyypillä. Testisovellusta on mm. käytetty apuvälineenä kontekstimääritysten mukaisuuden testauksessa (ks. luku 3). Sovelluksen käyttö pääpiirteissään tapahtuu seuraavasti: 1. Valitaan (tai kirjoitetaan) palvelin, johon halutaan ottaa yhteyttä (Context Server). 2. Valitaan operaatio (ja rajapinta), jonka metodia halutaan kutsua. 3. Syötetään ja valitaan tarvittavat lisäparametrit kutsuun (eri kutsuissa tarvitaan eri parametreja, jotka näkyvät kuvan 4.9 esimerkissä). 4. Suoritetaan kutsu. Kutsua voidaan myös muokata (esim. muuttaa kutsua virheelliseksi) ennen kutsun lähettämistä. 5. Tutkitaan, vastaavatko palvelimen palauttamat vastaukset määrityksiä ja käyttötarvetta. 6. Toistetaan vaiheita 2-5 tarvittavien testien läpikäymiseksi. 7. Luodaan haluttaessa tehdyistä http-kutsuista ja vastauksista halutaan lokitiedosto. Kuva 4.9. Kontekstipalvelinten testaussovellus. Käytännössä kontekstipalvelua käyttävät sovellukset suorittavat automaattisesti käyttäjältä näkymättömissä eri operaatioita vastaavia toimintoja. Testisovelluksessa kutsut, vastaukset ja parametrit ovat testisovelluksen käyttäjän nähtävissä, valittavissa ja muokattavissa. Sovelluksella voidaan testata yhdeltä työasemalta myös usean työaseman kontekstinhallintaa siten, että muilta työasemilta tulevat sovellukset käyttävät kontekstiin liittymiseen JoinCommonContextWithIP-operaatiota. 42 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 5

43 Testisovellus on hyödyllinen apuväline integrointimääritysten mukaisuutta testattaessa. Loki- ja peräkkäisten kutsujen teko-ominaisuuksia edelleen kehittämällä on mahdollista siirtyä kohti perustestien automatisointia ja automaattisten testiraporttien generointia. AVOINTEN INTEGROINTIRATKAISUJEN HYÖDYNTÄMINEN, TOTEUTTAMINEN JA TESTAUS 43

44 5 YDINPALVELU-ESIMERKIT PlugIT-hankkeessa on tuotettu sovellusten yhteisten ydinpalvelujen avoimia rajapintamäärityksiä. Kyseessä on palvelupohjainen integraatio, jonka avulla pyritään vähentämään päällekkäisiä tietoja ja toimintoja eri sovelluksissa, käyttäjän kannalta vähentämään moninkertaista samojen tietojen syöttöjä eri sovelluksiin ja ylläpitäjien kannalta vähentämään samojen tietojen päivittämistä useiden sovellusten tietovarastoihin. Sovellusten tekijöiden kannalta Ydinpalvelurajapintojen kautta saadaan käyttöön yhteisiä palveluita, joita ei siten erikseen tarvitse toteuttaa (tai tallentaa kaikkine tietoineen) jokaiseen ohjelmistoon. Ydinpalvelurajapintoja on PlugIT-hankkeessa määritelty useisiin integrointikohteisiin: käyttäjä, käyttöoikeudet, potilastiedot, kliiniset tiedot, koodistot. Eri rajapintojen tarkat määrittelyt ja kuvaukset löytyvät raporteista (Sormunen ym. 2004a-b, Rannanheimo ym ja Mykkänen ym. 2004c). PlugIT-hankkeen ydinpalvelurajapinnoissa on sovellettu mm. OMG:n terveydenhuoltospesifejä palvelustandardeja (ks. myös esimerkkitoteutus luvussa 6.1), JAAS-standardia, HL7:n CTS-standardia ja kansallisen koodistopalvelun määrittelyitä (Savolainen 2004, Sormunen 2003, Koodistopalvelu 2004). Teknisesti palvelurajapinnat on määritelty yksinkertaisina http- ja XMLtekniikoita hyödyntävinä hajautettuina palveluina, joihon eri tekniikoilla toteutetut sovellukset on suhteellisen helppo liittää. Tässä luvussa esitellään kyseisten määrityksen pohjalta tehtyjä toteutuksia, joilla havainnollistetaan palveluiden hyödyntämistä ja toteutusta eri sovelluksissa. 5.1 CoreServiceDemo Käyttäjä-, Käyttöoikeus- ja Potilaspalveluiden.NET-toteutus CoreServiceDemo-sovellus (Mäki 2004c) on palvelutoteutus, joka toteuttaa ydinpalveluiden käyttäjä-, potilas- ja käyttöoikeusrajapinnat, jotka ovat Ydinpalvelurajapinnat (käyttäjä, käyttöoikeus, potilas): Tekninen liittymämäärittely http- ja XML-tekniikoilla Versio 2.0 määrityksen (Sormunen 2004a) mukaisia. Sovellus on toteutettu Microsoft Visual Studio.NET 2003 sovelluskehittimellä. Käytetty ohjelmointikieli on C# ja sovelluksen tyyppi on ASP.NET Web Application (ks. Mykkänen ym. 2004b). Sovellus käyttää MS Access tietokantaa ja ODBCtietokantarajapintaa. Sovellus ei käytä erillistä kontekstipalvelua, vaan se hoitaa tarvittavien kuponkitietojen hallinnan itse. Käyttäjärajapintaan on toteutettu AuthenticateUser-, User:IdentifyProfile- sekä User:ProfileAccess-rajapinta, potilasrajapintaan Patient:IdentifyProfile- sekä Patient:ProfileAccessrajapinta ja käyttöoikeusrajapintaan AuthorizationAccess-rajapinta. Näihin rajapintoihin toteutetut operaatiot sekä niiden kuvaukset on esitelty taulukossa PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 5

45 Taulukko 5.1. CoreServiceDemo-sovellukseen toteutetut rajapinnat ja operaatiot. Rajapinta Operaatio Operaation kuvaus AuthenticateUser GetCoupon Hakee kupongin. CheckCoupon Tarkistaa, onko kuponki voimassa. CheckAuthentication Tarkistaa, onko kuponki varmennettu. Login Kirjaa käyttäjän ydinpalveluun. GetSubject Hakee kirjautuneen käyttäjän profiilin tunnisteen. Logout Kirjaa käyttäjän ulos ydinpalvelusta. User:IdentifyProfile FindCandidates Hakee käyttäjäkandidaatteja. GetMoreCandidates Hakee lisää edellisestä hausta jäljelle jääneitä käyttäjäkandidaatteja. DropRemainingCandidates Poistaa jäljellä olevat käyttäjäkandidaatit. User:ProfileAccess GetProfile Hakee yhden tai useamman käyttäjäprofiilin tietoja. CreateProfile Lisää yhden tai useamman uuden käyttäjäprofiilin. UpdateProfile Päivittää yhden tai useamman käyttäjäprofiilin tietoja. DeleteProfile Poistaa yhden tai useamman käyttäjäprofiilin. Patient:IdentifyProfile FindCandidates Hakee potilaskandidaatteja. GetMoreCandidates Hakee lisää edellisestä hausta jäljelle jääneitä potilaskandidaatteja. DropRemainingCandidates Poistaa jäljellä olevat potilaskandidaatit. Patient:ProfileAccess GetProfile Hakee yhden tai useamman potilasprofiilin tietoja. CreateProfile Lisää yhden tai useamman uuden potilasprofiilin. UpdateProfile Päivittää yhden tai useamman potilasprofiilin tietoja. DeleteProfile Poistaa yhden tai useamman potilasprofiilin. AuthorizationAccess CheckAuthorization Tarkistaa, onko lupa/luvat annettu. CoreServiceDemo-sovelluksessa rajapinnat on toteutettu luokkina ja rajapintojen operaatiot metodeina. Rajapinnat toteuttavien luokkien lisäksi sovelluksessa ovat luokat CoreServiceDemo.aspx, Global.asax, Checker ja DatabaseConnector. Sovelluksen luokat sekä tietokanta esitellään seuraavissa aliluvuissa CoreServiceDemo.aspx-luokka Luokka CoreServiceDemo.aspx on MS Visual Studio.NET sovelluskehittimen, ASP.NET Web Application tyyppistä sovellusta luotaessa automaattisesti generoitu luokka, joka toteuttaa sovelluksen käyttöliittymän (Web Forms page). Tässä sovelluksessa ei ole käyttöliittymää, joten luokkaan ei ole lisätty mitään toiminnallisuutta. Ydinpalvelun asiakassovellus käyttää CoreServiceDemo.aspx-tiedoston URL-osoitetta lähettäessään palvelupyyntöä. AVOINTEN INTEGROINTIRATKAISUJEN HYÖDYNTÄMINEN, TOTEUTTAMINEN JA TESTAUS 45

46 Kuva 5.1. CoreServiceDemo-sovelluksen luokat ja niiden väliset suhteet Global.asax-luokka Luokka Global.asax on MS Visual Studio.NET sovelluskehittimen ASP.NET Web Application tyyppistä sovellusta luotaessa automaattisesti generoima luokka, joka reagoi sovellustason tapahtumiin. Se sisältää valmiiksi metodit Application_Start, Session_Start, Application_BeginRequest, Application_EndRequest, Application_AuthenticateRequest, Application_Error, Session_End ja Application_End. Näistä metodeista käytetään tässä sovelluksessa ainoastaan Application_BeginRequest-metodia, jonka lisäksi luokkaan on toteutettu metodit streamtoxmldocument ja getresponsexmldoc. Metodi Application_BeginRequest ottaa palvelupyynnön vastaan, lukee sen XMLdokumentiksi kutsumalla streamtoxmldocument-metodia, hakee vastauksen kutsumalla getresponsexmldoc-metodia ja lähettää saadun vastauksen palvelupyynnön lähettäjälle. Metodi streamtoxmldocument muuntaa parametrina annetun Stream-tyyppisen palvelupyynnön XML-dokumentiksi ja poistaa siitä käsittelyä varten nimiavaruuden (xmlns-attribuutin). Metodi getresponsexmldoc kohdistaa palvelupyynnön interface- ja method-arvojen perusteella oikean luokan oikealle metodille (ks. luvut ) ja palauttaa metodilta saadun vastauksen palvelupyyntöön AuthenticateUser-luokka Luokka AuthenticateUser toteuttaa käyttäjärajapintaan kuuluvan AuthenticateUser-rajapinnan, jolla hoidetaan kuponkien luonti ja käyttäjien tunnistus. Rajapinnan operaatiot GetCoupon, Check- Coupon, CheckAuthentication, Login, GetSubject ja Logout on toteutettu metodeina: getcoupon hakee käyttäjälle kupongin. Jos samaan manifest-arvoon liittyviä varmennettuja kuponkeja on olemassa, niihin liitetty käyttäjä liitetään luotuun kuponkiin (varmennetaan kuponki). checkcoupon tarkistaa kupongin voimassaolon. checkauthentication tarkistaa, onko käyttäjä jo kirjautunut palveluun eli onko kuponki voimassa ja varmennettu. login kirjaa käyttäjän palveluun. Käyttäjän tunnistamiseen käytetään käyttäjätunnusta ja salasanaa. 46 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 5

47 getsubject hakee varmennettuun kuponkiin liitetyn käyttäjän profiilin tunniste. logout kirjaa käyttäjän ulos palvelusta eli poistaa kupongin. Jos poistettava kuponki on varmennettu, poistetaan myös kaikki muut samaan manifest-arvoon liittyvät kupongit UserIdentifyProfile-luokka Luokka UserIndentifyProfile toteuttaa käyttäjärajapintaan kuuluvan User:IndentifyProfilerajapinnan, jolla haetaan käyttäjäkandidaatteja. Rajapinnan operaatiot FindCandidates, GetMore- Candidates ja DropRemainingCandidates on toteutettu metodeina: findcandidates hakee käyttäjäkandidaatteja. Hakuehtoina voidaan käyttää profiilin tunnistetta, sukunimeä, etunimiä ja/tai yksikköä. Hakuehdoissa käytettävät ominaisuuksien nimet ovat id, sukunimi, etunimet ja yksikko. Profiilin tunnisteella haettaessa täytyy käyttää täsmällistä vastaavuutta, muilla haettaessa voidaan käyttää täsmällisen vastaavuuden lisäksi osittaista vastaavuutta (alusta tai keskeltä). Etunimellä haettaessa täytyy käyttää hakuehtona myös sukunimeä. getmorecandidates hakee aikaisemmasta hausta jäljelle jääneitä käyttäjäkandidaatteja. dropremainingcandidates poistaa aikaisemmasta hausta jäljelle jääneet käyttäjäkandidaatit. stringtoint on apumetodi, jolla muunnetaan String-tyyppinen kokonaisluku int-tyyppiseksi UserProfileAccess-luokka Luokka UserProfileAccess toteuttaa käyttäjärajapintaan kuuluvan User:ProfileAccess-rajapinnan, jolla käsitellään käyttäjien tietoja. Rajapinnan operaatiot on toteutettu luokkaan seuraavina metodeina: getprofile hakee yhden tai useamman käyttäjän tietoja. Käyttäjän tietoja hakiessa voidaan käyttää ominaisuuksia sukunimi, etunimet, yksikko ja kayttajatunnus. createprofile luo yhden tai useamman uuden käyttäjän. Tämä ei kuulu minimitoteutukseen. Käyttäjäprofiilia luodessa voidaan käyttää ominaisuuksia sukunimi, etunimet ja yksikko. updateprofile päivittää yhden tai useamman käyttäjän tietoja. Tämä ei kuulu minimitoteutukseen. Käyttäjäprofiilia päivitettäessä voidaan käyttää ominaisuuksia sukunimi, etunimet ja yksikko. deleteprofile poistaa yhden tai useamman käyttäjän PatientIdentifyProfile-luokka Luokka PatientIndentifyProfile toteuttaa potilasrajapintaan kuuluvan Patient:IndentifyProfilerajapinnan, jolla haetaan potilaskandidaatteja. Rajapinnan operaatiot toteuttavien metodien ja apumetodin tehtävät ovat seuraavat: findcandidates hakee potilaskandidaatteja. Hakuehtoina voidaan käyttää henkilötunnusta, sukunimeä, etunimiä, syntymäaikaa ja/tai yksikköä. Hakuehdoissa käytettävät ominaisuuksien nimet ovat hetu, sukunimi, etunimet, syntymaaika ja yksikko. Henkilötunnuksella haettaessa täytyy käyttää täsmällistä vastaavuutta, muilla haettaessa voidaan käyttää täsmällisen vastaavuuden lisäksi osittaista vastaavuutta (alusta tai keskeltä). Etunimellä haettaessa täytyy käyttää hakuehtona myös sukunimeä. getmorecandidates hakee aikaisemmasta hausta jäljelle jääneitä potilaskandidaatteja. dropremainingcandidates poistaa aikaisemmasta hausta jäljelle jääneet potilaskandidaatit. stringtoint on apumetodi, jolla muunnetaan String-tyyppinen kokonaisluku int-tyyppiseksi. AVOINTEN INTEGROINTIRATKAISUJEN HYÖDYNTÄMINEN, TOTEUTTAMINEN JA TESTAUS 47

48 5.1.7 PatientProfileAccess-luokka Luokka PatientProfileAccess toteuttaa potilasrajapintaan kuuluvan Patient:ProfileAccessrajapinnan, jolla käsitellään potilaiden tietoja. Rajapinnan operaatiot on toteutettu metodeina: getprofile hakee yhden tai useamman potilaan tietoja. Potilaan tietoja hakiessa voidaan käyttää ominaisuuksia (ominaisuuksien nimiä) hetu, sukunimi, etunimet, sukupuoli, syntymaaika, kotikunta, yksikko, H.katuosoite, H.postinumero, H.postitoimipaikka, H.maa, H.puhelinnumero, O.katuosoite, O.postinumero, O.postitoimipaikka, O.maa, O.puhelinnumero, C.katuosoite, C.postinumero, C.postitoimipaikka, C.maa, C.puhelinnumero, N.postitoimipaikka ja N.maa. Osoitetiedon alussa oleva H-kirjain tarkoittaa pysyvää kotiosoitetta, O-kirjain työosoitetta, C- kirjain tilapäistä kotiosoitetta ja N-kirjain syntymäpaikkaa. createprofile luo yhden tai useamman uuden potilaan. Potilasprofiilia luodessa voidaan käyttää samoja ominaisuuksia kuin potilaan tietoja hakiessa. updateprofile päivittää yhden tai useamman potilaan tietoja. Potilasprofiilia päivittäessä voidaan käyttää samoja ominaisuuksia kuin potilaan tietoja hakiessa. deleteprofile poistaa yhden tai useamman potilaan. Operaatiot createprofile, updateprofile ja deleteprofile eivät kuulu rajapinnan minimitoteutukseen, koska rajapinnan ensisijainen käyttötarkoitus on tietojen hakeminen, ei niiden lisääminen tai päivitys, jotka vaatisivat myös monipuolista tietojen tarkistamista ja monimutkaisempaa toiminnallisuuden ja vastuiden sopimista palvelun ja asiakassovellusten välillä AuthorizationAccess-luokka Luokka AuthorizationAccess toteuttaa käyttöoikeusrajapintaan kuuluvan AuthorizationAccessrajapinnan, jolla käsitellään abstrakteja lupia. Rajapinnan operaatio CheckAuthorization on toteutettu metodilla checkauthorization, jolla kysytään yksi tai useampi abstrakti lupa ydinjärjestelmältä. Sovellukseen on toteutettu kaksi erilaista lupakyselyä, jotka ovat: Onko käyttäjällä sovelluksessa application tietoon dataid oikeudet mode? ja Onko käyttäjällä oikeudet mode potilaan personid tietoihin?. Ensimmäisen tyyppisessä lupakyselyssä palvelupyyntö sisältää elementit application, dataid ja mode. Elementti application sisältää luvan kohteena olevan sovelluksen nimen, dataid luvan kohteen (tässä sovelluksessa käytössä: kayttaja, potilas tai kayttaja+potilas) ja mode käyttöoikeustason (R, RU tai RUCD). Toisessa lupakyselytyypissä palvelupyyntö sisältää elementit mode ja personid. Elementti mode sisältää käyttöoikeustason (R, RU tai RUCD) ja personid luvan kohteena olevan potilaan profiilin tunnisteen. Esimerkki. Käyttäjän kirjauduttua sovellukseen CoreClient sovellus kysyy, onko käyttäjällä sovelluksessa CoreClient oikeus lukea ja päivittää potilaiden tietoja sekä lisätä ja poistaa potilaita (ensimmäinen lupakyselytyyppi). Jos lupa on olemassa, käyttäjälle näytetään sovelluksessa olevat kyseisten toimintojen painikkeet/valikko. Kun käyttäjä hakee potilaskandidaatteja ja valitsee niistä Mauno Monosen ( A) käsiteltäväksi, sovellus tarkistaa, onko käyttäjällä oikeus lukea potilaan A tietoja (toinen lupakyselytyyppi). Jos lupa on olemassa, sovellus hakee Mauno Monosen tiedot ja näyttää ne. Jos lupaa ei ole olemassa, tietoja ei näytetä, vaan annetaan ilmoitus luvan puuttumisesta. 48 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 5

49 5.1.9 Checker-luokka Luokka Checker suorittaa erilaisia tarkistuksia ja tarkistettujen elementtien sisältöjen hakuja. Luokka sisältää seuraavat metodit: checkelement tarkistaa, sisältääkö palvelupyyntö parametrina annettua elementtiä. checkelementanditsinnertext tarkistaa, sisältääkö palvelupyyntö parametrina annettua elementtiä ja sisältääkö elementti tekstiä. checkelementanditschilds tarkistaa, sisältääkö palvelupyyntö parametrina annettua elementtiä ja onko elementillä lapsielementtejä. checkcouponauthentication tarkistaa tietokannasta, onko parametrina annettu kuponki varmennettu. checkfindcandidateelement tarkistaa palvelupyynnön findcandidate-elementin ja sen sisällön. checkprofileelements tarkistaa palvelupyynnöstä parametrina annetut profile-elementit (accessprofile-, createprofile-, updateprofile- tai deleteprofile-elementit) ja niiden sisällöt. getelementsinnertext tarkistaa, sisältääkö palvelupyyntö parametrina annettua elementtiä. Jos palvelupyyntö sisältää annetun elementin, metodi palauttaa elementin sisältämän tekstin (voi olla myös tyhjä). getelementsnotemptyinnertext tarkistaa, sisältääkö palvelupyyntö parametrina annettua elementtiä ja sisältääkö elementti tekstiä. Jos palvelupyyntö sisältää annetun elementin ja elementti sisältää tekstiä, metodi palauttaa elementin sisältämän tekstin DatabaseConnector-luokka Luokka DatabaseConnector hoitaa yhteyden tietokantaan. Sen metodi executeselect suorittaa SE- LECT-lauseen tietokantaan ja palauttaa kyselyn tuloksen DataSet-tyyppisenä. Metodi executeinsert suorittaa INSERT-lauseen, executeupdate UPDATE-lauseen ja executedelete DELETElauseen tietokantaan käyttämällä executenonquery-metodia Tietokanta CoreServiceDemo-palvelutoteutus käyttää omaa MS Access tietokantaa CoreDemoKanta, joka sisältää tietokantataulut kayttaja, kayttajakandidaatti, kayttajarooli, kayttajatunnus, kayttooikeus, kuponki, potilas, potilaskandidaatti, yhteystieto ja yksikko. Tietokantataulujen kentät on esitelty kuvassa 5.2. Tietokantataulujen avainkentät ovat lihavoituina. AVOINTEN INTEGROINTIRATKAISUJEN HYÖDYNTÄMINEN, TOTEUTTAMINEN JA TESTAUS 49

50 Kuva 5.2. CoreDemoKanta-tietokannan tietokantataulut Eri vaiheissa tehdyt ratkaisut Avoimen määrityksen hyödyntämisen vaiheiden (luku 2.2) kannalta eri vaiheissa on tehty seuraavia ratkaisuja: Sovelluksen tarpeet ja integrointimäärityksessä kuvattu ratkaisu Sovellus on ydinpalvelurajapintojen (käyttäjä, käyttöoikeus, potilas) palvelutoteutus, eli keskitetty palvelu, joka hallitsee käyttäjiä, käyttöoikeuksia ja potilaiden valittuja perustietoja. Se on esimerkkitoteutus, joka noudattaa Ydinpalvelurajapinnat (käyttäjä, käyttöoikeus, potilas): Tekninen liittymämäärittely http- ja XML-tekniikoilla -määrittelystä versio 2.0 -määritystä Tekniikkariippumaton ratkaisu sovelluksen kannalta Käyttäjärajapintaan toteutetaan rajapinnat AuthenticateUser, User:IdentifyProfile ja User:ProfileAccess. Käyttöoikeusrajapintaan toteutetaan rajapinta AuthorizationAccess. Potilasrajapintaan toteutetaan rajapinnat Patient:IdentifyProfile ja Patient:ProfileAccess. Rajapintojen kautta käsiteltävä toteutuskohtainen tietosisältö on kuvattu luvuissa ja AuthenticateUser-rajapintaan toteutetaan operaatiot GetCoupon, CheckCoupon, CheckAuthentication, Login, GetSubject ja Logout. User:IdentifyProfile- ja Patient:IdentifyProfile-rajapintoihin toteutetaan operaatiot Find- Candidates, GetMoreCandidates ja DropRemainingCandidates. User:ProfileAccess- ja Patient:ProfileAccess-rajapintoihin toteutetaan operaatiot GetProfile, CreateProfile, UpdateProfile ja DeleteProfile. AuthorizationAccess-rajapintaan toteutetaan operaatio CheckAuthorization ja sen kautta luvussa kuvatut tämän palvelun tukemat lupakyselyt. User:ProfileAccess- ja Patient:ProfileAccess-rajapintojen operaatiot GetProfile, Create- Profile, UpdateProfile ja DeleteProfile toteutetaan tukemaan yhden tai useamman profiilin samanaikaista käsittelyä. 50 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 5

51 Sovellus ei käytä erillistä kontekstipalvelua, vaan se hoitaa tarvittavien kuponkitietojen hallinnan itse. Sovellus käyttää omaa tietokantaa. Liittymätekniikan sovitus sovellukseen Sovellusta käytetään lähettämällä XML-muotoinen palvelupyyntö HTTP POST viestin sisältönä URL-osoitteeseen jossa <ip-osoite> on palvelimen IP-osoite (palvelin, jossa sovellus on käytettävissä). Toteutukseen tarvittavien XML- ja http-tekniikoiden hyödyntämiseksi käytetään.netvälineiden ASP.NET Web Application (System.Web)-kirjastoja sekä System.Xmlkirjastoa. Toteutuskohtaiset ratkaisut ja testaus User:IdentifyProfile-rajapinnassa käytetään seuraavia ominaisuuksia: id, sukunimi, etunimet ja yksikko. User:ProfileAccess-rajapinnassa käytetään seuraavia ominaisuuksia: sukunimi, etunimet ja yksikko. Patient:IdentifyProfile-rajapinnassa käytetään seuraavia ominaisuuksia: hetu, sukunimi, etunimet, syntymaaika ja yksikko. Patient:ProfileAccess-rajapinnassa käytetään seuraavia ominaisuuksia: hetu, sukunimi, etunimet, sukupuoli, syntymaaika, kotikunta, yksikko sekä erilaiset osoitetiedot. Osoitetieto-ominaisuudet nimetään tyyppi.osoitetieto, jossa tyyppi on osoitetiedon tyyppi (H, C, O tai N) ja osoitetieto tyyppiin liittyvä osoitetieto (katuosoite, postinumero, postitoimipaikka, maa tai puhelinnumero). Tyyppiin N liittyviä osoitetietoja ovat ainoastaan postitoimipaikka ja maa. Käyttöoikeuskyselyistä toteutetaan kaksi erilaista lupakyselyä. Käyttöoikeuskyselyissä (AuthorizationAccess-rajapinnan CheckAuthorization-operaatio) voi käyttää application-, dataid- ja mode-elementtejä tai mode- ja personid-elementtejä. HTTP-viestejä ei salata. Sovellus käyttää sisäisesti MS Access tietokantaa ja ODBC-tietokantarajapintaa. Erillistä leimaustestausta ei suoriteta, vaan palvelua testataan yksinkertaisella testiohjelmalla ja palvelun toteutuskohtaisten ratkaisujen kanssa yhteensopivalla asiakassovelluksella (luku 5.2). Paikallinen sovitus IIS-web-palvelimen asetuksia muuttamalla voidaan muuttaa mm. osoitetta (polkua), jolla palvelua käytetään. Sisällöllisiä tietojen tai toimintojen muokkausmahdollisuuksia sovellukseen ei ole rakennettu. Käyttöönotto Asennus- ja konfigurointiohjeet löytyvät Ydinpalvelurajapintojen (käyttäjä, käyttöoikeus, potilas) palvelutoteutus: CoreServiceDemo, versio 1.0 dokumentista (Mäki 2004c). 5.2 PatientCoreClientDemo Käyttäjä- ja Potilaspalveluiden.NET-asiakassovellus PatientCoreClientDemo-sovellus (Mäki 2004d) on asiakassovellus, joka käyttää käyttäjä- ja potilasrajapintojen ydinpalveluja (Mäki 2004c; Sormunen 2004a). Käyttäjä- ja potilasrajapintojen ydinpalvelut voivat olla toteutettuina samaan tai erillisiin palvelutoteutuksiin. PatientCoreClientDemosovellus on toteutettu Microsoft Visual Studio.NET 2003 sovelluskehittimellä. Käytetty ohjelmointikieli on C# ja sovelluksen tyyppi Windows Application. Sovellus sisältää tiedostot PatientCoreClientDemo.exe ja Setup.xml. PatientCoreClientDemo.exe on itse sovellus ja Setup.xml sisältää sovelluksen käyttämistä varten asetettavat tiedot, jotka AVOINTEN INTEGROINTIRATKAISUJEN HYÖDYNTÄMINEN, TOTEUTTAMINEN JA TESTAUS 51

52 ovat käyttäjän koneen tunnistetieto (manifest) sekä käytettävien käyttäjä- ja potilasrajapintojen ydinpalveluiden osoitteet. PatientCoreClientDemo-sovelluksessa on kolme lomaketta: päälomake sekä kirjautumis- ja hakulomakkeet. Kirjautumislomakkeella käyttäjä kirjautuu sovellukseen. Päälomakkeella käyttäjä voi lisätä uuden potilaan, muokata hakulomakkeella valitun potilaan tietoja tai poistaa valitun potilaan. Päälomakkeelta käyttäjä voi myös siirtyä hakulomakkeelle, jossa voi hakea listan potilaista erilaisilla hakuehdoilla ja valita halutun potilaan käsiteltäväksi päälomakkeella. Päälomakkeelta (tai kirjautumislomakkeelta) käyttäjä voi myös poistua sovelluksesta. Potilaiden listaus sekä heidän tietojensa haku ja katselu ovat potilasrajapinnan ydinpalveluiden kaikista toteutuksista yleensä löytyviä piirteitä. Potilaiden lisääminen ja poistaminen sekä potilaiden tietojen muokkaaminen eivät kuulu ydinpalveluiden minimitoteutukseen (Sormunen 2004a) eikä kyseisiä toimintoja yleensä suoriteta potilasrajapinnan kautta. Nämä toiminnot on kuitenkin toteutettu sovellukseen esimerkin vuoksi. Sovelluksessa on kolme lomakeluokkaa (PatientCoreClientDemo, Login ja Haku), jotka toteuttavat lomakkeet. Lisäksi sovelluksessa on kuusi apuluokkaa (AuthenticateUser, UserProfileAccess, PatientIdentifyProfile, PatientProfileAccess, CoreServiceConnector ja Converter), joita lomakeluokat sekä toiset apuluokat käyttävät. Kuva 5.3. PatientCoreClientDemo-sovelluksen luokat ja niiden väliset suhteet Vaatimukset ydinpalvelutoteutuksille Sovelluksen käyttämien käyttäjä- ja potilasrajapinnan ydinpalvelutoteutusten täytyy olla Ydinpalvelurajapinnat (käyttäjä, käyttöoikeus, potilas): Tekninen liittymämäärittely http- ja XMLtekniikoilla Versio 2.0 määrityksen (Sormunen 2004a) mukaisia. Lisäksi toteutus vaatii palvelujen toteutuksilta seuraavia ominaisuuksia: Käyttäjärajapinnan ydinpalveluun täytyy olla toteutettuna AuthenticateUser- ja User:ProfileAccess-rajapinnat. AuthenticateUser-rajapintaan täytyy olla toteutettuna GetCoupon-, CheckAuthentication-, Login-, GetSubject- ja Logout-operaatiot. UserProfileAccess-rajapintaan täytyy olla toteutettuna GetProfile-operaatio. Potilasrajapinnan ydinpalveluun täytyy olla toteutettuna Patient:IdentifyProfile- ja Patient:ProfileAccess-rajapinnat. Patient:IdentifyProfile-rajapintaan täytyy olla toteutettuna FindCandidates-, GetMoreCandidates- ja DropRemainingCandidates-operaatiot. PatientProfileAccesrajapintaan täytyy olla toteutettuna GetProfile-, CreateProfile-, UpdateProfile- ja DeleteProfileoperaatiot. 52 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 5

53 Taulukko 5.2. Eri rajapinnoissa vaadittavat käyttäjien ja potilaiden ominaisuudet. Ominaisuus kayttajatunnus hetu sukunimi etunimet yksikko syntymaaika yksikko sukupuoli syntymaaika kotikunta H.katuosoite H.postinumero H.postitoimipaikka H.maa H.puhelinnumero O.katuosoite O.postinumero O.postitoimipaikka O.maa O.puhelinnumero C.katuosoite C.postinumero C.postitoimipaikka C.maa C.puhelinnumero N.postitoimipaikka N.maa Rajapinnat UserProfileAccess (GetProfile-operaatio) Patient:IdentifyProfile ja Patient:ProfileAccess Patient:IdentifyProfile ja Patient:ProfileAccess Patient:IdentifyProfile ja Patient:ProfileAccess Patient:IdentifyProfile ja Patient:ProfileAccess Patient:IdentifyProfile ja Patient:ProfileAccess Patient:IdentifyProfile ja Patient:ProfileAccess Patient:ProfileAccess Patient:ProfileAccess Patient:ProfileAccess Patient:ProfileAccess Patient:ProfileAccess Patient:ProfileAccess Patient:ProfileAccess Patient:ProfileAccess Patient:ProfileAccess Patient:ProfileAccess Patient:ProfileAccess Patient:ProfileAccess Patient:ProfileAccess Patient:ProfileAccess Patient:ProfileAccess Patient:ProfileAccess Patient:ProfileAccess Patient:ProfileAccess Patient:ProfileAccess Patient:ProfileAccess Sovellus toimii näiden ratkaisujen avulla yhdessä luvussa 5.1 kuvatun palvelutoteutuksen kanssa Setup.xml-tiedosto Tiedostoon Setup.xml asetetaan (ennen sovelluksen käynnistämistä) käyttäjän koneen tunnistetieto sekä käyttäjä- ja potilasrajapintojen ydinpalveluiden URL-osoitteet. Käyttäjän koneen tunnistetieto asetetaan manifest-elementin sisällöksi. Sovelluksen käyttämä käyttäjärajapinnan ydinpalvelu määrittelee, mitä tunnistetiedon täytyy sisältää. Tunnistetietona voidaan käyttää esimerkiksi IP-osoitetta kuten CoreServiceDemo-ydinpalvelutoteutuksessa (Mäki 2004c). Käyttäjärajapinnan ydinpalvelun URL-osoite asetetaan userservice-elementin sisällöksi ja potilasrajapinnan ydinpalvelun URLosoite patientservice-elementin sisällöksi. Käyttäjä- ja potilasrajapintojen ydinpalveluiden osoitteet voivat olla myös samat. AVOINTEN INTEGROINTIRATKAISUJEN HYÖDYNTÄMINEN, TOTEUTTAMINEN JA TESTAUS 53

54 5.2.3 Lomakeluokat PatientCoreClientDemo toteuttaa PatientCoreClientDemo-sovelluksen päälomakkeen (kuva 5.4). Päälomakkeelta käyttäjä voi siirtyä hakulomakkeelle hakemaan ja valitsemaan käsiteltävää potilasta, katsella ja muokata käsiteltävän potilaan tietoja, lisätä uuden potilaan sekä poistaa käsiteltävän potilaan. Kaikki nämä toimenpiteet tapahtuvat palvelutoteutuksen kautta (vaikka palveluilta vaadittaviin minimiominaisuuksiin eivät kuulu lisäys, muokkaus tai poisto). Kuva 5.4. PatientCoreClientDemo-sovelluksen päälomake Luokka Login toteuttaa sovelluksen kirjautumislomakkeen (kuva 5.5), jolla käyttäjä voi kirjautua ydinpalveluun antamalla käyttäjätunnuksen ja salasanan. Kuva 5.5. PatientCoreClientDemo-sovelluksen kirjautumislomake 54 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 5

55 Luokka Haku toteuttaa sovelluksen hakulomakkeen (kuva 5.6), jolla käyttäjä voi hakea potilaskandidaatteja ja valita niistä yhden käsiteltäväksi päälomakkeella. Potilaskandidaatteja voi hakea henkilötunnuksen, sukunimen, etunimien, yksikön ja/tai syntymäajan perusteella. Kaikkiin hakuominaisuuksiin voidaan liittää täsmällinen hakuehto. Muita kuin henkilötunnusta voidaan hakea myös osittaisella vastaavuudella alusta tai keskeltä. Pelkällä etunimellä ei kuitenkaan voi hakea, vaan sen lisäksi on käytettävä hakuehtona sukunimen täsmällistä tai osittaista vastaavuutta. Hakulomakkeelle on toteutettu palvelun ominaisuuksien esittelyä varten kaikki hakumahdollisuudet, vaikka kaikkia niitä ei käytännössä tarvitakaan. Kuva 5.6. PatientCoreClientDemo-sovelluksen hakulomake Apuluokat Sovelluksessa on kuusi apuluokkaa: AuthenticateUser-luokka sisältää metodit: getcoupon, joka hakee kupongin ydinpalvelulta checkauthentication, joka tarkistaa ydinpalvelusta, onko kuponki varmennettu login, joka kirjaa käyttäjän ydinpalveluun getsubject, joka hake kirjautuneen käyttäjän profiilin tunnisteen, ja logout, joka kirjaa käyttäjän ulos ydinpalvelusta. UserProfileAccess-luokka sisältää metodin: getprofile, joka hakee käyttäjän käyttäjätunnuksen ydinpalvelusta. AVOINTEN INTEGROINTIRATKAISUJEN HYÖDYNTÄMINEN, TOTEUTTAMINEN JA TESTAUS 55

56 PatientIdentifyProfile-luokka sisältää metodit: findcandidates, joka hakee potilaskandidaatteja ydinpalvelusta getmorecandidates, joka hakee lisää potilaskandidaatteja edellisestä hausta, ja dropremainingcandidates, joka poistaa jäljellä olevat potilaskandidaatit ydinpalvelusta. PatientProfileAccess-luokka sisältää metodit: getprofile, joka hakee potilaan tiedot ydinpalvelusta createprofile, joka lisää uuden potilaan ydinpalveluun updateprofile, joka päivittää potilaan tiedot ydinpalveluun, ja deleteprofile, joka poistaa potilaan ydinpalvelusta. AuthenticateUser-, UserProfileAccess-, PatientIdentifyProfile- ja PatientProfileAccess-luokan metodit rakentavat XML-muotoisen palvelupyynnön ja hakevat vastauksen ydinpalvelulta kutsumalla (luokan ilmentymää luodessa annetun) CoreServiceConnector-luokan (ilmentymän) getresponsemetodia. Jokaisen luokan jokainen metodi muuntaa saadun vastauksen (XmlDocument-tyyppiseksi) XML-dokumentiksi kutsumalla Converter-luokan stringtoxmldocument-metodia, tarkistaa onko vastaus virheilmoitus ja palauttaa tarvittaessa XML-dokumentin tai sen perusteella muodostetun muun paluuarvon. CoreServiceConnector-luokka hoitaa yhteyden ydinpalveluun. Se sisältää metodin: getresponse, joka lähettää palvelupyynnön ja lukee ydinpalvelulta saadun vastauksen. Metodi getresponse saa parametrina XML-muotoisen palvelupyynnön merkkijonona. Metodi lähettää palvelupyynnön HTTP POST viestin (HttpWebRequest) sisältönä ydinpalvelulle käyttäen URL-osoitteena CoreServiceConnector-luokan ilmentymää luodessa annettua URL-osoitetta. Metodi lukee ydinpalvelulta saadun vastauksen, muuntaa sen merkkijonoksi kutsumalla Converterluokan streamtostring-metodia ja palauttaa paluuarvona saadun merkkijonon. Converter-luokkaa käytetään tiedon muuntamiseen eri tyyppiseksi. Luokka sisältää metodit: streamtostring, joka muuntaa Stream-tyyppisen tiedon String-tyyppiseksi stringtoxmldocument, joka muuntaa merkkijonon XML-dokumentiksi xmldocumenttostring, joka muuntaa XML-dokumentin merkkijonoksi, ja stringtoint, joka muuntaa String-tyyppisen kokonaisluvun int-tyyppiseksi Eri vaiheissa tehdyt ratkaisut Avoimen määrityksen hyödyntämisen vaiheiden suhteen (luku 2.2) eri vaiheissa on tehty seuraavia ratkaisuja: Sovelluksen tarpeet ja integrointimäärityksessä kuvattu ratkaisu Sovellus on ydinpalvelurajapintojen (käyttäjä, potilas) asiakassovellus ja noudattaa määritystä Ydinpalvelurajapinnat (käyttäjä, käyttöoikeus, potilas): Tekninen liittymämäärittely http- ja XML-tekniikoilla -määrittelystä versio 2.0 Sovellus on referenssitoteutus, jolla haetaan ja ylläpidetään potilastietoja hyödyntäen keskitettyä käyttäjä- ja potilaspalvelua (luku 5.1). Tekniikkariippumaton ratkaisu sovelluksen kannalta Sovellusta käynnistettäessä haetaan kuponki ydinpalvelulta. Sovelluksen käynnistymisen jälkeen kysytään ydinpalvelulta, onko kuponki varmennettu. Käyttäjän kirjautuessa kirjataan käyttäjä ydinpalveluun. 56 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 5

57 Kupongin varmennuskyselyn tai käyttäjän onnistuneen kirjautumisen jälkeen haetaan kirjautuneen käyttäjän profiilin tunniste ja sen perusteella käyttäjätunnus ydinpalvelusta. Käyttäjän hakiessa potilaskandidaatteja haetaan potilaskandidaatteja ydinpalvelusta. Käyttäjän hakiessa potilaskandidaatteja lisää edellisestä hausta haetaan potilaskandidaatteja lisää ydinpalvelusta. Käyttäjän peruuttaessa haun poistetaan jäljellä olevat potilaskandidaatit ydinpalvelusta. Käyttäjän valitessa käsiteltävän potilaan potilaskandidaateista haetaan potilaan tiedot ja poistetaan jäljellä olevat potilaskandidaatit ydinpalvelusta. Käyttäjän tallentaessa potilaan tietojen muutokset päivitetään potilaan tiedot ydinpalveluun. Käyttäjän lisätessä uuden potilaan lisätään potilas ydinpalveluun. Käyttäjän poistaessa potilaan poistetaan potilas ydinpalvelusta. Käyttäjän sulkiessa sovelluksen kirjataan käyttäjä ulos ydinpalvelusta. Käyttäjärajapinnasta käytetään AuthenticateUser- ja User:ProfileAccess-rajapintoja. Potilasrajapinnasta käytetään Patient:IdentifyProfile- ja Patient:ProfileAccess-rajapintoja. AuthenticateUser-rajapinnasta käytetään kaikkia muita paitsi CheckCoupon-operaatiota. User:ProfileAccess-rajapinnasta käytetään GetProfile-operaatiota. Patient:IdentifyProfile- ja Patient:ProfileAccess-rajapinnoista käytetään kaikkia operaatioita. Liittymätekniikan sovitus sovellukseen Ydinpalveluita käytetään sovelluksessa kutsumalla AuthenticateUser-, UserProfileAccess-, PatientIdentifyProfile- ja PatientProfileAccess-luokkien metodeita, jotka käyttävät CoreServiceConnector-luokan getresponse-metodia yhteyden hoitamiseksi ydinpalveluihin. Metodeissa on hyödynnetty.net-välineiden System.Xml- ja System.Net kirjastoja. Toteutus ja testaus HTTP-viestejä ei salata. Erillistä leimaustestausta ei suoriteta, vaan sovellusta testataan toteutuksen yhteydessä luvun 5.1 mukaisen ydinpalvelun kanssa. Paikallinen sovitus Setup.xml-tiedostoon asetetaan käytettävien käyttäjä- ja potilasrajapintojen ydinpalveluiden URL-osoitteet. Käyttöönotto Asennus- ja konfigurointiohjeet löytyvät Ydinpalvelurajapintojen asiakassovellus: PatientCoreClientDemo, versio 1.0 dokumentista (Mäki 2004d). 5.3 Käyttäjä-, Käyttöoikeus- ja Potilaspalveluiden Javatoteutus Yleistä Java-toteutuksesta Luvun 5 alussa kuvattujen ydinpalveluiden Java-toteutus noudattaa mahdollisimman tarkasti PlugIT-projektin ydinrajapintojen teknistä määritystä HTTP/XML tekniikalle (Sormunen 2004a). Tämän mukaisesti referenssitoteutukseen kuuluu seuraavat osat ja piirteet: Ydinrajapintojen referenssitoteutus on toteututettu erilliseksi ydinpalvelusovellukseksi, joka osaa kommunikoida asiakassovellusten kanssa HTTP-viestinnän avulla. Ydinpalvelujen referenssitoteutukseen kuuluu erillinen demoasiakassovellus (ks. luku 5.4), jonka avulla tunnistetaan käyttäjä, toteutetaan kertakirjautuminen ja käsitellään potilastietoa. AVOINTEN INTEGROINTIRATKAISUJEN HYÖDYNTÄMINEN, TOTEUTTAMINEN JA TESTAUS 57

58 Asiakassovelluksen ja ydinpalvelusovelluksen välinen liikenne tapahtuu lähettämällä ydinpalvelukutsuja XML-dokumentteina HTTP-yhteyden (tai HTTPS-yhteyden) yli. Asiakassovellus jää odottamaan ydinpalvelusovelluksen vastausta, joka on myös XMLdokumentti. Ydinpalvelusovellus ei itse voi lähettää HTTP-viestejä asiakassovellukselle; liikenne tapahtuu aina kysely-vastaus periaatteella jossa asiakassovellus kysyy ja ydinpalvelusovellus vastaa. Asiakassovellus voi halutessaan käyttää ydinpalvelusovellukseen kuuluvia littimiä (adapters), jotka hoitavat HTTP-viestinnän hallinnoinnin ja XML-dokumenttien luomisen, lähettämisen ja vastaanottamisen asiakassovelluksen puolesta. Ydinpalvelutoteutukseen kuuluva demoasiakassovellus käyttää yksin omaan liittimiä ydinpalvelusovelluksen kanssa kommunikoidessaan. Kuva 5.7. Ydinpalvelujen referenssitoteutuksen arkkitehtuuri Ydinpalvelujen Java-referenssitoteutuksen päämääränä on ollut luoda ydinpalveluja kattavasti esittelevä kokonaisuus, joka olisi mahdollisimman helposti asennettavissa. Tämä on toteutettu siten, että ydinpalvelutoteutus ja niitä hyödyntävä demoasiakassovellus ovat itsenäisiä ohjelmakokonaisuuksia (Web Archive paketteja) jotka voidaan asentaa mihin tahansa Java-sovelluspalvelimeen joka tukee Java Servlet- ja JavaServer Pages-teknologiaa. Alustavaatimukset ja käytetyt välineet Ydinpalvelusovellus ja demoasiakassovellus tarvitsevat vähintään Java Runtime Environment (JRE) version Sen lisäksi referenssitoteutus käyttää XML-dokumenttien käsittelyyn Xpath 1.0 toteutusta Xalan, joka on saatavilla osoitteesta Ydinpalvelusovellus ja demoasiakassovellus eivät toimi ilman näitä kirjastoja. Lisäksi referenssitoteutus tarvitsee Java-sovelluspalvelimen, joka tukee JavaServer Pages- ja Java Servlet spesifikaatioita, esimerkiksi ilmainen Tomcat Apache, joka on saatavilla osoitteesta Jos käytetty Java-sovelluspalvelin on Tomcat Apache, pitää Xa- 58 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 5

59 lan-kirjastot (xalan.jar, xercesimpl.jar, xml-apis.jar) kopioida Tomcatin common/endorsed hakemistoon korvaten siellä olevat entiset XML-kirjastot. Muussa tapauksessa Xalanin kirjastot saa käyttöön kopioimalla ne JRE:n lib/endorsed alihakemistoon. Toteutus vaatii, että nimenomaan Xalania käytetään Xpath-totetuksena, esimerkiksi JRE versio beta 1:n sisältämää Xpath-toteutusta ei voi käyttää referenssitoteuksen yhteydessä. Sovelluskehityksessä välineinä on käytetty Oraclen JDeveloper 10g-välinettä (ks. Karvinen ym. 2004) yhdessä integroidun Oracle 9iAS-sovelluspalvelimen kanssa. Lisäksi toteutusta on testattu Tomcat Apache 5 ja Resin 2.1-sovelluspalvelimilla. Käytettyjä tietokantavälineitä on kuvattu luvussa HTTP-kuuntelija Ydinpalvelusovellus on käytännössä toteutettu yksinkertaisena Java-servlettinä eli ydinpalvelusovelluksen HTTP-kuuntelija osa (kuva 5.7) toteuttaa luokan javax.servlet.http.httpservlet. HTTPkuuntelija ottaa POST metodilla lähetettyjä HTTP-viestejä vastaan. HTTP-kuuntelijan tehtävä on: lukea asiakassovelluksen avulla lähettämä XML-dokumentti ja jäsentää siitä oliomalli (Document Object Model puu). Samalla tarkistetaan että viestin syntaksi on oikea eli viesti on oikein muotoiltu XML-dokumentti. Viestin semanttista muotoa ei tarkisteta. alustaa palautettava XML-vastausdokumentti. ohjata kutsu oikealle palvelutoteutukselle XML -dokumentin sisältämän tiedon perusteella palautaa palvelutoteutuksen rakentama XML-vastausdokumentti tai asiakassovellukselle. HTTP-kuuntelija on toteutettu omana luokkanaan (org.plugit.http.servlet.httpserviceendpoint) AuthenticateUser- AuthorizationAccess-, IdentifyProfile- ja ProfileAccess-palvelut Jokainen ydinpalvelu on toteutettu omana Java-luokkanaan, jotka on lueteltu seuraavassa taulukossa. Taulukko 5.3. Ydinpalvelut ja ne toteuttavat luokat Palvelun nimi AuthenticateUser AuthorizationAccess UserIdentifyProfile PatientIdentifyProfile PatientProfileAccess UserProfileAccess Toteuttava Java-luokka org.plugit.http.service.authenticateuser org.plugit.http.service.authorizationaccess org.plugit.http.service.identifyprofile org.plugit.http.service.profileaccess Palvelutoteutukset toimivat siten, että ne muodostavat SQL-lauseita parametrinä saamiensa XMLdokumenttien mukaisesti ja rakentavat paluu-xml-dokumentin näiden SQL-lauseiden paluuarvojen perusteella. Ydinpalvelutoteutuksia ei kutsuta suoraan asiakassovelluksista, vaan HTTPkuuntelija (ks. luku 5.3.2) hoitaa palvelukutsuja sisältävät XML-dokumentit vastaan ja delegoi palvelukutsun oikealla ydinpalvelutoteutukselle. Palvelutoteutukset käyttävät Xalan-nimistä Xpath 1.0 toteutusta XML-viestien lukemiseen (katso luku ). Palvelutoteutuksien palauttamat XMLviestit rakennetaan käyttämällä SAX-rajapintoja, joiden avulla XML generoidaan tapahtumapohjaisesti eli kutsumalla haluttuja SAX-muuntajan metodeja, jotka generoivat XML-tekstidataa. AVOINTEN INTEGROINTIRATKAISUJEN HYÖDYNTÄMINEN, TOTEUTTAMINEN JA TESTAUS 59

60 AuthenticateUser-palvelu voidaan konfiguroida käyttämään ulkoista ContextManager-palvelua (ks. esim. luku 4.3). Tällöin single-signon toiminnallisuus saavutetaan ulkoisen kontekstipalvelun kautta. ContextManager-palvelun osoite voidaan määrittää ydinpalvelusovelluksen web.xml -tiedoston avulla muuttamalla ContextManagerURL ympäristöominaisuutta. Myös sovelluksen nimi, jota AuthenticateUser käyttää liittyessään yhteiseen kontekstiin, voidaan muuttaa Context- ManagerApplicationName ympäristömuuttujan avulla. Käyttäjien tiedot on talletettu kayttaja nimiseen tietokannat tauluun. Asiakasdemosovellus käyttää AuthorizationAccess-palvelua vain tarkistaakseen, onko käyttäjällä oikeus käyttää PotilasDemo nimistä sovellusta. Oikeudet on talletettu oikeus nimiseen tietokannan tauluun. Asiakasdemosovellus käyttää IdentifyProfile palvelua potilaskandidaattien tunnistamiseen. Potilaat on talletettu potilas nimiseen tietokannan tauluun. Asiakasdemosovellus käyttää ProfileAccess palvelua potilasprofiilien hakemiseen (PatientProfileAccess). Palvelun avulla myös haetaan sisäänkirjautuneen käyttäjän koko nimi (UserProfileAccess). Potilaat on talletettu potilas nimiseen tietokannan tauluun Tietokanta Ydinpalvelusovellus käyttää tietokantanaan HSQL (Hypersonic SQL) nimistä ilmaista Open Source-tietokantaratkaisua, jota saa kopioida vapaasti. Tietokanta on sisällytetty ydinpalvelusovellukseen siten, että se luodaan automaattisesti ydinpalvelusovellusta ensimmäisen kerran käynnistettäessä. Tietokanta luodaan sen henkilön kotihakemistoon, joka omistaa ydinpalvelusovellusta pyörittävän Java-sovelluspalvelimen prosessin. Tällöin tietokantaan luodaan myös testikäyttäjä. Tietokantaan ei kuitenkaan lisätä yhtään potilasta luomisen yhteydessä. Tietokantaa voidaan tarkastella ja muokata normaalilla tekstieditorilla tiedostossa demodb.script. Tietokantayhteys on toteutettu erillisessä luokassa (org.plugit.resource.databaseaccess). Java-toteutuksen kannalta tietokantaa käsitellään JDBC-rajapinnan kautta. HSQL:n JDBC-ajuri sisältää itse asiassa koko tietokantamoottorin, jonka kautta tietokantaa käsitellään. Tämä edesauttaa referenssitoteutuksen siirrettävyyttä, koska tietokantamoottorin ja tietokannan koko on vain satoja kilotavuja. Tietokannan sisältämiä tietoja kuvataan luvussa Java-toteutuksen lokitiedot Seuraavassa taulukossa on kuvattu referenssitoteutuksen käyttämät lokit eli mitä tietoja toteutuksen toiminnasta tallennetaan. Toteutus käyttää Java-ajoympäristön sisäänrakennettua tapahtumien tallentamis-järjestelmää (java.util.logging -pakettiin kuuluvat luokat) 60 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 5

61 Lokin nimi plugit.httptraffic plugit.database plugit.contextmanager plugit.authenticateuser plugit.authorizationaccess plugit.identifyprofile plugit.profileaccess Taulukko 5.4. Java-referenssitoteutukset lokit. Lokiin kirjoitettavat tiedot HTTP-liikenne. Tietokannan alustamiseen liittyvät tapahtumat. Ulkopuolisen kontekstipalvelun ja AuthenticateUser-palvelun välinen liikenne. Käyttäjän varmentamiseen liittyvät tapahtumat Käyttäjän valtuuttamiseen liittyvät tapahtumat. Profiilikandidaattien tunnistamiseen liittyvät tapahtumat. Profiilien käsittelyyn liittyvät tyapahtumat. Tapahtumia tallennetaan seuraavilla tasoilla SEVERE - kaikki virheet (oletustaso) INFO kaikki normaalit tapahtumat FINE kaikki tietokannan käsittelyyn liittyvät SQL-lauseet CONFIG kaikki referenssitoteutuksen konfiguraatioon liittyvät tapahtumat Tallennettavat tapahtumat voidaan konfiguroida Java-ajoympäristön lib-hakemistossa olevaa logging.properties tiedostoa muokkaamalla. Esimerkkikonfiguraatio: plugit.httptraffic.level = ALL plugit.contextmanager.level = SEVERE plugit.database.level = SEVERE plugit.authenticateuser.level = SEVERE plugit.profileaccess.level = SEVERE plugit.identifyprofile.level = SEVERE plugit.authorizationaccess.level = SEVERE Eri vaiheissa tehdyt ratkaisut Luvun 2.2 mukaisissa avoimen määrityksen hyödyntämisen vaiheissa Javaydinpalvelutoteutuksessa on tehty seuraavia ratkaisuja: Sovelluksen tarpeet ja integrointimäärityksessä kuvattu ratkaisu Sovellus on ydinpalvelurajapintojen (käyttäjä, käyttöoikeus, potilas) palvelutoteutus, eli keskitetty palvelu, joka hallitsee käyttäjiä, käyttöoikeuksia ja potilaiden valittuja perustietoja. Se on esimerkkitoteutus, joka noudattaa Ydinpalvelurajapinnat (käyttäjä, käyttöoikeus, potilas): Tekninen liittymämäärittely http- ja XML-tekniikoilla, versio 2.0 -määritystä. Tekniikkariippumaton ratkaisu sovelluksen kannalta Käyttäjärajapintaan toteutetaan rajapinnat AuthenticateUser, User:IdentifyProfile ja User:ProfileAccess. Käyttöoikeusrajapintaan toteutetaan rajapinta AuthorizationAccess. Potilasrajapintaan toteutetaan rajapinnat Patient:IdentifyProfile ja Patient:ProfileAccess. Rajapintojen kautta käsiteltävä tietosisältö on toteutuskohtainen (ks. alla). AuthenticateUser-rajapintaan toteutetaan operaatiot GetCoupon, CheckCoupon, CheckAuthentication, Login, GetSubject ja Logout. User:IdentifyProfile- ja Patient:IdentifyProfile-rajapintoihin toteutetaan operaatiot Find- Candidates, GetMoreCandidates ja DropRemainingCandidates. AVOINTEN INTEGROINTIRATKAISUJEN HYÖDYNTÄMINEN, TOTEUTTAMINEN JA TESTAUS 61

62 User:ProfileAccess- ja Patient:ProfileAccess-rajapintoihin toteutetaan operaatiot GetProfile, CreateProfile, UpdateProfile ja DeleteProfile. AuthorizationAccess-rajapintaan toteutetaan operaatio CheckAuthorization ja sen kautta yhden sovelluksen käyttöoikeuden kysely. User:ProfileAccess- ja Patient:ProfileAccess-rajapintojen operaatiot GetProfile, Create- Profile, UpdateProfile ja DeleteProfile toteutetaan tukemaan yhden tai useamman profiilin samanaikaista käsittelyä. AuthenticateUser-palvelun on mahdollisuus käyttää erillistä kontekstipalvelua, tai se voi hoitaa tarvittavien kuponkitietojen hallinnan itse. Sovellus käyttää omaa tietokantaa. Liittymätekniikan sovitus sovellukseen Sovellusta käytetään lähettämällä XML-muotoinen palvelupyyntö HTTP POST viestin sisältönä URL-osoitteeseen jossa <ip-osoite> on palvelimen IP-osoite (palvelin, jossa sovellus on käytettävissä). Toteutukseen tarvittavien XML- ja http-tekniikoiden hyödyntämiseksi käytetään J2EE:n httpservlet-luokkaa ja Xalan-nimistä Xpath-toteutusta. Toteutuskohtaiset ratkaisut ja testaus Patient:IdentifyProfile- ja Patient:ProfileAccess-rajapinnoissa palvelu tukee seuraavien ominaisuuksien käyttöä (ominaisuuksien nimet ovat suoraan xml-elementtien nimiä): pid, hetu, etunimet, sukunimi, yksikkoid, syntymaaika, sukupuoli.nimi, kunta.koodi, kunta.nimi, koti.katuosoite, koti.postinumero, koti.postitoimipaikka, koti.maakoodi, koti.maanimi, henkilotietolomake. User:IdentifyProfile- ja User:ProfileAccess-rajapinnoissa palvelu tukee seuraavien ominaisuuksien (xml-elementtien) käyttöä: uid, hetu, tunnus, salasana, etunimet, sukunimi, yksikkoid. Sovelluksen käyttöoikeuskyselyissä voi käyttää rajapinnan tarjoamia unitid-, application- Name-, role-, dataid-, mode- ja personid-tietoja. Ne vastaavat sovelluksen tietokannassa kenttiä yksikkoid, sovellus, rooli, kohde, toiminto ja potilasid. Rooli-, toiminto- ja potilasid-tietoja ei ole kuitenkaan hyödynnetty referenssitoteutuksessa. HTTP-viestejä ei salata. Jos web-palvelin tukee HTTPS-yhteyksien muodostamista, protokollan saa lisättyä helposti. Sovellus käyttää sisäisesti HSQL tietokantaa ja JDBC-tietokantarajapintaa. Sovelluksessa on mahdollisuus muodostaa lokitietoja Javan lokitietojen tallennusjärjestelmän kautta HTTP-liikenteestä, tietokantatapahtumista, kontekstipalvelun käytöstä sekä käyttäjä- ja profiilitoimintojen käytöstä. Palvelua on testattu luvussa 5.4 kuvatulla testiohjelmalla. Paikallinen sovitus Käytettävän web-palvelimen (esim. Apache) asetuksia muuttamalla voidaan muuttaa mm. osoitetta (polkua), jolla palvelua käytetään, tai ottaa käyttöön salattu HTTP-yhteys. Sovelluksen web.xml-tieostoon voidaan paikallisesti määritellä mahdollisesti käytettävän ulkoisen kontekstipalvelun osoite ja nimi, jota palvelu käyttää liittyessään kontekstipalveluun. Käyttöönotto Asennus- ja konfigurointiohjeet löytyvät Ydinpalvelurajapinnat (käyttäjä, potilas, käyttöoikeus): Kuvaus Java-referenssitoteutuksesta HTTP/XML tekniikalla dokumentista (Sormunen 2004b). 62 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 5

63 5.4 Java-toteutuksen demoasiakassovellus Luvun 5.3 palvelutoteutukseen liittyvä demoasiakassovellus on toteutettu JavaServer Pages (JSP) sovelluksena, joka on paketoitu httpservicesdemo.war nimiseksi paketiksi. Demoasiakassovelluksen käyttämä ydinpalvelujen toteutuksen HTTP-osoite voidaan määrittää CommonServicesURL ympäristömuuttujalla sovelluksen web.xml tiedostossa. Demoasiakassovellus osaa myös synkronoida valitun potilaan ContextManager -palvelun kanssa User.Id.Logon -tiedon avulla. ContextManager-palvelun osoite voidaan määrittää demoasiakassovelluksen web.xml tiedoston avulla muuttamalla ContextManagerURL -ympäristöominaisuutta. Myös sovelluksen nimi, jota AuthenticateUser käyttää liittyessään yhteiseen kontekstiin, voidaan muuttaa ContextManagerApplicationName ympäristömuuttujan avulla. Kuva 5.8. Demoasiakassovelluksen käyttöliittymän osat Käyttöliittymä Tässä kappaleessa on kuvattu lyhyesti käyttöliittymän JSP-sivujen toiminta. Ne ovat ainoa osa ydinpalvelujen Java-referenssitoteutuksesta jotka näkyvät loppukäyttäjälle. PatientLogin.jsp Sisäänkirjautumislomake. Jos käyttäjä on jo sisäänkirjautunut AuthenticateUser palvelun avulla, siirtytään suoraan sivulle Patient.jsp. PatientSignOn.jsp Yritetään sisäänkirjautumista annettujen salasanan ja tunnuksen avulla käyttäen AuthenticateUserpalvelua. Jos tämä onnistuu, siirrytään sivulle Patient.jsp. AVOINTEN INTEGROINTIRATKAISUJEN HYÖDYNTÄMINEN, TOTEUTTAMINEN JA TESTAUS 63

64 Patient.jsp Demoasiakassovelluksen pääsivu, jossa voidaan etsiä potilaskandidaatteja PatientIdentifyProfilepalvelun avulla, hakea yhden potilaan perustiedot, tallettaa ja lisätä uusia potilaita PatientProfileAccess-palvelun avulla ja siirtyä katselemaan tai muokkaamaan potilastietolomakkeita. Kun demoasiakassovellus käynnistetään, valittu potilas synkronoidaan automaattisesti yhteisestä kontekstista, jos potilastieto on asetettu sinen. Sivulla voidaan myös erillisillä painonapeilla synkronoida sen hetkinen potilas yhteisen kontekstin kanssa. Kuva 5.9. Java-toteutuksen käyttöliittymän potilasvalinta ja potilaan tiedot 64 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 5