You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Lähtökohta

  1. Arkkitehtuurin pysyttävä mahdollisimman yksinkertaisena
  2. Jos käyttäjiä heataan perusrekisteristä vain yhden integraation toimesta, miksi tarvitaan erillistä integraatiota
  3. Miten hoidetaan vikasietoisuus
  4. integraation auditointi
  5. Standardit ratkaisut ja jatkuvuus

Johdatus Peppi-ekosysteemissä käytössä oleviin integraatiotuottteisiin

Rajapinnat, perusreksiterin tekninen dokumentaatio

Camel

Vastaukset

1. Yksinkertaisuudella tarkoitetaan jäsentynyttä arkkitehtuuria, selkeästi nähtävissä eri osakokonaisuudet. Silloin niitä voidaan ylläpitää ja jatkokehittää helpommin. Ratkaisujen pitää myös perustua standardeihin tai yleisesti käytössä oleviin ratkaisumalleihin, jolloin niiden ymmärtäminen on helpompaa. Ratkaisumallit ovat symmetrisiä, sama logiikka toistuu ratkaisusta toiseen.

Pepissä ja eduixilla käytössä Camel, jolla pyritään standardoimaan erilaiset, organisaatiokohtaiset, integraatiot.

 

2. Ongelmat/selvitykset:

    • Jos tuleekin toinen integraatio, mitä tehdään? Mitä kaikkea Perusreksiteriin tulee integroitumaan? Tehdäänkö sitten kaksi integraatioratkaisua? esim. HAMK, jolla on keskitettytietovaranto, tässä kohtaa luultavasti on kaksi integraatiota, jotka hakevat tietoja. Mitä jos rest-haun jälkeen pitää lähettää tapahtuma vielä toiseen paikkaan, esim keskitettyyn tietovarantoon, vaaditaan joka tapauksessa transaktoita.
    • Tietosisältö sekoittuu, tietokannassa sekaisin tietoja jotka liittyvät opetuksen järjestämiseen ja järjestelmien integroimiseen. Esim. toisussa kannassa oli null rivejä vain sen takia että voidaan piilottaa yksittäisiä rivejä käyttöliittymässä -> hankaloitti migraatiota.
    • Oma "jono" toteutus varmasti usein helpompi, varsinkin jos vaatimukset ovat pieniä. Pepin teknisessä työryhmässä on päädytty ratkaisuun että integratioratkaisut pohjautuvat standardeihin(de facto) tuoteisiin/ratkaisumalleihin, jotka toimivat kaikille konsortiossa oleville organisaatioille.
    • Jos ei missään nimessä haluta kytkeytyä jonoon, niin yksi ratkaisu on että tehdään irrallinen jono-komponentti, joka julkaisee rajapinnan restillä. Se ei kuitenkaan ole osa perusrekisterin rajapintoja, vaan irrallinen komponentti.
    • Osalla organisaatioita, jotka voivat mahdollisesti ottaa pepin/perusreksiterin käyttöön, on jo käytössä jonkinlainen jono ratkaisu, esim. hy activeMQ(?), jyväskylä ZeroMQ(?). Käyttämällä Camelia voidaan näihin kaikkiin kytkeytyä ilman tarvetta omille kikkareille
    • integraatioiden näkökulmasta tapahtumapohjaiset viestinvälitykset, viesteissä kaikki tarvittava data, dokumentoivat paremmin rajapintojen/järjestelmän käyttöä.
    • Tapahtumapohjaiset integraatiot soveltuvat paremmin asynkroniseen tiedonsiirtoon ja löyhemmät(löysät) sidokset.
3. Transaktiot ja tallennetut viestit
4. activeMQ/camel-tuotteissa toiminnot integraatioiden seuraamiseen. Perusreksiterissä toteutetaan erillinen loki-palvelu, jonka voi kytkeä integraatioon.
5. Mahdollisuus massapotkuun. Eli että voidaan kaikesta huolimatta myös viedä tietty joukko käyttäjiä/dataa uudelleen

Ratkaisu

 

 

  1. Intergaatio käynnistyy perusrekisterin tapahtumasta. tapahtumat viedään jms-jonoon. Tapahtumat IDM:n näkökulmasta:
    1. Kokonaan uusi identiteetti + opiskeluoikeus
    2. Uusi opiskeluoikeus olemassaolevaan identiteettiin
    3. Olemassaolevan opiskeluoikeuden päivitys

 

intergaatio

Muut integraatiot

Esimerkkejä

  • Valmistumisjärjestelmä, hakee läsnäolotiedot, koulutusohjelman, ryhmän, valmistusmishalukkuus
  • Toteutuksen opiskelijat
  • Ilmoittatumiset lukkarikoneelle, haetaan automaattilukkari ilmoittautumistietojen perusteella
  • Opiskelijarekisteri, opiskelijajärjestöjen järjestelmät
  • Ryhmän opiskelijat

Asynkroninen tiedonsiirto

  • Työtilan jäsenet
  • Outlook-kalenterimerkinnät ilmoittautumisten perusteella
  • OPALA, eräajona lähetetään valmistuneen opiskelijan tiedot

VAATIMUKSET

  • Opintososiaalisiin palveluihin tarvitsee hetun
  • Toive skeeman pohjaksi esimerkiksi Oilin skeema

 

 DataPerusrekisterin dataLopullinen rajapinta
Valmistumisjärjestelmä

-Läsäolotieto. Kopioi taulut ja sarakkeet ja esimerkkidata(sensitiivinen tieto pois!)

TauluSarakkeetEsimerkkidata
oprli

oprli

snimi

knimi

ryhma_sryh

kohj_sryh

tutki

koulutus

lasanaolo

0000000

Testi

Testi

WINHAAJAT

WINHAKOU

6

13

2

kohjhlo_vast 
kohjninimi

Winhakoulutus

opiskkieli_ai1
  
    

 

  1. Simo täydentää taulukon ja lähettää sen Eerolle. Taulukko täydennetään ensi viikolla
  2. Eduix käy tiedot läpi ja täydentää taulukon, eli mitä löytyy perusrekisteristä
  3. Eduix tekee suunnitelman skeemalle ja integraatiorajapinnoille ja toimittaa sen Simolle
  4. Eduix toteuttaa rajapinnat, joihin Simo alkaa kytkeä nykyisiä järjestelmiä

Asynkroniset tiedonsiirrot

  • Nykyiset liitännäisjärjestelmät, jotka eduixin toteuttamia. näistä tulee erilliset tarjosupyynnöt. Aikataulu ennen vuoden 2015 loppua. esim. Lukkarikone, Ahot, työtilat, OJP, Elomake, harkinnanvarainen lisäaika, uusintakoe(?)

 

 

  • No labels
You must log in to comment.