Overblik

Dette dokument beskriver installation og konfiguration af Organdonorregister-servicen (ODR). Konfiguration af tilhørende DGWS/IDWS Proxy er også beskrevet.

Organdonorregister-servicen består af følgende komponent (war-arkiv), der skal konfigureres og deployes på en applikationsserver:

  • odr-service-wildfly: Organdonorregister-servicen. War-arkiv. Servlet-baseret webservice pakket specifikt til Wildfly.

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

Alle filer der refereres til ligger sammen med projektets kildekode i NSP's Subversion. Referencer til stier er relative med udgangspunkt i projektets rodmappe.

Ændringslog

Version

Dato

Ændring

Ansvarlig

1.0.1

2018-08-20

Initialt dokument

Trifork

1.0.22018-08-31Ny releaseTrifork
1.0.32018-09-11Ændret databasedriver til MySQLTrifork
1.0.112019-08-19Opdateret default value for property "minlog.read-activity-text". Tilføjet SQL-script.Trifork
1.0.132019-25-09AjourførtTrifork
1.0.162020-05-25Opdateret properties til slettejobKIT
1.0.172021-12-07Opdateret ifm inaktive cpr numre afvisesKvalitetsIT
1.0.182022-10-24SDS-5679: validering af alderKvalitetsIT
1.0.192023-09-26SDS-6386: ODR - oprydningsjob genbesøgKvalitetsIT

Byggevejledning

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.

Afvikling af unit-tests

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 med følgende Maven-kommando:

mvn clean test

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ø

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 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, 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 kræver en enkelt database til dens egen data. Derudover afhænger den af adgang til et view i en (replikeret) stamdata-database.

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

Databasebrugeren, der tilgår servicens egen database, skal være tildelt følgende rettigheder:

  • 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:

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


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:

Servicens 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

 

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 compose/database/db/test.


Deployment

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

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


Alle konfigurerbare properties bør gennemgås inden idriftsættelse, men standardværdierne er tiltænkt anvendelse i produktion medmindre andet er angivet.


Konfiguration af servicen

Herunder beskrives properties i odr-service-wildfly komponentens konfigurationsfiler.

application.properties

Properties for servicen ses i tabellen herunder.

PropertyBeskrivelseDefault
datasource.odr.jndi-nameAngiver navnet på en JNDI datasource til Organdonorregister-databasenjava:jboss/datasources/ODR-DS
datasource.stamdata.jndi-nameAngiver navnet på den JNDI datasource der giver adgang til en (replikeret) stamdata-databasejava:jboss/datasources/STM-DS
dcc.endpointAngiver 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-textAngiver den tekst der registreres i MinLog, når der bliver læst Organdonorregistering-data for et CPR-nummerL\u00e6sning af Organdonorregistrering

minlog.create-activity-text

Angiver den tekst der registreres i MinLog, når der bliver oprettet Organdonorregistering-data for et CPR-nummerOprettelse af Organdonorregistrering

minlog.delete-activity-text

Angiver den tekst der registreres i MinLog, når der bliver slettet Organdonorregistering-data for et CPR-nummerSletning af Organdonorregistrering

minlog.update-activity-text

Angiver den tekst der registreres i MinLog, når der bliver opdateret Organdonorregistering-data for et CPR-nummerOpdatering af Organdonorregistrering
schemavalidation.validate-requestsAngiver 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
jobs.delete.cpr-max-resultsSlettejob: Angiver maksimum antal rækker med opdateringer i cpr-registry der skal læses ad gangen25
jobs.delete.cpr-max-loopsSlettejob: Angiver maksimum antal batches der skal behandles pr. jobeksekvering2
cprexists.validationlevel

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.statusKonfiguration af inaktive status, liste adskilt af komma30,50,60
cprexists.minageAldersgrænse for oprettelse af organdonation15
whitelisted.level3.cvrsKomma separeret liste af cvr numre, der må kalde servicen med niveau 3 id kort
allowed.idws.audienceDet tilladte audience på indkommende idws requests

https://fsk

nas.app.nameApplikationsnavn til sla-logning ved NAS-kaldorgandonorregister
nas.app.shortnameKort applikationsnavn til sla-logning ved NAS-kald.odr
nas.fail.thesholdGrænse for hvor mange gange NAS-kald må fejle i træk, før NAS opfattes som usund.1
nas.connect.timeout.millisGrænse for hvor lang tid det må tage at oprette forbindelse til NAS (i ms.).10000
nas.read.timeout.millisGrænse for hvor lang tid det må tage at modtage svar fra NAS (i ms.).10000
nas.max.total.connectionsMaksimalt antal samtidige NAS-forbindelser.200
nas.default.max.connections.per.routeMaksimalt antal NAS-forbindelser per rute.20
nas.service.urlNAS Endpointhttp://test1.ekstern-test.nspop.dk:8080/nas2/notificationbroker/service
nas.topicNAS topichttp://sundhedsdatastyrelsen.dk/OrganDonation/2022/05/05:OrganDonationUpdated
nas.idcard.subject.id.typeSubjecttype for IDKort til NAS-kald.medcom:cvrnumber
nas.idcard.subject.idSubjectId for IDKort til NAS-kald.46837428
nas.idcard.subject.nameSubjectname for IDKort til NAS-kald.Funktionssignatur til testmiljø (funktionscertifikat)
nas.idcard.levelSikkerhedsniveau for IDKort til NAS-kald.3
nas.idcard.system.nameSystemnavn i IDKort til NAS-kald.itsystem
nas.sts.endpointEndpointet, hvor Minspærring skal trække sit SOSI IDkort på baggrund af sts.keystorehttp://test2.ekstern-test.nspop.dk:8080/sts/services/NewSecurityTokenService
nas.sts.test.modeBoolsk værdi, der angiver om der anvendes test- eller produktions SOSIFederationtrue
nas.sts.keystoresti til keystore, der indeholder certifikat til at trække Idkort til NAS-kald.Statens_Serum_Institut_FOCES.jks
nas.sts.keystore.passwordPassword til sts.keystoren/a
jobs.delete.max.timeAngiver 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. 

PropertyBeskrivelse
kafka.producer.bootstrap.serversKafka endpoint, som anvendes i forbindelse med kald til MinLog2
kafka.producer.client.idNavnet som ODR vil fremgå med i listen af Producers på et Kafka Cluster.
kafka.producer.key.serializerSerializer key for Kafka producer
kafka.producer.key.value.serializerSerializer 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.

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.

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

Overblik over komponenter

Der følgende beskriver de forskellige deployables som komponenten indeholder.

Filnavn når deployet

Beskrivelse

Kilde

odr-service-wildfly.war

ODR servicen

odr-service-wildfly-<version>.war

odr-operations.war

ODR baggrundsjob

odr-operations.war

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.


  • No labels