1. 1. Introduktion

1.1. 1.1. Formål

Formålet med dette dokument er at beskrive, hvordan et udviklingsmiljø til videreudvikling af NXRG 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.

1.2. 1.2. Sammenhæng med øvrige dokumenter

Dette dokument er en del af den samlede dokumentation for NXRG.

Dokumentets relation til de øvrige dokumenter er beskrevet i dokumentationsoversigten for NXRG.

1.3. 1.3. Læsevejledning

Læser forventes at have kendskab til Java softwareudvikling med anvendelse af Maven og WildFly. Derudover forventes kendskab til Docker samt docker-compose.

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

1.4. 1.4. Dokument Historik

1.5. 1.5. Introduktion til NXRG

Alle NXRG services udstiller en SOAP service. Snitfladen er defineret i en WSDL fil og en række XSD filer. 

Alle NXRG services er Java baserede komponenter, der baserer sig på Java 8 og Spring frameworket.

Design og arkitektur er beskrevet: NXRG - Design- og arkitekturbeskrivelse.

2. 2. Opsætning af udviklingsmiljø

I det følgende antages at koden er hentet fra SVN: https://svn.nspop.dk/svn/components/nxrg.

2.1. 2.1. Krav til software

NXRG deployeres vha. docker, hvorfor de alle baserer sig på NSP platformens base image, hvori der findes nødvendigt software til afvikling.

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

• Maven 3.0.3 eller højere anvendes.
• docker-compose version 3.4 eller højere

2.2. 2.2. Bygge WAR filer

Man skal bruge Maven til at bygge NXRG, hvilket gøres ved at køre kommandoen

Efter byg kan WAR filer findes her:

3. 3. Afvikling

Der henvises til installationsvejledningen for nærmere instrukser.

3.1. 3.1. Udviklers workstation

Når man udvikler kan det være praktisk at foretage lokal deployment.

Dette kan gøres vha. docker-compose:

Når NXRG er startet er, svarer den på:

• HelbredsURL: Se NXRG - Driftsvejledning
• Services: Se NXRG - Guide til anvendere

3.2. 3.2. Beskrivelse af systemdesign

Systemdesign er beskrevet i NXRG - Design- og arkitekturbeskrivelse.

4. 4. Beskrivelse af kildekodens strukturering og design

4.1. 4.1. Kode strukturering

Kildekoden bygges vha Maven, og kildekoden er struktureret som Maven moduler. NXRG består af følgende moduler:

4.2. 4.2. Databaseændringer

Databasemodellen styres ved hjælp af Liquibase. Det betyder at når der skal laves ændringer til databasemodellen, så må man ikke rette i de eksisterende skemafiler. I stedet skal der laves nye filer der beskriver ændringerne.

4.2.1. Skemaændringer

Skal der tilføjes f.eks. en ny kolonne eller en ny tabel skal nedenstående gøres.

1. Der oprettes en ny fil i folderen compose/configuration/database/ddl. Filen skal navngives liquibase-changelog-x.y.z.xml hvor x, y og z er det versionsnummer du forventer at release komponenten som. Filen skal beskrive ændringen der skal laves. Hvis man anvender liquibase SQL syntaxen får man typisk automatisk "rollback" med. Man kan også referere til rå SQL filer.
2. Filen fra punkt 1 tilføjes compose/database/liquibase-changelog-master.xml.
3. Done

4.2.2. Testdata

Opstår der en situation hvor der skal tilføjes yderlige testdata for at integrationstesten kan afvikles skal nedenstående udføres.

1. Der oprettes en ny fil i folderen compose/configuration/database/test. Filen skal navngives liquibase-changelog-test-x.y.z.xml hvor x, y og z er det versionsnummer du forventer at release komponenten som. Filen skal beskrive ændringen der skal laves. Hvis man avender liquibase SQL syntaxen får man typisk automatisk "rollback" med. Man kan også referere til rå SQL filer.
2. Filen fra punk 1 tilføjes compose/database/liquibase-changelog-test.xml
3. Done

