...

• 1. Indledning
  • 1.1. Formål
  • 1.2. Sammenhæng med øvrige dokumenter
  • 1.3. Læsevejledning
  • 1.4. Introduktion til Stamdataindlæsere
• 2. Opsætning af udviklingsmiljø
  • 2.1. Krav til software
  • 2.2. Bygge Docker images
• 3. Afvikling
  • 3.1. Udviklers arbejdsstation
  • 3.2. Continous Integration & Delivery
    • 3.2.1.1. Build
    • 3.2.1.2. integrationstest
• 4. Beskrivelse af systemdesign
  • 4.1. Overordnet design
  • 4.2. Modtag datasæt
    • 4.2.1. Modtagelse af en fil der skrives til temporær fil
    • 4.2.2. Modtagelse af fil som ikke skrives til temporær fil
    • 4.2.3. Modtagelse af filsæt i folder uden at filer må slettes
  • 4.3. Indlæs datasæt
  • 4.4. Validering af datasæt
    • 4.4.1. Validering af filnavn
    • 4.4.2. Validering af encoding
    • 4.4.3. Validering af struktur
    • 4.4.4. Yderligere validering
  • 4.5. Parsning af datasæt til events
  • 4.6. Validering af events
  • 4.7. Berigelse af events med metadata
  • 4.8. Dublet filter
  • 4.9. Levering af events
    • 4.9.1. Entiteter via SKRS
    • 4.9.2. Events via SKRS
  • 4.10. Logning
    • 4.10.1. SLALog
    • 4.10.2. Applikations- og audit-log
    • 4.10.3. Databaselog
  • 4.11. Backup af fil
  • 4.12. Status servlet
• 5. Beskrivelse af kildekodens struktur og design
  • 5.1. Kodestruktur for fælleskomponenter
  • 5.2. Kodestruktur for stamdataindlæser
  • 5.3. Versionskontrol
  • 5.4. Databasenavnekonvention
• 6. Beskrivelse af test opsætning
  • 6.1. Unittest
    • 6.1.1. Mocking i Camel
    • 6.1.2. Unittests med en kørende MariaDb
  • 6.2. Integrationstest
  • 6.3. Performancetest
• 7. Skabelon for udviklingsprojekt

1. Indledning

Indeværende dokument side tjener som guide til udvikling af fremtidige stamdataindlæsere, som skal udvikles i henhold til referencearkitekturen. Som udgangspunkt er denne guide den samme for enhver stamdataindlæser, hvorfor den ligger under referencearkitektur. Under den tilsvarende Guide til udviklere for en konkret stamdataindlæser, vil der derfor altid refereres til nærværende side, og kun i de tilfælde, hvor noget supplerende specifikt for den pågældende stamdataindlæser er nødvendigt, vil dette skrives under den konkrete stamdataindlæsers Guide til udviklere.

Referencearkitekturen har til formål at skabe et fælles grundlag for en modernisering af eksisterende og kommende stamdataindlæsere. Den gør dette ved at fastlægge de strukturer, metoder og paradigmer som anvendes ved udvikling af en stamdataindlæser, og som sammen sikrer en fælles forståelse for strukturen og opførslen af en stamdataindlæser. Betydningen er dels at der sker en modernisering af de eksisterende stamdataindlæsere, men også at fremtidig vedligehold vil være mere effektiv da stamdataindlæsere vil være bygget på et fælles fundament.

...

En typisk terminal kommando, her eksemplificeret for yderindlæseren, for at bygge en indlæser, og starte development docker-compose er som følger:

Denne bygger projektet, stopper og fjerner eventuelle gamle docker-containere, bygger nye og starter det igen.

...

For Yderindlæseren giver det følgende logs i filen nsputil-sla.log:
nsputil-sla.log

4.10.2. Applikations- og audit-log

...

For Yderindlæseren giver det følgende logs i yderAudit.log og yderApplication.log:
yderAudit.log

yderApplication.log

4.10.3. Databaselog

Som et supplement til indholdet i logfilerne samt til at levere datagrundlaget for ovennævnte status-servlet, logges der til følgende tabeller i databasen:

...

Hvis Stamdataindlæseren er ok, svares der med HTTP 200 og (som information) den gældende version af Stamdataindlæseren, f.eks.:

Hvis der er et problem som betyder at Stamdataindlæseren ikke kan sikre konsistensen af stamdata registret, skal der altid svares tilbage med HTTP 500 og en beskrivelse af problemet så driftsorganisationen umiddelbart kan påbegynde afhjælpning af fejlen, f.eks.:

5. Beskrivelse af kildekodens struktur og design

...

Flyway indeholder selv en tabel, som holder styr på hvilke scripts, der er afviklet. For at undgå sammenblanding mellem stamdataindlæsere, anvendes det angivne prefix også ved initialisering og afvikling af Flyway. Hvordan prefixet anvendes kan ses i denne kodestump fra Yderindlæseren:

6. Beskrivelse af test opsætning

...

Unittests kan køres ved at eksekvere

6.1.1. Mocking i Camel

I det Camel kører asynkront, er det nødvendigt for unittests at vide, hvornår Camel er færdig med at indlæse en fil, hvis testen skal vide, hvornår den kan kontrollere, om det gik som forventet. Dette gøres i stamdataindlæsere som Yderindlæseren, i klassen BaseMockTest, hvor Camel-routen mockes ved at tilføje et sidste MockEndpoint, som en test kan vente på.

...