...

Dette dokument har til formål at gøre det muligt for andre end den oprindelige leverandør at overtage videreudvikling af Det Fælles Stamkort 1.5 (FSK).

Dokumentationen er rettet mod udviklere og IT-arkitekter, som ikke på forhånd har kendskab til komponenten, og som ikke har adgang til komponentens oprindelige udviklere.

Det forudsættes at læseren har læst dokumentet Design og Arkitektur (FSK).

Ændringslog

...

Version

...

Dato

...

Ændring

...

Ansvarlig

...

2.0.0

...

2018-08-27

...

Initialt dokument

...

Trifork

...

.

...

Introduktion til projektet

FSK 1.5-servicens formål er at agere som en on-demand datakode for Dokumentdelingsservicen (DDS)datakilde for SFSK. Såfremt en sundhedsprofessionel henter en borgers stamkort gennem Dokumentdelingsservicen, vil FSK 1.5 -servicen blive kaldt af DDSSFSK, og returnere et XML dokument, som er sammenstillet af data fra følgende registre:

• CPR-Enkeltopslag (SCES)
• Organdonorregistret (ODR)
• Livstestamenteregistret (LTR)
• Behandlingstestamenteregistret (BTR)
• Stamkortregistret (SKR)
  
• Fravalg af Genoplivningsforsøg ved Hjertestop Register (FGVHR)

For ODR, LTR og BTR gælder, at der kun returneres information om, hvorvidt der findes data i de pågældende registre eller ej. Såfremt data ønskes hentet fra disse registre skal der foretages til kald direkte til den pågælende pågældende register-service. Se Se Guide til anvendere (FSK) for for beskrivelse af format for dokumentet, der returneres af FSK 1.5

Servicen er designet med henblik på udstilling via den nationale serviceplatform (NSP).Kodebasen består af én WAR-fil / komponent fsk-service.war.

Specielle bemærkninger

Databasevedligehold

...

WSDL'er og XSD'er for SCES, ODR, LTR, BTR, SKR og SKR FGVHR ligger i modulet fsk-schemas. Dette modul genererer JAXB-klasser som defineret i modulets pom.xml. De genererede klasser anvendes af tilsvarende Client-moduler SCESClient, OrganDonorClient, LivingWillClient, TreatmentWillClient, PersonalDataCardRegisterClient og PersonalDataCardRegisterClientFgvhrClient, som alle findes her: fsk-service/src/main/java/dk/stamkort/integrations.

Foretage succesfuldt kald af on-demand webservice i udviklingsmiljø

Efter deployment af fsk-serviceweb.war til en lokal Wildfly installation i udviklingsmiljøet er det muligt at kalde on-demand webservicen. Dette kan eksempelvis gøres ved at afvikle metoden callOnDemandService i klassen OnDemandServiceITCase inde i IntelliJ, og forinden specificere FSK_TEST_PORT til 8080 i den tilhørende IntelliJ runtime-konfiguration.

Som udgangspunkt er det dog ikke er muligt at få et succesfuldt svar tilbage, med mindre alle underliggende services kan kaldes med succes. Dvs. der skal anvendes et cpr-nummer, der findes i SCES, og både LTR-BTR, ODR og SKR de pågældende services skal være deployet korrekt til Wildfly, med tilhørende DGWS/IDWS proxies.  deployed korrekt på et af NSP's testsystemer (vi bruger typisk "test1" under udvikling). Alternativt kan integration til de enkelte services disables i FSK-servicens application.properties, som det f.eks. er gjort i fsk-test modulet.

...

Bygge projektet og afvikle unit tests

For at bygge projektet og afvikle unit -tests skal en MariaDB-database være tilgængelig. Dette opnår man lettest ved at køre MariaDB i en Docker-container. Følgende kommando køres fra projektroden:

docker-compose -f compose/development/docker-compose.yml up --build

Bemærk: Det kan tage op mod et minut før containeren er klar. De nødvendige databaser bliver oprettet automatisk. Bemærk at projektet skal bygges før ovenstående kommando fungerer, dette gøres med følgende kommando, ligeledes fra projektroden:

mvn clean install -DskipTests=true

I application.properties-filen i projektet er datasources som default sat til at anvende root-user med tomt password. Database-strukturen bliver automatisk oprettet vha. Flyway SQL-scripter, når unit-testene afvikles.

Datasourcen i testafviklingen auto-konfigureres vha. Spring Boot som anvender database-credentials fra ltr-btr-service/src/test/resources/application.properties.

Projektet skal være fuldt bygget for at lokale dependencies er på plads, og dernæst kan unit tests afvikles med følgende Maven kommando:

mvn clean test

tests anvendes følgende kommando:

mvn clean install

Der genereres Der genereres desuden en testrapport.

Adgange

Der er behov for adgange til følgende systemer:

• NSP SVN-repositoryBitBucket (git)
• Dependencies trækkes fra NSP's Nexus-repository: https://nexus.nspop.dk

Opsætning af udviklingsmiljø

Al kode findes i NSP SVNBitBucket.

Efter at projektet er checket ud vil man typisk gøre følgende:

• Opsætte udviklingsmiljø (her antages IntelliJ)

• Bygge war-filen med Maven og køre tests

Bygge WAR filer

Følgende software er nødvendigt for at bygge projektet

• En Subversion-klient

• Java 8

• Maven

• MariaDB

...

1. Check projektet ud fra SVN

2. Start MariaDB ved at køre følgende kommando: docker-compose -f compose/development/docker-compose.yml up fskdb

3. For at bygge projektet, foretage unittests samt at bygge war-filer foretages kommandoen: mvn clean install

Deployment med Docker

Når man udvikler kan det være praktisk at deploye applikationen lokalt. Dette kan gøres vha. Docker docker Compose-filen under compose/development/docker-compose.yml.

docker-compose up -d --build

I forbindelse med udvikling og fejlsøgning kan det være praktisk også at spinne FSK Registry op samt CDA viewer, som giver en brugergrænseflade, der kan anvendes til fremsøgning og hentning af stamkort på udviklingsmiljøet. Der er lavet en docker-compose til dette formål: compose/development/docker-compose-testutils.yml.

Den kan startes med:

docker-compose -f docker-compose-testutils.yml up

...

hvorefter CDA viewer er tilgængeligt lokalt på: http://localhost:8081/