Indholdsfortegnelse
Opsætning, krav og forudsætninger til platform
Applikationen er udviklet under den forudsætning, at den skal køre under en Wildfly 8.2 server, og køre med Java 8. Derudover er den under den antagelse, at den skal køre på de enkelte NSP instanser, og ikke i NSP backoffice.
Applikationen har brug for, at MySQL driveren er installeret og tilgængelig i Wildfly. Denne vil blive brugt i forbindelse med CVR whitelisting opslag beskrevet senere.
Applikationen forudsætter desuden, at audit API biblioteket er installeret og tilgængeligt i Wildfly.
Applikationen selv leveres som en .war
fil, og skal lægges ind under deployments/
mappen. Dernæst vil Wildfly starte applikationen op. Sørg for at alle konfigurations filerne er de forventede steder, samt at de er korrekt udfyldt, på forhånd.
Konfigurering af leverence
SORUS bruger tre konfigurations filer, som alle findes i resource/
mappen i roden af servicens mappe på SVN. Nedenstående tabel indeholder konfigurations filerne, samt deres forventede installations mappe i Wildfly's enten domain/
eller standalone/
mapper.
Fil | Installations lokation |
---|---|
log4j-sorus.properties | configuration/ |
sorus-ds.xml | deployments/ |
sorus.properties | configuration/ |
log4j-sorus.properties
Leverancen benytter Apache Log4J til applikations logning, og denne fil er konfigurering af denne.
Nærmere omkring opsætning af Log4J appenders kan findes på projektets egen dokumentations side her.
sorus.properties
Dette er den centrale konfigurations fil for applikationen. Nedenfor er en gennemgang af alle indstillinger, og kommentare til disse. Alle værdier skal være udfyldt for at applikationen kan fungerer korrekt.
Navn | Standard værdi | Kommentar |
---|---|---|
app.name | SOR Opdatering Service | Navnet for applikationen |
app.name.short | sorus | Applikationens forkortelse |
app.url | URL på applikationen, bruges i forbindelse med DKS og udstilling af WSDL | |
app.security.seal.federation.test | false | Angiver om SEAL modulet skal benytte test federation ved validering af de certifikater, som er brugt til signering af en request |
sor.db.jndi | java:jboss/datasources/SORRO | JNDI navn på den datasource applikationen skal benytte for database opslag |
sor.db.retry.max | 5 | Antallet af gange applikationen skal forsøge at udføre et database opslag, før at den giver op |
sor.db.retry.wait | 1000 | Tiden i millisekunder applikationen venter mellem hvert forsøg på opslag i databasen |
sor.backend.security.certificate.validation | true | Angiver om klienten for backend applikationen skal validere SSL certifikater, eller om den skal godkende alle. Denne burde ikke skulle slås fra, med mindre at backenden benytter et self-signed certifikat. |
sor.backend.security.username | Brugernavn til brug ved Basic Authentication mod backenden | |
sor.backend.security.password | Password til brug ved Basic Authentication mod backenden | |
sor.backend.url.base | Base URL for backenden, benyttes som stub som alle andre URLs bliver genereret ud fra | |
sor.backend.url.service | Restende af URL for SOAP endpoints for backenden | |
status.score.max | 100 | Bruges til udregning om applikationen er oppe og tilgængelig, eller om DCC skal betragte den som værende nede. Der vil internt blive holdt en score for at vurdere, om servicen er oppe eller ej. Denne vil blive påvirket af resultatet af kald mod backenden. Dette er den maksimale værdi denne score kan komme op på. |
status.score.down | 60 | Bruges til udregning om applikationen er oppe og tilgængelig, eller om DCC skal betragte den som værende nede. Hvis den interne score overstiger denne værdi, så vil servicen blive betragtet som værende nede. |
status.score.success | 40 | Bruges til udregning om applikationen er oppe og tilgængelig, eller om DCC skal betragte den som værende nede. Når et kald går succefuldt igennem til backend servicen, så vil denne værdi blive trukket fra den interne score. Den interne værdi kan ikke blive lavere end 0. Et kald som indeholder forkerte værdier vil stadig blive betragtet som værende en succes. Det er kun i de tilfælde, at backend servicen ikke kan nås, eller svarer tilbage med andet end HTTP 200, at det ikke bliver betragtet som værende en succes. |
status.score.error | 20 | Bruges til udregning om applikationen er oppe og tilgængelig, eller om DCC skal betragte den som værende nede. Når et kald ikke går succefuldt igennem til backend servicen, så vil denne værdi blive lagt til den interne score. |
sor-ds.xml
Denne fil indeholder opsætningen af forbindelsen til SOR databasen på NSP. Filen bruges af Wildfly til at opsætte en forbindelse til databasen, og derved ikke af applikationen direkte. Hvis en eksisterende datasource er skrevet ind i sorus.properties
, kan denne fil helt skippes, ellers er det vigtigt at JNDI navnene stemmer overens.
Denne database benyttes til CVR whitelisting på indkomne forspørgelser.
Konfigurering/Opsætning af database
For at opsætte databasen fuldt, kan følgende blive eksekveret på den valgte database server:
DROP DATABASE IF EXISTS sorus; CREATE DATABASE sorus; CREATE USER sor IDENTIFIED BY 'sorus'; GRANT ALL ON sorus.* TO 'sorus'@'%'; USE sorus; DROP TABLE IF EXISTS whitelist; CREATE TABLE whitelist ( id INT NOT NULL AUTO_INCREMENT, cvr CHAR(8) NOT NULL DEFAULT '0', comment VARCHAR(2048) NOT NULL DEFAULT '0', PRIMARY KEY (id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
Derefter kan yderligere whitelistede CVR numre blive indsat med statements der ligner følgende:
INSERT INTO whitelist (cvr, comment) VALUES ('46837428', 'Statens Serum Institut');
Comment
feltet kan indeholde hvad end man vil, i eksemplet er det bare brugt for at sige hvilken virksomhed der har det CVR nummer. Det vil ikke blive brugt i applikationen, det er udelukkende til hjælp når der arbejdes direkte i databasen uden om applikationen.
Det er vigtigt at få indsat relevante CVR numre som skal bruges til at teste applikationen med, ellers vil authorisering af forespørgelser fejle.
Præliminær smoketests
https://localhost/
bliver i de følgende URL'er brugt som eksempel. Ret disse til så de rent faktisk passer med virkeligheden.
Når servicen er blevet startet op, og igen fejl er sket i loggen under opstart, så kan applikationen hurtigt afprøves ved at gå ind på:
https://localhost/status?verbose
Dette burde give et XML output der ligner følgende:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ServiceStatus> <SealVersion>2.4.5</SealVersion> <CurrentDate>2019-01-02T16:02:26.837+01:00</CurrentDate> <StartedDate>2019-01-02T15:51:36.844+01:00</StartedDate> <LatestRequestDate>2019-01-02T16:01:30.533+01:00</LatestRequestDate> <LatestSuccessDate>2019-01-02T16:01:30.533+01:00</LatestSuccessDate> <RequestsTotal>36</RequestsTotal> <Requests24h>36</Requests24h> <RequestErrorsTotal>4</RequestErrorsTotal> <RequestErrors24h>4</RequestErrors24h> <RequestDurationAverageTotal>81</RequestDurationAverageTotal> <RequestDurationAverage24h>81</RequestDurationAverage24h> <RequestDurationMaxTotal>991</RequestDurationMaxTotal> <RequestDurationMax24h>991</RequestDurationMax24h> <UpDownScore>0</UpDownScore> <ServiceUp>true</ServiceUp> </ServiceStatus>
Dernæst kan det testes at hente WSDL filen for applikationen:
https://localhost/v3/SOROpdateringService?wsdl
I sektionen af den XML som beskriver service adressen, der kan det checkes at den står som forventet. Den sættes ud fra hvad er angivet i app.url
fra sorus.properties
filen, og det skal gerne stemme overens med den kaldte URL for at hente WSDL filen (uden ?wsdl
delen). Hvis denne er korrekt, så vil servleten for DKS også rapportere den korrekte URL tilbage.
Sikkerhedskrav til opsætning
Det anbefales kraftigt, at applikationen bliver opsat til at køre over en sikker forbindelse. Hvis ikke, så er det let for en tredjepart at kunne opfange og kopiere SOAP headers, og udgive sig for at være en anden virksomhed, og have alle de samme rettigheder som den virksomhed har.