...

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

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

...

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.

...

 Introduktion

Dette dokument giver vejledning til installation og konfiguration af NAP Platformen.

 Formål

Formålet med dette dokumentet er, at man med dokumentet i hånden, kan installere NAP Platformen services (NAP) uden yderligere informationer.

Dokumentet rummer guides til installation af de enkelt delkomponenter af NAP platformen. 

Sammenhæng med øvrige dokumenter

Dette dokument er en del af den samlede dokumentation for NAP Platformen.

Dokumentet er udformet, så det i videst muligt omfang opfylder sit formål uafhængigt af de øvrige dokumenter.

Ønskes mere information omkring guide til anvendelse findes dette på NAP Platform - Guide til anvendere.

Ønskes mere information omkring arkitektur og design findes dette på NAP Platform - Design og Arkitektur beskrivelse

 Forudsætninger

Krav til udviklingssoftware:

nap-test-web

Installation

Nap-test-web er en statisk service, som hostes i NSPs wildfly8 image.

Nap-test-web anvender Continuous Integration og Continuous Deployment miljøer til byg og leverance af komponenten.

Koden kan hentes på https://svn.nspop.dk/svn/components/nap/nap-test-web/.

Jenkins

Nap-test-web bygges på NSP's Jenkins server via følgende jobs:

NapTestWeb - build - bygger nap-test-web

NapTestWeb - push release candidate - pusher en release kandidat til NSP's docker registry

NapTestWeb - push snapshot - pusher en snapshot til NSP's docker registry

NapTestWeb - push release - pusher et release til NSP's docker registry

Docker

Nap-Test-Web kan findes på registry.nspop.dk/playground/nap/web/test:snapshot

Docker compose

Nap-test-web leveres som et sæt af Docker Compose filer i folderen https://svn.nspop.dk/src/components/nap/nap-test-web/trunk/compose/

For release x.y.z findes Docker Compose filerne i folderen https://svn.nspop.dk/src/components/nap/nap-test-web/tags/release-x.y.z/

En leverance af nap-reference består af en compose folder som beskrevet ovenfor samt tilhørende tags.

Krav til adgang til andre services

Framing

Servicen benytter sig af nap-angular-sdk og nap-typescript-sdk og er udviklet til at være indlejret i et nap-java-host eller et andet host system, hvor den får alt sin kontekst.

Det meste funktionalitet er bundet op på denne kontekst og det skal derfor opsættes, for at få det fulde ud af nap-test-web.

For opsætning af dette, skal nap-java-host. Opsætning af denne er yderligere beskrevet i dette dokument. 

Krav til applikationsservere

Nap-test-web er udviklet i Docker ved anvendelse af node:12-alpine.

Nap-test-web er bygget til imaget "registry.nspop.dk/platform/nsp:2.1.7".

Konfigurationen er således tilpasset deployering på WildFly 8.2 applikationsservere med OpenJDK 8.

Afvikling

Start

For at kunne køre de ovenstående compose filer kræves et docker netværk kaldet nap_net.

Hvis dette ikke allerede er lavet kør `docker network create nap_net`.

Kør `docker-compose up` fra compose/test mappen, for at starte en wildfly server i docker på nap_net netværket.

Herefter er containeren tilgængelig http://localhost:8080/testweb/ såfremt (https://svn.nspop.dk/src/components/nap/nap-compose/) kører på samme netværk som en reverse proxy.

 Stop

Kør `docker-compose down`.

Nap-administration

Installation

Nap-admin anvender Continuous Integration og Continuous Deployment miljøer til byg og leverance af komponenten.

Nap-lobby-web og Nap-administration ligger som repositories på svn.nspop.dk. Disse skal hentes for anvende de foreslåede compose-setups.

Kør "docker-compose up" fra compose/development, for at starte en wildfly server i docker på nap_net netværket.

Jenkins

Nap-administration bygges på NSP's Jenkins server via følgende jobs.

NapLobbyWeb-build - bygger nap-lobby-web

NapAdmin-build - bygger nap-admin. I denne pibeline kan det vælges at bygge nap-lobby-web, hvis dette ønskes inkluderet.

NapAdmin- push snapshot - bygger nap-lobby-web og ligger bygget ind i roden af nap-admin samt pusher til NSP's docker registry.

NapAdmin - push release - laver et release af nap-admin og pusher til NSP's docker registry.

Docker

Nap admin kan findes på registry.nspop.dk/playground/nap/lobby

Docker-compose

Nap-administration leveres som et sæt af Docker Compose filer i folderen https://svn.nspop.dk/svn/components/nap/nap-administration/trunk/compose/

For release x.y.z findes Docker Compose filerne i folderen https://svn.nspop.dk/svn/components/nap/nap-administration/tags/release-x.y.z/

En leverance af Nap-administration består af en compose folder som beskrevet ovenfor samt tilhørende tags.

Compose folderen indeholder 5 underfoldere:

Konfiguration

Alt konfiguration foregår ved at loade filer fra wildfly modulet dk.sds.nsp.nap.admin.facade.

De følgende konfigurationsfiler skal således volume mappes ind i modulet "dk/sds/nsp/nap/admin/main/" på applikationsserveren (/pack/wildfly8/modules/ i docker).

nap-lobby-ds.xml

Applikationskonfiguration

Disse filer bliver loadet ind på classpath når applikationen deployes.

Ved konfigurationsændringer skal wildfly serveren genstartes.

i NAP Platform - Driftsvejledning er hver enkel fil gennemgået i detaljer.

Afvikling

Start

For at kunne køre de ovenstående compose filer kræves et docker netværk kaldet nap_net.

Hvis dette ikke allerede er lavet kør `docker network create nap_net`.

Kør `docker-compose up` fra compose/test mappen, for at starte en wildfly server i docker på nap_net netværket.

Herefter er containeren tilgængelig http://localhost:8080/admin/ såfremt (https://svn.nspop.dk/src/components/nap/nap-compose/) kører på samme netværk som en reverse proxy.

Stop

Kør `docker-compose down`.

Krav til adgang til andre services

Nap-admin benytter sig af en database. En  mariadb instans der er tilknyttet i compose-filerne. Det er et krav, at denne er opsat og tilgængelig på den url, der er defineret i nap-lobby-ds.xml.

Adgang til denne service er garanteret ved at afvikle compose filerne beskrevet ovenfor.

Framing

Servicen benytter sig af nap-angular-sdk og nap-typescript-sdk og er udviklet til at være indlejret i et nap-java-host eller et andet host system, hvor den får alt sin kontekst.

Det meste funktionalitet er bundet op på denne kontekst og det skal derfor opsættes, for at få det fulde ud af nap-lobby-web.

For opsætning af dette, skal nap-java-host og nap-administration køres parallelt, og opsætning af det er yderligere beskrevet i dette dokument. 

3. Krav til applikationsservere

Nap-admin er udviklet i Docker ved anvendelse af imaget "registry.nspop.dk/platform/nsp:1".

Nap-lobby-web er udviklet i Docker ved anvendelse af node:12-alpine.

Den samlede deployment unit, nap-admin, er bygget til og testet i Docker med imaget  "registry.nspop.dk/platform/nsp:1"

Konfigurationen er således tilpasset deployering på WildFly 8.2 applikationsservere med OpenJDK 8.

nap-host-java

nap-host-java er lavet som executable, og kan hentes på nedenstående links.

Windows

Mac OS X

Linux

Alternativt kan kilde koden bygges med java 13 og køres med `java -jar`

Forbindelse til nap-administration og nap-Lobby

Servicen benytter sig af nap-administration og nap-lobby-web enten lokalt eller på test1

...

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.