Anchor
__RefHeading___Toc13002_485590894 __RefHeading___Toc13002_485590894

Anchor
_Toc40578283 _Toc40578283

Anchor
_Toc477259155 _Toc477259155

Formål

Formålet med dette dokument er at beskrive hvordan et udviklingsmiljø, til videreudvikling af BRS services, kan sættes op, samt hvordan koden bygges, deployes og testes.

Først gives

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.

 
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
__RefHeading___Toc13004_485590894 __RefHeading___Toc13004_485590894

Anchor
_Toc477259156 _Toc477259156

Introduktion til BRS Services

Behandlingsrelationsprojektet (BRS) har det primære formål, at stille en service til rådighed anvendere, således at det kan afgøres, om der findes en aktuel behandlingsrelation mellem en behandler og en patient på et givent tidspunkt (evt ved bestilling af opfølgninger). I Behandlingsrelationsservice (BRS) - Leverancebeskrivelse gives en grundig beskrivelse af de forretningsmæssige aspekter f BRS.

• 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 eksterne evidenskilder. Disse data importeres af selvstændige stamdata-importere. Kodebasen til import af data indgår derfor ikke i BRS.

Anchor
__RefHeading___Toc13006_485590894 __RefHeading___Toc13006_485590894

Specielle bemærkninger.

Anchor
__RefHeading___Toc13010_485590894 __RefHeading___Toc13010_485590894

Databasevedligehold

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:

integration/src/test/resources/sql/ 

- men ovenstående scripts er konstrueret udfra "master"-scripts der ligger i:

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
__RefHeading___Toc14788_485590894 __RefHeading___Toc14788_485590894

XSD-vedligehold

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:

index=fmktest host="test1" source="*fmk-auditlog-modul.log" dk.nsi.fmk.auditlog.service.behandlingsrelation.registration Processing 

Notifikationer:

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
__RefHeading___Toc13014_485590894 __RefHeading___Toc13014_485590894

Anchor
_Toc477259157 _Toc477259157

Opsætning af udviklingsmiljø

Al kode findes i NSP's Subversion respository. Rodfolderen for hele projektet kan findes her:

https://svn.nspop.dk/svn/components/brs

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
__RefHeading___Toc13016_485590894 __RefHeading___Toc13016_485590894

Anchor
_Toc477259158 _Toc477259158

Bygge WAR filer

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.

1. Check projektet ud fra NSP operatørens SVN
   
   

   Code Block
   svn co https://svn.nspop.dk/svn/components/brs/trunk BehandlingsRelation

2.  For opsætning af Maven, da byggeprocessen er tung, anbefales følgende indstillinger:
   

   Code Block
   MAVEN_OPTS='-Xms128m -Xmx2048m -XX:MaxPermSize=1024m'

3. For at bygge projektet, foretage unittests samt at bygge war-filer foretages kommandoen
   
   

   Code Block
   mvn clean install

Herefter kan en lokal udgave kan startes med docker

Anchor
__RefHeading___Toc13022_485590894 __RefHeading___Toc13022_485590894

Anchor
_Toc477259161 _Toc477259161

Beskrivelse af systemdesign

Der henvises til dokumentet "Design og Arkitektur", som kan findes i samme mappe som dette dokument.

Anchor
__RefHeading___Toc13024_485590894 __RefHeading___Toc13024_485590894

Anchor
_Toc477259162 _Toc477259162

Beskrivelse af kildekodens struktur

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.
• testreport - Modul der har til formål at samle jacoco testrapporter fra de enkelte moduler i en samlet rapport (inkl total beregning af testcoverage)

Anchor
__RefHeading___Toc13026_485590894 __RefHeading___Toc13026_485590894

Anchor
_Toc477259163 _Toc477259163

Generelt design af webservices

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
__RefHeading___Toc13028_485590894 __RefHeading___Toc13028_485590894

Anchor
_Toc477259164 _Toc477259164

Generelt design af Replikeringsjobbet

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.

Anchor
__RefHeading___Toc13030_485590894 __RefHeading___Toc13030_485590894

Anchor
_Toc477259165 _Toc477259165

Generelt design af Opfølgningsjobbet (Backoffice)

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.

Anchor
__RefHeading___Toc13032_485590894 __RefHeading___Toc13032_485590894

Anchor
_Toc477259166 _Toc477259166

Generelt design af behandlingsrelationsbiblioteket

Behandlingsrelationsbiblioteket er skrevet som en fælles kodebase der benytter reglerne i dokumentet "Behandlingsrelationsregler" der forefindes i dokumentationen.

Anchor
__RefHeading___Toc13034_485590894 __RefHeading___Toc13034_485590894

Anchor
_Toc477259167 _Toc477259167

Beskrivelse af test-setup

Herunder beskrives diverse muligheder for test af Behandlingsrelationsservicen.

Anchor
__RefHeading___Toc13036_485590894 __RefHeading___Toc13036_485590894

Unittests (Junit)

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 samlet rapport over code coverage generes automatisk af maven-jacoco-plugin i forbindelse med byg af projektet (findes i target folderen i testreport modulet efter byg).

Anchor
_Toc477259168 _Toc477259168

Anchor
__RefHeading___Toc13038_485590894 __RefHeading___Toc13038_485590894

Integrationstests

I mappen "integration" forefindes et modul til integrations- og stresstests. De pågældende tests kan afvikles med Maven. De pågældende tests kræver at der er etableret et kørende miljø. Et sådant miljø kan etableres lokalt ved at bygge BRS og starte docker-compose development-setuppet, som beskrevet tidligere i denne guide.

Når dette er gjort, afvikles integrationstests som følger:

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
__RefHeading___Toc13042_485590894 __RefHeading___Toc13042_485590894

Release af BRS

Forud for en release af BRS skal man ajourføre Behandlingsrelationsservice (BRS) - Leverancebeskrivelse 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:

mvn clean install

Derefter skal udviklingssetuppet startes (beskrevet tidligere i dette dokument), hvilket er forudsætning for næste skridt: integrationstesten. Denne udføres således (under integrationtest):

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:

mvn release:prepare -DdryRun=true

Under processen accepteres default-forslag til versionsnumre. Ovenstående genererer diverse filer, som kan opryddes via:

mvn release:clean

Efterfølgende tagges koden via:

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/components/brs/tags

Igen genereres der en række filer, som opryddes via:

mvn release:clean

Anchor
__RefHeading___Toc13044_485590894 __RefHeading___Toc13044_485590894

Anchor
_Toc263424147 _Toc263424147

Anchor
_Toc477259170 _Toc477259170

Ændringslog