Indholdsfortegnelse
Opsætning af udviklingsmiljø
Alt koden kan findes i følgende Subversion repository:
https://svn.nspop.dk/svn/capgemini/SORServices/NSP/sorus
Koden kan derefter importeres som projekt i en ønsket IDE (som Eclipse eller IntelliJ), der er ingen eksplicit grund til at skulle bruge en bestemt.
Projektet bygges af Maven, og er lavet til at køre under Java 8 og Wildfly 8.
Det anbefales også at installere Docker, men det er ikke strengt nødvendigt.
Beskrivelse af kodens struktur
Opdater servicen har følgende moduler:
Navn | Beskrivelse |
---|---|
SorBackend-stub | Stub version af SOR backend servicen, praktisk at benytte denne under daglig udvikling. Har til opgave at lave en tilfredsstillende substitut for den rigtige backend, komplet med basic authentication og REST services, men som bare accepterer alt input ukritisk. Den har ingen memory overhovedet, ud over at et nyt ID bliver udleveret ved CreateSorEntity operationen (bevares ikke hen over restart af servicen). |
SorDB | Indeholder filer med schema til opsætning af CVR whitelisting |
SorUpdateService | Selve opdatering servicen, inklusiv kode genereret fra WSDL og XSD filer, og unit og integration tests |
Under hvert eneste modul ligger også en Dockerfile
for at generere Docker images af hvert modul.
Opdater servicen er implementeret med Den Gode Webservice (DGWS), hvor at Seal.Java er brugt til at håndtere headers. Servicen er implementeret i Spring Boot. Biblioteker som leveres af Wildfly, bliver ikke inkluderet i den resulterende war fil.
To Maven plugins benyttes til at generere kode; cxf-codegen-plugin
og jaxb2-maven-plugin
. JAXB pluginet bliver brugt til at generere klasser ud fra specifikke XSD filer, imens at CXF pluginet bliver brugt til at generere klasser ud fra WSDL filer. Klasser genereret af CXF pluginet giver ikke nødgenvigvis en afhængighed af Apache CXF, men der er inkluderet et plugin i dette, som generere en override af toString()
på samtlige genererede klasser, som er afhængig af et CXF specifikt bibliotek. Dette bør uden videre kunne fjernes uden tab af funktionalitet, men er praktisk i forhold til debugging.
Apache CXF benyttes til at håndtere JAX-WS klient implementationerne. Ligeledes benyttes Apache CXF til server implementationen af stub backend servicen.
Beskrivelse af test setup
Unittests
Unittests kan udføres ved at køre følgende Maven kommando:
mvn test
Hvis test coverage rapporten skal skrives, skal Maven's verify
step også køres. I det tilfælde vil kommandoen se sådan ud:
mvn test verify
Coverage rapporten vil kunne findes under følgende lokation:
target/site/jacoco/index.html
Unittests kan indstilles ved at rette i filen:
src/test/resources/unit/sorus.properties
Alle test properties burde allerede være opsat som de bør være, og ingen konfiguration er nødvendigt.
Integrationstests
Integration tests kan udføres ved at køre følgende Maven kommando:
mvn verify -P integrationTests
Integration tests sker først på verify
steppet, og laver valide forespørgelser mod en deployeret service. Det er rigtige forespørgelser mod en rigtig deployment, så fejl på grund af datas indhold kan opleves, selvom at selve formen er korrekt. For eksempel, der forsøges oprettet en SOR enhed med et CVR, som allerede eksisterer i systemet. Dette vil fejle, da CVR skal være unikt, også selvom at den tilhører en slettet/lukket enhed.
Integration tests kan indstilled ved at rette i filen:
src/test/resources/integration/sorus.properties
Alternativt kan properties sættes og/eller overskrives på kommando linien. Følgende er eksempel på at overskrive URL til applikationen:
mvn verify -P integrationTests -DargLine="-Dsorus.url=http://differenturl:8080/sor-opdatering"
Deployment
En war fik kan genereres ved at køre Maven kommandoen:
mvn package
I roden af projektet findes en docker-compose.yml
fil, som laver et deployment af opdater servicen og opsætning, samt database for whitelisting og stub backend service. Dette er den anbefalede måde at prøve en deployment på, da det vil ske i et produktion-lignende miljø hver gang.
Alternativt kan servicen blive deployed på en lokal Wildfly server. Det anbefales at sætte denne op i forhold til hvordan imaget https://registry.nspop.dk/harbor/projects/4/repositories/playground%2Fnsp/tags/stable er defineret (Dockerfile er inkluderet i image). Filen SorUpdateService/target/sor-opdatering.war
kopieres til standalone/deployment/
mappen i Wildfly. Ligeledes skal SorUpdateService/resources/sorus-ds.xml
(som indeholder opsætning af datasource til whitelisting databasen) kopieres til standalone/deployment/
mappen, imens at SorUpdateService/resources/sorus.properties
og SorUpdateService/resources/log4j-sorus.properties
skal kopieres til standalone/configuration/ mappen i Wildfly.
Uanset hvilken måde deployment bliver foretaget på, så vil bemærkningen under SOR backend være relevant.
Bemærkninger
SOR backend
Der er en rigtig udvikling deployment af SOR backend servicen, men den kræver at deployment af opdater servicen kan nå sundhedsdatanettet (SDN). Stub backend servicen (som er del af denne kodebase) er udviklet blandt andet på grund af dette, og det anbefales primært at benytte den under udvikling og indledende integration test. Stub servicen genereres ud fra samme WSDL fil som den rigtig backend udstiller; denne skal dog opdateres manuelt lokalt, og kan findes i external/
mappen i roden af projektet.
Hvis ens udvikling setup er på SDN, og den rigtige backend kan benyttes, skal man være opmærksom på, at den udelukkende kan kontaktes på IPv6. Hostnavnet vil kunne resolves til en IPv4 adresse, men denne kan ikke bruges overhovedet. I skrivende stund vil Wildfly images for NSP blive opsat med -Djava.net.preferIPv4Stack=true
i standalone.conf
filen (standalone.conf.bat
hvis det er sat op på Windows); det er vigtigt at denne switch bliver sat til false, da at den ubruglige IPv4 adresse vil få Wildfly til slet ikke at prøve IPv6 adressen.
Opdatering af XSD filer
Hvis der kommer opdatering af XSD filerne for backend servicen, så skal der opdateres to steder.
For hvor fra at klasserne for klient implementationen mod backenden, læses WSDL og XSD filer fra external/schema/sor
. Det er også herfra at stub backenden genererer sine klasser fra, hvis denne benyttes.
For hvor fra at klasserne for server implementationen, læses WSDL filen fra SorUpdateService/src/main/webapp, og alle XSD filer er at finde under SorUpdateService/src/main/webapp/v3/schema
.
Backenden genererer en WSDL fil med samtlige typer den benytter indlejret i. For at benytte dem for server implementationen af SORUS skal disse først kopieres ud i separate filer. Yderligere er backenden kun i stand til at sætte typen xs:dateTime
på alle dato felter selvom at det bør kun være xs:date
. Dette er en begrænsning i .NET som den rigtige backend er skrevet i, men der er ikke oplevet nogen fejl ved manuelt at ændre disse felter til xs:date
.