1. Introduksjon

1.1. Generelt

Referansearkitektur for datautveksling gir god praksis for arkitekturer og løsninger innen temaområdet datautveksling.

Primære målgrupper er virksomhetsarkitekter, løsningsarkitekter og tech-leads i utviklingsteam.

Beskrivelsene kan leses som en sammenhengende "bok", men forutsetter en viss kjennskap til grunnleggende konsepter og metodikk.

Se også:

1.2. Omfang og avgrensing

Foreliggende referansearkitektur for datautveksling omfatter områder og basismønstre som svarer på følgende grunnleggende samhandlingsbehov:

  1. Spørring og oppslag: Enkeltvise oppslag i enkeltstående datakilder.

  2. Forsendelse: Enkeltvise overføringer av data fra en avsender til en bestemt mottaker.

  3. Publisering: Publisering av data og hendelser fra en til mange, med løs kopling mellom tilbydere og konsumenter.

Basismønstrene gir grunnlag for sammensatte og mer avanserte samhandlingsmønstre.

Referansearkitektur for datautveksling omfatter inntil videre følgende prioriterte arkitektur- og løsningsmønstre (uthevet skrift angir her avtalte leveranser i 2019):

  1. Deling av data ved forespørsel:

    1. Generisk mønster for spørring og oppslag.

    2. eOppslag - et arkitekturmønster for oppslag i data gjennom synkrone API-kall

    3. Løsningsmønster for eOppslag med bruk av nasjonale fellesløsninger i Norge

  2. Deling av data ved forsendelse:

    1. Generisk mønster for meldingsforsendelse

    2. eMelding - et arkitekturmønster etter modell av CEF eDelivery

    3. Løsningsmønster for eMelding i PEPPOL-infrastrukturen

  3. Deling av data ved publisering:

    1. Generisk mønster for publisering av data

    2. eNotifikasjon - arkitekturmønster for strømming av hendelsesdata

Illustrasjon - prioriterte arkitektur- og løsningsmønstre:

Aktuelle referansearkitekturer image
Figur 1. Prioriterte referansearkitekturer (høst 2019)

Her gjengis også en figur fra temaområde datautveksling som viser en oversikt over de viktigste operative og forvaltningsmessige kapabilitetene for henholdsvis datatilbyder og datakonsument. Nederst i figuren er det også listet tverrgående temaer som vurderes som særlig viktige i tilknytning til datautveksling.

Datautveksling - overordnet oversikt over kapabiliteter og temaer  image
Figur 2. Datautveksling - overordnet oversikt over kapabiliteter og temaer

Videre beskrivelser av temaer og kapabiliteter gis i tilknytning til beskrivelse er av de enkelte referansearkitekturene.

Virksomhetsarkitekturen kan inndeles i områder, eller temaområder, og videre i kapabiliteter. Dette kan gjøres i flere nivåer, til et hensiktsmessig detaljnivå. Med kapabilitet menes en evne som er forbundet med en rolle eller en aktør. Slike aktører kan være organisasjoner, personer eller tekniske systemer. Realiseringen av en kapabilitet gjøres igjen typisk gjennom organisasjoner, mennesker, prosesser og teknologier, gjerne i kombinasjon.

1.3. Leseveiledning

Det skilles mellom konseptuelle arkitekturbeskrivelser og mer løsningsnære beskrivelser. Løsningsmønstre gir konkret veiledning for løsningsarkitekter og utviklere, f.eks. ved å angi bruk av nasjonale felleskomponenter.

De generiske og konseptuelle beskrivelsene kommer først, og etterfølges eventuelt av alternative, mer spesifikke anvendelser (arkitektur- eller løsningsmønstre).

Løsningsarkitekter som er ute etter praktiske tips, kan velge å gå rett på de mest konkrete beskrivelsene.

2. Mønstre for spørring og oppslag

2.1. Generisk mønster for spørring og oppslag

2.1.1. Om dette mønsteret

Generisk mønster for spørring og oppslag adresserer området Deling av data på forespørsel og omhandler tilgjengeliggjøring av data og oppslag i data, som sett fra henholdvis datatilbyder og datakonsument.

Mønsteret dekker både asynkrone og synkrone oppslag, og det tas ikke stilling til kommunikasjonsprotokoll. Spørring og oppslag kan gjøres både mot data med ulike grader av tilgangsbegrensninger og mot åpne data helt uten tilgangsstyring.

Mønsteret gir heller ingen begrensninger i hva slags informasjon det gjelder, om det er strukturerte eller ustrukturerte data, eller hva data skal brukes til. Tilbyder og konsument av data kan være på tvers av virksomheter eller innenfor samme virksomhet.

Eksempler på bruk:

  • Oppslag i et felles dataregister, f.eks. Folkeregisteret.

  • Oppslag av data hos en annen virksomhet .

  • Oppslag av data i egen virksomhet.

2.1.2. Kapabilitetskart - relevante kapabiliteter

Modellen under viser hovedinndelingen i kapabiliteter en tilbyder og en konsument må ha for å dele data gjennom spørring og oppslag. Dette er av området som omhandler Deling av data på forespørsel.

Kapabiliteter
Figur 3. Kapabiliteter, deling av data på forespørsel

Tilbyder må kunne tilgjengeliggjøre data og dette er delt i to kapabiliteter:

  • Tilgjengeliggjøre data omhandler hvordan man registerer og setter opp tilganger.

  • Avgi data omhandler den operative delingen av data fra tilbyder.

Tilsvarende er det to detaljerte kapabiliteter tilknyttet konsument og det å innhente data:

  • Få tilgang til data består av prosesser for oppsett av tilgang.

  • Innhente data er det konsumenten må gjøre hver gang det gjøres et oppslag.

I tillegg kan begge parter ha kapabiliteten:

  • Delegering av rettigheter til databehandler må gjøres dersom en av partene benytter seg av en databehandler.

Tabell 1. Elementer i view for Kapabiliteter, forespørsel-svar
Element Beskrivelse

Datatilbyder

Tilbyder av data til andre aktører.

Datakonsument

Den som innhenter eller mottar data fra andre aktører.

Delegere rettigheter til databehandler

Evnen til å delegere rettigheter til databehandler som utfører oppgaver på vegne av behandlingsansvarlig.

Tilgjengeliggjøre data

Evnen til å gjøre data tilgjengelig for aktører utenfor egen virksomhet.

Få tilgang til data (konsument)

Evnen til å skaffe seg tilgang til tilbudte data fra annen aktør.

Avgi data

Evne til å avgi data på forespørsel. Kan omfatte tilgangsstyring.

Innhente data

Evnen til å innhente data fra en annen aktør.

Mer informasjon om kapabilitetskart og nedbrytingen av overordnede temaområder og kapabiliteter finnes under Nasjonalt arkitekturlandskap. Her finnes Deling av data på forespørsel som et eget område under området Datautveksling.

2.2. eOppslag - oppslag i data gjennom synkrone API-kall

2.2.1. eOppslag - generelt arkitekturmønster

eOppslag som arkitekturmønster beskriver synkrone API-kall mot en datatilbyder med tilgangsstyring ved bruk av sikkerhetsbilletter.

Her beskrives realiseringen av kapabilitetene i det generiske mønsteret for deling av data på forespørsel innenfor rammene av synkrone oppslag mot APIer og tilgangsstyring ved bruk av sikkerhetsbilletter.

Beskrivelsene er forsøkt å holdes generisk uten å peke til noen løsning og det vil dermed kunne være flere måter å realisere de ulike elementene på.

Klargjøring for deling av data på forespørsel
Tilgjengeliggjøre data

Tilgjengeliggjøring av API gjøres av tilbyder av data og er det tilbyder må gjennomføre for å gjøre et API synlig og tilgjengelig gjennom kataloger og søkeløsninger. Registrering av konsumenters rettigheter og tilganger inngår også som et prosessteg.

Dersom det er registrering av et åpent API, er det kun relevante prossessteg som utføres.

Bilde mangler

Tabell 2. Elementer i view for Tilgjengeliggjøre data
Element Beskrivelse

Datatilbyder

Tilbyder av data til andre aktører.

Tilgjengeliggjøre data

Evnen til å gjøre data tilgjengelig for aktører utenfor egen virksomhet.

Bruksavtale

Avtale om tilgang til og bruk av data. Dette kan for eksempel være en bilateralt utformet avtale, aksept av generelle bruksvilkår eller lisens for bruk av åpne data.

Tilgjengeliggjøre API

Prosessen med å tilby data gjennom et API til aktører utenfor egen virksomhet.

Registrere API

Prosess med å registere API i relevante tjenester, api-katalog, Maskinporten, Kapabilitetsoversikt

Inngå avtale om tilgang til data

Prosess for å inngå avtale om tilgang og bruk av data.

Tildele tilganger til API

Prosess for å registrere hvilke databrukere som skal få tilgang Sette policy, og grov tilgangsstyring gjennom maskinporten.

Registrere brukere av samtykke

Prosess for å registrere konsumenter som skal ha mulighet for å innhente samtykker som gir tilgang til en tjeneste.

Dette utføres kun om det er behov for samtykke for tilgang til dataene.

API-registreringstjeneste

Tjeneste for å registerer de API-ene man ønsker å tilby til konsumenter og egenskaper ved disse.

Registrering av API-brukere

Tjeneste for gjennom selvbetjening å registrere og vedlikeholde tilgangene konsumenter skal ha til API-er og scopes.

Registrere samtykkebasert tilgang

Tjeneste for å registerer konsumenter som kan innhente samtykke som gir grunnlag for utlevering fra datatilbyder.

Få tilgang til data

Få tilgang til API er det en konsument av data må gjøre for å få tilgang til data gjennom et API. Det omfatter å få kjennskap til aktuelt API, inngå avtale om bruk av data, samt å registrere 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.

Bilde mangler

Tabell 3. Elementer i view for Få tilgang til data
Element Beskrivelse

Datakonsument

Den som innhenter eller mottar data fra andre aktører.

Få tilgang til data (konsument)

Evnen til å skaffe seg tilgang til tilbudte data fra annen aktør.

Bruksavtale

Avtale om tilgang til og bruk av data. Dette kan for eksempel være en bilateralt utformet avtale, aksept av generelle bruksvilkår eller lisens for bruk av åpne data.

Få tilgang til API

Prosessen med å skaffe seg tilgang til tilbudte data fra annen aktør. Omfatte å finne API-er, inngå nødvendige avtaler og få tilganger.

Finn/få kjennskap til API

Prosessen med å finne eller få kjennskap til tilgjengelige API-er gjennom relevante kataloger og søkeløsninger.

Inngå avtale om tilgang til data

Prosess for å inngå avtale om tilgang og bruk av data.

Registreringstjeneste for API-brukere

Tjeneste for å registrere klienter som skal ha tilgang til et gitt API.

API-søk

Tjeneste for å søke etter og finne tilgjengelige API-er

Registrer klient med tildelt tilgang

Prosess for konsument å registerere (provisjonering av) den klienten som skal ha tilgang til API-et ved bruk av sikkerhetsbillett. Dette forutsetter at konsumenten har avtale om bruk av sikkerhetsbillettjenesten og at tilbyder har gitt konsumenten tilgang.

Dersom det er en leverandør som har blitt delegert rettigheter som databehandler på vegne av konsument er det leverandøren som registrer sin klient.

Delegere rettigheter til databehandler

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.

Bilde mangler

Tabell 4. Elementer i view for Delegere rettigheter til databehandler
Element Beskrivelse

Samhandlingsaktør

Samlebetegnelse på roller som inngår i en samhandlingsprosess og samhandler med en annen samhandlingsaktør. Kan være en tilbyder, konsument, avsender, mottaker, leverandør etc.

Delegere rettigheter til databehandler

Evnen til å delegere rettigheter til databehandler som utfører oppgaver på vegne av behandlingsansvarlig.

Tjenesteavtale

Avtale mellom leverandør og konsument som er grunnlaget for å kunne delegere rettigheter fra konsument til en leverandør

Delegering av rettigheter til databehandler (leverandør)

Prosessen med å delegere rettigheter til databehandler/leverandør.

