2 Järjestelmäpalvelut

Transkriptio

1 2 Järjestelmäpalvelut 2.1 Tietoa palvelusta 2.2 Avainkäsitteet Jokainen MoReq2010 :n ydinpalveluista on määritelty palvelunimellä (esim. käyttäjä ja käyttäjäryhmäpalvelu), palvelun versiolla (esim. 1.0) ja työkalujen palvelutunnisteella (esim. cd b0-4c1c-82b4-5c8370b7d0e6) tai liitännäismoduulien ja laajennusmoduulien työkalujen moduulitunnisteella. Nämä yksityiskohdat löytyvät Tietoa palvelusta osiosta (katso kohta 3.1 Tietoa palvelusta). Työkalujen palvelutunniste on universaalisesti yksilöivä tunniste, jota käytetään sisäisesti MoReq2010 -yhteensopivassa asiakirjajärjestelmässä (MYJ) osoittamaan mitä palvelua se toteuttaa. Tämä 2 luku, Järjestelmäpalvelut, sisältää toiminnallisuutta, joka on yleistä kaikille MoReq2010 ydinpalveluille ja siksi sillä ei ole erillistä Tietoa palvelusta osiota. Sen sijaan siinä viitataan kunkin yksittäisen palvelun Tietoa palvelusta osioon Järjestelmäpohjainen arkkitehtuuri MoReq2010 :n ytimen toiminnalliset vaatimukset on niputettu yhdeksäksi palvelumäärittelyksi, jotka näkyvät Kaaviossa 2a. Yhdessä nämä palvelut kuvaavat sen toiminnallisuuden, jota vaaditaan MY-järjestelmältä. Tämä 2 luku, joka on nimetty Järjestelmäpalveluiksi, kuvaa sen toiminnallisuuden, mikä vaaditaan jokaiselta MoReq2010 :n ydinpalvelulta. MoReq2010 :n palvelupohjaista arkkitehtuuria ei ole tarkoitettu pakottamaan järjestelmätoimittajia kehittämään täysin MorReq2010:ä noudattavia ratkaisuja, jotka yhdistävät useita tai jopa kaikki ydinpalvelujen toiminnallisuudet yhdeksi sovellukseksi. Jakamalla MoReq2010 :n arkkitehtuuri erillisiksi palveluiksi järjestelmätoimittajat voisivat tulevaisuudessa miettiä, kehittäessään asiakirjajärjestelmiä, mikä hyöty saavutettaisiin jos kukin palvelu olisi toisistaan irrallaan ja siten käytettävissä useamman kuin yhden MY-järjestelmän kesken. Esimerkiksi tulevaisuudessa jokainen organisaation asiakirjajärjestelmä olisi kykenevä jakamaan saman luokittelupalvelun tai saman asiakirjojen säilytysaikasuunnitelmapalvelun. Tulevaisuudessa voi olla myös mahdollista rakentaa MY-järjestelmä, jossa käytetään eri järjestelmätoimittajien palveluja ja vielä integroida ne keskenään. Olipa yksittäinen sovellus rakennettu tiukasti tai löyhästi integroiduista palveluista niin kaikki MYJ-ratkaisut täytyy testata samoja määräystenmukaisia kriteereitä vasten. MYJ:n järjestelmäpohjaisen arkkitehtuurin ytimessä on asiakirjapalvelu. Asiakirjapalvelu on ainoa ydinpalvelu, jota ei voi jakaa toisen MYJ:n kanssa. Kirjaimellisesti vain asiakirjapalvelu erottaa yhden MY-järjestelmän toisesta MYjärjestelmästä. Kaikki muut palvelut, jotka tukevat asiakirjapalvelua voivat samanaikaisesti tukea muita asiakirjapalveluita ja voivat sen vuoksi olla samanaikaisesti osa useaa MY-ratkaisua.

