Öffentliche Kommunikationswege

E-Mail und EDI

Prinzipiell lassen sich per E-Mail beliebige Daten austauschen. Erste Wahl ist diese Kommunikationsform aber nicht, denn:

• einige Mailserver haben Größenbeschränkungen, so könnten große Anhänge einfach verloren gehen.
• E-Mails werden heute üblicherweise nicht mehr mit einer Empfangsbestätigung quittiert, man weiß also nie, ob die Daten auch angekommen sind.
• es gibt keine Garantie dafür, dass eine E-Mail schnell ans Ziel kommt – oder überhaupt.
• E-Mails selbst sind nicht gegen Fremdzugriff (Mitlesen oder Manipulation) gesichert. Natürlich kann man mit PGP & Co. zumindest die Inhalte verschlüsseln und/oder signieren, aber es gibt sicherere Wege.
• man ist den Launen der eingesetzten Mail-Software unterworfen (es gibt z.B. Mailserver, die ungefragt das Encoding angehängter Texte umstellen).
• Virenscanner und andere Sicherheitsvorkehrungen können einzelne Anhänge oder ganze E-Mails verschlucken oder blockieren.

Aufgrund dieser Mankos normaler E-Mails hat man AS1 (Applicability Statement 1) entwickelt, einen Standard zur gesicherten Übertragung von Geschäftsdaten per E-Mail. Allerdings hat sich dieser nie so wirklich durchgesetzt.

Nach wie vor werden Geschäftsdaten, auch im EDI-Umfeld, per E-Mail versendet. Eigentlich sollte man hier eher von „Halb-EDI“ sprechen, da in diesen Fällen meist an einem Ende ein Mensch sitzt. Beispielsweise werden Rechnungen automatisiert im PDF-Format erstellt und per Mail verschickt, oder Sachbearbeiter eines eher kleinen Kunden geben Bestellungen noch manuell in Excel-Dateien, die dann per Mail in die automatische Verarbeitung beim Lieferanten gespeist werden. Im echten EDI, wo Daten ohne Eingriff des Menschen von einem System zum anderen gehen, sollte E-Mail inzwischen ausgestorben sein.
Für die Prozesse, an denen noch Menschen beteiligt sind, sollte aber eine EDI-Software vorsichtshalber auch in der Lage sein, Daten per E-Mail zu versenden und zu empfangen. Vorzugsweise sollten dabei natürlich alle Standard-Protokolle (SMTP, POP3, IMAP) unterstützt werden.

FTP

Das File Transfer Protocol ist, wie der Name schon sagt, zur Übertragung von Dateien da – oft passiert dies über FileZilla oder den Browser. Dass man FTP auch an der Konsole (Unix Shell bzw. DOS Box unter Windows) vornehmen kann, dürfte auch bekannt sein. Wenden wir uns dem Einsatz im EDI-Umfeld zu.

FTP für EDI
Zunächst kann man mit FTP nur eines tun: Dateien übertragen. Man kann sich an einem FTP-Server anmelden und entweder mit „get Dateiname“ eine Datei herunterladen (bzw. mit „mget Dateimuster“ auch mehrere) oder mit „put Dateiname“ eine Datei hochladen (analog mit „mput Dateimuster“ mehrere). Anschließend liegt eine Datei vor – lokal oder auf dem Server.
Nun muss die EDI-Software in der Lage sein, die Datei aufzugreifen und zu verarbeiten. Im einfachsten Falle kann der Ablauf so aussehen:

• Ein System-Job (Cron Job unter Unix bzw. die Windows-Entsprechung) holt regelmäßig Dateien per FTP irgendwo ab oder der Partner sendet sie regelmäßig an Ihren FTP-Server. In beiden Fällen landen die Daten in lokalen Verzeichnissen.
• Die EDI-Software schaut wiederum regelmäßig in das entsprechende Verzeichnis, ob neue Dateien da sind.
• Wenn Dateien da sind, werden diese eingelesen und verarbeitet.

Und auch die andere Richtung könnte ähnlich laufen: Das Ergebnis der Verarbeitung im EDI-System wird evtl. wieder irgendwo in einem Verzeichnis abgelegt, damit ein weiterer System-Cron die Daten per FTP anderswo hinschicken kann bzw. sie vom Partner bei Ihnen abgeholt werden können.

Das wäre die Lösung für ein sehr einfaches EDI-System, das selbst keinerlei FTP-Fähigkeiten besitzt.
Schöner ist natürlich, wenn alles in einer Hand liegt, die EDI-Software also selbst per FTP Dateien holen oder auch entgegennehmen kann. In dem Fall gibt es z.B. für den Eingang von Daten per FTP zwei Möglichkeiten:

• (1) Die EDI-Software baut eine FTP-Verbindung zu einem entfernten Server auf, besorgt sich dort die Daten und verarbeitet sie.
• (2) Ein entfernter Client nimmt Verbindung direkt zum EDI-System auf (das quasi FTP-Server spielt) und übergibt ihm die Dateien.

In beiden Fällen entfallen die Zwischenschritte, Daten lokal abzulegen und dann zeitgesteuert wieder einzulesen. Variante 2 ermöglicht sogar die sofortige Verarbeitung der Daten, sobald sie vom Partner erhalten werden. Bei zeitkritischen Inhalten ein großer Vorteil.
Der Rückweg gestaltet sich natürlich auch einfacher und schneller, wenn die eingesetzte EDI-Software einen eigenen FTP-Client mitbringt und ihre Daten ohne Verzögerung ausliefern kann.

HTTP

