Skip to content

Testsuite for Primärsysteme. This contains all mandatory testcases to pass the KOB (Konformitätsbestätigung) plus optional testcases meant to help during development.

License

Notifications You must be signed in to change notification settings

gematik/KOB-Testsuite


KOB-Testsuite

Einführung

Dies ist die Testsuite, mit welcher die Konformitätsbestätigung der gematik für EPA 3.0 erreicht werden kann.

Es sind der verpflichtende KOB-Test sowie optionale Tests vorhanden. In näherer Zukunft werden diese Tests mittels Testtreiber-Schnittstelle auch in einen voll automatisierbaren Zustand gebracht, sodass automatisierbar Regressionstests durchgeführt werden können.

Important

Für die Ausführung der KOB-Testsuite ist es wichtig, dass nicht die PS-Testsuite und auch keine Mock Services aus dem epa-deployment parallel auf dem gleichen Rechner verwendet werden (u.a. wegen Port Konflikte).

Setup

Die grundsätzlichen technischen Voraussetzungen sehen wie folgt aus:

Setup
  • Die Testsuite wird auf einem Tester-PC ausgeführt.

  • Auf diesem läuft auch das Primärsystem.

  • Der Konnektor ist korrekt konfiguriert und erreichbar.

  • Auf diesem Testrechner kann nun die Tiger-Testsuite gestartet werden, ebenso wie der Tiger-Proxy.

  • Die Kommunikation zwischen Primärsystem und der TI muss nun über den Tiger-Proxy geleitet werden.

  • Dieser kann die Kommunikation aufzeichnen und analysieren.

  • Die Testsuite kann Artefakte von Maven Central aus dem Internet beziehen.

Testvorbedingungen

Die grundsätzlichen fachlichen Voraussetzungen sehen wie folgt aus:

  • Die Aktenkonten bei beiden Aktensystemen sind eingerichtet worden.

  • E-Rezepte für die Aktenkonten wurden eingestellt. (z.B. können AVS Hersteller hierfür das Gematik Tool vom Medical Team ERPIONE nutzen)

  • Die Aktenlokalisierung der Aktenkonten kann bei beiden Aktensystemen erfolgreich durchgeführt werden.

  • Für die genutzte LEI (SMCB) kann eine Befugnis (Entitlement) für die Aktenkonten bei den beiden Aktensystemen eingestellt werden.

  • In Nicht-PU-Umgebungen muss der Client (das Primärsystem) die verwendeten Schlüssel (K2_c2s_app_data und K2_s2c_app_data) Base64 kodiert im Header "VAU-nonPU-Tracing" übertragen. Dies ist nur für die Testumgebungen (z.B. KOB-Testfall) vorgesehen und MUSS für die produktive Umgebung (PU) zwingend wieder entfernt und dürfen dort NICHT übertragen werden. (siehe A_24477)

Konfiguration

Warning

Für eine ordnungsgemäße Ausführung der KOB-Testsuite dürfen nur bestimmte Dateien angepasst werden. Diese sind: * kob.yaml (Konfiguration der Testsuite) * dc-testsuite.yml (Konfiguration des Docker-Containers) * .env (Konfiguration des Docker-Containers)

Alle übrigen Dateien dürfen nicht verändert werden!

Die folgenden, relevanten Konfigurationen der KOB-Testsuite müssen wie folgt in kob.yaml vorgenommen werden:

  • kvnrIbm - die für die KOB gegen das IBM Aktensystem verwendete KVNR

  • kvnrRise - die für die KOB gegen das RISE Aktensystem verwendete KVNR

  • emltype - das für die KOB verwendete EML-Format

  • useTestdriverApi - ob die Testtreiber-API bei der KOB verwendet werden soll

TLS Konfiguration

Der Tiger-Proxy unterstützt TLSv1.2 und gibt Server Zertifikate zurück, welche den Zertifikaten der Aktensysteme entsprechen. Zusätzlich wurden die unterstützen CipherSuiten wie folgt eingeschränkt (GS-A_4384-*):

  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

Routing

Es muss das Routing der Nachrichten über Tiger-Proxy der KOB-Testsuite erfolgen, um eine Auswertung dieser zu ermöglichen. Der Tiger-Proxy leitet die Anfragen an die korrekten Aktensysteme weiter. Wichtig ist hierbei auch, dass in dem äußeren HTTP-Request auch der HTTP-Header "Host" für die Anfrage an das entsprechende Aktensystem gesetzt ist, damit Tiger-Proxy die Anfrage entsprechend nach dem Mitschnitt weiterleiten kann.

