Page History
...
Dette dokument beskriver installation og konfiguration af Organdonorregister-servicen (ODR) samt tilhørende migreringsværktøj. Konfiguration af tilhørende DGWS/IDWS Proxy er også beskrevet.
Organdonorregister-servicen består af 3 komponenter følgende komponent (war-arkiverarkiv), der skal konfigureres og deployes på en applikationsserver:
- odr-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.
Info |
---|
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.1 | 2018-08-20 | Initialt dokument | Trifork | |
1.0.2 | 2018-08-31 | Ny release | Trifork | |
1.0.3 | 2018-09-11 | Ændret databasedriver til MySQL | Trifork | |
1.0.11 | 2019-08- | 1619 | Opdateret default value for property "minlog.read-activity-text". Tilføjet SQL-script. | Trifork |
1.0.13 | 2019-25-09 | Ajourført | Trifork | |
1.0.16 | 2020-05-25 | Opdateret properties til slettejob | KIT | |
1.0.17 | 2021-12-07 | Opdateret ifm inaktive cpr numre afvises | KvalitetsIT | |
1.0.18 | 2022-10-24 | SDS-5679: validering af alder | KvalitetsIT | |
1.0.19 | 2023-09-26 | SDS-6386: ODR - oprydningsjob genbesøg | KvalitetsIT |
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 odr-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.
Følgende Maven-kommando anvendes til at bygge projektet og afvikle unittest:
mvn clean install
Når projektet er bygget, kan unit-testene også afvikles alene 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
Ved kørsel af unit-tests, anvendes en in-memory database, som automatisk startes op, når unit-tests afvikles. Det er derfor ikke nødvendigt at starte en ekstern database til unit-test.
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).
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øjere.
Specialhensyn i miljøer med flere app-servere
I miljøer med flere app-servere er det vigtigt at servicens interne job ikke kører i flere inkarnationer, da der så kan opstå "race conditions". Derfor bør det sikres at jobbets "enabled"-property fra application.properties kun er true på præcis én app-server, og false på de øvrige.
Det drejer sig om denne property, 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 servicenKomponenten 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 testet mod MariaDB version 10.1, som bliver brugt på NSP platformen.
Til unit-test anvendes en in-memory H2-database, som automatisk startes ved kørsel af unit-testene.
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.
...
- odr/V1__create_OrganDonorRegistration.sql
- odr/V2__create_Properties.sql
- odr/V3__add_PersonIdentifier_index.sql
(Replikeret) Stamdata-database
- stm/R__create_v2_Person_Simplified_view.sql
Info |
---|
Scriptet R__create_v2_Person_Simplified_view.sql opretter et view, som afhænger af eksistensen af tabellen v2_Person. Dette er tabellen, der indeholder CPR-ændringer, og den skal man selv stå for at levere. Under afvikling af unit-tests bliver en testudgave af denne tabel automatisk oprettet vha. et SQL-script i projektets test-resources compose/database/db/test. |
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 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
...
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
for servicen ses i tabellen herunder.
Property | Beskrivelse | Default |
---|
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
Property | Beskrivelse | Default | |||
---|---|---|---|---|---|
datasource.odr.jndi-name | Angiver navnet på en JNDI datasource til Organdonorregister-databasen | java:jboss/datasources/ODR-DS | |||
datasource.stamdata.jndi-name | Angiver navnet på den JNDI datasource der giver adgang til en (replikeret) stamdata-database | java:jboss/datasources/STM-DS | |||
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/odr/odr | |||
minlog.read-activity-text | Angiver den tekst der registreres i MinLog, når der bliver læst Organdonorregistering-data for et CPR-nummer | L\u00e6sning af Organdonorregistrering | |||
minlog.create-activity-text | Angiver den tekst der registreres i MinLog, når der bliver oprettet Organdonorregistering-data for et CPR-nummer | Oprettelse af Organdonorregistrering | |||
minlog.delete-activity-text | Angiver den tekst der registreres i MinLog, når der bliver slettet Organdonorregistering-data for et CPR-nummer | Sletning af Organdonorregistrering | |||
minlog.update-activity-text | Angiver den tekst der registreres i MinLog, når der bliver opdateret Organdonorregistering-data for et CPR-nummer | Opdatering af Organdonorregistrering | |||
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 |
jobs.delete.enabled | Slettejob: Angiver om det schedulerede slettejob skal være aktiveret (true/false) | true | |||
jobs.delete.schedule | Slettejob: Angiver schedulering-pattern for slettejobet | 0 0 12 * * ? | |||
jobs.delete.cpr-max-results | Slettejob: Angiver maksimum antal rækker med opdateringer i cpr-registry der skal læses ad gangen | 100025 | |||
jobs.delete.cpr-max-loops | Slettejob: Angiver maksimum antal batches der skal behandles pr. jobeksekvering | 10002 |
...
cprexists. |
...
validationlevel |
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-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
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-odr.properties
Konfigurerer wsproxy komponenten.
Standardværdierne indeholder konfiguration til test1-miljøet, der signerer IDWS-responses med det medfølgende testcertifikat.
proxyconfig-odr.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-odr.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
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)
...
migration.personFileName
...
PersonData.csv
...
migration.organDonorFileName
...
OrganDonorData.csv
Valideringsniveau for CPR validering Eksempel: WARNING, REJECT, OFF | ||
cprexists.url | URL for CPR exist service Eksempel: http://test1-cnsp.ekstern-test.nspop.dk:8080/stamdata-cprexists | null |
cprexists.maxTotalConnections | Konfiguration af client pool til kald af CPRExists service | 200 |
cprexists.defaultMaxConnectionsPerRoute | Konfiguration af client pool til kald af CPRExists service | 20 |
cprexists.inactive.status | Konfiguration af inaktive status, liste adskilt af komma | 30,50,60 |
cprexists.minage | Aldersgrænse for oprettelse af organdonation | 15 |
whitelisted.level3.cvrs | Komma separeret liste af cvr numre, der må kalde servicen med niveau 3 id kort | |
allowed.idws.audience | Det tilladte audience på indkommende idws requests | |
nas.app.name | Applikationsnavn til sla-logning ved NAS-kald | organdonorregister |
nas.app.shortname | Kort applikationsnavn til sla-logning ved NAS-kald. | odr |
nas.fail.theshold | Grænse for hvor mange gange NAS-kald må fejle i træk, før NAS opfattes som usund. | 1 |
nas.connect.timeout.millis | Grænse for hvor lang tid det må tage at oprette forbindelse til NAS (i ms.). | 10000 |
nas.read.timeout.millis | Grænse for hvor lang tid det må tage at modtage svar fra NAS (i ms.). | 10000 |
nas.max.total.connections | Maksimalt antal samtidige NAS-forbindelser. | 200 |
nas.default.max.connections.per.route | Maksimalt antal NAS-forbindelser per rute. | 20 |
nas.service.url | NAS Endpoint | http://test1.ekstern-test.nspop.dk:8080/nas2/notificationbroker/service |
nas.topic | NAS topic | http://sundhedsdatastyrelsen.dk/OrganDonation/2022/05/05:OrganDonationUpdated |
nas.idcard.subject.id.type | Subjecttype for IDKort til NAS-kald. | medcom:cvrnumber |
nas.idcard.subject.id | SubjectId for IDKort til NAS-kald. | 46837428 |
nas.idcard.subject.name | Subjectname for IDKort til NAS-kald. | Funktionssignatur til testmiljø (funktionscertifikat) |
nas.idcard.level | Sikkerhedsniveau for IDKort til NAS-kald. | 3 |
nas.idcard.system.name | Systemnavn i IDKort til NAS-kald. | itsystem |
nas.sts.endpoint | Endpointet, hvor Minspærring skal trække sit SOSI IDkort på baggrund af sts.keystore | http://test2.ekstern-test.nspop.dk:8080/sts/services/NewSecurityTokenService |
nas.sts.test.mode | Boolsk værdi, der angiver om der anvendes test- eller produktions SOSIFederation | true |
nas.sts.keystore | sti til keystore, der indeholder certifikat til at trække Idkort til NAS-kald. | Statens_Serum_Institut_FOCES.jks |
nas.sts.keystore.password | Password til sts.keystore | n/a |
jobs.delete.max.time | Angiver den maksimale udførelsestid for baggrundsjobbet. Angives som Duration i ISO-8601 formattet. Default værdien er på 20 sekunder. | PT20S |
minlogclient.properties
ODR anvender MinLogProvider til at registrere logninger i MinLog2, og i den forbindelse skal Kafka properties for Min Log 2 konfigureres.
Property | Beskrivelse |
---|---|
kafka.producer.bootstrap.servers | Kafka endpoint, som anvendes i forbindelse med kald til MinLog2 |
kafka.producer.client.id | Navnet som ODR vil fremgå med i listen af Producers på et Kafka Cluster. |
kafka.producer.key.serializer | Serializer key for Kafka producer |
kafka.producer.key.value.serializer | Serializer value for Kafka producer |
kafka.topic | Kafka topic som anvendes i forbindelse med kald til MinLog2 |
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
log4j2.xml
Konfigurerer logning for migreringskomponenten.
Standardværdierne angiver nogle brugbare niveauer for anvendelse til migrering i produktion. Se migeringsvejledningen Driftsvejledningen for uddybet beskrivelse af logning.
Se den officielle Log4j dokumentation 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 2 1 dokumentation for alternativ konfiguration.
Konfiguration af 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
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.
Info |
---|
I mappen etc/wildfly/standalone/deployments er inkluderet eksempler på datasource-konfigurationer til selve servicens database (odr-ds.xml) og til (den replikerede) stamdata-database (stm-ds.xml). Disse datasource-konfigurationsfiler kan opsættes i Wildfly ved at kopiere dem ind i <wildfly-root>/standalone/deployments. Derudover skal der også deployes en databaseklient-driver i samme mappe. De medfølgende datasource-konfigurationer anvender driveren mysql-connector-java-5.1.29.jar og denne medfølger ikke i projektet. |
Æ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.
Filnavn når deployet | Beskrivelse | Kilde | ||||||
---|---|---|---|---|---|---|---|---|
odr-service-wildfly.war | ODR servicen | odr-service-wildfly-<version>.war | ||||||
odr.war | DGWS/IDWS Proxy . Se Installationsvejledning (DGWS/IDWS Proxy) for dokumentation. War-filen for wsproxy komponenten omdøbes til odr.war, hvilket bevirker at webservice context-path for wsproxy i dette tilfælde bliver /odr. | wsproxy-<version>.war (findes ikke i odr-projektet) | -operations.war | ODR baggrundsjob | odr-operations | odr-migration.war | ODR migeringsværktøj. Deployes kun når migrering skal foretages. | odr-migration-<version>.war |
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.
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.