Indholdsfortegnelse

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 GM-BFF 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 3 (Komponenter) er beskrevet hvilke komponenter, der indgår i GM-BFF og deres forventede placering med hensyn til platform.

Afsnit 5 (Konfiguration) beskriver aktuelle konfigurationsparametre for GM-BFF henholdsvis Repository, samt eksempler på konfigurationsparameter-filer.

Afsnit 6.1, 6.2 og 6.3 (Overvågning) beskriver hvorledes GM-BFF komponenterne overvåges.

I afsnit 6.4 er GM-BFF-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 7 (Standard fejlsøgning).

Specielle krav til backup er beskrevet i afsnit 8 (Krav til backup m.m.), ligesom procedure ved reetablering af komponenten ud fra backup beskrives.

Læsevejledning

Læseren forventes at have kendskab til Spring boot applikationer

Definitioner og referencer

Daglig drift

Dette afsnit beskriver den daglige drift af gm-bff.

Relaterede services

gm-bff afhænger af tilstedeværelsen af en række andre services, og ved fejl i nogle af disse vil gm-bff fejle tilsvarende. Disse services er:

• CMS - Content Management System
• KeyCloak til validering json web token i formatet JTP-H 
• GM-Facade - til fremsøgning af journal data og bestilling af journal via digital post.

Konfiguration

gm-bff kan afvikles i et docker setup, hvor image bygges ved at kalde:

mvn -B spring-boot:build-image --file pom.xml
-DskipTests
-Drevision=${{ env.BUILD_ID }}
-Dspring-boot.build-image.imageName=${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ env.BUILD_ID }}
-Dspring-boot.build-image.publish=true
-Ddocker.credentials.url=${{ env.REGISTRY }}
-Ddocker.credentials.username=${{ github.repository_owner }}
-Ddocker.credentials.password=${{ secrets.GITHUB_TOKEN }}

Bemærk, ovenstående opsætning er taget fra GitHub Action pipeline. 

log4j konfiguration

Log4j konfiguration findes i (hvis ovenstående format anvendes):

SLA-log konfiguration

Konfiguration af SLA-log findes i filen:

Whitelist konfiguration

Der foretages whitelisting ...

Monitorering

Til statuscheck af GM-BFF

Overvågning

GM-BFF overvåges ...

Placering af HTML overvågningsside

...

Fortolkning af HTML overvågningsside

Alle overvågningssider returnerer enten status 200 hvis de i øjeblikket kører fint, status 404 hvis servicen ikke er deployeret, .... og status 500, hvis der er opstået en fejl, og komponenten derfor ikke virker korrekt.

Overvågningstype

Som udgangspunkt overvåges følgende:

Audit log

Der foretages ikke audit log in gm-bff, da denne udelukkende kalder NSP komponenten GM-Facade. GM-Facade videre til MHD og som kalder videre til Dokumentdelingsservicen (DDS). Audit log foretages af i både MHD og DDS og derfor foretages der ikke yderligere audit log i gm-bff.  

Standard fejlsøgning

• Ved problemer med indlæsning af servicens konfigurationsfiler (...) bør man verificere at ...
• Ved manglende logning hvor der forventes fejlbeskeder bør konfigurationsfilen (...) checkes, da logindstillingerne sættes herigennem.
• En service eller et job kan stoppes og startes gennem docker.

Krav til backup m.m.

Det anbefales at aktuelle konfigurationsfiler til GM-BFF er under versionskontrol og back up.

Dokument Historik