Innhold
Motivasjon og innhald
USIT/LOS jobbar for tida med UiO sin nye integrasjonsarkitektur. Det er blitt vedteke prinsipper for integrasjonsarkitekur og det jobbast vidare med konkretisering av arkitekturen. I den samanheng er det ønskeleg at bestillingar rundt FSWS følger ny og komande arkitektur, for å unngå meirarbeid seinare.
I den nye integrasjonsarkitekturen leggast det blant anna vekt på RESTful integrasjon gjennom webservices, samt meldingsbaserte oppdateringar gjennom ei meldingskø. Desse to komponentane vil vere ein fordel å bruke med data frå FS, då FS inneheld store mengder data, og som brukast mange stader. Ved å gjere integrasjonen RESTful vert det enklare for klientar, også andre enn Cerebrum, å ta i bruk tenesta, og med meldingsbasert integrasjon vert dataflyten mykje kjappare. Til dømes kan studentar sine kontoar bli oppdaterte på minuttar etter ei endring i FS, i staden for i løpet av eit døgn som i dag. Dette er ei klar forbetring av brukaropplevinga! Vi foreslår difor at integrasjonen med FSWS vert meldingsbasert.
Sidan det ikkje er sikkert at vi kan få alt frå FSAT med det første, er forslaget vårt delt i separate steg. Det første steget er tilstrekkeleg for at Cerebrum skal kunne ta i bruk FSWS, men det er med steg 2 vi oppnår full meldingsbasert oppdatering:
- RESTfulle WS-kall: Cerebrum ønsker seg at informasjonen vi treng kjem på eit RESTfult format gjennom WS, altså med REST/JSON. Dette er sterkt ønskeleg for at Cerebrum skal kunne ta i bruk FSWS. Meir detaljar kjem lenger ned.
- Meldingskø: Ved at FSWS begynner å informere om endringar til ei meldingskø, vil Cerebrum kunne ta affære umiddelbart og be om relevant informasjon av FSWS gjennom forhåpentlegvis eksisterande, RESTfulle WS-kall. Dette steget gjer integrasjonen meldingsbasert.
I tillegg anbefaler vi at FSWS sin kommunikasjon går gjennom ein komande API gateway, for å enkelt administrere og styre tilgangen til FS sine data. Dette er ei generell teneste, og AF kan med den også styre tilgangen til andre konsumentar enn Cerebrum.
Steg 1 - WS-funksjonalitet og innhald
Vi har tidlegare sett på kva vi får gjennom dagens FSWS, sjå Utredning av å erstatte SQL-utplukk med FSWS. Oppsummert så gir den oss ein del av det vi treng, men noko informasjon manglar - som er motivasjonen for AF si bestilling til FSWS for Cerebrum - og i tillegg så er dette fulldumpsutplukk. Samtidig som dette arbeidet pågjekk begynte ny integrasjonsarkitektur å ta form. Vi har difor, i tillegg til å kommentere på AF sitt utkast til utplukk, også nye tilbakemeldingar med hensyn til integrasjonsarkitekturen.
Våre ønsker til FSWS sin oppførsel:
- RESTful, som vil sei at den støtter REST/JSON på "riktig" måte. REST er ein enkel protokoll, medan RESTful definerer ein del oppførsel og køyrereglar som gjer at integrasjonen vert meir standardisert og enklare å ta i bruk.
- Atomære oppslag, til dømes at vi kan hente ut fødselsnummeret til ein spesifikk student med eit eige oppslag. Dette er nødvendig ved bruk av meldingskø og gjer det enklare å styre tilgang til data gjennom API gateway.
- Utlistingsfunksjonar, som AF har beskreve, er berre nødvendige for Cerebrum dersom FSAT ikkje ønsker å ta i bruk meldingskø. Med meldingskø treng ikkje Cerebrum lenger å hente ut lister over alle studentar; meldingskøa vil gje oss informasjon om kva studentar eller studieelement som er relevante å hente ut informasjon om.
Desse ønska gjer at FSWS vil måtte endrast på mykje meir enn vi har diskutert i tidlegare møter. Plan B kan vere å fortsette som vi har tenkt tidlegare, å bruke getBASData og utfylle med ny funksjonalitet i FSWS, avhengig av behova til AF, men frå Cerebrum si side er det heller ønskeleg å vente på ei RESTful teneste foran FS.
Tilbakemeldingar til innhaldet i eksisterande datautplukk:
- Utplukka frå AF nemner ikkje studentnummer. Er det ein glipp? Vi ønsker å bruke studentnummer som identifikator, og unngå bruk av fødselsnummer.
- I utplukket for aktiv student får vi ikkje vite om studenten er EVU, phd eller vanleg student. Vi bruker i dag studienivåkode for å bedømme dette. Dersom ønsket er å ikkje skille på ulike studenttypar, men slå alt saman i same oppførsel, treng vi ikkje dette.
- Emnestudentar skillast i dag ut som eige utplukk. Det ser ut til at utplukket for aktiv student dekker desse, men vi vil sikre oss at dei er med.
- Postadresser manglar i begge utplukka, for aktiv og opptaksstudent. Adresser trengs i dag for å sende ut passordbrev manuelt. Dersom ikkje dette skal støttast lenger, treng vi ikkje adressene, men det gjer at nokre ikkje vil kunne få tilsendt passordbrev. Ein kjapp sjekk viste at det vart sendt ut rundt 100 manuelle passordbrev på 2.5 månadar frå Cerebrum.
- Dersom FS har fått inn støtte for alternativ til fødselsnummer så ønsker vi ei teneste for dette også.
- Info om stedkodestruktur og info om emner ser ut til å mangle. Dette brukast i dag av studentautomatikken, bl.a. for å generere automatiske grupper og enkelte e-postlister.
Veit vi at den eksisterande tenesta i FSWS, getBASData, kan brukast av UiO? Er den blitt testa? Kor lang tid tek den i så fall?
Steg 2 - bruk av meldingskø
USIT skal ha ei meldingskø, MQ, i pilot i løpet av 2016. MQ skal bruke standard protokollar for overføring av meldingar. Produsentar av data, som FS, informerer meldingskøa straks noko har skjedd i FS. Konsumentar som er interesserte i endringar i FS abonnerer på desse frå meldingskøa. Meldingskøa har ansvaret for å vidareformidle alle meldingar frå FS til abonnentar, og tek blant anna vare på meldingar til konsumentar som er nede.
Dei viktigaste punkta rundt dette:
Ønske om hendelsesbasert oppdatering via meldingskø. I utkastet er det beskreve at vi kan oppgje "endringar etter dato" for å unngå fulldump. Vi ønsker å ta det eitt steg vidare, og at FSWS snakker med ei meldingskø. Døme på korleis integrasjonen då fungerer:
- FSWS sender melding til meldingskøa om at ein person eller studieelement er blitt oppdatert.
- Cerebrum abonnerer på meldingskøa og får varsel om at noko har skjedd med ein spesifikk person eller studieelement.
- Cerebrum ber FSWS om meir informasjon om den spesifikke personen/studieelementet og oppdaterer seg med dette.
Frå FSWS har vi då behov for:
- At FSWS kan kommunisere med ei meldingskø på eit standard format for meldingar.
- At FSWS har atomære oppslag for uthenting av informasjon ein spesifikk student/person og studieelement. Med atomære oppslag meinast kommandoar for å td. hente ut spesifikk informasjon om enkeltpersonar, til dømes eit eige oppslag for å hente ut fødselsnummer, sidan dette ikkje skal vere tilgjengeleg for alle system.
Alternativt, om FSAT ikkje får på plass meldingskø, treng vi listefunksjon, som AF har beskreve, men meir atomære, som nemnd over.
Ein slik integrasjonen er ikkje Cerebrum-spesifikk. Vi ønsker at det brukast ei generell og standard meldingskø, som alle andre, relevante IT-tenester kan ta i bruk.
Bruk av API gateway
Vi ønsker også at FSWS kommuniserer via ein API gateway i staden for direkte med Cerebrum. API gateway tek seg av tilgangskontrollen mellom system, ved å først sjekke om Cerebrum har blitt gitt tilgang til det relevante kallet/utplukket. Ein slik komponent er relevant for IT-sikkerheten, ved å blant anna gje ein betre oversikt over integrasjonsbildet til organisasjonen, viser kva system som har tilgang til kva data, og forenklar og distribuerer administrasjonen av tilgangskontrollen.
I praksis vil ein API gateway gjere at Cerebrum snakker med API gateway, som først sjekker om Cerebrum har lov til å få informasjonen den spør om frå FS, før den ber om informasjonen frå FSWS på vegne av Cerebrum. API gateway kan også brukast på same måte av andre klientar, men AF må først gje klienten tilgang i administrasjonsgrensesnittet til API gateway.
Det er planen at USIT skal sette opp ein slik API gateway i pilot i 2016.
Det er uvisst kor mykje arbeid det er for ein produsent, som FSWS, å ta i bruk API gateway, men med ein RESTful kommunikasjon vert det enklare å granulere tilgangsstyringa.