Page History
Navitabs | ||||
---|---|---|---|---|
| ||||
Version 0.8, 2017-03-14
Anchor | ||||
---|---|---|---|---|
|
1 Formål
2 Introduktion til projektet
2.1 Specielle bemærkninger
1.1.1 Wildfly
1.1.2 Databasevedligehold
1.1.3 XSD-vedligehold
1.1.4 MySQL versionsproblematikker
3 Opsætning af udviklingsmiljø
3.1 Bygge WAR filer
3.2 Opsætning af Eclipse
4 Deployment på Wildfly 8.2.0
5 Beskrivelse af systemdesign
6 Beskrivelse af kildekodens struktur
6.1 Generelt design af webservices
6.2 Generelt design af Replikeringsjobbet
6.3 Generelt design af Opfølgningsjobbet (Backoffice)
6.4 Generelt design af behandlingsrelationsbiblioteket
7 Beskrivelse af test-setup
7.1 Unittests (Junit)
7.2 Integrationstests
8 Release af BRS
9 Ændringslog
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Der skal udarbejdes dokumentation, som gør det muligt for andre end den oprindelige leverandør, at overtage videreudvikling af komponenten. Dokumentationen skal være rettet mod udviklere og IT-arkitekter, som ikke på forhånd har kendskab til komponenten, og som ikke har adgang til komponentens oprindelige udviklere.
Guiden kan f.eks. indeholde:
- Beskrivelse af opsætning og installation af udviklingsmiljø
- Beskrivelse af hvordan man bygger og tester komponenten, herunder krav til tredjepartskomponenter mv.
- Beskrivelse af systemdesign (evt. med henvisning til designdokument, hvis dette skønnes tilstrækkeligt)
- Beskrivelse af kildekodens strukturering.Hvilke grupperinger/biblioteker findes, hvad deres formål er og hvad de indeholder.
- Beskrivelse af test-setup, herunder krav til data, tilgængelige platforme og evt. eksterne komponenter/services.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
FMKi projektets formål er at skabe en infrastruktur til FMK (Det Fælles Medicinkort), der hjælper FMK med at leve op til de lovmæssige krav, bl.a. kravet om aktuel behandlingsrelation. Behandlingsrelationsprojektet har det primære formål, at stille en service til rådighed for FMK (og på sigt andre aftagere) så man nemt kan afgøre om der findes en aktuel behandlingsrelation mellem en behandler og en patient. Da datagrundlaget for behandlingsrelationer ofte er forsinket, stilles der samtidig en service til rådighed, der kan følge op på de cases hvor der ikke findes en relation på forespørgselstidspunktet, og så enten logge at relationen blev fundet på et senere tidspunkt (når kildedata var blevet opdateret), eller afgive en alarm/notifikation, så der kan laves en manuel opfølgning på behandleren.
Anchor | ||||
---|---|---|---|---|
|
brs-frontend (dNSP og cNSP)
- brs webservice – afgør evidens for en behandlingsrelation og kan sætte en relationen til opfølgning.
- notification webservice – til hent af "alarmer", dvs. behandlingsrelationer, der ikke blev fundet evidens for i løbet af opfølgningsperioden.
- Replication job – sender behandlingsrelationer til opfølgning på backend.
brs-backend (Backoffice)
- replication webservice – modtager behandlingsrelationer til opfølgning fra frontend
- followupjob – foretager løbende opfølgning på behandlingsrelationer, og opretter alarm-notifikation hvis det ikke var muligt at opnå den ønskede evidens.
- cleanupjob – løbende sletning af gamle alarmer
For at kunne afgøre evidens for en behandlingsrelation er BRS afhængigt af stamdata fra landspatientregistret, sygesikringen mv. Disse data importeres af selvstændige stamdata-importere, Kodebasen til import af data indgår derfor ikke i BRS.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
I produktion kører brs-frontend og brs-backend i to forskellige Wildfly-instanser, men dette er i praksis ikke nødvendigt i et udviklingssetup, hvor man kan deploye begge war-filer på samme Wildfly-instans. Det eneste det har indflydelse på er logning, hvor der i produktion findes individuelle logging-profiles i standalone.xml, som logger til hhv. brs-frontend.log og brs-backend.log. Se i øvrigt installationsvejledningen.
Hvis man bruger de property-filer der følger med i projektet, vil der i modsætning til test- og produktionsmiljøer blive anvendt property-baserede whitelisting af CVR-numre. Det skal man være opmærksom på hvis man ønsker at bruge CVR-numre der ikke er whitelistet i forvejen.
Anchor | ||||
---|---|---|---|---|
|
Hvis det bliver nødvendigt at ændre på tabeller i MySQL, skal man være opmærksom på at det kan kræve opdateringer flere steder i projektet. Der ligger en række scripts der kan bruges til at etablere et udviklermiljø forfra her:
Code Block |
---|
integration/src/test/resources/sql/ |
- men ovenstående scripts er konstrueret udfra "master"-scripts der ligger i:
Code Block |
---|
common/src/main/resources/sql/ |
Ovenstående mappe indeholder i øvrigt både MySQL- og HSQLDB-varianter. Dvs. hvis der kommer nye tabeller eller lignende til skal de vedligeholdes mere end ét sted.
Anchor | ||||
---|---|---|---|---|
|
Et andet sted der er "dobbelt vedligehold" er på XSD-definitioner. Disse findes både i common- og integration-projektet. Dette er dog med fuldt overlæg, da integration-projektet spiller rollen som klient til systemet, og hvis der fx bliver lavet en XSD-ændring i BRS, vil man kunne se om ændringen har betydning for integrationstesten. Hvis integration-projektet blot havde benyttet XSDerne fra common, så ville man ikke opdage denne type fejl.
FMK klient-log
Hvis man har adgang til FMKs Splunk-installation, kan man benytte følgende queries (mod test1) for at se FMKs afsendelse af registreringer og hentning af notifikationer:
Registreringer:
Code Block |
---|
index=fmktest host="test1" source="*fmk-auditlog-modul.log" dk.nsi.fmk.auditlog.service.behandlingsrelation.registration Processing |
Notifikationer:
Code Block |
---|
index=fmktest host="*test1.recept.netic.dk" source="/pack/fmk_auditlog_modul/fmk-auditlog-modul.log" dk.nsi.fmk.auditlog.service.behandlingsrelation.notification.job NOT Executing |
Anchor | ||||
---|---|---|---|---|
|
I skrivende stund (marts 2017) benyttes MySQL version 5.5 i staging og produktion. Det er derfor nødvendigt at gå udenom features der findes i senere versioner (5.6, MariaDB osv). Dette kan fx være brugernavne længere end 16 karakterer, visse typer nestede select statements i inserts osv. Hvis man er i tvivl om bagud-kompatibilitet, bør man teste mod en MySQL-version der modsvarer produktion.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Al kode findes i NSP's Subversion respository. Rodfolderen for hele projektet kan findes her:
{+}https://svn.nspop.dk/svn/trifork/brs/trunk/+
Efter at projektet er checket ud vil man typisk gøre følgende:
- bygge war filer med Maven og køre tests
- opsætte udviklingsmiljø i Eclipse eller IntelliJ til at arbejde på projektet.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Følgende software er nødvendigt for at bygge projektet
- En SVN klient (min. version 1.6.0)
- Java 8
- Maven (min. version 3.0.2)
Gennemfør følgende steps for at bygge WAR filer.
- Check projektet ud fra NSP operatørens SVN
Code Block svn co https://svn.nspop.dk/svn/trifork/brs/trunk/ BehandlingsRelation
- For opsætning af Maven, da byggeprocessen er tung, anbefales følgende indstillinger:
Code Block MAVEN_OPTS='-Xms128m -Xmx2048m -XX:MaxPermSize=1024m'
- For at bygge projektet, foretage unittests samt at bygge war-filer foretages kommandoen
Code Block mvn clean install
Hvis man har en lokalt kørende Wildfly kan man med fordel tage udgangspunkt i "deploy.sh" som ligger i roden af projektet. Den sørger for at kopiere property-filer, standalone.xml samt war-filer til Wildfly. Bemærk dog, at hvis der er sket ændringer i standalone.xml, skal Wildfly genstartes.
Opsætning af IntelliJ Idea
Man åbner blot pom.xml fra rodbiblioteket. Efter en mvn clean install bør dependencies være på plads. Dog er "integration"-projektet specielt (det er ikke et "module" som de øvrige underprojekter), så det skal åbnes selvstændigt.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Det antages at Eclipse er installeret med et SVN og et Maven plugin. Til SVN anbefales Subclipse ({+}http://subclipse.tigris.org/+). Der findes et maven plugin på Eclipses marketplace. Derefter kan følgende step-by-step guide bruges til at klargøre Eclipse som udviklingsmiljø.
- Start Eclipse, og vælg "Import -> SVN -> Checkout Projeckts from SVN"
- Peg på følgende repository
{+}https://svn.nspop.dk/svn/trifork/brs/trunk/+
- Vælg roden af SVN strukturen (burde ramme trunk) og checkout
- Vælg "Next"
- Vælg "Finish"
- Vælg wizard'en "Java Project" og tryk "Next"
- Giv projektet et passende navn og vælg "Finish". Vælg "Ok" i dialogen.
- Højreklik på projektet og vælg "Maven" -> "Enable Dependency Management"
- Vælg "Import -> Maven -> Existing Maven Projects"
- Sæt flueben I alle projekterne og vælg "Finish"
- Højreklik på projektet "common" og vælg "Maven -> Update Project Configuration"
Bemærk at bruges eclipse uden Maven dependency management (da det ikke er så tungt), kan man køre kommandoen:
Code Block |
---|
mvn eclipse:eclipse |
Fra roden af projektet og derved få genereret .classpath filer. Man skal huske at køre denne kommando hver gang man ændrer i en dependency.
Projektet er nu klart i Eclipse. Unit-tests kan foretages ved at højreklikke på de enkelte komponenter og vælge "Run as… -> Junit test".
Pr. standard kører alle tests med en hsqldb in-memory database. Dette kan ændres ved at loade flere properties, f.eks. ved at bruge flaget –Ddk.nsi.properties.mode=local-deploy der benytter filen brs.local-deploy.properties til konfiguration af datakilder. Denne indeholder et MySQL setup på localhost. Automatiseret konfiguration af MySQL kan ske ved kommandoen
Code Block |
---|
mvn –Pinit-mysql generate-sources |
Der antages en localhost MySQL hvor root-kodeordet er blankt.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Når man udvikler kan det være praktisk at deploye til en lokal Wildfly server, da det er denne applikationsserver som bruges i NSP produktionsmiljøet. Der henvises til Installationsvejledningen for nærmere instrukser. Det anbefales at benytte NSP-in-a-box (NIAB) da denne indeholder en server, der er konfigureret på samme måde som den findes hos operatøren.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Der henvises til dokumentet "Design og Arkitektur", som kan findes i samme mappe som dette dokument.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Projektet er opdelt i følgende moduler:
- common – modul der indeholder de dele af koden der er fælles for komponenterne, herunder kode generet på baggrund af wsdl- og xsd-filer, databasehåndtering samt valideringsbiblioteket.
- brs-frontend – indeholder webservice til behandlingsrelations, webservice til notifikationsopslag, samt replicationjob, der periodisk overfører opsamlingsforespørgsler til backend-delen af systemet.
- brs-backend – indeholder webservice til modtagelse af opfølgninger fra frontend til backend-delen af systemet, followupjob til opfølgning og oprettelse af notifikationer, samt samt cleanupjob til sletning af notifikationer der er for gamle.
- integration – setup til integrationtest og stresstest. Bemærk at projektet er selvstændigt, og ikke er defineret som modul i stil med common, frontend og backend.
- performance – indeholder JMeter/Chronos tests, herunder maven mål til genering af test-data. Bemærk at dette modul ikke er ajourført, og pt. kun tjener som inspiration til hvordan en fremtidig struktureret performancetest kan udføres.
- dataload-maven-plugin – maven modul der benyttes af performance-test til oprettelsen af test-data.
- production – Hjælpe-klasser til udførelse af kald til et deployet system for at undersøge om det er fungerende.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Både Behandlingsrelationsservicen og Notificationservice er implementeret ved brug af Den Gode Webservice (DGWS), hvor Seal.Java er brugt til at håndtere headers.
JAX-WS er brugt til kodegenerering ud fra wsdl-filer. JAXB er brugt til kodegenerering ud fra xsd-filer. Dette giver anledning til nogle redundante filer der slettes blandt de generede JAX-WS filer. Grunden til at både JAX-WS og JAXB benyttes er, at JAX-WS ikke generer alle de nødvendige filer samt at det ikke er muligt at specificere visse JAXB bindings og parametre.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Replikeringsjobbet afvikles periodisk på dNSP'er og cNSP. Schedule, i form af et cron expression, samt adresse på backendens replikeringswebservice konfigureres i common/src/main/resources/default.properties, og kan overskrives i brs-frontend.properties i configuration-mappen på Wildfly.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Opfølgningsjobbet afvikles periodisk på Backoffice. Schedule, i form af cron expression, konfigureres i common/src/main/resources/default.properties, og kan overskrives i brs-backend.properties i configuration-mappen på Wildfly.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Behandlingsrelationsbiblioteket er skrevet som en fælles kodebase der benytter reglerne i dokumentet "Behandlingsrelationsregler" der forefindes i dokumentationen.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Herunder beskrives diverse muligheder for test af Behandlingsrelationsservicen.
Anchor | ||||
---|---|---|---|---|
|
Der er i projektet etableret unittests, som afvikles i forbindelse med Maven-byg af projektet og der er opnået høj code coverage. En rapport over code coverage generes automatisk af maven-jacoco-plugin i forbindelse med byg af projektet.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
I mappen "integration" forefindes et modul til integrations- og stresstests. De pågældende tests kan afvikles med Maven.
Det pågælende tests kræver at der er etableret et kørende miljø. Såfremt der testes mod localhost, vil man derfor forinden skulle foretage følgende:
- Byg BRS
- Deploy de 2 war-filer samt konfiguration til Wildfly på localhost
- Etabler de nødvendige databaser og tabeller i MySQL på localhost
- Afvikl. tests.
Der kan også testes mod andre miljøer end localhost, men så vil man manuelt skulle lægge datagrundlaget ind i miljøet først.
Der henvises til filen README.txt, som beskriver hvordan testen afvikles i praksis, herunder hvordan testdata indlæses.
Anchor | ||||
---|---|---|---|---|
|
Forud for en release af BRS skal man ajourføre "Changelog" med de opdateringer der er sket siden forrige release. Henvisninger til aktuelle JIRAs skal inkluderes, og det skal være muligt at danne sig et overblik over releasens overordnede indhold.
BRS releases vha. maven-release-plugin, som sørger for at tagge trunk med nuværende version fra pom.xml, samt sætte versionsnummeret frem i pom.xml. Processen derefter er, at Arosii bygger projektet udfra pågældende tag og afvikler en smoketest på den aktuelle version deployet på et miljø der modsvarer produktion.
Først og fremmest skal projektet kunne bygges og opfylde unit tests. Dette gøres via:
Code Block |
---|
mvn clean install |
Derefter skal det deployes på Wildfly, hvilket er forudsætning for næste skridt: integrationstesten. Denne udføres således (under integrationtest):
Code Block |
---|
mvn test -Dcreate_testdata=true |
(under antagelse af, at man har et kørende miljø). Dette tester basalt hul igennem platformen samt en række positiv/negativ-scenarier i forhold til stamdata, og skal køre igennem uden fejl. Se i øvrigt integration/README.txt hvis der er behov for at parameterisere i forhold til ikke-standard navngivning osv.
Når integrationstesten kører glat igennem kan man verificere at der kan releases via:
Code Block |
---|
mvn release:prepare -DdryRun=true |
Under processen accepteres default-forslag til versionsnumre. Ovenstående genererer diverse filer, som kan opryddes via:
Code Block |
---|
mvn release:clean |
Efterfølgende tagges koden via:
Code Block |
---|
mvn release:prepare |
Dette gør at trunk tagges, samt at diverse pom.xml får opdateret deres versionsnumre, hvilket samtidigt committes til trunk. Det nye tag skal efterfølgende fremgå under:
{+}https://svn.nspop.dk/svn/trifork/brs/tags/+
Igen genereres der en række filer, som opryddes via:
Code Block |
---|
mvn release:clean |
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Kilden til dette dokument kan findes på:
{+}https://svn.nspop.dk/svn/trifork/brs/trunk/doc/+
Version | Dato | Ændring | Ansvarlig |
---|---|---|---|
0.1 | 2011-06-15 | Initielt Dokument | Trifork |
0.2 | 2011-07-27 | Rettelser i forbindelse med udvidelse af maven opsætning samt konvertering til generelle notifikationer. | Trifork |
0.3 | 2011-08-10 | Udvidelse af dokumentation med GOS | Trifork |
0.4 | 2011-10-05 | Udvidelse af dokumentation med CPRABBS | Trifork |
0.5 | 2013-10-21 | Rettet svn urls | Trifork |
0.6 | 2014-03-04 | Tilføjet MAVEN_OPTS oplysninger, til bygge delen | Trifork |
0.7 | 2017-03-08 | Tilrettet BRS2 | Trifork |
0.8 | 2017-03-14 | Rettet betegnelser på NSP-miljøer | Trifork |