medExtendedServices - medline-online.com · Die Version der soapUI für die Testsuite ist V2.5.1,...

medExtendedServicesEntwicklerdokumentation

2103-3-580-00PORevision: 2452

21.09.2009

medExtendedServices V01.02

Hypercom GmbHKonrad-Zuse-Straße 19-2136251 Bad Hersfeld

Internet: www.medline.hypercom.com www.hypercom.com

© 2009 Hypercom Corporation, alle Rechte vorbehalten. Hypercom und das Hypercom Logo sind eingetragene Marken der Hypercom Corporation. Alle anderen Produkte oder Dienstleistungen, die in diesem Dokument genannt werden, sind Marken, Dienstleistungsmarken, eingetragene Marken oder eingetragene Dienstleistungsmarken der entsprechenden Eigentümer.

Hypercom erteilt keine stillschweigenden Garantien auf handelsübliche Qualitäten und Eignung für einen bestimmten Einsatzzweck.Hypercom übernimmt keine Haftung für Fehler oder Folgeschäden, die durch Ausstattung, Leistung und Gebrauch dieser Dokumentation entstehen. Diese Dokumentation enthält urheberrechtlich geschützte Informationen.Diese Dokumentation darf ohne vorherige Genehmigung von Hypercom weder vollständig noch in Auszügen fotokopiert, vervielfältigt, übersetzt oder auf Datenträgern erfasst werden. Änderungen in dieser Dokumentation sowie alle Rechte vorbehalten.

Technische Änderungen vorbehalten.

Entwicklerdokumentation 2103-3-580-00PO Seite 2 von 26

http://www.medline.hypercom.com/

http://www.hypercom.com/


Inhaltsverzeichnis

1 Einleitung....................................................................................................................4

2 Schnittstelle von medExtendedService......................................................................4

2.1 Besonderheiten unter Windows CE.....................................................................6

2.2 Besonderheiten beim medMobile........................................................................7

3 Testsuite soapUI.........................................................................................................7

3.1 Download und Installation der soapUI Umgebung..............................................7

3.2 Import des medExtendedServices SOAP-Projektes...........................................8

3.3 Anpassung der HOSTS-Datei.............................................................................9

4 Arbeiten mit dem soapUI Projekt.............................................................................11

4.1 Starten des medExtendedService.....................................................................11

4.2 Durchführen der Standardtestfälle.....................................................................11

4.2.1 Lesen der KVK............................................................................................12

4.2.2 Lesen der eGK............................................................................................14

4.2.3 Lesen gespeicherter Karten eines medMobile...........................................17

4.2.4 Lesen der eGK – erweiterte Requests........................................................18

4.3 Weitere Testfälle................................................................................................20

5 Testclient „medDump“..............................................................................................21

5.1 Überblick............................................................................................................21

5.2 Programmablauf................................................................................................22

5.3 Kompilieren von „medDump“ ............................................................................24



1 Einleitung

Das Programmpaket medExtendedServices stellt dem Entwickler Services zur Verfügung, um eGKs und KVKs auszulesen und medline Terminals von Hypercom zu verwalten. Die Dienste werden dabei als WebServices zur Verfügung gestellt, die sich konform zu einer Untermenge der WebServices eines Konnektors für das Release 2.3.4 und das Release 1.3.1 verhalten. Die benutzten WSDLs und Schemata befinden sich im Ordner WSDLs im Installationsverzeichnis.Die Serverkomponenten basieren auf dem Apache Axis2/C Framework. Folgende Systeme werden für die Serverkomponente unterstützt:

- WinCE 5.0 (x86), inkl. Wyse Thin Clients- Win32 (ab Windows 2000)

Installation und Einrichtung des Dienstes können dem Installationshandbuch entnommen werden. Diese Dokumentation soll Entwicklern dazu dienen, Komponenten zu entwickeln oder anzupassen, um mit Hilfe von medExtendedService eGKs und KVKs auszulesen. Dazu wird zunächst der Service selbst und danach ein Tool vorgestellt, mit dem es möglich ist, WebServices über ein GUI anzusprechen, um so auf einfache Art und Weise Testfälle oder Abläufe abzubilden. Abschließend wird das Beispielprogramm medDump erläutert, mit dessen Hilfe eGK-Daten und KVK-Daten als Dateien abgelegt werden können.

2 Schnittstelle von medExtendedService

Die Serverkomponente besitzt eine WebService basierte Schnittstelle. Eine Auflistung aller enthaltenen Dienste eines lokal laufenden medExtendedService kann über die URL http://localhost:8080/services/ abgerufen werden:


http://localhost:8080/services/


Die zur Verfügung gestellten WebServices basieren auf den WSDLs der gematik zu Release „2“ (Schemadateien Release 2.3.4) und Release „1“. Es werden folgende Operationen bereitgestellt:

• CardService (Endpunktbeispiel: http://localhost:8080/services/CardService)

o RequestCardo EjectCardo GetCardTerminals (erweiterte Rückgabe bei medMobile)o GetCards

• KVKService (Endpunktbeispiel: http://localhost:8080/services/KVKService)

o ReadKVK (erweiterte Rückgabe bei medMobile)• VSDService (Endpunktbeispiel:

http://localhost:8080/services/VSDService)o ReadVSD (erweiterte Rückgabe bei medMobile)o ReadVSDWithoutAuth (erweiterte Rückgabe bei

medMobile)• CardService_V1 (Endpunktbeispiel:

http://localhost:8080/services/CardService_V1)o RequestCardo EjectCardo GetCardTerminals (erweiterte Rückgabe bei medMobile)o GetCards

• KVKService_V1 (Endpunktbeispiel: http://localhost:8080/services/KVKService_V1)

o ReadKVK (erweiterte Rückgabe bei medMobile)• VSDService_V1 (Endpunktbeispiel:

http://localhost:8080/services/VSDService_V1)o ReadVSD (erweiterte Rückgabe bei medMobile)

Nicht benötigte Operationen wurden entfernt.

Lokale Endpunkte müssen über das HTTP-Protokoll, entfernte Endpunkte über HTTPS angesprochen werden. Weitere Hinweise zur Konfiguration finden sich im Installations- und Anwenderhandbuch.


http://www.gematik.de/upload/gem_Schemadateien_R2.3.4_081219_4437.zip


In der folgenden Abbildung wird der Datenfluss von einer Clientkomponente bis zum eigentlichen Service kurz erläutert:

Eine Beschreibung der Operationen befindet sich für den CardService in der Konnektorspezifikation (gematik Konnektorspezifikation 2.10.0) und für die anderen Services in der Facharchitektur Versichertenstammdatenmanagement (gematik Facharchitektur VSDM 2.6.0).

Das Lesen einer eGK findet bei medExtendedService wie im Release „0“ vorgesehen statt: Ein ReadVSD ist also identisch mit ReadVSDWithoutAuth. Das erforderliche Element HpcHandle im Request ReadVSD kann mit einem beliebigen String gefüllt sein. Das Element darf jedoch nicht entfallen oder leer sein. Um Entwickler zu unterstützen, die Ihre Software bereits für die Nutzung eines HBAs vorbereiten wollen, kann in der Konfigurationsdatei die Option HBA auf „true“ gesetzt werden. Nun wird immer ein Handle eines gesteckten HBAs im Request GetCards angezeigt.

2.1 Besonderheiten unter Windows CE

Der Dienst medExtendedService ist auch auf Windows CE 5.0 für x86 lauffähig. Die portierte CT-API unterstützt jedoch nur über V.24 angeschlossene medline Terminals. Die Portierung von Axis2/C auf Windows CE hat eine wichtige Einschränkung. Der Dienst arbeitet hier nicht multithreaded, bearbeitet also nur jeweils einen Request zur gleichen Zeit. Die Netzwerkverbindung muss also nach jedem Request-Response abgebaut werden, bevor ein neuer Request an den medExtendedService geschickt wird.Im Falle eines Axis2/C Clients kann dies über die Methode axis2_stub_free(...) gelöst werden. Diese Methode gibt den Speicher des


http://www.gematik.de/upload/gematik_VSD_Facharchitektur_VSDM_V2.6.0__3871.pdf

http://www.gematik.de/upload/gematik_VSD_Facharchitektur_VSDM_V2.6.0__3871.pdf

http://www.gematik.de/upload/gematik_KON_Konnektor_Spezifikation_V2.10.0_4391.pdf


Stub-Codes wieder frei und schließt noch offene Sockets. Im nächsten Abschnitt werden Testfälle und Abläufe und Ihre Durchführung mit Hilfe einer Testsuite erläutert.

2.2 Besonderheiten beim medMobile

Wird ein konfiguriertes medMobile erkannt liefert GetCardTerminals zusätzliche Informationen über das Terminal: Die Anzahl der gespeicherten Karten, der Ladezustand und die Authentisierungszustand wird angegeben. Sollen gespeicherte Karten ausgelesen werden gibt es zwei Wege: Zum Einen ist eine explizites Anfordern einer gespeicherten Karte über RequestCard möglich (hier muss als SlotId „1“ genutzt werden), die gelieferte Karte kann dann ausgelesen werden (ReadKVK bzw. ReadEGK enthalten zusätzliche Informationen zum Auslesedatum und der Zulassungsnummer des verwendeten Terminal und abschließend wird die Karte mit Hilfe von EjectCard aus der Verwaltung entfernt und auf dem Terminal gelöscht. Weitere Karten sind nun wieder unter Verwendung von RequestCard anzufordern. Zum Anderen ist ein Automatisches Anfordern möglich, dazu muss in der Konfigurationsdatei das Flag medMobile.AutoInsert auf „true“ gesetzt sein. Nun fordert ein GetCards mit CtId des medMobile die nächste Karte selbsttätig an, die Karte kann dann wie gewohnt ausgelesen werden. Wird nach erfolgreichem Auslesen wieder GetCards aufgrufen, wird die bereits gelesene Karte aus der Verwaltung entfernt und auf dem Terminal gelöscht und eine weitere Karte wird angefordert.

Ein zu Testzwecken genutztes medView darf nicht mit automatischem Anfordern genutzt werden.

3 Testsuite soapUI

Für Entwicklungen und Tests rund um den medExtendedService von Hypercom wird ein soapUI-Projekt als Beispiel- und Testumgebung mitgeliefert.Dieses Projekt kann nach Belieben erweitert oder verändert werden.

Als Grundlage wird die Open-Source Version des Programms „soapUI“ von der Firma „eviware“ genutzt, die getrennt zum gelieferten Projekt installiert werden muss.

Wer eine erweiterte SOAP-Umgebung nutzen möchte, kann die kostenpflichtige „soapUI-Pro“ Version benutzen.

3.1 Download und Installation der soapUI Umgebung

Die Version der soapUI für die Testsuite ist V2.5.1, die von der Homepage www.soapui.org heruntergeladen werden kann.


http://www.soapui.org/


Lokalisieren Sie dort den Downloadbereich und laden Sie die geeignete Version für Ihr Betriebssystem herunter. Zum Download werden Sie auf die Projektseite bei sourceforge.net weitergeleitet.

Wir empfehlen für Windows Betriebssysteme die „Installer Version“ herunterzuladen und zu installieren. (soapUI-2.5.1-installer.exe)Sie können aber auch, je nach Ihrem Betriebssystem, auf die anderen Versionen zum Download und zur Installation zurückgreifen.

Eine erfolgreiche Installation der soapUI ist Voraussetzung zur Nutzung des mitgelieferten Projektes.

3.2 Import des medExtendedServices SOAP-Projektes

Im Unterordner \soapUI-Projekt\ befindet sich die Datei medExtendedService-soapui-project.xml.

Bitte starten Sie die soapUI, gehen im Menü auf File -> Import Project und wählen oben genannte Datei aus und klicken dann auf Öffnen.

Es werden nun die SOAP-Requests und Testfälle importiert.Im Navigator der soapUI sollten folgende Einträge zu finden sein:



3.3 Anpassung der HOSTS-Datei

Die Endpunkte der veröffentlichen Services wurden mit dem Pseudo-Hostnamen medExtendedService versehen. Damit dieser Hostname aufgelöst werden kann, muss ein Eintrag in der Datei hosts des Betriebsystems ergänzt werden.

Bitte weisen Sie in Ihrer hosts Datei dem Host medExtendedService die IP-Adresse des Rechners zu, auf dem Sie die Serverkomponente betreiben.

Unter Windows XP finden Sie diese hosts Datei unter:C:\WINDOWS\system32\drivers\etc\hosts

Bei den meisten Linux bzw. UNIX Systemen unter:/etc/hosts

Beispieleintrag:

In der letzten Zeile des Beispiels wurde dem Pseudohostnamen die IP-Adresse 192.168.99.100 zugeordnet. Dies ist das System, auf dem die Serverkomponente medExtendedService.exe betrieben wird.

Weiterhin besteht die Möglichkeit, den Hostnamen medExtendedService von einem DNS-Server auflösen zu lassen.

Für permanente Änderungen können die Endpunkte auch innerhalb des soapUI-Werkzeugs editiert werden.


# hosts#127.0.0.1 localhost

# eHealth-Erweiterung192.168.99.100 medExtendedService


Sollten Sie den Service auf dem gleichen System starten, auf dem auch die soapUI läuft, müssen Sie darauf achten, dass Sie in der hosts Datei dem Namen „medExtendedService“ die IP-Adresse 127.0.0.1 zuweisen. Nun dürfen die Requests jedoch nicht mehr SSL-verschlüsselt werden, die Endpunkte müssen daher mit dem Protokoll HTTP statt mit HTTPS adressiert werden.



4 Arbeiten mit dem soapUI Projekt

Nachdem Sie nun die soapUI erfolgreich installiert und das Projekt erfolgreich importiert haben, können nun die ersten Tests durchgeführt werden.

4.1 Starten des medExtendedService

Starten Sie bitte den Service wie in der Dokumentation beschrieben.Wichtig ist, dass Sie wissen, auf welchem System unter welcher IP-Nummer der Service läuft und prüfen Sie bitte den richtigen Eintrag in der hosts Datei, wie im letzten Kapitel beschrieben.

Schließen Sie ein Terminal an und prüfen Sie, ob das Terminal erfolgreich erkannt und integriert wird.

4.2 Durchführen der Standardtestfälle

Halten Sie eine Krankenversichertenkarte (KVK) und eine elektronische Gesundheitskarte (eGK) bereit, um diese Tests durchzuführen.

In diesem Projekt sind 4 Standard-Testfälle definiert, die nun durchgegangen werden.



4.2.1 Lesen der KVK

Stecken Sie die KVK in das Terminal. Diese wird nun aktiviert, was durch ein Symbol auf dem Terminaldisplay angezeigt wird.

Klicken Sie doppelt auf ReadKVK Testcase. Folgendes Bild erscheint nun:

Starten Sie bitte den Testfall durch Klicken von .Der Testfall sollte ohne Fehler durchlaufen:



Doppelklick auf den SOAP-Request ReadKVK liefert den erfolgreichen Response:

Dort finden sich im Tag <n:KVK> die BASE64 kodierten KVK Daten.

Beispiel KVK Daten:

Base64 – KVK Daten Dekodiert – Hex - ASN1 YIGLgApBT0sgQmVybGlugQc0MjEyMDU5jwUyNDEwMYIMOTg3NjU0MzIxMDEygwQxMjM0kAExhANEci6FD3NjaHdhcnplIEJhbGtlboYDbWVkhwZNfWxsZXKICDI1MDYxOTgyiQ9Lb25yYWQtWnVzZS1TdHKLBTM2MjUxjAhIZXJzZmVsZI0EMTIwM44BDQ==

60818B800A414F4B204265726C696E8107343231323035398F053234313031820C393837363534333231303132830431323334900131840344722E850F7363687761727A652042616C6B656E86036D656487064D7D6C6C657288083235303631393832890F4B6F6E7261642D5A7573652D5374728B0533363235318C084865727366656C648D04313230338E010D



4.2.2 Lesen der eGK

Stecken Sie die eGK in das Terminal, um diese automatisch zu aktivieren.Klicken Sie doppelt auf ReadEGK Testcase. Folgendes Bild erscheint nun:

Starten Sie bitte den Testfall durch Klicken von .Der Testfall sollte ohne Fehler durchlaufen:



Doppelklick auf ReadVSD – Request 1 sollte die erfolgreiche Antwort zeigen:

Dort finden sich in den Tags: <n:Versichertendaten>, <n:Versicherungsdaten> und <n:GeschuetzteDaten>

die BASE64 kodierten eGK Informationen.

Beispiel eGK Daten:

TAG Base64 – eGK Daten Dekodiert - XMLVersichertendaten

PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iSVNPLTg4NTktMTUiPz4NCjxWU0Q6VUNfUGVyc29lbmxpY2hlVmVyc2ljaGVydGVuZGF0ZW5YTUwgQ0RNX1ZFUlNJT049IjMuMC4wIiB4bWxuczpWU0Q9Imh0dHA6Ly93cy5nZW1hdGlrLmRlL2ZhL3ZzZHMvdWNfUGVyc29lbmxpY2hlVmVyc2ljaGVydGVuZGF0ZW5YTUwvdjMuMCI+DQoJPFZTRDpWZXJzaWNoZXJ0ZXI+DQoJCTxWU0Q6VmVyc2ljaGVydGVuX0lEPkExMjM0NTY3ODM8L1ZTRDpWZXJzaWNoZXJ0ZW5fSUQ+DQoJCTxWU0Q6UGVyc29uPg0KCQkJPFZTRDpHZWJ1cnRzZGF0dW0+MTk3MDAxMDE8L1ZTRDpHZWJ1cnRzZGF0dW0+DQoJCQk8VlNEOlZvcm5hbWU+U2FuZHJh

<?xml version="1.0" encoding="ISO-8859-15"?>

<VSD:UC_PersoenlicheVersichertendatenXML CDM_VERSION="3.0.0" xmlns:VSD="http://ws.gematik.de/fa/vsds/uc_PersoenlicheVersichertendatenXML/v3.0">

<VSD:Versicherter>

<VSD:Versicherten_ID>A123456783</VSD:Versicherten_ID>

<VSD:Person>

<VSD:Geburtsdatum>19700101</VSD:Geburtsdatum>

<VSD:Vorname>Sandra</VSD:Vorname><VSD:Nachname>Koch</VSD:Nachname



PC9WU0Q6Vm9ybmFtZT4NCgkJCTxWU0Q6TmFjaG5hbWU+S29jaDwvVlNEOk5hY2huYW1lPg0KCQkJPFZTRDpHZXNjaGxlY2h0PjI8L1ZTRDpHZXNjaGxlY2h0Pg0KCQkJPFZTRDpTdHJhc3NlbkFkcmVzc2U+DQoJCQkJPFZTRDpQb3N0bGVpdHphaGw+MTAxMTc8L1ZTRDpQb3N0bGVpdHphaGw+DQoJCQkJPFZTRDpPcnQ+QmVybGluPC9WU0Q6T3J0Pg0KCQkJCTxWU0Q6TGFuZD4NCgkJCQkJPFZTRDpXb2huc2l0emxhZW5kZXJjb2RlPkRFPC9WU0Q6V29obnNpdHpsYWVuZGVyY29kZT4NCgkJCQk8L1ZTRDpMYW5kPg0KCQkJCTxWU0Q6U3RyYXNzZT5GcmllZHJpY2hzdHJh32U8L1ZTRDpTdHJhc3NlPg0KCQkJCTxWU0Q6SGF1c251bW1lcj4xMzY8L1ZTRDpIYXVzbnVtbWVyPg0KCQkJPC9WU0Q6U3RyYXNzZW5BZHJlc3NlPg0KCQk8L1ZTRDpQZXJzb24+DQoJPC9WU0Q6VmVyc2ljaGVydGVyPg0KPC9WU0Q6VUNfUGVyc29lbmxpY2hlVmVyc2ljaGVydGVuZGF0ZW5YTUw+DQo=

<VSD:Geschlecht>2</VSD:Geschlecht><VSD:StrassenAdresse>

<VSD:Postleitzahl>10117</VSD:Postleitzahl>

<VSD:Ort>Berlin</VSD:Ort><VSD:Land>

<VSD:Wohnsitzlaendercode>DE</VSD:Wohnsitzlaendercode>

</VSD:Land>

<VSD:Strasse>Friedrichstraße</VSD:Strasse>

<VSD:Hausnummer>136</VSD:Hausnummer></VSD:StrassenAdresse>

</VSD:Person></VSD:Versicherter>

</VSD:UC_PersoenlicheVersichertendatenXML>

Versicherungsdaten

PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iSVNPLTg4NTktMTUiPz4NCjxWU0Q6VUNfYWxsZ2VtZWluZVZlcnNpY2hlcnVuZ3NkYXRlblhNTCBDRE1fVkVSU0lPTj0iMy4wLjAiIHhtbG5zOlZTRD0iaHR0cDovL3dzLmdlbWF0aWsuZGUvZmEvdnNkcy91Y19hbGxnZW1laW5lVmVyc2ljaGVydW5nc2RhdGVuWE1ML3YzLjAiPg0KCTxWU0Q6VmVyc2ljaGVydGVyPg0KCQk8VlNEOlZlcnNpY2hlcnVuZ3NzY2h1dHo+DQoJCQk8VlNEOkJlZ2lubj4yMDA3MDEwMTwvVlNEOkJlZ2lubj4NCgkJCTxWU0Q6S29zdGVudHJhZWdlcj4NCgkJCQk8VlNEOktvc3RlbnRyYWVnZXJrZW5udW5nPjEyMzQ1Njc4OTwvVlNEOktvc3RlbnRyYWVnZXJrZW5udW5nPg0KCQkJCTxWU0Q6S29zdGVudHJhZWdlcmxhZW5kZXJjb2RlPkRFPC9WU0Q6S29zdGVudHJhZWdlcmxhZW5kZXJjb2RlPg0KCQkJCTxWU0Q6TmFtZT5nZW1hdGlrPC9WU0Q6TmFtZT4NCgkJCTwvVlNEOktvc3RlbnRyYWVnZXI+DQoJCTwvVlNEOlZlcnNpY2hlcnVuZ3NzY2h1dHo+DQoJCTxWU0Q6WnVzYXR6aW5mb3M+DQoJCQk8VlNEOlp1c2F0emluZm9zR0tWPg0KCQkJCTxWU0Q6UmVjaHRza3JlaXM+OTwvVlNEOlJlY2h0c2tyZWlzPg0KCQkJCTxWU0Q6VmVyc2ljaGVydGVuYXJ0PjE8L1ZTRDpWZXJzaWNoZXJ0ZW5hcnQ+DQoJCQkJPFZTRDpWZXJzaWNoZXJ0ZW5zdGF0dXNfUlNBPjA8L1ZTRDpWZXJzaWNoZXJ0ZW5zdGF0dXNfUlNBPg0KCQkJCTxWU0Q6WnVzYXR6aW5mb3NfQWJyZWNobnVuZ19HS1Y+DQoJCQkJCTxWU0Q6S29zdGVuZXJzdGF0dHVuZ19hbWJ1bGFudD4wPC9WU0Q6S29zdGVuZXJzdGF0dHVuZ19hbWJ1bGFudD4NCgkJCQkJPFZTRDpLb3N0ZW5lcnN0YXR0dW5nX3N0YXRpb25hZXI+MDwvVlNEOktvc3RlbmVyc3RhdHR1bmdfc3RhdGlvbmFlcj4NCgkJCQkJPFZTRDpXT1A+NzI8L1ZTRDpXT1A+DQoJCQkJPC9WU0Q6WnVzYXR6aW5mb3NfQWJyZWNobnVuZ19HS1Y+DQoJCQk8L1ZTRDpadXNhdHppbmZvc0dLVj4NCgkJPC9WU0Q6WnVzYXR6aW5mb3M+DQoJPC9WU0Q6VmVyc2ljaGVydGVyPg0KPC9WU0Q6VUNfYWxsZ2VtZ

<?xml version="1.0" encoding="ISO-8859-15"?><VSD:UC_allgemeineVersicherungsdatenXML CDM_VERSION="3.0.0" xmlns:VSD="http://ws.gematik.de/fa/vsds/uc_allgemeineVersicherungsdatenXML/v3.0">

<VSD:Versicherter><VSD:Versicherungsschutz>

<VSD:Beginn>20070101</VSD:Beginn><VSD:Kostentraeger>

<VSD:Kostentraegerkennung>123456789</VSD:Kostentraegerkennung>

<VSD:Kostentraegerlaendercode>DE</VSD:Kostentraegerlaendercode>

<VSD:Name>gematik</VSD:Name></VSD:Kostentraeger>

</VSD:Versicherungsschutz><VSD:Zusatzinfos>

<VSD:ZusatzinfosGKV><VSD:Rechtskreis>9</VSD:Rechtskreis>

<VSD:Versichertenart>1</VSD:Versichertenart>

<VSD:Versichertenstatus_RSA>0</VSD:Versichertenstatus_RSA>

<VSD:Zusatzinfos_Abrechnung_GKV>

<VSD:Kostenerstattung_ambulant>0</VSD:Kostenerstattung_ambulant>

<VSD:Kostenerstattung_stationaer>0</VSD:Kostenerstattung_stationaer>

<VSD:WOP>72</VSD:WOP></VSD:Zusatzinfos_Abrechnung_GKV>

</VSD:ZusatzinfosGKV></VSD:Zusatzinfos>

</VSD:Versicherter></VSD:UC_allgemeineVersicherungsdatenXML>



WluZVZlcnNpY2hlcnVuZ3NkYXRlblhNTD4NCg==

GeschuetzteDaten

PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iSVNPLTg4NTktMTUiPz4NCjxWU0Q6VUNfR2VzY2h1ZXR6dGVWZXJzaWNoZXJ0ZW5kYXRlblhNTCBDRE1fVkVSU0lPTj0iMy4wLjAiIHhtbG5zOlZTRD0iaHR0cDovL3dzLmdlbWF0aWsuZGUvZmEvdnNkcy91Y19nZXNjaHVldHp0ZVZlcnNpY2hlcnRlbmRhdGVuWE1ML3YzLjAiPg0KCTxWU0Q6WnV6YWhsdW5nc3N0YXR1cz4NCgkJPFZTRDpTdGF0dXM+MDwvVlNEOlN0YXR1cz4NCgk8L1ZTRDpadXphaGx1bmdzc3RhdHVzPg0KPC9WU0Q6VUNfR2VzY2h1ZXR6dGVWZXJzaWNoZXJ0ZW5kYXRlblhNTD4NCg==

<?xml version="1.0" encoding="ISO-8859-15"?><VSD:UC_GeschuetzteVersichertendatenXML CDM_VERSION="3.0.0" xmlns:VSD="http://ws.gematik.de/fa/vsds/uc_geschuetzteVersichertendatenXML/v3.0">

<VSD:Zuzahlungsstatus>

<VSD:Status>0</VSD:Status>

</VSD:Zuzahlungsstatus>

</VSD:UC_GeschuetzteVersichertendatenXML>

4.2.3 Lesen gespeicherter Karten eines medMobile

Um gespeicherte Karten eines mobilen Terminals auszulesen, muss eine Karte zunächst mit Hilfe des Kommandos RequestCard angefordert werden. Dazu ist eine Authentisierung am medMobile notwendig. Diese wird, wenn sie notwendig ist, transparent von medExtendedService durchgeführt. Nun kann die Karte wie gewohnt ausgelesen werden. Die Antworten enthalten das optionale Element <mobileStatus>, hier ist das Auslesedatum und die Zulassungsnummer enthalten. Um die nächste gespeicherte Karte auszulesen, muss die aktuelle Karte ausgeworfen und gelöscht werden. Dies wird mittels EjectCard gelöst. Das optionale Element <Erase> erzwingt das notwendige Löschen einer gespeicherten Karte.In der folgenden Abbildung ist ein Ablauf als soapUI Testfall dargestellt:



4.2.4 Lesen der eGK – erweiterte Requests

Um Ihnen noch weitere Möglichkeiten der Nutzung der einzelnen SOAP-Requests zu zeigen, befindet sich in den Standardtestfällen ein erweitertes Beispiel.

Hier können Sie die komfortable Steuerung des Kartenlesers durch „RequestCard“ und „EjectCard“ sehen, wie auch die Nutzung von mehreren Kartenterminals an einem medExtendedService.



4.3 Weitere Testfälle

Neben den Standardtestfällen befinden sich für die einzelnen Services jeweils eigene Testfälle.Diese können nach Belieben angepasst oder verändert werden.

Natürlich können Sie auch selber eigene Testfälle entwerfen oder vorhandene umschreiben oder erweitern.Dieses soapUI Projekt soll nur die grundlegenden Funktionen der Nutzung unseres medExtendedService zeigen.

Weitere Hilfe zur soapUI entnehmen Sie bitte der ausführlichen Dokumentation, die unter dem Menüpunkt Help zu finden ist.



5 Testclient „medDump“

Zusätzlich zu dem oben vorgestellten Testfällen, wird auch ein Testclient mitgeliefert, der mit dem medExtendedService kommuniziert. Dieser Testclient liegt als Binary für Windows und Linux Betriebssysteme und als Source vor. Er basiert, wie der medExtendedService selbst, auf dem Framework Axis2/C. Für medDump wird eine unangepasste Version von Axis2/C verwendet. Die Benutzung von medDump wird im Installations- und Anwenderhandbuch genau erläutert.

5.1 Überblick

Das Tool medDump ist ein Ausleseprogramm für die eGK bzw. KVK. Da die Serverkomponenten und damit die Terminals nicht lokal am PC angeschlossen sein müssen, ist es möglich mit medDump auch auf entfernte Services zuzugreifen, die Verbindung wird dabei SSL/TLS verschlüsselt. Die Sourcen von medDump bestehen aus zwei Teilen, zum einen wurde ein Großteil der Sourcen mit Hilfe des Tools WSDL2C aus dem Axis2/C Framework generiert, zum anderen gibt es die Ablauflogik von medDump, die die generierten Sourcen als Grundlage benutzt. Die generierten Sourcen befinden sich im Verzeichnis \medDump\src\generated.Neben dem Axis2/C Framework existieren diverse andere Frameworks, die es ermöglichen auf einfache Art und Weise SOAP-Requests zu verschicken und zu verarbeiten. Alle diese Tools arbeiten nach demselben Prinzip:

• Die WSDLs und Schemata werden eingelesen und es wird Code generiert, der es erlaubt, auf einer hohen Ebene Methoden eines WebService aufzurufen.

• Die in den Schemata beschriebenen Datenstrukturen werden in Datenstrukturen der verwendeten Programmiersprache umgewandelt, um ein einfaches Arbeiten zu ermöglichen.

In der folgenden Tabelle sind einige zusätzliche Frameworks für verschiedene Programmiersprachen aufgeführt.

Programmiersprache Name LinkC/C++ gsoap http://www.cs.fsu.edu/~engelen/soap.htmlJava Axis2/Java http://ws.apache.org/axis2/Java CXF (früher

XFire)http://cxf.apache.org/

Perl SOAP::WSDL http://sourceforge.net/projects/soap-wsdl/Div. .NET

Frameworkhttp://msdn.microsoft.com/de-de/default.aspx


http://msdn.microsoft.com/de-de/default.aspx

http://msdn.microsoft.com/de-de/default.aspx

http://sourceforge.net/projects/soap-wsdl/

http://cxf.apache.org/

http://ws.apache.org/axis2/

http://www.cs.fsu.edu/~engelen/soap.html


5.2 Programmablauf

In diesem Abschnitt soll der zur Verfügung gestellte Source-Code für medDump vorgestellt werden. Der Source-Code zeichnet sich durch eine flache Struktur aus, um einfache Lesbarkeit zu erlauben, ohne in der Datei springen zu müssen.Der Code arbeitet drei Schritte ab:

1.) Initialisierung / Einlesen der Parameter2.) Kommunikation mit medExtendedService3.) Freigabe benutzter Ressourcen

Sollte während der Verarbeitung ein Fehler aufgetreten sein, wird ein entsprechender Rückgabewert geliefert.Eine Auflistung möglicher Fehler- und Gutfälle befindet sich im Anwenderhandbuch.

Um beispielsweise aus Java heraus medDump zu starten und die Rückgabe auszuwerten ist folgender Code möglich:

Der generierte Code bietet drei wesentliche Funktionen:

1. Erzeugen von SOAP-Requests durch Füllen von Datenstrukturen, 2. Auslesen von SOAP-Responses über Abfragen von Datenstrukturen 3. Verschicken/Empfangen der SOAP-Nachrichten.

Diese drei Funktionalitäten werden nun am Beispiel von medDump vorgestellt.

1. Verschicken/Empfangen von SOAP-Nachrichten

Um die SOAP-Requests eines WebService aufzurufen, muss zunächst eine sog. axis2_stub_t Struktur erzeugt werden. Dazu wird eine Funktion der Formaxis2_stub_create_<ServiceName>(…) aufgerufen. Dies ist in medDump.c folgendermaßen realisiert:


Process proc = Runtime.getRuntime().exec(medDumpCmdLine);int returnValue = proc.waitFor();

// create environment for axis2c frameworkenv = axutil_env_create_all("./medDump.log", AXIS2_LOG_LEVEL_ERROR);

// every axis2c tool needs a axis2c installation (for library resolution / configuration)client_home = AXIS2_GETENV("AXIS2C_HOME");… // appends service path to base address addressCardService = addToBaseStub(base, "/services/CardService");

// creating stubs for each used servicecardstub = axis2_stub_create_CardService(env, client_home,

addressCardService);


Das eigentliche Verschicken einer SOAP-Nachricht wird über einen Aufruf der Form axis2_stub_op_<ServiceName>_<OperationName> realisiert. Die Rückgabe ist im Gutfall der SOAP-Response der Nachricht. Dies wird in medDump.c beispielsweise so realisiert:

Um den von Axis2/C intern verwalteten Netzwerk-Socket wieder freizugeben, muss die axis2_stub_t Struktur wieder freigeben werden. Dies geschieht mit Hilfe von axis2_stub_free().

2. Erzeugen von SOAP-Requests:

Request-Datenstrukturen die an die entsprechende axis2_stup_op… Funktionen übergeben werden müssen, werden zunächst über Funktionen der Form adb_<RequestName>_create() erzeugt.

Notwendige Elemente im SOAP-Request können über verschiedene Set-Funktionen erzeugt werden:

3. Auslesen von SOAP-Responses:

Response-Datenstrukturen, werden von axis2_stup_op…() Funktionen zurückgeliefert und können mit entsprechenden Get-Funktionen ausgewertet werden. Im Falle von komplexen Antwortstrukturen sind unter Umständen verschachtelte Abfragen notwendig. Folgendes Beispiel ist in medDump.c enthalten:


adb_GetCards_t* getCards = adb_GetCards_create(env);adb_GetCardsResponse_t* resp = NULL;…// call GetCards-Method of cardservice endpoint resp = axis2_stub_op_CardService_GetCards(cardstub, env, getCards);

eject = adb_EjectCard_create(env);adb_EjectCard_set_CardHandle(eject, env, ejectCardHandle);ejResp = axis2_stub_op_CardService_EjectCard(cardstub, env, eject);ejectresult = adb_Status_type0_get_Result(

adb_EjectCardResponse_get_Status(ejResp, env), env);

adb_CardInfoErrType_t * card = adb_Cards_type0_get_Card_at(cards, env, 0);int ctype_size = adb_CardInfoErrType_sizeof_CardType(card, env);// iterate over all given types of the cardfor (j = 0; j < ctype_size; j++) { adb_CardTypeType_t * type = adb_CardInfoErrType_get_CardType_at(card, env, j); // get string representation of card type axis2_char_t * typeString = adb_CardTypeType_get_CardTypeType(type, env); // if a cardtype of EHC was found going on dumping carddata if (strcmp(typeString, EGK) == 0) {

// found EHCaxis2_char_t * handle = adb_CardHandleType_get_CardHandleType(

adb_CardInfoErrType_get_CardHandle(card, env), env); … }}