Inngå avtale med leverandør

Prosessen med å inngå en avtale med leverandør. En slik avtale vil normalt være inngått tidligere og uavhengig av om man skal ta i bruk et nytt API. En tjenesteavtale med leverandør er en forutsetning for å kunne delegere en tilgang.

Registrere delegert tilgang

Prosessen med å delegere tilganger. I tilknytning til eOppslag vil formålet være å gi leverandør tilgang til å representere konsument overfor et API, men registreringen vil potensielt også kunne gjelde for andre områder.

Registering av representasjonsforhold

Tjeneste for å registrere et representasjonsforhold som gir leverandør mulighet til å opptre på vegne av konsument

Utveksling av data
Innhente data

Slå opp data gjennom et API er det en konsument må gjøre når det utføres et tjenestekall for å innhente data gjennom et API. Dersom det er et åpent API er det kun relevante prossessteg som utføres.

Bilde mangler

Tabell 5. Elementer i view for Innhente data
Element Beskrivelse

Datakonsument

Den som innhenter eller mottar data fra andre aktører.

Innhente data

Evnen til å innhente data fra en annen aktør.

Forespørsel om data

Forespørsel om data med parametetere i forespørselen, sikkerhetsbillett mv.

Slå opp data gjennom et API

Prosessen med å slå opp og hente data gjennom et API.

Innhent samtykke ved behov

Prosess for å innhente samtykke fra person eller virksomhet som grunnlag for å innhente data. Dette gjøres kun ved behov.

Hent teknisk endepunkt ved behov

Prosessen å slå opp den tekniske adressen til et API før spørring mot API-et. Gjøres kun dersom det er nødvendig.

Be om tilgangstoken

Prosessen med å benytte en sikkerhetsbillettjeneste for hente en sikkerhetsbillett som gir tilgang til et API. Dette forutsetter at alt er registert og satt opp riktig mot de aktuelle tjenestene.

Utfør tjenestekall

Prosessen med å benytte (gjøre et oppslag mot) et eksternt API.

Samtykkeregistererings-tjeneste

Tjeneste for å innhente samtykke fra den registrert som dataene gjelder. Dette kan være en person eller en virksomhet.

Adressetjeneste

Tjeneste som gir mulighet til å slå opp teknisk endepunkt

Tokentjeneste

Tjeneste som utsteder sikkerhetsbilletter. Sikkerhetsbillett utstedes basert på tildelte rettigheter og eventuelle representasjonsforhold.

Datautvekslings-tjeneste

Tjeneste for utveksling av data. Samme som data exchange service. Benyttes av avsender og mottaker for transport av meldinger.

Avgi data

Avgi forespurte data er det tilbyder av data må gjøre for å svare på en forespørsel. Prosessen kontrollere tilgang gjøres kun dersom det er enakk om å avgi data gjennom et sikret API.

Bilde mangler

Tabell 6. Elementer i view for Avgi data
Element Beskrivelse

Datatilbyder

Tilbyder av data til andre aktører.

Avgi data

Evne til å avgi data på forespørsel. Kan omfatte tilgangsstyring.

Forespørsel

Informasjon om det som forespørres.

Autentiseringsdata

Data som autentiserer konsument, f.eks. digitalt sertifikat eller sikkerhetsbillett.

Autorisasjonsdata

Data som autoriserer konsument, f.eks. påstander i en sikkerhetsbillett.

Svar på forespørsel

Informasjonen som avgis til konsument som svar på en forespørsel.

Avgi forespurte data gjennom API

Prosessen med å avgi data på forespørsel gjennom et egnet API.

Motta forespørsel om oppslag

Motta forespørsler fra API-konsument om å avgi data.

Autentisere konsument

Prosessen med å autentisere en kosnument.

Kontroller tilgang

Kontroll og håndheving av konsumentens rettigheter til å få forespurte data. I tillegg til "validering av sikkerhetsbillet", kan det være behov for kontroll mot virksomhetsinterne policies.

Avgi data

Prosessen med å gi svar på forespørselen.

Datautvekslings-tjeneste

Tjeneste for utveksling av data. Samme som data exchange service. Benyttes av avsender og mottaker for transport av meldinger.

Autentiseringstjeneste

Tjeneste som benyttes av tilbyder for å validere og kontrollere autentisiteten til et OAUTH2 token fra Maskinporten

Tilgangskontroll-tjeneste

Tjeneste for å sjekke rettigheter til data. Kan være eksterne eller interne tjenester. Eksempler på rettigheter kan komme av samtykker fra person eller virksomhet, eller rollebasert fra vergemål, familierelasjon el.

Datautvekslings-tjeneste

Tjeneste for utveksling av data. Samme som data exchange service. Benyttes av avsender og mottaker for transport av meldinger.

2.2.2. eOppslag - løsningsmønster med bruk av nasjonale fellesløsninger

Beskrivelsen under viser hvordan den generelle arkitekturen for eOppslag kan realiseres med løsningskomponentene Maskinporten, API-katalogen og Altinn-autorisasjon. Disse fellesløsningene leverer de tjenestene som er beskrevet på forretningsnivå over.

eOppslag kan benyttes både for sikrede API-er og API-er som tilbyr åpent tilgjengelige data uten tilgangsbegrensninger.

Det er ikke hensikten å låse referansearkitekturen til spesifikke løsninger, da ulike sektorer og aktører kan ha behov som ikke passer med det som er beskrevet. For synkrone tjenestekall basert på REST og med tilgangsstyring ved hjelp av OAUTH2-tokens, vil det være god støtte i å benytte de foreslåtte løsningene.

Nederst i beskrivelsen av løsningsmønstre er det en overordnet beskrivelse av hvilke data som inngår i registrering i de ulike komponentene.

Klargjøring for deling av data på forespørsel
Tilgjengeliggjøre data

For å tilby data gjennom et API sikret med fellestjenester må tilbyder inngå avtale for bruk av Maskinporten og Felles API-katalog. De respektive API-ene og hvem som skal ha hvilke rettighetene til disse må så registreres i løsningene.

Bilde mangler

Tabell 7. Elementer i view for Tilgjengeliggjøre data løsningsmønster
Element Beskrivelse

Datatilbyder

Tilbyder av data til andre aktører.

Tilgjengeliggjøre data

Evnen til å gjøre data tilgjengelig for aktører utenfor egen virksomhet.

Tilgjengeliggjøre API

Prosessen med å tilby data gjennom et API til aktører utenfor egen virksomhet.

Registrere API

Prosess med å registere API i relevante tjenester, api-katalog, Maskinporten, Kapabilitetsoversikt

Inngå avtale om tilgang til data

Prosess for å inngå avtale om tilgang og bruk av data.

Tildele tilganger til API

Prosess for å registrere hvilke databrukere som skal få tilgang Sette policy, og grov tilgangsstyring gjennom maskinporten.

Registrere brukere av samtykke

Prosess for å registrere konsumenter som skal ha mulighet for å innhente samtykker som gir tilgang til en tjeneste.

Dette utføres kun om det er behov for samtykke for tilgang til dataene.

Registrere Open API specification¨

Tjeneste i Felles API-katalogen for å registrere API. Bruk av tjenesten forutsetter at rettigheter til å gjøre dette på vegne av tilbyders virksomhet.

Selvbetjeningstjeneste for administrasjon av integrasjoner og APIer

Tjeneste "administrasjonssentre" vil ha rettigheter til å registrere på vegne av andre f.eks. API-katalogen

Registrering av API-brukere

Tjeneste for gjennom selvbetjening å registrere og vedlikeholde tilgangene konsumenter skal ha til API-er og scopes.

Registrere samtykkebasert tilgang

Tjeneste for å registerer konsumenter som kan innhente samtykke som gir grunnlag for utlevering fra datatilbyder.

Beskrivelse API

Dataobjekt som er en maskinlesbar beskrivelse av REST API-er iht. Open API Specification. Dette er formatet som benyttes for å registrere et API i felles API-katalog

Token-egenskaper

Egenskaper som f.eks. gyldighetstid ved tilgangstoken som er Maskinportens variant av sikkerhetsbillett.

OAUTH scopes

Dataobjekt som som kan beskrives som en ressurs-definisjon, og et token er som regel knyttet til ett eller flere scopes. Scopes benyttes til å styre tilganger til API-er og operasjoner, samt eventuelt hva slags responser man får fra API-er.

Tilganger konsument

Oversikt over hvilke API og OAUTH-scopes en virksomhet (representert ved organisasjonsnummer) skal ha tilgang til (utstedt token for).

Aktører som kan innhente samtykke for bruk av API

Oversikt over aktører som skal ha mulighet til å innhente samtykke som grunnlag for å få tilgang til data gjennom et API. URL til konsumenten det kan innhentes samtykke for må inngå i beskrivelsen.

Felles API-katalog

Del av Felles datakatalog som gir mulighet for å søke etter API-er og lese API-spesifikasjoner https://fellesdatakatalog.brreg.no/apis

Maskinporten

Maskinporten er en løsning for tilgangsstyring for virksomheter som utveksler data. Løsningen garanterer identiteten mellom virksomheter, og sørger for maskin-til-maskin autentisering

Altinn autorisasjon

Autorisasjonskomponenten i Altinn som gir muligheter til å delegere rettigheter til andre organisasjoner eller personer. Rettigheter til bruk av autorisasjonskomponenten baserer seg på registrerte roller i Enhetsregisteret. Altinn autorisasjon leverer også tjenester for å registrere og kontrollere samtykke gitt av person eller virksomhet.

Få tilgang til data

For å få tilgang til data gjennom et API sikret ved hjelp av nasjonale fellesløsninger, må konsumenten inngå avtale for bruk av Maskinporten og registrere den tekniske klienten som skal benytte løsningen.

Bilde mangler

Tabell 8. Elementer i view for Få tilgang til data - løsningsmønster
Element Beskrivelse

Datakonsument

Den som innhenter eller mottar data fra andre aktører.

Få tilgang til data (konsument)

Evnen til å skaffe seg tilgang til tilbudte data fra annen aktør.

Få tilgang til API

Prosessen med å skaffe seg tilgang til tilbudte data fra annen aktør. Omfatte å finne API-er, inngå nødvendige avtaler og få tilganger.

Finn/få kjennskap til API

Prosessen med å finne eller få kjennskap til tilgjengelige API-er gjennom relevante kataloger og søkeløsninger.

Inngå avtale om tilgang til data

Prosess for å inngå avtale om tilgang og bruk av data.

Registrer klient med tildelt tilgang

Prosess for konsument å registerere (provisjonering av) den klienten som skal ha tilgang til API-et ved bruk av sikkerhetsbillett. Dette forutsetter at konsumenten har avtale om bruk av sikkerhetsbillettjenesten og at tilbyder har gitt konsumenten tilgang.

Dersom det er en leverandør som har blitt delegert rettigheter som databehandler på vegne av konsument er det leverandøren som registrer sin klient.

API-søk

Tjeneste for å søke etter og finne tilgjengelige API-er

Registreringstjeneste for API-brukere

Tjeneste for å registrere klienter som skal ha tilgang til et gitt API.

Beskrivelse API

Dataobjekt som er en maskinlesbar beskrivelse av REST API-er iht. Open API Specification. Dette er formatet som benyttes for å registrere et API i felles API-katalog

Felles API-katalog

Del av Felles datakatalog som gir mulighet for å søke etter API-er og lese API-spesifikasjoner https://fellesdatakatalog.brreg.no/apis

Maskinporten

Maskinporten er en løsning for tilgangsstyring for virksomheter som utveksler data. Løsningen garanterer identiteten mellom virksomheter, og sørger for maskin-til-maskin autentisering

Delegering av rettigheter til databehandler

Dersom konsumenten benytter en leverandør som skal opptre på konsumentens vegne, må dette forholdet registereres gjennom Altinn autorisasjon slik at det blir tilgjengelig for Maskinporten å kontrollere representasjonsforholdet.

Bilde mangler

Tabell 9. Elementer i view for Delegere rettigheter til databehandler - løsningsmønster
Element Beskrivelse

