Dette dokument beskriver installation og konfiguration af Stamkortregister-servicen (SKR). Konfiguration af tilhørende DGWS/IDWS Proxy er også beskrevet.
Stamkortregister-servicen består af 2 komponenter (war-arkiver), der skal konfigureres og deployes på en applikationsserver:
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:
For at bygge disse interne artefakter, henvises der til artefakternes dokumentation.
Alle filer der refereres til ligger sammen med projektets kildekode i NSP's Subversion. Referencer til stier er relative med udgangspunkt i projektets rodmappe. |
Version | Dato | Ændring | Ansvarlig |
---|---|---|---|
1.0.0 | 2018-08-31 | Initialt dokument | Trifork |
1.0.1 | 2018-09-11 | Ændret databasedriver til MySQL | Trifork |
1.0.11 | 2019-08-16 | Fjernet SCES properties. Opdateret default value for property "minlog.read-activity-text". | Trifork |
For at bygge projektet og dets deployables (war-filer) uden at køre unit-tests og integrationstests, anvendes følgende Maven kommando:
mvn clean install -DskipTests
Projektets deployables ender i target-mappen under de respektive moduler.
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 skr-service/src/test/resources/db. Hvis disse standard-scripts anvendes, så passer de database-credentials, som er angivet i application.properties-filen i projektet. Database-strukturen bliver automatisk oprettet vha. Flyway SQL-scripter, når unit-testene afvikles.
Unit-testene i projektet kan afvikles med følgende Maven-kommando:
mvn clean test
Alternativt kan også samtidigt bygge projektet ved at anvende Maven-kommandoen:
mvn clean install
Kravene er baseret på det driftsmiljø, der aktuelt er gældende på den Nationale Service Platform (NSP).
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øjere.
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.
Servicen er testet mod MariaDB version 10.1, som bliver brugt på NSP platformen.
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.
Herunder beskrives servicens tilgang til database samt oprettelse af tabeller og views.
Servicen kræver en enkelt database til dens egen data.
Databasebrugeren, der tilgår servicens database, skal være tildelt følgende rettigheder:
Datamodellen styres vha. inkrementelle SQL-scripter, der kan findes under mappen skr-service/etc/db/migration.
Scripterne er udformet til at blive kørt med databasemigreringsværktøjet Flyway, men dette er kun aktiveret under afvikling af unit-tests, da dette ikke ønskes anvendt i produktion. |
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:
Under afvikling af unit-tests bliver test-data automatisk indsat i tabellerne vha. yderligere scripter i projektets test-resources. |
I udviklingssammenhæng og ved unit-tests kan en databasebruger og en database oprettes vha. scripterne recreate_service_user.sql og recreate_database.sql som er lokaliseret under skr-service/src/test/resources/db. Derefter kan Flyway automatisk initialisere databasen. |
Denne sektion beskriver konfiguration og deployment af alle ovenstående komponenter på Wildfly 8.
skr-service komponenten konfigureres ved hjælp et Wildfly-modul, der indholder de nødvendige konfigurationsfiler til definering af datasources, brugerdefinerede parametre, logning, mm.
skr-service er via en jboss-deployment-structure.xml konfigureret til at have en afhængighed på et Wildfly-modul med navnet dk.sundhedsdatastyrelsen.stamkortregister. |
Wildfly-modulet, som indeholder konfigurationsfilerne, kan findes under etc/wildfly/modules.
For at installere modulet 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/stamkortregister/main/module.xml ende under <wildfly-root>/modules/dk/sundhedsdatastyrelsen/stamkortregister/main/module.xml.
Selve konfigurationsfilerne for skr-service er lokaliseret i mappen <wildfly-root>/modules/dk/sundhedsdatastyrelsen/stamkortregister/main/resources. Konfigurationsfilerne vil være tilgængelige direkte på classpath'en for de deployede komponenter.
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. |
Herunder beskrives properties i skr-service komponentens konfigurationsfiler.
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.
Property | Beskrivelse | Default |
---|---|---|
spring.application.name | Navnet på applikationen. Skal ikke ændres. | skr |
spring.jmx.enabled | Disable Spring Boot JMX. Skal ikke ændres. Deaktiveret da vi ikke udstiller særlig JMX funktionalitet. | false |
spring.jta.enabled | 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) | false |
management.server.port | Port som Spring Boot management endpoints bind'er på. Endpoints deaktiveres ved at sættes værdien til -1. | -1 |
spring.datasource.jndi-name | Angiver navnet på den primære JNDI datasource | java:jboss/datasources/SKR-DS |
Property | Beskrivelse | Default |
---|---|---|
dcc.endpoint | Angiver det endpoint, som DCC'en skal kalde. Dette kommer til at fremgå af den XML, der returneres i /dksconfig. Bør ændres før produktion. | http://test1.fsk.netic.dk:8080/fsk/services/fsk |
minlog.read-activity-text | Angiver den tekst der registreres i MinLog, når der bliver læst Stamkortregister-data for et CPR-nummer | Opslag i Stamkort |
minlog.write-activity-text | Angiver den tekst der registreres i MinLog, når der bliver læst Stamkortregister-data for et CPR-nummer | Opdatering af Stamkortregister |
schemavalidation.validate-requests | Angiver om requests skal schema-valideres (true/false) | true |
schemavalidation.validate-responses | Angiver om responses skal schema-valideres (true/false) | true |
schemavalidation.fail-on-response-error | Angiver om en kald skal returnere fejl, hvis response ikke er schema-valid (true/false) | true |
forward-only-filter.enabled | Angiver om servicen kun skal kunne tilgås igennem DGWS/IDWS Proxyen (wsproxy komponenten). Bør altid være sat til true. (true/false) | true |
whitelist.careproviderid | Angiver en komma-separeret liste af whitelistede CVR-numre fra medcom:CareProviderID-attributten fra en DGWS header. Denne whitelisting medfører, at anvenderen kan redigere data ud fra et DGWS niveau 3 kald. Standard-værdien er Sundhed.dk's CVR-nummer. | 31908574 |
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.
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.
Konfigurerer SLA-logning for servicen.
Standardværdien er at SLA-logning er slået til.
Se NSP-util - Designdokument.doc for alternativ konfiguration.
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.
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.
Konfigurerer wsproxy komponenten.
Standardværdierne indeholder konfiguration til test1-miljøet, der signerer IDWS-responses med det medfølgende testcertifikat.
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.
Konfigurerer wsproxy komponentens egen logning. Komponenten har både service-logning og audit-logning.
Standardværdierne angiver nogle brugbare niveauer for anvendelse i produktion.
skr-service komponenten kræver adgang til en JNDI datasource. Denne skal opsættes i Wildfly og refereres til i servicens application.properties.
Vær opmærksom på at datasource'en skal opsættes med en strategi for reconnect håndtering i produktion. Se Wildfly's dokumentation for opsætning af datasources.
I mappen etc/wildfly/standalone/deployments er inkluderet eksempler på datasource-konfigurationer til servicens database (skr-ds.xml). Denne datasource-konfigurationsfil kan opsættes i Wildfly ved at kopiere den ind i <wildfly-root>/standalone/deployments. Derudover skal der også deployes en databaseklient-driver i samme mappe. Den medfølgende datasource-konfiguration anvender driveren mysql-connector-java-5.1.29.jar og denne medfølger ikke i projektet. |
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.
Komponenter, der skal deployes til Wildfly, kopieres til mappen <wildfly-root>/standalone/deployments.
Filnavn når deployet | Beskrivelse | Kilde |
---|---|---|
skr-service.war | SKR servicen | skr-service-<version>.war |
skr.war | DGWS/IDWS Proxy . Se Installationsvejledning (DGWS/IDWS Proxy) for dokumentation. War-filen for wsproxy komponenten omdøbes til skr.war, hvilket bevirker at webservice context-path for wsproxy i dette tilfælde bliver /skr. | wsproxy-<version>.war (findes ikke i skr-projektet) |
Se driftsvejledningen for yderligere information.
Når der kommer opgraderinger til en komponent, vil der medfølge release notes, der beskriver opgradering, fallback, osv. for den enkelte komponent.
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.