Altinn Melding og formidling
Thu Nov 23 2023 12:55:16 GMT+0100 (CET) Erik Hagen erik.hagen@digdir.no
Introduksjon
Altinn melding og Altinn formidling er to av produktene for meldingsutveksling som tilbys av Digdir. Disse produktene sorterer under felles produkteier, og presenteres derfor her samlet.
Altinn er for tiden i en moderniseringsprosess, der en går fra Altinn II til Altinn III. Denne prosessen forventes skal være ferdig innen juni 2025, blant annet fordi nåværende driftsavtaler da utgår. Dette innebærer betydelig innsats, da dagens Altinn-løsninger skal moderniseres og migreres til skyen.
En søker å legge opp migreringsløpet slik at det peker i "riktig" retning i forhold til et mer langsiktig løp. Det arbeides derfor med visjoner og malgsiktig strategi som grunnlag for løsningsvalfl på kort sikt.
Produktstrategien for Altinn melding og Altinn formidling henger sammen med produktstrategien for hele produktområdet for meldingsutveksling i Digdir. Det er også sammenhenger med andre produkteområder innen datadeling.
Løsninger og arkitektur as-is
Løsninger for meldingsutveksling…
Altinn Broker As-Is
Altinn formidling 2.0 - forretningstjenester og prosesser (Steinars modell)
.png)
Altinn formidling 2.0 - sekvensdiagram (påbegynt)
.png)
Altinn formidling - applikasjonstjenester - flow
Altinn formidling 2.0 - applikasjonstjenester - service usage
Altinn formidling 2.0 - applikasjonstjenester og API-er
Atlinn 2.0 formidling - applikasjoner og teknologier
Løsninger to-be
…
Altinn Broker to-be
..
Brukerbehov
Use cases for meldingsutveksling
View dok, Geneiske use cases
Juridiske forhold
-
Gjeldende lovpålagte krav. Eksempel: GDPR med krav til dataminimering mv.
-
Langtidslaging (arkivering)
-
Dokumentasjon av etterlevelse
-
Sporing av data - dataproveniens
-
Egenskaper relatert til organisatorisk samhandling
-
Type forretningsprosess. Eksempler: Bilateral prosess mellom to kjente parter (herunder spørring og forhåndsavtalt, periodisk distriusjon); Tverrgående prosess mellom faste parter; Tverrgående prosess mellom dynamiske oppdagete parter.
-
Antall samhandlingsparter
-
En-til-en, en-til-mange, mange-til-mange, mange-til-en
-
-
Kjente eller ukjente mottakere
-
Fast eller dynamisk gruppe med samhandlingsparter
-
Prosessens levetid. Relevant for feilhåndtering: Kortlevde prosesser med innebygd transaksjonssikkerhet kan tilbakerulles gjennom generelle mekanismer, f.eks. slik dette støttes av rollback i relasjonsdatabaser. Langlevde prosesser krever skreddersydde kompensasjonsaksjoner.
-
Roler og ansvar. Hvem skal ha ansvar for hva? Hvem sier om du får tilgang til opplysninger eller ikke?
-
Egenskaper relatert til semantisk interoperabilitet
-
Støtte for felles datamodeller (core vocabularies)
-
Støtte for aktuelle utvekslingsformater
-
Støtte for lenking av data
Egenskaper relatert til teknisk samhandling
-
Utvekslingsprotokoller
-
Synkron eller asynkron kommunikasjon
-
Støtte for utveklsingsprotokoller som f.eks. SOAP og REST
-
-
Tjenestekvalitet (QoS refers to the maintenance of the session once established and covers aspects such as throughput, error recovery/detection)
-
Meldingsstørrelse
-
Størrelse på enkeltvedlegg vs. samlede vedlegg?
-
-
Leveringstid for meldinger. Mål: Mikrosekunder, millisekunder, sekunder, timer, dager
-
Garantert leveringstid vs. krav til leveringstid
-
-
Responstid for spørringer. Mål: Mikrosekunder, millisekunder, sekunder, timer, dager
-
Garantert responstid vs. krav til responstid
-
-
Leveringssikkerhet. Mål: Prosentvis sannsynlighet for vellykket levering og mottak
-
Grad av garantert levering (uten behov for tilbakemelding på applikasjonslaget)
-
-
Lagringstid for data og logger
-
-
Tjenestegrad - GoS refers to the ability to access and establish services and includes the time required to establish sessions, system reliability (assessment of mean time before failure (MTBF) and meant time to repair (MTTR) for example) and recovery and system resilience (i.e. how it degrades).
-
Service establishment time
-
System reliability
-
System MTBF
-
System MTTR
-
Nettverkskvalitet
-
Andre egenskaper
-
Føringer
-
Prinsipper. sempel Digdirs overordnede arkitekturprinsipper
-
Standarder. Eksempel: Standarder i Referansekatalogen
-
Avtaler
-
-
Kompetanse
-
Kompleksitet
-
Kostnader
-
Informasjonssikkerhet og personvern
-
Risikoanalyser
-
Kvalitetskrav for konfidensialitet, integritet og tilgjengelighet
-
Mekanismer for autentisering, autorisasjon, kryptering, ikke-benektelse, mv.
-
.png)
Vedlegg
…
Diverse utkast - gammelt og nytt
Fellesløsninger - oversikt og sammenheng
.png)
.png)
.png)
.png)
.png)
Mønstre (Erik, 2021)
Utvekslingsmønstre - oversikt (canvas)
Merk: Denne oversikten er i arbeid.
.png)
Deling av data (Erik, 2019)
Del og innhent data og hendelser, detaljert verdistrøm datatilbyder med kapabiliteter
Forklaring: Datatilbyder må evne å bestemme hvilken teknisk løsning som skal benyttes når dataene gjøres tilgjengelig som åpne data
Datatilbyder må evne å velge hvor og hvordan dataene skal gjøres tilgjengelig, hvor skal datakonsument finne dataene og på hvilket format skal dataene deles
Datatilbyder må videre evne å bestemme detaljeringsgrad på dataene
Krav til personvern må kunne ivaretas, samt eventuelle krav i forhold til andre skjermingsverdige opplysninger
Løsning: Prosesser for å dele data som åpne data
.png)
Sammenhengende tjenester Erik, 2019)
Sammenhengende tjenester - Overordnede verdistrømmer
Del data , detaljert verdistrøm datatilbyder med kapabiliteter
Forklaring: Datatilbyder må evne å bestemme hvilken teknisk løsning som skal benyttes når dataene gjøres tilgjengelig som åpne data
Datatilbyder må evne å velge hvor og hvordan dataene skal gjøres tilgjengelig, hvor skal datakonsument finne dataene og på hvilket format skal dataene deles
Datatilbyder må videre evne å bestemme detaljeringsgrad på dataene
Krav til personvern må kunne ivaretas, samt eventuelle krav i forhold til andre skjermingsverdige opplysninger
Løsning: Prosesser for å dele data som åpne data
Innhent data, detaljert verdistrøm konsument med kapabiliteter
Overordnet verdistrøm - Samhandle i tverrgående prosesser
Utfør steg i samhandlingsprosess
Figuren nedenfor viser en generisk prosess for operativ databehandling, der datautveksling inngår.
Oppsummering:
-
Enhver databehandling krever data som input og vil resultere i output av data.
-
Input kan være alt fra en notifikasjon uten videre innhold til komplette meldinger. Om tilleggsdata må innhentes, gjøres dette f.eks. ved å forespørre aktuelle datakilde eller ved å vente på ytterligere input initiert av andre.
-
Output vil være lagrede data for bevis og gjenbruk, samt videresendte data til påfølgende ledd i behandlingskjeden, der det er aktuelt.
-
Det er ikke direkte vist i dette enkle prosessdiagrammet, men videresendte data kan her inkludere svar til avsender av mottatte data, i tillegg til en eller flere andre samhandlingsaktører.
-
For behandling av personopplysninger må det finnes et dokumentert behandlingsgrunnlag, enten i form av hjemmel eller samtykke. Dette vil være del av det totale datagrunnlaget for databehandlingen.
De viktigste kapabilitetene som behøves er indikert for hvert prosessteg. TBD?
.png)
.png)
.png)
.png)
.png)