Das Hypertext Transfer Protocol kennt jeder – ohne gäbe es kein Internet, wie wir es heute kennen. Es diente ursprünglich zum Transport von HTML-Seiten und Bildern, ist jedoch inzwischen stark erweitert worden und bietet für sich alleine schon diverse Möglichkeiten, beliebige Daten zu transferieren. HTML-Formulare, auch mit der Funktion des Datei-Uploads, sind Standard im Netz, und zum Download werden praktisch alle Arten von Dateien angeboten.
Basierend auf dem reinen HTTP-Protokoll sind inzwischen auch weitere Protokolle geschaffen worden, die auf diverse Aspekte der Datenübertragung zugeschnitten sind. Hier sind vor allem WebDAV und AS2 zu nennen. Wir wollen den Einsatz des ursprünglichen HTTP-Protokolls im EDI-Umfeld beleuchten.

• Das schöne an HTTP ist, dass es ein Frage-Antwort-Protokoll ist. Während man eine E-Mail einfach abfeuert und hofft, dass sie ankommt, und FTP lediglich eine erfolgreiche Übertragung der Daten bestätigen kann, gibt HTTP auch gleich Auskunft darüber, ob die Daten verarbeitet werden konnten. Es kann sogar – wie ein WebService – das Ergebnis dieser Verarbeitung zurücksenden. Und das, wohlgemerkt, synchron, also direkt als Antwort auf den eingehenden Request.
• Wenn es irgend etwas gibt, das durch die meisten Firewalls dieser Welt durchkommt, dann ist es das HTTP-Protokoll.
• HTTP-Server gibt es wie Sand am Meer, die bekanntesten sind sicher Apache und MS IIS.
• Eine HTTP-basierte Schnittstelle zum Datei-Up/Download kann, wenn sie entsprechend designed ist, gleichermaßen vom Menschen am Browser wie auch von einer automatisch arbeitenden Software angesprochen werden.

AS2

ist ein Übertragungsverfahren, das speziell für den Austausch von Geschäftsdaten entwickelt wurde. Dementsprechend hat man hier von Anfang an Wert auf Dinge wie Sicherheit und Nachweisbarkeit gelegt. Sicherheit wird durch Verschlüsselung und Signatur erreicht, die Nachweisbarkeit durch Empfangsbestätigungen (sogenannte MDNs).
Die Basis bildet HTTP bzw. HTTPS. Damit hat man den Vorteil, dass die Antwort auf eine Übertragung sofort (synchron) noch in derselben Verbindung gegeben werden kann. Außerdem ist das HTTP-Protokoll praktisch überall einsetzbar und nur in seltenen Fällen von Firewalls geblockt. Mit HTTPS (also SSL bzw. TLS) hat man zugleich eine Grundverschlüsselung der gesamten Kommunikation. Im Unterschied zu einfachem HTTP gibt es bei AS2 aber für Daten nur die Sende-Richtung (bei HTTP wäre das ein POST oder PUT), aber keinen Download von Dateien wie bei einem HTTP GET (es kommt höchstens eine kleine Empfangsbestätigung zurück).
Das ist aber noch nicht alles. Wie schon bei SSL, so kommen noch weitere Zertifikate zum Einsatz. Die Daten werden extra verschlüsselt und signiert. Hier wird der S/MIME-Standard genutzt. Und: Es gibt eine Empfangsbestätigung. Aber eines nach dem anderen.

Spielen wir das alte „Alice-und-Bob“-Spiel. Alice (A) will Daten per AS2 an Bob (B) senden. Folgende Schritte finden während der Übertragung statt:

1. A. bildet einen Hashwert über die Daten und signiert diesen mit ihrem privaten Schlüssel.
2. A. verschlüsselt die Daten (plus den signierten Hashwert) mit B.’s öffentlichem Schlüssel.
3. A. baut eine HTTP- oder HTTPS-Verbindung zu B. auf.
4. Im Falle HTTPS wird die ganze Übertragung noch einmal extra verschlüsselt, darauf gehen wir hier nicht näher ein.
5. In diversen speziellen HTTP-Headern werden die Kennungen (Seriennummern) der verwendeten Zertifikate mitgesendet, außerdem die AS2-Kennungen von Sender und Empfänger.
6. Der reine HTTP-Empfang kann an dieser Stelle schon mal bestätigt werden, falls die offizielle Empfangsbestätigung erst später folgt.
7. B. entschlüsselt die Übertragung mit seinem privaten Schlüssel. Welchen er nehmen muss, steht ja im HTTP-Header.
8. B. bildet einen Hashwert über die entschlüsselten Daten, entschlüsselt A.’s Hashwert mit ihrem öffentlichen Schlüssel und vergleicht die beiden.
9. B. entscheidet, ob er A. den Empfang positiv oder negativ bestätigen will (negativ z.B., wenn er Manipulation vermutet oder die ganze Entschlüsselung schief ging).
10. Die Empfangsbestätigung (Message Disposition Notification, MDN) kann mit B.’s privatem Schlüssel signiert werden.
B. schickt die MDN an A., synchron (als Antwort auf A.’s HTTP-Request) oder asynchron (in einer neu aufzubauenden HTTP-Verbindung, diesmal von B. zu A.).

Übrigens: Wenn Sie sich fragen, wozu denn die HTTPS-Verschlüsselung gebraucht wird, wenn AS2 dies doch schon vornimmt: AS2 verschlüsselt die Daten, aber nicht die HTTP-Header. So kann jeder mitlesen, wer an wen mit welchen Zertifikaten Daten schickt (und noch ein paar andere Kleinigkeiten). HTTPS verschlüsselt auch diese Metadaten.
Davon abgesehen ist bei AS2 die Verwendung von Verschlüsselung und Signatur nicht

SFTP

SSH/Secure File Transfer Protocol und SCP (Secury Copy) sind zwei Übertragungsprotokolle, die beide auf SSH aufsetzen. Es werden die Möglichkeiten von SSH zur Authentifizierung und Verschlüsselung genutzt, man spricht serverseitig meist mit einem SSH-Server, und normalerweise wird auch über Port 22 kommuniziert.
Auch wenn der Name es nahelegt: SFTP ähnelt nur bedingt dem verbreiteten FTP. Es dient eben auch dem Dateitransfer, technisch hat es damit aber wenig gemein. Allerdings bietet es mehr Möglichkeiten als das ausgesprochene SCP. Dieses kann tatsächlich nur Dateien kopieren (und rekursiv Verzeichnisbäume), während SFTP auch Befehle zum Umbenennen und Löschen von Dateien oder zur Anlage von Verzeichnissen kennt, ganz ähnlich dem normalen FTP.

Was bringt das beim elektronischen Datenaustausch?

Im Vergleich zu normalem FTP bietet SFTP/SCP zwei Vorteile:

• Die gesamte Kommunikation ist verschlüsselt (was sich allerdings auch mit FTPS, also SSL-verschlüsseltem FTP erreichen lässt).
• Es muss nur ein einziger Port (üblicherweise Port 22) in der Firewall freigeschaltet werden.

Bei FTP wird für jede einzelne Datenübertragung (sei es eine Datei oder nur ein Verzeichnislisting) ein neuer Port ausgehandelt. Firewalls können bei unverschlüsseltem FTP die Aushandlung belauschen und den entsprechenden Port freigeben, bei FTPS nicht. Deshalb müssen die Datenports auf einen gewissen Bereich (eine sog. Port Range) eingeschränkt und diese Ports in der Firewall freigegeben werden.

SFTP dagegen nimmt einfach Port 22 (oder auch einen anderen, wenn der SSH-Server anders konfiguriert ist). Darüber laufen Kommandos wie auch Datenübertragung. Nur diesen einen Port gibt man frei.
Für SCP gilt derselbe Vorteil, es kann nur ein paar Sachen nicht, die SFTP kann. Zum Beispiel kann jemand, der für ihn bestimmte Daten abgeholt hat, diese nicht einfach löschen. Dazu braucht er die Befehle der Secure Shell (SSH) selbst. Doch jemandem zu erlauben, auf dem eigenen Rechner SSH-Befehle abzusetzen, ist nicht ganz ohne…

Womit wir auch schon beim Nachteil wären, zumindest für eine Seite der Kommunikation. Da ein SSH-Server für den Verbindungsaufbau und die Verschlüsselung genutzt wird, besteht je nach genutzter Software die Gefahr, dass der User, der eigentlich nur SCP oder SFTP machen dürfte, sich auch in eine Secure Shell auf dem Server einloggt. Zwar hat er sein eigenes Konto und begrenzte Rechte, aber den einen oder anderen Ausbruch gibt’s ja immer wieder.
Davon abgesehen gelten für SFTP und SCP natürlich dieselben Vor- und Nachteile wie für normales FTP (soweit eben nicht schon als Unterschied angesprochen).

Abhilfe schafft in einigen Punkten ein System mit eigener Integration der Protokolle. Eine solche Software kann z.B. einen SFTP- und SCP-Server bereitstellen, der nicht die Möglichkeiten einer Secure Shell bietet. Und sie kann übertragene Daten sofort in die Verarbeitung nehmen, ohne Zwischenschritte, wie sie im FTP-Artikel beschrieben sind.

X.400

X.400 hat wenig mit der normalen Internet E-Mail gemein. Aber: Es ist ein Mail-Protokoll. Man versendet also Mails mit Absender, Empfänger, Text und evtl. Anhängen. Diese überträgt man an seinen Mail-Server, der sie (unter Umständen) an andere Mail-Server weiterleitet, bis sie im Postfach des Empfängers landen. Der holt sie von dort ab. Das waren die Gemeinsamkeiten. Womit wir bei den Unterschieden wären:

• Nicht jeder kann einfach so im Netz einen eigenen X.400-Server betreiben. Das bedeutet ein Stück Sicherheit, da die Mails nur über bekannte (und hoffentlich vertrauenswürdige) Stellen laufen.
• Die Einlieferung einer Mail im (eigenen) X.400-Server wird mit einem sogenannten Report bestätigt.
• Der Empfänger kann den Eingang einer Mail bei sich wiederum dem Absender bestätigen.
• Damit kann man das Netz aus X.400-Servern und -Clients als VAN bezeichnen, denn es bietet neben der reinen Übertragung auch noch die Sicherheit, dass nicht jeder mithören kann.
• Wie bei VANs üblich, kostet die Zusatzleistung etwas. Das Postfach sowieso, darüber hinaus kostet jede Verbindung, jede Nachricht extra. Auch die Empfangsbestätigung durch den Adressaten. Deshalb werden die selten verschickt.
• X.400-Server wurden ursprünglich via ISDN angesprochen, es existiert aber schon seit einer ganzen Weile die Möglichkeit, sie über das Internet zu kontaktieren. Und das auch SSL-verschlüsselt. Die ISDN-Variante kostet durch die Verbindungsgebühren extra.
• Als Mail-Client kann die von der Telekom verteilte Software Filework oder auch eine andere verwendet werden. EDI-Systeme sollten dieses Protokoll integriert haben, da X.400 gerade im EDI-Bereich sehr häufig anzutreffen ist.
• Es gibt auch ein Gateway zwischen X.400- und Internet-E-Mails. Dieses setzt die Nachrichten in beiden Richtungen um, so dass auch Nutzer normaler eMail mit X.400-Kunden kommunizieren können. Auch das kostet allerdings Geld.

OFTP

OFTP stammt aus einer Zeit, als das Internet noch in den Kinderschuhen steckte. Damals war ISDN so ziemlich das Modernste, was allgemein zugänglich war. Dementsprechend wurde OFTP auch über ISDN-Leitungen betrieben und wird es heute noch großenteils. Wobei das Protokoll selbst eigentlich unabhängig von der reinen Transportschicht ist und auch das alte OFTP in Version 1 bereits via TCP/IP und somit via Internet genutzt werden kann. Üblich ist der Weg über ISDN, was sinnvoll ist, da sich eine direkte Verbindung schlechter abhören lässt als eine offene Internet-Übertragung. OFTP1 hat noch keine eigenen Verschlüsselungsvorschriften. Da ist die vergleichsweise neue Version 2 schon weiter, denn hier gehört die Verwendung von TLS (bzw. SSL) zum Standard. Deshalb wird OFTP2 auch über das Internet betrieben.

Wie schon erwähnt, kennt OFTP eine Empfangsbestätigung, die sogenannte End-to-end Response (kurz: EERP). Diese bestätigt dem Absender, dass die Datei tatsächlich beim Empfänger angekommen ist. Das ist also ähnlich wie bei AS2 oder X.400. Wie bei AS2 die MDN kann bei OFTP die EERP sofort in der laufenden Übertragung geliefert werden oder erst in einer späteren Verbindung. Anders als bei X.400 wird sie üblicherweise auch tatsächlich genutzt, da sie bei vernünftig aufgesetzter Kommunikation keine zusätzlichen Kosten verursacht.

Die Nutzung von direkten ISDN-Verbindungen zwischen den Gesprächspartnern bei OFTP1 bzw. SSL-Verschlüsselung bei OFTP2 bietet Sicherheit bei der Übertragung, die EERP darüber hinaus die Nachvollziehbarkeit, ob eine Datei tatsächlich ihren Empfänger erreicht hat.
Das große Manko von OFTP1 ist, dass es beinahe ausschließlich via ISDN realisiert wird. Das bedeutet zum einen, dass jede Verbindung Geld kostet (und das können in manchen Unternehmen viele tausend Euro pro Monat sein), zum anderen aber auch, dass man ausreichend freie ISDN-Kanäle braucht, um nicht andauernd ein „Besetztzeichen“ zu bekommen, wenn man Daten übertragen will. Dafür wiederum braucht es auch die entsprechende Hardware. Deshalb wird OFTP1 derzeit Schritt für Schritt abgewickelt. Gerade die großen Autobauer (OFTP stammt ja aus dem Automotive-Umfeld) lösen ihr altes, ISDN-basiertes OFTP1 zur Zeit durch OFTP2 ab. Im Prinzip könnten sie genau so gut gleich AS2 nehmen, das noch ein bisschen mehr Sicherheit bietet, aber man bleibt doch lieber bei dem, was man kennt. Außerdem muss dafür zwar evtl. eine neue Version der OFTP-Software (oder auch eine ganz neue Software) eingespielt werden, diese ist dann aber normalerweise immer noch für OFTP1 nutzbar, da ja nicht alle Partner auch gleichzeitig auf die neue Version wechseln dürften. Nimmt man dagegen etwas ganz Neues für z.B. AS2, kann das womöglich kein OFTP mehr.

Natürlich gibt es auch EDI-Systeme, die beides (und noch einiges mehr) beherrschen. Siehe dazu auch Lobster_data.

OFTP in der Praxis

Wie schon erwähnt ist OFTP im Automotive-Bereich besonders verbreitet, aber auch darüber hinaus wird dieses Protokoll eingesetzt. Wenn Sie mit Geschäftspartnern Daten austauschen, die auf OFTP bestehen, werden Sie nicht umhin kommen, es auch einzusetzen.
Kann statt des alten OFTP1 via ISDN schon das neuere OFTP2 genutzt werden, ist es nicht mit nennenswerten laufenden Kosten verbunden. Sie brauchen eine Software, die OFTP2 beherrscht, einen Internet-Anschluss, eine ODETTE-ID und ein Zertifikat. Letzteres muss von ODETTE selbst ausgestellt oder von ODETTE oder einer diesem Institut genehmen Trust Center signiert sein. Lobster ist einer von zwei ODETTE-Zertifizierungspartnern in Europa!

Die Zertifizierung ist kostenpflichtig, doch verglichen mit den ISDN-Kosten der alten Methode ist das kaum der Rede wert. Zumindest, wenn Sie eine nennenswerte Zahl von Übertragungen vornehmen.
Müssen Sie sich noch mit dem alten OFTP1 herumschlagen, dann benötigen Sie eine dafür geeignete ISDN-Hardware. Das kann je nach Einsatzgebiet eine ISDN-Karte im Rechner sein oder ein Gerät, das per TCP/IP über das Netz angesprochen wird (aber eben mit der Außenwelt ISDN spricht).

WebDAV

