Overblik

Dette dokument beskriver installation og konfiguration af LivsBehandlingstestamenteregister- og behandlingstestamenteregister-servicen (LTR-BTR) samt tilhørende migreringsværktøj. Konfiguration af tilhørende DGWS/IDWS Proxy er også beskrevet.

Livs- og behandlingstestamenteregisterBehandlingstestamenteregister-servicen består af 3 komponenter følgende komponent (war-arkiverarkiv), der skal konfigureres og deployes på en applikationsserver:

• ltr-btr-service-wildfly: Livs- og behandlingstestamenteregister-servicen. War-arkiv. Servlet-baseret webservice pakket specifikt til Wildfly.

• ltr-migration: Komponent til migrering af data. Anvendes kun ved initial migrering af data fra den gamle løsning. War-arkiv. Servlet-baseret webservice pakket specifikt til Wildfly.
• wsproxy: DGWS/IDWS Proxy. Er ikke inkluderet i dette projekts kildekode. War-arkiv. Servlet-baseret proxy-komponent til håndtering af DGWS/IDWS i requests og responses.

Projektet bygges med Maven og kræver Java 8 samt en MariaDB-installation for at kunne afvikle unit-tests.

Udover normalt tilgængelige Maven dependencies, afhænger projektet også af interne artefakter. Hvis disse artefakter ikke er udgivet (released) i den påkrævede version i NSP's Nexus repository, skal man selv udtjekke og bygge dem fra NSP's Subversion i den pågældende version. Artefakternes forskellige versioner vil være tilgængelige under et Subversion-tag. Disse artefakter er:

• cpr-subscriber (Maven identifier: dk.sds:cprsubscriber)
• dgws_idws_proxy (Maven identifier: dk.sds.dgws-idws-proxy:wsproxy-api)

For at bygge disse interne artefakter, henvises der til artefakternes dokumentation.

Ændringslog

...

Version

...

Dato

...

Ændring

...

Ansvarlig

...

1.0.1

...

2018-08-15

...

Initialt dokument

...

Trifork

...

Projektet bygges med Maven og kræver Java 8 samt en MariaDB-installation for at kunne afvikle unit-tests.

Ændringslog

Byggevejledning

For

Byggevejledning

For at bygge projektet og dets deployables (war-filer) uden at køre unit-tests og integrationstests, anvendes følgende Maven kommando:

...

Projektets deployables ender i target-mappen under de respektive moduler.

Afvikling af unit-tests

For at afvikle projektets unit-tests, skal en MariaDB-database-server være tilgængelig.

I udviklingssammenhæng og ved unit-tests kan man nøjes med én databasebruger og ét database-schema. Disse kan oprettes vha. scripterne recreate_service_user.sql og recreate_database.sql som er lokaliseret under ltr-btr-service/src/test/resources/db. Hvis disse standard-scripts anvendes, så passer de database-credentials, som er angivet i oprette de nødvendige database-schemas vha. scriptet compose/database/db/create_db.sql. I application.properties-filen i projektet . Database-strukturen er datasources som default sat til at anvende root-user med tomt password. Database-strukturen bliver automatisk oprettet vha. Flyway SQL-scripter, når unit-testene afvikles.

...

Alternativt kan også samtidigt bygge projektet ved at anvende Maven-kommandoen:

mvn clean install

Afvikling af integrationstests

Se testvejledningen.

Krav til miljø

Kravene er baseret på det driftsmiljø, der aktuelt er gældende på den Nationale Service Platform (NSP)Komponenten er tilpasset at kunne indgå i det aktuelt gældende CI-miljø på NSP. Det tager aktuelt udgangspunkt i version 1 af NSP's platform Docker image.

Krav til

...

database

Servicen er udviklet til at kunne afvikles på Wildfly 8 i produktiontestet mod MariaDB version 10.1, som bliver brugt på NSP platformen, og denne installationsvejledning beskriver en sådan opsætning. Applikationsserveren kræver Java 8 eller højere.

Specialhensyn i miljøer med flere app-servere

I miljøer med flere app-servere er det vigtigt at servicens interne jobs ikke kører i flere inkarnationer, da der så kan opstå "race conditions". Derfor bør det sikres at jobbenes "enabled"-properties fra application.properties kun er true på præcis én app-server, og false på de øvrige.

Det drejer sig om disse properties, som også er beskrevet i tabellen længere nede:

...

Krav til operativsystem

Der stilles ingen krav til operativsystemet udover Java-understøttelse. Ubuntu Linux bruges som operativsystem på NSP’en, men udviklingen af servicen er foretaget på Windows 10 og denne platform kan ligeledes afvikle servicen.

Krav til database

Servicen er testet mod MariaDB version 10.1, som bliver brugt på NSP platformen.

Krav til hardware

Der stilles ikke nogle minimumskrav til hardware, udover minimumskravene for operativsystemet, for at kunne afvikle servicen fornuftigt til testformål. Dog skal man forvente at bruge high-end hardware (både cpu, ram, netkort og diske) for at kunne opfylde de gældende svartidskrav på NSP.

Oprettelse af databaser og tabeller

Herunder beskrives servicens tilgang til database samt oprettelse af tabeller og views.

Tilgang til database

Servicen kræver to databaser: en til Livstestamenteregistret og en til Behandlingstestamenteregistret. Derudover afhænger den af adgang til et view i en (replikeret) stamdata-database.

Servicen konfigureres med 3 datasources, som tilgår databaserne vha. separat specificerede brugere.

To brugere skal henholdsvis give adgang til Livstestamenteregister-databasen og Behandlingstestamenteregister-databasen, og de skal begge være tildelt følgende rettigheder på deres pågældende database:

• Ved normal drift i produktion: SELECT, INSERT, UPDATE, DELETE
• Yderligere nødvendige rettigheder ved databaseoprettelse og migreringer: CREATE, DROP, ALTER

Databasebrugeren, der tilgår stamdata-view'et, skal være tildelt følgende rettigheder:

• Ved normal drift i produktion: SELECT
• Yderligere nødvendige rettigheder ved databaseoprettelse og migreringer: CREATE VIEW, DROP

Oprettelse af database og tabeller

Datamodellen styres vha. inkrementelle SQL-scripter, der kan findes under mappen ltr-btr-service/etc/db/migration. De er inddelt i tre undermapper:

• ltr: indeholder scripter til at køre på servicens Livstestamenteregister-database
• btr: indeholder scripter til at køre på servicens Behandlingstestamenteregister-database
• stm: indeholder scripter til at køre på en (replikeret) stamdata-database.

I produktion anvendes scripterne manuelt og skal køres på databasen i inkrementel rækkefølge baseret på versionsnummeret i filnavnet (først V1__(...).sql, dernæst V2__(...).sql, osv.). Hvert script må aldrig køres mere end én gang; der gælder dog en undtagelse for ikke-versionerede scripter, hvis filnavne begynder med R, som står for Repeatable. Disse Repeatable scripter skal køres hver gang deres indhold (checksum) er blevet ændret, men de må først køres efter alle versionerede scripter er blevet kørt.

Ved initial installation af servicen vil det således være følgende scripter, der skal køres i den nedenstående rækkefølge:

Servicens Livstestamenteregister-database

• ltr/V1__create_LivingWill.sql
• ltr/V2__create_PropertiesLivingWill.sql

Servicens Behandlingstestamenteregister-database

• btr/V3__create_TreatmentWill.sql 
• btr/V4__create_PropertiesTreatmentWill.sql
• btr/V5__alter_add_NoForcedTreatmentIfIncapable.sql
• btr/V6__migrate_RelativeAcceptanceRequired_to_AcceptanceNeeded.sql
• btr/V7__add_AcceptanceNeeded_for_all.sql

(Replikeret) Stamdata-database

• stm/R__create_v2_Person_Simplified_view.sql

Deployment på Wildfly

