Se referencearkitekturens guide for stamdataindlæsere her for generelle fælles retningslinjer for udvikling af stamdataindlæsere.

Herunder beskrives specifikke forhold for sikrede Indlæseren.

Opsætning af udviklingsmiljø

I det følgende antages at koden er hentet fra GIT: https://git.nspop.dk/scm/im/sikrede-indlaeser.git

2.1. Krav til software

Sikrede indlæser deployeres vha. docker, hvorfor de alle baserer sig på NSP platformens base image, hvori der findes nødvendigt software til afvikling.

Derudover er der krav til de anvendte udviklingsværktøjer:

Bygge WAR filer

Man skal bruge Maven til at bygge Sikrede, hvilket gøres ved at køre kommandoen

mvn package


Efter byg kan WAR filer findes her:

./dk.nsp.sdm.sikrede-war-war/target/sikr.war

Afvikling

Der henvises til installationsvejledningen for nærmere instrukser.

Udviklers workstation

Når man udvikler kan det være praktisk at foretage lokal deployment.

Dette kan gøres vha. docker-compose:

docker-compose -f compose/development/docker-compose.yml up --build

Når Sikrede er startet er, svarer den på:

Beskrivelse af systemdesign

Systemdesign er beskrevet i Design og arkitekturbeskrivelsen.

Beskrivelse af kildekodens strukturering og design

Kode strukturering

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-integrationstestSikrede 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.

  1. 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.
  2. Filen fra punkt 1 tilføjes compose/database/liquibase-changelog-master.xml.
  3. Done

Validering

(TBD: hører dette afsnit til anvender guide istedet?)

Data validering

På hver række af data foretages der følgende valideringer.

Hvis data for en række fejler valideringen bliver denne række, og evt. indlejrede rækker, ikke indlæst, men resten af data i filen indlæses.

De implementerede valideringer tager udgangspunkt i snitfladebeskrivelsen for de sikrede der leveres og som her beskrevet i dette dokument:

Beskrivelse af testsetup

Unittests (JUnit)

JUnit anvendes til implementering af unit tests. Der er kontinuert gennemført unit tests på alle komponenter i projektet.

Unit tests afvikling under byg vha jacoco plugin for Maven, men kan separat afvikles ved at køre:

mvn test

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

Integrationstests

Sikrede har ingen integrationstest, da Unit testen af ruten kører det fulde flow. Der er mulighed for manuelt at lave en test i docker compose setup'et, se testvejledningen herfor.