Wenn wir uns im EDI-Umfeld bewegen, sind die ganzen, schönen Editier- und Versionierungsmöglichkeiten relativ uninteressant. Da müssen wir Daten in unser EDI-System hineinbekommen bzw. von diesem wieder hinausschicken. Es geht also letztlich nur um Datentransport. Schaut man sich unter diesem Aspekt die Methoden an, die WebDAV bietet (zusätzlich zu denen von HTTP), stellt man fest, dass diejenigen, die im EDI-Bereich interessant sind, eigentlich auch im FTP-Protokoll vorhanden sind. Und da gibt es sogar noch ein paar mehr Möglichkeiten. Wobei letztlich auch HTTP selbst mit GET und POST alles für diese Zwecke Nötige bereitstellt.
Wo also liegt der Vorteil von WebDAV? Gegenüber FTP hat es den Vorteil, dass HTTP von praktisch jeder Firewall durchgelassen wird und man auch beim Einsatz von SSL-Verschlüsselung nicht auf die Probleme wie bei FTPS treffen wird. Gegenüber einfachem HTTP hat es den Vorteil, dass man mit einer Verzeichnisstruktur arbeiten (und sie auch modifizieren) kann, ähnlich wie bei FTP. Ob man nun einen WebDAV-Server an seinen HTTP-Server andockt (es gibt viele davon) oder ein simples CGI-Script, das Daten per Post entgegennimmt (Download per GET geht ja sowieso), dürfte ansonsten ziemlich egal sein.

Letztlich dürfte der Einsatz von WebDAV in einem EDI-Szenario dann sinnvoll sein, wenn einer Ihrer Partner Ihnen auf diese Weise Daten zur Verfügung stellt. Für diesen Fall sollte eine EDI-Software deshalb auch das WebDAV-Protokoll beherrschen.

Interne Kommunikationswege

Das Dateisystem ist natürlich immer am leichtesten zu erreichen, erst recht das lokale. Hier kann man Daten zur Verarbeitung bereitstellen und hinterher die Ergebnisse ablegen. Vorausgesetzt natürlich, die verschiedenen Systeme, die miteinander kommunizieren, haben alle Zugriff auf das selbe Dateisystem.
Doch werden weder im EDI- noch im EAI-Umfeld alle relevanten Programme auf demselben Rechner laufen. Die nähmen sich nur gegenseitig Leistung weg, ganz zu schweigen von dem Risiko, dass auf einen Schlag alle geschäftskritischen Prozesse ausfallen könnten.

Eine Lösung hierfür ist sicher ein SAN, ein Storage Area Network, auf dem alle wichtigen Prozesse ihre Daten speichern. Da hat man meist gleich noch Hochverfügbarkeit usw. mit dabei. Aber es geht auch eine Nummer kleiner, mit dem NAS, dem Network Attached Storage. Das ist letztlich nichts anderes als der gute alte Fileserver, auf den mittels entsprechender Protokolle wie NFS oder SMB zugegriffen wird. Na gut, nicht nur der Fileserver, die Zugriffe erfolgen oft kreuz und quer durch’s ganze Firmennetz.

Das lokale Dateisystem ist wohl kaum einer näheren Betrachtung wert, und wenn Sie tatsächlich ein SAN aufbauen wollen, ist das ein zu großes Unterfangen, als dass man es hier nennenswert anschneiden könnte.
Interessant ist für uns eigentlich vor allem, welche Ansprüche an eine EDI-/EAI-Software zu stellen sind, die auf die Platten entfernter Rechner zugreifen muss.

NFS

NFS ist das alte Network File System aus der Unix-Welt. Es ist inzwischen in die Jahre gekommen und weist (aus historischen Gründen) auch nicht gerade hohe Sicherheitsstandards auf. Allerdings ist die aktuelle Version 4 gegenüber dem der verbreiteten Version 3 stark verbessert.
Wenn Sie in einer Unix/Linux-Umgebung unterwegs sind, können Sie sich das Leben mit NFS recht einfach machen. Sie mounten einfach die entsprechenden Netzlaufwerke (am besten automatisch schon beim Booten) und greifen in Ihrer Software dann auf diese genau so leicht zu wie auf lokale Partitionen und Verzeichnisse. Und eigentlich beherrschen auch Windows-Server NFS, es wird nur kaum genutzt. Wenn der entfernte Rechner mit Windows läuft, können Sie stattdessen über Samba dessen Freigaben ebenso mounten, da gibt es erst mal kaum Unterschiede (von einigen Feinheiten im Betrieb dann mal abgesehen, das ist dann aber SMB).
Ihr EDI-/EAI-System muss also, wenn es unter Unix/Linux läuft, weiter nichts beachten – es sieht genau genommen nicht einmal, dass ein Verzeichnis lokal und das andere eigentlich auf einem Server im Keller liegt. Ob da nun /user/local/data/Datei.txt steht oder /mount/fileserver/commondata/Datei.txt, der Zugriff erfolgt für die Anwendung identisch.

SMB

Mittels SMB realisiert in erster Linie Windows sein Netzwerk-Dateisystem. Hier ist die Sache etwas komplizierter als bei NFS-Mounts. Sie kennen das berühmte, verbundene Netzlaufwerk. Meist werden dafür Buchstaben weit hinten im Alphabet genutzt (besonders gerne das T), und dann zeigt eben Laufwerk T: auf ein freigegebenes Verzeichnis irgend eines entfernten Rechners. Das ist eine nette Lösung für einen Bürocomputer, an dem man sich erst mal einloggt, dann (meist automatisch) die Netzlaufwerke verbunden werden, und wenn man damit arbeiten will, ist alles da.
Für Serverprozesse, die meist als Windows-Dienst auch ganz ohne User-Login laufen müssen, ist das unbrauchbar. Solche Laufwerksbuchstaben wie T: sind immer auf den eingeloggten Benutzer bezogen und existieren für einen Prozess, der beim Rechnerstart ganz automatisch mit anläuft, gar nicht. Hier ist eine andere Technik gefragt, aber auch die kennen Sie schon aus Ihrem Dateimanager (aka Windows Explorer). Man gibt den Server und den Freigabenamen des gesuchten Verzeichnisses direkt an, etwa so:

\\servername\freigabename\pfad\Datei.txt

Mit dieser sogenannten UNC-Notation kann man jeden im Netz bekannten Rechner erreichen und alle dort freigegebenen Verzeichnisse ansprechen (unter Unix geht das übrigens auch, da werden dann normale Slashes / verwendet).
Nun braucht man aber für SMB auch eine Benutzer-Authentifikation. Während man NFS-(oder Samba-)Mounts beim Bootvorgang erledigt und sich dabei entsprechend zu erkennen gibt (was bei NFSv3 kaum der Rede wert ist), erwartet ein Windows-Rechner die Authentifikation des Users, wenn er auf die Freigabe zugreifen will.
Eine Möglichkeit dieses Problem zu lösen besteht darin, die entsprechende Software mit dem Benutzerkonto eines Domänen-Administrators laufen zu lassen. Greift sie dann auf den UNC-Pfad zu, gibt sie dabei die Identität ihres Benutzers an. Ist dieser auch auf dem entfernten Rechner bekannt, gewährt dieser den Zugriff. Allerdings ist nicht jeder System- und Netzwerk-Admin damit einverstanden, Programme im Kontext eines so mächtigen Users laufen zu lassen.
Die Alternative ist, dass sich die Software bei jedem Zugriff mit einem vorgegebenen Benutzer anmeldet. Das kann dann zum Beispiel so aussehen:

Angaben für eine SMB-Authentifikation in Lobster data

Natürlich muss die Software dazu in der Lage sein…

Der kleine Unterschied

Im Prinzip kann eine Software also auf freigegebene Verzeichnisse entfernter Rechner genau so leicht zugreifen wie auf die lokalen Festplatten.

Ein paar kleine Einschränkungen gibt es aber doch.
Die einfachste davon ist, dass der Server, auf dem das gewünschte Verzeichnis liegt, gerade nicht läuft oder durch eine Netzwerkstörung nicht erreichbar ist. Das kann einem allerdings beim Zugriff z.B. via FTP genau so passieren.
Eine andere Einschränkung ist die, dass man sich nicht zu sehr der Illusion hingeben sollte, dass man es mit einem lokalen Verzeichnis zu tun hat. Nicht nur ist die Zugriffszeit schlechter, da ja alles übe das Netzwerk geht, man kann sich auch nicht auf dieselben Mechanismen verlassen, die bei lokalen Laufwerken das Leben einfacher machen.
Als einfaches Beispiel seien File Events genannt. Sie kennen das vielleicht: Sie haben den Windows-Explorer offen, irgend ein Prozess legt eine neue Datei ab oder löscht eine weg, und Sie sehen die Veränderung sofort, auch ohne zu aktualisieren. Hier wurde das Ereignis (Datei hinzugekommen/gelöscht) als Nachricht ins System geschickt, und der Explorer konnte sofort darauf reagieren und die Anzeige aktualisieren. Über das Netz funktioniert so etwas nur sehr unzuverlässig. Der Grund mag sein, dass man die Netzwerklast nicht mit solchen Kleinigkeiten hochtreiben will. Der Nachteil ist, dass sich eine Software plötzlich, nur, weil es sich um eine Netzwerkressource handelt, auf diesen Mechanismus nicht mehr verlassen kann.

Nutzen für EDI/EAI

Beim Datenaustausch von EDI-/EAI-Systemen mit anderen Prozessen sind lokale oder Netzwerk-Dateisysteme eine einfache Lösung. Allerdings sollte man dabei nicht vergessen, dass man dem betreffenden System zwar eine Datei zur Verarbeitung bereitstellen kann, aber selbst nachsehen muss, ob es neue Arbeit gibt (File Events sind, wie erwähnt, nicht verlässlich). Das bedeutet: die diversen Empfänger müssen regelmäßig „ihre“ Verzeichnisse nach neuen Dateien durchsuchen, ganz ähnlich wie beim Datenaustausch mittels FTP. Im eigenen Firmennetz muss man sich aber normalerweise keine Sorgen um abgehörte oder gar manipulierte Übertragungen machen.
Manche etwas einfachere Software bietet schlicht nur eine solche Dateischnittstelle – oder man kann sie zumindest irgendwie dazuprogrammieren. Da bleibt einem dann also gar nichts anderes übrig. Gibt es aber andere Möglichkeiten, die gewährleisten, dass angelieferte Daten sofort in die Verarbeitung gehen, sollte man darauf zurückgreifen.

RFC

Funktionen (oder in SAP-Sprache Funktionsbausteine), die man von außen aufrufen kann, gibt es in Hülle und Fülle. Und was nicht von SAP mitgeliefert wird, kann man dazuprogrammieren. Dafür gibt es wiederum die SAP Consultants (auch in Hülle und Fülle). Oder natürlich, Sie haben einen Spezialisten im Haus.
Oben wurden schon zwei solche Funktionen genannt:

• Über IDOC_INBOUND_ASYNCHRONOUS kann ein IDoc von außen ins SAP eingeliefert werden, zum Beispiel ein neuer Auftrag.
• Über IDOC_OUTBOUND_ASYNCHRONOUS wirft SAP ein IDoc aus, das zum Beispiel von einer EDI-Software konvertiert und versendet werden soll.