Samhandlingsaktør

Samlebetegnelse på roller som inngår i en samhandlingsprosess og samhandler med en annen samhandlingsaktør. Kan være en tilbyder, konsument, avsender, mottaker, leverandør etc.

Delegere rettigheter til databehandler

Evnen til å delegere rettigheter til databehandler som utfører oppgaver på vegne av behandlingsansvarlig.

Delegering av rettigheter til databehandler (leverandør)

Prosessen med å delegere rettigheter til databehandler/leverandør.

Inngå avtale med leverandør

Prosessen med å inngå en avtale med leverandør. En slik avtale vil normalt være inngått tidligere og uavhengig av om man skal ta i bruk et nytt API. En tjenesteavtale med leverandør er en forutsetning forutsetning for å kunne delegere en tilgang.

Registrere delegert tilgang

Prosessen med å delegere tilganger. I tilknytning til eOppslag vil formålet være å gi leverandør tilgang til å representere konsument overfor et API, men registreringen vil potensielt også kunne gjelde for andre områder.

Delegerbar ressurs

Dataobjekt som beskriver en ressurs, f.eks. et API, som det kan gis rettigheter til gjennom et representasjonsforhold.

Registering av representasjonsforhold

Tjeneste for å registrere et representasjonsforhold som gir leverandør mulighet til å opptre på vegne av konsument

Altinn autorisasjon

Autorisasjonskomponenten i Altinn som gir muligheter til å delegere rettigheter til andre organisasjoner eller personer. Rettigheter til bruk av autorisasjonskomponenten baserer seg på registrerte roller i Enhetsregisteret. Altinn autorisasjon leverer også tjenester for å registrere og kontrollere samtykke gitt av person eller virksomhet.

Informasjon som inngår i klargjøring av forespørsel

Figuren under viser hvilken informasjons som må registreres i de ulike komponentene som del av klargjøringen for å forespørre data fra et API.

Bilde mangler

Tabell 10. Elementer i view for Dataobjekter eOppslag
Element Beskrivelse

API-katalogen

API-katalogen er en del av Felles datakatalog som inneholder API-beskrivelser med endepunktsadresser og kobling til datasett.

Beskrivelse API

Dataobjekt som er en maskinlesbar beskrivelse av REST API-er iht. Open API Specification. Dette er formatet som benyttes for å registrere et API i felles API-katalog

Endepunkt (adresse)

Dataobjekt som representerer teknisk adresse til et API eller ressurs.

Altinn autorisasjon

Autorisasjonskomponenten i Altinn som gir muligheter til å delegere rettigheter til andre organisasjoner eller personer. Rettigheter til bruk av autorisasjonskomponenten baserer seg på registrerte roller i Enhetsregisteret. Altinn autorisasjon leverer også tjenester for å registrere og kontrollere samtykke gitt av person eller virksomhet.

Delegerbar ressurs

Dataobjekt som beskriver en ressurs, f.eks. et API, som det kan gis rettigheter til gjennom et representasjonsforhold.

Beskrivelse av aktør som kan innhente samtykke

Dataobjekt som beskriver en datakonsument som har rett til å innhente samtykke om å slå opp data. Viktig innholde er bl.a. URL

Tilganger konsument/representasjonsforhold

Dataobjekt som beskriver hvilke tilganger til ressurser en representant (leverandør) skal ha på vegne av konsument.

Maskinporten

Maskinporten er en løsning for tilgangsstyring for virksomheter som utveksler data. Løsningen garanterer identiteten mellom virksomheter, og sørger for maskin-til-maskin autentisering

OAUTH scopes

Dataobjekt som som kan beskrives som en ressurs-definisjon, og et token er som regel knyttet til ett eller flere scopes. Scopes benyttes til å styre tilganger til API-er og operasjoner, samt eventuelt hva slags responser man får fra API-er.

Utveksling av data
Innhente data

Når en konsumet skal slå opp data gjennom et API benyttes Maskinporten for å få utstedt en sikkerhetsbillett som legges ved tjenestekallet til tilbyders API. Maskinporten utsteder sikkerhetsbilletter som OAUTH2-tokens.

Bilde mangler

Tabell 11. Elementer i view for Innhente data - løsningsmønster
Element Beskrivelse

Datakonsument

Den som innhenter eller mottar data fra andre aktører.

Innhente data

Evnen til å innhente data fra en annen aktør.

Slå opp data gjennom et API

Prosessen med lå opp og hente data gjennom et API.

Innhent samtykke ved behov

Prosess for å innhente samtykke fra person eller virksomhet som grunnlag for å innhente data. Dette gjøres kun ved behov.

Hent teknisk endepunkt ved behov

Prosessen å slå opp den tekniske adressen til et API før spørring mot API-et. Gjøres kun dersom det er nødvendig.

Be om tilgangstoken

Prosessen med å benytte en sikkerhetsbillettjeneste for hente en sikkerhetsbillett som gir tilgang til et API. Dette forutsetter at alt er registert og satt opp riktig mot de aktuelle tjenestene.

Utfør tjenestekall

Prosessen med å benytte (gjøre et oppslag mot) et eksternt API.

Samtykkeregistererings-tjeneste

Tjeneste for å innhente samtykke fra den registrert som dataene gjelder. Dette kan være en person eller en virksomhet.

Adressetjeneste

Tjeneste som gir mulighet til å slå opp teknisk endepunkt

Tokentjeneste

Tjeneste som utsteder sikkerhetsbilletter. Sikkerhetsbillett utstedes basert på tildelte rettigheter og eventuelle representasjonsforhold.

Oppslag representasjonsforhold

Tjeneste som benyttes av tokentjenesten for å kontrollere om det foreligger et delegert representasjonsforhold fra konsument til leverendør i autorisasjonstjenesten til Altinn.

Datautvekslingstjeneste

Tjeneste for utveksling av data. Samme som data exchange service. Benyttes av avsender og mottaker for transport av meldinger.

Endepunkt (adresse)

Teknisk adresse til et API eller ressurs

Virksomhetssertifikat

En virksomhets elektroniske ID. Benyttes for å autentisere virksomheten overfor tokentjenesten.

Tilganger konsument

Oversikt over hvilke API og OAUTH-scopes en virksomhet (representert ved organisasjonsnummer) skal ha tilgang til (utstedt token for).

Altinn autorisasjon

Autorisasjonskomponenten i Altinn som gir muligheter til å delegere rettigheter til andre organisasjoner eller personer. Rettigheter til bruk av autorisasjonskomponenten baserer seg på registrerte roller i Enhetsregisteret. Altinn autorisasjon leverer også tjenester for å registrere og kontrollere samtykke gitt av person eller virksomhet.

Felles API-katalog

Del av Felles datakatalog som gir mulighet for å søke etter API-er og lese API-spesifikasjoner https://fellesdatakatalog.brreg.no/apis

Maskinporten

Fellesløsning for API-sikring ved bruk av OAUTH2-tokens.

Altinn autorisasjon

Autorisasjonskomponenten i Altinn som gir muligheter til å delegere rettigheter til andre organisasjoner eller personer. Rettigheter til bruk av autorisasjonskomponenten baserer seg på registrerte roller i Enhetsregisteret. Altinn autorisasjon leverer også tjenester for å registrere og kontrollere samtykke gitt av person eller virksomhet.

Avgi data

Når tilbyder får en forspørsel om data som et API-kall og det ligger ved en sikkerhetsbillett benyttes valideringstjenesten til maskinporten for grov tilgangskontroll.

Bilde mangler

Tabell 12. Elementer i view for Avgi data - løsningsmønster
Element Beskrivelse

Datatilbyder

Tilbyder av data til andre aktører.

Avgi data

Evne til å avgi data på forespørsel. Kan omfatte tilgangsstyring.

Avgi forespurte data gjennom API

Prosessen med å avgi data på forespørsel gjennom et egnet API.

Motta forespørsel om oppslag

Motta forespørsler fra API-konsument om å avgi data.

Autentisere konsument

Prosessen med å autentisere en kosnument.

Kontroller tilgang

Kontroll og håndheving av konsumentens rettigheter til å få forespurte data. I tillegg til "validering av sikkerhetsbillet", kan det være behov for kontroll mot virksomhetsinterne policies.

Avgi data

Prosessen med å gi svar på forespørselen.

Datautvekslingstjeneste

Tjeneste for utveksling av data. Samme som data exchange service. Benyttes av avsender og mottaker for transport av meldinger.

Tokenvalideringstjeneste

Tjeneste som benyttes av tilbyder for å validere og kontrollere autentisiteten til et OAUTH2 token fra Maskinporten

Tilgangskontrolltjeneste

Tjeneste for å sjekke rettigheter til data. Kan være eksterne eller interne tjenester. Eksempler på rettigheter kan komme av samtykker fra person eller virksomhet, eller rollebasert fra vergemål, familierelasjon el.

Datautvekslingstjeneste

Tjeneste for utveksling av data. Samme som data exchange service. Benyttes av avsender og mottaker for transport av meldinger.

Maskinporten

Maskinporten er en løsning for tilgangsstyring for virksomheter som utveksler data. Løsningen garanterer identiteten mellom virksomheter, og sørger for maskin-til-maskin autentisering

Altinn autorisasjon

Autorisasjonskomponenten i Altinn som gir muligheter til å delegere rettigheter til andre organisasjoner eller personer. Rettigheter til bruk av autorisasjonskomponenten baserer seg på registrerte roller i Enhetsregisteret. Altinn autorisasjon leverer også tjenester for å registrere og kontrollere samtykke gitt av person eller virksomhet.

Egen autorisasjonskomponent

Komponent for å håndheve virksomhetens regler for tilgang. Også kalt policy enforcement point (PEP).

3. Mønstre for meldingsforsendelse

3.1. Generisk mønster for meldingsforsendelse

Det mest grunnleggende mønsteret for meldingsutveksling omhandler enkeltvise meldinger fra en avsender til en kjent mottaker

3.1.1. Introduksjon

Generisk mønster for meldingsforsendelse til kjent mottaker beskriver meldingsutveksling i form av enkeltvise meldinger fra en avsender til en kjent mottaker. De konseptuelle beskrivelsene som gis her danner grunnlag for beskrivelser av mer avanserte og spesialiserte mønstre; men kan også stå på egne ben, med egne løsningsmønstre.

Beskrivelsene skiller mellom

  1. Det konseptuelle arkitekturmønsteret

  2. Praktisk anvendelser i form av løsningsmønstre med mer konkret veiledning, f.eks. til bruk av nasjonale fellesløsninger.

3.1.2. Brukstilfeller

Aktuelle brukstilfeller for Generisk mønster for meldingsforsendelse til kjent mottaker:

  • melding om hendelser og data mellom to kjente parter i tverrgående forretningsprosesser, f.eks. saksbehandlingsprosesser.

  • melding om hendelser og data til datalagringsløsninger

3.1.3. Grunnleggende konsepter og forutsetninger

Logisk og fysisk dataflyt

Følgende arkitekturtegning illustrerer helt grunnleggende konsepter.

Generisk meldingsforsendelse image
Figur 4. Generisk meldingsforsendelse

Her skilles det mellom forretningsmessig informasjonsflyt mellom partene og den fysiske dataflyten mellom IT-løsningene på hver side.

Det forutsettes altså at det finnes en kommunikasjonsinfrastruktur som det kan sendes meldinger over. I sin enkleste form er dette internett. Det kan også finnes krav til bestemte formater og protokoller i en mer spesialisert meldingsinfrastruktur.

Et eksempel på dette er beskrevet i referansearkitekturen for eMelding (og anvendelser som i PEPPOL-infrastrukturen), der det stilles krav til støtte for en standardisert meldingsprotokoll på tvers av alle samhandlingsaktører innenfor et avtalefelleskap (i PEPPOL er det AS4).

Selv om avsender kjenner mottaker på forhånd, kan det være aktuelt å slå opp detaljer om mottakers kommunikasjonsløsning i tilknytning til selve forsendelsen. Dette gjøres typisk gjennom run-time oppslagstjenester; her vist som en (konseptuell) tjeneste for Kapabilitets-og adresseoppslag.

