Lobster Experten Fragen

Kommunikationswege, Datenquellen & -senken

Neben den genutzten Datenformaten ist im Bereich EDI (aber auch EAI) noch interessant, wie die Daten in ein System hineinkommen und wieder heraus. Wie also gelangen die Daten Ihrer Partner und Kunden in Ihr EDI-System, wie kommuniziert dieses mit den internen Systemen und wie bekommen die Partner am Ende ihre Daten zurück?

Eine klare Trennlinie lässt sich hier eigentlich gar nicht ziehen, weder zwischen reiner Kommunikation und Datenquellen/-senken, noch zwischen öffentlicher und interner Kommunikation. Denn natürlich können E-Mails, FTP-Übertragungen oder HTTP-Anfragen genau so gut innerhalb Ihres Intranets genutzt werden, wie sie über das Internet in alle Welt gehen. Umgekehrt können Datenbanken oder ERP-Systeme durchaus (z.B. mittels VPNs) über große Entfernungen angebunden werden.

Zu jeder Datenquelle und -Senke gehören natürlich auch eine oder mehrere Kommunikationsformen. Eine Datenbank kann z.B. via JDBC oder ODBC angesprochen werden, ein Lagerverwaltungssystem kann ebenso Textdateien im- und exportieren, wie man auch direkt in die Tabellen der darunterliegenden Datenbank greifen kann, und Systeme wie SAP bringen oft ihre ganz speziellen Zugriffsmethoden mit, in diesem Fall nennen sie sich ALE und RFC.

Trotzdem wird im folgenden eine Unterteilung zwischen „Eher öffentlich“ und „Eher intern“ gemacht, man sollte nur im Hinterkopf behalten, dass die Übergänge fließend sind. Wie auch der Übergang zwischen EDI und EAI in der Praxis eher fließend ist, da viele Systeme und Kommunikationswege in beiden Fällen angesprochen werden müssen.

Beispiel der Möglichkeiten eines konkreten Systems

Hier zum Beispiel die Möglichkeiten der Datenmanagement-Lösung  Lobster_data, Daten zur Verarbeitung zu erhalten bzw. sich selbst zu beschaffen:

Agenten
Möglichkeiten von Lobster_data, Daten zu empfangen…
Crontypen
…bzw. sich selbst zeitgesteuert Daten zu beschaffen.

 

Sie sehen, dass zum Beispiel das FTP-Protokoll zweifach auftaucht. In der Liste oben und als eine Auswahlmöglichkeit sogenannter Cron Jobs. Gleiches gilt für einige weitere Kommunikationsformen. Der Grund hierfür ist folgender: Dieses Produkt verfügt einen eigenen, vollwertigen FTP-Server als integralen Bestandteil. Und damit ergeben sich zwei mögliche Varianten, wer eine Datenübertragung initiieren kann:

Zum einen kann der Partner entscheiden, dass er jetzt gerade eine Datei an Sie loswerden möchte. Dann öffnet er (wenn Sie ihm ein entsprechendes Benutzerkonto eingerichtet haben) eine FTP-Verbindung zu Ihrem EDI-Server und schickt Ihnen die Daten zu. Ihr System wartet also einfach darauf, dass man ihm von außen etwas zur Verarbeitung zuschickt.
Zum anderen kann aber mit dem Partner abgesprochen sein, dass er seine Daten auf einem seiner FTP-Server bereitstellt, und Sie holen sich die Dateien dort ab. Da dieser Vorgang natürlich vollautomatisch ablaufen soll, konfiguriert man eine Zeitsteuerung, die die Abholung der Dateien regelt. Nichts anderes bedeutet „Cron Job“: Eine zeitgesteuert auszuführende Aktivität.

Falls jemandem auffällt, dass es bei OFTP eigentlich kein Kommando zum Download gibt, wie es das „get“ (bzw. RETR) im normalen FTP-Protokoll darstellt: Lesen Sie sich den Artikel zu OFTP durch, dann wissen Sie, wie man trotzdem eine ähnliche Abfrage realisieren kann.

Hat das EDI-System seine Arbeit erledigt (Formatkonvertierung, Anreicherung, Abgleich etc.), muss es das Ergebnis seines Tuns auch wieder loswerden:

Antwortwege
Auf all diesen Wegen (plus Datenbank) kann Lobster_data seine erstellten Daten
auch wieder in die Welt (oder Ihr Firmennetz) schicken.

 

Sie sehen bei Dateienein- und -ausgang eine bunte Mischung aus dem, was in unserer Gliederung als „eher öffentlich“ und „eher intern“ bezeichnet wird. Das ergibt sich für ein EDI-System eigentlich von selbst, denn dessen Zweck ist ja gerade, die internen Systeme mit der Außenwelt zu verknüpfen. Aber … wo man nun schon auf beiden Seiten interne Systeme anbinden kann, hat man bereits eine wichtige Anforderung an EAI-Software erfüllt. Schon wieder fällt auf: Eine strikte Trennung zwischen EDI und EAI ist graue Theorie und der Einsatz zweier getrennter Systeme eher praxisfern.