Es gibt noch andere, wichtige RFCs. Zum Beispiel den RFC_READ_TABLE, um sich kurzerhand Daten aus einem SAP-System zu besorgen. Der kann eine ganze Menge, man kann über ihn auch herausbekommen, welche IDoc-Typen es in einem SAP-System überhaupt gibt oder welche Erweiterungen zu diesen bekannt sind. Auch Beschreibungen dazu lassen sich erfragen.

Aber RFCs existieren nicht nur im SAP-System selbst. Auch eine angeschlossene Fremdsoftware (wie z.B. ein EDI- oder EAI-System) kann RFCs bereitstellen, die wiederum das SAP-System ansprechen. So kann also diese Form der Kommunikation in beide Richtungen erfolgen.

ALE

ALE ist sozusagen eine Zwischenschicht zwischen reinen RFCs und der Außenwelt. Fremdsoftware oder andere SAP-Installationen, die IDocs mit einem SAP-System austauschen wollen, greifen auf ALE zurück. Dieses verbirgt einige Feinheiten der eigentlichen RFC-Aufrufe, die es letztlich durchführt. Und eine solche Fremdsoftware wird in vielen Fällen eben ein EDI- oder EAI-System sein.
SAP selbst spricht auch von Translatoren, die sich auf der einen Seite via ALE mit dem SAP-System unterhalten und auf der anderen Seite mit einer beliebigen anderen Software kommunizieren. An einen solchen Translator werden gewisse Anforderungen gestellt.
Er muss:

• automatisch Strukturbeschreibungen von IDocS in seine eigenen Strukturdefinitionen übernehmen können.
• ein IDoc vom SAP-System übernehmen und die Informationen entsprechend seiner Strukturdefinitionen interpretieren können.
• ausreichend mächtige Mapping-Funktionalitäten bieten (also die Konvertierung zwischen Datenformaten beherrschen).
• erzeugte IDocs an das SAP-System übergeben können.

Alles in allem wird also neben einer vernünftigen Kommunikation mit dem SAP-System noch die einfachste Grundfunktionalität einer EDI- bzw. EAI-Software gefordert.
Wenn Sie auf der Suche nach einer solchen Software sind und ein SAP-System einsetzen (oder dies auf Sie zukommen könnte), achten Sie darauf, dass die Software in der Lage ist, SAP ALE und RFC zu „sprechen“ und oben genannte Punkte erfüllt.

Datenbanken und EDI/EAI/ETL

Software aus diesem Bereich hat die Aufgabe, viele unterschiedliche Systeme miteinander zu verknüpfen. Ein solches Programm darf also per se keine Sonderwünsche bzgl. der angesprochenen Datenbanken haben. Es muss vielmehr in der Lage sein, möglichst viele unterschiedliche Datenbanksysteme anzusprechen.

Die Systeme, um die es hier geht, müssen ODBC und/oder JDBC beherrschen. Auch für ganz besonders eigenwillige Datenbanken, die womöglich nur via API ansprechbar sind, muss der Standard abgedeckt sein. Das Tool hat sich nach den Gegebenheiten in Ihrer Firma zu richten, nicht umgekehrt.

Allerdings sollten Sie nicht euphorisch die Datenbanken aller möglichen Programme mit einem eventuell neu angeschafften EDI- oder EAI-Programm anzapfen und beliebig Daten hineinschreiben. Solange Sie nur lesen, kann wenig passieren, aber komplexere Software (von etwas so großem wie einem SAP ERP mal ganz zu Schweigen) ist empfindlich, wenn man an ihr vorbei in ihren Tabellen arbeitet. Zu viele Abhängigkeiten sind zu beachten, da können Sie sich ganz schnell etwas „zerschießen“. Hier sind andere Schnittstellen zu bevorzugen – sofern sie existieren.
Auch, wenn Sie ETL-Prozesse aufsetzen wollen, sollten sie wirklich wissen, was Sie tun.

Allein für Lookups (also das Nachsehen von Informationen, zum Beispiel das Auslesen einer Adresse zu einer Kundennummer) ist der direkte Zugriff auf Datenbanken eine feine Sache. Und da Sie womöglich nicht nur ein einziges Datenbanksystem im Hause haben, sollte sich der Zugriff auf die Systeme nicht allzu schwierig gestalten. Wenn Sie einen halben Tag damit verbringen, Zugriff auf eine weitere Datenbank zu erhalten oder bei der Definition jedes neuen Prozesses wieder alles einzeln konfigurieren müssen, passt was nicht. Auch sollte es möglich sein, in einem Prozess mehrere, unterschiedliche Datenbanken anzusprechen, die jeweils Teile der benötigten Daten beinhalten.

Ist das DB-System erst einmal angesprochen, geht es um die Tabellen. Das kann einfach sein oder kompliziert, je nach Software. Je mehr Unterstützung Sie hierbei von Ihrer Software erhalten, desto besser können Sie sich auf die eigentliche Definition eines EDI- oder EAI-Prozesses konzentrieren.

Bleibt noch eine Sache zu erwähnen: Wenn man von Datenbanken spricht, spricht man schnell auch von Massendaten. Da werden ganze Artikelstämme hin und her geschaufelt, und auch der Kundenstamm ist hoffentlich groß; da prasseln im Sekundentakt Aufträge, Rechnungen, Lieferscheine und und und herein, die entweder direkt in die verschiedenen Datenbanken geschrieben oder daraus gelesen werden, oder die zumindest mengenweise Lookups erfordern. All das muss performant ablaufen. Datenbanken sind normalerweise auf Performance getrimmt, aber auch das Programm, das sie anspricht, muss mit diesen Datenmengen klarkommen. Auch Millionen von Datensätzen müssen klaglos ausgelesen, verarbeitet und gespeichert werden.

