Page History
| Navitabs | ||||
|---|---|---|---|---|
| ||||
Version 0.8, 2017-03-14
| Anchor | ||||
|---|---|---|---|---|
|
1 Formål1Formål3
2Introduktion 2 Introduktion til projektet4projektet
2.1Specielle bemærkninger41 Specielle bemærkninger
1.1.1Wildfly41 Wildfly
1.1.2Databasevedligehold52 Databasevedligehold
1.1.3XSD3 XSD-vedligehold5vedligehold
1.1.4MySQL versionsproblematikker5
3Opsætning af udviklingsmiljø64 MySQL versionsproblematikker
3 Opsætning af udviklingsmiljø
3.1Bygge 1 Bygge WAR filer6filer
3.2Opsætning 2 Opsætning af Eclipse6Eclipse
4Deployment 4 Deployment på Wildfly 8.2.080
5Beskrivelse 5 Beskrivelse af systemdesign9systemdesign
6Beskrivelse 6 Beskrivelse af kildekodens struktur10struktur
6.1Generelt 1 Generelt design af webservices10webservices
6.2Generelt 2 Generelt design af Replikeringsjobbet10Replikeringsjobbet
6.3Generelt 3 Generelt design af Opfølgningsjobbet (Backoffice)10
6.4Generelt 4 Generelt design af behandlingsrelationsbiblioteket11behandlingsrelationsbiblioteket
7Beskrivelse 7 Beskrivelse af test-setup12setup
7.1Unittests 1 Unittests (Junit)12
7.2Integrationstests122 Integrationstests
8Release 8 Release af BRS13BRS
9Ændringslog14 9 Ændringslog
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
...
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 | ||||
|---|---|---|---|---|
|
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:
...
- Check projektet ud fra NSP operatørens SVN
svn co https://svn.nspop.dk/svn/trifork/brs/trunk/ BehandlingsRelation - For For opsætning af Maven, da byggeprocessen er tung, anbefales følgende indstillinger:
MAVEN_OPTS='-Xms128m -Xmx2048m -XX:MaxPermSize=1024m' - For at bygge projektet, foretage unittests samt at bygge war-filer foretages kommandoen
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.
...
Bemærk at bruges eclipse uden Maven dependency management (da det ikke er så tungt), kan man køre kommandoen:
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
mvn –Pinit-mysql generate-sources
Der antages en localhost MySQL hvor root-kodeordet er blankt.
...
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:
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):
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/trifork/brs/tags/+
Igen genereres der en række filer, som opryddes via:
mvn release:clean
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
...