Grundlegendes zu Kommunikationswegen, 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 gehen. 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 ihre Daten zurück?
Eine klare Trennlinie lässt sich hier eigentlich gar nicht ziehen, weder zwischen reiner Kommunikation und Datenquellen sowie -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 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 EDI-Software Lobster_data, Daten zur Verarbeitung zu erhalten bzw. sich selbst 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 über 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:
