AFVENTER ENDELIG GODKENDELSE

Indholdsfortegnelse

Opsætning af udviklingsmiljø

Alt koden kan findes i følgende Subversion repository:

https://svn.nspop.dk/svn/capgemini/SORServices/NSP/sorls

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

Opslag servicen har følgende moduler:

Under hvert eneste modul ligger også en Dockerfile for at generere Docker images af hvert modul.

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

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 package step også køres. I det tilfælde vil kommandoen se sådan ud:

mvn test package

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

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. Desuden, integration tests er blevet lavet mod den nuværende tilgægelige test dataset som betyder at hvis nogle af data værdier ænder sig, kan nogle af de test fejle. For eksample, en test for search operation sender SOAP request med partial entity name som "tr", og forventer at response har 7 records ialt. Hvis en anden dataset har mere eller mindre end 7 records, så betyder det at denne test assert vil fejle. På denne grund, er der et antal properties som er blevel defineret in property filen. Disse properties indeholder forventede værdier for nogle af de test. Hvis en test fejler på grund af forkert antal records, så kan disse properties ændres til at passe test resultat. For eksemple, den ovennævnte test for partial entity name returnerer 7 records, men hvis en anden dataset retunerer 10 records, kan vi ændre på property it.test.searchpartialentityname.count1 uden at genstarte eller gendeploy servicen.   

Integration tests kan indstilled ved at rette i filen:

src/test/resources/integration/sorls.properties

Alternativt kan properties sættes og/eller overskrives på kommando linien. Følgende er eksempel på at overskrive URL til applikationen:

mvn verify -PintegrationTest -DargLine="-Dsorls.url=http://<host>:8080/sor-opslag"

Deployment

Et war artefakt 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/tags/4/playground%2Fnspbase er defineret, samt beskrivelsen af NSP Access Handler Installationsvejledning. Filen SorLookupService/target/sor-opslag.war kopieres til standalone/deployment/ mappen i Wildfly. Ligeledes skal SorLookupService/resources/sor-ds.xml og SorLookupService/resources/sdm-ds.xml (som indeholder henholdvis opsætning af datasourcer til whitelisting databasen og SDM databasen) kopieres til standalone/deployment/ mappen, imens at SorLookupService/resources/sorls.properties og SorLookupService/resources/log4j-sorls.properties skal kopieres til standalone/configuration/ mappen i Wildfly.

Opdatering af XSD filer

Hvis der kommer opdatering af XSD filerne for sor objekter, så skal disse lægges ind to steder. Det primære sted SorLookupService/src/main/webapp/schema/sor, da det er hvor at opslag servicen genererer sine klasser ud fra.

Ændringer af SOAP interface WSDL filen skal kun ske i SorLookupService/src/main/webapp/sorls.wsdl. SVN vil se en ændring af linien, hvor at der importeres sortypes.xsd; det anbefales at dette rettes tilbage manuelt til:

<xs:include schemaLocation="schema/sor/sortypes.xsd"/>