Denne sektion beskriver konfiguration og deployment af alle ovenstående komponenter på Wildfly 8.

Installation af konfigurationsfiler

ltr-btr-service-wildfly og ltr-migration konfigureres ved hjælp hver deres Wildfly-modul, der indholder de nødvendige konfigurationsfiler til valg af datasources, brugerdefinerede parametre, logning, mm.

Wildfly-modulerne, som indeholder konfigurationsfilerne, kan findes under etc/wildfly/modules. Her findes et separat modul for henholdsvis ltr-btr -service-wildfly og ltr -migration, da begge komponenter har hver deres modul med tilhørende konfigurationsfiler. Denne separation af konfigurationsfiler gør, at det, når migreringsprocessen er afsluttet, er muligt helt at fjerne konfigurationsfiler relateret til migrering uden at skulle ændre i konfigurationsfiler for ltr-btr -service-wildfly.

For at installere begge moduler på Wildfly kopieres indholdet i mappen etc/wildfly/modules til Wildfly's modul-mappe (<wildfly-root>/modules). Med denne fremgangsmåde vil alle nødvendige filer blive tilføjet til Wildfly de rigtige steder, og eksempelvis vil filen i etc/wildfly/modules/dk/sundhedsdatastyrelsen/livstestamente/main/module.xml ende under <wildfly-root>/modules/dk/sundhedsdatastyrelsen/livstestamente/main/module.xml.

Selve konfigurationsfilerne for ltr-btr -service-wildfly er lokaliseret i mappen <wildfly-root>/modules/dk/sundhedsdatastyrelsen/livstestamente/main/resources og i den tilsvarende mappe i modulet for ltr -migration komponenten. Konfigurationsfilerne vil være tilgængelige direkte på classpath'en for de deployede komponenter.

Konfiguration af servicen

Herunder beskrives properties i ltr-btr-service-wildfly komponentens konfigurationsfiler.

application.properties

Properties er her opdelt i to tabeller. Den første tabel indeholder anvendte Spring Boot-properties. Den anden tabel indeholder properties, der er specifikt defineret til brug i servicen. Begge typer af properties er defineret i samme konfigurationsfil.

Spring Boot-properties

...

JTA transaktioner. Det er påkrævet at denne er false, således at Spring Boot i stedet anvender dens egen håndtering af transaktioner. (true/false)

...

Komponentspecifikke-properties

...

Angiver om responses skal schema-valideres (true/false)

...

Angiver om et kald skal returnere fejl, hvis response ikke er schema-valid (true/false)

...

Angiver det præcise tidspunkt (ISO 8601) fra hvornår mulighed for oprettelser aktiveres for Behandlingstestamenteregistret. Hvis denne er null eller ikke er mulig at parse som et tidspunkt, vil mulighed for oprettelse alligevel være muligt, og en advarsel vil blive logget ved opstart.

Hvis oprettelser og opdateringer deaktiveres for Behandlingstestamenteregistret, vil integrationstestene fejle.

...

1000

...

Krav til hardware

Der stilles ikke nogle særlige minimumskrav til hardware, men man skal forvente at bruge high-end hardware (både cpu, ram, netkort og diske) for at kunne opfylde de gældende svartidskrav på NSP.

Oprettelse af databaser og tabeller

Herunder beskrives servicens tilgang til database samt oprettelse af tabeller og views.

Tilgang til database

Servicen består af en database, der både indeholder data for Livstestamenteregistret og for Behandlingstestamenteregistret. Derudover afhænger den af adgang til et view i en (replikeret) stamdata-database.

Servicen konfigureres med 1 datasource, som tilgår databasen vha. separat specificerede brugere.

En bruger skal give adgang til databasen, og den skal være tildelt følgende rettigheder på databasen:

• Ved normal drift i produktion: SELECT, INSERT, UPDATE, DELETE
• Yderligere nødvendige rettigheder ved databaseoprettelse og migreringer: CREATE, DROP, ALTER

