Publisering og konsumering av hendelsesstrømmer

1. Om publisering og konsumering av hendelsesstrømmer

Mønstre for publisering handler helt grunnleggende om at tilbydere publiserer data, uten nødvendigvis å vite om aktuelle konsumenter. Data kan i denne sammenhengen være f.eks. metadata som i Felles datakatalog, eller f.eks. data bak et API som publiseres åpent.

Et spesialtilfelle som omhandles med en egen referansearkitektur her, er publisering av hendelsesstrømmer.

2. Bruksområder for publisering av hendelsesstrømmer

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

3. Konsepter for publisering av hendelsestrømmer

3.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 1. 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:

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

3.3. Konsepter for publisering og konsumering av hendelsesstrømmer

3.3.1. Basiskonsepter

3.3.1.1. 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 2. 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.
3.3.1.2. Begrepsapparat

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

Grunnleggende begreper for publisering av hendelser image
Figur 3. 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.

3.3.1.3. 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 4. 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.

3.3.1.4. 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 5. 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 6. 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.

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

3.3.2. Avanserte konsepter

3.3.2.1. 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 8. 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 9. 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.

3.3.2.2. 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 10. Filtrering og minimering av hendelseslister og notifikasjoner på tvers av tilbyder og konsument
3.3.2.3. 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. eNotifikasjon

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.2. Verdistrømbeskrivelse

4.2.1. 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 11. eNotifikasjon - oversikt over verdistrømmer

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

4.2.2. 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 12. eNotifikasjon - tilbyders verdistrøm

4.2.3. 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 13. eNotifikasjon - konsumenters verdistrøm

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 14. Kapabiliteter eNotifikasjon
Tabell 1. 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. 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å.

4.4.1. 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 15. Gi tilgang til notifikasjoner og hendelser
Tabell 2. 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.

4.4.2. 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 16. Få tilgang til notifikasjoner og hendelser
Tabell 3. 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.

4.4.3. 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 17. Generer og publiser notifikasjoner
Tabell 4. 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.

4.4.4. 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 18. Avgi forespurte notifikasjoner
Tabell 5. 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.

4.4.5. 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 19. Konsumer notifikasjoner
Tabell 6. 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.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.