Beispiel für den HTTP-Header, damit Tiger-Proxy korrekt routen kann.

Host: epa-as-1.ref.epa4all.de

Es gibt keine Vorgabe WIE diese Umleitung erfolgen muss, zwei Wege scheinen jedoch sinnvoll:

Forward Proxy (Variante 1)

In dieser Konfiguration kann die KOB-Testsuite als Forward-Proxy für das Primärsystem eingerichtet werden. Die Routen sind entsprechend konfiguriert, damit der Verkehr hier an die korrekten Aktensysteme weitergeleitet wird.

Hierbei sind folgende Punkte zu beachten:

  • Primärsystem seitig wird die KOB-Testsuite als Proxy konfiguriert (e.g. localhost:443). Hiermit werden die Requests über die KOB-Testsuite an die Aktensysteme gesendet. Ein Request an https://epa-as-1.ref.epa4all.de/foobar, via KOB-Testsuite mit localhost:443 entspricht somit curl -x localhost:443 epa-as-1.ref.epa4all.de/foobar)

  • Dabei ist darauf zu achten, dass der HTTP Header im (äußeren) HTTP Request dennoch den FQDN des Aktensystems enthält (e.g Host: epa-as-1.ref.epa4all.de), damit das Routing an das gewünschte Aktensystem erfolgen kann.

  • Eine zusätzliche Manipulation der DNS Auflösung (Variante 2) in der hosts Datei ist nicht notwendig.

DNS Manipulation (Variante 2)

Alternativ kann die DNS-Auflösung beeinflusst werden, z.B. über das Editieren der Host-Einträge im Testsystem selbst (e.g. /etc/hosts). Hier werden die Hostnamen der Aktensysteme auf die IP-Adresse des Testrechners, wo der Tiger-Proxy mit dem Port 443 läuft, umgeleitet.

Beispiel, wenn das Primärsystem auf dem gleichen Rechner läuft, wie die Testsuite mit dem Tiger-Proxy.

# Zur Durchfuehrung der KOB und/oder optionalen Testfällen
127.0.0.1    epa-as-1.ref.epa4all.de
127.0.0.1    epa-as-2.ref.epa4all.de
Important

Diese Einträge sollten nach der Durchführung der KOB-Testsuite wieder entfernt werden, da es ansonsten zu einem unbeabsichtigten Fehlverhalten führt, wenn die KOB-Testsuite nicht mehr aktiv läuft und somit die Nachrichten nicht mehr an die Aktensysteme weitergeleitet werden.

Proxy für die Erreichbarkeit der Aktensysteme

Sollten sich die Aktensysteme nicht direkt erreichen lassen, sondern nur über einen (Forward) Proxy (z.B. in einem unternehmensinternen VPN), dann müssen in der Datei tiger.yml folgende Zeilen entsprechen aktiviert und angepasst werden:

  # proxy configuration
  forwardToProxy:
    hostname: <PROXY_IP_OR_FQDN>
    port: <PROXY_PORT>

Konfiguration von Git

Bei dem Checkout für eine lokale Kopie von dem Repository ist darauf zu achten, dass die Dateien nicht verändert werden durch ein Checkout selbst. Hierzu ist zu prüfen, dass folgenden Git Einstellungen (.gitconfig) für den Checkout des Repos genutzt werden:

[core]
  autocrlf = false

Dies kann mit folgenden Befehlen erreicht werden, je nachdem auf welcher Ebene die Einstellung getroffen werden soll:

git config --system core.autocrlf false   # per-system solution
git config --global core.autocrlf false   # per-user solution
git config --local core.autocrlf false    # per-project solution

Proxy Konfiguration für Maven (Docker)

Da der KOB-Testsuite Container während der Ausführung Maven-Artefakte bezieht, muss das Internet für den Container erreichbar sein. Sollte das Internet nur über einen Proxy-Server erreichbar sein, müssen die Einstellungen in der [./settings.xml](./settings.xml) für die Ausführung des PS-Testsuite Containers angepasst werden. Bitte beachten Sie, dass der Parameter <active>true</active> gesetzt werden muss, um die Einstellungen zu aktivieren und das Docker-Volume kob-testsuite-maven gelöscht werden muss, um die Änderungen zu übernehmen.

