Introduktion

...

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

...

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)

...

Afvikle komponenten

...

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

...

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

Servicen er implementeret sikret ved brug af Den Gode Webservice [DGWS], hvor Seal.Java er anvendt anvendelse af NSP Security API til at håndtere sikkerhed og DGWS headers(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.Servicen er implementeret som en Java-webservice.

Beskrivelse af kildekodens struktur og design

TODO Eva

Kodestruktur

Projektet er delt i følgende moduler:

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

• types:

• 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, Anvendes 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:

• kommunikere med DDS backend XDS Repositories og XDS Registries.
• 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)
• sores-client: modul til kommunikation med sores servicen efter sor koder
• 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

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