Page History
...
I produktion består Organdonorregister-servicen af et komponent 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
Version | Dato | Ændring | Ansvarlig |
---|---|---|---|
1.0.1 | 2018-08-17 | Initialt dokument | Trifork |
1.0.2 | 2018-08-31 | Ny release | Trifork |
1.0.3 | 2018-11-23 | Tilføjet admin endpoints | Trifork |
1.0.13 | 2019-25-09 | Ajourført | Trifork |
1.0.16 | 2020-05-25 | Opdateret slettejob | KIT |
1.0.17 | 2021-12-07 | Opdateret ifm inaktive cpr numre afvises | KvalitetsIT |
1.0.18 | 2023-09-26 | SDS-6386: ODR - oprydningsjob genbesøg | KvalitetsIT |
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.
...
URL | Funktionalitet |
---|---|
<server>/odr/isAlive | Status-side for servicen. Viser om servicen fungerer korrekt, 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-operations/syncjobodr-slettejob/start | Slettejob startes ved kald af denne url. Returnerer tidspunkt for modtaget request og altid http status kode 200. Eventuelle fejl skrives i loggen. |
<server>/odr-operations/syncjobodr-slettejob/status | Oplysninger om slettejob på den pågældende server. Oplysningerne gemmes i hukommelsen på serveren og fosvinder forsvinder ved genstart. Der returneres http status kode 200 og følgende data: tidspunkt kan returneres følgende fra statussnitfladen: 200: Komponenten fungerer og kan anvendes. Der returneres desuden følgende oplysninger i JSON format:
|
Daglig drift
Servicen kræver ingen daglig vedligeholdelse udover sædvanlig systemovervågning.
...
Servicen udstiller en status-side (isAlive). På denne side fremgår servicens version , og opstartstidspunkt mm. samt status for slettejob.
Eksempel på et response fra status-siden:
Code Block |
---|
200 OK Title: odr-service-wildfly Deployed: 20182023-0809-10T1026T08:5554:1722.777Z308Z Build-Date: 20182023-0809-10T1026T08:5253:22Z08Z Build-Version: 1.0.146-SNAPSHOT Builder: A robottkn Display time: 20182023-0809-10T1226T11:5706:4352.577Z Delete job: Enabled, Last successful deletion: 1900-01-01T00:00:00Z, Error count: 0454Z CprExistsServiceClient : "0 fejl" |
Status for baggrundsjobbet fremgår af <server>/odr-operations/odr-slettejob/status. Eksempel på denne statusside hvor jobbet er fejlet:
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:
...
Alle logninger er konfigureret med 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:
Logfilnavn | Indhold | Komponent |
---|---|---|
accesshandler.log | Log for accesshandler-biblioteket. | service / operations |
access.log |
Access-log. | service | |
audit.log | Auditlog. Indeholder logning af, hvem der har kaldt, hvilken SOAP-action der blev kaldt, hvilken person der blev kaldt for, hvordan der blev kaldt (DGWS/IDWS) og hvornår der blev kaldt. | service |
odr.log | Applikationslog for servicen, som indeholder de vigtigste systemhændelser. Root: WARN |
org.springframework.
core: INFO | service / operations | |
nsp-kafka.log | Log for kafka-produceren, som står for skrivning til MinLog. | service |
nsputil-sla-odr.log | SLA-log. Indeholder SLA-logninger for alle kald på servicen. Indeholder desuden SLA-logninger for servicens kald til MinLog. |
service | |
server.log | Log for Wildfly-serveren. |
service / operations |
Auditlog
Der er i ODR fire kategorier af audit logs; cpr, organdonor registrering, aktør og cpr validering
Følgende tabel viser hvilke kategorier der audit logges for hver operation i ODR.
Operation | Kontekst | Kategorier |
---|---|---|
CreateOrganDonorRegistration | createOrganDonorRegistration | organdonor registrering, aktør, cpr validering |
UpdateOrganDonorRegistration | updateOrganDonorRegistration | organdonor registrering, aktør, cpr validering |
DeleteOrganDonorRegistration | deleteOrganDonorRegistration | cpr, aktør, cpr validering |
GetOrganDonorRegistration | getOrganDonorRegistration | organdonor registrering, aktør, cpr validering |
HasOrganDonorRegistration | hasOrganDonorRegistration | cpr, aktør, cpr validering |
Følgende tabeller viser hvad der audit logges for hver af de fire kategorier.
cpr
Komponent | Kontekst | Type | Nøgle | Information |
---|---|---|---|---|
ODR | (afhængig af operation) | Følsomme | cpr | CPR på borgeren |
organdonor registrering
Komponent | Kontekst | Type | Nøgle | Information |
---|---|---|---|---|
ODR | (afhængig af operation) | Ikke Personlig | pid | ID på registrering |
ODR | (afhængig af operation) | Følsomme | cpr | CPR på borgeren |
ODR | (afhængig af operation) | Ikke Personlig | version | version feltet på registrering |
ODR | (afhængig af operation) | Ikke Personlig | modified | modified feltet på registrering |
ODR | (afhængig af operation) | Ikke Personlig | validFrom | validFrom feltet på registrering |
ODR | (afhængig af operation) | Ikke Personlig | validTo | validTo feltet på registrering |
ODR | (afhængig af operation) | Følsomme | permissionType | permissionType feltet på registrering |
ODR | (afhængig af operation) | Følsomme | heart | heart feltet på registrering |
ODR | (afhængig af operation) | Følsomme | kidneys | kidneys feltet på registrering |
ODR | (afhængig af operation) | Følsomme | lungs | lungs feltet på registrering |
ODR | (afhængig af operation) | Følsomme | corneas | corneas feltet på registrering |
ODR | (afhængig af operation) | Følsomme | liver | liver feltet på registrering |
ODR | (afhængig af operation) | Følsomme | smallIntestine | smallIntestine feltet på registrering |
ODR | (afhængig af operation) | Følsomme | pancreas | pancreas feltet på registrering |
ODR | (afhængig af operation) | Følsomme | skin | skin feltet på registrering |
ODR | (afhængig af operation) | Følsomme | relativeAcceptanceRequired | relativeAcceptanceRequired feltet på registrering |
aktør
Komponent | Kontekst | Type | Nøgle | Information |
---|---|---|---|---|
ODR | (afhængig af operation) | Følsomme | actor-cpr | CPR på aktør |
ODR | (afhængig af operation) | Personlig | actor-usertype | Typen af aktør |
cpr validering
Følgende logges kun hvis validerings mode er sat til WARNING.
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
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).
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
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 parametre parameter til styring af slettejobbet kan ændres i application.properties for ODR:
jobs.delete.cpr-max-results.time=25
jobs.delete.cpr-max-loops=2Hvor jobs.delete.cpr-max-results bestemmer antal af cpr numre, der skal udtrækkes til sletning. Og jobs.delete.cpr-max-loops bestemmer antal gange udtræk af cpr numre skal gennemføres.
Hvis tiden til afvikling af slettejob overskrider 20-25 sekunder, så bør ovenstående parametre gøres mindrePT20S
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:
curl <server>/odr-serviceoperations/syncjobodr-slettejob/start
Slettejobbet skal aktiveres hver dag, hvert 15. minut mellem 8-16 - startende kl. 8
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.