Version 0.13, 2019-07-12

Formål

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

Servicen omfatter to komponenter:

• brs-frontend.war 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.war 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.

Krav til miljø

Krav til applikationsservere

Komponenterne er udviklet og testet under Jetty og Wildfly 8, og kan deployes i produktion på alle nævnte applikationsservere. Dog er der kun skrevet installationsvejledning for deployment på Wildfly 8, da det er denne platform som bruges på den nationale service platform (NSP).

Applikationsserveren kræver Java 8 eller højere.

Krav til operativsystem

Der stilles ingen krav til operativsystemet, ud over det åbenlyse krav om at Java er understøttet på operativsystemet. Ubuntu Linux bruges som operativsystem på NSP’en, men udviklingen af komponenten er foretaget på hhv. OS X og Windows 10, og disse platforme kan ligeledes afvikle komponenterne.

Krav til database

Komponenten er testet mod MariaDB version 10.0. Det er den samme MySQL version som bliver brugt på NSP platformen (NIAB version 1.1.3).

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)

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 kan findes på https://svn.nspop.dk/svn/components/brs

Tilgang til Stamdataudstillet database

Behandlingsrelationsservicen benytter data fra Stamdatamodulet. Servicen benytter tabellen ”AssignedDoctorⁱ”. 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.

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. Behandlingsrelation/common/src/main/resources/sql/create-treatmentrelationfollowup-tables.sql
2. Behandlingsrelation/common/src/main/resources/sql/mysql- treatmentrelationfollowup-alter-tables.sql

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. Behandlingsrelation/common/src/main/resources /sql/create-followup-tables.sql
2. Behandlingsrelation/common/src/main/resources /sql/mysql-followup-alter-tables.sql

Deployment på Wildfly 8

Denne sektion beskriver deployment processen på Wildfly 8

Konfiguration af properties

Der kræves forskellige property-filer afhængigt af om der er tale om deployment på dNSP/cNSP eller Backoffice. Hvis der deployes på NSP, skal der være en brs-frontend.properties til rådighed, og hvis der deployes til Backoffice, skal der være en brs-backend.properties til rådighed.

I Backoffice-miljøet placeres brs-backend.properties i Wildfly 8’s standalone/configuration folderen til Wildfly. Tilsvarende placeres brs-frontend.properties i samme folder i NSP-miljøerne.

Konfiguration af logging

I filen standalone/configuration/standalone.xml indsættes en logging-profil.

På NSP/frontend indsættes følgende under ”logging-profiles”

<logging-profile name="brs-frontend">
    <size-rotating-file-handler name="METRICS-FILE">
        <formatter>
            <pattern-formatter pattern="%d{dd MMM yyyy HH:mm:ss:SSS} app=%c, logLevel=%p, thread=%t, %m%n"/>
        </formatter>
        <file relative-to="jboss.server.log.dir" path="metrics.log"/>
        <rotate-size value="10M"/>
        <max-backup-index value="5"/>
        <append value="true"/>
    </size-rotating-file-handler>
    <size-rotating-file-handler name="FRONTEND-FILE">
        <level name="DEBUG"/>
        <formatter>
            <pattern-formatter pattern="%d{dd MMM yyyy HH:mm:ss:SSS} app=%c, logLevel=%p, thread=%t, %m%n"/>
        </formatter>
        <file relative-to="jboss.server.log.dir" path="brs-frontend.log"/>
        <rotate-size value="10M"/>
        <max-backup-index value="5"/>
        <append value="true"/>
    </size-rotating-file-handler>
    <size-rotating-file-handler name="FRONTEND-AUDIT-FILE">
        <formatter>
            <pattern-formatter pattern="%d{dd MMM yyyy HH:mm:ss:SSS} app=%c, logLevel=%p, thread=%t, %m%n"/>
        </formatter>
        <file relative-to="jboss.server.log.dir" path="brs-frontend-audit.log"/>
        <rotate-size value="10M"/>
        <max-backup-index value="5"/>
        <append value="true"/>
    </size-rotating-file-handler>
    <root-logger>
        <level name="INFO"/>
        <handlers>
            <handler name="FRONTEND-FILE"/>
        </handlers>
    </root-logger>
    <logger category="audit.dk.nsi.brs" use-parent-handlers="false">
        <level name="INFO"/>
        <handlers>
            <handler name="FRONTEND-AUDIT-FILE"/>
        </handlers>
    </logger>
    <logger category="dk.nsi.brs.common.metrics" use-parent-handlers="false">
        <level name="DEBUG"/>
        <handlers>
            <handler name="METRICS-FILE"/>
        </handlers>
    </logger>
    <logger category="org.hibernate">
        <level name="WARN"/>
    </logger>
    <logger category="org.springframework">
        <level name="WARN"/>
    </logger>
    <logger category="httpclient.wire">
        <level name="WARN"/>
    </logger>
    <logger category="org.apache">
        <level name="WARN"/>
    </logger>
    <logger category="com.sun">
        <level name="WARN"/>
    </logger>
</logging-profile>

På Backoffice/backend laves samme konfiguration, blot angives “backend” i stedet for “frontend”.

Eksempel på opsætning af logning findes i integration/src/test/resources/standalone.xml

Deployment af komponenter

Alle komponenter der skal deployes til Wildfly, skal kopieres til mappen ”standalone/deployments”.

• På dNSP/cNSP deployes brs-frontend.war
• På Backoffice deployes brs-backend.war

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

Der henvises til driftsvejledningen for yderligere information

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.

Konfiguration af komponenterne

Al konfiguration på NSP og Backoffice foregår ved redigering af hhv. brs-frontend.properties og brs-backend.properties, der placeres i standalone/configuration folderen under Wildfly. En skabelon til disse filer findes i integration/src/test/resources. Filerne konfigureres og placeres i standalone/configuration biblioteket på Wildfly.

Bemærk at brs-frontend.properties og brs-backend.properties i visse situationer ”overlapper”, dvs. indeholder ens properties. Dette skyldes bl.a. at funktionalitet til opslag af evidens for en behandlingsrelation findes i både frontend og backend.

For en oversigt over de enkelte properties og deres default-værdier henvises til driftsvejledningen, som også findes under ”docs”.

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');

Start/genstart af komponenterne

Alle komponenter kan genstartes ved ”touch” af de enkelte war filer på Wildfly. Alternativt kan Wildfly genstartes ved at køre kommandoen

service wildfly8 restart

Ændringslog