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.

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.

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.