# Package at.chipkarte.client.tsv.soap

Interface und Klassen der Testszenarienverwaltung (TSV).

See: Description

- Interface Summary
  Interface | Description
  --- | ---
  ITsvService | Dieses Service stellt die Funktionalitäten der Testszenarienverwaltung (TSV) zur Verfügung.

- Class Summary
  Class | Description
  --- | ---
  Zuordnungsinformation | Von TSV aufgrund der Szenario-Zuordnung erzeugte Zuordnungsinformationen.

## Package at.chipkarte.client.tsv.soap Description

Interface und Klassen der Testszenarienverwaltung (TSV). Dieses Package enthält den SOAP Endpoint `ITsvService` sowie die dazu notwendigen Klassen.
Inhalt der TSV package-Beschreibung:

- Allgemein

- Rechte
- Anmeldung
- Online/Offline Status
- e-card CardToken

- Funktionalität des TSV Service

- Schulungsszenarien abfragen
- Schulungsszenarien zuordnen
- Schulungsdaten löschen

- Informationen bzgl. Schulungsszenarien

# Allgemein

Dieses Service dient rein der Verwendung durch Vertragspartnersoftware-Hersteller.
Das TSV Service steht aus diesem Grund nur auf GINAs von Vertragspartnersoftware-Herstellern zur Verfügung. Die Zuordnung der GINA zu einer Benutzergruppe (Softwarehersteller oder Vertragspartner) kann mittels der BASE Funktion getGinaSoftwareVersion() abgefragt werden.

## Rechte

Für die Funktionen des TSV Service benötigt der Vertragspartner für die Durchführung das Recht TSV.CORE.
Wird eine Funktion, welche dieses Recht benötigt, ohne das entsprechende Recht aufgerufen, erhält man die Exception AccessException.MISSING_TSV_CORE.
Mittels der Funktion getBerechtigungen() aus dem BASE Service ist es möglich, die Rechte des Vertragspartners abzufragen.

## Anmeldung

Zur Nutzung der TSV Funktionalitäten muss der VertragspartnerSoftware-Hersteller einen Dialog auf einer VPSWH GINA aufbauen.
Dieser Dialog kann entweder mittels Pseudo o-card oder einem, für den SW-Hersteller registrierten, SW-Zertifikat (Enterprise Funktionalität) aufgebaut werden.

## Online-/Offline-Status

Im laufenden Betrieb kann ein Offline-Zustand bzw. das Auftreten eines Verbindungsproblems in Abängigkeit der Kommunikationsart mit dem e-card System wie folgt identifiziert werden:

- die Kommunikation erfolgt direkt über die GINA:
  Die aufrufende Funktion retourniert eine entsprechende SOAP Exception (ServiceException.CONNECTION_ERROR).
- die Kommunikation erfolgt über den Proxy auf der GINA:
  Es wird als Response HTTP 503 retourniert.
- die Kommunikation erfolgt direkt mit dem Serversystem:
  Es erfolgt keine Response.

Ob eine Verbindung für ein bestimmtes Service zum e-card-Serversystem besteht, sollte im Normalbetrieb NICHT abgefragt werden! Die Abfrage sollte nur dann durchgeführt werden um festzustellen, ab wann das Service wieder online ist, wenn zuvor Verbindungsprobleme aufgetreten sind.
Die empfohlene Frequenz für die Abfragen liegt in diesem Fall bei > 1 Minute.
Die Abfrage ist über eine REST Schnittstelle durchzuführen: Der Aufruf erfolgt mittels:
GET https://<gina-adresse>/<service-name>/<versionsnummer>/status
Ist der Server erreichbar, wird der Response HTTP 200 retourniert. Ist der Server nicht erreichbar (Offline) und der Request wird über die GINA geschickt (direkt über die GINA bzw. über den GINA Proxy), wird der Response HTTP 503 retourniert.
Hinweis: Erfolgt die Kommunikation mittels GINA Proxy wird im HTTP 503 Response zusätzlich der Text "Die GINA konnte keine Verbindung zum Serversystem herstellen." im Response-Body befüllt.
Erfolgt die Abfrage direkt auf das Serversystem (nach Entfall der GINA) wird im Offline-Fall keine Response mehr retourniert.

## e-card CardToken

