Page History
...
- 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 |
| 2.0.8 | 2019-07-31 | Tilføjet information om ny overgågningsside | 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 |
/actuator/info | Status-side. Se afsnittet versionsinformation. |
<server>/fsk/actuator/health | Status-side |
| . Viser |
| 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.
...
Versionsinformation
Servicen udstiller en
...
statusside med versionsinformation. Der returneres en body med JSON-data.
Property'en "build" indeholder oplysninger om versionen og hvornår den blev bygget.
Property'en "time" indeholder oplysninger om det aktuelle tidspunkt og tidspunktet for hvornår servicen blev deployed.
Eksempel:
| Code Block | ||
|---|---|---|
| ||
{
"build": {
"version": "2.0.8",
"artifact": "fsk-service",
"name": "fsk-service",
"group": "dk.sundhedsdatastyrelsen.stamkort",
"time": "2019-07-30T07:30:22.496Z"
},
"time": {
"currentTime": "2019-07-30T13:16:18.761Z",
"deployed": "2019-07-30T13:16:10.382Z"
}
} |
Overvågning
De følgende afsnit beskriver emner i servicen der kræver opmærksomhed ift. driften.
Health-statusside
Servicen udstiller en Health-statusside (også typisk kendt som isAlive), der viser om applikationen er sund, eller om noget kræver indgriben. Health-statussiden returnerer body med JSON-data, der beskriver sundhedsstatus for forskellige funktionalitet i applikationen.
Health-statussiden anvender Spring Boot Actuator, som er konfigureret med nogle specialfremstillede HealthIndicators.
Actuator beregner en overordnet status for applikationens tilstand, som baseres på den HealthIndicator, der returnerer den mest fatale status. Den overordnede status vises i JSON-property'en "status". Se eksempler længere nede.
Der er udover standard Actuator statusser defineret en specielfremstillet status (NEEDS_ATTENTION). Den følgende tabel viser alle statusser i rækkefølge fra sund til fatal. Tabellen viser også den HTTP statuskode, som Health-statussiden vil returnere til en given status:
| Status | HTTP statuskode | Beskrivelse |
|---|---|---|
| UP | 200 OK | Ingen fejl. |
| UNKNOWN | 200 OK | Ingen status tilgængelig. Typisk fordi applikationen netop er blevet deployed. |
| NEEDS_ATTENTION | 202 Accepted | En fejl kræver måske indgriben, men applikationen fungerer fortsat med nedsat funktion. |
| OUT_OF_SERVICE | 500 Internal Server Error | Applikationen/funktionen er deaktiveret. Denne status anvendes pt. ikke. |
| DOWN | 500 Internal Server Error | Applikationen/funktionen er nede og kræver øjeblikkelig indgriben. |
Opførsel for forskellige HealthIndicators
Nogle HealthIndicators anvender ikke nødvendigvis alle statusser men kun udvalgte. Følgende tabel viser, hvad de enkelte HealthIndicators tjekker, og hvornår de returnerer en specifik status.
Bemærk at det kun er "db"-HealthIndicator'en der kan returnere statussen "DOWN" og dermed udløse HTTP statuskoden "500 Internal Server Error".
| Navn (på property i JSON-response) | Beskrivelse |
|---|---|
| certificateExpiry | Tjekker om konfigurede certifikater er tæt på udløb. Der tjekkes alle certifikater i de to keystores der er angivet i property'erne application.properties:"client.keystore.filesystem.path" og i minlogclient.properties:"sts.keystore". Derudover vises detaljer om udløbsdato for alle certifikater. UP: OK |
| organDonorClient, livingWillClient, treatmentWillClient, personalDataCardRegisterClient, scesClient | Tjekker om det seneste kald med den pågældende integration var succesfuldt. Hvis det ikke var succesfuldt, så viser "error" en toString() på den exception der opstod. Der vises eventuelt "timeOfLastExecution", som angiver det seneste tidspunkt, hvor et kald blev forsøgt (uanset om det var successfuldt eller ikke-successfuldt). UP: OK |
| syncJob | Tjekker om den seneste afvikling af jobbet var successfuld. Hvis den ikke var succesfuld, så viser "error" en toString() på den exception der opstod. Der vises eventuelt "timeOfLastExecution", som angiver det seneste tidspunkt, hvor jobbet blev forsøgt afviklet. UP: OK |
| db | Er baseret på Actuor's indbyggede DataSourceHealthIndicator og tjekker, at der kan udføres en "SELECT 1" query på alle applikationens datasources. Query'en udføres i det øjeblik Health-statussiden forespørges. Der vises detaljer om status for de enkelte datasources. UP: OK |
Eksempel på response, når applikationen er sund
HTTP statuskode: 200 OK
| Code Block | ||
|---|---|---|
| ||
{
"status": "UP",
"details": {
"certificateExpiry": {
"status": "UP",
"details": {
"certificates": [
{
"file": "test1/FMK-KRS-TEST.jks",
"alias": "sosi:alias_system",
"validFrom": "2017-04-04T13:39:50Z",
"validUntil": "2020-04-04T13:39:27Z"
},
{
"file": "test1/FMK-KRS-TEST.jks",
"alias": "sosi:alias_system",
"validFrom": "2017-04-04T13:39:50Z",
"validUntil": "2020-04-04T13:39:27Z"
}
]
}
},
"organDonorClient": {
"status": "UP",
"details": {
"timeOfLastExecution": "2019-07-30T17:31:13.245Z"
}
},
"livingWillClient": {
"status": "UP",
"details": {
"timeOfLastExecution": "2019-07-30T17:31:13.246Z"
}
},
"treatmentWillClient": {
"status": "UP",
"details": {
"timeOfLastExecution": "2019-07-30T17:31:13.245Z"
}
},
"personalDataCardRegisterClient": {
"status": "UP",
"details": {
"timeOfLastExecution": "2019-07-30T17:31:13.246Z"
}
},
"scesClient": {
"status": "UP",
"details": {
"timeOfLastExecution": "2019-07-30T17:31:13.566Z"
}
},
"syncJob": {
"status": "UP",
"details": {
"timeOfLastExecution": "2019-07-30T18:00:05.321Z"
}
},
"db": {
"status": "UP",
"details": {
"primaryDataSource": {
"status": "UP",
"details": {
"database": "MySQL",
"hello": 1
}
},
"stamdataDataSource": {
"status": "UP",
"details": {
"database": "MySQL",
"hello": 1
}
}
}
}
}
} |
Eksempel på response, når noget i applikationen kræver indgriben
HTTP statuskode: 202 Accepted
| Code Block | ||
|---|---|---|
| ||
{
"status": "NEEDS_ATTENTION",
"details": {
"certificateExpiry": {
"status": "UP",
"details": {
"certificates": [
{
"file": "test1/FMK-KRS-TEST.jks",
"alias": "sosi:alias_system",
"validFrom": "2017-04-04T13:39:50Z",
"validUntil": "2020-04-04T13:39:27Z"
},
{
"file": "test1/FMK-KRS-TEST.jks",
"alias": "sosi:alias_system",
"validFrom": "2017-04-04T13:39:50Z",
"validUntil": "2020-04-04T13:39:27Z"
}
]
}
},
"organDonorClient": {
"status": "UP",
"details": {
"timeOfLastExecution": "2019-07-30T17:31:13.245Z"
}
},
"livingWillClient": {
"status": "NEEDS_ATTENTION",
"details": {
"error": "java.io.IOException: HTTP POST failed (404): Not Found",
"timeOfLastExecution": "2019-07-30T17:31:13.246Z"
}
},
"treatmentWillClient": {
"status": "UP",
"details": {
"timeOfLastExecution": "2019-07-30T17:31:13.245Z"
}
},
"personalDataCardRegisterClient": {
"status": "UP",
"details": {
"timeOfLastExecution": "2019-07-30T17:31:13.246Z"
}
},
"scesClient": {
"status": "UP",
"details": {
"timeOfLastExecution": "2019-07-30T17:31:13.566Z"
}
},
"syncJob": {
"status": "UP",
"details": {
"timeOfLastExecution": "2019-07-30T18:00:05.321Z"
}
},
"db": {
"status": "UP",
"details": {
"primaryDataSource": {
"status": "UP",
"details": {
"database": "MySQL",
"hello": 1
}
},
"stamdataDataSource": {
"status": "UP",
"details": {
"database": "MySQL",
"hello": 1
}
}
}
}
}
} |
Fejlfinding
Servicens logfiler bør tjekkes for ERROR-logninger
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.
...
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 |
...
| . |
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.