Page History
...
URL | Funktionalitet | |||||
|---|---|---|---|---|---|---|
<server>/odr/status | Status-side for servicen. Viser om servicen fungerer korrekt, se afsnittet Overvågning. | |||||
<server>/odr/alarm | Alarm-side for servicen. Viser om der er valideringsfejl i servicen, se afsnittet Overvågning. | |||||
<server>/odr/odr | Webservice-endpoint | |||||
<server>/odr/odrAdmin | Webservice admin-endpoint (til brug for brugerflade) | |||||
<server>/odr/dksconfig | DCC auto-konfigurations API. Anvendes til konfiguration af NSP'ens DCC. | |||||
<server>/odr/wsdl | HTML-side med links til download af WSDL-filer i hhv. DGWS- og IDWS-udgave. | |||||
<server>/odr/wsdl/dgws | DGWS WSDL | |||||
<server>/odr/wsdl/idws | IDWS WSDL | |||||
<server>/odr/wsdl/idws/standard | Standard IDWS WSDL. Samme som IDWS WSDL dog uden IDWS Fault. | |||||
<server>/odr-operations/odr-slettejob/deceased/start | Baggrundsjob til sletning af døde startes ved kald af denne url. Returnerer altid http status kode 200. Eventuelle fejl skrives i loggen. | |||||
<server>/odr-operations/odr-slettejob/emigrated/statusstart | Baggrundsjob til oprydning ift. udrejste startes ved kald af denne url. Hvis person har en aktiv registrering, så tjekkes dem om denne person er udrejst. Hvis dette er tilfældet, så sættes VALIDTO-datoen til afviklingstidspunktet. Returnerer altid http status kode 200. Eventuelle fejl skrives i loggen. | |||||
<server>/odr-operations/odr-slettejob/status | Dette kald rapportere om slettejobbets er klar til at modtage kald. Se detaljer i senere afsnit. Dette kald verificerer databaseadgang. Der kan returneres følgende fra statussnitfladen: 200: Der er adgang til databasen og jobbet kan anvendes. Code Block |
| ||||
<server>/odr-operations/odr-slettejob/alarm | Dette kald verificerer services, eksterne kald og databaseadgange. Denne service indeholder kun data, hvis der er alarmer. 200: Komponenten fungerer og der er ingen alarmer. Følgende er et ekempel på et svar, hvor personinformationservice ikke er tilgængelig.
|
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:
rapportere om slettejobbet er i en tilstand, der kræver indgriben fra driften. | |
<server>/odr-operations/odr-send-digitalpost-notifikation/start | Baggrundsjob til at sende notifikationer til personer, som skal have en påmindelse om organ donation. Se detaljer i senere afsnit. |
<server>/odr-operations/odr-send-digitalpost-notifikation/status | Dette kald rapportere om notifiationsjobbets er klar til at modtage kald. Se detaljer i senere afsnit. |
<server>/odr-operations/odr-send-digitalpost-notifikation/alarm | Dette kald rapportere om notifikationsjobbet er i en tilstand, der kræver indgriben fra driften. |
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:
| Code Block | ||||
|---|---|---|---|---|
| ||||
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, | ||||
| Code Block | ||||
| ||||
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 |
...
- 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.
...
Der er i ODR fire kategorier af audit logs; cpr, organdonor registrering, aktør, aktør og cpr validering, organdonor operations og digital post
Følgende tabel viser hvilke kategorier der audit logges for hver operation i ODR.
...
| Komponent | Kontekst | Type | Nøgle | Information |
|---|---|---|---|---|
| ODR | validateCpr | Følsomme | cpr-does-not-exist | Medsendt CPR nummer (hvis det ikke findes i CPR register) |
| ODR | validateCpr | Følsomme | cpr-inactive | Medsendt CPR nummer (hvis det er inaktivt) |
Minlog
digial post
| Komponent | Kontekst | Type | Nøgle | Information |
|---|---|---|---|---|
| ODR | digitalPostSent | Følsomme | digital-post-request | Medsendt CPR nummer og den skabelon der ønskes sendt. |
| ODR | digitalPostSent | Ikke Personlig | digital-post-response | Retursvar fra kald til Digital Post Adapter |
Minlog
Der er i ODR fire brugertyper: Borger, sundhedsfaglig, system bruger og admin bruger.
...
| Operation / brugertype | Borger | Sundhedsfaglig | System bruger | Admin bruger |
|---|---|---|---|---|
| CreateOrganDonorRegistration | x | x | x | |
| UpdateOrganDonorRegistration | x | x | x | |
| DeleteOrganDonorRegistration | x | x | x | |
| GetOrganDonorRegistration | x | x | ||
| HasOrganDonorRegistration |
Slettejob
Baggrundsjob (Slettejob/Oprydningsjob/Notifikationsjob)
Servicens baggrundsjobs Servicens slettejob bliver afviklet vha. en udstillet RestControllerudstillede RestControllere, som kaldes vha. simpelt HTTP GET kald.
Dette gøres for at sikre afviklingen af slettejob baggrundsjobs i flere-node drift, hvor en loadbalancer sørger for fordeling af kald til bagvedliggende servere.
Driften vedligeholder en cron, som kalder slettejobbets url'er for baggrundsjobbene i et fast mønster vha. curl.
Følgende parametre til styring af slettejobbet kan ændres i cleanup.properties for ODR:
...
Den tid vi ønsker at bruge på sletning ved hvert request. Tiden er ikke garanteret, da vi kun tjekker mod den efter hver StackOperation er udført.
Default værdien er 20 sekunder.
...
deletion.save.deceased
...
P60D
...
Den tid som skal gå før vi sletter data for en afdød person. Dette gøres så vi ikke sletter data, hvis personens status ændres til afdød og derefter tilbage til levende.
Default værdien er 60 dage.
...
personinformation.defaultMaxConnectionsPerRoute
...
20
...
Max antal forbindelser som HTTP Connection Manager må lave pr. rute.
...
personinformation.error.tolerance
...
0
...
Tolerance for hvor mange fejl PersonInformation servicen må have inden den melder tilbage at den ikke virker.
. 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:
| Nøgle | Default værdi | Beskrivelse |
|---|---|---|
| personinformation.url | http://test1-cnsp.ekstern-test.nspop.dk:8080/stamdata-personinformation/2024/08/01 | Den url som jobbet skal bruge, når den skal kalde servicen stamdata-personinformation. |
| personinformation.maxTotalConnections | 200 | Max antal forbindelser som HTTP Connection Manager må lave. |
personinformation.defaultMaxConnectionsPerRoute | 20 | Max antal forbindelser som HTTP Connection Manager må lave pr. rute. |
personinformation.defaultConnectionTimeoutMs | 20000 | Konfiguration af connection timeout (angives millisekunder) |
personinformation.error.tolerance | 0 | Tolerance for hvor mange fejl PersonInformation servicen må have inden den melder tilbage at den ikke virker i alarm indikatoren |
personinformation.errorcount.duration | PT10M | Angiver, hvor lang en periode, der skal kigges i efter antallet af fejl for PersonInformations alarm indikator |
Digital Post
Følgende parametre bruges til styringen af forbindelsen til Digital post servicen. De kan ændres i operations.properties for ODR:
| Nøgle | Default værdi | Beskrivelse |
|---|---|---|
| digitalpost.service.url | http://test1-cnsp.ekstern-test.nspop.dk:8080/digitalpost/2024/05/29/send | Den url som jobbet skal bruge, når den skal kalde servicen digital post |
| digitalpost.max.total.connections | 200 | Max antal forbindelser som HTTP Connection Manager må lave. |
| digitalpost.default.max.connections.per.route | 20 | Max antal forbindelser som HTTP Connection Manager må lave pr. rute. |
| digitalpost.default.connection.timeout.ms | 20000 | Konfiguration af connection timeout (angives millisekunder) |
| digitalpost.error.tolerance | 0 | Tolerance for hvor mange fejligital post servicen må have inden den melder tilbage at den ikke virker i alarm indikatoren |
| digitalpost.errorcount.duration | PT10M | Angiver, hvor lang en periode, der skal kigges i efter antallet af fejl forigital post alarm indikator |
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:
| Code Block | ||||
|---|---|---|---|---|
| ||||
curl <server>/odr-operations/odr-slettejob/deceased/start |
Følgende parametre til styring af OrganDonorDeceasedCleanup kan ændres i operations.properties for ODR:
| Nøgle | Default værdi | Beskrivelse |
|---|---|---|
deletion.desired.execution.duration.deceased | PT20S | Den tid vi ønsker at bruge på sletning ved hvert request. Tiden er ikke garanteret, da vi kun tjekker mod den efter hver StackOperation er udført. Default værdien er 20 sekunder. |
deletion.save.deceased | P12M | Den tid som skal gå før vi sletter data for en afdød person. Dette gøres så vi ikke sletter data, hvis personens status ændres til afdød og derefter tilbage til levende. |
deletion.batchsize.deceased | 1000 | Max. antal entries (f.eks. CPR) vi behandler pr. batch |
personinformation.batchsize.deceased | 100 | Max. antal CPR vi forespørger på i en enkelt request til personinformation |
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:
| Code Block | ||||
|---|---|---|---|---|
| ||||
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.
| Code Block | ||
|---|---|---|
| ||
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.
| Code Block | ||
|---|---|---|
| ||
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:
| Code Block | ||||
|---|---|---|---|---|
| ||||
curl <server>/odr-operations/odr-slettejob/emigrated/start |
Følgende parametre til styring af OrganDonorEmigratedCleanup kan ændres i operations.properties for ODR:
| Nøgle | Default værdi | Beskrivelse |
|---|---|---|
deletion.desired.execution.duration.emigrated | PT20S | Den tid vi ønsker at bruge på sletning ved hvert request. Tiden er ikke garanteret, da vi kun tjekker mod den efter hver StackOperation er udført. Default værdien er 20 sekunder. |
deletion.batchsize.emigrated | 1000 | Max. antal entries (f.eks. CPR) vi behandler pr. batch |
personinformation.batchsize.emigrated | 1000 | Max. antal CPR vi forespørger på i en enkelt request til personinformation |
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:
| Code Block | ||||
|---|---|---|---|---|
| ||||
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:
| Nøgle | Default værdi | Beskrivelse |
|---|---|---|
digitalpost.notification.odr.startdate | Den dato, hvor jobbet skal være aktivt første dag. Hvis jobbet køres før denne dato, vil der ikke blive sendt nogle notifikationer. | |
digitalpost.notification.odr.send.desired.execution.duration | PT20S | Den tid vi ønsker at bruge på hvert request. Tiden er ikke garanteret, da vi kun tjekker mod den efter hver StackOperation er udført. Parameteren angives som en Duration i ISO-8601 format Default værdien er 20 sekunder. |
digitalpost.notification.odr.send.limit | 1000 | Max. antal entries (antal notifikationer) vi henter op fra dagens udtrukne personer |
digitalpost.notification.odr.legalage.periode.year | P18Y | For udtræk af personer på deres fødselsdato. Det antal år personen skal være når notifikationen sendes ud Parameteren angives som en Duration i ISO-8601 format i år |
digitalpost.notification.odr.legalage.offset.days | P14D | For udtræk af personer på deres fødselsdato. En buffer periode i dage, hvornår notifikationen sendes ud før personen har fødselsdag. Parameteren angives som en Duration i ISO-8601 format i dage |
digitalpost.notification.odr.template.digital.undecided | ODR/20250911/digital/18aarIkkeTagetStilling | For udtræk af personer på deres fødselsdato. Den digitale brevskabelon, som anvendes for dem som ikke har taget stilling til organdonation |
digitalpost.notification.odr.template.digital.descided | ODR/20250911/digital/18aarHarTagetStilling | For udtræk af personer på deres fødselsdato. Den digitale brevskabelon, som anvendes for dem som har taget stilling til organdonation |
digitalpost.notification.odr.template.physical.undecided | ODR/20250911/physical/18aarIkkeTagetStilling | For udtræk af personer på deres fødselsdato. Den fysiske brevskabelon, som anvendes for dem som ikke har taget stilling til organdonation |
digitalpost.notification.odr.template.physical.descided | ODR/20250911/physical/18aarHarTagetStilling | For udtræk af personer på deres fødselsdato. Den fysiske brevskabelon, som anvendes for dem som har taget stilling til organdonation |
digitalpost.notification.odr.alarm.date.period | P3D | Angiver hvor alarm jobbet skal begynde at rapportere fejl at noget ikke er sendt Parameteren angives som en Duration i ISO-8601 format i dage |
Status og alarm endpoints
Kommando til kald af notifikationers status og alarm:
| Code Block | ||||
|---|---|---|---|---|
| ||||
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
| Healthindicator | Udførsel/resultat | StatusIndicator tekst | AlarmIndicator tekst | Konfiguration (property) |
|---|---|---|---|---|
DBHealthIndicator | Udførsel | Kalder databasen med "select 1" | Kalder databasen med "select 1" | datasource.odr.jndi-name=java:jboss/datasources/ODR-DS |
Status 200 | {"Database":"OK"} | |||
Status 500 | {"Database":"Unavailable"} | Der er ingen forbindelse til databasen med JNDI navnet <jndi> | ||
| StackedOperationsService (organDonorNotificationService) | Udførsel | Tjekker om den seneste kørsel af jobbet afsluttede med success | ||
Status 200 | ||||
Status 500 | Baggrundsjobbet StackedOperationsService fejlede sidst det blev kørt. Problemet var: <exception>. | |||
| NewestNotificationHealthIndicator | Udførsel | Henter den nyeste record fra tabel NotificationDate med status Completed | Tjekker om den seneste Completed record i NotificationDate ligger tidligere end det er tilladt at komme bagud. | digitalpost.notification.odr.alarm.date.period=P3D |
Status 200 | {"Nyeste færdigbehandlede dato":"Ingen"} eller {"Nyeste færdigbehandlede dato":"<dato>"} | |||
Status 500 | na - svarer altid 200 | Der er ikke færdigbehandlet en dato den: <dato>. Den er ældre end <dage> dage gammel. | ||
| StatusNotificationHealthIndicator | Udførsel | For hver status type hentes antal records fra tabel NotificationPerson | For hver status type (undtagen Completed) hentes antal records fra tabel NotificationPerson. Hvis dette antal er større end 0 og den seneste Completed record i NotificationDate ligger tidligere end det er tilladt at komme bagud. | digitalpost.notification.odr.alarm.date.period=P3D |
Status 200 | {"Antal i NotificationPerson med status <status>":"<antal>"} | |||
Status 500 | na - svarer altid 200 | Der ligger <antal> notifikationer fra den <dato> med status <status>. | ||
| ErrorNotificationHealthIndicator | Udførsel | Tjekker om der ligger records i tabel NotificationPerson, som har status Error. | ||
Status 200 | ||||
Status 500 | Der ligger totalt <antal> notifikationer med status Error. | |||
| PersonInformationHealthIndicator | Udførsel | Tjekker antal fejl inden for en given periode ikke overstiger maks | personinformation.error.tolerance=0 personinformation.errorcount.duration=PT10M | |
Status 200 | ||||
Status 500 | Person Information servicen har fejlet flere gange end tilladt i en given periode. | |||
| DigitalPostHealthIndicator | Udførsel | Tjekker antal fejl inden for en given periode ikke overstiger maks | digitalpost.error.tolerance=0 digitalpost.errorcount.duration=PT10M | |
Status 200 | ||||
Status 500 | Digital Post Adapter servicen har fejlet flere gange end tilladt i en given periode. |
Der er en max grænse for hvor lang tid jobbet må køre pr. gang (deletion.desired.execution.duration) 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.
OrganDonorDeceasedCleanupServlet
Baggrundsjobbet OrganDonorDeceasedCleanupServlet kaldes, når der skal ryddes op registreringer for person 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
...
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.