1. Indhold

2. Introduktion

2.1. Formål

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

2.2. Læsevejledning

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

2.3. Dokument historik

2.4. Definitioner og referencer

2.5. Introduktion til LAR servicen

LAR servicen udstiller en SOAP service med tre SOAP actions. En action til at læse data, en til at oprette data og en til at opdatere data. Snitfladen er defineret i en WSDL fil og en række XSD filer. 

LAR  servicen er en Java baseret komponent, der baserer sig på Java 8 og Spring Boot frameworket. Den udstiller SOAP snitfladen ved hjælp af Apache CXF.

Design og arkitektur er beskrevet: LAR - Design- og Arkitekturbeskrivelse

3. Opsætning af udviklingsmiljø

I det følgende antages at koden er hentet ned fra SVN: https://svn.nspop.dk/svn/components/lar/ og MSB-util fra https://svn.nspop.dk/svn/kvalitetsit/msbutil/.

3.1. Krav til software

Krav til applikationsserveren og operativsystemet er de samme som til produktionsmiljøet. De specifikke krav kan ses i https://www.nspop.dk/display/public/web/Husregler+for+udvikling+til+NSP

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

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

3.2. Byg af MSB-util

LAR servicen anvender hjælpe pakken MSB-util. MSB-Util sørger for at kalde MinLog, BehandlerRelation og samtykke. MSB-Util bygges med nedenstående kommando. Resultatet er en jar fil i target folderen under hvert maven modul. 

$ mvn clean install

3.3. Bygge WAR filen

Man skal bruge Apache Maven til at bygge CAVE servicen, hvilket gøres ved at køre kommandoen
$ mvn clean install

Efter byg kan den installerbare WAR fil findes her:

/cave-war/target/cave.war

4. Deployment på Wildfly

Der henvises til installationsvejledningen LAR - Driftsvejledning for nærmere instrukser.

4.1. Udviklers workstation

Når man udvikler kan det være praktisk at foretage deploy til en lokal Wildfly. Dette kan gøres vha. docker-compose:

Efter start af docker-compose kan larservicen tilgåes på localhost port 8082. Servicens wsdl kan f.eks. tilgåes på http://localhost:8082/lar/MedicationAllergyService?wsdl

4.2. Beskrivelse af systemdesign

Systemdesign er beskrevet i LAR - Design- og Arkitekturbeskrivelse

5. Beskrivelse af kildekodens strukturering og design

5.1. Kode strukturering for MSB-Util

Kildekoden bygges vha Apache Maven, og kildekoden er struktureret som Maven moduler, som vist nedenfor:

brs-client modulter indeholder forretningslogikken til at kalde behandler relation servicen.

common modulet indeholder delt funktionalitet mellem de andre moduler. 

consent-client modulet indeholder forretningslogikken til at kalde samtykke servicen. 

minlog-reg-client modulet indeholder forretningslogikken til at kalde min log. 

msb-util-interface indeholder interface definitioner samt input og output definitioner til de forskellige services. Dette giver en afkopling mellem interface og implementering for dem der skal anvende MSB-util. 

5.2. Kode strukturering for LAR

Kildekoden bygges vha Apache Maven, og kildekoden er struktureret som Maven moduler, som vist nedenfor:

larservice-app modulet indeholder forretningslokken logikken. 

larservice-cave modulet indeholder funktionalitet til at kalde CAVE servicen og konvertering af data fra det FHIR format CAVE servicen returnerer og det LAR snitfladen definerer. 

larservice-dgws modulet indeholder funktionalitet til at validere DGWS headeren og opbygge en request context.

larservice-types modulet indeholder WSDL og XSD'er samt de genererede typer til snitfladen. 

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

5.3. Logningsstrategi

Logning i applikationsloggen gøres efter følgende regler:

• Fejl logges med værdier når relevant
  • Dette kan f.eks. være valideringsfejl
  • Det må ikke være personhenførbar information
• Der logges med følgende niveauer:
  • DEBUG: anvendes til at kunne følge en given logik. Mellemregninger.
  • INFO: anvendes til at informere om et givet resultat, f.eks. hvad værdien er, når der opstår en valideringsfejl
  • ERROR: anvendes i fejlsituationer, hvor driften skal adviseres, f.eks. når MinLog ikke svarer
  • TRACE: anvendes typisk i ind og udgange af metoder

6. Beskrivelse af testsetup

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

6.2. Integrationstests

Integrationstests kan afvikles ved at køre:

mvn test -Pintegration-test   -Dconsentadministration.endpoint=http://test1-cnsp.ekstern-test.nspop.dk:8080/consent-administration/service -Dlarservice.wsdl=http://localhost:8065/larservice/MedicationAllergyService?wsdl

(samme 2 parametre skal angives ved kørsel i IDE, f.eks. for Eclipse i VM arguments i en run configuration)

Bemærk at dette forudsætter, at LAR Service er deployeret på JBoss-serveren. Det forudsættes også at CAVE servicen er tilgængelig. Se flere detaljer i test vejledning under integrationstest.

6.3. Performance test

Se afsnit 7 Udvikling af performance test

7. Udvikling af 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 LAR Testvejledning.

Performance testen skal passe til LAR servicens snitflade. Ændres denne 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.

7.1. Kildekode struktur

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

modules: indeholder kildekoden til de forskellige test, herunder LAR servicen. Der findes også 2 lister over cpr numre. cpr.txt indeholder få, for hurtigt test af testen. cprSample indeholder den fulde liste af 50.000 cprnumre, der passer med performance test data.

tests: indeholder de generede test filer (planer og distributioner) .

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 LAR servicen.

7.3. Udvikling af test

LAR servicens performance test består af tre java sourcer, hvoraf der reelt er logik i to af dem, og som skal vedligeholdes ved LAR snitflade ændringer.

• ListAllergyRequestSamplerGui: indeholder skærmbillede logik til at kunne angive input parametrene til LAR servicen
• ListAllergyRequestSampler: indholder logik til at lave det faktisk web service kald med de angivne input værdier

7.4. Generering af test filer 

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 ListAllergyRequestSamplerGui 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 ListAllergyRequestSampler.

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/lar/src/test/jmeter/templates/testplans og tests/lar/src/test/jmeter/templates/distributions