Dette dokument beskriver installation og konfiguration af Behandlingsrelations-servicen (BRS).
Servicen omfatter to komponenter:
I denne vejledning beskrives krav til operativsystem og serversoftware, samt installation og konfiguration af de ovennævnte komponenter.
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.
Der stilles ingen krav til operativsystemet udover, at det skal være Linux, og docker skal være installeret.
Komponenten er testet mod MariaDB version 10.1.
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
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
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.
Databasen ”register_notifications” oprettes.
Følgende sql scripts skal køres på ”register_notifications” databasen (i nævnte rækkefølge):
Databasen ”followup” oprettes.
Følgende sql scripts skal køres på ”followup” databasen (i nævnte rækkefølge):
NB: followup-databasen kan slettes, når migrering til Kafka er gennemført (se driftsvejledning for detaljer om migrering).
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):
NB: followup-databasen kan slettes, når migrering til Kafka er gennemført (se driftsvejledning for detaljer om migrering).
Denne sektion beskriver hvordan komponenten deployes.
BRS bygges med NSP's Jenkins server via følgende jobs:
NSP er selv ansvarlige for at pushe release versioner af BRS til NSP Docker Registry gennem Jenkins.
BRS består af to docker images som pushes til NSP Docker Registry under navnene:
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. |
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.
Logning konfigureres i log4j-filerne nævnt ovenfor. Se driftsvejledningen for en mere detaljeret beskrivelse af hvad der logges.
Der benyttes en rolling file appender, hvor størrelsen af log filerne og antallet af gemte log filer konfigureres med de to environment variable: LOG_MAX_FILE_SIZE og LOG_MAX_BACKUP_INDEX.
Herunder følger en tabel over komponenter, samt en kort beskrivelse af deres formål.
Komponent | Komponent(er) | Beskrivelse |
---|---|---|
brs-backend | followupservlet | 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. |
Der henvises til driftsvejledningen for yderligere information
Når der kommer opgraderinger til en komponent, vil der medfølge releasenotes, der beskriver opgradering, fallback, osv. for den enkelte komponent.
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');
BRS backend og frontend startes og stoppes med Docker Compose kommandoer.
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".
På et NSP miljø hentes "compose" folderen for den ønskede version med Subversion og kommandoen "docker-compose up" køres i folderen "release".
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 |