Stamdataservicen på NSP
Design og Arkitektur

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.

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 udstilles via stamdata services er beskyttet af Den Gode Webservice (DGWS), og adgangskontrollen er styret på basis af CVR-nummer.

Fysisk arkitektur

DoDi'en er lavet på en sådan måde at hver stamdata importer er deployet i sin egen WAR-fil, dette gør at den er let at teste, distribuere og skalere, samtidig skal hver parser inkludere et stamdata-core bibliotek (jar fil), der sikrer at database håndtering, filhåndtering, konfigurationshåndtering og generel overvågning håndteres på en passende måde af en stamdata importer.
Stamdata Core bruger JNDI til at slå database forbindelsen op i applikationsserveren, derved sikres at database styring og pooling sker centralt i applikationsserveren.
Den gamle model hvor alle importere var samlet i samme kodebase, og deployet som en WAR-fil viste sig i praksis ikke at være håndterbar at teste og drifte.
Se nedenstående figur der viser en principskitse af de enkelte stamdata importere.
Figur 2 principskitse over stamdata importer WAR filer

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.

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 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.. Hvert register har sin egen dedikerede mappe som automatisk bliver oprettet af Importer-komponenten.
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 importer har sin egen mappe, en mappe kan indeholde en undermappe med registerfiler, eller en LOCKED fil. Importeren står og poller dens pågældende undermappe(r) for registerfiler, samhørende registerfiler skal ligge i en mappe for sig selv. Efter en cooldown tid, hvor importeren sikrer at filstørrelser ikke vokser mere bygynder den at parse filerne. Går alt godt bliver undermappen og filerne slettet igen, og data ligger nu i databasen. Går det skidt ligger der en LOCKED fil i importerens mappe – og en fejlbesked vil blive vist på overvågningssiden, når fejlen er udbedret kan LOCKED filen fjernes manuelt og registerfilerne vil så igen blive forsøgt importeret. Eksempel hvor der er sket en fejl under parsning af CPR-filer:
Mappe: CPR

• Undermappe: 20120630
  • Fil 1: D100312-L431101
  • Fil 2: D100312-L431101
• Fejl fil: LOCKED

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

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 4 – 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 4, hvorfra de kan tilgås gennem de udstillede stamdataservices (ikke illustreret).

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 5 – Enkeltopslagsservicen til autorisationsregistret og STS deler datagrundlag.

Fysiske Datamodeller

Datamodellen for hvert enkelt register i Stamdataservicen er defineret i bilaget 'schema.sql'. Nedenfor er registrene beskrevet overordnet i tabelform.

Doseringsforslag

CPR-registret

SKS-registret

SOR-registret

Yderregistret

Autorisationsregistret

DKMA-registret

Bemyndigelser

SOR-NPI relationer

Ændringslog

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