2 Kaavio 2a MoReq2010 :ä noudattava asiakirjajärjestelmä (MYJ) kuvattuna toisiinsa liittyvien palvelujen ryppäinä järjestelmäpohjaisessa arkkitehtuurissa (kustakin ydinpalvelusta on määrittelyssä oma numeroitu lukunsa) Mallipalvelut ja liitännäismoduulit Kaksi MoReq2010 :n ydinpalveluista ovat mallipalveluita (katso luku4. Käyttäjäroolipalvelu ja luku 7. Metatietomallipalvelu). Tämä tarkoittaa, että vaikka määrittely on tuottanut kustakin palvelusta toiminnallisten vaatimusten oletuslistan, MoReq2010 ei vaadi järjestelmätoimittajia toteuttamaan nämä palvelut tarkasti samalla tavalla kuin mitä ne on määritelty paitsi niissä tapauksissa kun järjestelmätoimittaja haluaa tukea kehittyneempiä moduuleja kuten esimerkiksi sisäänlukumoduuleja. Ydinpalveluissa on myös kolme aluetta missä liitännäistoiminnallisuus on määritelty. Liitännäismoduulit edustavat vaihtoehtoista mutta yhtä kelpoa tapaa toteuttaa sama toiminnallisuus mutta eri tavalla kuin mitä perusmäärittelyssä on sanottu. Toimittajat voivat valita oman lähestymistapansa. Jokaisen MY-järjestelmän täytyy tarjota tukea ja olla sertifioitu vähintään yhtä toiminnallista toteutusta vasten. Järjestelmä voi yhtä hyvin tukea ja olla sertifioitu muita saman sarjan vaihtoehtoisia liitännäismoduuleja. MY-järjestelmän käyttöliittymä on esimerkki yhdestä alueesta missä liitännäistoiminnallisuus on määritelty.

3 2.2.3 Käyttäjärajapinta MoReq2010 ei edellytä, että käyttäjät aina käyttävät asiakirjajärjestelmiä suoraan. Perinteisissä asiakirjajärjestelmätoteutuksissa käyttäjät käyttävät asiakirjajärjestelmää graafisen käyttöliittymän (GUI) välityksellä. (Kaavio 2b). Kaavio 2b Käyttäjä käyttää asiakirjajärjestelmää suoraan graafisen käyttöliittymän GUI, kautta. Yhä enenevämmässä määrin asiakirjajärjestelmiä on kehitetty niin, että ne tukevat yhtä tai useampaa erilaista liiketoimintajärjestelmää. Näissä asiakirjajärjestelmissä ei ole graafista käyttöliittymää vaan niiden käyttö tapahtuu suoraan liiketoimintajärjestelmistä ohjelmointirajapinnan (API) kautta. Tässä vaihtoehdossa, joka on kuvattu Kaaviossa 2c, käyttäjä suorittaa toimintoja asiakirjajärjestelmässä vain epäsuorasti koska ne ovat seurausta käyttäjän liiketoimintajärjestelmässä tekemille toiminnoille: voi olla, että käyttäjä ei edes tunnista erillisen asiakirjajärjestelmän olemassaoloa. Kaavio 2c Käyttäjä käyttää asiakirjajärjestelmää epäsuorasti ohjelmointirajapinnan (API) kautta. MoReq2010 tukee molempia edellä kuvattuja tapoja käyttää asiakirjajärjestelmiä. MY-järjestelmässä voidaan määritellä millaista käyttöliittymää se tukee. MYjärjestelmä voi myös tukea useampaa kuin yhtä käyttöliittymätyyppiä samanaikaisesti. Vastaavasti kukin MoReq2010 :n ydinpalveluista voi tukea erilaisia käyttöliittymäoptioita. Esimerkiksi käyttäjä ja käyttäjäryhmäpalvelu voi tarjota API rajapinnan kun taas haku ja raportointi tarjoavat GUI rajapinnan. Läpi koko MoReq2010 :n, on tärkeää muistaa, että MYJ:n käyttäjä ei välttämättä ole henkilö vaan auktorisoitu käyttäjä voi olla yhtä hyvin joku liiketoimintajärjestelmä.