Avtaleforvaltning

Det forutsettes at det finnes avtaler mellom avsender og mottaker som ivaretar hensyn til interoperabilitet og informasjonssikkerhet.

Følgende figur illustrerer det generelle konseptet.

Generisk meldingsforsendelse inkl. avtaleforvaltning image
Figur 5. Generisk meldingsforsendelse inkl. avtaleforvaltning

Begrepene Avtaleforvalter og Samhandlingsavtale kan her forstås på ulike måter, avhengig av sammehengen (slik dette også framkommer av mer spesialiserte arkitekturmønstre).

Følgende figur illustrerer dette.

Former for avtaleforvaltning image
Figur 6. Former for avtaleforvaltning

Avtaler kan altså gjøres på flere måter:

  1. Bilateral avtale, der avtalen registreres direkte hos hver av partene.

  2. Bilateral avtale, der avtalen registreres hos tiltrodd tredjepart (avtaleforvalter).

  3. Avtalefellesskap, der avtalen registreres hos tiltrodd tredjepart (avtaleforvalter/fellesskapsforvalter) og der andre aktører eventuelt kan registrere tilsvarende kapabiliteter for sending og mottak.

De konseptuelle beskrivelsene tar høyde for at det kan finnes et avtalefellesskap, men dette er ikke en forutsetning for dette, generiske, arkitekturmønsteret.
Samhandlingsspesifikasjoner

Samhandlingsspesifikasjoner ligger til grunn for samhandlingsavtaler (se foregående avsnitt). For _Generisk mønster for meldingsforsendelse til kjent mottaker omfatter dette:

  • Tekniske spesifikasjoner: Muliggjør datautveksling mellom systemer. Omfatter transportprotokoller, meldingsformater, teknisk feilhåndtering, eventuell orkestreringsløsninger, m.m..

  • Semantisk spesifikasjoner: Muliggjør utveksling av meningsfull informasjon. Omfatter metadata og datamodeller for aktuelle meldingsformater.

  • Organisatorisk: Muliggjør forretningsprosesser på tvers av organsiasjonsenheter og systemer. Omfatter spesifikasjon av meldingsflyt på tvers av delproseser eller prosessteg (koreografi).

I dette (generiske) arkitekturmønsteret, gjøres et minimum av konkrete spesifikasjoner.

Følgende presiseres spesielt:

Dersom det skal utveksles meldinger i noen form for sammenhengende prosess, kreves en løsning for korrelering av meldinger. Det forutsettes her at det avtales en meldingsprotokoll på applikasjonslaget for dette med en parameter kalt "ConversationId" eller tilsvarende.

3.1.4. Kapabilitetskart - relevante kapabiliteter

Modellen under viser hovedinndelingen i kapabiliteter for meldingsforsendelse mellom en avsender og en mottaker.

Kapabiliteter - meldingsforsendelse image
Figur 7. Kapabiliteter - meldingsforsendelse
Tabell 13. Elementer i view, Kapabiliteter for generisk meldingsforsendelse
Element Beskrivelse

Avsender

Den som sender en elektronisk melding eller tilsvarende.

Mottaker

Den som mottar en elektronisk melding eller tilsvarende.

Klargjøre for deling av data ved forsendelse

Evne til å klargjøre for meldingsutveksling med eksterne parter.

Sende data

Evnen til å sende data til en mottaker.

Motta data

Evnen til å motta en en forsendelse fra en avsender.

Realiseringen av disse kapabilitetene er beskrevet i det følgende; først konseptuelt, så med løsningsspefikke eksempler eller anbefalinger.

3.1.5. Konseptuelle beskrivelser (arkitekturbyggeklosser)

Klargjøring for meldingsforsendelse

Modellen under detaljerer hvordan en samhandlingsaktør, som i dette tilfellet normalt vil være en avsender eller mottaker, blir klar for å sende data som en melding. Dette gjøres ved å inngå nødvendige avtaler for meldngsforsendelse og registrere nødvendige data i registre som er tilgjengelig for de andre samhandlingsaktørene i fellesskapet. Det vil kunne være forskjeller på hva som er nødvendig å gjøre avhengig av om samhandlingsaktøren er en avsender eller mottaker, men normalt vil man inneha begge roller i fellesskapet.

Klargjør for eMelding (arkitekturmønster) image
Figur 8. Klargjør for melding (arkitekturmønster)

Forklaring til figur:

Tabell 14. Elementer i view for Klargjør for melding (arkitekturmønster)
Element Beskrivelse

Samhandlingsaktør

Samlebetegnelse på roller som inngår i en samhandlingsprosess og samhandler med en annen samhandlingsaktør. Kan være en tilbyder, konsument, avsender, mottaker, leverandør etc.

Klargjøre for deling av data ved forsendelse

Evne til å klargjøre for meldingsutveksling med eksterne parter.

Interoperability specification

Spesifikasjoner for hvordan man samhandler i et fellesskap. Dette kan være meldingsformater, krav til tekniske komponenter etc.

Samhandlingsavtale

Avtale som regulerer forhold tilknyttet samhandlingen mellom to parter, eller deltakerne ie et fellesskap for meldingsutveksling.

Kapabilitetsbeskrivelse

Strukturert beskrivelse av evner og kapabiliteter relevante for samhandling i fellesskapet

Mottakeradresse

Teknisk adresse for hvor meldinger skal sendes. Dette kan være adressen til mottaker direkte eller mottakers integrasjonspunkt.

Mottakersertifikat

Offentlig nøkkel benyttes for kryptering og validering av signatur.

Privat nøkkel benyttes til dekryptering og signering av meldinger.

Avsendersertifikat

Offentlig nøkkel benyttes for kryptering og validering av signatur.

Privat nøkkel benyttes til dekryptering og signering av meldinger.

Klargjør for melding

Prosessen med å klargjøre for melding ved å inngå nødvendige avtaler og tilgjengeliggjøre nødvendig informasjon til andre samhandlingsaktører.

Inngå avtaler for meldingsforsendelse

Prosessen med å inngå bilaterale avtaler med sammhandlingsparter eller innmelding i et fellesskap. F.eks. gjennom å akseptere spesifikke avtaler, vilkår eller kontrakter og innrette seg etter reglene og forpliktelsene som gjelder i et fellesskap (community), eller det som er avtalt mellom samhanslingsaktørene.

Registrer kapabiliteter

Registering av kapabiliteter vil si å tilgjengeligjøre for avsendere og konsumenter hvilke meldinger og formater man kan motta og hvilke ressurser og tjenester man tilbyr.

Registrer adresser

Med adresse menes nødvendig informasjon for å få tilgang til tjenester fra tilbyder eller for å sende melding til mottaker av meldinger.

Registrer sertifikater

Tilgjengeliggjøre for samhandlende parter sertifikater for bruk ved forsendelser. Dette kan være generelle eller domenespesifikke sertifikater. Eventuelt spesifikt for enkelet forretningsområder.

Sertifikater må forvaltes og fornyes etter gjeldende regler for å være gyldige og egnet for bruk.

Kapabilitetsregistrering

Tjeneste for å registrere kapabiliteter

Adresseregistrering

Tjeneste for å registrere adresse for å sende melding til mottaker.

Sertifikatregisterering

Tjeneste for å registrere serifikater i felles katalogtjeneste.

Operativ meldingsforsendelse
Send melding

Her beskrives en referansemodell for operativ meldingsforsendelse. Merk: Enkelte prosess-steg kan være uaktuelle, avhengig av dataene som utveksles og spesifikasjonene for samhandling innen et eventuelt avtalefellesskap.

Send melding (arkitekturmønster) image
Figur 9. Send melding (arkitekturmønster)

Forklaring til figur:

Tabell 15. Elementer i view for Send melding (arkitekturmønster)
Element Beskrivelse

Avsender

Den som sender et brev, en pakke, en e-post, en elektronisk melding, en SMS eller lignende.

Sende data

Evnen til å sende data til en mottaker.

Meldingsinnhold

Meldingsinnholdet eller informasjonen som skal sendes til ekstern part.

Mottakersertifikat

Offentlig nøkkel benyttes for kryptering og validering av signatur.

Privat nøkkel benyttes til dekryptering og signering av meldinger.

Mottakeradresse

Teknsik adresse til hvor meldinger skal sendes.

Avsendersertifikat

Offentlig nøkkel benyttes for kryptering og validering av signatur.

Privat nøkkel benyttes til dekryptering og signering av meldinger.

Forsendelse

Den pakken som sendes til mottaker. Inkluderer forretningsmelding, metadata, adresse etc.

Send melding

Prosessen med å sende en eMelding til en mottaker ved hjelp av fellestjenester.

Kontroller mottakers kapabiliteter

Prosess for å slå opp og kontrollere mottakers evner til samhandling innenfor fellesskapet.

Formater melding

Prosess for å tilpasse informasjonspakken til mottakers kapabiliteter og fellesskapets standarder.

Krypter melding

Prosess med å sikre forsendelsen. Inkluderer konfidensialitets- og integritetssikring der dette er nødvendig. Normalt gjøres dette ved hjelp av kryptografi og sertifikater.

Adresser forsendelse

Prosess med å adressere forsendelsen. Dette kan være til mottaker direkte eller til dennes representant eller aksesspunkt.

Signer forsendelse

Prosessen med å signere meldingen som sendes til mottaker. Til dette benyttes eget sertifikats private nøkkel.

Ekspeder melding

Prosessen med å sende melding til mottaker.

Kapabilitetsoppslag

Tjeneste for å slå opp kapabilitetene til en samhandlingspart

Datatransformasjon

Tjeneste for transformere data og meldinger til andre formater.

Sertifikatoppslag

Tjeneste for å hente krypteringssertifkat til mottaker.

Adresseoppslag

Tjeneste for å slå opp adressen til en mottaker.

Signeringstjeneste

Tjeneste for å signere en elektronisk melding. For eMelding er det signatur i form av elektronisk segl som er mest relevant.

Datautvekslings-tjeneste

Tjeneste for utveksling av data. Samme som data exchange service. Benyttes av avsender og mottaker for transport av meldinger.

Sporingstjeneste

Tjeneste for sporing (audit) av meldinger.

Motta melding

Motta melding detaljerer prosessen med å motta en melding etter klargjøring for forsendelse. Alle stegene i prosessen vil ikke alltid være nødvendig avhengig av dataene som utveksles og spesifikasjonene for samhandling innen fellesskapet.

Motta melding (arkitekturmønster) image
Figur 10. Motta melding (arkitekturmønster)

Forklaring til figur:

Tabell 16. Elementer i view for Motta melding (arkitekturmønster)
Element Beskrivelse

Mottaker

Den som mottar en melding.

Motta melding

Evnen til å motta, validere og kvittere for mottatte meldinger.

Forsendelse

Den pakken som sendes til mottaker. Inkluderer forretningsmelding, metadata, adresse etc.

Avsendersertifikat

Offentlig nøkkel benyttes for kryptering og validering av signatur.

Privat nøkkel benyttes til dekryptering og signering av meldinger.

Mottakersertifikat

Offentlig nøkkel benyttes for kryptering og validering av signatur.

Privat nøkkel benyttes til dekryptering og signering av meldinger.

Motta melding

Prosessen med å motta melding. Består av flere delprosesser.

Etter mottak må mottaker følge opp og håndtere innholdet i meldingen.

Motta forsendelse

Prosessen med å motta en melding fra avsender

Kontroller forsendelse

Prosessen med å kontrollere om forsendelsen er autentisk og fra en legitim avsender.

Dekrypter melding

Prosessen med å dekryptere mottatt melding.

Valider forsendelse

Prosessen med å kontrollere om innholdet i en forsendelse er i henhold til avtale og avtalte formater.

Datautvekslings-tjeneste

Tjeneste for utveksling av data. Samme som data exchange service. Benyttes av avsender og mottaker for transport av meldinger.

Sporingstjeneste

Tjeneste for sporing (audit) av meldinger.

Signaturvaliderings-tjeneste

