Opsætning af eget miljø

Introduktion

Denne side beskriver fokusområder, anvender skal være opmærksomme på når anvenderen opret sin database, forretningslogik, kontroller og hvad der ellers indgå i anvenderens miljø.

Opsætning af eget miljø

Ved opsætning af eget miljø, er der en række forhold man skal være opmærksom på. De åbenlyse er naturligvis at oprette tabeldefinitioner, der matcher de data man ønsker at have en kopi af, eventuelt suppleret med egne kontrol/metadata-felter, eksempelvis data for sidste opdatering i egen database.

Derudover er der to store fokusområder: Grunddataregister forretningslogik og teknologivalg.

Grunddataregister forretningslogik bør tænkes ind i opsætningen af eget miljø, eventuelt allerede ved indlæsning af data.

Langt de fleste både REST services og filudtræk leverer kun data fra et enkelt register, hvor anvendere typisk har behov for sammensat data på tværs af registre. Der er enkelte undtagelser, eksempelvis Ejerfortegnelsens *MedStamoplysninger tjenester, som leverer sammenhængende data på tværs af registrene. Det fremgår som regel af tjenestebeskrivelserne på Dataoversigten, hvilke registre der leveres data fra. Disse sammensatte tjenester er dog begrænset til kun at levere aktuelle data, så de kan ikke anvendes, hvis man har interesse i de bitemporale dimensioner.

For at anvende registerspecifikke tjenester skal anvendere derfor selv skal kende og kunne håndtere grunddataregistrenes forretningslogik. Dette omfatter forståelse for informationsmodellerne på data.gov.dk, nøglerne på forretningsobjekterne, referencerne mellem grunddataregistrene samt forståelse for – og forskellene i bitemporalitet mellem registrene. Forskellene i bitemporalitet er nærmere beskrevet på siden Datafordeleren - introduktion til bitemporalitet

Ud over denne designforskel på implementering af bitemporalitet, både i registrene og i tjenesterne, eksisterer der også data med overlap i de bitemporale dimensioner – Overlap, der skal håndteres af de enkelte anvendere, hvis der skal gøres fuld brug af de bitemporale dimensioner.

I relation til teknologivalg gøres der opmærksom på, at totaludtræk fra registrene har en anselig størrelse, så det anbefales at vælge værktøjer og teknologier, der er designet til håndtering af store datamængder. Datafordeleren tilbyder også deltafiler, hvor dataændringer identificeres via et Datafordeler tidsstempel for sidste ændring, men da flere registre jævnligt laver nye totalindlæsninger på Datafordeleren, bør anvendere vælge en teknologistak, der understøtter hyppige indlæsninger at store datamængder, eksempelvis et ETL værktøj.

Initial load af data

Initial load af data skal typisk ske via fil totaludtræk for de relevante data.

Totaludtræk kan enten hentes via et enkelt manuelt download, eller via et abonnement. Se mere om filudtræk i Guide til filudtræk på Selvbetjeningen.

Filerne er i enten JSON eller XML – det vælges, når filudtræk bestilles i Selvbetjeningen.

De enkelte filudtræk genereres af Datafordeleren og placeres på Datafordelerens ftp server, når det er dannet. Herefter modtager man en email om at filen er dannet – dette fremgår også af guiden.

Herefter skal filen downloades med ftp og indlæses i anvenderens eget miljø. Bemærk at totaludtræk for en række registre er struktureret på den måde at indholdet ligger tabelvis i filen, så der skal implementeres simpel logik der håndterer denne struktur ved indlæsning.

Opsætning af opdateringer, herunder opsætning af abonnement på Datafordeleren

Hvilke abonnementer, der er behov for, afhænger af de valgte tjenester og den ønskede opdateringsfrekvens.

Abonnementer kræver tjenestebrugere, som kan oprettes af organisationens webbruger - se mere om oprettelse af brugere 

• Guide til REST på Selvbetjeningen 

• Guide til filudtræk på Selvbetjeningen 

• Guide til hændelser på Selvbetjeningen

Hvis man vælger opdatering via hændelser, henledes opmærksomheden på at der er tale om datanære hændelser, generelt uden payload. Dette betyder at man som anvender, i umiddelbar forlængelse af modtagelsen af en hændelse, har behov for at hente det objekt hændelsen omhandler, via en passende REST service.