4 2.2.4 Entiteettityypit ja alatyypit Kukin MoReq2010 :n ydinpalvelu hallinnoi entiteettejä, jotka kuuluvat tietynlaisiin entiteettityyppiin. MoReq2010 :n ydinpalvelut viittaavat seuraaviin entiteetti tyyppeihin. Pääsynhallinnan käyttäjäluettelot, määritelty luvussa 4. Käyttäjäroolipalvelu Asiakirjakertymät, määritelty luvussa 6. Asiakirjapalvelu Luokat, määritelty luvussa 5. Luokittamispalvelu Komponentit, määritelty luvussa 6. Asiakirjapalvelu Toimintokeskeytykset, määritelty luvussa 9. Toimenpidekeskeytyspalvelu Säilytysaikataulut, määritelty luvussa 8. Säilytysaikasuunnitelmapalvelu Entiteettityypit, määritelty luvussa 2. Järjestelmäpalvelut Tapahtumat, määritelty luvussa 2. Järjestelmäpalvelut Toimintomäärittelyt, määritelty luvussa 2. Järjestelmäpalvelut Käyttäjäryhmät, määritelty luvussa 3. Käyttäjä ja käyttäjäryhmäpalvelu Metatietoelementtien määrittelyt, määritelty luvussa 7. Metatietomallipalvelu Asiakirjat, määritelty luvussa 6. Asiakirjapalvelu Roolit, määritelty luvussa 4. Käyttäjäroolipalvelu Palvelut, määritelty luvussa 2. Järjestelmäpalvelut Käyttäjät, määritelty luvussa 3. Käyttäjä ja käyttäjäryhmäpalvelu Kunkin entiteettityypin attribuuttilistat löytyvät kohdasta 14.2 Entiteettityypit. Vaikka pääsynhallinnan käyttäjälistat ja tapahtumat on esitetty muiden entiteettityyppien joukossa, ne eivät ole itsenäisiä entiteettejä. Kaikilla entiteeteillä, pois lukien pääsynhallinnan käyttäjälistat ja tapahtumat, on yhdistetty tapahtumahistoria, joka muodostuu joukosta tapahtumia ja tiedostojärjestelmään kirjautumisia. Kunkin palvelun hallinnoimat entiteettityypit löytyvät kohdasta Entiteetit ja palvelut ja perustelut kohdasta R Esimerkiksi asiakirjapalvelu hallinnoi koosteita, asiakirjoja ja komponentteja kun taas säilytysaikasuunnitelmapalvelu hallinnoi säilytysaikatauluja. Jos palvelut eivät ole MY-järjestelmässä loogisesti erotettu toisistaan, niin järjestelmän tulee hallinnoida kaikki MoReq2010 :n entiteettityyppien mukaiset entiteetit kollektiivisesti. MoReq2010 sallii kullekin entiteettityypille erikoistuneen alatyypin. Esimerkiksi metatietoelementin määrittelyt on jaettu kahteen osaan: järjestelmän metatietoelementtien määrittelyt kontekstuaalisen metatietoelementin määrittelyt Kumpikin näistä on alatyyppi perusentiteettityypille Metatietoelementin määrittely. Alatyypeille on tavallisesti luonteenomaista se, että niillä on ylimääräisiä järjestelmän metatietoelementtejä verrattuna perusentiteettityyppiin sekä vaatimusmäärittelyssä sanottuja lisätoimintasääntöjä. Jotkut MoReq2010 :n ydinpalvelujen entiteettityypeistä on tarkoituksella suunniteltu olemaan perustyyppejä entiteetin alatyypeille: lisäyksenä metatietoelementin määrittelyihin. Niitä ovat: Luokat, luokkien alatyypit on määritelty erilaisissa MoReq2010 :n liitännäismoduuleissa, 200. Luokittelusarjat Komponentit, komponenttien alatyypit on määritelty erilaisissa MoReq2010 :n liitännäismoduuleissa, 300. Komponenttisarjat

