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, WildFly applikationsserver 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

Definition	Beskrivelse
NSI	National Sundheds-IT
NSP	Den nationale service platform (inden for sundheds-IT)
SHAK	Sygehusafdelingsklassifikation
SOR	Sundhedsvæsenets organisationsregister
STS	Security Token Service
BRS	Behandlingsrelationsservicen
HS	Healthshare Document Registry
NXRG	Det nationale XDS Registry på NSP

Alias	Beskrivelse
Oversigt	Dokumentdelingsservice (DDS)
DGWS	Den Gode WebService 1.0.1
Design	DDS - Design- og Arkitekturbeskrivelse
Installationsvejledning	DDS - Installationsvejledning
Min-log	MinLog2 - Design og Arkitektur beskrivelse
SAM	MinSpærring - Arkitektur og Design
SAM-guide	MinSpærring - Guide til Udviklere
Minlog-guide	MinLog2 - Min Log Registrering - Guide til udviklere

TODO: tjek om alias bliver brugt

Introduktion til DDS Registry og Repository

Realisering af DDS registry og repository består af en Java-baseret webservices.

Webservicene tillader anvender systemer at

lave forespørgsler til dokumentdelingsservice og få metadata om patientinformationer, der er gemt deri, retur. Den filtrerer resultatet baseret på borgerens samtykker.
foretage udtræk af patient specifikke dokumenter fra XDS dokument kildesystemer. Den filtrerer dokumenterne 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ø

I det følgende antages at koden er hentet ned fra softwarebørsen el.lign.

Krav til software

Krav til applikationsserveren, operativsystemet og databasen er de samme som til produktionsmiljøet. De specifikke krav kan ses i [Installationsvejledning] afsnit 2.

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

Krav til Maven

Maven 3.0.3 eller højere anvendes.

Krav til Docker

Docker 18.x eller højere anvendes.

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:

mvn test

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

Integrationstest

For at køre integrationstesten gøres følgende:

Byg DDS, som beskrevet ovenfor

Udfør følgende kommandoer:

cd compose/development
docker-compose up --build

Vent på at setuppet kommer op.

cd integrationstest

mvn verify -Plocal,integration-tests

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

TODO: hvor meget skal med fra gl repository guide i afsnit "Beskrivelse af kildekodens struktur og design" og hvor opdateret er den? Ret evt. intro afsnit

TODO: Og hvad med Cobertura til code coverage. Source koden har referncer her til. Evt. flyttes til test vejledningen?

Generelt design af DDS Registry og Repository

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 implementeret ved brug af Den Gode Webservice [DGWS], hvor Seal.Java er anvendt til at håndtere sikkerhed og DGWS headers.

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

Servicen er implementeret som en Java-webservice.

Beskrivelse af kildekodens struktur og design

TODO Eva

Kodestruktur

Projektet er delt i følgende moduler:

dds/common – modul der indeholder de java-komponenter, de to webservices (DDS registry & repository) deler.
dds/brs-client – modul der indeholder en webserviceklient til kommunikation med BRS.
dds/ddsregistry – modul der indeholder webservice til filtrerede opslag i healthshare (denne service).
dds/ddsrepository – modul der indeholder webservice til at hente dokumenter vedrørende specifikke patienter fra healthshare
dds/types – modul der indeholder wsdl’er og xml-skemafiler i SOAP 1.2 version. Disse bruges af webservicen, til at snakke med healthshare.
dds/integrationtest-util – modul der indeholder java-komponenter, som flere integrationtests deler.
dds/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 repository.
dds/cobertura – modul der indeholder komponenter til instrumentering af kode til generering af code coverage rapport.
dds/xds-repository-stub – modul der indeholder en stub der kan køres tests imod.
dds/ddsregistry-proxy – modul der indeholder en proxy til udviklingsbrug. Proxyen sikrer at der kun bliver gemt data på testpatienter.

Der er afhængigheder til forskellige maven-artefakter, hvoraf følgende er skabt i regi af NSI:

dk.nsi,services-common:services-common – modul der indeholder de dele af koden der er fælles for alle komponenterne, herunder interface til opslag i SOR register, DGWS fejlkoder, samt utilities til logning med mere.
dk.nsi.services-common:remote-test-resources – Modulet indeholder SQL-scripts og datasource konfigurationer til Stamdata database. Scripts opretter Stamdata databasen og tabellerne med initielt test data.
dk.nsi.hsuid:hsuid – modul der indeholder implementering af OIO attributter til identifikation af sundhedsfaglige personer, der er fælles for webservicekomponenter, der anvender DGWS.
dk.nsi.dgws:dgws-common – modul der indeholder implementering af DGWS fælles funktionalitet til håndtering af DGWS header og fejlkoder.
dk.nsi.dgws:provider – modul der indeholder implementering af DGWS provider funktionalitet, der anvendes af alle komponenter der anvender DGWS i rollen som web service provider.
dk.nsi.dgws:remote-test-resources – Modulet indeholder SQL-script og datasource konfiguration til whitelist databasen. Script opretter whitelist databasen med initielt test indhold.
dk.nsi.dgws:consumer – modul der indeholder implementering af DGWS consumer funktionalitet, der anvendes af komponenter der anvender DGWS i rollen som web service consumer (aktuelt ConsentAdministration, der kalder Min-log-registration webservicen).
dk.nsi.consentservices.verification:consent-verification-client – modul der indeholder funktionalitet til kald af webservice til verifikation af samtykker.
dk.nsi.minlog.registration:minlog-registration-client – modul der indeholder funktionalitet til kald af webservice til registrering af hændelser i en borgers Minlog.