Page History
...
Code Block |
---|
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:
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):
Code Block |
---|
{"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:
...
Komponent | Kontekst | Type | Nøgle | Information |
---|---|---|---|---|
BTR | validateCpr | Personlig | cpr-does-not-exist | Medsendt CPR nummer (hvis det ikke findes i CPR register) |
BTR | validateCpr | Personlig | cpr-inactive | Medsendt CPR nummer (hvis det er inaktivt) |
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).
Slettejob
Livstestamenteregistret
Operation / Brugertype | Borger | Sundhedsfaglig | System bruger | Admin bruger |
---|---|---|---|---|
UpdateLivingWill | x | x | x | |
DeleteLivingWill | x | x | x | |
GetLivingWill | x | x | ||
HasLivingWill |
Behandlingstestamenteregistret
Operation / Brugertype | Borger | Sundhedsfaglig | System bruger | Admin bruger |
---|---|---|---|---|
CreateTreatmentWill | x | x | x | |
UpdateTreatmentWill | x | x | x | |
DeleteTreatmentWill | x | x | x | |
GetTreatmentWill | x | x | ||
HasTreatmentWill |
Slettejob
Servicens slettejob 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
...
parameter til styring af slettejobbet kan ændres i application.properties for LTR:
...
jobs.delete.
...
max
...
.
...
time=
...
PT20S
og BTR:
jobs.delete.cpr-max-results.btrtime=25
jobs.delete.cpr-max-loops.btr=2
...
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-service/syncjoboperations/ltr-slettejob/start
og BTR:
curl <server>/ltr-btr-service/syncjoboperations/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).
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.