Driftsvejledningen indeholder information der er relevant for driften af Behandlingstestamenteregister-servicen (BTR), herunder oplysninger om standard placering af log- og konfigurationsfiler, eksterne afhængigheder og fejlfinding.
I produktion består Behandlingstestamenteregister-servicen af en komponente (war-arkiv), der er deployet på en Wildfly applikationsserver: ltr-btr-service-wildfly: Denne afhænger af adgang til 2 MariaDB datasources. Desuden afhænger den af at kunne kalde (skrive til) MinLog-servicen.
Version | Dato | Ændring | Ansvarlig |
---|---|---|---|
1.0.1 | 2018-08-17 | Initialt dokument | Trifork |
1.0.2 | 2018-08-31 | Ny release | Trifork |
1.0.3 | 2018-09-06 | Endpoints ændret fra /ltr-btr til /btr | Trifork |
1.0.4 | 2018-11-23 | Tilføjet admin endpoints | Trifork |
1.0.14 | 2019-25-09 | Ajourført | Trifork |
1.1.0 | 2020-03-24 | TreatmentWillV2 med noLifeProlongingIfDying uden angivelse af yderligere accept | KvalitetsIT |
1.1.1 | 2020-03-30 | Afvisning af yderligere accept for uafvendeligt døende på TreatmentWill-snitflade | KvalitetsIT |
1.1.3 | 2020-05-26 | Opdateret slettejob | KvalitetsIT |
1.1.7 | 2021-09-06 | Opdateret ifm. udfasning af dgws/idws-proxy. | KvalitetsIT |
1.1.8 | 2021-10-12 | Opdateret ifm. udfasning af btr-snitflade med accept fra pårørende, værge eller fremtidsfuldmægtig for uafvendeligt døende | KvalitetsIT |
1.1.9 | 2021-10-26 | Opdateret ifm inaktive cpr numre afvises | KvalitetsIT |
Servicen udstiller en række data som beskrevet i anvenderguiden. Komponenten kaldes af anvendere gennem NSP'ens DCC (afkoblingskomponenten), som viderestiller kaldet til servicens webservice-endpoint. Servicen udstiller derudover en række administrative og konfigurationsrelaterede funktionaliter.
URL | Funktionalitet |
---|---|
<server>/btr/isAlive | Status-side for servicen. Viser om servicen fungerer korrekt, se afsnittet Overvågning. |
<server>/btr/dksconfig/ltr | Livstestamenteregistret: DCC auto-konfigurations API. Anvendes til konfiguration af NSP'ens DCC. |
<server>/btr/ltr | Livstestamenteregistret: Webservice-endpoint |
<server>/btr/btr | Behandlingstestamenteregistret: Webservice-endpoint |
<server>/btr/ltrAdmin | Livstestamenteregistret: Webservice admin-endpoint (til brug for brugerflade) |
<server>/btr/btrAdmin | Behandlingstestamenteregistret: Webservice admin-endpoint (til brug for brugerflade) |
<server>/btr/dksconfig/btr | Behandlingstestamenteregistret: DCC auto-konfigurations API. Anvendes til konfiguration af NSP'ens DCC. |
<server>/btr/wsdl | HTML-side med links til download af WSDL-filer i hhv. DGWS- og IDWS-udgave. |
<server>/btr/wsdl/ltr/dgws | Livstestamenteregistret: DGWS WSDL |
<server>/btr/wsdl/ltr/idws | Livstestamenteregistret: IDWS WSDL |
<server>/btr/wsdl/btrV2/dgws | Behandlingstestamenteregistret version 2: DGWS WSDL |
<server>/btr/wsdl/btrV2/idws | Behandlingstestamenteregistret version 2: IDWS WSDL |
<server>/btr/syncjob/ltr/start | Slettejob for LTR startes ved kald af denne url, og personer, som har været døde i et år eller mere, slettes fra LivingWill tabellen. Returnerer tidspunkt for modtaget request og http status kode 200 |
<server>/btr/syncjob/ltr/status | Oplysninger om slettejob for LTR på den pågældende server. Oplysningerne gemmes i hukommelsen på serveren og fosvinder ved genstart. Der returneres http status kode 200 og følgende data: tidspunkt for sidste afvikling af slettejob på serveren (hvis værdien findes ellers tom værdi), status for sidste afvikling på serveren (true=ingen fejl, false=fejl, tom tekst=ikke afviklet) og fejlbesked ved sidste afvikling (hvis findes ellers er værdien udeladt) |
<server>/btr/syncjob/btr/start | Slettejob for BTR startes ved kald af denne url, og personer, som har været døde i et år eller mere, slettes fra TreatmentWill tabellen. Returnerer tidspunkt for modtaget request og http status kode 200 |
<server>/btr/syncjob/btr/status | Oplysninger om slettejob for BTR på den pågældende server. Oplysningerne gemmes i hukommelsen på serveren og fosvinder ved genstart. Der returneres http status kode 200 og følgende data: tidspunkt for sidste afvikling af slettejob på serveren (hvis værdien findes ellers tom værdi), status for sidste afvikling på serveren (true=ingen fejl, false=fejl, tom tekst=ikke afviklet) og fejlbesked ved sidste afvikling (hvis findes ellers er værdien udeladt) |
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 to slettejobs.
Servicen udstiller en status-side (isAlive). På denne side fremgår servicens version, opstartstidspunkt mm. samt status for slettejob.
Eksempel på et response fra status-siden:
200 OK Title: ltr-btr-service-wildfly Deployed: 2018-08-10T10:55:17.777Z Build-Date: 2018-08-10T10:52:22Z Build-Version: 1.0.1-SNAPSHOT Builder: A robot Display time: 2018-08-10T12:57:43.577Z Delete job: Enabled, Last successful deletion: 1900-01-01T00:00:00Z, Error count: 0 |
Status-siden returnerer følgende HTTP statuskoder afhængig af servicens status:
Følgende årsager kan resultere i en statuskode 500:
Hvis status-siden giver HTTP 500 bør man checke den servicens log, som burde indeholde en detaljeret fejlmeddelelse med stacktrace.
Følgende beskrivelse af logning i servicen tager udgangspunkt i standard-opsætningen. Logning konfigureres vha. konfigurationsfilerne beskrevet i installationsvejledningen.
Alle logfiler placeres i standalone/log i Wildfly.
Alle logninger er konfigureret med en rolling file appender, der indsætter et postfix i filnavnet på historiske logfiler ud fra følgende pattern:
-%d{MM-dd-yyyy}-%i
Der oprettes således en logfil pr. dag, og desuden oprettes endnu en logfil, når en logfil er blevet 10 MB stor.
Følgende tabel over logfiler beskriver, hvilke komponenter der skriver til dem:
Logfilnavn | Indhold |
---|---|
accesshandler.log | Log for accesshandler-biblioteket. |
access.log | Access-log. |
btr_audit.log | Auditlog. Indeholder logning af, hvem der har kaldt, hvilken SOAP-action der blev kaldt, hvilken person der blev kaldt for, hvordan der blev kaldt (DGWS/IDWS), hvornår der blev kaldt samt kaldets varighed. |
btr_service.log | Applikationslog for servicen, som indeholder de vigtigste systemhændelser. Root: WARN |
nsp-kafka.log | Log for kafka-produceren, som står for skrivning til MinLog. |
nsputil-sla-btr.log | SLA-log. Indeholder SLA-logninger for alle kald på servicen. Indeholder desuden SLA-logninger for servicens kald til MinLog. |
server.log | Log for Wildfly-serveren. |
CprExist logger til sla loggen, hvis CPR nummeret ikke findes eller er inaktivt og validerings mode er sat til WARNING. Formattet af logning er som følger
Slettejob for hver service bliver afviklet vha. en udstillet RestController, som kaldes vha. simpelt HTTP GET kald.
Dette gøres for at sikre afviklingen af slettejob i flere-node drift, hvor en loadbalancer sørger for fordeling af kald til bagvedliggende servere.
Driften vedligeholder en cron, som kalder slettejobbets url i et fast mønster vha. curl.
Følgende parametre til styring af slettejobbet kan ændres i application.properties for LTR:
jobs.delete.cpr-max-results.ltr=25
jobs.delete.cpr-max-loops.ltr=2
og BTR:
jobs.delete.cpr-max-results.btr=25
jobs.delete.cpr-max-loops.btr=2
Hvor jobs.delete.cpr-max-results.xxx bestemmer antal af cpr numre, der skal udtrækkes til sletning. Og jobs.delete.cpr-max-loops.xxx bestemmer antal gange udtræk af cpr numre skal gennemføres.
Hvis tiden til afvikling af slettejob overskrider 20-25 sekunder, så bør ovenstående parametre gøres mindre.
Kommando til kald af slettejob for LTR:
curl <server>/btr-service/syncjob/ltr/start
og BTR:
curl <server>/btr-service/syncjob/btr/start
Slettejobbet skal for LTR aktiveres hver dag, hvert 15. minut mellem 8.05-16.05 - startende kl. 8.05
Slettejobbet skal for BTR aktiveres hver dag, hvert 15. minut mellem 8.10-16.10 - startende kl. 8.10
Med mindre ovenstående parametre ændres, så vil slettejobbet behandle op til 1550 sletninger om dagen. (I gennemsnit er der 150 døde pr. døgn)
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.