Page History
Navitabs | ||||||
---|---|---|---|---|---|---|
| ||||||
Overblik
Driftsvejledningen indeholder information der er relevant for driften af Det Fælles Stamkort 1.5-servicen (FSK), herunder oplysninger om standard placering af log- og konfigurationsfiler, eksterne afhængigheder, start/stop/genstart og fejlfinding.
I produktion består Det Fælles Stamkort servicen af én komponent fsk-service (war-arkiv), der er deployet på en Wildfly applikationsserver.
Servicen har følgende afhængigheder:
- Der kræves adgang til 2 MariaDB datasources.
- Kald til (skrivning til) MinLog-servicen.
- Kald til (læsning fra) CPR-Enkeltopslag (SCES)
- Kald til (læsning fra) Organdonorregister-servicen (ODR)
- Kald til (læsning fra) Livstestamenteregister-servicen (LTR)
- Kald til (læsning fra) Behandlingstestamenteregister-servicen (BTR)
- Kald til (læsning fra) Stamkortregister-servicen. (SKR)
- Kald til (både læsning fra og skrivning til ) Dokumentdelingsservicen og det underliggende registry (DDS).
Ændringslog
Version | Dato | Ændring | Ansvarlig |
---|---|---|---|
2.0.0 | 2018-08-27 | Initialt dokument | Trifork |
Funktionalitet
Servicen udstiller data som beskrevet i anvenderguiden. Komponenten kaldes alene af Dokumentdelingsservicen (DDS). Servicen udstiller derudover en række administrative og konfigurationsrelaterede funktionaliteter.
Direkte kald på service-komponenten
URL | Funktionalitet |
---|---|
<server>/fsk/isAlive | Status-side for servicen. Viser versionsinformation og fortæller om servicen fungerer korrekt, se afsnittet Overvågning. |
Daglig drift
Servicen kræver ingen daglig vedligeholdelse udover sædvanlig systemovervågning.
Alt data for en borger fjernes 1 år efter borgerens død ved hjælp af et integreret job kaldet SyncJob. Dette job fjerner både data fra servicens primære database samt fra DDS registry.
Overvågning
Servicen udstiller en status-side (isAlive). På denne side fremgår servicens version, mm. samt status for adgang til servicens datasources.
Eksempel på et response fra status-siden:
Code Block |
---|
200 OK
Title: fsk-service
Deployed: Wed Aug 15 16:28:37 CEST 2018
Build-Date: 2018-08-15T11:52:02Z
Build-Version: 1.0-SNAPSHOT
Builder: A robot
Display time: Fri Aug 17 12:58:17 CEST 2018 |
HTTP statuskode
Status-siden returnerer følgende HTTP statuskoder afhængig af servicens status:
- 200: Applikationen kører i øjeblikket fint.
- 500: Der er opstået en fejl, der kræver indgriben.
Fejlfinding
Såfremt der er problemer med adgang til servicens databaser, vises i stedet en fejl:
Code Block |
---|
500 Internal Server Error
Stamdata database check failed
Title: fsk-service
Deployed: Wed Aug 15 16:28:37 CEST 2018
Build-Date: 2018-08-15T11:52:02Z
Build-Version: 1.0-SNAPSHOT
Builder: A robot
Display time: Fri Aug 17 12:58:17 CEST 2018 |
Følgende årsager kan resultere i en statuskode 500:
- Hvis mindst én databaserne ikke er tilgængelige. Der overvåges databaseadgang ved et simpelt "SELECT 1" statement. Denne query køres på alle datasources.
- Andre ukendte årsager.
Hvis status-siden giver HTTP 500 bør man checke den tilsvarende log, som typisk vil indeholde en mere detaljeret fejlmeddelelse end status-siden (stacktrace osv).
En service eller et job kan genstartes ved at kalde touch på den tilsvarende war-fil. I yderste konsekvens kan Wildfly genstartes.
SyncJob
Jobbet sørger for oprettelse/nedlæggelse af metadata i DDS registry i takt med ændringer i CPR-registeret (fødsler/dødsfald). Ifm. midlertidige fejl fra DDS, vil jobbet standse og forsøge igen senere (afhængigt af CRON-udtrykket i "jobs.ddssync.schedule" i application.properties). Det er dog også tænkeligt at DDS returnerer en logisk fejl, hvor det ikke giver mening at forsøge igen senere. Derfor er FSK udstyret med en property "jobs.ddssync.max.errors", hvor det er muligt at angive hvor mange fejl jobbet accepterer før det standser. Normalt bør værdien være '0', hvilket betyder at man ikke accepterer fejl, og at jobbet derfor vil forsøge igen med den samme besked. For at tillade jobbet at ignorere den ene fejl, kan værdien sættes til '1', og så bør der kigges nærmere på hvad der gemmer sig bag fejlen, så der kan ske manuelt data-opret.
Følgende logning kan ses hvis SyncJob støder på et midlertidigt problem, og derfor opgiver videre behandling før CRON-udtrykket tillader det:
Code Block |
---|
2018-08-27 15:14:18.627 [main] WARN dk.stamkort.integrations.dds.SyncJob [] - CPR -> DDS synchronization job stopped due to temporary error. Sync will pause and retry later
dk.stamkort.dao.exceptions.DDSTemporaryException:
at dk.stamkort.integrations.dds.SyncJob.createDDRegistryEntry(SyncJob.java:245) ~[classes/:?]
at dk.stamkort.integrations.dds.SyncJob.runSyncPersonIds(SyncJob.java:144) [classes/:?]
at dk.stamkort.integrations.dds.SyncJobTest.runSynchronizationJob(SyncJobTest.java:329) [test-classes/:?]
at dk.stamkort.integrations.dds.SyncJobTest.testJobErrorHandlingForTemporaryError(SyncJobTest.java:282) [test-classes/:?]
at ... |
Nedenstånde logning ses hvis antallet af logiske fejl overskrides, så jobbet opgiver videre behandling:
Code Block |
---|
2018-08-27 15:14:14.495 [main] WARN dk.stamkort.integrations.dds.SyncJob [] - DDS logical error for documentId=urn:sds:fsk:stamkort:3ed5c350-f71d-4337-9d20-1d7d3911f461
dk.stamkort.dao.exceptions.DDSPermanentException:
at dk.stamkort.integrations.dds.SyncJob.createDDRegistryEntry(SyncJob.java:245) ~[classes/:?]
at dk.stamkort.integrations.dds.SyncJob.runSyncPersonIds(SyncJob.java:144) [classes/:?]
at dk.stamkort.integrations.dds.SyncJobTest.runSynchronizationJob(SyncJobTest.java:329) [test-classes/:?]
at dk.stamkort.integrations.dds.SyncJobTest.testJobErrorHandlingForPermanentError(SyncJobTest.java:304) [test-classes/:?]
at ...
2018-08-27 15:14:14.496 [main] ERROR dk.stamkort.integrations.dds.SyncJob [] - Max number of errors (2) exceeded for SyncJob (max allowed is 1) |
Logfiler og fortolkning af disse
Alle logfiler er at finde i ”log” under Wildfly. Herunder findes en liste over logfiler, med en beskrivelse af hvilke komponenter der skriver til dem. Log konfigurationen for servicen er konfigureret i modules/dk/sundhedsdatastyrelsen/fsk/main/resources/log4j2.xml som der også er vist et eksempel på i Installationsvejledning (FSK) .
Alle logs benytter en rolling file appender, og indeholder derfor et postfix i filnavnet, der ikke er præsenteret i nedenstående.
Logfilnavn | Indhold |
---|---|
fsk_service.log | Applikationslog fra FSKservicen, som indeholder de vigtigste systemhændelser (INFO), fejl (ERROR) og advarsler (WARN). |
fsk_audit.log | Auditlog fra FSK-servicen, som indeholder logning af, hvem der har kaldt, hvilken service der blev kaldt, hvordan der blev kaldt, hvornår der blev kaldt samt kaldets varighed. Bemærk, Da FSK-servicen kun udstiller én webservice, som er on-demand servicen til kald fra DDS, vil mange oplysninger være éns fra kald til kald. |
Ved en fejl på en overvågningsside skrives der til den relevante logfil.
Krav til backup m.m.
Der bør foretages backup af data på en forsvarlig måde, i tilfælde af behov for en genetablering af data. Disse skal opbevares på en forsvarlig måde, jfr. regler om personhenførbare data.