...

I produktion består Behandlingstestamenteregister-servicen af 2 følgende to komponenter (war-arkiverarkiv), der er deployet på en Wildfly applikationsserver:

• ltr-btr-service-wildfly: Selve Behandlingstestamenteregister-servicen. Denne afhænger af adgang til 2 MariaDB datasources. Desuden afhænger den af at kunne kalde (skrive til) MinLog-servicen.wsproxy: DGWS/IDWS proxy der håndterer requests og responses og internt viderestiller til 
• ltr-btr-service-wildfly.

...

• operations: De to baggrundsjobs der hører til Behandlingstestamenteregister-servicen. Denne afhænger også af adgang til 2 MariaDB datasources.

Ændringslog

Funktionalitet

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.

...

<server>/btr-service/isAlivestatus

<server>/btr/isAlive

<server>/btr/alarm

<server>/btr

/dksconfig/ltr

<server>/btr

/ltr

<server>/btr

/btr

<server>/btr

/ltrAdmin

<server>/btr

/btrAdmin

<server>/btr

/dksconfig/btr

<server>/btr

/wsdl

<server>/btr

/wsdl/ltr/dgws

<server>/btr

/wsdl/ltr/idws

<server>/btr

/wsdl/btr/dgws

<server>/btr

/wsdl/btr/idws

<server>/btr-service/wsdl/btrV2/dgws

<server>/btr-service/wsdl/btrV2/idws

Kald via proxy-komponenten

<server>/btr/

treatment-will-deceased-cleanup/start

<server>/btr/

treatment-will-deceased-cleanup/status

<server>/btr/

<server>/btr/btr

<server>/btr/ltrAdmin

<server>/btr/btrAdmin

<server>/btr/isAlive

<server>/btr/dksconfig

<server>/btr/wsdl

<server>/btr/wsdl/ltr/dgws

<server>/btr/wsdl/ltr/idws

<server>/btr/wsdl/btr/dgws

<server>/btr/wsdl/btr/idws

<server>/btr/wsdl/btrV2/dgws

living-will-deceased-cleanup/start

<server>/btr/living-will-deceased-cleanup/status

<server>/btr/wsdl/btrV2/idws

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 et integreret slettejobto slettejobs.

Overvågning

Servicen udstiller nu en status-side

...

og en alarm-side, hvor den tidligere kun har udstillet en isAlive-side.

Kald til den gamle isAlive-side vil nu blive håndteret på samme måde, som kald til status-siden.

I den nye udgave vil status-siden kun melde fejl, hvis servicen ikke kan nå de bagved liggende databaser. Status siden vil stadig indholde informationer om version, opstartstidspunkt m.m. 

Eksempel på et response fra status-siden:

HTTP/1.1 200 OK
Connection: keep-alive
X-Powered-By: Undertow/1
Server: WildFly/8
Transfer-Encoding: chunked
Content-Type: text/plain;charset=ISO-8859-1
Date: Mon, 2 Dec 2024 01:01:01 GMT

200  OK

Title: ltr-btr-service-wildfly
Deployed: 20182024-0812-10T1002T01:5500:1700.777Z00Z
Build-Date: 20182024-0812-10T1012T00:5200:22Z00Z
Build-Version: 1.01.1-SNAPSHOT
Builder: A robotRobot
Display time: 20182024-0812-10T1202T01:57:43.577Z
Delete job: Enabled, Last successful deletion: 1900-01-01T00:00:00Z, Error count: 0

HTTP statuskode

01:01.001Z

Den nye alarm-side vil kun melde fejl og indeholde information, hvis bagved liggende tjeks melder fejl.

HTTP/1.1 500 Internal Server Error
Connection: keep-alive
X-Powered-By: Undertow/1
Server: WildFly/8
Transfer-Encoding: chunked
Content-Type: text/plain;charset=ISO-8859-1
Date: Mon, 2 Dec 2024 01:01:01 GMT

203  Non-Authoritative Information from: PersonInformationServiceClient
Antal fejl: 25
2024-12-02T01:00:00.001: Fejl i retursvar fra PersonInformation

Status for baggrundsjobbet LTR fremgår af denne url:

curl <server>/ltr-btr-operations/ltr-slettejob/status

og for BTR:

curl <server>/ltr-btr-operations/btr-slettejob/status

Eksempel på denne statusside hvor et af jobbene er fejlet (det vil se ud på samme måde for begge jobs):

{"lastException":"An error occurred querying v2_Person_Simplified between 2022-09-26T11:06:47Z and 2022-09-26T11:11:29Z","timeOfLastExecution":"2023-09-26 13:11:29","lastExecutionSucceeded":"false"}

HTTP statuskode

Status og alarm-siderne 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

Følgende årsager kan resultere i en statuskode 500 på status-siden:

• Hvis mindst én btr eller stm 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 servicens log, som burde indeholde en detaljeret fejlmeddelelse med stacktrace.

Følgende årsager kan resultere i en statuskode 500 på alarm-siden:

• Hvis der opstår fejl ved kald til PersonInformation-servicen.

Hvis alarm-siden giver HTTP 500, så vil den også sende informativ tekst med omkring fejl. Derudover bør man tjekke servicelog.

Logning

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 logs benytter en rolling file appender, der indsætter og indeholder derfor et postfix i filnavnet på historiske logfiler ud fra følgende pattern:

-%d{MM-dd-yyyy}-%i

...

, der ikke er præsenteret i nedenstående.

Følgende tabel over logfiler beskriver, hvilke komponenter der skriver til dem:

Slettejob

Auditlog

Der er i BTR fem kategorier af audit logs; cpr, livstestamente, behandlingstestamente, aktør og cpr validering

Følgende tabeller viser hvilke kategorier der audit logges for hver operation i BTR.

Livstestamenteregistret

Behandlingstestamenteregistret

Behandlingstestamenteregistret version 2

Følgende tabeller viser hvad der audit logges for hver af de fem kategorier.

cpr

livstestamente

behandlingstestamente

aktør

cpr validering

Følgende logges kun hvis validerings mode er sat til WARNING.

Minlog

Der er i BTR fire brugertyper: Borger, sundhedsfaglig, system bruger og admin bruger. 

Følgende tabel viser for hvilke operationer og brugertype kombinationer, der logges til minlog (x=der logges).

Livstestamenteregistret

Behandlingstestamenteregistret

Slettejob

Servicens slettejob 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 parameter til styring af slettejobbet kan ændres i application.properties for LTR:

jobs.delete.max.time=PT20S

og BTR:

jobs.delete.max.time=PT20S

Der er en max grænse for hvor lang tid jobbet må køre pr. gang og det kan angives her. 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.

Kommando til kald af slettejob for LTR:

curl <server>/ltr-btr-operations/ltr-slettejob/start

og BTR:

curl <server>/ltr-btr-operations/btr-slettejob/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)Servicens slettejob kører automatisk efter det konfigurede scheduling-pattern. Størrelsen af batches kan konfigureres som beskrevet i installationsvejledningen.

Backup

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.