Se referencearkitekturens guide for stamdataindlæsere her for generelle fælles retningslinjer for udvikling af stamdataindlæsere.

Herunder beskrives specifikke forhold for Cpr Indlæseren.

 Byggevejldning

Udover normalt tilgængelige Maven dependencies, afhænger projektet også af interne artefakter. Hvis disse artefakter ikke er udgivet (released) i den påkrævede version i NSP's Nexus repository, skal man selv udtjekke og bygge dem fra NSP's Subversion i den pågældende version. Artefakternes forskellige versioner vil være tilgængelige under et Subversion-tag. Disse artefakter er:

• stamdataindlaeser (Maven identifier:dk.nsi.sdm.stamdataindlaeser:stamdataindlaeser)

For at bygge disse interne artefakter, henvises der til artefakternes dokumentation.

For at bygge projektet og dets deployables (war-filen) uden at køre unit-tests og integrationstests, anvendes følgende Maven kommando:

mvn clean install -DskipTests

Projektets deployables ender i target-mappen under de respektive moduler.

Data validering

På hver række af data foretages der følgende valideringer.

Hvis en data for en række fejler valideringen bliver denne række, og evt. indlejrede rækker, ikke indlæst, men resten af data i filen indlæses

...

As-is validering

Disse er valideringer, der er kopieret fra den eksisterende Yder indlæser.

...

.

Nye valideringer

Disse valideringer er tilkommet i forbindelse med implementering af

...

CprIndlæser

• CPR numre er valide - dvs. 10 cifre, hvor de første

...

• to cifre er et tal fra 01 og 31, og de næste to er et tal fra 01-12 - hvis et CPR nummer ikke er validt skippes den pågældende

...

• Person
  
• Felterne i tabellerne der er defineret som alfanumeriske - så der foretages ikke nogen validering af typen/udfaldsrum af værdier
• Felterne i tabellerne der er defineret som "Date" valideres for om de overholder formatet "dd-MM-yyyy".
• Felterne i tabellerne der er defineret som "DateTime" valideres for om de overholder formatet "dd-MM-yyyy HH:mm".
• Felterne i tabellerne der er defineret som "int" valideres for om værdier er numeriske.

...

Filsæt validering

På et modtaget filsæt gennemføres der et antal valideringer før data parses og splittes til events for levering til modtagere af data.

De valideringer, der er implementeret, er:

 Validering af filnavn

Filnavnet skal overholde følgende:

• Input filerne ved fuldt import skal overholde dette pattern: 

  D.{6}\\.L4311.*

Validering af encoding

Indholdet af filen for CprIndlæseren forventes at være encodet i ISO-8859-1.

Der foretages en validering af encoding ved at udføre en dekodning af fil-indholdet med ISO-8859-1.

Hvis valideringen fejler stoppes filen og den givne fejl logges til databasen og applikationsloggen med en relativ position i filen af det tegn som ikke er i den forventede encoding.

Validering af struktur

Indholdet af filen for CprIndlæseren forventes at være i følgende struktur:

<START RECORD>

<CPR RECORD 1 ...>

<CPR RECORD 2 ...>

<CPR RECORD 3 ...>

..

<CPR RECORD n ...>

<SLUT RECORD>

<FEJL RECORD 1>

<FEJL RECORD 2>

...

<FEJL RECORD m>

Hvor <START RECORD> starter med "000" og <SLUT RECORD> starter med "999". De enkelte <CPR RECORDS> starter med en recordtype der kan have værdier i intervallet "001" .. "030".

<FEJL RECORDS> starter med "910".

Inputfilen forventes at have denne struktur og det valideres inden indlæsningen påbegyndes.

Hvis valideringen fejler stoppes filen og den givne fejl logges til databasen og applikationsloggen.

Overvågning

Overvågningsservicen giver udslag på sin statusservice i følgende situationer, hvilket vil sætte supporter igang

• En filsæt validering fejler - dvs. at den senest modtagne fil er afvist som helhed
• En event-validering fejler - dvs. at enkelte events i en modtagen fil ikke opfylder validitets-regler.
• Afhængighedsproblemer (fx. ingen forbindelse til databasen)
• Der er gået uforholdsmæssigt lang tid siden vi har fået sidste fil (kan konfigureres)
• Anden processeringsfejl

Registrering af fejl

De ovenstående fejlscenarier er knyttet til indlæsningerne, og da yder indlæseren godt kan slukkes og startes, bliver evt. fejltilstande holdt i databasen i tabellerne CPR_dataset, CPR_datasetlog, CPR_registerstatus og CPR_registerfejl.

Tabellerne CPR_dataset og CPR_datasetlog er i bund og grund en database log over fejl der er opstået under processering af en fil. Disse tabeller udtrykker derfor hvordan processering af den seneste fil er foregået.

Tabellerne CPR_registerstatus og CPR_registerfejl beskriver den akkumulerede status for et givent register (her cprregisteret) og holder derfor styr på, om f.eks. en fejl i en given event stadig er forekommende, selvom der er modtaget stamdata filer efter at fejlen optrådte første gang.

Det er tabellerne CPR_registerstatus og CPR_registerfejl der danner grundlaget for visningen i overvågningsservicen, da vi her ønsker at se den akkumulerede status for det pågældende register.

Bemærk, at for CprIndlæseren, som kun indlæser fulde indlæsninger, vil den akkumulerede status altid svare til status for den senest modtagne fil.

...

Efter hver <CPR RECORD> forventes der at være et CprNr. Det skal være et tal med 10 cifre - og de første 4 cifre skal være en dato.

Det tjekkes at navnet på input filerne ved delta import overholder dette pattern:

D.*\\.L431101