Konfiguration sker i filerne i "compose/configuration" mappen, følger den normale komponent-standard og består af følgende filer:
Konfigurationsfil | Beskrivelse |
|---|---|
| sores.properties | Applikations-navngivning samt opsætning af |
| sdm-ds.xml | Definition af datasource |
| log4j-sores.xml | Opsætning af log-niveau og -destination. Følger NSP-standard. |
Forskellige konfigurationsparametre kan styres via properties i filen sores.properties.
Property | Beskrivelse |
|---|---|
| app.name | Services navn. Default "SOR Enkeltopslags Service". |
| app.name.short | Servicens korte navn. Default: "sores" |
sdm.db.jndi | Datasource til sor-databasen. Det er en pegepind over på den der er angivet i sdm-ds.xml. |
sores.entityNameLookup.max.result.count | Et øvre grænse for, hvor mange entiteter, der kan returneres i operationen "entityNameLookup". Default er 5. |
sores.retention.period | En skæringsdato for hvor hvor langt tilbage i tid der ligger historik for i cachen. Angives som duration i ISO-8601 formattet. Default er "P2Y" (2 år). |
sores.cache.ttl | Værdi som angiver perioden, hvor en cache er Warm. Default er P2D (2 dage) |
sores.startup.reload | Styring af om reload kaldes under initialisering af servicen. Funktionen er som default slået til og kan kun de-aktiveres ved at angive værdien til false. Hvis der er en cache file og den ikke er af samme version som koden forventer, det kan ske hvis der er kommet et nyt feltet til cachen som ikke er der i den gamle version. Så bliver cachen bygges op fra ny. Version tjekkes, hver gange der sker en cachen reloade. |
sores.cache.file | Fil i containeren hvori cachen gemmes ved reload. Hvis databasen ikke er nyere end den allerede eksisterende cache, reloades kun fra filen. En fuld database-reload kan gennemtvinges ved at fjerne filen. |
sores.servlet.logging.interval | Angiver hvor ofte der skal laves logs over operationer. Angives som en ISO-8601 duration (f.eks. PT60M for 60 minutter). Default er PT60M. |
sores.servlet.logging.precision | Angiver hvor præcist varigheder logges. Mulige værdier: NANOS, MILLIS, MINUTES. Default er MILLIS. |
Servicen tilbyder i tilgift til NSPs standard-funktioner muligheden for at loade data i cache fra databasen:
Funktion | Beskrivelse | Eksempel-response |
|---|---|---|
| /status | NSP Standardfunktion. HTTP-response-code angiver servicens tilgængelighed | HTTP/1.1 200 OK |
| /version | NSP Standardfunktion. Versions-nummeret sendes som response-text | 1.0.0 |
| /reload | Genindlæser data fra databasen, hvis der er ændringer siden sidste indlæsning. Men kun hvis der ikke findes en cache-fil, eller hvis cache-filens indhold er ældre end databasen. Er cache-filen forældet, laves en fuld database reload. Hvis cache-filen ikke er af samme version som koden forventer, det kan ske hvis der er kommet et nyt feltet til cachen som ikke er der i den gamle version. Så bliver cachen bygges op fra ny. Version tjekkes, hver gange der sker en cachen reloade. Der kan kun være ét reload kørende ad gangen. Hvis et reload allerede er i gang, returneres en besked som denne: "Reload job already running since 2024-05-12 14:00:00" | 'Data from 2024-12-24 02:09:27 reloaded at 2025-05-12 10:46:54' |
I strukturen returneret fra kald til "/status" fås følgende kombinationer
Database available | Database Unavailable | |
|---|---|---|
| Cache Cold | HTTP/1.1 200 Status: Reload required | HTTP/1.1 500 Status: Unable to load cache |
| Cache Warm | HTTP/1.1 200 Status: OK | HTTP/1.1 200 Status: Degraded |
Ved "Degraded" og "Unable to load cache" bør driften foretage fejlfinding af forbindelsen til datasourcen.
Ved "Reload required" afventes næste curl-kald fra cron-containeren, der trigger et reload, og driften behøver ikke gøre noget. Kald foretaget efter reloadet er kørt til ende, bør returnere "OK".
SORES leveres med en docker-container, hvori et cron-job med fast interval kalder /reload på SORES-containeren.
Fejlfinding foregår ved gennemsyn af logfilerne. Der er ingen kendte fejl.
SORES bruger SOR registret i stamdata-databasen, og der er derfor ingen oprydning forbundet med SORES selv.
Logfiler håndteres efter NSP standard, og memory-cachen forsvinder, hvis servicen lukkes/genstartes.