5 Hierarkkinen luokka, määritelty 201. Hierarkkinen luokittelu liitännäismoduulissa, on esimerkki Luokka-entiteettityypin alatyypistä. Sähköinen komponentti, määritelty 301. Sähköiset komponentit liitännäismoduulissa, on esimerkki Komponenttientiteettityypin alatyypistä. MoReq2010 :n laajennusmoduulit voivat lisätä uusia entiteettityyppejä ja alatyyppejä Entiteetin anatomia Useimmilla entiteeteillä on kolme kokoelmaa tietoa, jotka liittyvät entiteettiin. (Kaavio 2d). Metatieto: tieto, joka kuvaa entiteetin, sisältäen metatietoelementin määrittelyt ja joka jakautuu järjestelmän metatietoan (MoReq2010 :n määrittelemä) ja kontekstuaaliseen metatietoan (toimittajan ja/tai käyttäjän määrittelemä). Tapahtumahistoria: kokoelma entiteetin tapahtumia, joka varastoi informaatiota kaikista erilaisista toiminnoista, joita entiteetille on tehty. Pääsynhallinnan käyttäjälistat: luettelo käyttöoikeusmerkinnöistä, jotka määrittelevät roolipohjaisesti ketkä käyttäjät ja käyttäjäryhmät voivat suorittaa toimintoja entiteetille. Kaavio 2d Kuhunkin entiteettiin liittyy metatieto, tapahtumahistoria ja tiedostojärjestelmän pääsylista Lisää informaatiota siitä kuinka metatietoa hallinnoidaan MoReq2010 :ssä löytyy luvusta 7. Metatietomallipalvelu vaikka tapahtumahistoria käsitelläänkin tässä yhteydessä. Tiedostojärjestelmän pääsylistoista saa lisätietoa luvusta 4. Käyttäjäroolipalvelu. Tapahtumat ja käyttöoikeusmerkinnät jakavat entiteettinsä tapahtumahistorian ja tiedostojärjestelmän pääsylistan. Komponentit jakavat asiakirjaentiteettinsä tiedostojärjestelmän pääsylistan. MoReq2010 :n ydinpalvelu ei ole vain tiettyihin entiteettityyppeihin kuuluvien entiteettien tallennuspaikka; ydinpalvelu on itsessään entiteetti, jolla on omat metatiedot, tapahtumahistoria ja pääsynhallinnan käyttäjälistat, jotka palvelu on

6 perinyt kaikilta palvelun entiteeteiltä. Entiteettien yhdistelmä ja niiden suhteet palveluihin on kuvattu Kaaviossa 2e. Kaavio 2e Palvelu sisältää entiteettejä, joilla on omat metatiedot, tapahtumahistoriat ja tiedostojärjestelmän pääsylistat mutta palvelua itseään pidetään myös entiteettinä, jolla on metatieto, tapahtumahistoria ja tiedostojärjestelmän pääsylista Entiteettien tunnistaminen Kaikkein tärkein entiteetin metatietoelementti on kenties sen järjestelmätunniste. MoReq2010 vaatii universaalisti yksilöivän tunnisteen (UUID) kullekin entiteetille ja kullekin palvelulle MYJ:ssä. UUID:n käyttö on pakollista tämän määrittelyn mukaan: tämä tarkoittaa, että mikä entiteetti tahansa voidaan eksportoida yhdestä MYJ:stä ja importoida toiseen MYJ:ään ja entiteetti säilyttää universaalin yksilöintinsä. Importoiva MYJ voi jopa käsitellä alkuperäisen entiteetin eri versioita, jotka on eksportoitu eri aikoina tai siirretty välittäjä MYJ:n kautta. Kaikki entiteetit voidaan jäljittää takaisin siihen tiettyyn instanssiin missä ne alun perin luotiin alkuperäisessä palvelussa Toimintojen suorittaminen Käyttäjät käsittelevät entiteettejä MYJ:ssä tekemällä niihin toimintoja. Joskus MYJ itse tekee toiminnon kuten esimerkiksi silloin kun se generoi uuden järjestelmätunnisteen palvelulle. MoReq2010 on vaatimusmäärittely ja kukin toiminto, joka voidaan suorittaa MYJ:n entiteetille, voidaan jäljittää takaisin yhteen tai useampaan toiminnalliseen vaatimukseen. Käyttäjä voi suorittaa entiteetille toiminnon vain jos hänellä on siihen riittävät oikeudet. Yhtäpitävästi luvun 4. Käyttäjäroolipalvelu kanssa, oikeus suorittaa toiminto tulee roolin mukaan, johon käyttäjä tai käyttäjäryhmä kuuluu. Roolit on annettu joko yksittäiselle käyttäjälle tai käyttäjäryhmälle käyttöoikeusmerkinnöillä, jotka tulevat osaksi joko palvelua tai entiteetin pääsynhallinnan käyttäjälistaa (ACL).