Dazu müssen die folgenden Einträge angepasst werden:

  <proxy>
    <id>optional</id>
    <active>true</active>
    <protocol>https</protocol>
    <host>proxy.example.com</host>
    <port>8080</port>
    <username>user</username>
    <password>password</password>
    <nonProxyHosts>localhost|127.0.0.1</nonProxyHosts>
  </proxy>

Testausführung

Die KOB-Testsuite kann entweder lokal per Maven oder in einem Docker-Container ausgeführt werden. Per Default starten momentan nur die verpflichtenden KOB-Testfälle. Ohne diesen Filter werden alle Tests ausgeführt. Siehe .env Datei. Hier können dann auch die optionalen Testfälle, wenn gewünscht, konfiguriert werden.

  • @KOB - für den Test gegen beide Aktensysteme (Default)

Optionale Testfälle:

  • @login - Aufbau einer User-Session bei einem der beiden Aktensysteme

  • @information-record-status - Aktenkontolokalisierung bei einem der beiden Aktensysteme

  • @information-consent-decisions - Abfrage der Zustimmung für ein Aktenkonto bei einem der beiden Aktensysteme

  • @entitlement - Einstellen einer Befugnis für ein Aktenkonto bei einem der beiden Aktensysteme

Lokal (Maven)

Für die lokale Ausführung werden folgende Software-Versionen empfohlen:

  • Maven Version >= 3.9

  • JAVA Version >= 17

Ist dies gegeben, reicht ein einfaches Kommando mvn clean verify im Root-Verzeichnis des Projekts.

Lokal (Docker)

Die Testsuite kann mit einem Docker-Compose gestartet werden.

docker compose -f dc-testsuite.yml up

WorkflowUI

Die Durchführung der Testsuite geschieht über die von der KOB-Testsuite bereitgestellte Webseite der WorkflowUI. Hierzu wird die folgende Adresse im Browser aufgerufen, wenn sich die Testsuite auf dem lokalen Rechner gestartet wurde: http://localhost:9010. Beim Starten über Maven versucht die Testsuite diese Seite automatisch im Default-Browser zu öffnen. Beim Starten als Docker Container wird der entsprechende Link im Log ausgegeben, sobald die Seite aufrufbar ist.

========================================================================================================================
  ____ _____  _    ____ _____ ___ _   _  ____  __        _____  ____  _  _______ _     _____        __  _   _ ___
 / ___|_   _|/ \  |  _ \_   _|_ _| \ | |/ ___| \ \      / / _ \|  _ \| |/ /  ___| |   / _ \ \      / / | | | |_ _|
 \___ \ | | / _ \ | |_) || |  | ||  \| | |  _   \ \ /\ / / | | | |_) | ' /| |_  | |  | | | \ \ /\ / /  | | | || |
  ___) || |/ ___ \|  _ < | |  | || |\  | |_| |   \ V  V /| |_| |  _ <| . \|  _| | |__| |_| |\ V  V /   | |_| || |   _ _ _
 |____/ |_/_/   \_\_| \_\|_| |___|_| \_|\____|    \_/\_/  \___/|_| \_\_|\_\_|   |_____\___/  \_/\_/     \___/|___| (_|_|_)

========================================================================================================================
09:21:12.065 [main ] INFO  d.g.t.t.l.TigerDirector - Waiting for workflow Ui to fetch status...
09:21:12.065 [main ] INFO  d.g.t.t.l.TigerDirector - Workflow UI http://localhost:9010

Nachdem der Testfall gestartet wurde, wartet die Testdurchführung auf eine Benutzerinteraktion, um mit der Prüfung der mitgeschnittenen Nachrichten vorzufahren. D.h. das in diesem Moment die eML vom Aktensystem abgerufen wurden muss, bevor man die Testdurchführung fortführt.

Continue Dialog in Testsuite

Port Tabelle

Service

Port

Protocol

Tiger Testsuite (WorkflowUI)

9010

http

Tiger-Proxy Admin Port

9011

http

Tiger-Proxy Proxy Port

443

http / https

Prüfnachweis für die KOB

Für die Beantragung des KOB Zertifikates bei der gematik benötigen Sie als Prüfnachweis den Testreport (zip file) und pro konfiguriertem Aktensystem je ein Screenshot (Bilddatei) von Ihrer GUI des PS auf der die angezeigte eML ersichtlich wird. Den Screenshot Datei(en) erstellen Sie bitte lokal bei Ihnen am System.

Note

