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 et 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. 

Den applikationspecifikke del af GM_BFF konfigureres via filen application.yml.

logging:
  level:
    ROOT: info
    org:
      springframework:
        web: debug
        security: debug

server:
  port: 8082
  servlet:
    context-path: /gm-bff

management:
  endpoints:
    web:
      exposure:
        include: health

spring:

  application:
    name: gm-bff

  datasource:
    driverClassName: org.postgresql.Driver
    url: jdbc:postgresql://localhost:5432/db?currentSchema=gm
    username: db
    password: db

service:

  version: @project.version@

  gm-facade-endpoint: https://gmaf/gmaf

  cms-endpoint: https://cms

  oidc:
    issuer: https://test.cloud.idm.trifork.com/auth/realms/gravid
    audience: https://audience.nspop.dk/mhd
    scope: nsp-gm-clientstate
    issuance-policy: urn:dk:sds:policy:gm-access

  cache:
    cache-age: 300 # max age of usable cached data, in seconds
    cleanup-frequency: 300000 # frequency of cache clean up, in milliseconds

meilisearch:
  meilisearch-endpoint: https://meilisearch
  meili-master-key: 9ooLuYuw149G5zhWYT....

---
spring:
  config:
    activate:
      on-profile: prod

log4j konfiguration

Der logges med log4j2s default opsætning, hvor der logges til til standard out. Log level opsættes i application.yaml

SLA-log konfiguration

Der findes ingen konfiguration af SLA-log, da dette request tider logges som en del af request logs med loggeren REQUEST_LOG:

 {"traceId":"68c7f7186ebdf5341a477e4f02b1f9aa","spanId":"e8f08dabc6e8c95e","method":"GET","clientIp":"127.0.0.1","userAgent":"bruno-runtime/2.10.0","uri":"/gm-bff/api/v1/overview/pregnancyinfo","status":200,"elapsedMs":2106}

Derudover logges udførselstider for kald til GM-Facede og CMS på lignende vis med loggeren SUB_REQUEST_LOG:

{"traceId":"68c7f7186ebdf5341a477e4f02b1f9aa","spanId":"e8f08dabc6e8c95e","method":"GET","uri":"https://gmaf/gmaf/api/2025/06/25/journal","direction":"OUTBOUND","status":200,"elapsedMs":1454}

Whitelist konfiguration

Der er ingen whitelisting. 

Monitorering

Statuscheck af GM-BFF et tilgængelig på:

/gm-bff/actuator/health

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