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 et komponent (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.

Æ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

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

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/syncjob/start	Slettejob startes ved kald af denne url. Returnerer tidspunkt for modtaget request og http status kode 200
<server>/odr/syncjob/status	Oplysninger om slettejob på den pågældende server. Oplysningerne gemmes i hukommelsen på serveren og fosvinder ved genstart. Der returneres http status kode 200 og følgende data: tidspunkt for sidste afvikling af slettejob på serveren (hvis værdien findes ellers tom værdi), status for sidste afvikling på serveren (true=ingen fejl, false=fejl, tom tekst=ikke afviklet) og fejlbesked ved sidste afvikling (hvis findes ellers er værdien udeladt)

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 en status-side (isAlive). På denne side fremgår servicens version, opstartstidspunkt mm. samt status for slettejob.

Eksempel på et response fra status-siden:

200 OK

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

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 mindst én 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 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:

Logfilnavn	Indhold
accesshandler.log	Log for accesshandler-biblioteket.
access.log	Access-log.
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.
odr_service.log	Applikationslog for servicen, som indeholder de vigtigste systemhændelser. Root: WARN org.springframework.core: INFO dk.sundhedsdatastyrelsen.organdonor: INFO
nsp-kafka.log	Log for kafka-produceren, som står for skrivning til MinLog.
nsputil-sla-odr.log	SLA-log. Indeholder SLA-logninger for alle kald på servicen. Indeholder desuden SLA-logninger for servicens kald til MinLog.
server.log	Log for Wildfly-serveren.

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

cpr

Komponent	Kontekst	Type	Nøgle	Information
ODR	(afhængig af operation)	Personlig	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)	Personlig	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)	Personlig	actor-cpr	CPR på aktør
ODR	(afhængig af operation)	Personlig	actor-firstname	Fornavn på aktør
ODR	(afhængig af operation)	Personlig	actor-lastname	Efternavn på aktør
ODR	(afhængig af operation)	Personlig	actor-usertype	Typen af aktør
ODR	(afhængig af operation)	Personlig	actor-authorisation-number	Autorisationsnummer på aktør
ODR	(afhængig af operation)	Personlig	actor-education-code	Uddannelseskode på aktør
ODR	(afhængig af operation)	Personlig	actor-organisation-id	Organisations ID på aktør
ODR	(afhængig af operation)	Personlig	actor-organisation-id-source	Typen af organisations ID
ODR	(afhængig af operation)	Personlig	actor-organisation-name	Organisationsnavn på aktør

cpr validering

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

Komponent	Kontekst	Type	Nøgle	Information
ODR	validateCpr	Personlig	cpr-does-not-exist	Medsendt CPR nummer (hvis det ikke findes i CPR register)
ODR	validateCpr	Personlig	cpr-inactive	Medsendt CPR nummer (hvis det er inaktivt)

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 til styring af slettejobbet kan ændres i application.properties for ODR:

jobs.delete.cpr-max-results=25
jobs.delete.cpr-max-loops=2

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

Kommando til kald af slettejob:

curl <server>/odr-service/syncjob/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.