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

Herunder beskrives specifikke forhold for Yder Indlæseren.

Kildekode

Database

I "referencearkitekturens guide til udviklere for stamdataindlæsere" nævnes, at Flyway anvendes til at holde styr på database ændringer. Dette gælder ikke for Yder. Her anvendes istedet Liquibase.

Data validering

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

...

As-is validering

Disse er valideringer, der er kopieret fra den eksisterende Yder indlæ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 YderPerson
  Der kan vel ikke forekomme erstatnings-cpr numre her?
• Yder numre er valide - dvs. 6 cifre - hvis et Yder nummer ikke er validt skippes den pågældende Yder samt dens YderPersoner
• Der hvor der i grænseflade beskrivelsen grænsefladebeskrivelsen (vedhæftet) er angivet en type for data - f.eks. at TilDatoYder er på formen ÅÅÅÅMMDD - valideres det om data følger det angivne format.
• En YderPerson der ligger under en Yder skal pege på samme Ydernummer som den omkringliggende Yder har. - hvis en YderPerson ikke peger korrekt på dens yder skippes YderPersonen
• Angivne koder ligger inden for de tilladte værdier

De implementerede valideringer tager udgangspunkt i snitfladebeskrivelsen for de yderdata der leveres og som her beskrevet i dette dokument:

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 encoding

...

• Det tjekkes at værdien i AntPost-elementet matcher summen af elementer i filen
• Det tjekkes at antallet af hhv. Ydere og YderPersoner ikke afviger mere end allowableDifference % fra det antal valide Ydere og YderPersoner der er i databasen.
  allowableDiference allowableDifference værdien konfigureres eksternt.

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

Validering af filnavn

Yderindlæseren modtager filer uden et løbenummer, så derfor er der ikke implementeret en validering af filnavnet iht. til sekvensen af filer.

Overvågning

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

...

Se driftvejledningen her afsnittet med service snitflader.

Registrering af fejl

De ovenstående fejlscenarier Fejlscenarier er knyttet til indlæsningerne, og da yder indlæseren godt kan slukkes og startes, bliver evt. fejltilstande holdt i databasen i tabellerne YDS_DataDet, DataSet og YDS_DataSetLog, YDS_RegisterStatus og YDS_RegisterFejl.

Tabellerne YDS_DataSet og YDS_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 YDS_RegisterStatus og YDS_RegisterFejl beskriver den akkumulerede status for et givent register (her yderregisteret) 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 YDS_RegisterStatus og YDS_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 yder indlæ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 yderindlæ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.

...