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:

• Maven 3.0.3 eller højere anvendes.
• docker-compose version 3.4 eller højere

Bygge WAR filer

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

Efter byg kan WAR filer findes her:

Afvikling

Der henvises til installationsvejledningenfor 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:

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

• HelbredsURL: Se Driftvejledning

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:

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.

• Cpr numre har længden 10, er numerisk samt har gyldig dato og månded (validateAsCpr)
• Ydre numre har længden 6 og er numerisk (ved manglende foranstillede 0'er sættes de på) (validateAsYderAndPadZero)
• Datoer i forhold til specificeret format (validateAsDateYYYYMMDD og validateAsDateYYYY_MM_DD)
• Sikringkoder er er numeriske (validateAsNumber)
• SAlder er numerisk (validateAsNumber)
• Tekster har den korrekt længde, når angivet i spec (validateAsText)
• SKon er "M" eller "K" (validateAsText)
• SStatus er en af værdierne "B", "D", "E", "G", "L", "U", "V" eller blank (validateAsText)
• Alle felter er "mandatory" med undtagelse af 
  • Felterne SIkraftDatoYderGl, SRegDatoYderGl, SIkraftDatoGrpGl, ,SRegDatoGrpGl, SIkraftDatoYderFrem, SRegDatoYderFrem, SIkraftDatoGrpFrem, SRegDatoGrpFrem
  • Felterne i SaerligSundhedskort kan alle udelades (alle eller ingen)
  • Felterne i SocialSundhedsland kan alle udelades (alle eller ingen)

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

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)

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:

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.