Tjeneste for å validere og verifisere elektronsike signaturer. I forbindelse med eMelding er det kontroll av elektronisk segl som er mest relevant.

Datavaliderings-tjeneste

Tjeneste for å validere meldinger mot format og forventet innhold.

3.2. eMelding - et arkitekturmønster etter modell fra CEF eDelivery

eMelding er en referansearkitektur for meldingsutveksling på tvers av virksomheter, sektorer og landegrenser.

3.2.1. Introduksjon

eMelding kan ses på som en "beste praksis" for meldingsutveksling på tvers av virksomheter og sektorer i offentlig sektor, samt mellom offentlig sektor og privat sektor.

Referansearkitekturen tar utgangspunkt i den europeiske "byggeklossen" CEF eDelivery. CEF eDelivery spesifiserer arkitekturer og standarder for meldingsutveksling. Det finnes flere eksisterende anvendelser og gjenbrukbare løsninger for å realisere eDelivery i ulike land og virksomheter.

eMelding anvendes bl.a. innen PEPPOL-nettverket, nærmere bestemt i regi av OpenPEPPOL.

OpenPEPPOL is a non-profit international association under Belgian law (Association Internationale Sans But Lucratif – AISBL) and consists of both public sector and private members. The association has assumed full responsibility for the development and maintenance of the PEPPOL specifications, building blocks and its services and implementation across Europe.

eMelding som referansearkitektur rendyrker konseptene og har en klar kopling til CEF eDelivery, men beskrives i utgangspunktet frikoplet fra CEF eDelivery. Med dette som utgangspunkt, angis så aktuelle løsninger og praktiske anvendelser i form av CEF eDelivery og PEPPOL/OpenPEPPOL.

eMelding som referansearkitektur er avgrenset til asynkron meldingsutveksling innenfor et fellesskap (community) som samhandler under et felles interoperabilitetsregime. Når man er del av fellesskapet vil man kunne sende meldinger til andre parter i fellesskapet uten å måtte inngå bilaterale avtaler om dette. Hver enkelt part registrerer sine samhandlingskapabiliteter i felles registre, for andre til å oppdage.

eMelding som referansearkitektur støtter mønstre for request-reply og korrelering av meldinger i prosessinstanser, tilsvarende slik dette legges opp til i spesifikasjonen av metadata i meldingsprofil for CEF eDelivery.

3.2.2. Grunnleggende konsepter for eMelding

Firehjørnersmodellen
Generelt

Begrepet "firehjørnersmodell", eller “4-corner model”, stammer fra CEF eDelivery.

Følgende figur illustrerer aktuelle konsepter:

Firehjørnersmodellen - forvaltningsmessig image
Figur 11. Firehjørnersmodellen - forvaltningsmessig
Denne modellen kan minne om en "tjenestebuss" (ESB), der det også finnes tilsvarende løs kopling mellom avsender og mottaker. Den grunnleggende forskjellen er at dette mønsteret er fullstendig distribuert og skalerer "uendelig" over www på global basis.

I firehjørnersmodellen kommuniserer avsenders og mottakers systemer via hver sine aksesspunktløsninger. Aksesspunktene konverterer mellom applikasjonsspesifikke protokoller og en standardisert, sikker meldingsprotokoll over aktuell kommunikasosjonsinfrastruktur.

Hvert aksesspunkt blir en node i et tillitsfelleskap.

Aksesspunktene kan eventuelt integreres i avsenders og mottakers systemer. Om dette gjøres på begge sider, vil en rent fysisk ha en punkt-til-punkt forbindelse, men uten at det endrer konseptet som sådan.

Nærmere om "hjørnene":

Hjørne 1 representerer back-end systemet (som ligger innenfor avsenders juridiske ansvar) som sender melding til et annet back-end system (hjørne 4).

Hjørne 2 (aksesspunkt for avsender) Samhandler med hjørne 1 og slår opp mottakers adresse og kapabiliteter. Aksesspunktet har evnen til å sende på en sikker og pålitelig måte til et annet aksesspunkt.

Hjørne 3 (aksesspunkt for mottaker) Mottakers aksesspunkt har teknisk evne til å motta meldinger på en sikker og pålitelig måte og samhandle med hjørne 4.

Hjørne 4 representerer back-end systemet til mottaker.

Egenskaper ved 4-hjørnersmodellen
  • Løs kopling mellom avsender og mottaker

  • Sikker meldingsinfrastruktur (mellom aksesspunktene)

  • Avtaleforvaltning gjennom betrodd tredjepart

  • Mulighet for å oppdage tjenestetilbydere og inngå avtaler runtime

  • Ubegrenset skalering

  • Mulig å opprette flere communities

Backend-integrasjon

I 4-hjørnersmodellen er det fleksibilitet gjennom hvordan man velger å integrere aksesspunktet med egen IT-arkitektur og IT-infrastruktur. Sett fra avsenderapplikasjonen er det tre måter å integrere hjørne 1/hjørne 2 og hjørne 3/hjørne 4.

Tett kobling

Avsender applikasjon og aksesspunkt er tett koblet ved at avsender applikasjonen har integrert funksjonaliteten til aksesspunktet. Det blir dermed et en-til-en forhold mellom aksesspunkt og avsender applikasjonen.

Semi-tett kobling

Avsender applikasjonen og aksesspunkt er semi-tett koblet ved at back-end og aksesspunkt er løst koblet internt, men del av det samme interne IT-arkitekturen og IT-infrastrukturen. Et aksesspunkt kan håndtere flere avsender applikasjoner.

Løs kobling

Avsender applikasjonen og aksesspunkt er løst koblet og ikke en del av samme interne IT-arkitektur og IT-infrastruktur. Ett aksesspunkt kan håndtere meldingsutveksling for mange avsender applikasjoner fra flere virksomheter.

Ved løs kobling er det spesielle hensyn ved ende til ende kryptering og integritet. Det er hjørne 1 som må pakke og kryptere informasjonen og kun hjørne 4 som kan dekryptere. Hjørne 2 og hjørne 3 har ikke lov til å pakke om, fjerne eller legge til noe til meldingen og fungerer kun som en ruting mekanisme.

3.2.4. Anvendelse av eMelding i PEPPOL-infrastrukturen i Norge

Generelt

Beskrivelsene her viser på hvordan den generiske referansearkitekturen for eMelding kan realiseres med arkitektur- og løsningskomponenter som inngår i PEPPOL-infrastrukturen; basert på CEF eDelivery.

Utover de arkitekturtegningene som presenenteres, henvises til omfattende dokumentasjon av eDelivery og PEPPOL.

PEPPOL eDelivery Network overview
Figur 12. PEPPOL eDelivery Network overview

Arkitektur- og løsningsbyggeklosser:

  • CEF SMP (Service Metadata Publisher): Oppslagstjeneste for å finne adresse og kapabiliteter for aktuell mottaker. Inneholder mottakers ID, aksesspunktadresse og dokumenttyper som mottaker kan motta. Aktuelle løsninger: ELMA.

  • BCP (Business Certificate Publisher): Sertifikatutsteder. Løsninger: Se https://vefa.difi.no/bcp/.

  • Adressetjenesten CEF SML (Service Metadata Locater): Global oppslagstjeneste for å finne fram til aktuell SMP.

  • BCL (Business Certificate Locator): Oppslagstjeneste for å finne BCP (introdusert ifm. Enhanced PEPPOL eDelivery Network).

  • Elektronisk mottakeradresseregister (ELMA): Norsk register over foretak som kan ta i mot dokumenter i standardisert EHF-format.

Klargjør for deling av data ved forsendelse (eMelding)
Klargjør for eMelding (løsningsmønster) image
Figur 13. Klargjør for eMelding (løsningsmønster)

Forklaring til figur:

Tabell 17. Elementer i view for Klargjør for eMelding (løsningsmønster)
Element Beskrivelse

Samhandlingsaktør

Samlebetegnelse på roller som inngår i en samhandlingsprosess og samhandler med en annen samhandlingsaktør. Kan være en tilbyder, konsument, avsender, mottaker, leverandør etc.

Klargjøre for deling av data ved forsendelse

Evne til å klargjøre for meldingsutveksling med eksterne parter.

Klargjør for melding

Prosessen med å klargjøre for melding ved å inngå nødvendige avtaler og tilgjengeliggjøre nødvendig informasjon til andre samhandlingsaktører.

Inngå avtaler for meldingsforsendelse

Prosessen med å inngå bilaterale avtaler med sammhandlingsparter eller innmelding i et fellesskap. F.eks. gjennom å akseptere spesifikke avtaler, vilkår eller kontrakter og innrette seg etter reglene og forpliktelsene som gjelder i et fellesskap (community), eller det som er avtalt mellom samhanslingsaktørene.

Registrer kapabiliteter

Registering av kapabiliteter vil si å tilgjengeligjøre for avsendere og konsumenter hvilke meldinger og formater man kan motta og hvilke ressurser og tjenester man tilbyr.

Registrer adresser

Med adresse menes nødvendig informasjon for å få tilgang til tjenester fra tilbyder eller for å sende melding til mottaker av meldinger.

Registrer sertifikater

Tilgjengeliggjøre for samhandlende parter sertifikater for bruk ved forsendelser. Dette kan være generelle eller domenespesifikke sertifikater. Eventuelt spesifikt for enkelet forretningsområder.

Sertifikater må forvaltes og fornyes etter gjeldende regler for å være gyldige og egnet for bruk.

Kapabilitetsregistrering

Tjeneste for å registrere kapabiliteter

Adresseregistrering

Tjeneste for å registrere adresse for å sende melding til mottaker.

Sertifikatregisterering

Tjeneste for å registrere serifikater i felles katalogtjeneste.

OpenPeppol

Elektronisk mottakerregister (ELMA)

Med ELMA får brukerne dine oversikt over alle virksomheter i Norge som kan motta elektroniske fakturaer i henhold til EHF-standarden.

CEF SML

Service Metadata Locator

BCL

Business Certificate Locater

BCP (CommFides eller Buypass)

Business Certificate Publisher

Operativ deling av data ved forsendelse (eMelding)
Send eMelding
Send eMelding  (løsningsmønster) image
Figur 14. Send eMelding (løsningsmønster)

Forklaring til figur:

Tabell 18. Elementer i view for Send eMelding (løsningsmønster)
Element Beskrivelse

Avsender

Den som sender et brev, en pakke, en e-post, en elektronisk melding, en SMS eller lignende.

Sende data

Evnen til å sende data til en mottaker.

Send melding

Prosessen med å sende en eMelding til en mottaker ved hjelp av fellestjenester.

Kontroller mottakers kapabiliteter

Prosess for å slå opp og kontrollere mottakers evner til samhandling innenfor fellesskapet.

Formater melding

Prosess for å tilpasse informasjonspakken til mottakers kapabiliteter og fellesskapets standarder.

Krypter melding

Prosess med å sikre forsendelsen. Inkluderer konfidensialitets- og integritetssikring der dette er nødvendig. Normalt gjøres dette ved hjelp av kryptografi og sertifikater.

Adresser forsendelse

Prosess med å adressere forsendelsen. Dette kan være til mottaker direkte eller til dennes representant eller aksesspunkt,

Signer forsendelse

Prosessen med å signere meldingen som sendes til mottaker. Til dette benyttes eget sertifikats private nøkkel.

Eksepeder melding

Prosessen med å sende melding til mottaker.

Kapabilitetsoppslag

Tjeneste for å slå opp kapabilitetene til en samhandlingspart

Datatransformasjon

Tjeneste for transformere data og meldinger til andre formater.

Sertifikatoppslag

Tjeneste for å hente krypteringssertifkat til mottaker.

Adresseoppslag

Tjeneste for å slå opp adressen til en mottaker.

Signeringstjeneste

Tjeneste for å signere en elektronisk melding. For eMelding er det signatur i form av elektronisk segl som er mest relevant.

Datautvekslings-tjeneste

Tjeneste for utveksling av data. Samme som data exchange service. Benyttes av avsender og mottaker for transport av meldinger.

Sporingstjeneste

Tjeneste for sporing (audit) av meldinger.

CEF SML

Service Metadata Locator