Das e-card Cardtoken (SV-Signaturtoken mit e-card) kann mittels REST Schnittstelle vom LANCCR angefordert werden.
Die Dokumentation des REST-Services zur Kommunikation mit dem Kartenleser ist zu finden unter: Swagger Doku LANCCR.
Bei der Verwendung eines Test-Patienten kann ein e-card Cardtoken (SV-Signaturtoken mit e-card) oder ein o-card Cardtoken (SV-Signaturtoken mit Admin-Karte) ausgestellt werden.
Das ausgestellte Cardtoken kann anschließend in den Funktionen der jeweiligen Services anstelle einer (gesteckten) e-card verwendet werden.
Das Stecken der e-card zum Ausführen der jeweiligen Servicefunktion ist nicht mehr notwendig.
Das Cardtoken kann je nach Service für eine bestimmte Dauer nach Ausstellung genutzt werden. In der Regel ist ein ausgestellter CardToken für 10 Stunden verwendbar.
Welcher Cardtoken vom jeweiligen Service unterstützt wird, ist bei den Services selbst definiert.
In TSV wird nur das e-card Cardtoken unterstützt!
In TSV muss bei folgenden Funktionen ein Cardtoken zwingend angegeben werden:

- setSchulungsszenario()
- deleteSchulungsdaten()

Das Cardtoken muss dabei mit der Pseudo-e-card erstellt worden sein, zu der eine Zuordnung gewünscht ist.

# Funktionalität des TSV Service

Mittels dieses Services können Vertragspartnersoftware-Hersteller ihren Pseudo e-cards (mittels Angabe des jeweiligen Cardtokens) verschiedene, vordefinierte Szenarien zuordnen, um die Abläufe und Fehlerfälle der einzelnen Services mit verschiedenen SV-Personen (mit verschiedenen Vorbedingungen) durchzulaufen und zu testen. So gibt es z.B. Szenarien bei denen die SV-Person mehrfachversichert ist oder bei denen die e-card der SV-Person als gesperrt gekennzeichnet ist usw.
Folgende Funktionalitäten können durchgeführt werden:

## Schulungsszenarien abfragen:

Die verfügbaren Schulungsszenarien werden ermittelt.

## Schulungsszenarien zuordnen:

Der mittels angegebenen Cardtoken definierten Pseudo e-card wird das ausgewählte Szenario zugeordnet. Nach dieser Zuordnung besitzt diese Pseudo e-card innerhalb des TSV Service die Ansprüche und Daten der SV-Person des ausgewählten Szenarios.
War bereits ein Szenario der Pseudo e-card zugeordnet, wird dieses gelöscht (ebenso wie eventuell vorhandene Schulungskonsultationen u. ä.) und die neue Zuordnung vorgenommen.
Hinweis: Bei bestimmten Szenarien können Zusatzinformationen retourniert werden, die bei anderen Services Verwendung finden (z.B. REZID).
Wichtig: Ist der Pseudo e-card bereits ein Szenario mit einer Namensangabe zugeordnet, erfolgt keine automatische Rücksetzung auf den Originalnamen der Pseudo e-card bei Zuordnung eines Szenarios ohne Namensangabe.

## Schulungsdaten löschen:

Wurden durch die mittels CardToken angegebene Pseudo e-card am Testsystem Schulungsdaten angelegt (zum Beispiel Konsultationen), werden diese, sowie vorhandene weitere Daten (wie z.B. AU-Meldungen, ...) entfernt..
Das ursprüngliche Szenario bleibt dabei weiterhin der Pseudo e-card zugordnet.
Hinweis: Bei bestimmten Szenarien können Zusatzinformationen retourniert werden, die bei anderen Services Verwendung finden (z.B. REZID).
Wichtig:Ist der Pseudo e-card bereits ein Szenario mit einer Namensangabe zugeordnet, erfolgt keine automatische Rücksetzung auf den Originalnamen der Pseudo e-card beim Löschen der Schulungsdaten über die SS12. Das Zurücksetzen der Namensdaten wird nur über die e-card WEB-GUI unterstützt!

# Informationen bzgl. Schulungsszenarien

Eine Beschreibung der verfügbaren Szenarien finden Sie im der Szenarienbeschreibung unter www.chipkarte.at (Bereich Softwarehersteller).