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-operations/odr-slettejob/deceased/start | Slettejob 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/statusOplysninger | om slettejob på den pågældende server. Oplysningerne gemmes i hukommelsen på serveren og forsvinder ved genstart. Dette kald verificerer databaseadgang. Der kan returneres følgende fra statussnitfladen: 200: Der er adgang til databasen og jobbet kan anvendes. Der returneres desuden følgende oplysninger i JSON format:
| ||||||
<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.
...
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, 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 |
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
HTTP/1.1 500 Internal Server Error Connection: keep-alive X-Powered-By: Undertow/1 Server: WildFly/8 Transfer-Encoding: chunked Content-Type: text/plain;charset=ISO-8859-1 Date: Mon, 4 Dec 2024 16:32:48 GMT 203 Non-Authoritative Information from: CprExistsServiceClient Antal fejl: 56 2024-12-04T16:24:32.480: Fejl i retursvar fra CPRExist |
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 og alarm-siderne 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 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.
...
Driften vedligeholder en cron, som kalder slettejobbets url i et fast mønster vha. curl.
Følgende parameter parametre til styring af slettejobbet kan ændres i applicationcleanup.properties for ODR:
| Nøgle | Default værdi | Beskrivelse |
|---|---|---|
| deletion.desired.execution.duration | 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 | 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. |
| deletion.batchsize | 1000 | Max. antal entries (f.eks. CPR) vi behandler pr. batch |
| personinformation.batchsize | 100 | Max. antal CPR vi forespørger på i en enkelt request til personinformation |
| personinformation.url | http://test1-cnsp.ekstern-test.nspop.dk:8080/stamdata-personinformation/v1 | 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.error.tolerance | 0 | Tolerance for hvor mange fejl PersonInformation servicen må have inden den melder tilbage at den ikke virker. |
deletion.desired.execution.durationjobs.delete.max.time=PT20S
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.
...