Databasebrugeren, der tilgår stamdata-view'et, skal være tildelt følgende rettigheder:

• Ved normal drift i produktion: SELECT
• Yderligere nødvendige rettigheder ved databaseoprettelse og migreringer: CREATE VIEW, DROP

Oprettelse af database og tabeller

Datamodellen styres vha. inkrementelle SQL-scripter, der kan findes under compose/database/db/migration. De er inddelt i 2 undermapper:

• btr: indeholder scripts til at køre på servicens Livstestamenteregister-database og Behandlingstestamenteregister-database
• stm: indeholder scripts til at køre på en (replikeret) stamdata-database.

I produktion anvendes scripterne manuelt og skal køres på databasen i inkrementel rækkefølge baseret på versionsnummeret i filnavnet (først V1__(...).sql, dernæst V2__(...).sql, osv.). Hvert script må aldrig køres mere end én gang; der gælder dog en undtagelse for ikke-versionerede scripter, hvis filnavne begynder med R, som står for Repeatable. Disse Repeatable scripter skal køres hver gang deres indhold (checksum) er blevet ændret, men de må først køres efter alle versionerede scripter er blevet kørt.

Ved initial installation af servicen vil det således være følgende scripter, der skal køres i den nedenstående rækkefølge:

Servicens Behandlingstestamenteregister og Livstestamenteregister-database

• btr/V1__create_LivingWill.sql
• btr/V2__create_PropertiesLivingWill.sql
• btr/V3__create_TreatmentWill.sql 
• btr/V4__create_PropertiesTreatmentWill.sql
• btr/V5__alter_add_NoForcedTreatmentIfIncapable.sql
• btr/V6__migrate_RelativeAcceptanceRequired_to_AcceptanceNeeded.sql
• btr/V7__add_AcceptanceNeeded_for_all.sql
• btr/V8__add_PersonIdentifier_index.sql
• btr/V9__add_PersonIdentifier_index.sql

(Replikeret) Stamdata-database

• stm/R__create_v2_Person_Simplified_view.sql

Deployment

Komponenten deployes vha. NSP's platform Docker image og konfigurationsfiler mountes i containeren som angivet i projektets Compose-filer.

ltr-btr-service-wildfly indholder de nødvendige konfigurationsfiler til valg af datasource, brugerdefinerede parametre, logning, mm. Wildfly-modulet er integreret i komponentens Docker image.

Konfiguration af servicen

Herunder beskrives properties i ltr-btr-service-wildfly komponentens konfigurationsfiler.

application.properties

log4j.xml

Konfigurerer logning for servicen.

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.

Standardværdierne angiver nogle brugbare niveauer for anvendelse i produktion. Se Driftsvejledningen for uddybet beskrivelse af logning.

Se den officielle Log4j dokumentation for alternativ konfiguration.

minlogclient.properties

BTR anvender MinLogProvider til at registrere logninger i MinLog2, og i den forbindelse skal Kafka properties for Min Log 2 konfigureres. 

log4j-nspslalog.properties

Standardværdierne konfigurerer en Log4j-backend der logger med ISO 8601 timestamps.

Se  NSP-util - Designdokument.doc  eller den officielle Log4j 1 dokumentation for alternativ konfiguration.

accesshandler

security.properties

Konfigurerer security-api'et. Standardværdierne opsætter en keystore til signering af responses. Der henvises til accesshandlerens dokumentation for yderligere detaljer om konfiguration af security-api'et.

security.skip

Der henvises til accesshandlerens dokumentation for yderligere detaljer om konfiguration af security-api'et.

Konfiguration af datasources

ltr-btr-service-wildfly-komponenten kræver adgang til en JNDI-datakilde. Det skal opsættes i Wildfly og henvises til i tjenestens application.properties.

Overblik over komponenter

log4j2.xml

Konfigurerer logning for servicen.

Standardværdierne angiver nogle brugbare niveauer for anvendelse i produktion. Se Driftsvejledningen for uddybet beskrivelse af logning.

