1      Formål

Nærværende dokument giver et overblik over stamdataservicen med fokus på design og arkitektur. Dokumentet har som formål at give et indblik i det underliggende design, de udstillede snitflader på det overordnede niveau samt særlige forhold vedrørende de udstillede registre. Både aftagere af stamdataservicen, kildedataleverandører samt NSP operatør/driftsleverandør kan med fordel læse dette dokument.

2      Arkitekturoverblik

Stamdata modulet (SDM) er udstillet på NSP, og består af flere komponenter. Der er 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 Den Gode Webservice (DGWS), og adgangskontrollen styres på basis af CVR-nummer. Det er kun servicen cprexists der ikke er beskyttet af en sikkerhedsprotokol. Dette er en REST service der kun kan anvendes af komponenter på NSP'en.

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.

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).

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

Stamdataregistret giver mulighed for dels enkeltopslag i de tilknyttede registre, dels mulighed for udtræk af hele registre til opbevaring og anvendelse i den lokale infrastruktur. Disse services beskrives i de følgende afsnit.

3.3.1      Kopiregisterservicen

Der kan foretages komplette registerudtræk ved anvendelse af Kopiregisterservicen (KRS), der er en identitetsbaseret DGWS webservice udstillet på NSP-platformen.

Kopiregisterservicen giver dels mulighed for etableringsudtræk, hvor det komplette register leveres [2], dels såkaldte ”delta-opdateringer”, hvor ændringer i registret siden sidste udtræk leveres. De to typer udtræk er varianter af samme kald, hvor et etableringsudtræk leverer summen af samtlige ændringer i det pågældende registers levetid, og hvor et deltaudtræk leverer summen af ændringer siden sidste kald.

[2] Da registrene kan være af en størrelse, der gør det uhensigtsmæssigt at lave et komplet udtræk i et enkelt kald til KRS, gennemføres det komplette udtræk typisk ved en række på hinanden følgende kald. Dette er dog en teknisk detalje.

Figur 4 – Kopiregisterservicen udstiller snitflader til udtræk af registre

Til at styre hvilke klienter der har adgang til de respektive registre i Stamdata findes der en rettighedstabel. Tabellen opdateres af driftsoperatøren. Der henvises til driftsguiden for en detaljeret beskrivelse af rettighedstildeling.

3.3.2 Fleropslagsservicen

Der kan foretages registerudtræk af et antal objekter ad gangen ved anvendelse af Registerfleropslagsservicen (RFS), der er en identitetsbaseret DGWS webservice udstillet på NSP-platformen. Fleropslagsservicen er en variant af kopiregisterservicen, og følger samme struktur som denne. Der anvendes samme rettighedstildeling som til SKRS.

3.4     Enkeltopslagsservices

For udvalgte registre er der implementeret såkaldte enkeltopslagsservices, der, som navnet antyder, giver mulighed for opslag på enkeltregistreringer i de respektive registre. Alle enkeltopslagsservices implementeres som identitetsbaserede web services.

Figur 5 – Stamdataservicen udstiller snitflader til enkeltopslag for udvalgte registre

Stamdataservicen stiller følgende enkeltopslagsservices til rådighed:

For yderligere information om enkeltopslagsservices henvises til anvenderguiden, der indgår på lige fod med nærværende dokument i den samlede dokumentations­pakke for stamdataservicen.

Udover de nævnte enkeltopslagsservices eksisterer der også en REST service kaldet cprexists. Denne service kan anvendes, af NSP komponenter, til at verificere om et CPR nummer eksisterer samt stille en person status til rådighed..

4      Særlige forhold

Stamdataservicen anvender en række tabeller til at opbevare stamdataregistrene. Disse tabeller er typisk koblet relativt hårdt op mod kilderegistrenes struktur, og tidligere erfaringer har vist, at der med jævne mellemrum forekommer ændringer i kilderegistrene. Det er derfor forsøgt undgået at andre (NSP-) komponenter end stamdataservicen anvender stamdatatabellerne. Hvor andre komponenter har behov for at anvende stamdata internt på NSP, kopieres data ud i separate tabeller, som komponenterne kan bruge i stedet.

På NSP 2.0 anvendes autorisationsregistrets data af STS (til berigelse og verifikation af autorisationsnummer), og der er derfor oprettet en særlig Autorisationstabel til dette formål som illustreret på figuren nedenfor.

Figur 8 – Enkeltopslagsservicen til autorisationsregistret og STS deler datagrundlag.

5      Fysiske Datamodeller

Der henvises til arkitekturdokumentationen for en oversigt over de fysiske datamodeller for stamdataregistrene.

6      Ændringslog

Kilden til dette dokument kan kan erhverves ved henvendelse til NSP-operatøren.