...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
Feltnavn | Betydning |
|---|---|
eventid | Identifikator for den specifikke hændelse. |
entityname | Navnet på entiteten som hændelsen omhandler. |
eventaction | Handlingen som er foretaget for at ændre registerdataene. Kan enten være "i" for insert, "u" for update, eller "d" for delete. |
datafordelerRegisterImportSequenceNumber | Registeret dataindlæsningspakke-sekvensnummer, der indeholder ændringen. |
datafordelerOpdateringstid | Tidspunktet hvor dataene (hændelsen) er blevet indsat i databasen hos Datafordeleren. |
fromfailedimport | Indikator for om hændelsen er fra en fejlet import, og derfor vil være en duplikat, for at anvendere kan håndtere det i deres løsninger. |
object_id | ID på registerdata-objektet som er opdateret. Genereret af registeret, hvis det findes for den specifikke entitet. |
object_datafordelerRowId | Identifikator for registerdata-objektet som hændelsen omhandler. Genereret af Datafordeleren. |
object_datafordelerRowVersion | Versionen for registerdata-objektet. Feltet starter med værdien 1 og stiger med 1 hver gang registeret opdaterer rækken. |
object_registreringfra | Den nye værdi af "registrering fra", fra hændelsens registerdata-objekt, der er blevet opdateret – forudsat at et sådant felt findes. |
object_registreringtil | Den nye værdi af "registrering til", fra hændelsens registerdata-objekt, der er blevet opdateret – forudsat at et sådant felt findes. |
object_status | Den nye værdi af status, fra hændelsens registerdata-objekt, der er blevet opdateret – forudsat at et sådant felt findes. |
object_virkningfra | Den nye værdi af "virkning fra", fra hændelsens registerdata-objekt, der er blevet opdateret – forudsat at et sådant felt findes. |
object_virkningtil | Den nye værdi af "virkning til", fra hændelsens registerdata-objekt, der er blevet opdateret – forudsat at et sådant felt findes. |
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
For at illustrere de praktiske anvendelsesmuligheder af Datafordelerens hændelsessystem, præsenteres her en række konkrete forretningsscenarier fra forskellige brancher og sektorer. Disse eksempler viser, hvordan organisationer kan udnytte hændelser til at automatisere forretningsprocesser, sikre datakvalitet og optimere deres it-systemer.
Scenarierne spænder fra offentlige myndigheder, der skal sikre regeloverholdelse og effektiv sagsbehandling, til private virksomheder der bruger realtidsdata til at forbedre kundeservice og risikostyring. Hvert scenarie beskriver både det forretningsmæssige behov og den konkrete tekniske implementering ved hjælp af moderniserede hændelser.
Disse eksempler kan bruges som inspiration til at identificere lignende anvendelsesmuligheder i din egen organisation og som vejledning til implementering af hændelsesbaserede løsninger.
Kommune – Byggesagsbehandling
Scenarie: En kommune skal automatisk opdatere deres byggesagssystem, når nye bygninger registreres, eller eksisterende bygninger ændres i BBR.
Implementering:
Wiki Markup Abonner på BBR_Bygning hændelser med eventaction: \["i", "u"\]- Ved modtagelse af hændelse, hent bygningsdata via GraphQL ved hjælp af object_datafordelerRowId fra hændelsen
- Automatisk opret eller opdater byggesag i kommunens system
- F.eks. ved en bitemporal update af en Byggesag, skal både en "Insert" og en "Update" hændelse hentes, for at opdatere anvenderens byggesagsystem
- Hvis kommunen har behov for at holde sig opdateret på personflytninger:
- Abonner på CPR_Hændelse med kommunekodefiltrering
- Ved modtagelse af hændelse, hent den faktiske data via GraphQL ved hjælp af object_id for CPR Public Sector
Selskabsskat - Virksomhedsovervågning
Scenarie: SKAT skal overvåge virksomhedsændringer for korrekt selskabsbeskatning og momsregistrering.
Implementering:
- Abonner på CVR_Virksomhed hændelser for alle virksomhedsændringer
- Ved modtagelse af hændelse, hent den faktiske virksomhedsdata via GraphQL ved hjælp af object_datafordelerRowId fra hændelsen
- Automatisk opdater skatteregistre ved ændring af:
- Virksomhedsform (personligt/aktieselskab)
- Aktivitetsområde (branchekoder)
- Adresse
It-serviceudbyder – Datasynkronisering
Scenarie: En it-leverandør skal holde flere kundesystemer synkroniserede med centrale registre.
Implementering:
...