Message Services

Dies ist ein sehr allgemeiner Begriff. So ein Message Service dient dazu, Nachrichten zwischen diversen Systemen auszutauschen, die voneinander im Prinzip gar nichts wissen müssen. Jedes angeschlossene System schickt einfach Nachrichten an diesen Service, die von anderen Systemen empfangen werden. Und jedes System, das solche Nachrichten empfangen will, registriert sich für bestimmte Kanäle oder Themen. Das Interessante dabei ist, dass der Sender gar nicht genau wissen muss, wer seine Nachricht empfängt, ja oft nicht einmal mitbekommt, ob sie überhaupt empfangen wurde. Und wie die Nachricht letztlich verarbeitet wurde, interessiert ihn eigentlich auch nicht. Das entkoppelt die verschiedenen Systeme voneinander, logisch und auch zeitlich.

Message Services und EDI/EAI

An sich ist ein Message Service die ideale Möglichkeit für Systeme innerhalb eines Firmennetzes miteinander zu kommunizieren. SAP bietet ALE als direkte Kommunikationsform an, das ist aber eben sehr SAP-spezifisch. Andere Produkte stützen sich auf HTTP oder gar auf einfache Dateisystem-Schnittstellen, aber diese Formen der Kommunikation sind eigentlich nur Notbehelfe. Während HTTP oder auch FTP für die Kommunikation zwischen verschiedenen Firmen im Internet geeignet sind und AS2 z.B. geradezu dafür entworfen, ist das Dateisystem in erster Linie zur Datenhaltung, aber nicht zur Kommunikation gemacht. Für den Datenaustausch im selben lokalen Netz dagegen sind all diese Wege nur zweckentfremdet worden.
Message Services sind hingegen exakt dafür entworfen. Ob EAI- oder EDI-System (oder eines, das beides beherrscht), es muss immer mit anderen Produkten im Haus (bzw. im LAN) kommuniziert werden. Dazu gibt es ein Konzept wie den ESB (Enterprise Service Bus). Die reale Implementierung dieser Kommunikation dagegen kann sehr gut ein Message Service sein. Vorausgesetzt natürlich, die bereits im Hause vorhandene Software ist fähig, mit einem solchen Message Service zu arbeiten. Eine gute Möglichkeit dazu ist die Nutzung von AMQP.
Wenn Sie vor der Entscheidung stehen, eine EDI- oder EAI-Software anzuschaffen, klopfen Sie doch mal die schon existierenden (oder noch anzuschaffenden) Systeme daraufhin ab, ob sie diese Fähigkeit besitzen. Und sollte das in Frage kommen, achten Sie auch bei Ihrer EDI/EAI-Wahl darauf.

AS/400 DataQueue

Data Queues sind ein Konzept der IBM AS/400 (bzw. heute System i, oder auch iSeries oder i5) zur schnellen Kommunikation von Prozessen sowohl auf der iSeries, als auch außerhalb. Auch wenn der Name „Queue“ (also Schlange bzw. Warteschlange) auf eine FIFO-Verarbeitung hinweist, sind im Prinzip drei Arbeitsmoden möglich:

• FIFO: First In First Out, also das typische Warteschlangenkonzept, bei dem die Einträge der Eingangsreihenfolge nach abgearbeitet werden.
• LIFO: Last In Last Out, was man eigentlich eher als Stack (=Stapel) bezeichnen würde; hier wird immer der neueste Eintrag zuerst ausgelesen.
• Keyed: Hier entscheidet nicht die Reihenfolge der Einträge, sondern sie werden über einen Key ausgelesen, der jedem Queue-Eintrag zugeordnet ist.

Egal, welcher Modus genutzt wird, immer gibt es einen oder mehrere Prozesse, die Einträge auf der Data Queue einstellen, und einen oder mehrere andere, die die Data Queue Fragen regelmäßig abfragen und vorhandene Einträge wieder herausholen.

Sonstige

Die gängigen Wege, auf denen verschiedene Software-Systeme miteinander kommunizieren können, wurden auf dieser Seite einzeln beschrieben. Natürlich gibt es noch weitere.
So kann durchaus der Bedarf bestehen, Daten nicht nur elektronisch zu verarbeiten und zu speichern, sondern auch auszudrucken. Ein klassisches Beispiel wären Lieferscheine oder auch Etiketten mit Barcodes. Auch das gehört – wenn auch nicht im engsten Sinne – zum Thema EDI bzw. EAI. Hier sollte die eingesetzte Software entweder die Möglichkeit bieten, direkt die verfügbaren Drucker anzusprechen (und zum Beispiel auch die Daten für den Druck als PDF aufzubereiten).

Schnittstellen, über die man eigenen Code anbinden kann, sind zudem wichtig, denn es gibt immer wieder den einen oder anderen nicht „üblichen“ Weg, auf dem Daten beschafft oder versendet werden sollen. Möglicherweise wird eigenentwickelte Software verwendet, die keinerlei Standard-Schnittstelle unterstützt, dann kann man selbst etwas „dranprogrammieren“. Auch zahlt es sich aus, wenn man auf Seiten der EDI/EAI-Software Möglichkeiten hat, eigenen Code anzudocken, und so schnell eine Verbindung zu schaffen.