Page History
| Navitabs | ||||
|---|---|---|---|---|
| ||||
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.
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.
...
Nye valideringer
Disse
...
valideringer er tilkommet i forbindelse med implementering af CprIndlæser
- CPR numre er valide - dvs. 10 cifre hvor første 6 cifre er en gyldig dato - hvis et CPR nummer ikke er validt skippes den pågældende Person
- Felterne i Yder og YderPerson er defineret som alfanumeriske - så der foretages ikke nogen validering af typen/udfaldsrum af værdier
- Felterne i Yder og YderPerson er defineret med deres længder, og det valideres om alle værdier overholder den givne længde for feltet
- Felterne i Yder og YderPerson er alle defineret som "mandatory" felter, og det tjekkes derfor om alle felter indeholder en værdi
...
Nye valideringer
Disse valideringer er tilkommet i forbindelse med implementering af Yder indlæser
...
- .
...
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 delta import skal overholde dette pattern:
D.*\\.L431101
- 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.
Da overvågningsservicen polles hvert 10 sekund er der et krav til at den er letvægts. I den nuværende overvågningsservice i CprIndlæseren er det kun hvis databasen er nede at det kan tage et par sekunder, hvorfor yder indlæseren venter et par sekunder før den giver op.