Overblik

Dette dokument beskriver en testvejledning for Det Fælles Stamkort 1.5-servicen. Det forudsættes at projektet er bygget og installeret, og med denne vejledning kan man således afvikle integrations- og performancetests og derved kontrollere robustheden.

Ændringslog

Version

Dato

Ændring

Ansvarlig

2.0.0

2018-08-27

Initialt dokument

Trifork

2.0.92019-25-09AjourførtTrifork

Integrationstests

Integrationstest skal afvikles mod den deployede komponent med test-opsætning.

Selve integrationstesten består af et kald til OnDemand webservicen.

Når servicens er installeret og deployet, kan korrekt deployment verificeres ved at køre integrationstestene. Dette gøres ved at anvende følgende Maven-kommando, som aktiverer Maven-profilen extITs  specificerer miljø:

For opsætningen af miljøet er der lavet 3 maven profiler.  

mvn verify -pl fsk-test -PextITs -P<miljø>

Der er oprettet en test person i DTG med cpr. 0509900267. Denne persons FSK stamkort docid kan så benyttes i testen se nedenstående tabel for de konkrete værdier af docid. 

miljødocid
devurn:sds:fsk:stamkort:00000000-0000-0000-0000-000000000003
test11.2.208.176.43210.8.10.12^3f718e08-7940-4fcd-a460-1769ac82416c
test21.2.208.176.43210.8.20.12^317b5758-90c7-45eb-be03-1aa7dedb4121

Ønsker man at angive host, port og docid direkte på komandolinjen kan man også gøre dette.

mvn verify -pl fsk-test -PextITs -DFSK_TEST_HOST=<host> -DFSK_TEST_PORT=<port> -DFSK_TEST_DOCID=<docid>

I ovenstående kommando skal <host> erstattes med adressen på det miljøet, <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.

Hvis man er uheldig og kommer til at afvikle testen med f.eks. Java 11 får man en fejl om at attributten soapenv:mustUnderstand ikke må være der. Det kan få en til og tro at det er FSK og eller testen der er noget i vejen med. Problemet er dog højest sandsynligt at man ikke anvender Java 8 når man afvikler testen.

Der er tilføjet en bunke integrationstests til at teste hjørnetilfælde mellem SKR og FSK. De tager lidt tid at køre og kan derfor deaktiveres med -DSKIP_CORNER_CASE_TESTS=true

Codecoverage

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.

Verifikation og fejlfinding

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.

  • No labels