...

<server>/btr/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/wsdl/btrV2/dgws

<server>/btr/wsdl/btrV2/idws

<server>/ltr-btr-operations/ltr-slettejobtreatment-will-deceased-cleanup/start

<server>/btr/ltrtreatment-btrwill-operations/ltrdeceased-slettejobcleanup/status

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

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

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 to slettejobs.

Overvågning

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:

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

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

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 to 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: 2024-12-02T01:00:00.00Z
Build-Date: 2024-12-12T00:00:00Z
Build-Version: 1.1.1
Builder: A Robot
Display time: 2024-12-02T01: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

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 for baggrundsjobbet LTR fremgår af denne url:

...

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-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:

• Hvis 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.

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 logs benytter en rolling file appender, og indeholder derfor et postfix i filnavnet, der ikke er præsenteret i nedenstående.

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

...

Logfilnavn

...

Indhold

...

audit.log

...

btr_service.log

...

Applikationslog for servicen, som indeholder de vigtigste systemhændelser.

Root: WARN
org.springframework.core: INFO
dk.sundhedsdatastyrelsen.livstestamente: INFO

...

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 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 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.
  

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 logs benytter en rolling file appender, og indeholder derfor et postfix i filnavnet, der ikke er præsenteret i nedenstående.

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

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

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 version 2

...

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

cpr

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

cpr

livstestamente

...

behandlingstestamente

behandlingstestamente

aktør

aktør

cpr validering

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

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.

...

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

...