Page History
Navitabs | ||||
---|---|---|---|---|
|
Konfiguration
Konfiguration sker i filerne i "compose/configuration" mappen, følger den normale komponent-standard og består af følgende filer:
...
Konfigurationsfil
...
Beskrivelse
...
Applikations-navngivning samt opsætning af
datakilde-strategi (xml eller database)
pegepind til datasource og/eller lokation af xml-filer
...
Provisionering af datagrundlag
Hvis SORES er konfigureret til at bruge database-strategi, fødes data af SOR2-indlæseren, og driften skal ikke gøre noget specielt.
Hvis SORES er konfigureret til at bruge xml-strategi, skal driften dagligt downloade et SOR udtræk og udpakke de to filer Sor.xml
og SorDataTypes.xml
til lokationen angivet i sores.properties
.
Overvågning
Servicen tilbyder i tilgift til NSPs standard-funktioner muligheden for at loade data i cache fra databasen:
...
Funktion
...
Beskrivelse
...
Eksempel-response
...
HTTP/1.1 200 OK
{
"Version":"1.0.0",
"Cache":"Cold",
"CacheLoadTime":"-999999999-01-01T00:00",
"Database":"Available",
"Status":"Reload required"
}
...
Indledning
Nærværende dokument udgør driftsvejledningen for CRK. Komponenten er udviklet som en Java webapplikation og understøttes på Wildfly Application Server version 8.2.
Denne driftsvejledning er gældende for CRK version 1.0.x.
Eksterne afhængigheder
Der kræves som udgangspunkt INGEN adgang til tjenester på internettet. De enkelte jobs, som indlæser endpoint definitioner kan dog være opsat til at hente denne fra en ekstern URL.
Placering af logfiler
Komponenten logger til sin egen rullende log som hedder crk.log.
Logfiler er volume-mappet, så de er tilgængelige på docker-hosten, men af historiske hensyn kan det nævnes, at inde i containeren ligger logfilerne på Wildfly platformen i:
|
hvor '$JBOSS_HOME' udpeger roden på Wildfly Application Server installationen.
Indgange i loggen indeholder en kort beskrivelse af hændelsen, tidspunktet samt hændelsens alvorlighedsgrad ('Severity').
Ved drift bør der ikke være indgange af alvorlighedsgrad 'ERROR' i loggen. Se overvågningsvejledning nedenfor.
Placering af konfigurationsfiler
Komponentens konfiguration udgøres af filerne i folderen 'CRK' som er placeret under
|
Bemærk, at disse også er volume-mappet ind.
Ændringer i konfigurationen af komponenten træder først i kraft efter genstart af komponenten. Se vejledning nedenfor.
Start/stop vejledning
Komponenten stoppes og startes gennem docker.
Efter genstart bør der verificeres at der ikke er nogen indgange med alvorlighedsgrad 'ERROR' i komponentens log.
Overvågning
Udover at overvåge selve applikationsserveren for ressourceknaphed og generelle fejl kan man overvåge CRK ved at:
- Sikre, at endpointet svarer, ved at foretage simple HTTP GET kald mod komponents 'check' status side:
- http://<HOST>:<PORT>/crk/checkstatus
Denne angiver pt blot antallet af aktive endpoints i konfigurationen og kan anvendes til at afgøre om komponenten er "I live".
- http://<HOST>:<PORT>/crk/checkstatus
- Overvåge komponentens logfil for 'ERROR' indgange
Versionsudstilling
CRK udstiller sit versionsnummer på følgende endpoint: http://<HOST>:<PORT>/crk/version. Endpointet svarer på GET-requests, og versionsnummeret kommer i body'en af svaret. Eksempel på kald af endpoint:
curl -i localhost:8060/crk/version
Eksempel på response:
Code Block |
---|
HTTP/1.1 200 OK
Connection: keep-alive
X-Powered-By: Undertow/1
Server: WildFly/8
Transfer-Encoding: chunked
Date: Thu, 16 Sep 2021 07:33:16 GMT
Version: 1.0.8-SNAPSHOT |
Administrativ overskrivning af konfiguration
Ved (genindlæsning) af endpoint definition fra ekstern kilde oprettes en ny version af endpoint i databasen. Tidligere versioner af samme endpoint deaktiveres. Nye actions oprettes (som aktive) i databasen som peger på den nye version af endpointet. Såfremt en tidligere aktiv action bortfalder for et endpoint, vil den gamle værdi blive kopieret med angivelse af kilde.
Dette åbner et antal muligheder for administrativt at påvirke DCC konfigurationen (se installationsvejledningen for en oversigt over de nedenfor anvendte konfigurationsfiler).
Deaktivering af endpoint
Det er muligt helt at deaktivere et endpoint. Dette kan gøres ved at markere den aktive version som active=false.
Bemærk at det kan være nyttigt at forhindre genindlæsning ved at disable det tilsvarende job i crk-jobs.xml.
Rollback til tidligere version af endpoint
Det er muligt at rulle et endpoint tilbage til en tidligere version. Dette kan gøres ved at markere den aktive version som active=false, og markere den tidligere version med active=true.
Bemærk at det kan være nyttigt at forhindre genindlæsning ved at disable det tilsvarende job i crk-jobs.xml. Herved undgås utilsigtet "reaktivering" af den nye version.
Deaktivering af action
En action kan deaktiveres ved at markere den med active=false. Den vil herefter ikke længere være aktiv i DCC konfigurationen.
Ved opdatering fra ekstern kilde, vil denne action blive reaktiveret hvis og kun hvis den er indeholdt i den nye end point definition.
Håndtering af nedlagte actions
Såfremt en tidligere aktiv action bortfalder for et endpoint, vil den gamle værdi blive kopieret med angivelse af kilde. Tilstedeværelsen af kilde angivelse ("inheritedEndpoint") kan således fortolkes som et "deprekeringsflag".
Der kan herefter administrativt tages stilling til om denne action helt skal bortfalde i DCC-konfigurationen, hvilket kan ske ved markering active=false for pågældende action.
Overskrivning af gateway egenskab
Såfremt den eksterne kilde angiver at en action kræver et niveau 4 id-kort (MOCES), sættes useProxy til true. Dvs det tillades DCC at køre forespørgsler til denne action igennem en SOSI-GW.
Det er muligt at overskrive denne værdi ved at definere proxyOverride. En definition af proxyOverride har fortrinsret, og vil blive bevaret ved fremtidige opdateringer af pågældende action (værdien kopieres fra tidligere versioner).
Backup
Der bør foretages backup af komponentens egne konfigurationsfiler hver gang konfigurationen ændres.
For at gøre eventuelt fejlfinding nemmere anbefales det, at der ligeledes tages backup af komponentens logfiler.
Kendte fejl
Der pt. ingen kendte fejl
Status og forventet reaktion herpå
I strukturen returneret fra kald til "/status" fås følgende kombinationer
...
Database available
...
Database Unavailable
...
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".
Cache-reload
SORES leveres med en docker-container, hvori et cron-job med fast interval kalder /reload på SORES-containeren.
Fejlfinding
Fejlfinding foregår ved gennemsyn af logfilerne. Der er ingen kendte fejl.
Oprydning
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.