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.
Først beskrives de softwaremæssige krav, der er til miljøet, samt hvordan kode hentes og bygges. Dernæst beskrives deploymentmiljøet.
Kodestrukturen, kodemæssige afhængigheder til tredjeparts moduler og de forskellige servicemodulers ansvar og design beskrives sidst i dette dokument sammen med testdesign.
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æ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.
Definition | Beskrivelse |
NSP | Den nationale service platform (inden for sundheds-IT) |
DDS | Dokumentdelingsservice |
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 Design og Arkitekturbeskrivelse.
I det følgende antages at koden er hentet ned fra nspop SVN.
Krav til applikationsserveren og operativsystemet er de samme som til produktionsmiljøet. De specifikke krav kan ses i DRS Installationsvejledning.
Derudover er der en række krav til de anvendte udviklingsværktøjer:
Maven 3.0.3 eller højere anvendes.
Man skal bruge Apache Maven til at bygge DRS, hvilket gøres ved at køre kommandoen
$ mvn clean install
I ”target” folderen vil der efterfølgende ligge en kompileret WAR fil ved navn
drs- proxy-0.0.1- SNAPSHOT.war.original
Bemærk at der også ligger en egentlig WAR fil. Denne WAR fil indeholder en række Spring Boot klasser, og
skal ikke bruges til deployment i en Wildfly, men kan i stedet startes ved at køre kommandoen
$ mvn spring-boot:run
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.
Der henvises til installationsvejledningen DRS Installationsvejledning for nærmere instrukser.
Når man udvikler kan det være praktisk at foretage deploy til en lokal Wildfly.
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.
Systemdesign er beskrevet i DRS Design og Arkitekturbeskrivelse.
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:
”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.
.
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
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
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
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-test
Bemærk at dette forudsætter, at service(s) etc. er deployeret på JBoss-serveren, da integrationstestene afvikles imod kørende service(s).
Code coverage analyse er foretaget i projektet med anvendelse af Maven Sonar plugin og tilhørende Sonar repository.
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.