Nærværende dokument er en guide til nye udviklere af stamdataservicen på BackOffice. Guiden gennemgår på overordnet plan de aktiviteter, der er nødvendige for at kunne videreudvikle stamdataservicen.
Efter nærværende introduktion vil dokumentet gennemgå de væsentligste dele af opsætningen af et lokalt udviklingsmiljø og afvikling af test/performancetest.
Dokumentet forudsætter, at læseren har grundig kendskab til Java udvikling, webservices og Maven. Kendskab til JBoss applikationsserver 7 vil yderligere hjælpe læseren, men er ikke en forudsætning.
I dokumentet benyttes følgende notationer:
Markering af scripts og kommandoer.
Markering af advarsler
Markering af referencer til filer.
Den primære målgruppe for dokumentet er systemudviklere.
Stamdata importerne består af en kerne komponent (sdm4-core), og en række importer specifikke komponenter – alle deployes på BackOffice og har udelukkende til formål at populere data i en database (kan godt være forskellige databaser for hver komponent), se [DESIGN] for yderligere information vedrørende BackOffice.
Komponenter på BackOffice:
BackOffice applikationerne er en række selvstændigt kørende applikationer, til overvågning af indkomne data filer, der kan være i forskellige formater (XML, fastlængde, csv, m.v). Indkomne filer indlæses, valideres og gemmes herefter i DoDi’ens database.
Hvert komponent indeholder en implementation af et Parser interface der fungerer som entry-point til applikationen. Det anbefales, at man som ny udvikler på projektet kigger koden igennem med denne fil som udgangspunkt.
Stamdata importerne styres af java properties filer. Hver stamdata importer har en default konfigurations fil (default-config.properties) som er deployet sammen med war filen, denne kan overstyres med en properties fil lagt i jboss uden for war filen (config.properties) – se installations guiden for detaljer
Opsætningen af udviklingsmiljøet for stamdataservicen forudsætter, at følgende elementer allerede er installeret på udviklerens maskine:
Kildekoden er placeret i to forskellige github-repositories:
Kildekoden er placeret her:
Core modul: https://svn.nspop.dk/svn/trifork/sdm4-core/trunk/
Maven-plugin: https://github.com/trifork/sdm4-vagrant-maven-plugin/
Test-utils: https://svn.nspop.dk/svn/trifork/sdm4-testutils/trunk/
Parent-modul inkl. Test-environment: https://svn.nspop.dk/svn/trifork/sdm4-parent/trunk/
Importer moduler
https://svn.nspop.dk/svn/trifork/sdm4-autorisationimporter/trunk/
https://svn.nspop.dk/svn/trifork/sdm4-bemyndigelseimporter/trunk/
https://svn.nspop.dk/svn/trifork/sdm4-cprimporter/trunk/
https://svn.nspop.dk/svn/trifork/sdm4-doseringimporter/trunk/
https://svn.nspop.dk/svn/trifork/sdm4-lprimporter/trunk/
https://svn.nspop.dk/svn/trifork/sdm4-refhostimporter/trunk/
https://svn.nspop.dk/svn/trifork/sdm4-sikredeimporter/trunk/
https://svn.nspop.dk/svn/trifork/sdm4-sksimporter/trunk/
https://svn.nspop.dk/svn/trifork/sdm4-sorimporter/trunk/
https://svn.nspop.dk/svn/trifork/sdm4-sorrelationimporter/trunk/
https://svn.nspop.dk/svn/trifork/sdm4-takstimporter/trunk/
https://svn.nspop.dk/svn/trifork/sdm4-testdataimporter/trunk/
https://svn.nspop.dk/svn/trifork/sdm4-tilskudsblanketimporter/trunk/
https://svn.nspop.dk/svn/trifork/sdm4-vaccinationimporter/trunk/
https://svn.nspop.dk/svn/trifork/sdm4-vitaminimporter/trunk/
https://svn.nspop.dk/svn/trifork/sdm4-ydelseimporter/trunk/
https://svn.nspop.dk/svn/trifork/sdm4-yderimporter/trunk/
Koden checkes ud på følgende måde:
% svn co <kode-url> <sdm4-navn>
Stamdataprojektet anvender Maven som byggesystem [MAVEN]. Strukturen følger de generelle anbefalinger for Maven projekter, og er struktureret med en parent pom.xml og en projekt pom.xml fil for hvert underprojekt.
Subprojekterne er opbygget efter Maven layout konventionen.
For at bygge en importer, skal man gøre følgende:
Check Core-modul ud og kør mvn install
Check Maven-plugin ud og kør mvn install
CheckTest-utils ud og kør mvn install
Check parent-modul ud og kør mvn install
Herefter er du klar til at bygge et importer-modul.
Importmodulets integrationstest er afhængig af at ligge som et subdirectory til parent-modulet, så du skal checke det ud som sådan et.
Hvis du ønsker at checke alle importermoduler ud, ligger der i roden af parent-modulet et script, checkout-importermodules.sh, som udfører checkout af alle importermoduler samt maven-plugin og test-utils.
For at kunne hente NSI-specifikke dependencies (SEAL, nsp-util) osv. i binær form i stedet for at skulle bygge dem allesammen lokalt, indeholder pom’erne for alle importmoduler en reference til nexus.trifork.com, som er et artefaktrepository der er placeret hos Trifork. Binære releases af alle moduler inkl. core, maven-plugin, test-utils og parent findes også i nexus.trifork.com.
Repository’et bør snarest muligt udskiftes med et repository der er driftet hos NSI. Når et sådant er etableret, vil alle SDM4-moduler skifte til at bruge dette.
BackOffice-projekterne anvender Vagrant+Ansible til at opsætte udviklingsmiljøet.
For at få bootet og opsat en udviklingsmaskine, køres følgende
% vagrant up
Fra roden af et importermodul eller fra parent-modulet.
Når vagrant har bygget den virtuelle maskine, er den sat op med den korrekte version af Wildfly samt en MariaDB der er konfigureret til at have en root-bruger med password papkasse og en sdm4-bruger med password sdm4.
Der er også automatisk oprettet en tom database med standard-navnet for databasen, (sdm_warehouse) og en datasource i JBoss med det JNDI-navn, som applikationen som default forventer at kunne slå datasource op.
Applikationen kører ved opstart automatisk databaseskema på databasen.
Der er forwardet følgende porte ind i den virtuelle maskine, så man kan tilgå Wildfly og MariaDB fra sin lokale maskine
8080 -> 8080 (dvs. at man kan tilgå http://localhost:8080/)
3307 -> 3306 (dvs. at man kan have en urelateret mysql kørende lokalt og tilgå SDM-mysql’en på den virtuelle maskine på url localhost:3307)
Installationen kan verificeres ved at eksekvere stamdataservicens test suite.
Stamdataservicen benytter JUnit og Mockito til test.
Testkoden er for hvert modul lokaliseret i:
src/test/java
Test suiten afvikles ved at udføre følgende kommando i projektroden:
% mvn test
Kommandoen kan også udføres under de individuelle moduler, hvorved kun undermodulets test udføres.
Installationen kan yderligere verificeres ved at udføre kommandoen:
% mvn verify
Denne kommando validerer code coverage og kode konventionerne for projektet.
Kode konventionerne følger reglerne defineret i filen:
config/checkstyle.xml
Stamdataservicen kan principielt udvikles i enhver Java IDE, der forstår Maven projekters opbygning.
I dette dokument beskrives kort opsætning for to af de pt. mest udbredte Java IDE’er: Eclipse og IntelliJ.
Eclipse er ikke født med Maven support, og det anbefales derfor, at man installerer m2eclipse inden stamdataservicen hentes ind i Eclipse:
Herefter importeres projekterne i Eclipse via ”import”:
Alternativt kan man importere projektet ved at udføre følgende kommando:
% mvn eclipse:eclipse
Og herefter importere projektet på normal vis i Eclipse.
Kommandoen genererer Eclipse projektfilerne (.project og .classpath) for roden og hvert undermodul. Denne metode kræver dog, at kommandoen udføres hver gang man ændrer i pom filerne.
IntelliJ Idea er født med Maven support, og stamdataservicen kan derfor direkte importeres. Projektet importeres i IntelliJ ved under ”Create new project” at vælge ”Import project from external model”. Herefter udvælges roden af stamdataservicen, hvorefter projektet importeres.
Det anbefales i den sammenhæng, at man krydser af i ”Import Maven projects automatically”, hvorefter IntelliJ selv detekterer nye moduler i projektet.
Alternativt kan man importere projektet ved at udføre følgende kommando:
% mvn idea:idea
Herefter kan projektet importeres på normal vis i IntelliJ.
Obs! Denne metode kræver dog, at kommandoen udføres hver gang man ændrer i pom filerne.
Stamdataservicen kan bygges til distribution eller lokal test ved at udføre:
% mvn package
I de følgende beskrives problemer og deres løsninger:
I JBoss’s boot.log:
$JBOSS_HOME/server/default/log/boot.log
Logger JBoss noget i stil med ”out of memory” og nævner “permgenspace”
Forøg JBoss permgen space ved at ændre linien indeholdende:
JAVA_OPTS="-Xms2048m -Xmx2048m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000"
i filen
$JBOSS_HOME/bin/run.conf
til
JAVA_OPTS="-Xms2048m -Xmx2048m -XX:MaxPermSize=512m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000"
Nyeste udgave af dette dokument kan erhverves ved henvendelse til NSP-operatøren.
Version | Dato | Ændring | Ansvarlig |
1.0 | 28/4-2011 | Initielt Dokument | Trifork |
1.1 | 6/10-2011 | Opdateret med CPR tjenester | Trifork |
1.2 | 8/12-2011 | Kvalitetssikret af Lakeside | Lakeside |
1.3 | 22/12-2011 | Opdateret bla. med performance test af autorisationsservicen og kopi-register-servicen | Trifork |
1.4 | 20/8-2012 | Tilføjet DoDi-specifikke afsnit der beskriver SDM4 | Trifork |
1.5 | 24/8 2012 | Fjernet al dokumentation der ikke var SDM4 importer specifik | Trifork |
1.6 | 9/1-2014 | Opdateret source links | Trifork KPN |
1.7 | 11/10-2017 | Ajourført (udstilling kun på NSPOP) | NSP Operatør |