Elektronisk mottakerregister (ELMA)

Med ELMA får brukerne dine oversikt over alle virksomheter i Norge som kan motta elektroniske fakturaer i henhold til EHF-standarden.

BCL

Business Certificate Locater

BCP (CommFides eller Buypass)

Business Certificate Publisher

PEPPOL

Motta eMelding
Motta eMelding (løsningsmønster) image
Figur 15. Motta eMelding (løsningsmønster)

Forklaring til figur:

Tabell 19. Elementer i view for Motta eMelding (løsningsmønster)
Element Beskrivelse

Mottaker

Den som mottar en elektronisk melding eller tilsvarende.

Motta melding

Evnen til å motta, validere og kvittere for mottatte meldinger.

Motta melding

Prosessen med å motta melding. Består av flere delprosesser.

Etter mottak må mottaker følge opp og håndtere innholdet i meldingen.

Motta forsendelse

Prosessen med å motta en melding fra avsender

Kontroller forsendelse

Prosessen med å kontrollere om forsendelsen er autentisk og fra en legitim avsender.

Dekrypter melding

Prosessen med å dekryptere mottatt melding.

Valider forsendelse

Prosessen med å kontrollere om innholdet i en forsendelse er i henhold til avtale og avtalte formater.

Datautvekslings-tjeneste

Tjeneste for utveksling av data. Samme som data exchange service. Benyttes av avsender og mottaker for transport av meldinger.

Sporingstjeneste

Tjeneste for sporing (audit) av meldinger.

Signaturvaliderings-tjeneste

Tjeneste for å validere og verifisere elektronsike signaturer. I forbindelse med eMelding er det kontroll av elektronisk segl som er mest relevant.

Datavaliderings-tjeneste

Tjeneste for å validere meldinger mot format og forventet innhold.

PEPPOL

4. Mønstre for publisering

4.1. Introduksjon

Mønstre for publisering handler helt grunnleggende om at tilbydere publiserer datastrømmer, eller hendelsesstrømmer, uten å måtte vite hvem konsumentene er. Konsumentene kan i sin tur koble seg på disse hendelsestrømmene og ta rede på hva som skjer.

Publisering av hendelser - basiskonsept image
Figur 16. Publisering av hendelser - basiskonsept

Dette gir en form for løs kobling mellom aktørene som fremmer innovasjon og samhandling. Nye samhandlingsparter kan plukke opp hendelser og kople seg på i tjenesteproduksjonen. Forretningsprosessene behøver ikke være kartlagt og fastsatt i minste detalj på forhånd. Nye prosesser kan utvikles i dynamiske økosystemer. Dette kan ses som et essensielt element i satsingen på sammenhengende tjenester og realisering av målsetninger om datadrevet økonomi og innovasjon; se f.eks. Stortingsmelding om datadrevet økonomi og innovasjon.

Endringer i IT-systemene blir også enklere, fordi det vil være mindre avhengigheter til systemene hos andre virksomheter. En ønsker generelt å komme bort fra store monolittiske systemer som ikke er lagt opp til å samspille i en distribuert kontekst.

Løs kopling mellom IT-systemene er blant de de helt grunnleggende arkitekturprinsippene innen tjenesteorientert atrkitektur. Gjeldende arkitekturprinsipper fra Digitaliseringsdirektoratet per 2020 sier blant annet: Ta hensyn til anerkjente designprinsipper for tjenesteorientert arkitektur, slik som løse koplinger, modularisering, standardiserte tjenestekontrakter med videre.

Det fokuseres her på mønstre som understøtter hendelsesdrevet arkitektur og tjenesteorientering, og det benyttes et begrepsapparat som gjenspeiler dette. Mønstre for publisering handler derfor her i hovedsak om publisering av data om hendelser, samt strømming av slike data. Andre former for publisering, slik som f.eks. publisering av API-er i en API-katalog, faller utenfor her.

Det finnes flere varianter av mønstrene, og disse egner seg til ulike formål. Utvikling av arkitekturer og fellesløsninger pågår både i Norge og internasjonalt, blant annet med komponenter fra EU. Det finnes også en rekke teknologier og produkter, deriblant mye som open source.

I artikkelen What do you mean by “Event-Driven”? (fra 2017), redegjør Martin Fowler kort for noen av de mest aktuelle mønstrene for strømming av hendelser. Han peker her også på behovet for god veiledning.

Dette er fremdeles for de fleste et vanskelig område å navigere i. Det finnes mange kilder til informasjon, men ingen enkelt, dekkende lærebok. Både vinkling og begrepsapparat fra ulike kilder er egnet til forvirring.

Ambisjonsnivået her er heller ikke å gi en komplett innføring i alle aspekter. Beskrivelser og utvalg av mønstre vil være behovsdrevet og vil utvikles over tid.

Noen litteraturhenvisninger

Det er skrevet mye om arkitekturmønstre for publisering, strømming og hendelsesdrevet arkitektur de siste årene, gjerne med ulike innfallsvinkler ut fra sammenhengen med arkitekturparadigmer som SOA og Microservices.

Noen utvalgte henvisninger:

4.2. Bruksområder

Eksempler på anvendelse av mønstre for publisering og konsumering av hendelsesstrømmer:

  • Trigging av forretningsprosesser hos samhandlingsparter som deltar i dynamiske forretningsprosesser og tilpasset saksbehandling.

  • Replikering av data ved hendelsesbasert oppdatering av kopier og avledede datasett.

  • Logging av hendelsesrelaterte data for formål som arkivering og verifikasjon av etterlevelse.

  • Hendelsesbasert innhenting av data brukt til analyser og statistikk.

  • Strømming av IoT-data, enten periodisk (tidshendelse) eller ved terskeloverskridende endringer i måleverdier

4.3. Konsepter for publisering og konsumering av hendelsesstrømmer

4.3.1. Basiskonsepter

Aktørsamspill

Datatilbyder publiserer hendelsestrømmer som konsumeres av datakonsumenter. Tilsvarende kan en si at datatilbyders publiseringsløsning skriver notifikasjoner til hendelseslister etterhvert som hendelser skjer, etterfulgt av at datakonsumentene leser notifikasjoner gjennom sine løsninger for innhenting og mottak.

Publisering av hendelser - grunnleggende konsept
Figur 17. Publisering av hendelser - grunnleggende konsept, med applikasjoner

Legg merke til at den publiserte hendelseslisten her er en del av tilbyders løsning og ansvar.

I praksis kan også både datatilbyder og datakonsument velge å benytte en ekstern tjenesteleverandør for å formidle hendelsesdata. I så fall kan ekstern tjenesteleverandørs løsninger og tjenester anses som del av tilbyders eller konsuments løsninger og tjenester på lik linje med interne leverandører (og behøver ikke vises som egen part).

Det faller utenfor omfanget her å gå inn på tilfeller der ekstern tjenesteleverandør opptrer som mellomledd på en måte som gjør det nødvendig å se på juridiske forhold eller løsninger på tvers av partene.
Begrepsapparat

Grunnleggende begreper og sammenhenger er vist i følgende modell.

Grunnleggende begreper for publisering av hendelser image
Figur 18. Grunnleggende begreper for publisering av hendelser
  • Hendelser er det som skjer i den virkelige i verden, i en konstant strøm av endrede data, eller hendelsesstrømmer.

  • Subjekt er hvem eller hva hendelsen omhandler, slik dette er å oppfatte i den aktuelle konteksten. Dette kan f.eks. være et fysisk objekt (eks. bil), en person, en virksomhet eller et konsept (eks. politikk). Det kan også være en samling av underordnede subjekter, slik som f.eks. en befolkningsgruppe eller alle virksomheter som har et navn som begynner på A.

  • Assosiert med hver hendelse finnes et datagrunnlag som tilsvarer tilstanden før hendelsen inntraff. I bakkant av hendelsen finnes tilsvarende et oppdatert datagrunnlag.

  • I tilknytning til hver hendelse finnes Hendelsesrelaterte data. Dette kan være små eller store datasett som beskriver datagrunnlaget og aktuelle endringer. Nærmere om begreper og tekniske løsninger for dette gis i tilknytning til de ulike arkitekturmønstrene, med ulike måter å representere og oppdatere datagrunnlaget på, på tvers av tilbyder og konsument.

  • En notifikasjon informerer om at en hendelse har inntruffet og kan inneholde hele eller deler av det totale settet av aktuelle hendelsesrelaterte data, enten direkte eller gjennom lenke til hvor datasettet finnes (eventuelt en kombinasjon).

  • Notifikasjoner samles og publiseres av tilbyder gjennom hendelseslister.

  • En og samme hendelse kan være representert gjennom flere notifikasjoner som hver beskriver hendelsen på ulike måter for ulike formål og ulike målgrupper; som publisert gjennom ulike hendelseslister.

Innhold i notifikasjoner

En modell som konkretiserer notifikasjonsinnholdet er vist i figuren nedenfor. Her er det også angitt relasjonene til hendelsesrelaterte data, noe som kan være et langt større datasett enn det som utveksles i notifikasjoner mellom tilbyder og konsument.

Notifikasjonsinnhold image
Figur 19. Notifikasjonsinnhold

Forklaring til figuren over:

  • En notifikasjon inneholder som minimum en identifikator for notifikasjonen. Denne må være gyldig på tvers av tilbyder og konsument. Tilbyder må holde rede på sammenhengen mellom notifikasjon og assosierte, hendelsesrelaterte data.

  • Hvilke notifikasjonsdata som forøvrig er relevante, avhenger av hendelsestype og eventuell innholdsminimering.

    • Hendelsestype identifiserer typen hendelse overfor konsument, som grunnlag for filtrering og videre behandling.

    • Sekvensinformasjon kan gis ved å peke på foregående notifikasjon for samme subjekt. Tidsstempel med tilstrekkelig oppløsning kan også angi sekvens, men gir ikke generelt en like direkte og treffsikker identifisering av foregående notifikasjon. Merk: Løpende sekvensnummer er også mulig å benytte, men er ikke vist her.

    • Subjekt for hendelse: Se definisjon av subjekt.

Innhenting av notifikasjoner gjennom spørring mot hendelseslister

Pullbasert innhenting av notifikasjoner skjer gjennom at konsumenten forespør notifikasjoner fra tilbyder, etterfulgt av at forespurte notifikasjoner leveres. Dette kan være en enkelt notifikasjon eller flere i rekke. Illustrasjon (sekvensdiagram):

Spørring mot hendelseslister - basisflyt image
Figur 20. Spørring mot hendelseslister - basisflyt

Forespørsler gjøres mot tilbyders spørretjeneste, som vist i følgende diagram.

Tilbyders spørretjeneste mot hendelsesliste image
Figur 21. Tilbyders spørretjeneste mot hendelsesliste

Tilbyders spørretjeneste mot hendelseslister må støtte ulike måter å lese ut aktuelle hendelser på, slik som:

  • Spørringer for å hente ut filtrerte utvalg av notifikasjoner og, ved behov, minimere datainnhold i hver enkelt notifikasjon.

  • Avspilling av notifikasjoner innen angitt tidsrom.

  • Avspilling av seneste notifikasjoner, f.eks etter en gitt identifikator.

Innhenting av supplerende hendelsesrelaterte data

For notifikasjoner som ikke gir et tilstrekkelig sett av hendelsesrelaterte data for konsumentens formål, må datakonsumenten selv ta initiativ til å innhente supplerende hendelsesrelaterte data.

Det er uproblematisk å sende med en ny måleverdi for et termometer, mens det kan være mindre ønskelig å distribuere komplette kopier av større og distribuerte datasett. Hensyn til dataminimering (personvern eller andre hesnyn) spiller også en rolle i slike vurderinger.

Den typiske prosessen er illustrert i følgende sekvensdiagram:

Spørring mot hendelseslister - med innhenting av supplerende data image
Figur 22. Spørring mot hendelseslister - med innhenting av supplerende data

I forespørsel om supplerende hendelsesrelaterte data må det kunne identifiseres hvilke data som ønskes. Tilbyder kan gi ulike opsjoner for dette. En mulighet er at identifikator for notifikasjonen entydig identifiserer aktuelle datasett. En annen mulighet er f.eks. spørring etter etter spesifikke informasjonselementer for et angitt subjekt.

