...

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.

...

curl -v http://localhost:8080/yderindlaeser/status

...

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 [Processing]
• En Yderevent-validering fejler - dvs. at enkelte Yderevents i en modtagen fil ikke opfylder validitets-regler. [DataSetLog]
  Hvis en Yderevent er fejlet i et load, så vil fejl markeringen først blive fjernet når man manuelt har fjernet linierne fra datasetlog efter håndtering af problemet.
• Afhængighedsproblemer (fx. ingen forbindelse til databasen eller SFTP server) [SFTP YDER_EXTERNAL, SFTP YDER og Database]
• Et modtaget filsæt afviger volumenmæssigt for meget i forhold til seneste succesfulde filsæt (kan konfigureres). [Processing]

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

Det overordnede flow i Yderindlæseren er som vist denne figur:

Image Removed

Datakilden er Praksys, som med jævne mellemrum, leverer et fuldt udtræk af yder data til en sftp server (interaktion 2. Lever udtræk i figuren)

Yderindlæseren poller en SFTP server for nye filer af typen .xml (interaktion 3. Hent udtræk i figuren). Når der dukker en fil op, hentes den ind til Yderindlæseren og slettes fra SFTP serveren.

Fra den interne placering, læses udtrækket (interaktion 4. Læser udtræk i figuren). Derved tjekkes den modtagne fil 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 (interaktion 5. Opdater register i figuren) og som Yderevents (interaktion 6. Skriv events i figuren), 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.

Til sidst  ved successfuld håndtering skrives en tom ".done" fil til intern folder. Ved kritisk fejl skrive en ".fail" fil. Denne fil sendes til SFTP lokation og anses som ekstern kvittering på endt håndtering.

Statusservice

Statusservice vil svare med en http 200 når alt er ok, men vil svare med en http 500 når der er opstået en fejl under behandling af en fil eller der er en ekstern afhængighed der kan tilgås.

Svar ved ok

Når alt er ok svarer statusservicen med http 200 og viser denne information

...

Dette kan gøres ved at kigge i log filer og i databasens tabeller. Se længere nede i dette dokument under statusservice, for de forskellige typer af status.
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
Det overordnede flow i Yderindlæseren er som vist denne figur:
Image Added

Datakilden er Praksys, som med jævne mellemrum, leverer et fuldt udtræk af yder data til en sftp server (interaktion 2. Lever udtræk i figuren)
Yderindlæseren poller en SFTP server for nye filer af typen .xml (interaktion 3. Hent udtræk i figuren). Når der dukker en fil op, hentes den ind til Yderindlæseren og slettes fra SFTP serveren.
Fra den interne placering, læses udtrækket (interaktion 4. Læser udtræk i figuren). Derved tjekkes den modtagne fil 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 (interaktion 5. Opdater register i figuren) og som Yderevents (interaktion 6. Skriv events i figuren), 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.
Til sidst  ved successfuld håndtering skrives en tom ".done" fil til intern folder. Ved kritisk fejl skrive en ".fail" fil. Denne fil sendes til SFTP lokation og anses som ekstern kvittering på endt håndtering.
Statusservice
Statusservice vil svare med en http 200 når alt er ok, men vil svare med en http 500 når der er opstået en fejl under behandling af en fil eller der er en ekstern afhængighed der kan tilgås.
Se iøvrigt også Fejlhåndtering fælles for alle stamdataindlæsere
Svar ved ok
Når alt er ok svarer statusservicen med http 200 og viser denne information
 Code Block
title
Eksempel på status service
{
   "DataSetLog":"OK",
   "SFTP YDER_EXTERNAL":"OK",
   "SFTP YDER":"OK",
   "Database":"OK",
   "version":"1.1.3-SNAPSHOT",
   "Processing":"Dataprocessering OK"
}

##


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 [Processing]
En Yderevent-validering fejler - dvs. at enkelte Yderevents i en modtagen fil ikke opfylder validitets-regler. [DataSetLog]
Hvis en Yderevent er fejlet i et load, så vil fejl markeringen først blive fjernet når man manuelt har fjernet linierne fra datasetlog efter håndtering af problemet.
Afhængighedsproblemer (fx. ingen forbindelse til databasen eller SFTP server) [SFTP YDER_EXTERNAL, SFTP YDER og Database]
Et modtaget filsæt afviger volumenmæssigt for meget i forhold til seneste succesfulde filsæt (kan konfigureres). [Processing]


Svar ved fejl i behandling af fil
...