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 bliver leveret efter retningslinierne sat i NSP Continuous Integration & Delivery.

Konfigurering af leverence

SORLS bruger fire konfigurations filer, som alle findes i compose/configuration/ mappen i roden af servicens mappe på SVN. Nedenstående tabel indeholder konfigurations filerne.

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

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

sdm-ds.xml

Denne fil indeholder opsætningen af forbindelsen til SDM 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 sorls.properties, kan denne fil helt skippes, ellers er det vigtigt at JNDI navnene stemmer overens.

Denne database benyttes til opslag på SOR stamdata.

Konfigurering/Opsætning af SOR database

For at opsætte SOR databasen fuldt, kan følgende blive eksekveret på den valgte database server:

DROP DATABASE IF EXISTS sor;

CREATE DATABASE sor;

CREATE USER sor IDENTIFIED BY 'sor';

GRANT ALL ON sor.* TO 'sor'@'%';

USE sor;

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.

Konfigurering/Opsætning af SDM database

Opslag servicen benytter tabeller oprettet af SOR2 importer projektet, og det antages at denne har opsat alle relevante tabeller i sdm4 databasen på forhånd.

Ligeledes er det forventet, at SOR2 importer projektet indsætter og vedligeholder data i de anvendte tabeller.

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/sor-opslag/status

Dette burde give et XML output der ligner følgende:

<ServiceStatus>
  <SealVersion>2.4.5</SealVersion>
  <CurrentDate>2019-01-02T16:24:15.619+01:00</CurrentDate>
  <StartedDate>2019-01-02T15:51:36.844+01:00</StartedDate>
  <LatestRequestDate>2019-01-02T16:20:51.670+01:00</LatestRequestDate>
  <LatestSuccessDate>2019-01-02T16:20:51.670+01:00</LatestSuccessDate>
  <RequestsTotal>54</RequestsTotal>
  <Requests24h>54</Requests24h>
  <RequestErrorsTotal>6</RequestErrorsTotal>
  <RequestErrors24h>6</RequestErrors24h>
  <RequestDurationAverageTotal>95</RequestDurationAverageTotal>
  <RequestDurationAverage24h>95</RequestDurationAverage24h>
  <RequestDurationMaxTotal>1012</RequestDurationMaxTotal>
  <RequestDurationMax24h>1012</RequestDurationMax24h>
  <UpDownScore>0</UpDownScore>
  <ServiceUp>true</ServiceUp>
</ServiceStatus>

Dernæst kan det testes at hente WSDL filen for applikationen:

https://localhost/sor-opslag/SORLookupService?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 sorls.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.