Page History
...
Servicen har følgende afhængigheder:
- Der kræves adgang til 2 to 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)
Æ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/actuator/info...
Status-side. Se afsnittet versionsinformation.
...
<server>/fsk/actuator/health...
- Kald til (læsning fra) Fravalg af Genoplivningsforsøg ved Hjertestop Register (FGVHR)
Funktionalitet
Servicen udstiller data som beskrevet i anvenderguiden. Komponenten kaldes alene af Dokumentdelingsservicen (DDS). Servicen udstiller derudover en række administrative og konfigurationsrelaterede funktionaliteter. Servicen har et slettejob, som er beskrevet længere nede i dokumentet.
Direkte kald på service-komponenten
URL | Funktionalitet |
|---|---|
<server>/fsk/isAlive | Status-side for FSK servicen. Viser om servicen fungerer korrekt, se afsnittet Overvågning. |
<server slettejob>/fsk-operations/fsk-cleanup/status | Returnerer statuskoden for den seneste kørsel af slettejobbet |
<server slettejob>/fsk-operations/fsk-cleanup/start | Starter fsk slette jobbet, som sletter stamkort, for personer, der har været afdøde et år |
<server slettejob>/fsk-operations/health | Status-side for slettejobbet. Viser om servicen fungerer korrekt, se afsnittet Overvågning. |
Opsætning
I application.properties kan der indstilles forkellige ting. Her følger et eksempel:
| Code Block |
|---|
author.institution.root=1. |
Opsætning
I application.properties kan der indstilles forkellige ting. Her følger et eksempel:
| Code Block |
|---|
author.institution.root=1.2.208.176.1.1 author.institution.extension=1126211000016009 author.institution.assigningAuthorityName=SOR author.institution.name=Sundhedsdatastyrelsen health.certificate-expires-warning=30 # WhitelistedJNDI CVRs (comma-separated) that are allowed to call with DGWS level 3 whitelisted.level3.cvrs=31908574,33257872 health.certificate-expires-warning=30 # JNDI datasource datasource properties datasource-fsk.jndi-name=java:jboss/datasources/FSK-DS datasource-stm.jndi-name=java:jboss/datasources/STM-DS sts.endpoint=http://test1.ekstern-test.nspop.dk:8080/sts/services/NewSecurityTokenService # MinlogSCES minlog.read-activity.text=Opslag i Stamkort minlog.on.idcard.level3.enabled=true # SCES sces.enable=truesces.enable=true sces.endpoint=http://test1.ekstern-test.nspop.dk:8080/stamdata-cpr-ws/service/DetGodeCPROpslag-1.0.4 sces.connect.timeout.millis=2000 sces.read.timeout.millis=7000 # ODR odr.enable=true odr.endpoint=http://test1-cnsp.ekstern-test.nspop.dk:8080/odr/odr odr.connect.timeout.millis=2000 odr.read.timeout.millis=7000 # LTR ltr.enable=true ltr.endpoint=http://test1-cnsp.ekstern-test.nspop.dk:8080/btr/ltr ltr.connect.timeout.millis=2000 ltr.read.timeout.millis=7000 # BTR btr.startdatetime=2019-01-01 00:00:00 btr.enable=true btr.endpoint=http://test1-cnsp.ekstern-test.nspop.dk:8080/btr/btr btr.connect.timeout.millis=2000 btr.read.timeout.millis=7000 # SKR skr.enable=true skr.endpoint=http://test1-cnsp.ekstern-test.nspop.dk:8080/skr/skr skr.connect.timeout.millis=2000 skr.read.timeout.millis=7000 # SYES syes.endpoint=http://test1-cnsp.ekstern-test.nspop.dk:8080/stamdata-yder-lookup-ws/service/YderService syes.connect.timeout.millis=2000 syes.read.timeout.millis=7000 # DDS dds.repository.unique.id=1.2.208.176.43210.8.10.12 dds.home.community.id=1.2.208.176.8.1.12 # FGVHR - De andre services genbruger ID-kort og FGVHR - De andre services genbruger ID-kort og HSUID-header som FSK modtager, til at kalde videre. Det gør FGVHR ikke, derfor skal certifikat og ID-kort konfigureres: fgvhr.enable=true fgvhr.endpoint=http://test1-cnsp.ekstern-test.nspop.dk:8080/fgvhr/20230601/hasNoResuscitation fgvhr.connect.timeout.millis=2000 fgvhr.read.timeout.millis=7000 fgvhr.sts.keystore=NSP_Test_Service_Consumer_sds.p12 # skal mappes ind i containeren på følgende sti, så navnet på keystore stemmer overens: /pack/wildfly/modules/dk/sundhedsdatastyrelsen/fsk/main/NSP_Test_Service_Consumer_sds.p12 fgvhr.sts.keystore.password=Test1234 fgvhr.idcard.subject.name=Sundhedsdatastyrelsen fgvhr.idcard.subject.id=33257872 fgvhr.idcard.system.name=FSK |
Daglig drift
Servicen kræver ingen daglig vedligeholdelse udover sædvanlig systemovervågning.
Versionsinformation
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:
...
| language | text |
|---|
...
# Cleanup
deletion.fsk.batchsize=1000
desired.execution.duration=PT20S
deletion.save.deceased=12M
# PersonInformation
personinformation.url=http://test1-cnsp.ekstern-test.nspop.dk:8080/stamdata-personinformation/v1
personinformation.errorcount.duration=PT10M
personinformation.error.tolerance=0
fsk.httpclient.pooling.totalconnections=200
fsk.httpclient.pooling.maxconnections.pr.route=20 |
Daglig drift
Servicen kræver ingen daglig vedligeholdelse udover sædvanlig systemovervågning.
Alt data (inkl. historiske data) for en borger fjernes 1 år efter borgerens død ved hjælp af slettejobbet.
Overvågning
De følgende afsnit beskriver emner i servicen, der kræver opmærksomhed ift. driften.
Health-statusside
FSK Servicen udstiller en 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.
Ud over status, indholder siden også data omkring byg, installation, version mm. Se eksemplet nedenfor.
Health-statussiden er opbygget vha Health-statussiden er opbygget vha. Spring Boot Actuator, som er konfigureret med nogle specialfremstillede HealthIndicators.
Actuator beregner Der beregnes 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.
Denne status returneres som http status kode, men indgår også i selve indholdet, med information omkring, hvilken healthindicator, som kræver opmærksomhed (kun den første, hvis flere med samme kritikalitet)
Tabellen viser 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:. Fra sund til fatal.
| 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 i response | Beskrivelse | ||
|---|---|---|---|
organDonorClient | |||
| 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 | ||
fsk database | Tjekker | $.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
| Code Block | ||
|---|---|---|
| ||
{
"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
}
}
}
}
}
} |
Eksempel på response, når noget i applikationen kræver indgriben
HTTP statuskode: 202 Accepted
| Code Block | ||
|---|---|---|
| ||
{
"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
}
}
}
}
}
} |
Fejlfinding
Servicens logfiler bør løbende tjekkes for ERROR-logninger.
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.
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
Følgende tabel viser hvad der audit logges ved successfulde kald til fsk.
...
Krav til backup m.m.
...
Title: fsk-web
Deployed: 2024-08-05T12:28:04.506Z
Build-Date: 2024-08-05T12:26:14Z
Build-Version: 2.2.1
Builder: lene
Display time: 2024-08-05T12:54:07.418Z
200 OK
organDonorClient : "timeOfLastExecution: 2024-08-05T12:53:38.116Z"
livingWillClient : "timeOfLastExecution: 2024-08-05T12:53:38.114Z"
treatmentWillClient : "timeOfLastExecution: 2024-08-05T12:53:38.114Z"
personalDataCardRegisterClient : "timeOfLastExecution: 2024-08-05T12:53:38.204Z"
yderClient : "timeOfLastExecution: 2024-08-05T12:53:38.251Z"
scesClient : "timeOfLastExecution: 2024-08-05T12:53:38.115Z"
FgvhrClient : "timeOfLastExecution: 2024-08-05T12:53:38.114Z"
fsk database : "Forbindelse til database fsk ok"
stm database : "Forbindelse til database stm ok" |
Eksempel på response, når noget i applikationen kræver indgriben
HTTP statuskode: 203 Non Authoritative Information
| Code Block | ||
|---|---|---|
| ||
Title: fsk-web
Deployed: 2024-08-05T12:57:50.776Z
Build-Date: 2024-08-05T12:26:14Z
Build-Version: 2.2.1
Builder: lene
Display time: 2024-08-05T12:58:40.406Z
203 Non Authoritative Information from:organDonorClient
organDonorClient : "timeOfLastExecution: 2024-08-05T12:58:35.228Z"
livingWillClient : "timeOfLastExecution: 2024-08-05T12:58:35.325Z"
treatmentWillClient : "timeOfLastExecution: 2024-08-05T12:58:35.309Z"
personalDataCardRegisterClient : "timeOfLastExecution: 2024-08-05T12:58:35.408Z"
yderClient : "timeOfLastExecution: 2024-08-05T12:58:35.457Z"
scesClient : "timeOfLastExecution: 2024-08-05T12:58:35.294Z"
FgvhrClient : "timeOfLastExecution: 2024-08-05T12:58:35.274Z"
fsk database : "Forbindelse til database fsk ok"
stm database : "Forbindelse til database stm ok" |
Slettejobbet status endpoints
Slettejobbet har sine egne status endpoints
<server slettejob>/fsk-operations/fsk-cleanup/status: fortæller med en http kode, hvordan den seneste sletning gik.
<server slettejob>/fsk-operations/health: fortæller status til eksterne services og database. Hvis de melder fejl så tjek log filerne.
Eksempel på svar fra health endpointet:
| Code Block | ||
|---|---|---|
| ||
{
"DB":"OK",
"PersonInformation":"OK"
} |
Fejlfinding
Servicens logfiler bør løbende tjekkes for ERROR-logninger.
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.
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, 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 og SFSK, vil mange oplysninger være éns fra kald til kald. |
Auditlog
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 | Følsomme | cpr | CPR på borgeren |
Krav til backup m.m.
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.
Slette job
Detaljer omkring de forskellige trin slettejobbet har, kan findes i FSK Design og arkitektur dokumentet.
Servicens slettejob bliver afviklet vha. en udstillet RestController, som kaldes vha. simpelt HTTP GET kald.
Driften vedligeholder en cron, som kalder slettejobbets url i et fast mønster vha. curl.
Man kan ændre styring af slettejobbet ved at ændre følgende parametre:
- desired.execution.duration=PT20S
Det er en max grænse for hvor lang tid jobbet må køre pr. gang. Når jobbet har kørt den tid der er angivet, så stopper udførslen. Her efter kan jobbet kaldes igen og den vil fortsætte med processeringen hvor jobbet stoppede sidst.
Parameteren angives som en Duration i ISO-8601 format. Dvs. eksemplet viser 20 sekunder. - deletion.fsk.batchsize=1000
Det er en max grænse for, hvor mange cpr numre, der håndteres af gangen. Blandt andet i forbindelse med kald til PersonInformation deceased og den videre sletning af stamkort. - deletion.save.deceased=12M
Angiver hvor lang tid en person skal være død for at stamdata bliver slettet
Kommando til kald af slettejob: <server>/fsk-operations/fsk-cleanup/start
...