7 Kuten aiemmin on puhuttu kohdassa Mallipalvelut ja liitännäismoduulit, jotkut MYJ-ratkaisut voivat poiketa tietyistä käyttäjäroolipalvelun vaatimuksista mutta kaikkien MYJ-ratkaisujen täytyy kyetä tuottamaan samanlainen ja kelvollinen toiminnallisuus. Käyttäjäroolipalvelun sisältö on tarkemmin määritelty luvussa 4. Käyttäjäroolipalvelu Tapahtumahistoria MYJ:n jokaisella entiteetillä on tapahtumahistoria, joka muodostuu entiteettiin kohdistuneista tapahtumista. Milloin tahansa entiteetille on suoritettu toiminto käyttäjän tai järjestelmän toimesta, tapahtumasta generoidaan merkintä joka lisätään entiteetin tapahtumahistoriaan. Sen vuoksi jokainen tapahtuma tapahtumahistoriassa vastaa MYJ:ssä suoritettua toimintoa. Jotta tapahtumahistoria ei kasvaisi liian suureksi tai että se ei täyttyisi turhanaikaisilla tapahtumilla, sallii MoReq2010, että auktorisoitu käyttäjä voi ottaa tapahtumahistorian kirjoittamisen pois päältä tiettyjen toimintojen osalta. Tapahtuman metatiedon päivittää aina MYJeikä käyttäjällä saa olla mahdollisuutta sitä muuttaa. Tapahtumilla ei ole tapahtumahistoriaa. Eri tapahtumilla on eri metatieto riippuen toiminnosta, jolla tapahtuma on tehty. Tämä tekee mahdolliseksi sen, että tapahtuma voi esiintyä useammankin entiteetin tapahtumahistoriassa: alla esimerkkejä. Jos auktorisoitu käyttäjä muuttaa koosteen nimen, R6.5.3:n mukaisesti, niin silloin kyseessä on vain yksi aktiivinen entiteetti (kooste). Tapahtuma (F Kooste metatieton muokkaaminen) tulee näkyviin vain koosteen tapahtumahistoriaan. Jos auktorisoitu käyttäjä luo asiakirjan koosteeseen, R6.5.10:n mukaisesti, niin silloin on kyse kahdesta aktiivisesta entiteetistä (sekä kooste että asiakirja) ja sama tapahtuma (F Asiakirja luonti) tulee näkyviin kummankin aktiivisen entiteetin tapahtumahistoriaan. Jos auktorisoitu käyttäjä siirtää asiakirjan yhdestä koosteesta toiseen koosteeseen, R mukaisesti, niin silloin on kyse kolmesta aktiivisesta entiteetistä (edeltävä isäkooste, uusi isäkooste ja asiakirja). Tapahtuma (F Kooste lisää asiakirja) tulee näkyviin kaikkien kolmen aktiivisen entiteetin tapahtumahistorioihin yhtä aikaa. R mukaisesti asiakirja on aina aktiivinen entiteetti toiminnoissa, jotka suoritetaan sen komponenteilla niin, että generoidut tapahtumat tulevat aina näkyviin sekä komponentin että asiakirjan tapahtumahistorioissa. Kaavio 2f näyttää miten tapahtuma voi kuulua useamman kuin yhden entiteetin historiaan.