4.2.3. Migrerede data

I development-setuppet bliver der ved opstart indlæst et dump af opentext-registry'et fra test1. Dette indlæses i en database for sig selv. Man kan tilgå denne database med følgende kommando (i mariadb-containeren):

mysql -uopentext -popentext opentext

4.3. 4.3. Migrering

Beskrivelse af hvordan man afvikler migreringen fra det gamle Opentext-registry til NXRG findes i Design- og Arkitekturbeskrivelsen og driftvejledningen.

4.4. 4.4. Beskrivelse af testsetup

4.5. 4.5. Unittests (JUnit)

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

Unit tests afvikling under byg vha jacoco plugin for Maven, men kan separat afvikles ved at køre:

Hvis der derimod laves en verify, så vil der også blive genereret code coverage, hvor fremkommende rapport kan ses i testreport/target/site/jacoco-aggregate/index.html

4.6. 4.6. Integrationstests

Integrationstests ligger i modulet nxrg-qa og kan afvikles med:

Dette forudsætter at alle services er startet som angivet i docker-compose setuppet.

Hvis man ønsker af afvikle testen op mod en andet miljø f.eks. test1 eller test2 henvises til NXRG - Testvejledning.

4.7. 4.7. Performance test

Performance testen foregår vha. et test framework udviklet af Arosii.

Performance testen består af 2 dele:

1. Udvikling af selve testen. Dette foregår i JMeter og kræver både java udvikling og efterfølgende opsætning i JMeter.
2. Udførsel af testen. Dette foregår vha. en række shell scripts på en master og flere slave maskiner. 

Udvikling og opsæt er beskrevet i nærværende dokument, mens den faktiske udførsel af testen er beskrevet i NXRG Testvejledning.

Performance testen skal passe til NXRGs  snitflader. Ændres disse er det også nødvendigt at ændre performance testen.

I det følgende antages at koden er hentet ned fra SVN: https://svn.nspop.dk/svn/components/performance/trunk/  samt at man har docker installeret i sit udviklingsmiljø. JMeter skal også være tilgængelig.

4.7.1. Kildekodens struktur

Kildekoden indeholder også performance test til andre services, men i nedestående er NXRG vigtigste dele trukket frem.

modules: indeholder kildekoden til de forskellige test

• GUI klasserne anvendes til indtastning  af test parametre
• Sampler klasserne anvendes til at lave det faktiske service kald
• persons_nxrg indeholder de cpr numre, der skal køres test med
• Message indeholder labels til skærmbillederne

tests: indeholder de generede test filer

• distributioner
• planer

4.7.2. Versionskontrol

Test versionen styres vha. af revision i trunk. I dokumentet "testvejledning" afsnit performance test angives, hvilken version af performance testen der anvendes med en given version af NXRG.

4.7.3. Udvikling af test

NXRGs  performance test består af ovennævnte java sourcer. Disse vedligeholdes i takt med at NXRG snitflader ændres/udvides og skal performance testes.

Lokal test kan gøres ved at bygge projektet og starte JMeter op.

4.7.4. Generering af testfiler

Når man har udviklet og bygget test projektet, startes JMeter. Herefter kan en eksisterende performance test åbnes og køres herfra. Eller en ny kan laves. 

Det følgende skærmbillede viser den skærm, som er udviklet i ITI61SamplerGUI med data hentet fra en gemt test:

Når man starter testen (den grønne pil) aktiveres et kald mod den service, der er konfigureret under 'Host configuration' og hermed aktiveres koden fra ITI61Sampler.

Resultatet kan ses under 'View Result Tree',  hvor både kald og svar kan ses. 

Den endelige kørsel af performance testen skal bruge en test plan (skabes når ovenstående test gemmes) samt en distribution, der indeholder 'Distribution' delen af ovenstående. De gemmes henholdsvis i tests/<modul>/src/test/jmeter/templates/testplans og tests/<modul>/src/test/jmeter/templates/distributions. Hvor <modul> kan være ihe eller aftaler.