In der folgenden Abbildung ist ein schematischer Ablauf eines Lesevorgangs einer eGK abgebildet:

sd Use Case Model

Actor1

cardstubm edDum p vsdstubkvkstub adb

Generie rter Code

m ain(in t, char**) :int

axis2_stub_create_CardService() :axis2_stub_t*

axis2_stub_create_VSDService() :axis2_stub_t*

axis2_stub_create_KVKService() :axis2_stub_t*

adb_GetCards_create() :adb_GetCards_t*

axis2_stub_op_CardService_GetCards() :adb_GetCardsResponse_t*

axis2_stub_free()

adb_GetCardsResponse_get_Sta tus() :adb_Status_type0_t*

adb_Sta tus_type0_get_Resu l t() :char *

adb_GetCardsResponse_get_Cards() :adb_Cards_type0_t *

adb_Cards_type0_sizeof_Card() :int

adb_Cards_type0_get_Card_at() :adb_Card InfoErrT ype_t *

adb_ReadVSD_create() :adb_ReadVSD_t*

axis2_stub_op_VSDService_ReadVSD() :adb_ReadVSDResponse_t*

adb_ReadVSDResponse_get_VSD_XM L() :adb_VSD_XM LT ype_t*

adb_VSD_XM LT ype_get_Versichertendaten() :axuti l_base64_b inary_t *

