Auszug aus Kapitel IV: Die Abwicklung des Zahlungsverkehrs
privater Kunden auf der Basis eines standardisierten Nachrichtenaustausches
Autor: Paul Mausberg
Die verwendete Kommunikation der Fallstudie (5.2)
Die Kommunikation bildet einen Schwerpunkt in diesem Kapitel, da in diesem Bereich für die Gruppe der privaten Kunden keine kommerziell vertriebenen Produkte für den benötigten Kommunikationsaufbau existieren. Aus diesem Grunde wurden unterschiedliche Arten der Kommunikation getestet, wobei sich nur eine als nicht gangbar erwies.
Deutlich herauszustellen ist, dass die Kommunikation für den Kunden transparent gestaltet werden muss, da sie für ihn irrelevant ist. Die unterschiedlichen Versuche dienten nur dem Zwecke der Evaluation von verschiedenen, bereits bestehenden Kommunikationswegen.
Im Folgenden werden die unterschiedlichen, im Projekt verwendeten Arten von Datenflüssen skizziert. Dabei werden die Vorgänge dargestellt, die in der in Bild IV - 13 dargestellten Kommunikationsschicht ablaufen. Alle Aktivitäten, die die Mail-Objekte durchlaufen, sind in Richtung des jeweiligen kontoführenden Kreditinstitutes aufgezählt. Es ist aber selbstverständlich, dass diese Wege bidirektional zu nutzen sind und die Aktivitäten sich damit umkehren.
Bild IV - 13: Kommunikation
Aus Gründen der Klarheit wurde auf eine Darstellung der Kundensoftware, die neben der Kontendatenverwaltung für die Erstellung und den Empfang von Edifact-Nachrichten zuständig ist, in den Abbildungen verzichtet. Bei allen dargestellten Kommunikationswegen beginnt auf der Kundenseite der Vorgang mit der Generierung eines Payord, der dann der jeweiligen Kommunikationssoftware zugeleitet wird, bzw. endet der Vorgang mit dem Empfang von Creadv und Debadv und deren Verarbeitung in der Telebankingsoftware.
Um Wiederholungen zu vermeiden, werden diese Vorgänge als gegeben vorausgesetzt und nicht mehr jedesmal erwähnt.
Zentrales Rechnersystem HSG - SKA
Auf einer Personal Workstation (PWS) wird durch die Software Lotus Notes eine Mail generiert, welche die Edifact-Nachricht zum Inhalt hat. Auf dem zentralen Rechnersystem der HSG wird das Mail-Objekt auf Simple Mail Transport Protokoll (SMTP) umgesetzt. In einem weiteren Schritt wird auf einem SUN-Rechner innerhalb des selben Systems durch den Konverter "PP" die SMTP-Mail auf eine X.400 Mail konvertiert. Von dort gelangt sie zu Switch, das den ersten Message Transfer Agent (MTA) in diesem Message Handling System (MHS) darstellt. Da das Mail-Objekt hier von SMTP in das X.400 Protokoll konvertiert wird, existiert kein User Agent (UA) nach der X.400 Definition.
Vom MTA Switch wird das Mail-Objekt über den MTA Arcom an den MTA Swisscos weitergereicht, ohne dass eine Veränderung der Mail erfolgt.
Man kann dieses MHS auch unter dem Gesichtspunkt der Verwaltung betrachten. Hier fungiert Arcom als Administrative Management Domain (ADMD) und Switch sowie Swisscos als Private Management Domain (PRMD).
Bild IV - 14: Kommunikation: Zentrales Rechnersystem HSG zur SKA
Von Swisscos wird die Mail auf das Odette File Transfer Protokoll (OFTP) umgewandelt und dann an die Schweizerische Kreditanstalt gesendet. Zur Konvertierung wird bei der Swisscos die Software XLATE-PC als Konverter eingesetzt. Die Übertragung zur SKA erfolgt über das X.25-Netz der schweizerischen PTT Telecom. Bei der Swisscos endet der X.400 Bereich. Die SKA nimmt Aufträge auf dem Standard von UN/Edifact zur Zeit nur über die Swisscos an.
Ein nicht lösbares Problem lag in der Konvertierung der Mail von SMTP zu X.400. Einige Angaben, die im Header der SMTP-Mail enthalten waren, konnten nicht in den Header der X.400-Mail übernommen werden. Diese Informationen wurden daher als Body Part 1 im Mail-Objekt abgelegt. Der ursprüngliche Body Part 1, in dem die eigentliche UN/Edifact-Nachricht enthalten war, wurde zum Body Part 2. Dies erwies sich als nicht akzeptabel, da eine Edifact-Nachricht immer im ersten Body Part einer Mail beinhaltet sein muss. Das System bei der Swisscos, das die Konvertierung von der X.400-Mail auf OFTP vornehmen sollte, konnte die Nachricht nicht richtig einlesen. Dieser Weg vom Kunden zur SKA ist nicht gangbar.
Auch bei der Nachrichtenübermittlung in umgekehrter Richtung entstanden Probleme. Bei der Entgegennahme der X.400-Mail und der Konvertierung in SMTP-Mail wurden Records ab einer Länge von 1000 Zeichen abgeschnitten und unvollständig abgeliefert. Dieses Problem konnte insoweit behoben werden, dass bei der Umwandlung von OFTP- in X.400-Mail vom System der Swisscos jeweils ein carriage return nach 80 Zeichen eingefügt wurde. Aufgrund dieser Änderung konnten Mails ohne Schwierigkeiten auf SMTP umgewandelt werden.
SAS-System an der HSG - SKA
Aufgrund der Probleme mit der vorher beschriebenen Vorgehensweise wird ein anderer Weg beschritten: Hierbei wird die Mail auf dem SAS-System der Hochschule St. Gallen erstellt. Das SAS-System fungiert aus der funktionalen X.400-Sicht sowohl als User Agent (UA) als auch als MTA. Der Zugang zu diesem System erfolgte über das Kommunikationsprogramm Dynacomm unter Windows, das eine Terminalverbindung aufbaut. Auf dem SAS-System kann eine X.400-Mail erstellt werden, die ohne Konvertierung an den MTA Switch weitergereicht wird. Die Problematik der SMTP/X.400 Umwandlung wird umgangen. Vom SAS-System bis zum MTA der Swisscos besteht hier ein X.400 konformes Message Transfer System (MTS).
Bild IV - 15: Kommunikation: SAS-System HSG zur SKA
Ab dem MTA Switch nimmt die Mail denselben Weg, wie er im vorhergehenden Abschnitt beschrieben wurde.
Bei der Übermittlung von Mail-Objekten an den Kunden gab es keine Schwierigkeiten. Für den produktiven Betrieb wurde von dieser Lösung Abstand genommen, da es sich schwierig gestaltet, das SAS-System mit der Telebankingsoftware des Kunden, auf der die Mail-Objekte erzeugt werden, zu verbinden. Ziel ist es, die Kommunikation für den Kunden möglichst benutzerfreundlich zu gestalten, d.h. eine automatische Versendung der Mail zu realisieren.
SAS-System an der HSG - SBV
Dieser Datenfluss ähnelt dem unter Abschnitt "SAS-System an der HSG - SKA" beschriebenen, da bis zur Übergabe der Mail-Objekte an den Arcom-Message Transfer Agent kein Unterschied auftritt. Von dort wird es an den MTA des Schweizerischen Bankvereins übergeben, der die Mail zur Weiterverarbeitung in das Zahlungsverkehrssystem einspeist.
Bei diesem Weg trat ein Problem auf, das auch bei den anderen Versuchen, den Schweizerischen Bankverein in den Nachrichtenfluss einzubinden, nicht behoben werden konnte. Die Mail-Objekte an den Bankverein wurden mit einer X.400-Adresse versehen. Diese gelangten zum MTA des SBV und wurden von dort ordnungsgemäss in die richtige Mailbox der Zahlungsverkehrsabteilung eingespeist. In der Mailbox des SBV waren jedoch nicht die richtigen Einstellungen zur internen Weiterleitung der Mail in das Zahlungsverkehrssystem vorhanden. Die UN/Edifact-Nachricht konnte somit intern nicht weitergeleitet und verarbeitet werden.
Bild IV - 16: Kommunikation: SAS-System HSG zum SBV
Der umgekehrte Weg vom Bankverein zum Kunden war ohne Probleme möglich. Es wurde ein Test-Creadv zugesendet, der auch verarbeitet werden konnte.
Der Kontakt mit dem Schweizerischen Bankverein beschränkte sich, aufgrund der Schwierigkeiten, nur auf den Testbetrieb des Projektes. Es wurden keine produktiven Edifact-Nachrichten versendet.
CompuServe - SKA
Bei diesem Übertragungsweg wird die UN/Edifact-Nachricht, die von der Client-Software (eine genauere Beschreibung findet sich im Abschnitt Kunden, S. 218) in ein Datei geschrieben wird, durch die Software "CompuServe Information Manager" weitergeleitet. Auf der Personal Workstation, auf der sich dieses Kommunikationsprogramm befindet, wird die Mail Offline vorbereitet. Bei der Adressierung kann aus verschiedenen Netzwerksystemen ausgewählt werden. Um die Swisscos anzusprechen, wurde deren Internet-Adresse benutzt. Das Mail-Objekt wird mit dem proprietären Protokoll "Quick BPlus" auf einer Modemwählleitung an CompuServe übermittelt. Von hier aus wird sie an die Zentrale von CompuServe in Columbus, Ohio, USA weitergeleitet. Dort wird der Header der Mail konvertiert und an das Internet-Format angepasst. Die Zentrale von CompuServe speist das Mail-Objekt dann über einen Gateway in das Internet ein, wo es dann zur Swisscos gelangt. Dort wird die Mail vom Internetprotokoll auf das OFTP-Protokoll umgewandelt und an die SKA weitergeleitet. Der letzte Schritt erfolgt analog den oben beschriebenen Vorgängen.
Bild IV - 17: Kommunikation: CompuServe zur SKA
Ein Problem lag bei der Länge der übermittelten Records. Bei einer Länge von über 400 Zeichen konnte das Mail-Objekt nicht von CompuServe ausgeliefert werden. Nachdem vom Programm alle 80 Zeichen ein "carriage return" eingebaut wurde, konnte die Mail ohne Schwierigkeiten abgesandt werden. Beim Empfang von Informationen wurde dieses Problem von Seiten der Swisscos durch den Einbau von "carriage return" in die Nachricht ausgeräumt.
Dieser Konvertierungsdienst ist ein Beispiel für eine Funktion, die ein Mittler für den jeweiligen Empfänger erbringen kann.
IBM - SKA
Auf der Personal Workstation wurde die Software "Expedite Base Version 4.1, for Windows" der Firma Advantis installiert. Diese nimmt die UN/Edifact-Nachrichten, die von der Client-Software in einer Datei gespeichert werden, und überträgt diese über eine Modemwählleitung. Für diesen Filetransfer wird ein proprietäres Protokoll von IBM verwendet. Über die Modemleitung gelangt die Mail zum IBM Network. Dort wird sie in das SNA-Protokoll konvertiert und erhält einen SNA-Header, der nur für IBM-interne Zwecke dient, hinzugefügt. Die Mail an sich wird nicht verändert. Von hier gelangt sie mit dem Protokoll Systems Network Architekture (SNA) zum IBM Information Exchange. Hier findet die Adressumwandlung statt, wobei verschiedene Möglichkeiten der Weiterleitung bestehen.
Ein Weg führt über eine Bridge zur IBM Mail Exchange (IMX). Von dort aus kann das Mail-Objekt in das Internet, das X.400-Netz oder andere Netze, eingespeist werden.
Ein anderer Weg von der IBM Information Exchange (IE) führt über eine IE-OFTP-Bridge zum OFTP-Modul. Hier werden die Mails auf das OFTP-Protokoll umgewandelt und mittels einer X.25-Verbindung mit ODEX/370-Protokoll an die Swisscos weitergeleitet.
Bild IV - 18: Kommunikation: IBM zur SKA
Bei der Swisscos entfällt die Konvertierung, da die Mail schon das entsprechende Protokoll aufweist. Die Swisscos leitet die Mail zur Verarbeitung an die SKA weiter.
IBM - SBV
Bei dieser Variante ist der Mailfluss bis zum Eingang in den IBM Information Exchange genau so, wie im vorigen Beispiel beschrieben. Von dort gelangt die Mail über eine Bridge in den IBM Mail Exchange und wird dort auf das X.400 Protokoll konvertiert. Der IBM Mail Exchange fungiert hierbei als MTA nach der X.400-Norm. Von dort wird die Mail über den Arcom-MTA an den MTA des Schweizerischen Bankvereins weitergeleitet.
Bild IV - 19: Kommunikation: IBM zum SBV
Nach den Verwaltungseinteilungen nach der X.400-Norm agieren die IBM und Arcom als Administrative Management Domains und der SBV als Private Management Domain.
Vom IBM-MTA gelangt das Mail-Objekt in die entsprechende Mailbox des Bankvereins. Auch bei diesem Übertragungsweg wurde die Transaktion vom Bankverein nicht weiterverarbeitet, da die interne Weiterleitung nicht gewährleistet war. Das Problem, das bereits oben geschildert wurde, konnte durch die Wahl eines anderen Kommunikationsweges nicht behoben werden.
Telekurs - SBV
Bei diesem Übertragungsweg befindet sich eine Kommunikationssoftware auf der Personal Workstation des Kunden, die die Verbindung zur Telekurs aufnimmt. Diese Software kommt von der Firma Alprange Communications Ltd. Sie nimmt die von der Client-Software erstellte UN/Edifact-Nachricht als Bodypart in das von ihr erzeugte Mail-Objekt auf. Die Kommunikationssoftware nutzt eine Modem-Wählverbindung, um die Mail an die Telekurs zu versenden, dabei wird das Z-Modem-Protokoll verwendet. Das Telekurssystem Telos 400 konvertiert diese Mail zu einer X.400-Mail und sendet sie weiter. Das System fungiert hier sowohl als User Agent (UA) als auch als Message Transfer Agent (MTA). Von dort wird die Mail über den bekannten Weg via Arcom an den Bankverein weitergeleitet. Auch hier trat das Problem auf, dass die Nachricht intern nicht in das Zahlungsverkehrssystem weitergeleitet wurde.
Bild IV - 20: Kommunikation: Telekurs zum SBV
Aus der Sichtweise der Verwaltungen dienen hier Arcom als Administrative Management Domain und Telos 400 und der Bankverein als Private Management Domains.
