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 og fejlfinding.
I produktion består Det Fælles Stamkort servicen af én komponent fsk-web (war-arkiv), der er deployet på en Wildfly applikationsserver.
Servicen har følgende afhængigheder:
Version | Dato | Ændring | Ansvarlig |
---|---|---|---|
2.0.0 | 2018-08-27 | Initialt dokument | Trifork |
2.0.8 | 2019-07-31 | Tilføjet information om ny overvågningsside | Trifork |
2.0.9 | 2019-25-09 | Ajourført | Trifork |
2.0.13 | 2020-02-13 | Beskrivelse af SyncJob ændret | KvalitetsIT |
2.0.14 | 2021-08-20 | Fjernet referencer til SyncJob | KvalitetsIT |
Servicen udstiller data som beskrevet i anvenderguiden. Komponenten kaldes alene af Dokumentdelingsservicen (DDS). Servicen udstiller derudover en række administrative og konfigurationsrelaterede funktionaliteter.
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. |
Servicen kræver ingen daglig vedligeholdelse udover sædvanlig systemovervågning.
Servicen udstiller en statusside med versionsinformation. Der returneres en body med JSON-data.
"$.build" indeholder oplysninger om versionen, og hvornår den blev bygget.
"$.time" indeholder oplysninger om det aktuelle tidspunkt, og tidspunktet for hvornår servicen blev deployed.
Eksempel:
{ "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" } } |
De følgende afsnit beskriver emner i servicen, der kræver opmærksomhed ift. driften.
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 en body med JSON-data, der beskriver sundhedsstatus for forskellig funktionalitet i applikationen.
Health-statussiden er opbygget vha. 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. Denne 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 overordnet status:
HTTP statuskode | Beskrivelse |
---|---|
200 OK | Ingen fejl. |
203 Non authoratative information | En fejl kræver måske indgriben, men applikationen fungerer fortsat med nedsat funktion. |
500 Internal Server Error | Applikationen/funktionen er nede og kræver øjeblikkelig indgriben. |
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 |
---|---|
$.details.organDonorClient | 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). Statuskode 200: OK |
$.details.db | Er baseret på Actuator'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. Statuskode 200: OK |
HTTP statuskode: 200 OK
{ "status": "UP", "details": { "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" } }, "minLogClient": { "status": "UP", "details": { "timeOfLastExecution": "2019-07-30T17:31:13.569Z" } }, "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 } } } } } } |
HTTP statuskode: 202 Accepted
{ "status": "NEEDS_ATTENTION", "details": { "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" } }, "minLogClient": { "status": "UP", "details": { "timeOfLastExecution": "2019-07-30T17:31:13.569Z" } }, "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 } } } } } } |
Servicens logfiler bør løbende tjekkes for ERROR-logninger.
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.
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. |
Følgende tabel viser hvad der audit logges ved successfulde kald til fsk.
Komponent | Kontekst | Type | Nøgle | Information |
---|---|---|---|---|
FSK | retrieveDocumentSet | Ikke Personlig | document-id | ID på hentet dokument |
FSK | retrieveDocumentSet | Personlig | cpr | CPR på borgeren |
FSK | retrieveDocumentSet | Personlig | actor-cpr | CPR på aktør |
FSK | retrieveDocumentSet | Personlig | actor-firstname | Fornavn på aktør |
FSK | retrieveDocumentSet | Personlig | actor-lastname | Efternavn på aktør |
FSK | retrieveDocumentSet | Personlig | actor-usertype | Typen af aktør |
FSK | retrieveDocumentSet | Personlig | actor-authorisation-number | Autorisationsnummer på aktør |
FSK | retrieveDocumentSet | Personlig | actor-education-code | Uddannelseskode på aktør |
FSK | retrieveDocumentSet | Personlig | actor-organisation-id | Organisations ID på aktør |
FSK | retrieveDocumentSet | Personlig | actor-organisation-id-source | Typen af organisations ID |
FSK | retrieveDocumentSet | Personlig | actor-organisation-name | Organisationsnavn på aktør |
Servicen indeholder ikke nogen backup-mekanismer, og dette skal derfor konfigureres på database-niveau. Der bør foretages backup af data på en forsvarlig måde, i tilfælde af behov for en genetablering af data. Disse data skal opbevares på en forsvarlig måde, jfr. regler om personhenførbare data.