Overblik

Driftsvejledningen indeholder information der er relevant for driften af Organdonorregister-servicen (ODR), herunder oplysninger om standard placering af log- og konfigurationsfiler, eksterne afhængigheder og fejlfinding.

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

• odr-service-wildfly: Selve Organdonorregister-servicen. Denne afhænger af adgang til 2 MariaDB datasources. Desuden afhænger den af at kunne kalde (skrive til) MinLog-servicen.
• odr-operations: Baggrundsjob der hører til Organdonorregister-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.

Direkte kald på service-komponenten

<server>/odr/status

<server>/odr/alarm

<server>/odr/odr

<server>/odr/odrAdmin

<server>/odr/dksconfig

<server>/odr/wsdl

<server>/odr/wsdl/dgws

<server>/odr/wsdl/idws

<server>/odr-operations/odr-slettejob/deceased/start

<server>/odr-operations/odr-slettejob/emigrated/start

<server>/odr-operations/odr-slettejob/status

<server>/odr-operations/odr-slettejob/alarm

<server>/odr-operations/odr-send-digitalpost-notifikation/start

<server>/odr-operations/odr-send-digitalpost-notifikation/status

<server>/odr-operations/odr-send-digitalpost-notifikation/alarm

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

Overvågning

Servicen udstiller nu en status-side og en alarm-side, hvor der tidligere kun blev udstillet en samlet isAlive-side.

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, 3 Dec 2024 03:13:23 GMT

200  OK

Title: odr-service-wildfly
Deployed: 2024-12-03T02:02:02.002Z
Build-Date: 2024-12-03T01:01:01Z
Build-Version: 1.0.x
Builder: A Robot
Display time: 2024-12-03T03:13:23.345Z

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, 4 Dec 2024 16:32:48 GMT

203  Non-Authoritative Information from: CprExistsServiceClient
Antal fejl: 56
2024-12-04T16:24:32.480: Fejl i retursvar fra CPRExist

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 mindst én 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 logninger er konfigureret med 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 ODR fire kategorier af audit logs; cpr, organdonor registrering, aktør, cpr validering, organdonor operations og digital post

Følgende tabel viser hvilke kategorier der audit logges for hver operation i ODR.

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

cpr

organdonor registrering

aktør

cpr validering

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

digial post

Minlog

Der er i ODR 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).

Baggrundsjob (Slettejob/Oprydningsjob/Notifikationsjob)

Servicens baggrundsjobs bliver afviklet vha. en udstillede RestControllere, som kaldes vha. simpelt HTTP GET kald.
Dette gøres for at sikre afviklingen af baggrundsjobs i flere-node drift, hvor en loadbalancer sørger for fordeling af kald til bagvedliggende servere.

Driften vedligeholder en cron, som kalder url'er for baggrundsjobbene i et fast mønster vha. curl.

ODR har følgende baggrundsjobs:

• OrganDonorDeceasedCleanup - Slettejob til sletning af afdødes registreringer

• OrganDonorEmigratedCleanup - Oprydningsjov til invalidering af udrejstes registreringer

• OrganDonorNotification - Afsendelse af notifikationer vha. digital post

PersonInformation

Følgende parametre bruges til styringen af forbindelsen til PersonInformation servicen, som bruges på tværs af baggrundsjobs. De kan ændres i operations.properties for ODR:

Digital Post

Følgende parametre bruges til styringen af forbindelsen til Digital post servicen. De kan ændres i operations.properties for ODR:

OrganDonorDeceasedCleanup

Baggrundsjobbet kaldes når der skal slettes registreringer for personer der har været erklæret døde de sidste 60 dage (deletion.save.deceased)

Kommando til kald af slettejob:

curl <server>/odr-operations/odr-slettejob/deceased/start

Følgende parametre til styring af OrganDonorDeceasedCleanup kan ændres i operations.properties for ODR:

Der er en max grænse for hvor lang tid jobbet må køre pr. gang (deletion.desired.execution.duration.deceased) 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.

Status og alarm endpoints

Kommando til kald af slette job status og alarm:

curl <server>/odr-operations/odr-slettejob/status
curl <server>/odr-operations/odr-slettejob/alarm

Status kaldet verificerer databaseadgang. Der kan returneres følgende fra statussnitfladen:

200: Der er adgang til databasen og jobbet kan anvendes.

5xx: Komponenten melder at den ikke kan anvendes.

HTTP/1.1 200 OK
Database : OK 

Alarm kaldet verificerer services, eksterne kald og databaseadgange. Denne service indeholder kun data, hvis der er alarmer.

200: Komponenten fungerer og der er ingen alarmer.

5xx: Komponenten melder at den ikke kan anvendes.

Følgende er et ekempel på et svar, hvor personinformationservice ikke er tilgængelig.

HTTP/1.1 500 Internal Server Error
Baggrundsjobbet StackedOperationsService fejlede sidst det blev kørt. Problemet var: Data for CPR-nummeret kunne ikke findes, fordi kaldet til PersonInformation-servicen returnerede en uventet statuskode: 409.
Person Information servicen har fejlet flere gange end tilladt i en given periode.

OrganDonorEmigratedCleanup

Baggrundsjobbet kaldes når der skal ryddes op registreringer for person der er udrejste.

Kommando til kald af slettejob:

curl <server>/odr-operations/odr-slettejob/emigrated/start

Følgende parametre til styring af OrganDonorEmigratedCleanup kan ændres i operations.properties for ODR:

Der er en max grænse for hvor lang tid jobbet må køre pr. gang (deletion.desired.execution.duration.emigrated) 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.

Status og alarm endpoints

Se for OrganDonorDeceasedCleanup.

OrganDonorNotification

Baggrundsjobbet kaldes når der skal sendes notificationer til personer omkring påmindelser om organdonation. For nuværende er det notifikationer til personer, der snart bliver 18 år.

Kommando til kald af notifikationer:

curl <server>/odr-operations/odr-send-digitalpost-notifikation/start

Et job arbejder sig gennem datoer. Fra en given start dato og maksimalt indtil dags dato for jobbets udførsel. Når jobbet startes, hentes de personer frem, som skal have tilsendt en notifikation for en given dag. Først når alle personer har fået tilsendt en notifikation fortsættes til næste dag.

Ved at kalde jobbets status endpoint kan det ses, hvilken dato, der senest er kørt færdig, ligesom man kan se en tæller for de enkelte status for de nuværende notifkationer, der arbejdes på.

Hvis der ligger notifikationer i NotificationPerson, med status Error, skal problemerne bag disse løses. Når de problemet er løst, sættes status i databasen tilbage til Pending og SentAtDateTime samt ErrorMessage nullstilles . Jobbet startet igen. 

Ligger der vedvarende de samme notifikationer i NotificationPerson med status InProgress eller Sent  skal disse også manuelt håndteres. Igen ved at sætte status status til Pending, så jobbet tager fra i dem på nu.

Eksempel på sql, der kan opdatere NotificationPerson:

• find de relevante records: select NotificationPersonPID, ErrorMessage from NotificationPerson where status = "Error";
• opdater med ny status: update NotificationPerson set Status = "Pending", SentAtDateTime = null, ErrorMessage = null where NotificationPersonPID = <id> and status = "Error";'
• Tilsvarende kan de andre status findes. Anvend her InProgress og Sent.

Ligger der vedvarende den samme record i NotificationAge med status Locked tyder noget på at jobbet er gået i stå. Sørg for at ingen notifications job kører, og undersøg tilstanden i tabel NotificationPerson for at finde ud af, hvor langt kørslen er nået og ryd op tilsvarende.

For yderligere detaljer se design og arkitektur dokumentet. 

Parametre

Følgende parametre til styring af OrganDonorNotification kan ændres i operations.properties for ODR:

Status og alarm endpoints

Kommando til kald af notifikationers status og alarm:

curl <server>/odr-operations/odr-send-digitalpost-notifikation/status
curl <server>/odr-operations/odr-send-digitalpost-notifikation/alarm

Der er følgende status og alarm check i notifikations jobbet

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.