Se den officielle Log4j 2 dokumentation for alternativ konfiguration.

minlogclient.properties

Konfigurerer MinLog for servicen.

Standardværdierne indeholder konfiguration der skriver MinLog-logninger til test1-miljøet.

I produktion skal properties konfigureres som beskrevet i  MinLog Service - Guide til anvendere .

nspslalog-btr.properties

Konfigurerer SLA-logning for servicen.

Standardværdien er at SLA-logning er slået til.

Se  NSP-util - Designdokument.doc  for alternativ konfiguration.

log4j-nspslalog.properties

Standardværdierne konfigurerer en Log4j-backend der logger med ISO 8601 timestamps.

Se  NSP-util - Designdokument.doc  eller den officielle Log4j 1 dokumentation for alternativ konfiguration.

Konfiguration af proxy-komponent

Wsproxy er en separat komponent og har derfor adskilte konfigurationsfiler ift. selve servicen. Bemærk at disse konfigurationsfiler ikke er placeret i et modul, men i stedet under etc/wildfly/standalone/configuration. De skal installeres i <wildfly-root>/ standalone/configuration.

Der henvises til  Installationsvejledning (DGWS/IDWS Proxy)  for nærmere beskrivelse af konfigurationen.

wsproxy-btr.properties

Konfigurerer wsproxy komponenten.

Standardværdierne indeholder konfiguration til test1-miljøet, der signerer IDWS-responses med det medfølgende testcertifikat.

proxyconfig-btr.xml

Konfigurerer mapning af requests til den interne forwarding fra wsproxy til selve servicen.

Standardværdierne angiver nogle brugbare konfigurationer af mapninger for anvendelse i produktion.

log4j2-wsproxy-btr.xml

Konfigurerer wsproxy komponentens egen logning. Komponenten har både service-logning og audit-logning.

Standardværdierne angiver nogle brugbare niveauer for anvendelse i produktion.

Konfiguration af migreringskomponent

application.properties

...

JTA transaktioner. Det er påkrævet at denne er false, således at Spring Boot i stedet anvender dens egen håndtering af transaktioner. (true/false)

...

log4j2.xml

Konfigurerer logning for migreringskomponenten.

Standardværdierne angiver nogle brugbare niveauer for anvendelse til migrering i produktion. Se migeringsvejledningen for uddybet beskrivelse af logning.

Se den officielle Log4j 2 dokumentation for alternativ konfiguration.

Konfiguration af datasources

ltr-btr-service-wildfly komponenten kræver adgang til 2 JNDI datasources. Disse skal opsættes i Wildfly og refereres til i servicens application.properties.

Vær opmærksom på at datasource'ene skal opsættes med en strategi for reconnect håndtering i produktion. Se Wildfly's dokumentation for opsætning af datasources.

Ændring til standardkonfiguration i Wildfly

Standardkonfigurationen i Wildfly refererer i filen modules/system/layers/base/sun/jdk/main/service-loader-resources/META-INF/services/javax.script.ScriptEngineFactory til 2 ScriptEngineFactories:

com.sun.script.javascript.RhinoScriptEngineFactory
jdk.nashorn.api.scripting.NashornScriptEngineFactory

RhinoScriptEngineFactory findes ikke i Java 8. Derfor fås fejlen "javax.script.ScriptEngineFactory: Provider com.sun.script.javascript.RhinoScriptEngineFactory not found" når der anvendes Java 8. For at undgå denne fejlmeddelelse under opstart af Wildfly skal den første linje fjernes eller udkommenteres.

Deployment af komponenter

Komponenter, der skal deployes til Wildfly, kopieres til mappen <wildfly-root>/standalone/deployments.

Se driftsvejledningen for yderligere information.

Opgradering af komponenter

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

Start/genstart af komponenterne

Alle komponenter kan genstartes ved at opdatere war-filens last access time med Unix-kommandoen touch, hvilket automatisk detekteres af Wildfly's deploynent scanner. Alternativt kan Wildfly genstartes.