8 2.2.9 Aikaleimat Kaavio 2f Sama tapahtuma entiteetti voi näkyä useammassa kuin yhdessä tapahtumahistoriassa Perinteinen audit trail voidaan nähdä koko MYJ:n kaikkien entiteettien kaikkien tapahtumien tapahtumahistoriana (aikaleimajärjestyksessä). MoReq2010 :ssä on erityisiä piirteitä, jotka sallivat asiakirjajärjestelmien yhteiskäyttöisyyden yleisellä tasolla. Yksi näistä on aikaleimojen käyttö. Määrittely vaatii, että MYJlisää aikaleimat metatietona jokaiseen generoimaansa tapahtumaan. Esimerkiksi jokaisella entiteetillä on aikaleima, joka kertoo milloin entiteetti on luotu. Aikaleimojen on sisällettävä täydellinen ja tarkka päiväys ja kellon aika mukaan lukien aikavyöhyke, joiden perusteella tapahtumat voidaan järjestää tapahtumajärjestykseen. Jos MY-järjestelmä kykenee suorittamaan useita tapahtumia sekunnissa, on MYJ:n kyettävä antamaan tapahtumien tapahtuma-aika millisekunnin tai vielä sitäkin tarkemmalla tarkkuudella, jotta tapahtumat pysyvät oikeassa järjestyksessä aikaleiman mukaan järjestettäessä. Aikaleimat tukevat yhteiskäyttöisyyttä mahdollistaessaan entiteettien onnistuneen siirron toiseen MY-järjestelmään toisella aikavyöhykkeellä Yleispätevä kielituki Toinen MoReq2010 :n yleispätevä ominaisuus on, että se tukee Unicodea. Kaikkien merkkimuotoisten metatietoelementtien on oltava Unicode formaatissa ja varustettuna kielitunnisteella. MY-järjestelmä voi tukea vain yhtä tai rajoitettua määrää eri kieliä. Yhtä kaikki, tukeakseen yhteiskäyttöisyyttä kielitunnisteen tulee löytyä kaikista tekstimuotoisista metadatoista.

9 Entiteetin elinkaari Entiteettityypistä riippumatta, kaikilla MYJ:n entiteeteillä on samanlainen elinkaari. Piirros entiteetin elinkaaresta näkyy Kaaviossa 2g. Kaavio 2g MYJ:n jokaisella entiteetillä on samanlainen elinkaari MYJ:n jokainen entiteetti luodaan niin, että sen ensimmäinen tapahtuma on aina sen luontitapahtuma. Sen jälkeen entiteetti säilyy aktiivisena kunnes se hävitetään hävitystapahtumalla. Hävityksen jälkeen MYJ säilyttää jäännöstiedon osoittamaan, että entiteetti oli aiemmin olemassa MYJ:ssä. Kaikkien MYJ-ratkaisujen pitää säilyttää entiteettien jäännöstiedot. Hävittäminen on eri asia kuin poistaminen, jossa kaikki jäljet entiteetin olemassaolosta pyyhitään pois. Entiteettejä ei ole mahdollista poistaa MYJ:stä ikään kuin niitä ei olisi koskaan sinne luotukaan paitsi jos ne poistetaan ennen kuin niitä on käytetty: entiteettejä, joita on käytetty, ei voi poistaa. Joillain entiteeteillä, erityisesti asiakirjat ja niiden komponentit, mutta myös sellaiset entiteetit kuin tapahtumat, käyttöoikeusmerkinnät, järjestelmän metatietoelementtien määrittelyt jne. ei ole ensikäytön aikaleimaa eikä niitä voi koskaan poistaa. Kun ne on kerran luotu, ei näitä entiteettityyppien entiteettejä voi pyyhkiä pois ilman, että MYJ:ään jää siitä jälki. Asiakirjan elinkaari on selitetty yksityiskohtaisemmin luvussa 6. Asiakirjapalvelu ja luvussa 8. Säilytysaikasuunnitelmapalvelu.