From 9cdde0bad3a768a987706ba03c9222c27b5d308b Mon Sep 17 00:00:00 2001 From: Johannes Marbach Date: Wed, 13 Nov 2024 14:58:08 +0100 Subject: [PATCH] Stop generating SVGs and use PNGs instead --- .github/workflows/generate-images.yml | 6 ++++-- docs/Fachdienst/MessengerService.adoc | 4 ++-- docs/IDP/idp.adoc | 2 +- docs/Test/Test.adoc | 24 ++++++++++++------------ docs/anwendungsfaelle/COM-chatbot.adoc | 2 +- 5 files changed, 20 insertions(+), 18 deletions(-) diff --git a/.github/workflows/generate-images.yml b/.github/workflows/generate-images.yml index 7b89cac7..1225a339 100644 --- a/.github/workflows/generate-images.yml +++ b/.github/workflows/generate-images.yml @@ -13,8 +13,10 @@ on: jobs: generate: - uses: gematik/github-image-actions/.github/workflows/generate-images.yml@0.1.0 + uses: gematik/github-image-actions/.github/workflows/generate-images.yml@5542d48205b96c1488e12a967fe64291ace49c97 with: srcdir: src/images outdir: images/generated - ref: 0.1.0 + ref: 5542d48205b96c1488e12a967fe64291ace49c97 + png: true + svg: false diff --git a/docs/Fachdienst/MessengerService.adoc b/docs/Fachdienst/MessengerService.adoc index d38e8d99..c3428ade 100644 --- a/docs/Fachdienst/MessengerService.adoc +++ b/docs/Fachdienst/MessengerService.adoc @@ -23,7 +23,7 @@ Die folgende Seite gibt einen kurzen Überblick über die Funktionalitäten und == Überblick Der *Messenger-Service* ist eine Teilkomponente des *TI-M Fachdienstes* und wird für Organisationen des Gesundheitswesens (z. B. Arztpraxis, Krankenhaus, Krankenkasse, Apotheke, Verband, Kostenträger etc.) bereitgestellt. Der *Messenger-Service* besteht aus einem *Matrix-Homeserver* (basierend auf dem Matrix-Protokoll) und einem *Messenger-Proxy*. Dieser stellt sicher, dass eine Kommunikation mit anderen Messenger-Services, als Teil des *TI-M Dienstes*, nur innerhalb der gemeinsamen *TI-Föderation* erfolgt. Der *Matrix-Homeserver* basiert auf dem offenen Kommunikationsprotokoll link:https://spec.matrix.org/[Matrix]. Welche Schnittstellen der *Messenger-Service* nutzt und anbietet ist in der folgenden Abbildung dargestellt: -image::generated/TI-M_Basis/API-Messenger-Service.svg[align="center",width="55%"] +image::generated/TI-M_Basis/API-Messenger-Service.png[align="center",width="55%"] ==== Authentifizierungsverfahren *Messenger-Services* können den Akteuren unterschiedliche Authentifizierungsverfahren anbieten. Dabei können diverse Authentifizierungsmechanismen durch eine Organisation für Ihre Akteure bereitgestellt werden. Die Organisation und der von ihr gewählte *TI-Messenger-Anbieter* vereinbaren das zur Anwendung kommende Authentifizierungsverfahren bilateral und stimmen sich über die technische Realisierung der dafür notwendigen Anbindung ab. @@ -34,7 +34,7 @@ Der *Messenger-Proxy* agiert neben der Funktion als Proxy zur Weiterleitung alle ==== Client-Server Prüfungen Der *Messenger-Proxy* als Prüfinstanz aller eingehenden, sowie ausgehenden Anfragen zum *Matrix-Homeserver* ist für die Regelung der gemäß Matrix-Client-Server-API und Matrix-Server-Server-API geltenden Aufrufe zuständig. Daher ist es erforderlich, dass der *Messenger-Proxy* für jeden *Messenger-Service* als Forward- sowie Reverse-Proxy bereitgestellt wird. Die folgende Abbildung verdeutlicht die beide gerade skizzierten Funktionsweisen. -image::generated/TI-M_Basis/Pruefungen_Messenger_Proxy.svg[width="100%"] +image::generated/TI-M_Basis/Pruefungen_Messenger_Proxy.png[width="100%"] Bei Aufruf der Client-Server-API durch einen *TI-Messenger-Client* aus dem Internet fungiert der *Messenger-Proxy* als Reverse-Proxy. Beim Aufruf der Server-Server-API im Rahmen einer Server-To-Server Kommunikation fungiert der *Messenger-Proxy* als Forward-, sowie als Reverse-Proxy. diff --git a/docs/IDP/idp.adoc b/docs/IDP/idp.adoc index 8cf3f2e7..45acff30 100644 --- a/docs/IDP/idp.adoc +++ b/docs/IDP/idp.adoc @@ -321,4 +321,4 @@ CAUTION: Der von der gematik bereitgestellte Authenticator wird nicht in Verbind Die Abbildung zeigt die Verwendung des *Authenticators* mit der Auto-Redirect Funktion (`callback=DIRECT`) bei der die `redirect_uri` direkt vom Authenticator aufgerufen wird und der Browserclient über Polling beim Fachdienst den Status des Austausches des Tokens abfragt. Details zur Interaktion mit dem *Authenticator* sind in Kapitel _Interaktion mit der Fachanwendung_ beschrieben. Alternativ könnte der *Authenticator* beim Aufruf der `redirect_uri` eine nutzerfreundliche Webseite der *Relying Party* in einem neuen Browsertab öffnen. -image::generated/Other/idp.svg[width="100%"] +image::generated/Other/idp.png[width="100%"] diff --git a/docs/Test/Test.adoc b/docs/Test/Test.adoc index 97b72b5e..10b108ab 100644 --- a/docs/Test/Test.adoc +++ b/docs/Test/Test.adoc @@ -47,20 +47,20 @@ Dieses Testtreiber-Module MUSS Bestandteil der Test-APP sein (internes Testtreib Bei einem internen Testtreiber-Modul wird die REST-Schnittstelle in die Test-App integriert (der Zugriff erfolgt hierbei direkt über das Endgerät). .Abbildung{counter:abbildung: 1}: internes Testtreiber Modul -image:generated/Other/Test/testtreiber-internes-Modul.svg[align="left",width="100%", title="internes Testtreiber Modul"] +image:generated/Other/Test/testtreiber-internes-Modul.png[align="left",width="100%", title="internes Testtreiber Modul"] ==== externes Testtreiber-Modul Bei einem externen Testtreiber-Modul erhält die REST-Schnittstelle Zugang zum Test-Environment des Herstellers. .Abbildung{counter:abbildung: 1}: externes Testtreiber Modul -image:generated/Other/Test/testtreiber-externes-Modul.svg[align="left",width="100%", title="externes Testtreiber Modul"] +image:generated/Other/Test/testtreiber-externes-Modul.png[align="left",width="100%", title="externes Testtreiber Modul"] === TI-Messenger Testtreiber Anschaltung Das folgende Bild zeigt die Anschaltung der Testtreiber Clients. Die Clients können über eine externe oder interne Testtreiber-Schnittstelle mit der Testsuite remote oder local verbunden werden. Diese Leistung MUSS von jedem Hersteller erbracht werden. Welche Clients eingesetzt werden, können die Hersteller selbstständig entscheiden. Es werden nur bereitgestellte Clients zugelassen. Clients mit den gleichen Eigenschaften werden unter einer URL zusammengefasst. Diese URL wird dann in die Konfigurationsdatei 'combine_items.json' eingetragen. In dieser Datei werden alle Testobjekte verwaltet. .Abbildung{counter:abbildung: 1}: Anschaltung der Testtreiber Clients -image:generated/Other/Test/Anschaltung der Testtreiber Clients.svg[align="left",width="100%", title="Anschaltung der Testtreiber Clients"] +image:generated/Other/Test/Anschaltung der Testtreiber Clients.png[align="left",width="100%", title="Anschaltung der Testtreiber Clients"] Die unterschiedlichen Testtreibeschnittstellen werden mit mTLS gesichert. Die gematik stellt für den zugriff auf die Schnittstelle entsprechende Zertifikate bereit. Weiterführende Informationen zur Testsuite und zur Testtreiber-Schnittstelle findet man in der https://github.com/gematik/TI-Messenger-Testsuite/blob/main/doc/userguide/Testsuite.adoc[Testsuite TI-M Dienst Release 1.1.1]. @@ -87,14 +87,14 @@ Die gematik stellt eine TI-M Dienst Referenzimplementierung zur Verfügung. Zur Vor der Zulassung können sich die Hersteller eine Referenz-Instanz über die gematik bestellen. Die Referenz-Instanz hilft den Herstellern bei der Entwicklung neuer TI-M Clients, FdV und TI-M FD Versionen. Für die IOP-Tests zwischen den verschiedenen TI-Messenger-Anbietern bzw. -Herstellern können sowohl die Test-Instanzen als auch die Referenz-Instanzen genutzt werden. Die TI-M Dienste müssen gegen die Referenz-Instanz erfolgreich getestet werden. Die Testergebnisse sind der gematik vorzulegen. .Abbildung{counter:abbildung: 1}: Referenz-Instanz -image:generated/Other/Test/HerstellerInstanz.svg[align="left",width="100%", title="Referenz-Instanz"] +image:generated/Other/Test/HerstellerInstanz.png[align="left",width="100%", title="Referenz-Instanz"] === Hersteller IOP Tests Alle Anbieter MÜSSEN bereits im Vorfeld diesen IOP- und E2E-Tests selbständig und eigenverantwortlich durchführen. Bei Problemen im Rahmen der Zulassung MÜSSEN die Anbieter bei der Analyse unterstützen. In der folgenden Abbildung ist eine Systemumgebung für Herstellertests dargestellt. .Abbildung{counter:abbildung: 1}: IOP Testumgebung Hersteller -image:generated/Other/Test/testumgebung-Hersteller.svg[align="left",width="100%", title="IOP Testumgebung Hersteller"] +image:generated/Other/Test/testumgebung-Hersteller.png[align="left",width="100%", title="IOP Testumgebung Hersteller"] == Zulassung @@ -109,20 +109,20 @@ Die Tests werden zunächst gegen die Referenzimplementierung der gematik durchge Die Hersteller von TI-M Diensten müssen wie zuvor erwähnt die Testtreiberschnittstelle und den Fachdienst bereitstellen. Bei Problemen im Rahmen der Zulassung müssen die Anbieter bei der Analyse unterstützen. In der folgenden Abbildung ist eine Systemumgebung für den Zulassungstest TI-Messenger Pro (TI-M Pro) dargestellt. .Abbildung{counter:abbildung: 1}: Zulassung TI-Messenger Pro -image:generated/Other/Test/Zulassung TIM-Basis.svg[align="left",width="100%", title="Zulassung TI-Messenger Pro"] +image:generated/Other/Test/Zulassung TIM-Basis.png[align="left",width="100%", title="Zulassung TI-Messenger Pro"] ==== Zulassung TI-Messenger ePA Die Hersteller von Versicherten-Frontends müssen ebenfalls das FdV, die Testtreiberschnittstelle und den Fachdienst für Versicherte bereitstellen. Bei Problemen im Rahmen der Zulassung müssen die Anbieter bei der Analyse unterstützen. In der folgenden Abbildung ist eine Systemumgebung für den Zulassungstest TI-Messerger ePA (TI-M ePA) dargestellt. .Abbildung{counter:abbildung: 1}: Zulassung TI-Messenger ePA -image:generated/Other/Test/Zulassung TIM-ePA.svg[align="left",width="100%", title="Zulassung TI-Messenger ePA"] +image:generated/Other/Test/Zulassung TIM-ePA.png[align="left",width="100%", title="Zulassung TI-Messenger ePA"] === IOP Tests zwischen Anbietern durch die gematik Zusätzlich zu den bereits durchgeführten IOP- und E2E-Tests werden weitere Interoperabilitätstests verschiedener TI-Messenger-Lösungen vor und nach der Zulassung durch die gematik durchgeführt. Die folgende Abbildung zeigt die Nutzung der existierenden Testumgebung durch die gematik während der Zulassungs- und Interoperabilitätstests. .Abbildung{counter:abbildung: 1}: IOP Tests -image:generated/Other/Test/testumgebung-Gematik.svg[align="left",width="100%", title="IOP Tests"] +image:generated/Other/Test/testumgebung-Gematik.png[align="left",width="100%", title="IOP Tests"] IOP- und E2E-Tests für die Interoperabilität MÜSSEN zwischen den verschiedenen TI-Messenger-Anbietern nachgewiesen werden. Hierfür werden dann alle bereits zur Verfügung stehenden TI-M Dienste (die Test-Instanzen der einzelnen Hersteller) zusammengeschlossen und anschließend gegeneinander getestet. @@ -131,7 +131,7 @@ IOP- und E2E-Tests für die Interoperabilität MÜSSEN zwischen den verschiedene Im Anschluss der Zulassung wird mit den IOP- und E2E-Tests die Interoperabilität zwischen den verschiedenen TI-Messenger-Anbietern nachgewiesen. Hierfür werden dann alle bereits zur Verfügung stehenden TI-M Dienste (die Test-Instanzen der einzelnen Hersteller) zusammengeschlossen und anschließen gegeneinander getestet. Alle Anbieter MÜSSEN bereits im Vorfeld diesen IOP- und E2E-Tests selbständig und eigenverantwortlich durchführen. Bei Problemen im Rahmen der IOP Tests MÜSSEN die Anbieter bei der Analyse unterstützen. In der folgenden Abbildung ist eine Systemumgebung für Herstellertests TI-M Pro dargestellt. .Abbildung{counter:abbildung: 1}: IOP Test TI-Messenger Pro -image:generated/Other/Test/Testumgebung Basis.svg[align="left",width="100%", title="IOP Test TI-Messenger Pro"] +image:generated/Other/Test/Testumgebung Basis.png[align="left",width="100%", title="IOP Test TI-Messenger Pro"] Weiterhin wird ein dauerhaftes Continuous Testing eingeführt. Das Continuous Testing wird dann in der Folge erweitert Dadurch wird auch ein Test unterschiedlicher Messenger Versionen und Ausprägungen ermöglicht. @@ -140,19 +140,19 @@ Weiterhin wird ein dauerhaftes Continuous Testing eingeführt. Das Continuous Te Für den TI-M ePA gelten ebenso die im Kap. 3.2.1 beschriebenen Anforderungen an den IOP Test. In der folgenden Abbildung ist eine Systemumgebung für Herstellertests TI-M ePA dargestellt. Bei Problemen im Rahmen der IOP Tests MÜSSEN die Anbieter des Fachdienstes und des FdVs bei der Analyse unterstützen. .Abbildung{counter:abbildung: 1}: IOP Test TI-Messenger ePA -image:generated/Other/Test/Testumgebung ePA.svg[align="left",width="100%", title="IOP Test TI-Messenger ePA"] +image:generated/Other/Test/Testumgebung ePA.png[align="left",width="100%", title="IOP Test TI-Messenger ePA"] ==== IOP Tests Pools Um eine größere Abdeckung zu erhalten werden die Hersteller in Pools eingeteilt. Somit können mehrere Hersteller gleichzeitig getestet werden. Anschließend werden die Pools erneut gemischt. .Abbildung{counter:abbildung: 1}: IOP Test Pools -image:generated/Other/Test/IOP Pools.svg[align="left",width="100%", title="Verpflichtung nach der Zulassung"] +image:generated/Other/Test/IOP Pools.png[align="left",width="100%", title="Verpflichtung nach der Zulassung"] == Verpflichtung nach der Zulassung Der TI-Messenger-Anbieter MUSS eine Referenz-Instanz und mindestens eine Test-Instanz des TI-Messenger-Fachdienstes (TI-M FD) und TI-Messenger-Clients (TI-M Client) bereitstellen und betreiben. Die Referenz-Instanz hat die gleiche Version wie die Produktionsumgebung. Weiterhin wird die Referenz-Instanz für die Reproduktion aktueller Fehler/Probleme aus der Produktionsumgebung genutzt. Der Zugriff auf die Referenz-Instanz MUSS für die gematik zur Fehleranalyse gewährleistet sein. Die Test-Instanz dient den Herstellern bei der Entwicklung neuer TI-M Clients und TI-M FD Versionen, bei den IOP-Tests zwischen den verschiedenen TI-Messenger-Anbietern und wird zudem von der gematik für die Zulassung genutzt. Der TI-Messenger-Anbieter MUSS die verschiedenen Benutzer der Referenz-Instanz und der Test-Instanz koordinieren (Verwaltung eines Test-/Nutzungsplans). Bei Bedarf (Entwicklung verschiedener Versionen, hoher Auslastung durch andere Hersteller oder durch die gematik) MUSS der TI-Messenger-Anbieter auch mehrere Test-Instanzen mit der gleichen oder mit verschiedenen Versionen bereitstellen und betreiben. .Abbildung{counter:abbildung: 1}: Verpflichtung nach der Zulassung -image:generated/Other/Test/nach_der_Zulassung.svg[align="left",width="100%", title="Verpflichtung nach der Zulassung"] +image:generated/Other/Test/nach_der_Zulassung.png[align="left",width="100%", title="Verpflichtung nach der Zulassung"] Die Referenz-Instanz und die Test-Instanz wird auch im Anschluss der Zulassung weiter für IOP Test und Continuous Testing genutzt. \ No newline at end of file diff --git a/docs/anwendungsfaelle/COM-chatbot.adoc b/docs/anwendungsfaelle/COM-chatbot.adoc index 29909f3d..29f2856b 100644 --- a/docs/anwendungsfaelle/COM-chatbot.adoc +++ b/docs/anwendungsfaelle/COM-chatbot.adoc @@ -53,7 +53,7 @@ C. Beispielhafter Ablauf (siehe Abbildung "Kommunikation mit einem Chatbot"): .Kommunikation mit einem Chatbot [%collapsible%open] ==== -image:generated/Other/chatbot.svg[width="100%"] +image:generated/Other/chatbot.png[width="100%"] ====