Table of Contents

1       Introduktion

...

Introduktion

Formål

Formålet med dette dokument er at beskrive hvordan et udviklingsmiljø, til videreudvikling af FSK Registry, kan sættes op, samt hvordan koden bygges, deployes og testes.

...

Kodestrukturen, kodemæssige afhængigheder til tredjeparts moduler og de forskellige servicemodulers ansvar og design beskrives sidst i dette dokument sammen med testdesign.

...

Sammenhæng med øvrige dokumenter

Dette dokument er en del af den samlede dokumentation for FSK Registry.

Dokumentets relation til de øvrige dokumenter er beskrevet i dokumentationsoversigten for projektet FSK Registry Adapter.

...

Læsevejledning

Læser forventes at have kendskab til Java softwareudvikling med anvendelse af Maven og WildFly.

Hvor der i teksten er angivet <component base> refereres til topniveaufolderen for kildekoden for komponenten.

...

Definitioner og referencer

...

Introduktion til

...

FSK Registry

FSK Registry udstiller netop een web service - ITI-18 Registry Stored Query.

FSK Registry

...

Dokument Registreringsservicen (DRS) er forholdsvis simpel i opbygning, og består primært af en Servlet,
der agerer SOAP proxy mellem multiple anvendere og en enkelt pre-konfigureret backend service.
DRS er en Java baseret komponent, der baserer sig på Java 7 og Spring frameworket. Der anvendes Spring
Boot som konfiguration og konventionsværktøj omkring Spring Frameworket.

Design og arkitektur er beskrevet: DRS FSK Registry Design og Arkitekturbeskrivelse.

...

Opsætning af udviklingsmiljø

I det følgende antages at koden er hentet ned fra nspop SVN.

...

SVN: https://svn.nspop.dk/svn/kvalitetsit/fskregistry

Krav til software

Krav til applikationsserveren og operativsystemet er de samme som til produktionsmiljøet. De specifikke krav kan ses i DRS Installationsvejledning .for FSK Registry Adapter

Derudover er der en række krav til de anvendte udviklingsværktøjer:

Maven 3.0.3 eller højere anvendes.

...

Bygge WAR filen

Man skal bruge Apache Maven til at bygge DRSFSK Registry, hvilket gøres ved at køre kommandoen
$ mvn clean installI ”target” folderen vil der efterfølgende ligge en kompileret WAR fil ved navn

drs- proxy-0.0.1- SNAPSHOT.war.original

...

Efter by kan den installerbare WAR fil findes her:

/fskregistry-war/target/fskregistry.war

Dette gør det muligt at afvikle DRS lokalt, uden først at deploye den i en Wildfly applikationsserver.

Når man afvikler DRS via denne kommando, bliver indholdet af ”config” folderen placeret på classpath, og
konfiguration, keystores m.m. hentes fra denne folder.

...

Deployment på Wildfly

Der henvises til installationsvejledningen DRS Installationsvejledning for FSK Registry Adapter for nærmere instrukser.

...

Udviklers workstation

Når man udvikler kan det være praktisk at foretage deploy til en lokal Wildfly.

4.2           NIAB

Det anbefales at benytte NSP-in-a-box (NIAB) til, da denne indeholder en JBoss der er konfigureret på samme måde som den fundet ved operatøren, samt at NIAB anvender et Linux operativsystem.

...

Beskrivelse af systemdesign

Systemdesign er beskrevet i DRS FSK Registry Design og Arkitekturbeskrivelse.

...

Beskrivelse af kildekodens strukturering og design

6.1           Kode strukturering

Kildekoden bygges vha Apache Maven, og kildekoden er struktureret som Maven moduler, som vist
nedenfor.├── dummy-client
│   ├── config
│   ├── pom.xml
│   └── src
│   └── main
│   ├── java
│   └── resources
├── proxy
│   ├── config
│   └── src
│   └── main
│   ├── java
│   ├── resources
│   └── webapp
├── tool
│   ├── config
│   └── src
│   └── main
│   └── java
└── wildfly-configuration

