Lobster Experten Fragen

FTP

Das File Transfer Protocol FTP ist, wie der Name schon sagt, zur Übertragung von Dateien da. Die meisten werden schon mal mit FTP gearbeitet haben, z.B. über FileZilla oder den Browser. Dass man FTP auch an der Konsole (Unix Shell bzw. DOS Box unter Windows) machen kann, sollte auch bekannt sein. Wie FTP im Prinzip funktioniert, das erklärt mal wieder Wikipedia. Wir wenden 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). Fein. Anschließend liegt also eine Datei herum, lokal oder eben auf dem Server. Und nun?
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 selbst 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 zwei ermöglicht damit sogar eine 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.

Vorteile

  • FTP überträgt Daten direkt zum Zielsystem. Sie wissen also genau, ob Ihre Daten angekommen sind und wann.
    Dass eine Datei (wie bei E-Mail möglich) unterwegs verloren geht, kann praktisch ausgeschlossen werden.
  • FTP-Clients gibt es praktisch auf jedem Betriebssystem, damit ist jeder Partner in der Lage, mit Ihnen zu kommunizieren.
  • Wählt man die binäre Übertragung, kann man sicher sein, dass die Daten unverfälscht angekommen sind.

Nachteile

  • Sie erfahren, ob die Übertragung der Daten funktioniert hat. Ob das EDI-System diese auch in die Verarbeitung genommen hat, bleibt unklar.
  • FTP ist per se nicht gegen Mithören und Manipulation gesichert. Hier gibt es mit FTPS (also dem Einsatz von SSL während der FTP-Übertragung) allerdings eine Abhilfe.
  • Firewalls und NATting stören gerne mal die Aushandlung der Daten-Ports. Da lässt sich ein System vom anderen nicht vorschreiben, welchen Port es zu öffnen hat, bzw. der Port kann nicht durchgeroutet werden.
  • Vernünftige Firewalls bekommen zwar normalerweise mit, welcher Port ausgehandelt wird, und öffnen diesen. Wird allerdings eine Verschlüsselung mittels SSL eingesetzt, kann das Aushandeln nicht mehr mitgehört werden. Das kann den Einsatz von FTP(S) zumindest sehr erschweren und einiges an Zusatzkonfigurationen nötig machen (Port Ranges definieren etc.).

Man hat auch einen auf FTP basierenden Standard zur sicheren Datenübermittlung geschaffen, der sich AS3 nennt. Hier gibt es Empfangsbestätigungen (alias MDNs) usw., doch wie AS1 (das auf E-Mail basierende Pendant) hat er sich nie wirklich durchgesetzt und ist in der Praxis nicht von Bedeutung.

FTP ist also schon wesentlich besser für EDI-Szenarien geeignet als E-Mail und wird auch intensiv genutzt. Allerdings gibt es z.B. mit AS2 optimalere Kommunikationsformen.

(Fall Sie hier übrigens SFTP vermisst haben: Da dieses Protokoll technisch nur bedingt FTP ähnelt, dafür aber eng mit SSH verbandelt ist, gibt es dazu einen eigenen Artikel.)