Illustration af Left Joins. Kilde: https://www.w3schools.com/sql/sql_join_left.asp
Med GraphQL-klient
Det anbefales at benytte et GraphQL-klient til at læse GraphQL-skemaerne, da det gør arbejdet med GraphQL-tjenesterne enklere at læse. Med et GraphQL-klient som Altair eller Nitro bliver sammensætningen af queries gjort enklere.
Eksempel på visning i GraphQL klient
Altair fungerer både som API-klient og GraphQL-klient. Med Altair kan du indlæse det hentede GraphQL-skema for den ønskede tjeneste ved at klikke på "Docs", derefter på "..."-knappen og vælge den relevante fil. Når GraphQL-skemaet er åbnet, kan man frit søge i dokumentationen på en let læselig måde.
Figur 4.2: Altair dokumentation
I eksemplet på figur [4.1] ønskes det at finde en relation fra DAR_Adresse til BBR_Enhed. For at gøre dette i Altair søger du på "DAR_Adresse" i Docs-vinduet.
Figur 4.3: Altair søgning
Derefter åbner du entiteten med typen QUERY og klikker på nodes for at se alle felter og relationer, som DAR_Adresse indeholder. Her kan du se, at der findes en relation til BBR_Enhed ved navn AdresseHarEnhed.
Figur 4.4: "ADD QUERY"-knappen i Altair
Alternativt kan du holde musen til højre for entitetsnavnet, hvor en "ADD QUERY"knap vises. Ved at klikke på denne knap udfyldes alle felter automatisk, og der genereres en gyldig query. Det eneste, der herefter skal tilpasses, er valg af underentiteter, registrerings og virkningstid samt paging.
Oversigt over registre
I nedenstående tabel er der en oversigt over hvilke registre der er tilgængelige i de forskellige tjenester samt om de er adgangsbegrænset. Denne oversigt er er god at bruge til beslutningen om hvilken tjeneste, du vil kalde, samt hvilke der kræver særtilladelser.
Register | flexible | flexibleCurrent | Adgangsbegrænset |
BBR | Ja | Ja | Nej |
CPR | Ja (uden joins) | Ja (uden joins) | Ja |
CVR | Nej | Ja | Nej (pånær CVRPerson |
DAGI | Ja | Ja | Nej |
DAR | Ja | Ja | Nej |
DHM Højdekurver | Ja | Ja | Nej |
DHM Oprindelse | Ja | Ja | Nej |
Danske Stednavne | Ja | Ja | Nej |
EBR | Ja | Ja | Nej |
EJF | Ja | Ja | Ja |
EJFCustom | Ja (uden PersonSimpel) | Ja | Ja |
Fikspunkter | Ja | Ja | Nej |
GeoDanmark Vektor | Ja | Ja | Nej |
MAT | Ja | Ja | Nej |
SVR | Ja | Ja | Ja |
VUR | Ja | Ja | Nej |
Tabel 4.5: Oversigt over registre
Authentication
Alle der vil bruge fleksibel opslagslogik skal være authenticated. For opsætning af authentication til fleksibel opslagslogik se authentication afsnittet under [GraphQL-Dokumentation].
Specielt for fleksibel opslagslogik
Da nogle entiteter har begrænset adgang, er det nødvendigt at ansøge om adgang til disse. Du kan både ansøge om adgang og se, hvilke entiteter der er adgangsbegrænsede, under "Dataadgang" i IT-systemet i Datafordeler Administration. Her vælger du det ønskede register samt de specifikke entiteter, du ønsker adgang til. Følgende registre indeholder entiteter med adgangsbegrænsning: CPR, CVR, EJF, EJFCustom og SVR. Dette krav om adgangsgodkendelse gjaldt også i den entitetsbaserede opslagslogik. Forskellen er, at det nu er muligt at joine mellem både ubegrænsede og begrænsede entiteter, så længe du har den nødvendige adgang til samtlige relevante entiteter. Skal du tilgå disse registre, kan dette ikke gøres ved brug af en API-nøgle. Grundet øget sikkerhedskrav, skal der anvendes Shared Secret. Opsætningen af Shared Secret forklares også i [GraphQL-Dokumentation].
Bitemporalitet i fleksibel opslagslogik
Bitemporalitet i fleksibel opslagslogik fungerer næsten på samme måde som i entitetsbaseret GraphQL. Hvis du ønsker at læse mere om, hvordan bitemporalitet fungerer, henvises der til confluence-siden [Bitemporalitet]. I fleksibel opslagslogik er det ikke er muligt at anvende relationer til CVR, EJFCustom_PersonSimpelAlt og EJFCustom_PersonSimpelBegrænset i det almindelige flexible-miljø, da disse entiteter ikke understøtter filtrering på registreringstid pga. krav fra registrene. De kan derfor udelukkende tilgås via flexibleCurrent-tjenesten.
Paging
For fleksibel opslagslogik fungerer pagingpå præcis samme måde som i de entitetbaserede GraphQL-tjenester. Der henvises derfor til [GraphQL-Dokumentation] for en dybdegående forklaring af paging. Dette afsnit vil kun tage udgangspunkt i, hvad der er nyt for fleksibel opslagslogik.
PageInfo for underentiteter
I [GraphQL-dokumentationen] nævnes det, at du kan hente pageInfo på entiteter med én-til-mange-relationer. Det samme gælder for underentiteter. Det anbefales stærkt at benytte pageInfo både for over- og underentiteter, da det giver det bedst mulige overblik over data og paging.
Querien i figur [7.1] nedenunder er lavet uden filtrering (where-klausul) for at understrege vigtigheden af pageInfo. I querien hentes der 10 resultater fra overentiteten DAR_Adresse og kun 1 resultat fra underentiteten BBR_Enhed gennem én-til-mange joinet AdresseHarEnhed.
{
DAR_Adresse(
first: 10
virkningstid: "2025-01-23T10:39:04.658307Z"
where: {}
) {
pageInfo {
hasNextPage
endCursor
}
nodes {
adressebetegnelse
bygning
doerbetegnelse
doerpunkt
etagebetegnelse
forretningshaendelse
forretningsomraade
forretningsproces
husnummer
id_lokalId
id_namespace
AdresseHarEnhed(first: 1)
{
pageInfo {
hasNextPage
endCursor
}
nodes {
adresseIdentificerer
bygning
id_lokalId
forretningsproces
forretningsomraade
forretningshaendelse
}
}
}
}
}
Kode 7.1: Én-til-mange relation med få resultater
Hvis du så forestiller dig, at man gerne vil have alle resultaterne ud, hvor der er mere end én enhed på en adresse, så giver denne query ikke nok resultater. Du vil i dit resultat kun få ét resultat pr. adresse, og det vil derfor ikke være det korrekte resultat, som du henter ud. I figur [7.2], kan man se, hvordan pageInfo belyser dette.
{
"adressebetegnelse": "Spindelvej 11, Guderup, 6430 Nordborg",
"bygning": null,
"doerbetegnelse": "",
"doerpunkt": null,
"etagebetegnelse": "",
"forretningshaendelse": "2",
"forretningsomraade": "54.15.10.08",
"forretningsproces": "0",
"husnummer": "ba5a9150-df2c-48f6-84bd-47092e1b573e",
"id_lokalId": "00009b67-504c-4fe0-b1d1-39126722df0f",
"id_namespace": "http://data.gov.dk/dar/adresse",
"AdresseHarEnhed": {
"pageInfo": {
"hasNextPage": true,
"endCursor": "TjJabE16RmhOR010WVRrMU1DMDBOemMxTFRoa09EUXRZVFZrTWpKa01qUTJaalUyO01qQXlNeTB3T1MweU0xUXdPVG95TlRvMU9TNHlOamt3T0RJd0t6QXdPakF3O01qQXlNeTB3T1MweU0xUXdPVG95TlRvMU9TNHlOamt3T0RJd0t6QXdPakF3"
},
"nodes": [
{
"adresseIdentificerer": "00009b67-504c-4fe0-b1d1-39126722df0f",
"bygning": "2fa95df9-3f96-46ad-953f-39fe744fc2f3",
"id_lokalId": "7fe31a4c-a950-4775-8d84-a5d22d246f56",
"forretningsproces": "0",
"forretningsomraade": "54.15.05.05",
"forretningshaendelse": null
}
]
}
},
Kode 7.2: Resultat af query fra figur [7.1]
Fordi du bruger pageinfo på underentiteten, kan du se, at "hasNextPage" er true. Det vil sige, at der findes flere resultater, end der er vist. Var pageInfo ikke blevet inkluderet i querien, så ville du ikke vide, at du manglede resultater.
Fejlkoder
Dette afsnit vil gennemgå de fejlkoder, en anvender af fleksibel opslagslogik vil kunne støde på og dermed skabe en forståelse for hvilke type fejl, du kan møde samt hvordan disse løses.
Det bør nævnes, at hvis du som anvender ikke har lavet opt-in på moderne HTTP koder i din API- eller GraphQL-klient eller din browser, vil du ikke altid modtage en fejlkode på din forespørgsel. Du vil i stedet modtage HTTP-kode OK-200. Korrekte fejlkoder er vigtige, da det er sådan systemer bygget på fleksibel opslagslogik vil kunne flage, at der er en fejl.
Maksimalt antal joins overskredet
En ny type fejl anvendere kan møde er 400 Bad Request med beskrivelsen: "The request exceeds the max allowed number of joins. The max allowed number of joins in a single request is 20." (Se eksempel nedenunder)
Figur 8.1: Fejlkode for maksimalt antal joins overskredet
Denne fejl opstår, fordi der som nævnt – på trods af muligheden for at lave joins og sammensætte data i fleksibel opslagslogik – er indført en begrænsning for at undgå overbelastning af systemet og sikre god ydeevne. Som tidligere nævnt er grænsen sat til 17 joins i alt eller 7 joins i dybden. Hvis du modtager denne fejl, skyldes det, at man har overskredet det tilladte antal joins i en enkelt request. Der er to løsninger på dette problem:
- Du kan konsekvent fjerne unødvendige joins.
- Du kan opdele forespørgslen i flere mindre forespørgsler.
Det bør altid vurderes for hver request om anvenderne har brug for al dataen og om nogle dele kan udelades.
Anvender har ikke adgang til denne ressource
I entitetsbaseret GraphQL kan du kun tilgå en entitet ad gangen, hvilket gjorde det tydeligt, om du hvade adgang til en given entitet eller ej. Med fleksibel opslagslogik er det nu muligt at joine til entiteter, som du ikke nødvendigvis har adgang til. Hvis dette sker, vil en query ikke altid resultere i en 401 Unauthorized-fejl, men kan i stedet returnere en 200 OK-status med beskeden: "The current user is not authorized to access this resource." Se eksempel nedenfor:
Figur 8.2: Fejlkode for ingen adgang til ressource
Den returnerer kun HTTP kode OK-200, hvis ikke man har lavet opt-in til moderne HTTP koder.
Specielt for flexibleCurrent tjenesten
I entitetsbaseret GraphQL har du tidligere kunnet foretage forespørgsler direkte mod hvert registers egne endepunkter. I fleksibel opslagslogik skal man være opmærksom på forskellen mellem flexible- og flexibleCurrent-tjenesterne. I flexible-tjenesten skal der filtreres både på registreringstid og virkningstid. Forsøger du at anvende queries fra flexible-tjenesten direkte på flexibleCurrent-tjenesten, vil du få fejlen: "The argument 'registreringstid' does not exist". (Se figur [8.3]).
Figur 8.3: Registreringstid findes ikke
I eksemplet forsøges der at blive kaldt en query for DAR_Adresse, på flexibleCurrent-tjenesten med registreringstid udfyldt, da man vil joine til en CVR entitet. Da parameteren registreringstid ikke findes i flexibleCurrent, svarer serveren med HTTP-status 400 Bad Request. Løsningen på dette problem er blot at fjerne parameteren registreringstid fra forespørgslen.
Specielt for flexible tjenesten
I flexible-tjenesten er det ikke muligt at forespørge på alle CVR-entiteter samt EJFCustom_PersonSimpelAlt og EJFCustom_PersonSimpelBegrænset. Dette er tidligere nævnt, men dette afsnit beskriver, hvilken fejlmeddelelse du vil få i sådanne tilfælde. I eksemplet nedenfor forsøges det at kalde en query for CVR på flexible-endepunktet i stedet for flexibleCurrent:
Figur 8.4: Entitet findes ikke
Her vil man modtage en HTTP 400 Bad Request med beskeden: "The field '{entitet}' does not exist on the type 'Query'." Som løsning bør du altid først kontrollere, om entitetens navn er stavet korrekt, da entitetsnavne er case sensitive og selv små stavefejl kan forårsage fejl. Hvis du er sikker på, at queryen er korrekt skrevet, bør du derefter sikre sig, at du kalder den rette tjeneste. Er du sikker på, at du kalder den korrekte tjeneste, bør du undersøge om, at dit kald er tilladt. Dette kan du finde ud af i den givne tjenestes GraphQL-skema.
Transition og eksempel på anvendelse
Denne sektion går i dybden med, hvordan du som anvender kan overgå til fleksibel opslagslogik, og indeholder et eksempel på, hvordan en REST-tjeneste kan oversættes til en GraphQL-forespørgsel, der viser anvendelsen af fleksibel opslagslogik i praksis. Eksemplet kommer fra et dokument på Confluence, som Datafordeleren har lavet, for at vise, hvordan de top 10 mest anvendte REST-tjenester kan oversættes til GraphQL tjenester. Resten af oversættelserne kan findes her: [GraphQL-Queries].
Overgangen fra REST-tjenester til GraphQL-tjenester
Med entitetsbaseret GraphQL har det hidtil været vanskeligt at hente større mængder sammenhængende data ad gangen. Her har du som anvender skulle lave flere forskellige kald, for at få samme mængde data som i REST-tjenesterne. Med indførelsen af fleksibel opslagslogik bliver det nu muligt at oversætte REST-tjenester direkte til GraphQL. For nogle REST-kald, der anvender mere end 7 joins i dybden eller 17 joins i alt for at sammensætte data, vil det dog være nødvendigt at opdele forespørgslerne i flere GraphQL-queries. En væsentlig fordel ved GraphQL er, at du nu selv kan vælge præcis, hvilke felter og relationer, der skal returneres. Hvor REST-tjenester returnerer alle, kan du i GraphQL frit fravælge uønskede felter og relationer. Det betyder, at man kun henter den data, man reelt har brug for, hvilket kan minimere behovet for efterfølgende datarensning og øge effektiviteten i dataudtrækket.
Det er vigtigt at nævne, at planen er, at GraphQL-tjenesterne skal erstatte REST-tjenesterne, og at REST-tjenesterne vil blive udfaset og gjort utilgængelige i fremtiden. Planen for dette vil være, at der vil være paralleldrift med både REST og GraphQL-tjenester, hvorefter REST-tjenesten vil blive lukket. Du bør derfor allerede nu overveje at oversætte de tjenester, du benytter, til GraphQL. Hvis oversættelsen ikke sker i tide, vil dune risikere at miste adgang til de tjenester, du er afhængig af, hvilket kan få konsekvenser for systemer, der baserer sig på disse data.
For at gøre overgangen til GraphQL så enkel som mulig, anbefales det kraftigt, at dune anvender et GraphQL-klient. I afsnittet [4.2] om GraphQL-skemaer gennemgås, hvordan GraphQL-skemaerne læses, og hvorfor det er en fordel at benytte et GraphQL-klient.
Eksempel på oversættelse af REST-tjeneste til GraphQL-query
I dette afsnit gennemgås et eksempel på, hvordan en nuværende REST-tjeneste kan oversættes til GraphQL-queries. Formålet med eksemplet er at vise, hvordan du som anvender kan konvertere REST-tjenester til GraphQL-queries og dermed få inspiration til at udforme egne queries. Det er også vigtigt at fremhæve, at du ikke længere er bundet af REST-tjenesternes struktur. Så længe relationerne i relationsbilagene tillader det, kan du nu sammensætte queries, der præcist matcher dine behov. Det åbner mulighed for at opbygge 'egne' tjenester, hvilket ikke tidligere var muligt.
Alle oversættelserne i [GraphQL-Queries] er lavet baseret på pseudo-SQL'en fra Dataleverancespecifikationen (DLS). SQL'en kan findes på [DLS-Udstilling] i ZIP-filerne. Vil du oversætte en REST-tjeneste, som du anvender, kan du bruge SQL'en som udgangspunkt og oversætte så vidt muligt.
Eksempel: Oversættelse af REST-Tjenesten BBRSag
I figur [10.1] oversættes REST-tjenesten for BBRSag. For tjenesten BBRSag ser pseudo-SQL'en for tjenesten således ud:
SELECT BBRSagSource.*, SagsniveauSource.* FROM BBRSag AS BBRSagSource
LEFT JOIN Sagsniveau AS SagsniveauSource ON SagsniveauSource.byggesag = BBRSagSource.id_lokalId
WHERE (@Id = NULL OR BBRSagSource.id_lokalId In @Id)
AND (@VirkningFra = NULL OR BBRSagSource.virkningTil = NULL OR @VirkningFra < BBRSagSource.virkningTil)
AND (@VirkningTil = NULL OR BBRSagSource.virkningFra = NULL OR @VirkningTil >= BBRSagSource.virkningFra)
AND (@Virkningsaktoer = NULL OR BBRSagSource.virkningsaktoer = @Virkningsaktoer)
AND (@RegistreringFra = NULL OR BBRSagSource.registreringTil = NULL OR @RegistreringFra < BBRSagSource.registreringTil)
AND (@RegistreringTil = NULL OR BBRSagSource.registreringFra = NULL OR @RegistreringTil >= BBRSagSource.registreringFra)
AND (@Registreringsaktoer = NULL OR BBRSagSource.registreringsaktoer = @Registreringsaktoer)
AND (@Status = NULL OR BBRSagSource.status IN @Status)
AND (@Forretningsproces = NULL OR BBRSagSource.forretningsproces = @Forretningsproces)
AND (@Forretningsomraade = NULL OR BBRSagSource.forretningsomraade = @Forretningsomraade)
AND (@Forretningshaendelse = NULL OR BBRSagSource.forretningshaendelse = @Forretningshaendelse)
AND (@Kommunekode = NULL OR BBRSagSource.Kommunekode = @Kommunekode)
AND (@DAFTimestampFra = NULL OR @DAFTimestampFra <= BBRSagSource.UpdateTimestamp())
AND (@DAFTimestampTil = NULL OR @DAFTimestampTil > BBRSagSource.UpdateTimestamp())
AND (@Bygning = NULL OR SagsniveauSource.stamdataBygning = @Bygning OR SagsniveauSource.sagsdataBygning = @Bygning)
AND (@Enhed = NULL OR SagsniveauSource.stamdataEnhed = @Enhed OR SagsniveauSource.sagsdataEnhed = @Enhed)
AND (@Etage = NULL OR SagsniveauSource.stamdataEtage = @Etage OR SagsniveauSource.sagsdataEtage = @Etage)
AND (@Grund = NULL OR SagsniveauSource.stamdataGrund = @Grund OR SagsniveauSource.sagsdataGrund = @Grund)
AND (@Opgang = NULL OR SagsniveauSource.stamdataOpgang = @Opgang OR SagsniveauSource.sagsdataOpgang = @Opgang)
AND (@TekniskAnlaeg = NULL OR SagsniveauSource.stamdataTekniskAnlaeg = @TekniskAnlaeg OR SagsniveauSource.sagsdataTekniskAnlaeg = @TekniskAnlaeg)
AND (
@PeriodeaendringFra = NULL
OR
@PeriodeaendringTil = NULL
OR (
BBRSagSource.Id_lokalId IN
(
SELECT DISTINCT BBRSagChanges.Id_lokalId FROM BBRSag AS BBRSagChanges
WHERE BBRSagChanges.Id_lokalId IN
(
SELECT DISTINCT BS.Id_lokalId FROM BBRSag AS BS
WHERE
(BS.registreringFra >= @PeriodeaendringFra AND BS.registreringFra <= @PeriodeaendringTil)
OR
(BS.registreringTil >= @PeriodeaendringFra AND BS.registreringTil <= @PeriodeaendringTil)
)
UNION
SELECT DISTINCT SagsniveauChanges.byggesag FROM Sagsniveau AS SagsniveauChanges
WHERE SagsniveauChanges.Id_lokalId IN
(
SELECT DISTINCT SN.id_lokalId FROM Sagsniveau AS SN
WHERE
(SN.registreringFra >= @PeriodeaendringFra AND SN.registreringFra <= @PeriodeaendringTil)
OR
(SN.registreringTil >= @PeriodeaendringFra AND SN.registreringTil <= @PeriodeaendringTil)
)
)
AND BBRSagSource.virkningTil = NULL
AND
(
(
@KunNyesteIPeriode = FALSE
AND
BBRSagSource.registreringFra <= @PeriodeaendringFra AND (BBRSagSource.registreringTil > @PeriodeaendringFra OR BBRSagSource.registreringTil = NULL)
AND
(
SagsniveauSource.id_lokalId = NULL OR
(
SagsniveauSource.virkningTil = NULL AND
SagsniveauSource.registreringFra <= @PeriodeaendringFra AND (SagsniveauSource.registreringTil > @PeriodeaendringFra OR SagsniveauSource.registreringTil = NULL)
)
)
)
OR
(
BBRSagSource.registreringFra <= @PeriodeaendringTil AND (BBRSagSource.registreringTil > @PeriodeaendringTil OR BBRSagSource.registreringTil = NULL)
AND
(
SagsniveauSource.id_lokalId = NULL OR
(
SagsniveauSource.virkningTil = NULL AND
SagsniveauSource.registreringFra <= @PeriodeaendringTil AND (SagsniveauSource.registreringTil > @PeriodeaendringTil OR SagsniveauSource.registreringTil = NULL)
)
)
)
)
))
Kode 10.1: Pseudo-SQL for REST-tjenesten BBRSag
I pseudo SQL-querien henter man alt fra tabellerne BBRSag og BBRSagsniveau og filtrerer på flere parametre. For simplificering er næsten alle disse parametre udeladt og de bitemporale felter håndteres af registreringstid og virkningstid parametrene i GraphQL.
Med entitetsbaseret GraphQL var du nødt til at lave to separate GraphQL-kald for at oversætte denne tjeneste. Et kald for at få BBR_BBRSag entiteten og et kald for at få BBR_Sagsniveau. Så skulle du selv manuelt sammensætte dataen i et system. Med fleksibel opslagslogik er det muligt at joine direkte på sin entitet.
For at lave dette join skal vi først i GraphQL-skemaet finde ud af, hvad relationen hedder. I dette eksempel har relationen et sigende navn, og den var derfor nem at finde. Relationen ser således ud i GraphQL-skemaet:
Bruger man i stedet et GraphQL-klient vil det fremstå under BBR_BBRSag entiteten. Da BBR entiteten indgår i flexible tjenesten kalder vi vores request fra følgende URL:
https://graphql.datafordeler.dk/
flexible/v1?apikey={apikey}
Nu hvor relationen kendes, kan GraphQL-querien opbygges.
{
BBR_BBRSag(
first: 10
registreringstid: "2025-03-28T22:12:56.184158Z"
virkningstid: "2025-11-14T11:28:27.184158Z"
where: {
status: { in
: [
"11", "12"] }
kommunekode: { eq: "0101" }
}
)
Kode 10.2: Første del af BBRSag i GraphQL
Queries er opbygget sådan, at du tager udgangspunkt i overentiteten BBR_BBRSag. Du anvender "first"-parameteren for at begrænse søgningen til de første 10 resultater. Da du kalder flexible-tjenesten skal du benytte de bitemporale felter registreringstid og virkningstid til at filtrere data. Derudover tilføjes valgfrie klausuler, hvor du i dette tilfælde ønsker at hente alle resultater med statuskode 11 eller 12 med kommunekode 0101.
{
pageInfo {
hasNextPage
endCursor
}
Kode 10.3: Paging info
I næste del hentes paging informationer, hvilket gør det lettere for anvenderen at holde overblik over de hentede data. Da "first"-parameteren er sat til kun at vise 10 resultater, kan der være yderligere data på næste side, som ikke vises i det aktuelle udtræk. Det anbefales altid at medtage paginginformationer i sine queries.
nodes {
datafordelerOpdateringstid
datafordelerRegisterImportSequenceNumber
datafordelerRowId
datafordelerRowVersion
forretningshaendelse
forretningsomraade
forretningsproces
id_lokalId
id_namespace
kommunekode
registreringFra
registreringsaktoer
registreringTil
sag001Byggesagsnummer
sag002Byggesagsdato
sag003Byggetilladelsesdato
sag004ForventetPaabegyndelsesdato
sag005Paabegyndelsesdato
sag006IbrugtagningsTilladelse
sag007Henlaeggelse
sag008FaerdigtBygningsareal
sag009ForventetFuldfoertDato
sag010FuldfoerelseAfByggeri
sag012Byggesagskode
sag013AnmeldelseAfByggearbejde
sag016DelvisIbrugtagningsTilladelse
sag017ForeloebigFaerdiggjortBygningsareal
sag018ForeloebigFaerdiggjortAntalLejligheder
sag019Bygherreforhold
sag024DatoForModtagelseAfAnsoegningOmByggetilladelse
sag025DatoForFyldestgoerendeAnsoegning
sag026DatoForNaboorientering
sag027DatoForFaerdigbehandlingAfNaboorientering
sag032Litra
sag033ForeloebigFaerdiggjortAntalLejlighederUdenKoekken
status
virkningFra
virkningsaktoer
virkningTil
bbrSagErTilknyttetSagsniveau(
first: 10
) {
pageInfo {
hasNextPage
endCursor
}
nodes {
datafordelerOpdateringstid
byggesag
forretningshaendelse
forretningsomraade
forretningsproces
id_lokalId
id_namespace
kommunekode
niveautype
registreringFra
registreringsaktoer
registreringTil
sagsdataBygning
sagsdataEnhed
sagsdataEtage
sagsdataGrund
sagsdataOpgang
sagsdataTekniskAnlaeg
sagstype
stamdataBygning
stamdataEnhed
stamdataEtage
stamdataGrund
stamdataOpgang
stamdataTekniskAnlaeg
status
virkningFra
virkningsaktoer
virkningTil
}
}
Kode 10.4: Nodes til BBRSag i GraphQL
Så henter du alle nodes ind. Nodes er der, hvor der bør udfyldes, hvilke felter du ønsker returneret som svar. I pesudo-SQL'en er der "Select *" og du ønsker derfor alle felter ud. Som noget nyt i fleksibel opslagslogik kan du som nævnt lave joins og det vil ske i nodes. Her har vi joinet bbrSagErTilknyttetSagsniveau. Opstillingen af underentiteten vil være på præcis samme måde som opstillingen af en overentitet med undtagelse af, at du ikke kan indstille registreringstid eller virkningstid, da disse arves fra overentiteten. Den samlede query vil så ende med at se således ud:
{
BBR_BBRSag(
first: 10
registreringstid: "2025-03-28T22:12:56.184158Z"
virkningstid: "2025-11-14T11:28:27.184158Z"
where: {
status: { in
: [
"11", "12"] }
kommunekode: { eq: "0101" }
}
) {
pageInfo {
hasNextPage
endCursor
}
nodes {
datafordelerOpdateringstid
datafordelerRegisterImportSequenceNumber
datafordelerRowId
datafordelerRowVersion
forretningshaendelse
forretningsomraade
forretningsproces
id_lokalId
id_namespace
kommunekode
registreringFra
registreringsaktoer
registreringTil
sag001Byggesagsnummer
sag002Byggesagsdato
sag003Byggetilladelsesdato
sag004ForventetPaabegyndelsesdato
sag005Paabegyndelsesdato
sag006IbrugtagningsTilladelse
sag007Henlaeggelse
sag008FaerdigtBygningsareal
sag009ForventetFuldfoertDato
sag010FuldfoerelseAfByggeri
sag012Byggesagskode
sag013AnmeldelseAfByggearbejde
sag016DelvisIbrugtagningsTilladelse
sag017ForeloebigFaerdiggjortBygningsareal
sag018ForeloebigFaerdiggjortAntalLejligheder
sag019Bygherreforhold
sag024DatoForModtagelseAfAnsoegningOmByggetilladelse
sag025DatoForFyldestgoerendeAnsoegning
sag026DatoForNaboorientering
sag027DatoForFaerdigbehandlingAfNaboorientering
sag032Litra
sag033ForeloebigFaerdiggjortAntalLejlighederUdenKoekken
status
virkningFra
virkningsaktoer
virkningTil
bbrSagErTilknyttetSagsniveau(
first: 10
) {
pageInfo {
hasNextPage
endCursor
}
nodes {
datafordelerOpdateringstid
byggesag
forretningshaendelse
forretningsomraade
forretningsproces
id_lokalId
id_namespace
kommunekode
niveautype
registreringFra
registreringsaktoer
registreringTil
sagsdataBygning
sagsdataEnhed
sagsdataEtage
sagsdataGrund
sagsdataOpgang
sagsdataTekniskAnlaeg
sagstype
stamdataBygning
stamdataEnhed
stamdataEtage
stamdataGrund
stamdataOpgang
stamdataTekniskAnlaeg
status
virkningFra
virkningsaktoer
virkningTil
}
}
}
}
}
Kode 10.5: Fulde query for BBRSag
Svaret på querien vil så have medtaget alle felter fra querien. Hvis underentiteten er tom, er det fordi, at der ikke er nogen data på denne. Ønsker du at kalde denne i flexibleCurrent, skal med fjerne registreringstids parameteren.
{
"data": {
"BBR_BBRSag": {
"pageInfo": {
"hasNextPage": true,
"endCursor": "TURBd05qVXlaVEl0WVRBNU9TMDBZbVUyTFdFellqWXRaV1pqTkRRM05XRXpNREZpO01qQXhPQzB3TWkweE5sUXhOem8xT0Rvd01DNHdNREF4TVRrd0t6QXdPakF3O01qQXhOaTB4TWkwd01WUXhNVG95TXpveU15NDFNVGN3TURBd0t6QXdPakF3"
},
"nodes": [
{
"datafordelerOpdateringstid": "2021-04-04T05:39:13.568817Z",
"datafordelerRegisterImportSequenceNumber": 1857504,
"datafordelerRowId": "5d7438ad-5415-4764-9602-eaab858134a6",
"datafordelerRowVersion": 1,
"forretningshaendelse": "Byggesag",
"forretningsomraade": "54.15.05.05",
"forretningsproces": "11",
"id_lokalId": "000652e2-a099-4be6-a3b6-efc4475a301b",
"id_namespace": "http://data.gov.dk/bbr/bbrsag",
"kommunekode": "0101",
"registreringFra": "2018-02-16T17:58:00.000119Z",
"registreringsaktoer": "BBR",
"registreringTil": null,
"sag001Byggesagsnummer": "443870",
"sag002Byggesagsdato": null,
"sag003Byggetilladelsesdato": null,
"sag004ForventetPaabegyndelsesdato": null,
"sag005Paabegyndelsesdato": null,
"sag006IbrugtagningsTilladelse": null,
"sag007Henlaeggelse": null,
"sag008FaerdigtBygningsareal": null,
"sag009ForventetFuldfoertDato": null,
"sag010FuldfoerelseAfByggeri": null,
"sag012Byggesagskode": "3",
"sag013AnmeldelseAfByggearbejde": null,
"sag016DelvisIbrugtagningsTilladelse": null,
"sag017ForeloebigFaerdiggjortBygningsareal": null,
"sag018ForeloebigFaerdiggjortAntalLejligheder": null,
"sag019Bygherreforhold": null,
"sag024DatoForModtagelseAfAnsoegningOmByggetilladelse": "2011-01-13T23:00:00.000000Z",
"sag025DatoForFyldestgoerendeAnsoegning": null,
"sag026DatoForNaboorientering": null,
"sag027DatoForFaerdigbehandlingAfNaboorientering": null,
"sag032Litra": "",
"sag033ForeloebigFaerdiggjortAntalLejlighederUdenKoekken": null,
"status": "11",
"virkningFra": "2016-12-01T11:23:23.517000Z",
"virkningsaktoer": "Konvertering2017",
"virkningTil": null,
"bbrSagErTilknyttetSagsniveau": {
"pageInfo": {
"hasNextPage": false,
"endCursor": "TWpRM01qY3dZamd0TldVMFpDMDBaRE0yTFdJMVkyWXRNVGhqWm1KbU56TTFZelZoO01qQXhOeTB3Tmkwd01sUXhNam95T1Rvek55NHdNREF3TURBd0t6QXdPakF3O01qQXhOaTB4TWkwd01WUXhNVG95TXpveU15NDFNVGN3TURBd0t6QXdPakF3"
},
"nodes": [
{
"datafordelerOpdateringstid": "2021-04-06T11:55:49.595558Z",
"byggesag": "000652e2-a099-4be6-a3b6-efc4475a301b",
"forretningshaendelse": "Byggesag",
"forretningsomraade": "54.15.05.05",
"forretningsproces": "0",
"id_lokalId": "247270b8-5e4d-4d36-b5cf-18cfbf735c5a",
"id_namespace": "http://data.gov.dk/bbr/sagsniveau",
"kommunekode": "0101",
"niveautype": "1",
"registreringFra": "2017-06-02T12:29:37.000000Z",
"registreringsaktoer": "BBR",
"registreringTil": null,
"sagsdataBygning": null,
"sagsdataEnhed": null,
"sagsdataEtage": null,
"sagsdataGrund": "304b8453-8212-407d-86d6-681c3faefd60",
"sagsdataOpgang": null,
"sagsdataTekniskAnlaeg": null,
"sagstype": "0",
"stamdataBygning": null,
"stamdataEnhed": null,
"stamdataEtage": null,
"stamdataGrund": "7e86c455-17d3-4d13-ae7f-24367d6966fc",
"stamdataOpgang": null,
"stamdataTekniskAnlaeg": null,
"status": "9",
"virkningFra": "2016-12-01T11:23:23.517000Z",
"virkningsaktoer": "BBR",
"virkningTil": null
}
]
}
}
]
}
}
}
Kode 10.6: Resultat fra query (begrænset til "first: 1")