Overblik
Driftsvejledningen indeholder information der er relevant for driften af Stamkortregister-servicen (SKR), herunder oplysninger om standard placering af log- og konfigurationsfiler, eksterne afhængigheder og fejlfinding.
I produktion består Stamkortregister-servicen af to komponenter (war-arkiver) der er deployet på en Wildfly applikationsserver:
- skr-service: Selve Stamkortregister-servicen. Denne afhænger af adgang til 2 MariaDB datasources. Desuden afhænger den af at kunne kalde (skrive til) MinLog-servicen og NAS.
- skr-operations: REST-service til baggrundsjobs, som kaldes af driften.
Ændringslog
Version | Dato | Ændring | Ansvarlig |
|---|---|---|---|
1.0.0 | 2018-08-31 | Initialt dokument | Trifork |
| 1.0.11 | 2019-08-02 | Ændret WSDL-stier | Trifork |
| 1.0.12 | 2019-25-09 | Ajourført | Trifork |
| 1.0.17 | 2019-08-10 | Ændret SWDL | |
| 1.0.18 | 2020-10-07 | Opdateret slettejob | KIT |
| 1.0.19 | 2021-04-13 | Tilføjet NAS | KIT |
| 1.0.20 | 2021-04-27 | Tilføjet WSDL-sti | KIT |
| 1.0.21 | 2021-06-08 | Tilføjet WSDL-stier | KIT |
Funktionalitet
SKR 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>/skr/isAlive | Status-side for servicen. Viser om servicen fungerer korrekt, se afsnittet Overvågning. |
<server>/skr/skr | Webservice-dispatcher (dispatcher videre til korrekt version baseret på SOAP Action) |
<server>/skr/20210602 | Webservice-endpoint (for 20210602 udgave) |
<server>/skr/20200728 | Webservice-endpoint (for 20200728 udgave) |
<server>/skr/20190801 | Webservice-endpoint (for 20190801 udgave) |
<server>/skr/20180501 | Webservice-endpoint (for 20180501 udgave) |
<server>/skr/dksconfig | DCC auto-konfigurations API. Anvendes til konfiguration af NSP'ens DCC. |
<server>/skr/wsdl | HTML-side med links til download af WSDL-filer i hhv. DGWS- og IDWS-udgave. |
<server>/skr/wsdl/dgws20200728 | DGWS WSDL |
<server>/skr/wsdl/idws20200728 | IDWS WSDL |
<server>/skr/wsdl/dgws20210602 | DGWS WSDL |
<server>/skr/wsdl/idws20210602 | IDWS WSDL |
<server>/skr/wsdl/dgws20210408 | DGWS WSDL for migreringssnitflade |
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: skr-service Deployed: 2018-08-10T10:55:17.777Z Build-Date: 2018-08-10T10:52:22Z Build-Version: 1.0.0-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 logs benytter 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. |
skr_service.log | Applikationslog for servicen, som indeholder de vigtigste systemhændelser. Root: WARN |
nsp-kafka.log | Log for kafka-produceren, som står for skrivning til MinLog. |
| nsputil-sla-skr.log | SLA-log. Indeholder SLA-logninger for alle kald på servicen. Indeholder desuden SLA-logninger for servicens kald til MinLog og NAS. |
| server.log | Log for Wildfly-serveren. |
Auditlog
Der er i SKR tre kategorier af audit logs; cpr, aktør og cpr validering
Følgende tabel viser hvilke kategorier der audit logges for hver operation i SKR.
| Operation | Kontekst | Kategorier |
|---|---|---|
| GetPersonalDataCard | getPersonalDataCard | cpr, aktør, cpr validering |
| UpdateContactInformation | updateContactInformation | cpr, aktør, cpr validering |
| CreateRelatives | createRelatives | cpr, aktør, cpr validering |
| UpdateRelatives | updateRelatives | cpr, aktør, cpr validering |
| DeleteRelatives | deleteRelatives | cpr, aktør, cpr validering |
| CreateTemporaryAddress | createTemporaryAddress | cpr, aktør, cpr validering |
| UpdateTemporaryAddress | updateTemporaryAddress | cpr, aktør, cpr validering |
| DeleteTemporaryAddress | deleteTemporaryAddress | cpr, aktør, cpr validering |
| CreateLanguage | createLanguage | cpr, aktør, cpr validering |
| UpdateLanguage | updateLanguage | cpr, aktør, cpr validering |
| DeleteLanguage | deleteLanguage | cpr, aktør, cpr validering |
| CreateHealthProvider | createHealthProvider | cpr, aktør, cpr validering |
| UpdateHealthProvider | updateHealthProvider | cpr, aktør, cpr validering |
| DeleteHealthProvider | deleteHealthProvider | cpr, aktør, cpr validering |
| SaveDataCard | saveDataCard | cpr, aktør, cpr validering |
| MigratePersonalDataCard | migratePersonalDataCard | cpr, aktør, cpr validering |
Følgende tabeller viser hvad der audit logges for hver af de tre kategorier.
cpr
| Komponent | Kontekst | Type | Nøgle | Information |
|---|---|---|---|---|
| SKR | (afhængig af operation) | Følsomme | cpr | CPR på borgeren |
aktør
| Komponent | Kontekst | Type | Nøgle | Information |
|---|---|---|---|---|
| SKR | (afhængig af operation) | Ikke Personlig | actor-pid | PID på aktør |
| SKR | (afhængig af operation) | Følsomme | actor-person-id | ID på aktør |
| SKR | (afhængig af operation) | Personlig | actor-person-id-source | Typen af ID på aktør |
| SKR | (afhængig af operation) | Personlig | actor-usertype | Typen af aktør |
| SKR | (afhængig af operation) | Personlig | actor-user-relation | Aktørens relation til borger |
cpr validering
Følgende logges kun hvis validerings mode er sat til WARNING.
| Komponent | Kontekst | Type | Nøgle | Information |
|---|---|---|---|---|
| SKR | validateCpr | Følsomme | cpr-does-not-exist | Medsendt CPR nummer (hvis det ikke findes i CPR register) |
MinLog
Der er i SKR fire brugertyper: Borger, borger på vegne af borger, sundhedsfaglig og system bruger.
Følgende tabel viser for hvilke operationer og brugertype kombinationer, der logges til minlog (x=der logges).
| Operation / brugertype | Borger | Borger på vegne af borger | Sundhedsfaglig | System bruger |
|---|---|---|---|---|
| getPersonalDataCard | x | x | ||
| updateContactInformation | x | x | x | |
| createRelatives, updateRelatives, markRelativesAsDeleted | x | x | x | |
| createLanguage, updateLanguage, markLanguageAsDeleted | x | x | x | |
| createTempAddress, updateTempAddress, markTempAddressAsDeleted | x | x | x | |
| createHealthProvider, updateHealthProvider, markHealthProviderAsDeleted | x | x | x | |
| saveDataCard | x | x | x |
Whitelisting af anvendere
De enkelte anvendere skal whitelistes til at bruge SKR. Der findes en tabel whitelist til dette formål. Det er anvenders certifikat, der whitelistes.
Det er oplysningen CVR der skal anvendes i til at indsætte i whitelisting tabellen.
Brugeren kan hvidlistes til forskellige funktioner: SKR og SaveDataCard. Funktionen "SaveDataCard" giver brugeren mulighed for at ringe til SaveDataCardService. Funktionen "SKR" giver brugeren mulighed for at kalde alle andre servicemetoder.
Certifikatet whitelistes ved følgende SQL:
INSERT INTO whitelist (cvr, function) VALUES ('46837428', 'SKR');
Baggrundsjobs
Servicens baggrundsjobs bliver afviklet vha. udstillede REST services, som kaldes vha. simple 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.
For hvert baggrundsjob, vedligeholder driften en cron, som kalder jobbets url i et fast mønster vha. curl.
Slettejob
Slettejobbet ligger i skr-service komponenten.
Følgende parametre til styring af slettejobbet kan ændres i application.properties:
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.
Endpoints til slettejob:
| URL | Beskrivelse |
|---|---|
<server>/skr/syncjob/start | Slettejob startes ved kald af denne url. Returnerer tidspunkt for modtaget request og http status kode 200 |
<server>/skr/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) |
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)
Oprydningsjob
Oprydningsjobs ligger i skr-operations komponenten.
Implementationerne følger husreglerne for baggrundsjobs og understøtter derfor samtidige kald.
Løsningerne bruger in-memory stak, hvorpå der løbende bliver påfyldt opgaver. Opgaver bliver altid lagt på stakken i tilfældig rækkefølge.
Ved hver kørsel, bliver der enten fyldt nye opgaver på stakken, eller der bliver taget en opgave fra stakken, som bliver udført.
Opgaver på stakken kan enten være en operation til at udføre en oprydning eller en supplier, der leverer flere opgaver til stakken.
CPR Oprydningsjob
| URL | Beskrivelse |
|---|---|
<server>/skr-operations/cpr-cleanup/start | Starter CPR oprydningsjobbet |
<server>/skr-operations/cpr-cleanup/status | Returnerer statuskoden for seneste kørsel af oprydningsjobbet. Har oprydningsjobbet ikke kørt endnu, returneres statuskode 200 |
Der benyttes tre typer af suppliers og en operation:
| Supplier | Beskrivelse |
|---|---|
| Default supplier | Benyttes til at fylde opgaver på stakken, når stakken er tom. For hvert af tallene 0-9, oprettes en suffix baseret supplier |
| Suffix baseret supplier | Givet et tal, hentes alle person id'er fra skr databasen, der slutter på dette tal. Opretter en mængde batch suppliers, hver med et konfigurerbart antal af disse person id'er |
| Batch supplier | Givet en liste af person id'er, hentes for hvert id alle de cpr numre der er gemt i fritekstfelter i personens stamkort. For hvert person id og tilhørende liste af cpr numre, oprettes et cpr oprydningsjob. |
| Operation | Beskrivelse |
|---|---|
| Cpr oprydningsjob | Givet et person id og en liste af cpr numre, erstattes alle disse cpr numre med X'er i personens stamkort. Der udsendes herefter en NAS notifikation. |
OBS: Loggen for dette job kommer til at indeholde maskerede cpr numre (cpr numre, hvor de sidste 4 cifre er udskiftet med X'er), og skal derfor behandles som en audit log.
Telefonnumre oprydningsjob
| URL | Beskrivelse |
|---|---|
<server>/skr-operations/phonenumber-cleanup/start | Starter oprydningsjobbet til at slette ugyldige telefonnumre |
<server>/skr-operations/phonenumber-cleanup/status | Returnerer statuskoden for seneste kørsel af oprydningsjobbet. Har oprydningsjobbet ikke kørt endnu, returneres statuskode 200 |
Der benyttes tre typer af suppliers og en operation:
| Supplier | Beskrivelse |
|---|---|
| Default supplier | Benyttes til at fylde opgaver på stakken, når stakken er tom. For hvert af tallene 0-9, oprettes en suffix baseret supplier |
| Suffix baseret supplier | Givet et tal, hentes alle person id'er fra skr databasen, der slutter på dette tal. Opretter en mængde batch suppliers, hver med et konfigurerbart antal af disse person id'er |
| Batch supplier | Givet en liste af person id'er, hentes for hvert id alle de telefonnumre der ikke overholder gyldig format fra personens stamkort. For hvert person id og tilhørende liste af telefonnumre, oprettes et telefonnummer oprydningsjob. |
| Operation | Beskrivelse |
|---|---|
| Telefonnummer oprydningsjob | Givet et person id og en liste af telefonnumre, slette alle disse telefonnumre r i personens stamkort. Der udsendes herefter en NAS notifikation. |
OBS: Loggen for dette job kommer til at indeholde maskerede cpr numre (cpr numre, hvor de sidste 4 cifre er udskiftet med X'er), og skal derfor behandles som en audit log.
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.