Sollten ihr Primärsystem oder Middleware keine Verordnung oder abweichende Verordnungen ausstellen können, so ist bei der Beauftragung in TITUS über die Kommentarfunktion Bemerkung eine Begründung beizufügen.

Einzustellende E-Rezepte

In dem o.g. Screenshot für die Beantragung des KOB Zertifikates sollte die elektronische Medikationsliste mit den folgenden Feldern für die jeweiligen Medikationen ersichtlich sein:

  • Verordnungsdatum

  • Wirkstoffname

  • Wirkstärke

  • Arzneimittelbezeichnung

  • Form

  • Dosierangabe/ Gebrauchsanweisung

  • PZN

  • Verordner

Abgeleitet werden sollen Einträge von folgenden beispielhaften E-Rezepten, wobei der Screenshot Daten aus der jeweiligen Tabelle enthalten soll:

Arzneimittelbezeichnung Form Dosierangabe/ Gebrauchsanweisung PZN

Prospan® Hustensaft 100ml N1

FLE

2mal tägl. 5ml

08585997

Wirkstoffname Wirkstärke Dosierangabe/ Gebrauchsanweisung

Ramipril

5 mg/1

1-0-0-0

Wirkstoffname Wirkstärke Dosierangabe/ Gebrauchsanweisung

Salicylsäure

5 g

1–3mal/Tag auf die erkrankten Hautstellen auftragen

2-propanol 70 %

Arzneimittelbezeichnung

Metformin 850mg Tabletten N3

Nutzung von Gematik E-Rezept Client

Für die Erstellung der E-Rezepte können Sie alternativ den Gematik E-Rezept Client ERPIONE nutzen. Dieser ist als Docker Container in Dockerhub veröffentlicht. Eine weiterführende Dokumentation zu der Funktionsweise des Clients in Verbindung mit dem Backend Service PRIMSYS ist in Github beschrieben.

Benötigen Sie ein API Key oder haben generell Fragen zu dem Client, wenden Sie sich bitte an den gematik Service Desk und öffnen Sie ein entsprechendes Ticket (siehe Fehlertickets).

Testreport

Die Testergebnisse selbst sind unter target/site/serenity/index.html zu finden und können somit im Browser verifiziert werden. Der Testreport wird automatisch nach der Ausführung im target/kob-testsuite.*-test-report.zip abgelegt, wenn die Ausführung über den Quit Button in der WorkflowUI beendet wird.

Testreport aus Docker Container

Um diese Datei aus dem Docker Container in das lokale System zu kopieren, kann folgender Befehl genutzt werden:

docker cp kob-testsuite:/app/report/kob-testsuite-test-report.zip .

Eine weitere Möglichkeit ist, die Report ZIP Datei über die Anwendung DockerDesktop herunterzuladen.

Download Test Report ZIP über Docker Desktop

Upload bei TITUS

