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.
Læser forventes at have kendskab til Java softwareudvikling med anvendelse af Maven og WildFly.
Dato | Ansvarlig | Beskrivelse |
|---|---|---|
| 26/2-2018 | KvalitetsIT | Initiel version |
Reference | Beskrivelse |
NSP | Den nationale service platform (inden for sundheds-IT) |
| FHIR | Fast Health Interoperability Resources |
| DGWS | Den Gode Web Service |
LAR servicen udstiller en SOAP service med to SOAP actions. En action til at læse data og en action til at hente 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
I det følgende antages at koden er hentet ned fra SVN: https://svn.nspop.dk/svn/kvalitetsit/lar/ og MSB-util fra https://svn.nspop.dk/svn/kvalitetsit/msbutil/.
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.
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
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
Der henvises til installationsvejledningen LAR Driftsvejledning for nærmere instrukser.
Når man udvikler kan det være praktisk at foretage deploy til en lokal Wildfly.
Systemdesign er beskrevet i LAR Design og Arkitekturbeskrivelse
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).
Logning i applikationsloggen gøres efter følgende regler:
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
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, da integrationstestene afvikles imod kørende service(s).
Se næste afsnit
Performance testen foregår vha. et test framework udviklet af Arosii.
Performance testen består af 2 dele:
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/kvalitetsit/cave-performance/ samt at man har docker installeret i sit udviklingsmiljø. Lokal JMeter installation er ikke nødvendig.
Hvis ikke nedenstående fremgangsmåder fungerer umiddelbart, kan der hentes hjælp i filen README, der ligger i roden i projektet. Denne indeholder information om software og OS platform.
Kilde koden er udleveret af Arosii og eftefølgende tilrettet til LAR service projektet. Kildekoden indeholder også performance test til andre services. Om disse er opdateret til kørende version af disse services er ikke sikkert, men kan tjene til inspiration til fremtidig udvikling af performance test.
.
|
doc: indeholder Arosiis vejledning til brug af frameworket
environment:
jmeter-docker: indeholder det, som muliggør at køre JMeter i en docker container
kit-vagrant:
modules: indeholder kildekoden til de forskellige test, herunder LAR servicen
tests: indeholder de generede test filer og eventuelle hjælpe filer. For LAR servicens vedkommende indeholder folderen udover test filer et database dump med 50.000 allergier og den tilhørenede liste af cpr numre.
Ændringer til cave-performance skal tagges i SVN med samme release, som den lar version rettelsen gælder.
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.
Ved ændringer hvor der typisk sættes nye felter på i ListAllergyRequestSamplerGui og disse anvendes herefter i ListAllergyRequestSampler. Derefter bygges med
mvn -Pdockerbuild clean install.
Ved at anvende profilen "dockerbuild" bliver der samtidig oprettet et docker image, som anvendes, når man starter JMeter op (se næste afsnit)
Når man har bygget test projektet, som angivet i forrige afsnit, startes JMeter op med
docker run -it --net=host -e DISPLAY=$DISPLAY -v ${PWD}/tests/:/tests/ -v /tmp/.X11-unix:/tmp/.X11-unix -v ~/.Xauthority:/root/.Xauthority:ro kvalitetsit/cave-performance
Herefter kan en eksisterende performance test åbnes og køres herfra. Eller en ny kan laves. Filerne kan gemmes lokalt udenfor docker containeren.
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/larservice/src/test/jmeter/templates/testplans og tests/larservice/src/test/jmeter/templates/distributions