...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
Handlingsbaseret-filtrering
...
...
...
...
Kombineret filtrering
Eksempel ses i Figur 16.
- Betingelse: ObjektType = "Bygning"
- Betingelse: Objekthandling = "Create,Update"
| Wiki Markup |
|---|
where: \{
entityname: \{ eq: "Bygning" \}
eventaction: \{ in: \["i", "u"\] \}
\}
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="110a4247-6f45-4360-9a18-de2cb6d2b34e"><ac:parameter ac:name="">_Ref208481508</ac:parameter></ac:structured-macro>Figur 16: Eksempel på kombineret filtrering af Bygning og "Create" og "Insert" |
...
Afsnittet giver et eksempel på hvordan en eksisterende anvender på Datafordeleren kan overgå fra at bruge PUSH- og PULL-hændelser, til at bruge moderniserede hændelser. Eksemplerne her i transitionsguiden tager udgangspunkt i en anvender som ønsker hændelser for entiteten BBR_Bygning fra BBR-registeret.
...
Her henter anvenderen hændelsesbeskeder ved at kalde Datafordeleren, svarende til abonnering på hændelser beskrevet i afsnit 2.3.2 (Abonnement på hændelser). Afsnittet påbegyndes med en situationsbeskrivelse, efterfulgt af konkrete trin der beskriver transitionen.
Situationsbeskrivelse
| Wiki Markup |
|---|
Anvenderen har været inde og foretage filtrering på de hændelser, som Datafordeleren returnerer (se afsnittet om filtrering på *\[NUDAF-HAENDELSE-GUIDE\]{*}). Filtrering er sat op så der kun returneres hændelser for BBR_Bygning.
Anvenderen benytter følgende parametre: |
- DateFrom = 2025-06-21
- DateTo = 2025-07-21
- Format = json
- Page = 1
- PageSize = 100
Anvender har allerede en tjenestebruger, som abonnementet er relateret til. Det er vigtigt at bemærke, at anvenderen kun kan modtage hændelser der er opstået efter tidspunktet hvor abonnementet blev oprettet – hændelser fra før dette tidspunkt er ikke tilgængelige. Anvender bruger sin tjenestebruger til at kalde REST-tjenesterne på URL'en:
Transition
- Anvender tilgår følgende tjeneste med sin API-nøgle for at hente GraphQL-skemaet for BBR:
- Da anvender har dannet sig et overblik over GraphQL-skemaet og derfor ved hvilke queries der kan sendes for BBR, sender anvender nu query fra Figur 16 til URL'en nedenfor for at hente hændelser for BBR_Bygning med de ønskede oplysninger fra situationsbeskrivelsen:
| Wiki Markup |
|---|
\\
query \{
BBR_Events(
first: 100
where: \{
and: \[
\{ entityname: \{ eq: "Bygning" \} \},
\{ datafordelerOpdateringstid: \{ gte: "2025-06-21T00:00:00Z" \} \},
\{ datafordelerOpdateringstid: \{ lte: "2025-07-21T23:59:59Z" \} \}
\]
\}
) \{
pageInfo \{ hasNextPage endCursor \}
nodes \{
eventid entityname eventaction datafordelerRegisterImportSequenceNumber
datafordelerOpdateringstid fromfailedimport object_id object_datafordelerRowId
object_datafordelerRowVersion object_registreringfra object_registreringtil
object_status object_virkningfra object_virkningtil
\}
\}
\}
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="686cd0e1-6461-4afa-9178-305c3fadef00"><ac:parameter ac:name="">_Ref208481880</ac:parameter></ac:structured-macro>Figur 17: Eksempel på query for transition af BBR-hændelse |
- Anvender får nu et respons tilbage fra Datafordeleren der indeholder hændelser indenfor de specificerede kriterier i JSON-format som vist i Figur 18 (resultatet er kortet ned til kun at indeholde et eksempel på en hændelse).
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
