1 Innledning
I en integrasjonsarkitektur som baserer seg på APIer for datauttrekk er det essensielt at konsumerende tjenester kan få beskjed om at informasjonen i et API har blitt endret, slik at informasjonen kan behandles uten at det komplette settet med informasjon som er tilgjengelig via APIet konsumeres. Beskjedene om endring i datagrunnlag kalles for notifikasjoner.
Notifikasjoner trenger livsløpsforvaltning på lik linje med API-er. For API-er er dette tilbudt via en API Manager, som lar API-eiere forvalte tilgangene samtidig som den håndhever hvem som får gjøre uttrekk fra API-et.
For å oppnå samme grad av livsløpsforvaltning for notifikasjoner trengs det et grensesnitt som tilbyr følgende funksjonalitet:
I denne sammenheng brukes begrepene konsument og produsent om applikasjoner. En konsument er en applikasjon som tar i mot notifikasjoner fra andre applikasjoner, mens en produsent er en applikasjon som publiserer notifikasjoner som andre applikasjoner kan ta i mot.
- Enkel og brukervennlig gjør-det-selv administrasjon, slik at
- produsenter kan tilgjengeliggjøre notifikasjoner fra sitt system.
- konsumenter kan søke om abonnement på notifikasjoner som er interessante.
- produsenter kan godkjenne konsumenters ønske om abonnement på forskjellige notifikasjonstyper.
- Enkel og brukervennlig administrasjon av hemmeligheter som benyttes til autentisering.
- Synkronisering av informasjon om abonnementer og hemmeligheter til RabbitMQ, med hensyn til utførelse av autentisering og autorisasjon av konsumenter og produsenter.
- Katalog over hvilke systemer som produserer notifikasjoner er tilgjengelig.
- Katalog over hvilke systemer som konsumerer notifikasjoner er tilgjengelig.
1.1 Brukerroller
Selvbetjeningsgrensesnittet er i hovedsak myntet på produsenter og konsumenter, uten noen spesifikk avgrensning til om det er beslutningstakere eller teknisk personell som utfører operasjoner.
1.2 Kontakt
2 Redegjørelse
2.1 Bakgrunn
Forprosjektet som utredet innføring av UH:IntArk (2018-2019) identifiserte behovet for livsløpsforvaltning av notifikasjoner på lik linje med livsløpsforvaltning av APIer. Tjenesten anses dermed som en komponent i IntArk-plattformen.
Forprosjektet anbefalte implementasjon av en løsning som ville
- tilgjengeliggjøre informasjon om notifikasjoner for produsenter
- forenkle administrasjon av notifikasjonsinfrastrukturen
- ivareta sikkerhet
- sørge for eierskap og ansvarliggjøring av produsenter
2.2 RabbitMQ tilgangskontroll
Tilgangskontroll for RabbitMQ er flyttet til selvbetjeningsportalen. Konsekvensen er at nedetid for selvbetjeningsportalen vil føre til at applikasjoner ikke kan konsumere eller publisere notifikasjoner.
2.3 Eksterne produsenter
Det finnes foreløpig ikke noe funksjonalitet for å håndtere eksterne produsenter via selvbetjeningsportalen. For å få notifikasjoner fra eksterne produsenter inn i sin egen RabbitMQ-instans må man derfor manuelt opprette en spade som spar notifikasjoner fra produsenten sin RabbitMQ-instans. Ideelt sett ville det vært mulig å abonnere på notifkasjonene til eksterne produsenter fra selvbetjeningsportalen, men dette er vanskelig å implementere så lenge eksterne instanser ikke følger et standardisert oppsett.
3 Detaljebeskrivelse
3.1 Høynivådesign (Overordnet design)
Den overordnede flyten avhenger av flere ulike komponenter. Brukerene interagerer med tjenesten gjennom vevgrensesnittet.
- Pålogging (autentisering) skjer gjennom Feide. Ved pålogging blir brukeren sine gruppemedlemskap hentet fra Feide, og gruppemedlemskapene synkroniseres til selvbetjeningsportalen. Disse gruppene kan senere brukes til tilgangsstyring. Første gang en bruker logger på, blir det opprettet en brukerkonto i selvbetjeningsportalen.
- Gjennom vevgrensesnittet kan brukeren opprette applikasjoner, be om å abbonnere på andre applikasjoner sine notifikasjoner, eller håndtere inkommende forespørsler om å få abonnere på notifikasjoner. Hver av disse handlingene fører til at objekter opprettes eller endres i databasen.
- Det er en separat prosess (demon) som kontinuerlig synkroniserer ønsket tilstand til RabbitMQ. Denne utleder ønsket tilstand i RabbitMQ fra objektene som finnes i selvbetjeningsportalen.
- Når et abonnement har blitt godkjent og synkronisert, vil en konsument kunne begynne å konsumere notifikasjoner.
- Det kreves autorisasjon for at en bruker skal få lov til å gjennomføre handlinger i RabbitMQ, for eksempel om en konsument vil konsumere en melding fra en kø. RabbitMQ kan konfigureres til å flytte sjekkene for autentisering og autorisasjon til et eksternt API. I vårt tilfelle er det selvbetjeningsportalen som står for å gjøre disse sjekkene. Hver gang noen ber om å gjøre en handling som krever autorisasjon i RabbitMQ, gjør RabbitMQ en spørring mot selvbetjeningsportalen sitt API som svarer på om handlingen skal tillates. Forespørsler tillates eller avslås på grunnlag av data som finnes i selvbetjeningsportalen.
3.2 Lavnivådesign (Design av enkeltkomponenter)
Teknisk kan tjenesten deles opp i flere logiske deler basert på hvilken oppgave de utfører. De tre første av disse delene er alle inkludert i applikasjonen sitt repo.
3.2.1 Vevgrensesnitt
Tjenesten er skrevet i python og benytter web-rammeverket Django. Den består av statiske nettsider, men noen av disse statiske nettsidene har innbakte javascript-komponenter i seg. Komponentene interagerer med tjenestens endepunkt for å hente, poste og slette data, slik at endringer kan fremvises dynamisk.
3.2.2 Dæmon
Tjenesten består i tillegg av en dæmon som kjører og kontinuerlig leter etter nye endringer som trenger å synkroniseres til RabbitMQ. Når en usynkronisert endring har blitt funnet, gjøres det et forsøk på å synkronisere endringen på bakgrunn av de data som finnes i tjenesten.
3.2.3 RabbitMQ tilgangskontroll
Som nevnt under punkt 3.1, har RabbitMQ blitt satt opp til å bruke selvbetjeningsportalen for tilgangskontroll. Dette skjer ved at det selvbetjeningsportalen tilgjengeliggjør ulike endepunkter som RabbitMQ kan gjøre spørringer mot. Hvilket endepunkt som blir kalt avhenger av hvilken ressurs brukeren ber om tilgang til.
3.2.4 Mikrotjeneste for sletting av spader
En bug i RabbitMQ gjør at spader ikke kan slettes pålitelig via RabbitMQ sitt management-API. Kort fortalt består problemet i at forespørsler om å slette spader vil ende opp på en tilfeldig node. For at sletting skal fungere som forventet, må forespørselen ende opp på samme RabbitMQ-node som spaden kjører på. Mikrotjenesten kjører i samme Openshift-prosjekt som RabbitMQ og tar hånd om å sjekke hvilken node en spade kjører på før den sender kallet videre til riktig node.
3.2.5 Klient for kommunikasjon med RabbitMQ
Funksjonaliteten for å kommunisere med RabbitMQ sitt management-API er implementert i et eget gjenbrukbart bibliotek.
4 Avhengigheter
Konkrete systemer/tjenester og en kort beskrivelse av hva avhengigheten går ut på.
4.1 Feide
Tjenesten er avhengig av Feide for autentisering av brukere.
4.2 RabbitMQ
Tjenesten har en gjensidig avhengighet med RabbitMQ.
4.3 NREC
Produksjonsversjonene av applikasjonen kjører i NREC.