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 pegepind til datasource |
| sdm-ds.xml | Definition af datasource |
| log4j-sores.xml | Opsætning af log-niveau og -destination. Følger NSP-standard. |
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 | 'Reload done at 2020-04-01T12:00:00.000' |
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.