Det bør sikres at hendelsesrelaterte data forblir identifiserbare og tilgjengelige over tid. En god måte å gjøre dette på er gjennom globalt unike identifikatorer i kombinasjon med en mekanisme for datavirtualisering.
Selve innhentingen av supplerende hendelsesrelaterte data dekkes av eOppslag referansearkitektur.

4.3.2. Avanserte konsepter

Abonnementsbasert publisering
Dette konseptet tilsvarer det som i litteraturen tradisjonelt omtales som publish-subscribe; se f.eks. wikipedia om publish-subscribe pattern for en enkel beskrivelse av dette.

Her introduseres støtte for å tegne abonnementer for formål og behov som:

  • Støtte for strenge sanntidskrav. Unngå behov for å polle hendelseslistene for endringer og i stedet få abonnerte notifikasjoner levert fortløpende (pushbasert levering).

  • Velg mellom opsjoner for å få mottak av notifikasjoner til ønsket teknisk grensesnitt (f.eks. kall av API vs. levering til meldingkø).

  • SLA-avtaler, f.eks. avtale om akseptable tidsforsinkelser før levering av notifikasjoner.

  • Abonnementsbasert betaling. f.eks. ut fra valg mellom ulike, volumbaserte prispakker som tilbys, eller f.eks. volumuavhengig fastpris.

Følgende figur illustrerer det forretningsmessige koneptet for abonnement på hendelsesstrømmer.

Publisering av hendelser - basiskonsept med abonnement image
Figur 23. Publisering av hendelser - basiskonsept med abonnement

Registrering av abonnement gjøres typisk mot en selvbetjeningsløsning for dette hos datatilbyder. Datatilbyder vil deretter sende notifikasjoner fortløpende og pushbasert til konsumentens mottaksløsning som avtalt.

Pushbasert levering av notifikasjoner til abonnenter image
Figur 24. Pushbasert levering av notifikasjoner til abonnenter
Analogi til mediehus:
  • Mediehus (tilbyder) publiserer nyheter (hendelser) via nyhetskanaler (hendelsesstrømmer) til et konsumentmarked der konsumentene ikke nødvendigvis er kjent på forhånd.

  • Konsumenter kan kople seg på for å lese nyheter på tilfeldig basis, f.eks. en løssalgsavis.

  • Konsumenter kan eventuelt tegne abonnementer for å få levert nyhetene "på døra" (f.eks. til en innboks).

  • Konsumenter kan også tegne abonnementer for å få et utvalg av nyhetene (innholdsfilter.)

  • Tilbyder kan ta betalt for innhold og tjenester, eller det kan være gratis.

Filtrering og minimering av hendelseslister og notifikasjoner

Filtrering og minimering av hendelseslister og notifikasjoner handler om:

  1. Filtrering av hendelseslister slik at en får det ønskede utvalget av subjekter og hendelser, f.eks. salg av leiligheter til under 2 millioner kroner i din bydel. Dette handler ikke om å gjøre innhentingen stykkevis og delt. Det er normalt viktig å sørge for at den filtrerte hendelseslisten gir komplett historikk for formålet.

  2. Minimering av innholdet i notifikasjoner, slik at konsumenten unngår å motta eller få tilgang til mer informasjon enn det som er interessant for konsumenten eller det has hjemmel for ut fra personvernhensyn.

Dette kan løses på ulike måter, herunder:

  1. Tilbyder tilbyr ulike hendelseslister, der det i utgangspunktet er gjort et utvalg fra det komplette utvalget innen tilbyders domene, basert på metadata og kriterier som tema eller konfidensialitet for hver hendelsesliste.

  2. Tilbyder filtrerer innen hver hendelsesliste ut fra konsumentens spesifikasjon /spørring.

  3. Tilbyder minimerer innholdet i hver notifikasjon ut fra konsumentens spesifikasjon /spørring.

  4. Konsumenten ignorerer irrelevante notifikasjoner ved å filtrere innlesingen på konsumentsiden eller forkaste notifikasjoneretter innlesing.

På veien fra tilbyder til konsument vil hendelseslister og notifikasjoner på denne måten endre innhold. Det er de samme hendelsene som gjelder, men nye datasett. Det kan være nyttig å skille mellom tilbyders publiserte notifikasjoner, utvekslede notifikasjoner (tilpasset for konsument av tilbyder) og de notifikasjonene som er relevante for konsument og tas videre til prosessering. En kan tilsvarende se på serier av f.eks. utvekslede notifikasjoner som en utvekslet hendelsesliste. Dette begrepsapparatet er oppsummert i følgende modell.

Filtrering og minimering av hendelseslister og notifikasjoner på tvers av tilbyder og konsument image
Figur 25. Filtrering og minimering av hendelseslister og notifikasjoner på tvers av tilbyder og konsument
Tilstand som resultat av hendelser

Et subjekts tilstand kan beskrives i form av et øyeblikksbilde eller som en serie endringer ut fra et tidligere øyeblikksbilde. En notifikasjon inneholder tilsvarende enten et øyeblikksbilde av subjektet eller data om hendelsen som beskriver en inkrementell endring.

Eksempel: Anta at termometeravlesninger rapporteres som daglige endringer siden forrige avlesning. For å finne dagens temperatur, må det være et kjent startpunkt (øyeblikksbilde).

En kan tenke på notifikasjoner som transaksjoner i et regskap som gjøres opp med jevne mellomrom. Subjekttilstanden tilsvarer saldo, og ny saldo kan enkelt regnes ut ved å legge sammen alle transaksjonene siden forrige dokumenterte oppgjør. En kan også gå hele veien tilbake til oppstart, som i dette tilfellet uten videre er et kjent utgangspunkt (nullsaldo).

4.4. eNotifikasjon

4.4.1. Om dette mønsteret

eNotifikasjon er en referansearkitektur for utveksling av notifikasjoner som er innrettet på å støtte opp under "nyere" arkitekturmønstre for distribuerte applikasjoner, særlig aktuelt innen Microservices som arkitekturparadigme.

Et sentralt arkitekturmønster som støttes, er best kjent som Event Sourcing, blant annet karakterisert ved at tilstanden til et system eller et subjekt kan bestemmes ut fra en logg av hendelser. Se litteratur om Event Sourcing

Beskrivelsene her bygger på utvalgte deler av en separat oversikt over konsepter for publisering og konsumering av hendelsesstrømmer.

Grunnleggende egenskaper ved eNotifikasjon som mønster - en oppsummering av aktuelle konsepter:

  • Tilstanden til et subjekt kan bestemmes gjennom å prosessere en kronologisk sekvens av hendelser, ut fra et gitt øyeblikksbilde.

  • En hendelse kan representeres ved en eller flere notifikasjoner.

  • Notifikasjoner samles i hendelseslister.

  • Hendelser er i seg selv uforanderlige (immutable). Tilsvarende gjelder for notifikasjoner i hendelseslister, dvs. at notifikasjoner i regelen ikke endres eller slettes fra hendelseslister.

  • Hver enkelt konsument kan lese samme notifikasjon flere ganger.

  • Hendelseslister kan traverseres og spørres mot.

  • En hendelsesliste tilsvarer en logg, og kan benyttes som en logg.

4.4.2. Verdistrømbeskrivelse

eNotifikasjon - oversikt over verdistrømmer

Følgende modell viser en oversikt over verdistrømmene på tvers av datatilbyder og datakonsument for eNotifikasjon. Dette er en spesialisering av den generiske verdistrømbeskrivelsen som finnes under Felles referansemodeller for datadeling.

eNotifikasjon - oversikt over verdistrømmer image
Figur 26. eNotifikasjon - oversikt over verdistrømmer

Disse verdistrømmene er nærmere beskrevet for hver rolle i påfølgende avsnitt.

eNotifikasjon - verdistrøm for datatilbyder

Her vises verdistrømmen for eNotifikasjon sett fra datatilbyder, med angivelse av kapabiliteter.

Det som er spesifikt for eNotifikasjon er vist med uthevet skrift, dvs. Inngå avtaler om tilgang og levering av hendelsesstrømmer, Generere og tilby notifikasjoner, samt Avgi forespurte notifikasjoner. Realiseringen av disse kapabilitetene beskrives i prosessmodeller m.v. for eNotifikasjon.

Øvrige kapabiliteter er beskrevet andre steder; se referansearkitektur for mønsteret eOppslag.

eNotifikasjon - tilbyders verdistrøm image
Figur 27. eNotifikasjon - tilbyders verdistrøm
eNotifikasjon - verdistrøm for datakonsumenter

Her vises verdistrømmen for eNotifikasjon sett fra datakonsumenter, med angivelse av kapabiliteter.

Det som er spesifikt for eNotifikasjon er vist med uthevet skrift, dvs. Inngå avtaler om tilgang og innhenting av hendelsesstrømmer og Innhente og håndtere notifikasjoner. Realiseringen av disse kapabilitetene beskrives i prosessmodeller m.v. for eNotifikasjon.

Øvrige kapabiliteter er beskrevet andre steder; se referansearkitektur for mønsteret eOppslag.

eNotifikasjon - konsumenters verdistrøm image
Figur 28. eNotifikasjon - konsumenters verdistrøm

4.4.3. Kapabilitetskart for eNotifikasjon

Modellen under gir en samlet oversikt over kapabiliteter som er spesifikke for eNotifikasjon, slik disse er identifisert i foregående verdistrømbeskrivelse.

Kapabiliteter eNotifikasjon image
Figur 29. Kapabiliteter eNotifikasjon
Tabell 20. Elementer i view for Kapabiliteter eNotifikasjon
Element Beskrivelse

Datatilbyder

Tilbyder av data til andre aktører.

Datakonsument

Den som innhenter eller mottar data fra andre aktører.

Innhente og håndtere notifikasjoner

Evnen til å konsumere hendelseslister ved å innhente notifikasjoner.

Generere og tilby notifikasjoner

Evnen til å dele informasjon om hendelser gjennom notifikasjoner som tilgjengeliggjøres for konsumenter gjennom hendelseslister.

Inngå avtaler om tilgang og innhenting av hendelsesstrømmer

Evnen til å inngå avtaler med datatilbyder om tilgang til hendelser gjennom hendelseslister med notifikasjoner.

Inngå avtaler om tilgang og levering av hendelsesstrømmer

Evnen til å inngå avtaler med datakonsumenter om tilgengjengeliggjøring av hendelseslister med notifikasjoner om hendelser.

Avgi forespurte notifikasjoner

Evnen til å avgi notifikasjoner på forespørsel

4.4.4. Realisering av kapabiliteter - generisk arkitekturmønster

Her beskrives realiseringen av de kapabilitetene som er spesifikke for eNotifikasjon i form av et generisk, løsningsuavhengig arkitekturmønster. Det vil kunne være flere måter å realisere aktuelle arkitekturbyggeklosser på.

Inngå avtaler om tilgang og levering av hendelsesstrømmer

Gi tilgang til notifikasjoner og hendelser er den prosessen datatilbyder må gjøre for å gi datakonsumenten tilgang til hendelseslister. Ved helt åpne hendelseslister kan prosessen være unødvendig og utgår, men vil normalt omfatte å tilgjengeliggjøre API som beskrevet i eOppslag. I tillegg kan det eventuelt registreres informasjon i tilknytning til filtrering og tilpasning av hendelselister ut fra konsumentens behov og tilganger.

Gi tilgang til notifikasjoner og hendelser image
Figur 30. Gi tilgang til notifikasjoner og hendelser
Tabell 21. Elementer i view for Gi tilgang til notifikasjoner og hendelser
Element Beskrivelse

Gi tilgang til notifikasjoner og hendelser

Prosessen med oppsett for å gi tilgang til notifikasjoner og hendelser.

Motta forespørsel om tilgang til hendelsesstrømmer

Prosessen med å motta forespørsel om tilgang til notifikasjoner på hendelseslister.

Inngå avtale om tilgang til hendelsesliste med notifikasjoner

