Indledning

Nærværende dokument udgør driftsvejledningen for Yderindlæseren. Yderindlæseren er en stamdataindlæser som vedligeholder register over ydere og deres tilknyttede personer (kaldet yder personer).

Yderindlæseren er en webapplikation der deployer på en Wildfly applikationsserver.

Distributionen af Yderindlæseren foregår som et Docker image der er bygget på NSP platform Docker imaget (registry.nspop.dk/platform/nsp)

Monitoreringssnitflader

Alle Yderindlæsere overvåges via en simpel statusservice. (Se evt. https://www.nspop.dk/display/public/web/Husregler+for+udvikling+til+NSP#HusreglerforudviklingtilNSP-Snitfladetilmonitorering(gl4.4)).

Denne statusservice bliver overvåget ved at den polles hver 10. sekund for en ny status (200 ok og 500 fejl pr default HTTP). Ved 500 er det tegn på, at en supporter skal igang med at kigge på problemet.

Statusservicen giver udslag i følgende situationer, som vil sætte support igang

En filsæt validering fejler - dvs. at den senest modtagne fil er afvist som helhed
En Yderevent-validering fejler - dvs. at enkelte Yderevents i en modtagen fil ikke opfylder validitets-regler.
Hvis en Yderevent er fejlet i et load, så vil fejl markeringen først blive fjernet når der er modtaget et nyt load hvor den pågældende Yderevent er indlæst med succes.
Afhængighedsproblemer (fx. ingen forbindelse til databasen eller SFTP server)
Der er gået uforholdsmæssigt lang tid siden vi har fået sidste fil (kan konfigureres)
Et modtaget filsæt afviger volumenmæssigt for meget i forhold til seneste succesfulde filsæt (kan konfigureres).

Generelle overvågningssnitflader

Ingen - ud over den beskrevne statusservice.

Service snitflader

Ingen - de data der indlæses i registret via Yderindlæseren stilles til rådighed via SKRS, men Yderindlæseren selv udstiller ikke nogen services.

Hvordan agerer Yderindlæseren

Yderindlæseren poller en SFTP server for nye filer af typen .xml, og når der dukker en fil op, hentes den ind til Yderindlæseren og slettes fra SFTP serveren.

Den modtagne fil tjekkes for format og konsistens og derefter påbegyndes indlæsningen af de data der findes i den modtagne fil.

Yderindlæseren vil indlæse så meget som muligt af de modtagne data, mens data som det ikke er muligt at indlæse logges til fejlbehandling.

Data indlæses både som enkeltstående rækker i Yder registerdatabasen og som Yderevents, hvor den enkelte event samler en Yder med dens relaterede entiteter, i en event tabel.

Efter endt håndtering vil data, enten som enkeltrækker eller som events kunne hentes via SKRS grænsefladen.

Håndtering af fejlsituationer

Følgende fejlsituationer kan opstå under drift af Yderindlæseren.

Statusservice melder fejl

Når statusservicen svarer med en http 500 skal der igangsættes support til hhv.

Afklaring af fejl på database eller SFTP forbindelse og efterfølgende re-etablering
Ved fejl i filsæt validering og manglende eller for afvigende filsæt, skal der tages kontakt til Praksys, som leverer filsættet for at afklare fejlen og bede dem om at igangsætte handlinger, der retter fejlen.

Yderindlæseren går ned

I tilfælde af at docker containeren der kører Yderindlæseren går ned, kan følgende trin følges for at sikre at evt. data der var under behandling bliver færdigbehandlet.

Yderindlæseren er designet til at en stamdata fil kan genkøres uden at de register data der vedligeholdes bliver korrupte, så de beskrevne trin går kun ud på at få yderindlæseren til at genbehandle en evt. afbrudt fil indlæsning.

Som beskrevet i Yderindlæser - Installationsvejledning er Yderindlæserens docker container startet med hhv. et volume-mount der bibeholder indholdet af den interne input folder /tmp/yder/input og et volume-mount der bibeholder indholdet af den interne backup folder /tmp/yder/input/.done efter docker containeren er stoppet.

Derfor vil disse volumemounts indeholde evt. filer der var under behandling da docker containeren stoppede eller som er lagt i backup mens docker containeren kørte.

Yderindlæseren er opdelt i en producerende del, som parser og splitter stamdata filen, og en konsumerende del, som skriver de splittede data til databasen.

Når Yderindlæserens producerende del er igang med at behandle en fil, vil /tmp/yder/input folderen indeholde den fil der er under behandling, f.eks. A23.D210309.XML samt en låse fil med navnet A23.D210309.XML.camelLock. Filen A23.D210309.XML.camelLock fortæller Yderindlæseren, at filen med navnet uden .camelLock, er under indlæsning og der derfor ikke skal tages fat i denne fil.

Når Yderindlæserens producerende del er færdig, vil datafilen bliver kopieret til en backup lokation og filen med endelsen .camelLock slettes.

Hvis der var en fil under behandling af den producerende del, når Yderindlæserens docker container går ned, så vil der i volume-mountet for /tmp/yder/input ligge en fil med endelsen .camelLock.

Når docker containeren med Yderindlæseren er startet igen, kan filen med endelsen .camelLock slettes hvilket vil få Yderindlæseren til at tage fat i stamdata filen og indlæsningen af filen vil gentages.

Hvis Yderindlæserens docker container går ned mens en fil under behandling er kommet igennem den producerende del og der kun udestår den konsumerende dels behandling af de splittede data, så vil filen være flyttet til backup folderen, og den vil derfor ligge i denne folder efter docker containeren er stoppet.

Det er her nødvendigt at kigge i databasen for at afgøre om der var filer i behandling da docker containeren gik ned.

Dette gøres ved at udføre SQL forespørgslen

select * from YDS_dataset where status not like "%Completed%";

mod Yderindlæserens database.

Hvis denne forespørgsel returnerer en eller flere rækker, findes den række hvor DataReceived kolonnen er umiddelbart før tidspunktet hvor Yderindlæserens docker container gik ned, og FileName + UUID kolonnen i samme række vil fortælle hvilken fil i backup folderen der ikke blev afsluttet. Filen fra backupfolderen kan dernæst flyttes til input folderen så indlæsningen kan genoptages.

Beskrivelse af logs

Yderindlæseren skriver til 4 forskellige log filer, der alle er placeret lokalt i Docker containeren i Wildfly standard log folderen: /pack/wildfly8/standalone/log

NSP SLA log

Denne log ligger i filen nsputil-sla.log og indeholder NSP SLA logninger på formen

22-06-2020 12:30:43,863 [Camel (camel-1) thread #4 - sftp://foo@localhost:33219/praksys] INFO  dk.sdsd.nsp.slalogdata - LogPoint="LoggerBean" LogPointUniqId="LoggerBean" StartTime="2020-06-22 12:30:43.863" EndTime="2020-06-22 12:30:43.863" Duration="53 microseconds" MessageId="8d0bf2fe-d37d-46ad-bb16-19418eca1270" RequestSize=0 ReplySize=0 Result=OK ClientIP="<empty>" SOAPOperation="DataSet fetched" SOAPEndpoint="<empty>" SOAPAction="<empty>" TargetSOAPOperation="<empty>" TargetSOAPEndpoint="<empty>" GenericCallParms(1)= { ("Input","M.S1040025.00001.xml") }
22-06-2020 12:30:44,442 [Camel (camel-1) thread #5 - file:///tmp/yder/input] INFO  dk.sdsd.nsp.slalogdata - LogPoint="LoggerBean" LogPointUniqId="LoggerBean" StartTime="2020-06-22 12:30:43.863" EndTime="2020-06-22 12:30:43.863" Duration="53 microseconds" MessageId="427705ca-83b3-45a5-9128-ceb46a649c52" RequestSize=0 ReplySize=0 Result=OK ClientIP="<empty>" SOAPOperation="DataSet received" SOAPEndpoint="<empty>" SOAPAction="<empty>" TargetSOAPOperation="<empty>" TargetSOAPEndpoint="<empty>" GenericCallParms(1)= { ("Input","M.S1040025.00001.xml") }
22-06-2020 12:30:49,344 [Camel (camel-1) thread #1 - AggregateTimeoutChecker] INFO  dk.sdsd.nsp.slalogdata - LogPoint="LoggerBean" LogPointUniqId="LoggerBean" StartTime="2020-06-22 12:30:43.863" EndTime="2020-06-22 12:30:49.344" Duration="5481368 microseconds" MessageId="427705ca-83b3-45a5-9128-ceb46a649c52" RequestSize=0 ReplySize=0 Result=OK ClientIP="<empty>" SOAPOperation="DataSet completed" SOAPEndpoint="<empty>" SOAPAction="<empty>" TargetSOAPOperation="<empty>" TargetSOAPEndpoint="<empty>" GenericCallParms(1)= { ("Input","M.S1040025.00001.xml") }

Audit log

Denne log ligger i filen yderAudit.log og indeholder overordnet logning af Yderindlæserens aktivitet

timestamp="2020-06-22 12:30:44,565" priority="INFO" class="dk.nsi.sdm.yder.bean.LoggerBean" message="The file M.S1040025.00001.xml has been preparsed"
timestamp="2020-06-22 12:30:48,097" priority="INFO" class="dk.nsi.sdm.yder.bean.LoggerBean" message="The file M.S1040025.00001.xml has been parsed and splitted"
timestamp="2020-06-22 12:30:49,345" priority="INFO" class="dk.nsi.sdm.yder.bean.LoggerBean" message="The file M.S1040025.00001.xml has been completed with status Completed"

Application log

Denne log ligger i filen yderApplication.log og indeholder detaljeret logning af Yderindlæserens aktivitet

timestamp="2020-06-22 12:30:43,864" priority="DEBUG" class="dk.nsi.sdm.yder.bean.LoggerBean" message="The file M.S1040025.00001.xml has been fetched"
timestamp="2020-06-22 12:30:44,442" priority="DEBUG" class="dk.nsi.sdm.yder.bean.LoggerBean" message="The file M.S1040025.00001.xml has been received"
timestamp="2020-06-22 12:30:44,565" priority="INFO" class="dk.nsi.sdm.yder.bean.LoggerBean" message="The file M.S1040025.00001.xml has been preparsed"
timestamp="2020-06-22 12:30:48,069" priority="DEBUG" class="dk.nsi.sdm.yder.parser.YderSaxParseSplitHandler" message="Parsed 59 yders and 54 persons"
timestamp="2020-06-22 12:30:48,097" priority="INFO" class="dk.nsi.sdm.yder.bean.LoggerBean" message="The file M.S1040025.00001.xml has been parsed and splitted"
timestamp="2020-06-22 12:30:49,345" priority="INFO" class="dk.nsi.sdm.yder.bean.LoggerBean" message="The file M.S1040025.00001.xml has been completed with status Completed"

Stat log

Denne log ligger i filen yderStat.log og indeholder statistik logning af Yderindlæserens aktivitet

{"Time to preparse":"PT0.074S","Time to parse":"PT3.502S","Parsed records":"Parsed 59 Yders and 54 YderPersons","Application":"YderIndlæser","Timestamp":"2020-06-22 12:30:49,345","Processing Time":"PT5.345S","ExchangeId":"427705ca-83b3-45a5-9128-ceb46a649c52"}