Page History
| Navitabs | ||||
|---|---|---|---|---|
| ||||
| Table of Contents | ||
|---|---|---|
|
Se referencearkitekturens guide for stamdataindlæsere her for generelle fælles retningslinjer for udvikling af stamdataindlæsere.
...
Efter byg kan WAR filer findes her:
|
Afvikling
...
Dette kan gøres vha. docker-compose:
|
Når Sikrede er startet er, svarer den på:
- HelbredsURL: Se Driftvejledning
Beskrivelse af systemdesign
...
Kildekoden bygges vha Maven, og kildekoden er struktureret som Maven moduler. Sikrede består af følgende moduler:
| sikrede-common | Fælles indlæser service- og forretningsfunktionalitet er samlet her |
| sikrede-event | Her specificeres avsc filen. Og generes source kode herfra. |
| sikrede-integrationstest | Sikrede har ingen automatiske integrationstest |
| sikrede-service | Sikrede indlæser service- og forretningsfunktionalitet er samlet her |
| sikrede-testreport | Modul til at samle jacoco test reports og beregne samlet test coverage. |
| sikrede-war | Modul, der er ansvarlig for at pakke Sikrede som en NSP service - herunder angivelse af modulafhængigheder i deploymentdescriptor. Indeholder også Dockerfile til selve byg af Docker image. |
Databaseændringer
Databasemodellen styres ved hjælp af Liquibase. Det betyder at når der skal laves ændringer til databasemodellen, så må man ikke rette i de eksisterende skemafiler. I stedet skal der laves nye filer der beskriver ændringerne.
Skemaændringer
Skal der tilføjes f.eks. en ny kolonne eller en ny tabel skal nedenstående gøres.
- Der oprettes en ny fil i folderen compose/configuration/database/ddl. Filen skal navngives liquibase-changelog-x.y.z.xml hvor x, y og z er det versionsnummer du forventer at release komponenten som. Filen skal beskrive ændringen der skal laves. Hvis man anvender liquibase SQL syntaxen får man typisk automatisk "rollback" med. Man kan også referere til rå SQL filer.
- Filen fra punkt 1 tilføjes compose/database/liquibase-changelog-master.xml.
- Done
Validering
(TBD: hører dette afsnit til anvender guide istedet?)
Data validering
På hver række af data foretages der følgende valideringer.
...
| View file | ||||
|---|---|---|---|---|
|
Filsæt validering
På et modtaget filsæt gennemføres der et antal valideringer før data parses og splittes til events for levering til modtagere af data.
De valideringer, der er implementeret, er:
Validering af encoding
Indholdet af filen for sikrede indlæseren forventes at være encodet i UTF-8.
Der foretages en validering af encoding ved at udføre en dekodning af fil-indholdet med UTF-8.
Hvis valideringen fejler stoppes filen og den givne fejl logges.
Validering af struktur
Indholdet af filen for Sikrede indlæseren forventes at være i en given fast struktur (flad fil).
Der foretages en validering af strukturen. Denne validering tjekker ikke for data indholdet, men sikrer udelukkende at strukturen af filen er som forventet.
Valideringen af strukturen fejler hvis
- Den første linie ikke er start (header) format
- Hvis start format ikke overholder:
- korrekt linie længde
- PostType er 00
- OpgDato korrekt dato format
- Timestamp korrekt format
- Hvis sikrede data format ikke overholder
- korrekt linie længde
- PostType er 10
- Der mangler et slut (footer) format
- Hvis slut format ikke overholder
- korrekt linie længde
- PostType er 99
- AntPost skal være numerisk og matche det antal data linier, der er i filen
- Der er data efter slut formatet
Hvis valideringen fejler stoppes filen og den givne fejl logges.
Validering af filnavn
TBD
Beskrivelse af testsetup
Unittests (JUnit)
...
Unit tests afvikling under byg vha jacoco plugin for Maven, men kan separat afvikles ved at køre:
|
Hvis der derimod laves en verify, så vil der også blive genereret code coverage, hvor fremkommende rapport kan ses i sikrede-testreport/target/site/jacoco-aggregate/index.html
...