Datautveksling

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.

Delegere rettigheter til databehandler - UHF image
Figure 1. Delegere rettigheter til databehandler - UHF

Vis detaljer om elementene i diagrammet (Tips: Shift-klikk for å åpne i nytt vindu)

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 at blir lagret i et system fra datakilden, før det lagres. Ved provisjonering med synkront oppsalg 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 brukerenes 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 visning av kontaktinformasjon i personprofiler. En professor kjøper seg ny telefon, og melder nummeret inn til sin arbeidsgiver. Telefonnummeret er reflektert i personprofilen snarlig etter registrering i HR-systemet.

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

eOppslag Verdistrøm med kapabiliteter for tilbyder og konsument - UHF   image
Figure 2. eOppslag Verdistrøm med kapabiliteter for tilbyder og konsument - UHF

Vis detaljer om elementene i diagrammet (Tips: Shift-klikk for å åpne i nytt vindu)

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.

Publiser API image
Figure 3. Publiser API

Vis detaljer om elementene i diagrammet (Tips: Shift-klikk for å åpne i nytt vindu)

2.4. Tilgjengeliggjøre data etter forsepø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.

Tilgjengeliggjøre data etter forsepørsel løsningsmønster UHF image
Figure 4. Tilgjengeliggjøre data etter forsepørsel løsningsmønster UHF

Vis detaljer om elementene i diagrammet (Tips: Shift-klikk for å åpne i nytt vindu)

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 er ennå ikke helt avklart.

Få tilgang til data - løsningsmønster UHF image
Figure 5. Få tilgang til data - løsningsmønster UHF

Vis detaljer om elementene i diagrammet (Tips: Shift-klikk for å åpne i nytt vindu)

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.

Innhente data - løsningsmønster UHF image
Figure 6. Innhente data - løsningsmønster UHF

Vis detaljer om elementene i diagrammet (Tips: Shift-klikk for å åpne i nytt vindu)

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.

Avgi data - løsningsmønster UHF image
Figure 7. Avgi data - løsningsmønster UHF

Vis detaljer om elementene i diagrammet (Tips: Shift-klikk for å åpne i nytt vindu)

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

Hendelsestrømmer kan implementeres som Hendelseslister eller en Publisert meldingskø (publiser/abonner)

Publisering av hendelser - basiskonsept UHF image
Figure 8. Publisering av hendelser - basiskonsept UHF

Vis detaljer om elementene i diagrammet (Tips: Shift-klikk for å åpne i nytt vindu)

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.

notifikasjon verdistrøm
Figure 9. eNotifikasjon verdistrøm

3.3. Grunnleggende begreper for publisering av hendelser - Hendelsesliste og Publiser og Abonner UHF

Notifikasjoner blir publisert enten i form av en hendelsesliste eller i form av en publisering i form av publisering/abonnering til en publisert meldingskø

Grunnleggende begreper for publisering av hendelser - Hendelsesliste og Publiser og Abonner UHF image
Figure 10. Grunnleggende begreper for publisering av hendelser - Hendelsesliste og Publiser og Abonner UHF

Vis detaljer om elementene i diagrammet (Tips: Shift-klikk for å åpne i nytt vindu)

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)

Notifikasjonsinnhold - basiskonsept UHF image
Figure 11. Notifikasjonsinnhold - basiskonsept UHF

Vis detaljer om elementene i diagrammet (Tips: Shift-klikk for å åpne i nytt vindu)

3.5. Inngå avtaler om tilgang og levering av hendelsesstrømmer - Publiser og Abonner UHF

Datatibyder 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 (publisert meldingskø)

Inngå avtaler om tilgang og levering av hendelsesstrømmer - Publiser og Abonner UHF  image
Figure 12. Inngå avtaler om tilgang og levering av hendelsesstrømmer - Publiser og Abonner UHF

Vis detaljer om elementene i diagrammet (Tips: Shift-klikk for å åpne i nytt vindu)

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 (publisert meldingskø)

Inngå avtaler om tilgang og innhenting av hendelsesstrømmer - Hendelsesliste og Publiser og Abonner UHF image
Figure 13. Inngå avtaler om tilgang og innhenting av hendelsesstrømmer - Hendelsesliste og Publiser og Abonner UHF

Vis detaljer om elementene i diagrammet (Tips: Shift-klikk for å åpne i nytt vindu)

3.7. Generere og publisere notifikasjoner - Publiser og Abonner UHF

Datatilbyder publiserer en notifikasjon til en Notifikasjonsdistubusjon i form av en publisering/abonneringsløsning

Generere og publisere notifikasjoner - Publiser og Abonner UHF  image
Figure 14. Generere og publisere notifikasjoner - Publiser og Abonner UHF

Vis detaljer om elementene i diagrammet (Tips: Shift-klikk for å åpne i nytt vindu)

3.8. Konsumer notifikasjoner - Publiser og Abonner UHF

Datakonsumentlytter på emner som konsumenten abonnerer på hos Datatilbyder. Når en ny melding kommer i meldingskøen trigges konsumsjonen av notifikasjonen. Datakonsumenten vurderer relevans 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"

Konsumer notifikasjoner - Publiser og Abonner UHF image
Figure 15. Konsumer notifikasjoner - Publiser og Abonner UHF

Vis detaljer om elementene i diagrammet (Tips: Shift-klikk for å åpne i nytt vindu)

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 å 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.

Be om oppdatering  - løsningsmønster i UHF sektoren  image
Figure 16. Be om oppdatering - løsningsmønster i UHF sektoren

Vis detaljer om elementene i diagrammet (Tips: Shift-klikk for å åpne i nytt vindu)

4.2. Håndtere forespørsel om oppdatering - 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.

Håndtere forespørsel om oppdatering  - løsningsmønster UHF  image
Figure 17. Håndtere forespørsel om oppdatering - løsningsmønster UHF

Vis detaljer om elementene i diagrammet (Tips: Shift-klikk for å åpne i nytt vindu)