Loggen Sie sich in Ihren Account auf dem Titus Bestätigungsportal (https://titus.gematik.solutions) ein und laden Sie die entsprechenden Prüfnachweise im Bestätigungsantrag hoch. Für das Hochladen nutzen sie den Dialog "Nachweise für das Bestätigungsverfahren", wo sowohl der Testreport als ZIP Datei als auch den/die Screenshot Datei(en), welche die eML in ihrem Primärsystem darstellen, ausgewählt werden können. Im Anschluss starten Sie den Bestätigungsnachweis über TITUS.

Upload Dialog in TITUS

Weitere Hinweise zur Handlungsanweisung für die Konformitätsbewertung (KOB) können im Service Desk nachgelesen werden: https://service.gematik.de/servicedesk/customer/kb/view/459882847

Fragen zum Titus-Bestätigungsportal und zur Durchführung des KOB Verfahrens können Sie ebenfalls über unseren Service Desk einstellen: https://service.gematik.de/servicedesk/customer/portal/26/group/36

Troubleshooting / FAQs

Starten der Testsuite (Docker)

java.nio.file.AccessDeniedException: /.m2/repository/org

Der Zugriff auf das Docker Volume schlägt fehl.

Variante 1

Das Volume mit der gleichen Bezeichnung schon existiert und wurde von einer anderen, möglicherweise älteren, Version der KOB-Testsuite erstellt wurde. Man muss das Volume einmal löschen und bei Start der neuen Testsuite wird es wieder angelegt.

$> docker compose -f dc-testsuite.yml rm
$> docker volume rm -f kob-testsuite-maven
$> docker compose -f dc-testsuite.yml up

Variante 2 (Linux)

Bitte prüfen Sie vor dem Start der Testsuite, ob Sie das .docker Verzeichnis löschen können und starten sie die Testsuite im Anschluss noch einmal.

Variante 3 (ohne Docker Volume)

Eine weitere Möglichkeit ist auf die Nutzung des Docker Volume zu verzichten. Der Nachteil hierbei ist, dass die Maven Artefakte bei jedem Start der Testsuite erneut heruntergeladen werden müssen, was mehr Zeit in Anspruch nimmt. Hierzu wird die Zeile - kob-testsuite-maven:/.m2 wie folgt mit einem Hash (#) auskommentiert.

    volumes:
      - ./tiger.yaml:/app/tiger.yaml
      - ./kob.yaml:/app/kob.yaml
      #- kob-testsuite-maven:/.m2
      # has to be 'copied' AFTER the volume is mounted
      - ./settings.xml:/.m2/settings.xml

Ausführen der Tests / fehlschlagende Tests

Im Falle eines fehlgeschlagenen Testlaufs und dem Schreiben eines Support-Tickets im gematik Service Desk ist es sinnvoll, die *.tgr-Datei mit den aufgezeichneten Nachrichten anzuhängen. Damit ist es möglich, die Traces in eine lokale Tiger-Anwendung zu importieren, um die Kommunikation und deren Meldungsdetails anzuzeigen.

Dazu müssen Sie den folgenden Befehl ausführen, um die *.tgr aus dem ps-testsuite Container in das lokale Verzeichnis zu kopieren.

docker cp ps-testsuite:/app/tiger-proxy.tgr .

Geplante Änderungen

Hier eine Übersicht über die wichtigsten Änderungen, die wir planen. Wenn Sie hier Dinge vermissen oder Anregungen haben, melden Sie sich bitte bei uns!

  • Automatisierung der optionalen Tests. Hierfür werden ggf. Anpassungen der Testtreiberschnittstelle notwendig sein. Diese Änderungen werden aber NICHT mit den verpflichtenden Tests kollidieren. Sprich: Die jetzt existierende Schnittstelle wird aller Voraussicht nach bis zur KOB 3.0 unverändert bleiben.

  • Einbau einer Test-REST-API in die Tiger-Testsuite, um eine bessere Integration in CI/CD-Pipelines zu ermöglichen.

Fehlertickets

Wenn Sie ein Fehlerticket eröffnen wollen für dieses Repository, nutzen Sie bitte den gematik Service Desk unter https://service.gematik.de/servicedesk/customer/portal/26.

Beiträge

Wenn Sie zu diesem Repository beitragen wollen, schauen Sie sich bitte die Datei CONTRIBUTING.MD an.

License

Copyright 2024 gematik GmbH

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License.

See the LICENSE for the specific language governing permissions and limitations under the License.

Additional Notes and Disclaimer from gematik GmbH

  1. Copyright notice: Each published work result is accompanied by an explicit statement of the license conditions for use. These are regularly typical conditions in connection with open source or free software. Programs described/provided/linked here are free software, unless otherwise stated.

  2. Permission notice: Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

    1. The copyright notice (Item 1) and the permission notice (Item 2) shall be included in all copies or substantial portions of the Software.

    2. The software is provided "as is" without warranty of any kind, either express or implied, including, but not limited to, the warranties of fitness for a particular purpose, merchantability, and/or non-infringement. The authors or copyright holders shall not be liable in any manner whatsoever for any damages or other claims arising from, out of or in connection with the software or the use or other dealings with the software, whether in an action of contract, tort, or otherwise.

    3. The software is the result of research and development activities, therefore not necessarily quality assured and without the character of a liable product. For this reason, gematik does not provide any support or other user assistance (unless otherwise stated in individual cases and without justification of a legal obligation). Furthermore, there is no claim to further development and adaptation of the results to a more current state of the art.

  3. Gematik may remove published results temporarily or permanently from the place of publication at any time without prior notice or justification.

  4. Please note: Parts of this code may have been generated using AI-supported technology.’ Please take this into account, especially when troubleshooting, for security analyses and possible adjustments.

Kontakt

gematik GmbH: [OSPO@gematik.de](mailto:OSPO@gematik.de)

About

Testsuite for Primärsysteme. This contains all mandatory testcases to pass the KOB (Konformitätsbestätigung) plus optional testcases meant to help during development.

Resources

License

Code of conduct

Security policy

Stars

Watchers

Forks

Packages

No packages published

Languages