”dummy-client” og ”tool” er simple værktøjer der er blevet anvendt under udviklingen af DRS, da der ikke
var adgang til en egentligt backend service i starten af udviklingsprojektet.
”dummy-client” er et simpelt værktøj til at trække et token, og genere et DGWS-beriget SOAP-request, der
efterfølgende kan afspilles via et HTTP værktøj som Postman eller lignende.
”tool” er en simpel ”hello world” SOAP service, der kan anvendes som en backend service. Den er
hardkodet til altid at give det samme svar – et eksempel svar fra en ITI-41 service.
”proxy” modulet er den egentlige leverance, og det er her at DRS kildekoden befinder sig.

Der er afhængigheder til forskellige artefakter, hvoraf følgende er skabt i regi af NSI:

• seal 

6.2      Generelt design af DRS

”dummy-client” og ”tool” er simple værktøjer der er blevet anvendt under udviklingen af DRS, da der ikke
var adgang til en egentligt backend service i starten af udviklingsprojektet.

...

.
├── fskregistry-xds
├── fskregistry-app
├── fskregistry-war
    └── src
        ├── main
        │   ├── java
        │   ├── resources
        │   └── webapp
        │       └── WEB-INF
        │           ├── jboss-deployment-structure.xml
        │           └── web.xml
        └── test
            ├── conf
            │   ├── fskreg.properties
            │   ├── fskreg.properties_old
            │   ├── fskreg.properties_tilrettet
            │   ├── log4j-fskregistry-ws.xml
            │   ├── log4j-nspslalog-fskreg.properties 
            │   ├── log4j.properties
            │   ├── module.xml
            │   └── nspslalog-fskreg.properties
            ├── installation
                └── fsk-ds.xml

fskregistry-xds modulet indeholder koden til selve ITI-18 servicen.

fskregistry-app indeholder applikationslogikken - f.eks. den konkrete validering af patient id, beregning af DocumentEntry samt SQL kaldene mod databasen

fskregistry-war står for selve pakketeringen som WAR fil. Herunder JBoss specifikke deployment descriptor samt eksempel konfiguration (WildFly Modul). 

Beskrivelse af testsetup

...

.

6.3      Generelt design af samtykkeadministration

Nedenstående figur giver et overblik over de væsentligste package dependencies for samtykkeadministrationsservicen (consent-administration). Der er ikke tale om en komplet nedbrydning.

Figur 1 consent-administration dependencies

6.4      Generelt design af samtykkeverifikation

Nedenstående figur giver et overblik over de væsentligste package dependencies for samtykkeverifikationsservice (consent-verification). Der er ikke tale om en komplet nedbrydning.

Figur 2 consent-verification dependencies

7       Beskrivelse af testsetup

...

Unittests (JUnit)

JUnit anvendes til implementering af unit tests. Der er kontinuert gennemført unit tests på alle komponenter i projektet.

Unit tests kan afvikles ved at køre:

mvn test

...

Integrationstests

...

Maven Failsafe plugin anvendes til gennemførelse af integrationstests af samtykkewebservices.

Integrationstestene af samtykkeadministration er afhængige af at Min-log-registreringsservicen er deployet.

Det nødvendige testdata læses automatisk på af maven-scriptet, inden integrationstestene afvikles.

Integrationstests kan afvikles ved at køre:

mvn verify –Pexternal-testtest -Pintegration-tests -Dintegrationtestpropdir=src/test/integrationstest-localhost

Bemærk at dette forudsætter, at service(s) etc. FSK Registry er deployeret på JBoss-serveren, da integrationstestene afvikles imod kørende service(s).

7.3           Code coverage (Sonar)

Code coverage analyse er foretaget i projektet med anvendelse af Maven Sonar plugin og tilhørende Sonar repository.

7.4      Performancetests (JMeter)

Performance test gennemføres med anvendelse af JMeter.

Testen består i at SOAP-requestet fra to integrationstests, i samtykkeverifikationsservicen, sendes til servicen 100 gange i streg i 10 parallelle tråde.

SOAP-requestet genereres ved at køre alle integrationstestene til verifikationsservicen (ConsentVerificationServiceIT). De to udvalgte integrationstests er verifyDataForPositiveConsentForDataForOrg og verifyDataSpecificResultForNegativeConsentForDataForAll.Performancetesten findes i dds/performance.