Datautveksling
Fellestjenestene i datadelingsplattformen brukes i felles prosesser for å dele data. Gjennom å utføre en fellesprosess, vil en datakonsument eller en datatilbyder oppnå en evne (kapabilitet). Dette kapittelet beskriver de fellesprosessene som er definert for deling av data, og de evnene som oppnås ved å benytte dem. Prosessbeskrivelsen viser hvilke tjenester støtter prosessen, og hvilke komponenter realiserer tjenestene. Prosessbeskrivelsen viser også de sentrale forretningsobjekter og dataobjekter som benyttes og produseres underveis. Både tjenester og komponenter kan aksessere dataobjekter.
Prosessbeskrivelsene er presentert i ArchiMate modelleringsspråk. Vår bruk av Archimate er beskrevet i Vedlegg F. Prosesstegningene er definert for høyere utdanning og forskning, omtalt som "UHF".
1. Delegere rettigheter til databehandler - UHF
Delegering av rettigheter til databehandler er det en konsument må gjøre for at en leverandør kan identifisere seg med sitt eget virksomhetssertifikat og opptre på vegne av konsumenten som er den som innehar behandlingsgrunnlaget for å innhente data.
2. Datautveksling ved oppslag
2.1. Datautvekslingsmønster
Synkront oppslag
Synkront oppslag er realiseringen av eOppslag. I dette mønsteret hentes data fra datakilden ved behov. Et typisk eksempel på synkront oppslag kan være uthenting av aktuelle konteringsregler fra økonomisystemet ved prevalidering av regnskap før det føres i hovedbok.
Provisjonering via synkront oppslag
Synkront oppslag kan også benyttes til provisjonering. I et slikt tilfelle hentes all informasjon det er nødvendig å lagre i et system fra datakilden. Ved provisjonering med synkront oppslag er det ofte store mengder data i bevegelse, og overføringen tar tid. Disse egenskapene medfører at provisjonering via synkront oppslag utføres sjelden. Denne metoden blir ofte kalt batch-provisjonering.
Provisjonering via lettvekts eNotifikasjoner
I de tilfellene provisjonering via synkrone oppslag ikke kan besørge en propageringshastighet som understøtter brukernes behov, kan lette eNotifikasjoner benyttes i kombinasjon med eOppslag. De lette eNotifikasjonene bærer informasjon om hvilke data som har endret seg i datakilden, og leveres umiddelbart til de som måtte være interessert i dataendringene. Dette tillater systemet som er avhengig av provisjonering å hente kun den informasjonen som har blitt endret.
Et typisk eksempel på bruk av dette mønsteret er en professor som publiserer en artikkel i Nasjonalt Vitenarkiv. Professorens personprofil på institusjonens nettsider blir oppdatert snarlig etter at artikkelen er publisert i Nasjonalt Vitenarkiv, siden det blir sendt en lettvekts notifikasjon om registreringen.
Fremtidige utvidelser
Digitaliseringsdirektoratets referansearkitektur definerer to varianter av eNotifikasjon, den tidligere omtalte lettvektsvarianten, og en basert på hendelseslister.
Hendelseslister består av notifikasjoner som konsumeres via eOppslag. Notifikasjonene kan inneholde varierende mengde informasjon, og propageres ikke like hurtig som lettvektsvarianten beskrevet ovenfor. Hendelseslistene er persistente av natur (til forskjell fra lettvektsvarianten, der notifikasjonene «forsvinner» når de er konsumert), og lar sådan datakilden beskrive en historikk. Et typisk eksempel på en slik historikk kan være de forskjellige stegene i en saksbehandlingsprosess, der de forskjellige stegene må være klart definert for å kunne foreta videre steg i saksbehandlingsprosessen, eller realisere etterlevelse av juridiske krav.
I neste versjon av referansearkitekturen vil det vurderes å inkludere varianten basert på hendelseslister. Det vil også vurderes å utvide definisjonen av lettvektsnotifikasjoner slik at de kan bære konkrete data (også kalt Event Carried State Transfer), til forskjell fra eksisterende definisjon der de kun bærer en referanse til dataene som er endret.
2.2. eOppslag Verdistrøm med kapabiliteter for tilbyder og konsument - UHF
2.3. Publiser API
En prosessflyt som datatilbyder må gjennomføre for å gjøre et API synlig og tilgjengelig gjennom kataloger og søkeløsninger. Metadata om APIet blir registrert i API-katalogen. Metadata inkluderer begreper og datamodeller omfattet av datasettet som APIet tilgjengeliggjør, samt tilganger (scopes) knyttet til APIet som kan tildeles konsumenter.
APIet registrert i UHF API katalog blir høstet inn i Felles API katalog. Vi ønsker at tilganger (scopes) i tillegg skal registreres i Maskinporten slik at konsumenter utenfor UHF sektoren kan oppdage APIet og be om tilgang på et senere tidspunkt.
2.4. Tilgjengeliggjøre data etter forespørsel - løsningsmønster UHF
En prosessflyt som datatilbyder må gjennomføre for å tildele rettigheter til en konsument som ber om tilgang til data. En datatilbyder mottar forespørsel om tilgang til et API på vegne av en organisasjon eller bruker. Dataeieren tar stilling til om konsumenten skal få tilgang til data gjennom APIet. Tilgang registreres knyttet til konsumentens klient (applikasjonen som benytter APIet) i klientregisteret.
2.5. Få tilgang til data - løsningsmønster UHF
En prosessflyt en konsument av data må gjennomføre for å få tildelt rettigheter til data gjennom et API. Det omfatter å få kjennskap til aktuelt API gjennom API-katalogen, autentisere konsumenten, inngå avtale om bruk av data, samt å registrere tilganger hos den tekniske komponenten som skal utføre tjenestekallet. Dersom det dreier seg om tilgang til et åpent tilgjengelig API, kan enkelte delaktiviteter i prosessene hoppes over, men for å kunne logge informasjon om bruk av APIer bør alle konsumenter av et API registreres i klientregisteret.
Viewet bør strengt tatt vise at konsumenten kan finne APIet enten i UHF sektorens API katalog eller i Felles datakatalog. Vi velger å vise prosessflyten kun med UHF sektorens komponenter både for å kunne presentere en oversiktlig prosessflyt og fordi forholdet til de nasjonale felleskomponenter ennå ikke er helt avklart.
2.6. Innhente data - løsningsmønster UHF
En prosessflyt en konsument utfører når det utføres et tjenestekall for å innhente data gjennom et API. API-adressen hentes i API-katalogen. Tilgang til APIet byttes inn mot et kjøretids-token i autoriseringstjenesten. Tjenestekall til APIet utføres gjennom API gateway der tokenet benyttes for å få tilgang. Dersom det er et åpent API er det kun relevante prossessteg som utføres.
2.7. Avgi data - løsningsmønster UHF
En prosessflyt en tilbyder av data utfører for å svare på en dataforespørsel. Tilbyder mottar forespørsel om oppslag med et aksesstoken. Klienten som forespør autentiseres og token valideres. Eventuelt mer fin-granulert tilgangskontroll utføres og data returneres. Tilgang kontrolleres kun dersom det er snakk om et sikret API.
3. Datautveksling ved publisering – konsumering (hendelsesbasert)
Datautveksling ved publisering og konsumering av hendelser er basert på publisering-konsumering i Referansearkitektur for datautveksling fra Digitaliseringsdirektoratet.
3.1. Publisering av hendelser - basiskonsept UHF
Hendelser er endringer som oppstår hos en datatilbyder og som nødvendiggjør at datatilbyder deler denne endringen med andre.
Datatilbyder publiserer en hendelse til en hendelsesstrøm. Datakonsument konsumerer hendelser fra hendelsesstrømmen og om nødvendig gjør oppdateringer av sine data.
Hendelsestrømmer implementeres som lettvekts notifikasjoner i en notifikasjonskø (publiser/abonner).
Alternative måter er blant annet hendelseslister, som beskrevet i Digitaliseringsdirektoratets referansearkitektur for datadeling og i kapittelet Datautvekslingsmønster.
3.2. eNotifikasjon - oversikt over verdistrømmer UHF
Den overordnede verdistrømmen vist under skisserer handlingene hos datatilbyder og datakonsument som inngår i dette utvekslingsmønsteret. Datatilbyderen oppretter en hendelsesstrøm som datakonsumenten oppdager og abonnerer på. Datatilbyderen publiserer notifikasjoner om hendelser i hendelsesstrømmen, og datakonsumenten innhenter disse. Når konsumenten har mottatt en notifikasjon, vurderer konsumenten om det er behov for å innhente mer informasjon om hendelsen. I så fall benytter konsumenten synkront oppslag som beskrevet tidligere for innhentingen.
3.3. Grunnleggende begreper for publisering av hendelser - Hendelsesliste, Publiser og Abonner UHF
Notifikasjoner blir publisert i form av publisering/abonnering til en notifikasjonskø. Hendelseslister er en alternativ måte å beskrive en slik strøm av hendelser.
3.4. Notifikasjonsinnhold - basiskonsept UHF
Som et minimum må en notifikasjon inneholde en identifikator. Anbefalt innhold er basert på standarden CloudEvents (se Utvikling av ytre API i dette dokumentet)
3.5. Inngå avtaler om tilgang og levering av hendelsesstrømmer - Publiser og Abonner UHF
Datatilbyder mottar forespørsel om å inngå avtale om tilgang og innhenting av hendelsesstrømmer Hendelsesstrømmen kan være i form av en hendelsesliste eller abonnement på et emne (notifikasjonskø).
3.6. Inngå avtaler om tilgang og innhenting av hendelsesstrømmer - Hendelsesliste og Publiser og Abonner UHF
Datakonsument inngår avtale om tilgang og innhenting av hendelsesstrømmer Hendelsesstrømmen kan være i form av en hendelsesliste eller abonnement på et emne (notifikasjonskø).
3.7. Generere og publisere notifikasjoner - Publiser og Abonner UHF
Datatilbyder publiserer en notifikasjon til en Notifikasjonsdistribusjon i form av en publisering/abonneringsløsning. Notifikasjonsdistribusjonen er realisert som en publisert kø per abonnent med et emne.
Datatilbyder publiserer notifikasjoner til disse køene når hendelser oppstår hos datatilbyder.
Hver enkelt abonnent har en innboks som abonnenten konsumerer. Notifikasjoner er transient og forsvinner fra innboksen etter at de er konsumert.
3.8. Konsumer notifikasjoner - Publiser og Abonner UHF
Datakonsument lytter på emner som konsumenten abonnerer på hos Datatilbyder. Når en ny notifikasjon kommer i notifikasjonskøen trigges konsumering av notifikasjonen.
Datakonsumenten vurderer relevans med basis i regler definert for abonnenten og foretar videre behandling av notifikasjon.
Videre behandling består av å gjøre et eOppslag (via API) som beskrevet i «Løsningsmønster forespørsel UHF» dersom konsumenten har behov for ytterligere informasjon om hendelsen beskrevet i notifikasjonen.
4. Oppdatering
Datatilbyder kan gjøre oppdatering av data tilgjengelig for datakonsument gjennom et API. Prosessen for en datakonsument å be om tilgang til oppdatering (se Få tilgang til data) og for en datatilbyder å gi tilgang til oppdatering (se Tilgjengeliggjøre data etter forespørsel) er tilsvarende som for tilgang til å lese data. Det vil ofte være forskjellige kriterier som må oppfylles for å få lov til å oppdatere data enn for å lese data. Dette kan inkludere både kvalitetssikring og juridiske hensyn.
4.1. Be om oppdatering - løsningsmønster i UHF sektoren
En prosessflyt en konsument utfører når det utføres et tjenestekall for å be om en oppdatering av data gjennom et API. API-adressen hentes i API-katalogen. Tilgang til APIet byttes inn mot et kjøretids-token i autoriseringstjenesten. Tjenestekall til APIet utføres gjennom API gateway der tokenet benyttes for å få tilgang.
4.2. Håndtere forespørsel om oppdatering - løsningsmønster UHF
En prosessflyt en tilbyder av data utfører for å svare på en oppdateringsforespørsel. Tilbyder mottar forespørsel om oppdatering med et aksesstoken. Klienten som forespør autentiseres og token valideres. Eventuelt mer fin-granulert tilgangskontroll utføres og data oppdateres.
