Page History
...
Dette dokument beskriver installation og konfiguration af Behandlingstestamenteregister-servicen (BTR) samt tilhørende migreringsværktøj. Konfiguration af tilhørende DGWS/IDWS Proxy er også beskrevet.
Behandlingstestamenteregister-servicen består af 3 komponenter følgende komponent (war-arkiverarkiv), der skal konfigureres og deployes på en applikationsserver:
- 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.
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. |
Ændringslog
Projektet bygges med Maven og kræver Java 8 samt en MariaDB-installation for at kunne afvikle unit-tests.
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. |
Ændringslog
Version | Dato | Ændring | Ansvarlig |
---|---|---|---|
1.0.1 | 2018-08-15 | Initialt dokument | Trifork |
1.0.2 | 2018-08-31 | Ny release | Trifork |
1.0.3 | 2018-09-06 | Endpoints ændret fra /ltr-btr til /btr | Trifork |
1.0.4 | 2018-09-11 | Ændret databasedriver til MySQL | Trifork |
1.0.6 | 2018-10-15 | Tilføjelse af tre SQL-scripter | Trifork |
1.0.12 | 2019-08-19 | Opdateret default value for property "minlog.read-activity-text.ltr" og "minlog.read-activity-text.btr". Tilføjet to SQL-scripter. | Trifork |
1.0.14 | 2019-25-09 | Ajourført | Trifork |
1.1.3 | 2020-05-26 | Opdateret properties til slettejob | KvalitetsIT |
1.1.7 | 2021-09-06 | Opdateret ifm. udfasning af dgws/idws-proxy. | KvalitetsIT |
1.1.8 | 2021-10-12 | Opdateret ifm. udfasning af btr-snitflade med accept fra pårørende, værge eller fremtidsfuldmægtig for uafvendeligt døende | KvalitetsIT |
1.1.9 | 2021-10-25 | Opdateret ifm inaktive cpr numre afvises | KvalitetsIT |
1.1.10 | 2022-10-18 | Tilføjet minlog.read-activity-text-with-only-forced-treatment.btr | KvalitetsIT |
1.1.11 | 2022-10-25 | TIlføjet cprexists.minage | KvalitetsIT |
1.1.33 | 2023-11-09 | SDS-6387: omlægning af slettejob | KvalitetsIT |
Version | Dato | Ændring | Ansvarlig |
1.0.1 | 2018-08-15 | Initialt dokument | Trifork |
1.0.2 | 2018-08-31 | Ny release | Trifork |
1.0.3 | 2018-09-06 | Endpoints ændret fra /ltr-btr til /btr | Trifork |
1.0.4 | 2018-09-11 | Ændret databasedriver til MySQL | Trifork |
1.0.6 | 2018-10-15 | Tilføjelse af tre SQL-scripter | Trifork |
1.0.12 | 2019-08-19 | Opdateret default value for property "minlog.read-activity-text.ltr" og "minlog.read-activity-text.btr". Tilføjet to SQL-scripter. | Trifork |
1.0.14 | 2019-25-09 | Ajourført | Trifork
Byggevejledning
For at bygge projektet og dets deployables (war-filer) uden at køre unit-tests og integrationstests, anvendes følgende Maven kommando:
...
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.
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 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, 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
...
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, 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.
...
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 compose/database/db/migration. De er inddelt i 3 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.
Info |
---|
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 Livstestamenteregister-database
- ltr/V1__create_LivingWill.sql
- ltr/V2__create_PropertiesLivingWill.sql
- ltr/V8__add_PersonIdentifier_index.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
- btr/V9__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 compose/database/db/test. |
Deployment
Komponenten deployes vha. NSP's platform Docker image og konfigurationsfiler mountes i containeren som angivet i projektets Compose-filer.
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-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. |
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
...
Info |
---|
Scripts 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 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
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 compose/database/db/test. |
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.
Info |
---|
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 ltr-btr-service-wildfly komponentens konfigurationsfiler.
application.properties
Property | Beskrivelse | Default |
---|---|---|
datasource.btr.jndi-name | Angiver navnet på en JNDI datasource til Behandlingstestamenteregister-databasen | java:jboss/datasources/BTR-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.ltr | Angiver det endpoint, som DCC'en skal kalde for Livstestamenteregistret. Dette kommer til at fremgå af den XML, der returneres i /dksconfig. Bør ændres før produktion. | http://test1.fsk.netic.dk:8080/btr/ltr |
dcc.endpoint.btr | Angiver det endpoint, som DCC'en skal kalde for Behandlingstestamenteregistret. Dette kommer til at fremgå af den XML, der returneres i /dksconfig . Bør ændres før produktion. | http://test1.fsk.netic.dk:8080/btr/btr |
minlog.read-activity-text.ltr | Angiver den tekst der registreres i MinLog, når der bliver læst Livstestamente-data for et CPR-nummer. | L\u00e6sning af Livstestamente |
minlog.read-activity-text.btr | Angiver den tekst der registreres i MinLog, når der bliver læst Behandlingstestamente-data for et CPR-nummer. | L\u00e6sning af Behandlingstestamente |
minlog.read-activity-text-with-only-forced-treatment.btr | Angiver den tekst der registreres i MinLog, når der bliver læst Behandlingstestamente-data som kun indeholder tvang ved somatisk behandling for et CPR-nummer. | |
minlog.create-activity-text.btr | Angiver den tekst der registreres i MinLog, når der bliver oprettet Behandlingstestamente-data for et CPR-nummer. | Oprettelse af Behandlingstestamente |
minlog.delete-activity-text.ltr | Angiver den tekst der registreres i MinLog, når der bliver slettet Livstestamente-data for et CPR-nummer. | Sletning af Livstestamente |
minlog.delete-activity-text.btr | Angiver den tekst der registreres i MinLog, når der bliver slettet Behandlingstestamente-data for et CPR-nummer. | Sletning af Behandlingstestamente |
minlog.update-activity-text.ltr | Angiver den tekst der registreres i MinLog, når der bliver opdateret Livstestamente-data for et CPR-nummer. | Opdatering af Livstestamente |
minlog.update-activity-text.btr | Angiver den tekst der registreres i MinLog, når der bliver opdateret Behandlingstestamente-data for et CPR-nummer. | Opdatering af Behandlingstestamente |
btr.open-date | 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. | 2018-06-01T00:00:00+01:00 |
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.status | Konfiguration af inaktive status, liste adskilt af komma | 30,50,60 |
cprexists.minage | Minimum alder for oprettelse af behandlingstestamente | 18 |
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 | https://fsk |
nas.app.name | Applikationsnavn til sla-logning ved NAS-kald | treatmentwillregister |
nas.app.shortname | Kort applikationsnavn til sla-logning ved NAS-kald. | btr |
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.livingwillnotification | NAS topic ved opdateringer af livstestamente | http://sundhedsdatastyrelsen.dk/LivingWill/2022/05/05:LivingWillUpdated |
nas.topic.treatmentwillnotification | NAS topic ved opdateringer af behandlingstestamente | http://sundhedsdatastyrelsen.dk/TreatmentWill/2022/05/05:TreatmentWillUpdated |
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 |
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.
Property | Beskrivelse |
---|---|
kafka.producer.bootstrap.servers | Kafka endpoint, som anvendes i forbindelse med kald til MinLog2 |
kafka.producer.client.id | Navnet som BTR 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-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
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 .
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 er mountet i Docker containeren under <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 -komponenten kræver adgang til 2 en JNDI datasources-datakilde. Disse Det skal opsættes i Wildfly og refereres henvises til i servicens tjenestens application.properties.
Overblik over komponenter
...
.properties.
Overblik over komponenter
Filnavn når deployet | Beskrivelse | Kilde | |||
---|---|---|---|---|---|
btr-service.war | LTR-BTR servicen | ltr-btr-service-wildfly-<version>.war | |||
btr.war | DGWS/IDWS Proxy. Se Installationsvejledning (DGWS/IDWS Proxy) for dokumentation. War-filen for wsproxy komponenten omdøbes til btr.war, hvilket bevirker at webservice context-path for wsproxy i dette tilfælde bliver /btr. | wsproxy-<version>.war (findes ikke i projektet) | |||
btr-service.war | LTR-BTR servicen | ltr-btr-service-wildfly-<version>.war | |||
ltr-btr-operations.war | LTR-BTR baggrundsjob | ltr-btr-operations | ltr-migration.war | LTR migeringsværktøj. Deployes kun når migrering skal foretages. | ltr-migration-<version>.war |
Se driftsvejledningen for yderligere information.
...