Denne side beskriver, hvordan hændelser fungerer på Datafordeleren som et værktøj til at holde registerdata synkroniseret.

Hændelser giver anvendere mulighed for at modtage automatiske notifikationer, når data ændres, så de kan holde egne løsninger opdaterede uden at skulle forespørge unødigt efter data.

Hvad er hændelser?

For et register er en hændelse en ændring af data. En hændelse kan således være resultatet af et trin i en forvaltningsproces (også omtalt som en forretningsproces), som opdaterer data i et register.

Hændelser bliver automatisk oprettet som strukturerede notifikationer, når ændringerne i registerdata indlæses på Datafordeleren. Det fungerer som et system, der kommunikerer dataændringer, når anvendere opretter en forbindelse ved at abonnere på hændelser eller henter hændelser via queries.

Ved at bruge hændelser, kan du som anvender hente opdateringer, og holde dine egne data synkroniseret med de nyeste ændringer. For eksempel hvis en virksomhed skifter navn, vil du få en hændelsesbesked, hvorefter du kan opdatere dit kopiregister.

Hændelser er opdelt per register, så du kan vælge kun at modtage hændelser for de enkelte registre, du har behov for. Hændelser per register er implementeret som en entitet, der fungerer på samme måde som andre entiteter, som kan hentes gennem Datafordelerens GraphQL-tjenester. Eksempelvis har BBR en entitet, der hedder BBR_Events, gennem hvilken alle hændelser for BBR kan hentes.

Hændelser indeholder metadata om ændringerne i registerdata, herunder:

• Hvilken handling der skete (insert, update, delete).
• Navnet på entiteten.
• Et ID der identificerer den specifikke række, så dataene kan spores videre til entiteten med ændringerne.
• Sekvensnummer på den indlæste pakke som dataene kommer fra.

Hændelser er gjort tilgængelige med to forskellige metoder:

• Forespørgsel til entitetsbaserede GraphQL-tjenester via query til hændelsesentiteten.
• Abonnement på hændelser via Server-Sent Events (SSE) for opdateringer i næsten realtid.

Typisk vil hændelser blive brugt i en totrinsproces:

• Hent eller modtag hændelser for at se, hvilke objekter der er ændret.
• Hent den faktiske data for de ændrede objekter i separate forespørgsler til GraphQL-tjenesterne .

Hvad betyder data i hændelser?

Hændelser der modtages via GraphQL kan indeholde felterne som vises i nedenstående tabel, hvis anvender inkluderer dem i sin query.

Data i en hændelse er i høj grad baseret på det underliggende dataobjekt, som hændelsen refererer til. En dybere forståelse af felterne kræver derfor kendskab til de specifikke entiteter, som hændelserne er baseret på, og deres struktur.

Bitemporal data

Du kan som anvender filtrere entiteter baseret på bitemporale data ved hjælp af inputvariablerne object_registreringfra, object_registreringtil, object_virkningfra og object_virkningtil, hvilket muliggør mere præcis og kontekstspecifik datahentning.

Nogle entiteter understøtter forespørgsler på begge dimensioner, mens andre kun understøtter én af værdierne - hvilke bitemporale dimensioner, der understøttes for en given entitet, kan ses i tjenestens GraphQL-skema.

Læs mere om filtrering og tilladte operatorer i afsnit 4.2 (Mulige filtreringer).

Specielt om CPR-felter

CPR-registeret har specielle filtreringsmuligheder, der ikke findes i andre registre. Dette skyldes CPR's unikke behov for at kunne spore borgeres tilknytning til kommuner over tid, hvilket er relevant for mange offentlige myndigheder og private virksomheder, der arbejder med persondata. Disse vises i nedenstående tabel.

De to yderligere felter giver mulighed for at filtrere hændelser baseret på borgeres kommunetilhørsforhold, både nuværende og historisk. Dette er særligt nyttigt når anvendere kun har behov for at modtage hændelser om borgere i specifikke kommuner, eller når de f.eks. skal håndtere kommuneskift.

Læs mere om filtrering af hændelser for CPR baseret på kommunekoder i afsnit 4.2.1.2 (CPR-felter).

Overordnet arkitektur

Figuren nedenfor illustrerer den overordnede arkitektur for distribution af hændelser via Datafordeleren.

