Introduktion og overblik
Driftvejledningen indeholder information, som er relevant i forhold til drift af eCPR. Der gives en grundig introduktion til konfiguration, herunder hvilke properties der eksistere, samt deres standard konfiguration. Dertil kommer information om hvordan systemet overvåges i form af HTTP-endpoints samt Auditlog, SLA-logning samt øvrig logning.
eCPR består af én javabaseret web-service, nemlig eCPR-service. servicen har følgende afhængiheder:
- Der kræves adgang til en MariaDB datasource
- National adviserings service 2.0 (NAS)
- Kald til (læsning fra) CPR-Enkeltopslag (SCES)
- Læsning fra krs-stamdata gennem et view.
Dokument historik
Version | Dato | Ændring | Ansvarlig |
---|---|---|---|
0.1 | 23.10.2023 | Påbegyndt driftvejledningen | Trifork |
1.0 | -- | Initialt dokument | Trifork |
Konfiguration
Konfigurationen af eCPR sker i filerne i "compose/configuration" mappen som beskrevet i installationsvejledningen. I det følgende gennemgås hver enkelt services konfigurationsfiler i detaljer:
Konfiguration af eCPR-servicen
Overordnet konfiguration | Property | Beskrivelse |
---|---|---|
Database | spring.datasource.* | Dette er 4 properties der bruges til at konfigruere databasen, herunder driver class name, url, username og password |
Dcc | dcc.endpoint | Dette er adressen til eCPR udstillet til dcc'en |
Schema validering
| schemavalidation.validate.* | Boolean der angivre om request og/eller respons skal skemavalideres |
schemavalidation.fail.on.response.error | Angiver om der skal smides en fejl hvis responset ikke overholder skemaet (er skemavalid) | |
Lucene indexering
| jobs.searchindex.maxResut | Max antallet af resultater som lucene søgning kan returnere |
jobs.searchindex.enabled | Angiver om lucene indexeringsjobbet skal køre. Skal som udgangspunkt altid være enabled, for ellers forældes data i lucene indexet hurtigt. | |
jobs.searchindex.msInitialDelay | Angiver tiden fra start af deployment til første Lucene Indexerings kørsel | |
jobs.searchindex.msDelayBetween | Angiver hvor ofte lucene indexeringsjobbet skal køre | |
jobs.searchindex.InitialLoad.batchSize | Når opstarts indexeringen køres, angiver batchSize antallet af linjer, altså maximal datamængde, der indlæses ad gangen | |
jobs.searchindex.InitialLoad.msBetweenBatches | tiden mellem batches | |
jobs.searchindex.alwaysIndexFullDatabase | Angiver om alt data i databasen skal indexeres ved kørsel af lucene indexing | |
Slet reserverede eCPR-numre
| jobs.deletedReservedIDs.enabled | Hvis der reserveres en række eCPR-numre, så sættes der en udløbsdato på disse cpr-numre. Hvis ikke der er indlæst data inden udløbsdatoen er overskredet angiver denne property, om de reserverede eCPR-numre skal slettes |
jobs.deletedReservedIDs.executeEachMidnight | ??? | |
Export history to file
| jobs.exportHistoryToFile.enabled | Angiver om export jobbet skal køre. Dette angiver altså ikke kun om export jobbet skal gemmes til en fil, men om exportHistory jobbet skal køre i det hele taget |
jobs.exportHistoryToFile.initialDelay | Angiver tiden fra start af deployment til første exportHistory-job køres | |
jobs.exportHistoryToFile.delayBetween | Angiver tiden mellem to på hinanden følgende exportHistory jobs | |
jobs.exportHistoryToFile.initialLoad.batchSize | Når første exportHistory-job køres, angiver batchSize antallet af linjer, altså maximal datamængde, der indlæses ad gangen | |
jobs.exportHistoryToFile.initialLoad.msBeweenBatches | tiden mellem batches | |
temp.dir | temp.dir bliver brugt til at lagre midlerdigige exportHistory filer før de bliver zippet. Bør forblive den angivne fil. | |
ziptemp.dir | ziptemp.dir er en undermappe til temp.dir hvor zipfilen placeres inden den sendes | |
completedFileName | Navnet på zip-filen | |
temp.archive.dir | Denne fillokation er en undermappe til temp.dir, hvor zipfilen arkiveres efter den er sendt. | |
sftp.remote.dir | SKAL SLETTES | |
Upload zip-file to NSP-job
| jobs.uploadToNsp.* | Dette er tilsammen 3 properties, der konfigruerer hvorvidt exportHistory.zip-filen skal uploades til NSP samt initial delay og tiden mellem 2 jobs. |
sftp.enabled | ANgiver om sftp-funktionaliteten af jobbet er aktiveret. Hvis denne er disabled sendes exportHistory.zip-filen ikke til nsp uanset konfigurationen af jobs.uploadToNsp. | |
sftp.remote.path | Denne fil angiver hvor på modtagerserveren zip-filen skal placeres | |
sftp.hostname | ||
sftp.port | ||
sftp.username | ||
sftp.password | ||
Logginglevel
| logging.level.org.springframework.web | Disse to properties sætter logging level af springframeworket. Denne bør justeres til et lavt niveau inden eCPR sættes i produktion. Øvrige logningsniveauer er angivet i log4j konfigurationsfilen (NAVN!?) |
logging.level.org.springframework.security | ||
admin.service.shouldCheckPermissions | Propertien angiver, om der skal tjekkes, at brugere har de nødvendige rettigheder for at udføre det pågælende kald der er udført. | |
| spring.datasource.tomcat.connection-properties | Spørg Jakob |
Advis forwarding
| advis.enabled | Angiver om advisering til NAS er enabled |
nas.url | Angiver den endelige url til NAS | |
Sosi-certifikat | sosi.* | De relevandte sosi parametre er angivet sidst i propertyfilen. For at læse mere om sosi henvises til HVOR!? |
| sosi.sts.url | Endpoint for Secure Token Service (STS) |
| sosi.careprovider.name | Firmanavn fra systemcertifikat, som anvendes til DGWS adgang til DDS registry |
| sosi.careprovider.cvr | CVR-nummer fra systemcertifikat, som anvendes til DGWS adgang til DDS registry |
| sosi.production.federation | Angiver om det certifikat, der anvendes til adgang DGWS-adgang til DDS registrym, er et produktionscertifikat |
| Systemnavn fra systemcertifikat, som anvendes til DGWS adgang til DDS registry | |
| sosi.keystore.file | Navn på keystore med det systemcertifikat, som anvendes til DGWS adgang til DDS registry (Andre steder er det .path og ikke file, men er det mon det samme?) |
| sosi.keystore.password | Password til keystore med det systemcertifikat, som anvendes til DGWS adgang til DDS registry |
| sosi.timeout | Timeout for kald til DDS, angivet i millisekunder |
| isProduction | Denne bool angiver om systemet er i produktion. |
OBS! Husk at lav et link hertil fra installationsvejledningen!
Konfiguration af log4j2-ecpr2
OBS!! vent med at opdatere til log4j er degraderet til log4j2
Overvågning
Http Endpoints
Health status side (isAlive)
Servicen udstiller en Health-statusside (også typisk kendt som isAlive), der viser om applikationen er sund, eller om noget kræver en indgriben. Health-statussiden returnerer en body med en tekstrække, der beskriver sundhedsstatus for forskellig funktionalitet i eCPR-applikationen. IsAlive-overvågningen udstedes på http://localhost:8380/ecpr2/isAlive
Et eksempel på en sund service ses nedenfor:
Database Respond: 200 OK OK
Data Indexed: 200 OK OK
Title: ecpr2-service
Deployed: Mon Oct 23 12:35:45 CEST 2023
Build-Date: 2023-10-18T13:50:46Z
Build-Version: 1.28.18
Builder: trifork2
Display time: Mon Oct 23 16:10:27 CEST 2023
Lucene indexer job: Enabled, Last successful indexing: 2023-10-23T14:00:41.745Z, Error count: 0
Delete Reserved Person Ids job: Enabled, Last Exceeded Reserved Ids delete: Never, Error count: 0 |
Health Status siden returnerer HTTP statuskoden "200 OK" hvis både databasen responderer og hvis data i databasen succesfuldt er blevet indexeret af lucene. Hvis en af mulighederne ikke er sande returneres HTTP statuskoden "500 Internal Server Error".
De forskellige linjers betydning er forklaret nedenfor:
Titel på linje | Forklaring |
---|---|
Database Respond | Hvis databasen kører og er kontaktbar returneres 200 OK, og ellers returneres 500 Internal Server Error |
Data indexed | Indikerer om data indexeringen er kørt (ELLER?) |
Title | Titlen på servicen som er defineret HVOR? |
Deployed | Indikere tidspunketet, hvor servicen er deployet |
Builder | Indikere hvem der har bygget servicen samt hvornår servicen senest er blevet bygget, og hvilken version der her blev bygget. |
Display Time | TIdspunktet hvor HealtStatusSiden blev kaldt |
Lucene indexer job | Denne linje viser om Lucene indexering er konfigureret til at køre (Se property jobs.searchindex.enabled), hvornår seneste kørsel er sket samt antallet af gange lucene indexeringen er fejlet i streg, hvis indexeringen er fejlet. |
Delete Reserved Person Ids job | Viser om reserverede ID'er er opsat til at slettes (Se propertien jobs.deletedReservedIDs.enabled) , hvornår seneste sletning er udført, samt antallet af gange en sletning er fejlet i streg, ved seneste sletning |
exportHistory
ExportHistory-endpint bruges til overvågning af om HistoryExport-jobbet er blevet udført succesfuldt. Hvis export-jobbet er gennemført uden fejl returneres "200 OK", mens der ved fejl returneres "500 Internal Server Error".
Export History:
Http status: 200 OK
Error message: no error
Export number: 2
Export time of last export: 12/20/2022 19:45:05 |
De forskellige linjers betydning er forklaret nedenfor:
Titel | Forklaring |
---|---|
Http status | Dette viser status for export-jobbet. Hvis der returneres 200 OK er seneste export forløbet uden fejl, mens 500 Internal Server Error indikerer at der er opstået en fejl i seneste export job |
Error Messag | Hvis seneste export er exporteret med fejl udskrives fejlbeskeden her, og i alle andre tilfælde skrives "no error" |
Export number | Export number viser antallet af exportjobs, der er kørt, hvor der er blevet eller forsøgt exporteret data. Hvis exportjobbet er startet, men uden der har været ny data at exportere, så tælles dette ikke med i 'Export number' |
Export time of last export | Denne dato og tid er tidspunktet for den seneste gang exportjobbet er kørt, hvor der er eksporteret data fejlfrit. Hvis den seneste export er sket med fejl returneres tidspunktet for fejlen. |
Logning
eCPR-servicen logger på tre forskellige måder, som alle er uddybet nedenfor:
3.2.1 Auditlog
Hvornår skrives der til auditlogningen? Er der tilfælde hvor der ikke Auditlogges?
Er der et slrligt format/et eksempel på et format?
3.2.2 SLA logning
3.2.3 Intern logning
Til intern logning bruges Log4J, hvor logningsniveauet er specificeret i log4J konfigurationsfilen (se ovenfor).
Hvad er logningskonventionen i eCPR? Kan det bruges til debugging, eller hvad kan det bruges til?
Fejlfinding
Servicens logfiler kan med fordel løbende tjekkes for Error-logninger. Derudover kan de ovenstående endpoints bruges til hhv. at se den generelle status for servicen (isAlive) samt at overvåge om export af ændringer foreløber fejlfrit.