1. Formål

Dette dokument beskriver installation og konfiguration af Behandlingsrelations-servicen (BRS).


Servicen omfatter to komponenter:

  • brs-frontend til installation i NSP-miljøer (de decentrale dNSP miljøer og det centrale cNSP miljø). Denne indeholder webservices til opslag af evidens for behandlingsrelationer og hent af alarm-notifikationer.
  • brs-backend til installation i det centrale Backoffice miljø. Denne service indeholder batchjobs til løbende opfølgning på evidens for behandlingsrelationer og generering af alarm-notifikationer.

I denne vejledning beskrives krav til operativsystem og serversoftware, samt installation og konfiguration af de ovennævnte komponenter.

2. Krav til miljø

2.1. Krav til applikationsservere

Komponenterne er udviklet og testet i Docker ved anvendelse af et base-image for NSP platformen.

Komponenternes konfiguration er således tilpasset deployering på WildFly 8.2 applikationsservere med OpenJDK 8.

2.2. Krav til operativsystem

Der stilles ingen krav til operativsystemet udover, at det skal være Linux, og docker skal være installeret.

2.3. Krav til database

Komponenten er testet mod MariaDB version 10.1.

2.4. Krav til hardware

Der er nogle minimumskrav for at kunne afvikle komponenten fornuftigt til testformål. Dog skal man forvente at bruge high-end hardware (både cpu, ram, netkort & diske) for at kunne opfylde svartidskravene på NSP platformen.

Minimumskravene, for fornuftig performance på et test-setup, er

  • Intel Core 2 eller lignende CPU
  • 2 GB ram
  • Nødvendig harddisk plads for at kunne håndtere alle registre (10+ GB)

3. Oprettelse af databaser og tabeller

Herunder beskrives opsætningen af databaserne, samt oprettelsen af tabellerne. Alle filer der refereres til kommer fra et SVN checkout. Den seneste version samt tidligere releases kan findes på https://svn.nspop.dk/src/components/brs

3.1. Tilgang til Stamdataudstillet database

Behandlingsrelationsservicen benytter data fra Stamdatamodulet. Servicen benytter tabellen ”AssignedDoctori”. Databasen fra Stamdata indeholdende pågældende tabel skal derfor være til rådighed for både frontend-modulet i NSP-miljøerne og backend-modulet i Backoffice-miljøet.

3.2. Oprettelse af database og tabeller i Backoffice-miljøet

Databasen ”register_notifications” oprettes.

Følgende sql scripts skal køres på ”register_notifications” databasen (i nævnte rækkefølge):

  1. Behandlingsrelation/common/src/main/resources/sql/create-register_notifications-tables.sql
  2. Behandlingsrelation/common/src/main/resources/sql/mysql-register_notifications-alter-tables.sql
  3. Behandlingsrelation/common/src/main/resources/sql/create-whitelist_config-table.sql


Databasen ”followup” oprettes.

Følgende sql scripts skal køres på ”followup” databasen (i nævnte rækkefølge):

  1. compose/database/brs/database/04-create-treatmentrelationfollowup-tables.sql
  2. compose/database/brs/database/05-mysql-treatmentrelationfollowup-alter-tables.sql

3.3. Oprettelse af database og tabeller i dNSP/cNSP-miljøer

Databasen ”register_notifications” oprettes som en replikeret kopi af samme database i Backoffice miljøet.

Databasen ”followup” installeres.

Følgende sql scripts skal køres på ”followup” databasen (i nævnte rækkefølge):

  1. compose/database/brs/database/06-create-followup-tables.sql
  2. compose/database/brs/database/07-mysql-followup-alter-tables.sql

4. Deployment

Denne sektion beskriver hvordan komponenten deployes.

4.1. Jenkins

BRS bygges med NSP's Jenkins server via følgende jobs:

  • BRS_build - Bygger koden (sker automatisk ved commits)
  • BRS_push_snapshot - Pusher det nyeste snapshot image til NSP Docker Registry

NSP er selv ansvarlige for at pushe release versioner af BRS til NSP Docker Registry gennem Jenkins.

4.2. Docker

BRS består af to docker images som pushes til NSP Docker Registry under navnene:

  • registry.nspop.dk/components/brs/brs-frontend:snapshot
  • registry.nspop.dk/components/brs/brs-backend:snapshot

4.3. Docker-compose

BRS leveres samtidig som et sæt af Docker Compose filer i folderen https://svn.nspop.dk/src/components/brs/trunk/compose.


Compose folderen indeholder 5 underfoldere:

configuration Her ligger alle de konfigurationsfiler som det forventes af driften tilretter til det anvendte miljø.
database Her ville alle de databasefiler som det forventes at driften lægger på en NSP database ligge, hvis der var nogen
development Her ligger en Docker Compose fil til brug for udvikling. Se Guide til Udviklere.
test Her ligger en Docker Compose fil der kan starte BRS i en standalone test konfiguration.
release Her ligger den Docker Compose fil som det forventes driften anvender på både test og produktionsmiljøerne.

4.4. Konfiguration af properties

I folderen https://svn.nspop.dk/src/components/brs/trunk/compose/configuration findes følgende konfigurationsfiler:


