...

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

...

Se testvejledningen.

Krav til miljø

Kravene er baseret på det driftsmiljø, der aktuelt er gældende på den Nationale Service Platform (NSP).

Krav til applikationsserver

Servicen er udviklet til at kunne afvikles på Wildfly 8 i produktion, som bliver brugt på NSP platformen, og denne installationsvejledning beskriver en sådan opsætning. Applikationsserveren kræver Java 8 eller højereKomponenten 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.

Specialhensyn i miljøer med flere app-servere

...

Krav til operativsystem

...

Krav til database

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

Krav til hardware

Der stilles ikke nogle særlige minimumskrav til hardware, udover minimumskravene for operativsystemet, for at kunne afvikle servicen fornuftigt til testformål. Dog skal man 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.

...

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

• odr: indeholder scripter til at køre på servicens egen database
• stm: indeholder scripter til at køre på en (replikeret) stamdata-database.

...

• stm/R__create_v2_Person_Simplified_view.sql

Deployment

...

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

...

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

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

Info
odr-service-wildfly er via en jboss-deployment-structure.xml konfigureret til at have en afhængighed på et Wildfly-modul med navnet dk.sundhedsdatastyrelsen.organdonor. Ligeledes er odr-migration afhængig af dk.sundhedsdatastyrelsen.organdonor-migration.

Wildfly-modulerne, som indeholder konfigurationsfilerne, kan findes under etc/wildfly/modules. Her findes et separat modul for henholdsvis odr-service-wildfly og odr-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 odr-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/organdonor/main/module.xml ende under <wildfly-root>/modules/dk/sundhedsdatastyrelsen/organdonor/main/module.xml.

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

 Wildfly-modulet er integreret i komponentens Docker image.

Info
Alle konfigurerbare properties bør gennemgås inden idriftsættelse, men standardværdierne er tiltænkt anvendelse i produktion medmindre andet er angivet. Med "standardværdierne" forstås de værdier der står i eksempelfilerne under etc/wildfly-mappen i projektets kildekode.

Konfiguration af servicen

...

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

nspslalog-odr.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

...

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 er mountet i Docker containeren under <wildfly-root>/ standalone/configuration.

...

odr-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

Overblik over komponenter

Der følgende beskriver de forskellige deployables som komponenten indeholderKomponenter, der skal deployes til Wildfly, kopieres til mappen <wildfly-root>/standalone/deployments.

...

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.