Dette dokument beskriver en kort byggevejledning og derudover en testvejledning for Det Fælles Stamkort 1.5-servicen. Der anvises også en metode til mere detaljeret verifikation og fejlfinding.
Projektet bygges med Maven og kræver Java 8 samt en MariaDB-installation for at kunne afvikle tests.
Version | Dato | Ændring | Ansvarlig |
|---|---|---|---|
2.0.0 | 2018-08-27 | Initialt dokument | Trifork |
For blot at bygge projektet og dets deployable (war-fil) anvendes følgende Maven kommando:
mvn clean install -DskipTests
Bemærk at kommandoen skipper unit-tests og integrationstests, men Maven-eksekveringen starter alligevel en lokal Wildfly-server op, deployer servicen og lukker Wildfly-serveren ned igen. Denne sideeffekt skal blot ignoreres.
Projektets deployables ender i target-mappen under de respektive moduler.
For at afvikle unit-tests skal en MariaDB-database være tilgængelig.
I udviklingssammenhæng og ved unit-tests kan man nøjes med én databasebruger og én database. Disse kan oprettes vha. scripterne recreate_service_user.sql og recreate_database.sql som er lokaliseret under fsk-service/etc/db/. Derefter kan Flyway automatisk initialisere databasen under Maven byg.
Datasourcen i testafviklingen auto-konfigureres vha. Spring Boot som anvender database-credentials fra fsk-service/src/test/resources/application.properties. De default værdier matcher værdierne i de førnævnte SQL-scripts.
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
Der genereres desuden en testrapport.
Integrationstest kan både afvikles på en lokal Wildfly-server og på et eksternt miljø.
Selve integrationstesten består af et kald til OnDemand webservicen.
For at afvikle integrationstests lokalt anvendes følgende Maven kommando:
mvn clean install
Bemærk at dette først afvikler unit-tests.
Når Maven når til integration-test-fasen starter den selv en Wildfly-server op, hvor den automatisk installerer og deployer følgende ting:
Når servicens er installeret og deployet på et ekstern miljø, kan korrekt deployment verificeres ved at køre integrationstestene på det eksterne miljø. Dette gøres ved at anvende følgende maven kommando:
mvn verify -pl fsk-test -DFSK_TEST_HOST=<host> -DFSK_TEST_PORT=<port> -DFSK_TEST_DOCID=<docid>
I ovenstående kommando skal <host> erstattes med adressen på det eksterne miljø, <port> med portnummeret, servicen svarer på (typisk 8080), og <docid> med et dokument-id, som findes i RegistryIndex-tabellen i det pågælende eksterne testmiljøs FSK database.
Bemærk at dette kræver, at projektet er fuldt bygget, for at lokale dependencies er på plads.
Bemærk også at Maven-eksekveringen alligevel starter en lokal Wildfly-server op, deployer servicen og lukker Wildfly-serveren ned igen. Denne sideeffekt skal blot ignoreres.
Efter afvikling af unittests genereres en testrapport med Maven-plugin’et JaCoCo. Rapporten kan ses ved at åbne følgende fil i en browser:
fsk-service/target/site/jacoco/index.html
Dette gælder for selve fsk-service og dets funktionalitet, som refereres til modul: fsk.
I aktuelle version af fsk-service er codecoverage 80%. Der henvises til JaCoCo testrapporten for yderligere information vedr. coverage.
Nedenstående beskrivelse kan benyttes hvis der er behov for mere detaljeret verifikation og fejlfinding på et FSK-miljø.
Der er følgende integrationer i FSK:
1. Replikering af NSP stamdata til tabellerne YderregisterPerson_v3, Yderregister_v3 og v2_Person.
2. Registrering af dokument-metadata i DDS registry baseret på CPR-data fra v2_Person.
3. Kald til FSKs DocumentProviderWS fra DDS, hvilket medfører kald til SCES, SKR, LTR/BTR og ODR
De forskellige integrationer kan verificeres på følgende måde:
1. Hvis replikeringen af stamdata har været succesfuld, bør der være data i de 3 nævnte tabeller. I produktion findes nedenstående tabelstørrelser (på testmiljøer findes der kun en brøkdel):
YderregisterPerson_v3 ca. 21.000
Yderregister_v3: ca. 63.000
v2_Person: 14-15 mio
2. FSK opdaterer dokumentdelingsservicens registry, så der findes metadata for personer der er markeret som levende i v2_Person. Når der registreres metadata for et CPR-nummer, vil der opstå en ny række i FSK-tabellen RegistryIndex, som indeholder en registrering af FSKs dokumentId og CPR-nummer. Når synkroniseringen er færdigkørt, bør antallet af rækker i RegistryIndex matche antal aktive personer i v2_Person (med status 01 og ValidFrom < now() < ValidFrom).
3. Når FSK har registreret metadata for et CPR-nummer i DDS, kan FSKs on-demand service kaldes gennem DDS. Dette gøres nemmest via testklasse der ligger her i projektet:
fsk.service/src/test/java/dk/stamkort/integrations/dds/DDSIntegrationTest.java
I testklassen indsættes værdierne fra en tilfældig række i tabellen RegistryIndex i variablerne personIdentifier og fskDocumentId. Testen benytter konfiguration fra fsk-service/src/test/resources/testclient.properties, som skal tilrettes hvis der ikke er tale om test1-miljøet (se evt. afsnit 2.2 her: https://www.nspop.dk/pages/viewpage.action?pageId=32126754). Endvidere skal man redigere værdien af "dds.repository.unique.id" i fsk/src/test/resources/application.properties, så det matcher miljøet (se evt. installationsvejledningen mht. hvilke værdier der hører til hvilke miljøer).
En kørsel af callDDS-testen bør resultere i logning af følgende i testklassen:
Errors: 0
Warnings: 0
Retrieved documents: 1
Unreachable documents: 0
Returned document: <?xml version="1.0" encoding="UTF-8" standalone="yes"?><POCD_MT000040.ClinicalDocument moodCode="EVN" classCode="DOCCLIN" xmlns="urn:hl7-org:v3" xmlns:ns2="urn:hl7-org:sdtc" xmlns:ns3="urn:hl7-org:fsk">...</POCD_MT000040.ClinicalDocument>
Hvis der skulle opstå en fejl i FSK ifm. generering af dokumentet, vil det resultere i logning af "Unreachable documents: 1". I den situation er det nødvendigt at inspicere FSKs logfiler for at finde årsagen til fejlen.