Dette dokument er rettet mod systemadministratorer og driftspersoner, som skal kunne håndtere driftsmæssige aspekter af komponenten.
Driftsvejledningen indeholder information om DPA med hensyn til eksterne afhængigheder, standard placering af logfiler og konfigurationsfiler, og evt. krav til genstart af applikationer hvis komponenten ikke er responsiv.
I afsnit 3 (Komponenter) er beskrevet hvilke komponenter, der indgår i DPA og deres forventede placering med hensyn til platform.
Afsnit 5 (Konfiguration) beskriver aktuelle konfigurationsparametre for DPA, samt eksempler på konfigurationsparameter-filer.
Afsnit 6.1, 6.2 og 6.3 (Overvågning) beskriver hvorledes DPA komponenterne overvåges.
I afsnit 6.4 er DPA-relaterede logfiler beskrevet, så disse evt. kan overvåges, og tillige danne baggrund for fejlsøgning.
Beskrivelse af standard fejlsøgning og start/stop vejledning for komponenterne er beskrevet i afsnit 7 (Standard fejlsøgning).
Specielle krav til backup er beskrevet i afsnit 8 (Krav til backup m.m.), ligesom procedure ved reetablering af komponenten ud fra backup beskrives.
Læseren forventes at have kendskab til NSP miljøet.
Definition | Beskrivelse |
|---|---|
| NSP | Den nationale service platform |
| SDS | Sundhedsdatastyrelsen |
Dette dokument dækker følgende komponenter:
Dette afsnit beskriver den daglige drift af systemet.
DPA afhænger af tilstedeværelsen af en række andre services, og ved fejl i nogle af disse vil DPA fejle tilsvarende. Disse services er:
DPA forventer at modtage et kald til <serverurl>/digitalpostOperations/sendDigitalPost med jævne mellemrum. Når jobbet aktiveres køres det i op mod digitalpost.send.desired.execution.duration tid. Propertien er som udgangspunkt sat til 20 sekunder.
Dette kald vil føre til afsendelse af de breve der ved kald til SOAP-endpointed er skrevet i databasen, og de breve der ved tidligere aktiveringer af dette job er fejlet.
Jobbet vil logge hvor lang tid der er brugt, og hvor mange operationer der er tilbage (svarende nogenlunde til hvor mange breve der ikke er afsendt).
Hvis jobbet aktiveres mens der allerede er en kørsel i gang vil den nye kørsel gå i gang efter første kørsel er færdig (synchronized metode i java). Den vil dog tælle sin kørsels-tid fra punktet hvor kaldet blev foretaget, ikke fra punktet hvor første kørsel var færdig, og der vil derfor ikke blive en uendelig obhobning af jobs.
Hvor ofte jobbet bør aktiveres afhænger af, hvor mange breve der sendes, og kan evt. tilpasses ud fra log-beskeder og antal usendte beskeder i alarm-endpoint.
Komponenterne afvikles i et docker-compo3 setup, som ligger under https://git.nspop.dk/projects/COM/repos/digital-post-adapter/browse/compose.
Log4j konfiguration findes i (hvis ovenstående format anvendes): compose/configuration/log4j.properties filen
Se yderligere opsætning i installationsvejledningen.
Konfiguration af SLA-log findes i: compose/configuration/nspslalog-dpa.properties filen
Der foretages whitelisting ved check mod databasen. En ny whitelisting kan tilføjes med følgende SQL insert:
INSERT INTO whitelist (persistent_unique_key, it_system_name, template_id, comment)
VALUES ('some-key-here', 'some-it-system-name-here', 'fgvhr/20241218/BekraeftelseRegistreringFravalg', 'some-reason-for-whitelisting-here'); |
Databasen skal indeholde alle de skabeloner som DPK understøtter i det tilsvarende miljø. Disse kan findes på https://github.com/trifork/dpk-docs/wiki/Templates. Her er deres DPK-navn og deres Substitutionsværdier. Der vil som udgangspunkt være 2 DPK-templates med samme indhold, 1 til fysiske breve og 1 til digitale breve. De vil i DPA samles til 1 template, hvis navn er tilsvarende, men uden reference til om den er digital eller physical. F.eks. vil fgvhr/20241218/digital/BekraeftelseRegistreringFravalg og fgvhr/20241218/physical/BekraeftelseRegistreringFravalg blive samlet til fgvhr/20241218/BekraeftelseRegistreringFravalg.
Nye skabeloner tilføjes til databasen med følgende SQL insert:
INSERT INTO template (identifier, dpk_identifier, template_type)
VALUES ('DPA-template-key-here', 'DPK-digital-template-key-here', 'DIGITAL'), ('DPA-template-key-here', 'DPK-physical-template-key-here', 'PHYSICAL'); |
Substitutionsværdier indsættes med følgende SQL insert. Regex for date-felter skal være "\d{4}-\d{2}-\d{2}" svarende til et dato-format på "YYYY-MM-DD". For andre felter kan regex være ".*":
INSERT INTO template_detail_rule (template_identifier, detail_name, regex, optional)
VALUES ('DPA-template-key-here', 'substitution-value-name-here', 'regex-here', 1 or 0); |
Konfigurationen af servicen findes i: compose/configuration/dpa.properties filen
| Property | Beskrivelse | Påkrævet |
|---|---|---|
| dpk.url | URL til Digital Post Komponent | Ja |
| person_information.url | URL til Person Information | Ja |
| datasource.jndi | Navn på jboss datasource (defineret i dpa-ds.xml) | Ja |
| digitalpost.send.limit | Maksimalt antal breve der skal behandles i 1 aktivering af send-jobbet | Ja |
| digitalpost.send.desired.execution.duration | Ønsket varighed af send-jobbet | Ja |
| service.contract.endpoint | URL som skrives ind i WSDL | Ja |
Til statuscheck af DPA udstilles <serverurl>/digitalpost/status som returnerer HTTP 200 hvis servicen i øjeblikket kører fint og HTTP 503 hvis der er opstået en fejl der kræver indgriben.
DPA overvåges på <serverurl>/digitalpost/alarm.
Overvågningssiden returnerer enten status 200 hvis de i øjeblikket kører fint, status 404 hvis servicen ikke er deployeret og status 500, hvis der er opstået en fejl, og komponenten derfor ikke virker korrekt.
Derudover returneres evt. følgende fejlbeskeder hvis de er opfyldt:
Fejlbeskederne med fejl angiver altid den seneste fejl for et givet brev.
Hvert servicekald medfører en ny indgang i auditloggen, som kan være udfyldt med følgende komponenter:
| Komponent | Kontekst | Type | Nøgle | Information |
|---|---|---|---|---|
| DPA | UUID for kaldet | Følsom | request | Indhold af kald mod DPK |
| DPA | UUID for kaldet | Følsom | response | Indhold af svar fra DPK |
| DPA | UUID for kaldet | Følsom | modtager-cpr | Modtagerens CPR |
| DPA | UUID for kaldet | Ikke personlig | messageId | Besked ID for kaldet. Samme som Kontekst. |
| DPA | UUID for kaldet | Ikke personlig | skabelon | Navn på skabelonen. Ikke nødvendigvis samme som hos DPK |
Det anbefales at aktuelle konfigurationsfiler til DPA er under versionskontrol og back up.
| 3/4 2025 | Martin Henriksen/SDS | Etablering af dokumentation |
| 4/6 2025 | Markus Andreassen/Trifork | Udfyldelse af dokumentation |
| 28/7 2025 | Markus Andreassen/Trifork | Udvidelse af dokumentation ifbm. QA |