backend/brs-backend.dev.properties Konfiguration af brs-backend til udviklingsbrug.
backend/brs-backend-log4j.xml Logopsætning af brs-backend.
backend/brs-backend.properties Konfiguration af brs-backend.
backend/crl.skip Skipliste til certificate revocation tjek.
backend/properties/Capgemini_Sogeti_Danmark_AS_SOR_FOCES.jks Keystore til SOR kald.
backend/properties/module.xml Module-fil.
frontend/brs-frontend.dev.properties Konfiguration af brs-frontend til udviklingsbrug.
frontend/brs-frontend-log4j.xml Logopsætning af brs-frontend.
frontend/brs-frontend.properties Konfiguration af brs-frontend.
frontend/crl.skip Skipliste til certificate revocation tjek.
frontend/properties/Capgemini_Sogeti_Danmark_AS_SOR_FOCES.jks Keystore til SOR kald.
frontend/properties/module.xml Module-fil.
sores/* Konfiguration til brug i udviklersetup.


Filerne brs-backend.properties og brs-frontend.properties skal tilrettes til de forskellige miljøer hvorpå de installeres. Filerne indeholder en konfiguration der passer i en standalone test konfiguration. Se driftsvejledningen for en beskrivelse af indholdet af filerne.

4.5. Konfiguration af logning

Logning konfigureres i log4j-filerne nævnt ovenfor. Se driftsvejledningen for en mere detaljeret beskrivelse af hvad der logges.

4.6. Deployment af komponenter

Herunder følger en tabel over komponenter, samt en kort beskrivelse af deres formål.

Komponent Komponent(er) Beskrivelse
brs-backend replicationservice Opsamling af behandlingsrelationer til opfølgning fra frontend.

followupjob Kontrol af opfølgninger til sletning eller oprettelse af alarm-notifikationer.

Cleanupjob Sletning af gamle notifikationer.
brs-frontend behandlingsrelationsservice Service til forespørgsel på behandlingsrelationer.

notifikationsservice Service til hent af notifikationer.

Replicationjob Job til overførsel af behandlingsrelationer til opfølgning til backend.

Der henvises til driftsvejledningen for yderligere information

4.7. Opgradering af komponenter

Når der kommer opgraderinger til en komponent, vil der medfølge releasenotes, der beskriver opgradering, fallback, osv. for den enkelte komponent.

4.8. Whitelisting af services

Adgang til BRS services styres på CVR niveau. Adgang til services kan styres enten via property filen, eller via en lignende konfiguration i whitelist_config tabellen.

Vælges DATABASE som styringsmodel for whitelisting i propertyen "dk.nsi.auth.whitelistservice.type” anvendes de komma-separerede lister i propertyfilen ikke. I stedet indsættes en record i tabellen for hver adgang der skal gives. Nedenstående eksempler angiver formatet.


Eksempler på at oprette adgang til BRS

INSERT INTO whitelist_config (service_key, service_type, cvr) VALUES ('dk.nsi.auth.brs.cvr.list', 'NO_TYPE', '55832218');


Eksempler på at oprette query-adgang til notifications-servicen

INSERT INTO whitelist_config (service_key, service_type, cvr) VALUES ('dk.nsi.auth.query.type.cvr.list', 'BRS', '55832218');

4.9. Start/genstart af komponenterne

BRS backend og frontend startes og stoppes med Docker Compose kommandoer.

4.10. Standalone test

For en standalone test af BivWSP hentes "compose" folderen for den ønskede version med Subversion og kommandoen "docker-compose up" køres i folderen "test".

4.11. NSP Miljø

På et NSP miljø hentes "compose" folderen for den ønskede version med Subversion og kommandoen "docker-compose up" køres i folderen "release".

5. Ændringslog


Version

Dato

Ændring

Ansvarlig

0.1

2011-06-15

Initielt dokument

Trifork

0.2

2011-06-21 Opdatering af databaseoprettelser på NSP og DoDis opfølgningstabeller

Trifork

0.3

2011-07-27 Opdateret jf. ny struktur med generel notificationsservice.

Trifork

0.4

2011-08-10 Opdateret dokumentation med GOS services

Trifork

0.5

2011-10-05 Opdateres dokumentation med CPRABBS service

Trifork

0.6

2011-11-28 Dokumentation opdateret med whitelist_config tabeloprettelse

Trifork

0.7

2013-10-21 Opdateret kilde

Trifork

0.8 2014-03-12 Opdateret med beskrivelse af propertyfil, og detaljer for hver property Trifork
0.9 2016-09-01 Opdateret til Wildfly 8 Trifork
0.10 2016-11-11 Opdateret logning til profiler Trifork
0.11 2017-03-09 Tilrettet BRS2 Trifork
0.12 2017-03-14 Rettet betegnelse på NSP-miljøer Trifork
0.13 2019-07-12 Dokument fra repository lagt i confluence. Tidligere dokuments indhold var - forkert - arkitektur dokumentet KvalitetsIT
0.14 2020-07-23 Opdateret med beskrivelse af docker-setup. KvalitetsIT
0.15 2020-11-23 Gennemlæst og foretaget smårettelser (i krav til applikationsserver og operativsystem, hvor Docker er sat som krav) KvalitetsIT



  • No labels