wri teT oFi le(axuti l_base64_binary_t*, axuti l_env_t*, char*)

adb_VSD_XM LT ype_get_Versicherungsdaten() :axuti l_base64_binary_t *

wri teT oFi le(axuti l_base64_binary_t*, axuti l_env_t*, char*)

axis2_stub_free()

axis2_stub_free()

5.3 Kompilieren von „medDump“

Die Win32-Binärversion des Tools medDump wurde mit Hilfe eines Visual Studio 2008 Projektes erstellt. Die Linux-Binärversion wurde mit Hilfe eines Makefiles und gcc (Version 4.1.2) erzeugt. Ein Makefile das es erlaubt, medDump.exe mit Hilfe des Microsoft C Compilers zu erzeugen, befindet sich im src-Verzeichnis von medDump. Im Auslieferungszustand benutzt das Makefile die mitgelieferten Header-Dateien. Diese enthalten kleine Anpassungen an Präprozessordefinitionen. Als Importbibliotheken sind die von Hypercom mit OpenSSL-Unterstützung erstellten Fassungen angegeben (basierend auf Axis2/C 1.5.0). Die zur Verfügung gestellten



Bibliotheken von Axis2/C sind unter Linux mit ./configure --enable-openssl bzw. unter Windows dem Präprozessorschalter ENABLE_SSL = 1 erzeugt worden. Um in einer IDE ein Projekt zum Kompilieren von medDump aufzusetzen, genügt es, die gesamten Sourcen dort einzufügen und die Header-Dateien und die Bibliotheken axutil, axiom und axis2_engine im Suchpfad des Compilers anzugeben. Das entstandene Executable ist nur in einer korrekt eingerichteten Axis2/C Installation lauffähig, wie sie beispielsweise im Ordner \medDump\bin vorhanden ist.


medExtendedServices - medline-online.com · Die Version der soapUI für die Testsuite ist V2.5.1,...

Documents

Transcript of medExtendedServices - medline-online.com · Die Version der soapUI für die Testsuite ist V2.5.1,...