...

Stamdata modulet (SDM) er udstillet på NSP, og består af flere komponenter. Der er . Den indeholder en række webservices, som tilbyder data-adgang til forskellige registre (enkeltopslag og udtræk af registre), og et dataopsamlings framework, bestående af parsere og importere, der henter data fra en række eksterne kildedataregistre, bl.a. CPR-registret og SKS. Nedenstående figur viser en principskitse over arkitekturen, hvor stamdata services er udstillet på den enkelte NSP instans.

...

Figur 1  – Stamdatamodulet opsamler data fra kilderegistre og udstiller data på NSP

Adgangen til de data der er beskyttet af en sikkerhedsprotokol er beskyttet af sikkerhedsprotokollen Den Gode Webservice (DGWS), og adgangskontrollen derudover styres adgangskontrol på basis af CVR-nummer.
Det er kun servicen personinformation der ikke er beskyttet af en sikkerhedsprotokol. Dette er en REST service der kun kan anvendes af komponenter på NSP'en.

I diagrammet nedenfor ses et arkitekturoverblik for Stamdata-servicen, med de forskellige services, som anvender data fra stamdata-databasen.  
Databasen opdateres med data af de forskellige importere og indlæsere. Yderligere dokumentation om disse findes her: Stamdataregistre og tilhørende datatyper.

3      Logisk Arkitektur

Den logiske arkitektur er opdelt i dataindsamling, replikering til NSP instanserne og udstilling af data gennem services. I de følgende afsnit beskrives disse elementer af arkitekturen.

3.1     Dataindsamling: Stamdata Importer og Parser

Stamdataregistret samler stamdata fra en række kilderegistre hos offentlige myndigheder. Indsamlingen af data implementeres i forhold til hvert enkelt kilderegister ved anvendelse af en registerspecifik Parser, men med anvendelse af en fælles Importer-komponent. Importer-komponenten kører på DoDi-platformen, og er ansvarlig for at indlæse dataset fra registerfiler, der placeres i en dedikeret mappe i filsystemet [1]. Hvert register har sin egen dedikerede mappe som automatisk bliver oprettet af Importer-komponenten.

[1] For hvert register implementeres en transportløsning (f.eks. FTP som push eller pull), der har som opgave at overføre ”rå” registerdata fra kilderegistret til NSP-platformen.

Importeren overvåger filsystemet og aktiverer de registerspecifikke parsere, når nye registerfiler er tilgængelige i filsystemet. De respektive parsere processerer registerfilerne og overfører registerdata til den lokale database. Parsningen kan i princippet bestå af en direkte dataoverførsel fra fil til database, men indeholder i de fleste tilfælde forretningslogik, f.eks. transformationer af data og denormaliseringer.

Hver mappe har tre undermapper:

• input: En inbox som jævnligt undersøges for nye filer
• processing: Indeholder filer som er ved at blive importeret
• rejected: Her placeres filer som ikke kunne importeres i tilfælde af fejl.

Image Removed

Figur 2 – Principskitse af et importforløb, hvor en parser aktiveres af importeren

3.2     Replikering til NSP-instanserne

Dataindsamlingen fra kilderegistrene foregår på DoDi (for yderligere information om NSP-konceptets komponenter henvises til den overordnede NSP-dokumentation).Image Removed

Figur 3 – principskite af envejs-replikeringen fra DoDi til NSP-instanserne

Stamdatatabellerne registreres i NSP’ens replikeringsmekanisme, og de parsede registerdata replikeres derfor automatisk ud til de enkelte NSP-instanser som illustreret på Figur 3, hvorfra de kan tilgås gennem de udstillede stamdataservices (ikke illustreret).

3.3     Etableringsudtræk og partielle udtræk af hele registre

...