Data oprettes og vedligeholdes i registre og kopieres løbende til Datafordeleren gennem replikeringskanaler. Herefter indlæses data i Datafordelerens databaser, hvor der genereres hændelser baseret på den indlæste data.

Datafordeleren distribuerer både registerdata og hændelser til anvendere, som kan tilgå data gennem forskellige tjenester, eksempelvis de entitetsbaserede GraphQL-tjenester.

Grundlæggende GraphQL for hændelser

Hændelser udstilles via GraphQL-tjenester, som følger de samme principper som der er beskrevet i *\[C0200-REST-GRAPHQL\]* og *\[C0200-ENTITETSBASEREDE-GRAPHQL\]{*}under GraphQL på Datafordeleren. De vigtige koncepter for moderniserede entitetsbaserede hændelser er:

• Skemastruktur - Hændelser følger samme skemaprincipper som andre GraphQL-entiteter.
• Filtrering - Anvender samme filtreringsoperatorer (eq, gt, in, osv.) som beskrevet i [C0200-REST-GRAPHQL].
• Paging - Hændelser følger standard GraphQL-pagingsmønstre.

Brugsscenarier for hændelser

Der kan være forskellige scenarier for, hvordan en anvender ønsker at modtage hændelser. Har man ikke behov for at modtage opdateringer med det samme, kan man hente hændelser med queries mod GraphQL-tjenesterne, beskrevet i afsnit 2.3.1 (Anvendelse af queries). .

Har man derimod behov for at modtage hændelser i nær realtid, fordi man for eksempel skal igangsætte en proces baseret på ændringer i registerdata, kan man i stedet abonnere på hændelser, beskrevet i afsnit 2.3.2 (Abonnement på hændelser).

Autentifikation og autorisation for at kunne sende forespørgsler til GraphQL-tjenesterne er beskrevet i [C0200-ENTITETSBASEREDE-GRAPHQL] Autentifikation og autorisation for GraphQL-tjenester.

Anvendelse af queries

Ved anvendelse af queries for at modtage hændelser, sendes en query afsted mod endepunktet for det ønskede registers GraphQL-tjeneste.

Når anvenderen du sender en query, får anvenderen du hændelser tilbage, der indeholder metadata om ændringer i registerets data. Hvor mange hændelser der bliver returneret, og hvilke entiteter det omhandler kommer an på den sendte query.

Queries returnerer alle hændelser for et register, inklusive historiske. EventID kan bruges for at filtrere på nye hændelser gennem at lave et "greater than" filter på den sidste kendte EventID. Filtrering beskrives yderligere i afsnit 4.2 (Mulige filtreringer).   Læs mere om filtrering.

Dette flow er afbilledet i Figur 2nedenfor.

Abonnement på hændelser

GraphQL-abonnementer på hændelser benytter Server-Sent Events (SSE) teknologi, som muliggør en vedvarende forbindelse mellem server og klient (anvenders egne løsninger). Når en klient sender en GraphQL forespørgsel for at abonnere på hændelser, oprettes der til serveren, en åben forbindelse, som venter på nye data.

Hvis der er hændelser tilgængelige der opfylder de kriterier opsat i abonnementet, returneres de næsten øjeblikkeligt via SSE. Ellers holdes forbindelsen åben, indtil forbindelsen rammer tidsgrænsen på 10 minutter, eller brugeren selv lukker den. Klienten kan derefter straks åbne en ny forbindelse og fortsætte med at vente på opdateringer, hvilket sikrer næsten realtids-opdateringer. Afsendelsesfrekvensen for hændelser vil som udgangspunkt ligge på 30 sekunder for alle registre, dvs. det vil sige at der maksimum vil gå 30 sekunder, fra en hændelse er oprettet i Datafordelerens database, til den publiceres til anvendere. Dette flow er afbilledet i Figur 3nedenfor.

Abonnementsforespørgsler ligner almindelige queries, men uden pagingsegenskaberpaging egenskaber, da kun én hændelse returneres ad gangen, når nye data detekteres.

Abonnementer understøtter de samme filtreringsmuligheder som queries, hvilket giver dig som anvender kontrol over hvilke hændelser, der skal modtages.

Filtrering beskrives i afsnit 4.2 (afsnittet Mulige filtreringer), og oprettelse af abonnement på hændelser beskrives i afsnit 4.5 (afsnittet Opret abonnement).