Prosessen med å registrere seg som konsument av en hendelsesliste hos datatilbyder

Datatilbyder

Tilbyder av data til andre aktører.

Registrering av konsument av hendelsesliste

Tjeneste for å registrere konsumenter av hendelseslite med notifikasjoner.

Inngå avtaler om tilgang og levering av hendelsesstrømmer

Evnen til å inngå avtaler med datakonsumenter om tilgengjengeliggjøring av hendelseslister med notifikasjoner om hendelser.

Inngå avtaler om tilgang og innhenting av hendelsesstrømmer

Få tilgang til notifikasjoner og hendelser er den prosessen datakonsument må gjøre for å sette opp og få tilganger til hendelseslister. Prosessetrinnene kommer i tillegg til prosessen for å få tigang til API som beskrevet i eOppslag.

Få tilgang til notifikasjoner og hendelser image
Figur 31. Få tilgang til notifikasjoner og hendelser
Tabell 22. Elementer i view for Få tilgang til notifikasjoner og hendelser
Element Beskrivelse

Beskrive behov og tilganger

Prosessen med å beskrive hvilke tilganger konsument har rettigeheter til og hvilken type notifikasjoner som er aktuelle.

Inngå avtale om tilgang til hendelsesliste med notifikasjoner

Prosessen med å registrere seg som konsument av en hendelsesliste hos datatilbyder

Datakonsument

Den som innhenter eller mottar data fra andre aktører.

Inngå avtaler om tilgang og innhenting av hendelsesstrømmer

Evnen til å inngå avtaler med datatilbyder om tilgang til hendelser gjennom hendelseslister med notifikasjoner.

Registrering av konsument av hendelsesliste

Tjeneste for å registrere konsumenter av hendelseslite med notifikasjoner.

Generere og tilby notifikasjoner

Generer og publiser notifikasjoner er den prosessen datatilbyder må gjøre for å tilby notifikasjoner gjennom hendelseslister. Hendelselister tilbys på tilsvarende måte som beskrevet for generelle mønstre for spørring og oppslag (herunder eOppslag), men det finnes spesielle krav for hendelseslister med tanke på segmentering, filtrering og navigering.

Generer og publiser notifikasjoner image
Figur 32. Generer og publiser notifikasjoner
Tabell 23. Elementer i view for Generer og publiser notifikasjoner
Element Beskrivelse

Generere og publisere notifikasjoner

Evnen til å generere notifikasjoner som data om hendelser, samt å publisere slike notifikasjoner i en eller flere hendelseslister, eventuelt tilpasset ulike målgrupper.

Datatilbyder

Tilbyder av data til andre aktører.

Generer og publiser notifikasjoner

Prosessen med å dele informasjon om hendelser.

Generer notifikasjon ut fra hendelse

Prosessen med å generere en notifikasjon på bakgrunn av en hendelse.

Publiser notifikasjon i hendelseslister

Prosessen med å legge notifikasjoner i en eller flere hendelseslister som er eksponert overfor aktuelle konsumenter.

Notifikasjon

En notifikasjon informerer om at en hendelse har inntruffet og kan inneholde elle peke til hele eller deler av det totale settet av aktuelle, hendelsesrelaterte data.

Hendelsesliste

Liste med notifikasjoner tilgjengelig for konsumenter.

Generering av notifikasjon

Tjeneste som genererer notifikasjoner basert på hendelser, der alle aktuelle grunnlagsdata er med eller lenket til.

Skriving av notifikasjon til eksponerte hendelseslister

Tjeneste for å skrive en notifikasjon til en eller flere hendelseslister, eventuelt med filtrering av informasjon ut fra hvem som er aktuelle konsumenter.

Komplett notifikasjon, tilbyders domene

Notifikasjon som inneholder eller lenker til et fullstendig sett av hendelsesrelaterte data.

Publisert hendelsesliste

Hendelsesliste som eksponeres for konsument. En tilbyder kan tilby flere hendelselister i parallell f.eks. med ulike temaer og for konsumenter med ulike rettigheter.

Publisert notifikasjon

Notifikasjon som publiseres på en eller flere hendelseslister. Publiserte notifikasjoner kan være "tykke" eller "tynne" med hensyn på hvor mye informasjon om en hendelse de inneholder.

Avgi forespurte notifikasjoner

Notifikasjoner avgis gjennom API på tilsvarende måte som beskrevet for generelle mønstre for spørring og oppslag, men tilbyder må, ved behov, tilpasse hendelsene som avgis etter det konsumenten har rettigheter til og etterspør. F.eks. kan konsumenten kun ha rettigheter til en delmengde av alle hendelser i hendelsesliten og også kun være interessert i enkelte typer hendelser. Konsumenten vil også normalt kun ha behov for å hente notifikasjoner som ikke er hentet tidliger, men kan også ønske å hente tidligere notifikasjoner på nytt.

Avgi forespurte notifikasjoner image
Figur 33. Avgi forespurte notifikasjoner
Tabell 24. Elementer i view for Avgi forespurte notifikasjoner
Element Beskrivelse

Tilbyders spørretjeneste mot hendelsesliste

Tjeneste for spørring og navigering av hendelsesliste gjennom API.

Avgi forespurte data gjennom API

Prosessen med å avgi data på forespørsel gjennom et egnet API.

Avgi forespurte notifikasjoner gjennom API

Prosessen med å avgi notifikasjoner på forespørsel gjennom et API som

Motta forespørsel om notifikasjoner

Motta forespørsler fra konsument om å avgi notifikasjoner.

Avgi utvalgte notifikasjoner

Avgi utvalgte hendelser basert på parametere i forespørsel om notifikasjoner.

Tilpass innhold til konsument (dersom aktuelt)

Prosessen med å tilpasse innholdet til konsument. Tilpasningen gjøres på grunnlag av parametere/informasjon i forespørselen.

Autentiser konsument og kontroller tilgang

Prosessen med å autentisere en konsument og kontrollere rettigheter til data.

Datatilbyder

Tilbyder av data til andre aktører.

Forespørsel om notifikasjoner

Dataobjekt med eventuelle parametere for spørring på notifikasjoner fra tilgjengelig hendelsesliste. Kan inneholde referanse til hvor i hendelselisten (f.eks. tid eller sekvensnummer) man ønsker å lese, avgrensning til temaer, rettigheter og liknende. Informasjonen er grunnlag for eventuell tilpasning av innhold og utvalg.

Tilbyders filtrerings- og minimeringstjeneste

Tjeneste for å filtrere og minimere informasjon ut fra parametere i forespørselen og hvilken informasjon konsumenten har rettigheter til.

Autentiseringstjeneste

Tjeneste som benyttes av tilbyder for å autentisere aktuell konsument.

Tilgangskontroll-tjeneste

Tjeneste for å sjekke rettigheter til data. Kan være eksterne eller interne tjenester. Eksempler på rettigheter kan komme av samtykker fra person eller virksomhet, eller rollebasert fra vergemål, familierelasjon el.

Avgi forespurte notifikasjoner

Evnen til å avgi notifikasjoner på forespørsel

Utvekslet hendelsesliste

Hendelsesliste som utveksles, filtrert ut fra konsumentens spesifikasjoner.

Publisert hendelsesliste

Hendelsesliste som eksponeres for konsument. En tilbyder kan tilby flere hendelselister i parallell f.eks. med ulike temaer og for konsumenter med ulike rettigheter.

Publisert notifikasjon

Notifikasjon som publiseres på en eller flere hendelseslister. Publiserte notifikasjoner kan være "tykke" eller "tynne" med hensyn på hvor mye informasjon om en hendelse de inneholder.

Utvekslet notifikasjon

Notifikasjon som utveksles, eventuelt minimert ut fra konsumentens spesifikasjoner.

Innhente og håndtere notifikasjoner

Notifikasjoner leses på tilsvarende måte som beskrevet for generelle mønstre for spørring og oppslag (herunder eOppslag), men konsumentene må holde orden på spesielle forhold som rekkefølge og hvilke notifikasjoner som er lest. Konsumenten må også være i stand til å vurdere relevansen av hendelsene før videre behandling av notifikasjonene.

Konsumer notifikasjoner image
Figur 34. Konsumer notifikasjoner
Tabell 25. Elementer i view for Konsumer notifikasjoner
Element Beskrivelse

Innhente og håndtere notifikasjoner

Evnen til å konsumere hendelseslister ved å innhente notifikasjoner.

Datakonsument

Den som innhenter eller mottar data fra andre aktører.

Konsumer notifikasjoner

Prosessen med å lese og håndtere notifikasjoner.

Forespør og motta notifikasjoner

Prosess for å hente inn en eller flere notifikasjoner fra en hendelsesliste.

Vurder relevans av notifikasjon

Prosess med å vurdere om en hendelsen knyttet til lest notifikasjon er relevant for konsumenten.

Forkast notifikasjon

Prosess med å forkaste notifikasjon som ikke er relevant for virksomheten. Avhengig av krav til personvern og informasjonssikkerhet kan det være særskilte krav til hva som er lov å beholde.

Videre behandling av notifikasjon

Prosess med videre behandling av en notifikasjon som normalt vil være å innhente mer informasjon om hendelsen eller subjektet notifikasjonen er knyttet til og eventuelt agere ut i fra denne.

Forespørsel om notifikasjoner

Dataobjekt med eventuelle parametere for spørring på notifikasjoner fra tilgjengelig hendelsesliste. Kan inneholde referanse til hvor i hendelselisten (f.eks. tid eller sekvensnummer) man ønsker å lese, avgrensning til temaer, rettigheter og liknende. Informasjonen er grunnlag for eventuell tilpasning av innhold og utvalg.

Kriterier og regler for å vurdere relevans av notifikasjoner

Informasjon om hva som legges til grunn for å vurdere relevansen av en hendelse, basert på informasjon i lest notifikasjon.

Notifikasjon

En notifikasjon informerer om at en hendelse har inntruffet og kan inneholde elle peke til hele eller deler av det totale settet av aktuelle, hendelsesrelaterte data.

Konsuments filtrerings- og minimeringstjeneste

Tjeneste for å filtrere innhentede notifikasjoner. Dette er en tilleggsmekanisme for filtrering og minimering, sammenliknet med det som gjøres gjennom spørringer mot datatilbyder, og benyttes ved behov. Filtreringen kan gjøres ved å filtrere selve innlesing eller ved å filtrere mottatte notifikasjoner etter innlesing. Etter innlesing kan det også gjøres minimering av innholdet i notifikasjonen.

Datautvekslings-tjeneste

Tjeneste for utveksling av data over aktuell transportprotokoll, f.eks, gjennom asynkrone medlinger eller synkrone API-oppslag.

Tilbyders spørretjeneste mot hendelsesliste

Tjeneste for spørring og navigering av hendelsesliste gjennom API.

4.4.5. Løsningsmønstre for eNotifikasjon

Spesifikke løsningsmønstre for eNotifikasjon er inntil videre ikke utarbeidet. Det er stor variasjon i praksis, og ingen fellesløsninger er så langt etablert i Norge.

Mer om fellesløsninger, standarder og løsningsmønstre vil følge her etterhvert.

Det finnes i mellomtiden noen gode eksempler å peke på.

Her nevnes spesielt:

  1. Modernisert folkeregister fra Skatteetaten tilbyr hendelseslister og oppslag som konsumenttjenester. Disse tjenestene er beskrevet i Folkeregisterets API dokumentasjon.

5. Sammensatte arkitekturmønstre for datadeling og samhandling

Basismønstre for datautveksling kan kombineres og brukes på ulike måter. Her beskrives noen typiske brukstilfeller og samhandlingsmønstre.

i arbeid I arbeid.

Som eksempler på samhandlingsmønstre som det kan være aktuelt å adressere her, er meldingsutveksling i tverrgående prosesser mellom kjente parter, dynamiske prosesser i økosystem og flere spesialiserte arbeidsflytmønstre (f.eks. det mønsteret son benyttes i eResept, der det publiseres en hendelse til alle apotekene, men kun ett apotek kan ta jobben og "kvittere ut" hendelsen).