Page History
Table of Contents | ||
---|---|---|
|
Introduktion
Formål
Dette dokument er rettet mod systemadministratorer og driftspersoner, som skal kunne håndtere driftsmæssige aspekter af komponenten.
Driftsvejledningen indeholder information om Dokumentregistreringsservice (DRS) komponenten med hensyn til eksterne afhængigheder, standard placering af logfiler og konfigurationsfiler, og evt. krav til genstart af applikationer hvis komponenten ikke er responsiv.
I afsnit 2 er beskrevet hvilke komponenter, der indgår i DRS og deres forventede placering med hensyn til platform.
Afsnit 4 beskriver aktuelle konfigurationsparametre for DRS, samt eksempler på konfigurationsparameter-filer.
Afsnit 5.1, 5.2 og 5.3 beskriver hvorledes DRS komponenterne overvåges.
I afsnit 5.4 er DRS-relaterede logfiler beskrevet, så disse evt. kan overvåges, og tillige danne baggrund for fejlsøgning.
Beskrivelse af standard fejlsøgning og start/stop vejledning for komponenterne er beskrevet i afsnit 6.
Specielle krav til backup er beskrevet i afsnit 7, ligesom procedure ved reetablering af komponenten ud fra backup beskrives.
Læsevejledning
Læseren forventes at have kendskab til National Sundheds-IT’s platform NSP, samt generelt kendskab til WildFly applikationsserver, samt Ubuntu Linux operativ system.
Dokumenthistorik
Version | Dato | Ansvarlig | Beskrivelse |
0.8 | 13.10.2017 | KvalitetsIT | Initiel udgave |
0.9 | 25.10.2017 | KvalitetsIT | Tilrettet ifølge JIRA SDS-2194 |
Definitioner og referencer
Definition | Beskrivelse |
NSP | Den nationale service platform (inden for sundheds-IT) |
STS | Security Token Service |
Komponenter
Dette dokument dækker følgende komponenter på NSP:
Dokumentregistreringsservice
Type: Webservice
Filnavn: drs.war
Url: <serverurl>/drs
Servicecheckurl: <serverurl>/drs/health
Versionurl: <serverurl>/drs/health returnerer en json struktur med denne
DRS komponenten anvender desuden Aftale XDS Repository.
Daglig drift
Dette afsnit beskriver den daglige drift af systemet.
Relaterede services
DRS afhænger af tilstedeværelsen af andre services, og ved fejl i disse vil DRS fejle tilsvarende. Disse services er:
Aftale XDS Repository
Konfiguration
DRS
Servicekonfiguration
Grundlæggende konfiguration foregår ved redigering i filen application.properties der placeres i følgende WildFly modul:
/pack/wildfly8/modules/sds/drs/configuration/main/
Moduldefinitionen er at finde i sourcekoden til drs under:
/proxy/config/module.xml
I filen skal følgende properties være definerede:
Property | Beskrivelse |
environment | Værdien skal være én af følgende development/production Værdien afgør, hvorvidt SOSITestFederation eller SOSIFederation anvendes. |
dgwsheaders.remove | Værdien skal være én af følgende: true/false Angiver, om DGWS headers skal fjernes fra SOAP beskeden inden denne proxies videre til Aftale XDS Repository |
backend.url | Adressen på Aftale XDS Repositorys iti-41 endpoint |
log4j konfiguration
Log4j konfiguration findes i samme wildfly modul som servicekonfigurationen
Se yderligere opsætning i installationsvejledningen.
SLA-log konfiguration
SLA-log konfigurationen lægges i samme wildfly modul som servicekonfigurationen.
Se yderligere opsætning i installationsvejledningen.
HTTP Statuscheck på DRS
Til statuscheck af DRS forefindes en health URL (se ovenfor)
Test af versionsnummer
Hvis helbredsURLen ovenfor tilgåes, så kan man se versionsnummeret:
{ version: "0.0.1-SNAPSHOT"}
Overvågning
DRS overvåges af en servicespecifik servicechecksnitflade, hvis url kan aflæses i afsnit 2.
Fortolkning af Health URL
Health URL returnerer enten status 200, hvis de i øjeblikket kører fint, status 404 hvis servicen ikke er deployeret.
Logfiler og fortolkning af disse
Konfigureres i log4j properties
Standard fejlsøgning
Ved problemer med indlæsning af servicens konfigurationsfil (application.properties) bør man verificere at filen ligger korrekt i wildfly modulet.
Ved manglende logning bør konfigurationsfilen (log4j.properties samt log4j-nspslalog.properties) checkes, da logindstillingerne sættes herigennem.
En service eller et job kan genstartes ved at kalde touch på den tilsvarende war-fil. I yderste konsekvens kan WildFly genstartes ved at bruge /etc/init.d/wildfly8 restart.
Krav til backup m.m.
Det anbefales at aktuelle konfigurationsfiler er under versionskontrol og back up.