Introduktion

Formål

Formålet med dette dokument er at beskrive hvordan et udviklingsmiljø, til videreudvikling af DDS Registry og Repository, kan sættes op, samt hvordan koden bygges, deployes og testes.

I afsnit 3 (Opsætning af udviklingsmiljø) beskrives de softwaremæssige krav der er til miljøet samt hvordan kode bygges og køres.

Kodestrukturen, kodemæssige afhængigheder til tredjeparts moduler og de forskellige servicemodulers ansvar og design beskrives i afsnit 4 (Generelt design af DDS Registry og Repository).

Sammenhæng med øvrige dokumenter

Dette dokument er en del af den samlede dokumentation for DDS projektet.

Dokumentets relation til de øvrige dokumenter er beskrevet i dokumentationsoversigten for projektet: Dokumentdelingsservice (DDS).

Læsevejledning

Læser forventes at have kendskab til Java softwareudvikling med anvendelse af Maven, Docker og MySQL.

Hvor der i teksten er angivet <component base> refereres til topniveaufolderen for kildekoden for komponenten.

Dokumenthistorik

Dokumentet er oprettet med udgangspunkt i 2 separate Guide til udviklere for registry henholdsvis repository. Den videre redigeringshistorik efter dette tidspunkt fremgår af confluence "Page History".

Definitioner og referencer

Introduktion til DDS Registry og Repository

Realisering af DDS Registry og Repository består af en Java-baserede webservices.

Webservicene tillader anvender systemer at

• lave forespørgsler til dokumentdelingsservice og få metadata om patientinformationer, der er gemt i de bagvedliggende XDS Registries, retur. Den filtrerer resultatet baseret på borgerens samtykker.

• foretage udtræk af patient specifikke dokumenter fra XDS dokument kildesystemer. DDS filtrerer under visse omstændigheder dokumentindholdet baseret på borgerens samtykker.

Servicene validerer brugerens rettigheder, kalder behandlingsrelationsservicen og gemmer eventuelle relevante oplysninger i borgerens Min-log.

For en dybere introduktion til servicen og baggrunden bag, se "DDS - Guide til anvendere" og "DDS - Design- og Arkitekturbeskrivelse".

Opsætning af udviklingsmiljø

DDS source koden ligger i SVN på følgende URL: https://svn.nspop.dk/svn/components/dds/

Krav til software

Krav til udviklingsmaskiner er de samme som til produktionsmiljøet. De specifikke krav kan ses i DDS - Installationsvejledning.

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

• Maven 3.0.3 eller højere.
• Docker 18.x eller højere.
• docker-compose version 1.23.x eller højere.

Bygge komponenten

Udfør følgende kommando for at bygge komponenten:

mvn clean install

Det tager lidt tid, da der skal genereres kode ud fra et større antal wsdl-filer.

Unit test (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 testreport/target/site/jacoco-aggregate/index.html

Aktuel code coverage beregnes også af Jenkins. Se https://jenkins.nspop.dk/.

Afvikle komponenten

Efter byg kan DDS afvikles vha docker-compose. Til dette formål findes compose-setup i mappen compose.

For at starte DDS afvikles følgende kommando (build parameteren sikrer, at DDSens Docker images bygges):

Vent på at setuppet kommer op (loggen falder til ro).

Integrationstest

For at køre integrationstesten gøres følgende. DDS komponenten afvikles i docker-compose som beskrevet ovenfor.

Dernæst kan integrationstestene startes med følgende kommandoer:

Det er muligt at ramme andre miljøer end det lokale ved at udskifte local med test1 eller test2.

Generelt design af DDS Registry og Repository

DDS består af to overordnede applikationer: DDS Registry og DDS Repository, der kan bygges (som war-filer og senere som Docker images) og afvikles uafhængig af hinanden.

Servicene består af en række Maven-moduler, der findes under dds/ddsregistry og dds/ddsrepository

• application: Indeholder webservice og forretningslogik

• war: Bygger war-filen der skal deployes

• integrationtest: Indeholder integrationstests af webservicene

Derudover er der en række generelle designvalg for servicen:

Servicen er sikret ved anvendelse af NSP Security API til at håndtere sikkerhed (i praksis DGWS og IDWS).

JAX-WS er anvendt til kodegenerering ud fra WSDL-filer og JAXB er anvendt til kodegenerering ud fra XSD-filer.

Beskrivelse af kildekodens struktur og design

Koden er bygge op som et hierarki af maven moduler. De enkelte moduler er beskrevet nedenfor:

• types: modul der indeholder wsdl’er og xml-skemafiler i SOAP 1.2 version. Anvendes til at kommunikere med DDS backend XDS Repositories og XDS Registries.
• client-types: modul der indeholder wsdl’er og xml-skemafiler i SOAP 1.1 version. Disse skal bruges til at lave en klient der kan kontakte DDS services.
• minspaerring-client: modul til kommunikation med MinSpærring (tjek af spærringer)
• brs-client: modul til kommunikation med BRS
• stamdata-lookup-client: modul til kommunikation med stamdata-lookup (personinformation)
• common: diverse fællesmoduler, der anvends både af DDS Repository og DDS Registry
• ddsregistry:
  
  • application: DDS Registry specifikke klasser og funktionalitet
  • war: pakker DDS Registry som en web applikation
• ddsrepository:
  • application: DDS Repository specifikke klasser og funktionalitet
  • war: pakker DDS Repository som en web applikation
• testreport: samler de enkelte coverage reports op for de forskellige moduler til en samlet rapport
• integrationstest
  • nsp-service-clients: modul til oprettelse af testdata i eksterne services (MinSpærring)
  • dds-xds-testclient: modul med fælles testfunktionalitet (ikke afhængig af sikkerhedsprotokol)
  • dds-dgws-testclient: DGWS integrationstests
  • dds-oioidws-testclient: IDWS integrationstests