OFTP - Die Zukunft der Datenübermittlung?!

Durch immer intensiver werdende Kunden-Lieferantenbeziehung (Stichwort "Industrie 4.0") ist der schnelle und sichere Informationsaustausch von wesentlicher Bedeutung. Nun sollte man meinen, dass im Zeitalter der Digitalisierung (die Hightech-Strategie der Bundesregierung wurde bereits 2006 beschlossen) der elektronische Datenaustausch (EDI) zwischen Firmen tägliche Praxis ist. Leider ist dem insbesondere bei den KMU nicht so. Dabei liegen die Vorteile von EDI vor allem auch bei der direkten Einbindung ins ERP für beide Kommunikationspartner klar auf der Hand:

• Geschwindigkeit: Die Änderungen sind sofort in den ERP-Systemen sichtbar
• Arbeitsaufwand: Das lästige Abtippen von Rechnungen, Lieferscheinen etc. entfällt
• Datengüte: Die Kommunikation erfolgt von Maschine zu Maschine. Der Mensch als mögliche Fehlerquelle entfällt.

Die eigentliche Kernaufgabe des Informationsaustauschs in Bezug auf ERP-Systeme ist relativ simpel:

1. Abspeichern von Unternehmensdaten (meist ERP-Daten wie Aufträge, Lieferscheine, Rechnungen aber auch CAD-Dateien etc.) in einheitlichen standardisierten Datenformaten
2. Allgemein verfügbare, sichere und schnelle Übertragung (Transportschicht)
3. Verarbeitung der Daten im ERP-System des Lieferanten/Kunden

Während die Übertragung (Punkt 2) im Zeitalter des Internet als weitestgehend unkritisch betrachtet werden kann, erweist sich Punkt 1 und in dessen Folge auch Punkt 3 als unerwartet schwierig.

Viele Köche verderben den Brei

Das Problem bei den (EDI-)Datenformate ist nicht, dass es keinen Standard gibt, sondern dass es einfach zu viele gibt. Unter Federführung der UN (CEFACT) wurde EDIFACT zur Norm erhoben, dann wurden auf nationaler Ebene Parallelformate wie openTrans, myOpenFactory, VDA etc. entwickelt und dann kamen die großen ERP-Hersteller mit wieder eigene Formate (SAP-iDoc, Oracle). Da das alles noch nicht reichte, bekamen jede Branche noch ihr eigenes standardisiertes Format in Form von Subsets (bei EDIFACT gibt es derer über 20, von der Möbel- über Reifen-, Sanitär-, Baustoffbranche bis hin zu VDA für die Automobilbranche), die teils national und teils weltweit gelten. Sie denken jetzt reicht es aber? Irrtum! Denn nun kamen noch die Branchenprimusse, die innerhalb der Subsets ihre firmenspezifischen Besonderheiten zum Standard (nur für deren Lieferanten) erklärten oder gleich eigene proprietäre Formate entwickelten. Resultat ist eine kaum mehr zu überblickende Anzahl von "Standardformaten", die noch dazu regelmäßig modifiziert werden.

Auf Kundenseite ist dies unkritisch, da sie ja nur das eine in ihrem ERP implementierte Datenformat verwenden. Das Problem haben die (kleineren KMU-) Lieferanten. Ist deren Marktstellung schwächer, haben sie meist keine andere Möglichkeit als das vom Kunden verwendete Format in ihr ERP-System zu implementieren, was mit erheblichem einmaligen Kosten für Programmierung und Einrichtung sowie geringen laufenden Kosten (Zertifikate, IT) verbunden ist. Und wenn dann noch mehrere Kunden auf der Nutzung "ihres" Formats bestehen, vervielfachen sich die Kosten für den KMU-Lieferanten.

Das wissen natürlich auch die Kunden, weshalb sie selbst oder ein von ihnen beauftragter Dienstleister als Alternative Web-Portale zur Verfügung stellen, bei denen die EDI-Daten vom KMU-Lieferanten manuell erfasst und dann vom Portal konvertiert und übermittelt werden. Hierbei ist der einmalige Aufwand für den KMU-Lieferanten deutlich geringer (Schulung, ggf. Installationskosten für den Dienstleister) bei mittleren laufenden Kosten (Personal für Dateneingabe, Nutzungsgebühren für Dienstleister).

Im folgendem möchten wir das vor allem in der Automobilbranche verbreitete Protokoll OFTP (ODETTE File Transfer Protocol) etwas näher vorstellen. Wir haben das Protokoll in unserem universellen Schnittstellenserver (DE-Server, ist eine OS-Projekt) implementiert, dessen Aufgabe es ist, Daten aus verschiedensten Quellen (PDF, ASCII, Datenbanken, DATEV, HTTP, und eben auch OFTP) ineinander zu konvertieren und zu überwachen.

Aufgabe

OFTP ist ein Netzwerkprotokoll zur elektronischen Datenübertragung zwischen zwei Kommunikationspartnern. In Version 1 (OFTP1, seit 1986) entspricht es der VDA-Empfehlung 4914/2. Der Hauptunterschied zu Version 2 (OFTP2, seit 2007) ist die Änderung der Transportschicht (bei OFTP1 => ISDN, bei OFTP2 => TCP/IP).

Vorteile

• Wiederaufnahme von unterbrochenen Übertragungen (heute zunehmend unkritisch, da i.d.R. hohe Bandbreiten verfügbar)
• Dreistufiges Sicherheitskonzept ermöglicht die sichere Übertragung der Daten
• Empfangsbestätigung (EERP- End-to-end Response). Die Gegenstelle bestätigt den Empfang jeder Datei, wodurch eine nachweisbare Übermittlung gewährleistet ist.

Sicherheit

Durch die im OFTP-Protokoll implementierten Sicherheitsstufen: - Verschlüsselung und Authentifizierung der Verbindung (SSL-verschlüsselte TCP/IP-Verbindung) - Verschlüsselung der Daten (Austausch öffentlicher/privater Schlüssel) - Signierung (jeder Kommunikationspartner erhält eine weltweit einmalige ODETTE-ID; Hashsummenaustausch bei Empfang; Zertifikate) wird der unbefugte Zugriff weitestgehend verhindert.

Einsatzvoraussetzungen

Um die Kommunikation via OFTP zu gewährleisten werden entsprechende Zertifikate, ein Domainname sowie eine Odette-ID benötigt, worüber jeder Teilnehmer eindeutig identifiziert werden kann.

Die Odette-ID wird von der Odette Organisation generiert. Sie ist eine weltweit eindeutige Identifikationsnummer des Kommunikationspartners.

Damit die Übertragung kryptographisch gesichert erfolgen kann, benötigt man zusätzlich ein Zertifikat. Dieses wird ebenfalls von der Odette Organisation ausgestellt. In dieses Zertifikat, werden der Domainname und die Odette-ID eingebettet. Dies ermöglicht eine sicherer Identifizierung des Kommunikationspartners (Authentifizierung).

Dieses Zertifikat ist ein Clientzertifikat für Signierung und Verschlüsslung, und kann auch für andere Kommunikationen verwendet werden.

Das Protokoll schreibt aber nicht die ausschließliche Verwendung eines Odette-Zertifikates vor. Es kann jede beliebige Zertifikatsautorität (CA) verwendet werden, z.B. VeriSign, LetsEncrypt, eigens erstellte etc. Der Kommunikationspartner muss Ihr nur das nötige "Vertrauen" schenken.

Ablaufbeispiel

Zunächst werden die Daten von Station A an den Verteiler Z gesendet. Diese verteilt die Daten weiter an Station B ebenso wie auch an Station C und empfängt anschließend eine EERP von Station B und daraufhin auch eine EERP von Station C. Sobald beide EERP's von B und C vorliegen, sendet der Verteiler einen gesammelten EERP an den ursprünglichen Auftraggeber Station A. Der nun dadurch weiß, dass seine Informationen bei allen Teilnehmern angekommen sind.

Eine Negative End Response (NERP) ist technisch ebenso möglich, wird jedoch in der Praxis eher selten verwendet. Üblicherweise wird meist nach einer festgelegten Zeit, die Nachricht auf den Fehlerstatus gesetzt, wenn kein EERP eingetroffen ist.

Fazit

Aus heutiger Sicht des KMU-Lieferanten, ist eine Implementierung von Netzwerkprotokollen zur elektronischen Datenübertragung im ERP-System sinnvoll, wenn: - (möglichst) alle Kunden das gleiche Protokoll verwenden - die Protokollverarbeitung im ERP-System integriert ist - eine große oder häufig aktualisierte Datenmenge zu verarbeiten sind

Trifft dies nicht zu und besteht der Kunde auf eine elektronische Datenübertragung, hat der KMU-Lieferant keine andere Wahl als die vom Kunden/Dienstleister bereitgestellten Portale zu nutzen. Dies ist jedoch immer die schlechteste Lösung, da sämtliche einleitend genannten Vorteile des elektronischen Informationsaustausches für ihn verloren gehen.

Technische Daten OFTP-Schnittstelle (PPS2000, PPSn)

• Beschreibung: Netzwerkprotokoll zur elektronischen Datenübertragung
  
• Programmiersprache: C#, Lua, SQL
• Implementierte Protokolle (Satzarten): VDA 4905 (Lieferabrufe), VDA 4912 (Lieferschein), VDA 4913 (Lieferschein- und Transportdaten), VDA 4922 (Speditionsauftrag), VDA 4951 (Datenfernübertragung von CAD/CAM Daten)
• RFC2204 ODETTE File Transfer Protocol
• RFC5024 ODETTE File Transfer Protocol 2.0

Über uns

Die TecWare Gesellschaft für Softwareentwicklung mit Sitz im sächsischen Niederau OT Ockrilla entwickelt seit über 25 Jahren kundenindividuelle Softwarelösungen mit dem Schwerpunkten ERP-Systeme, Materialwirtschaft und Logistik. Wir unterstützen die Open Source Initiative (https://opensource.org/), auf deren Grundlage wir derzeit an einem Open Source-basierten PPS- und CRM-System (Programmiersprache C#) arbeiten. Sie finden das OS-Projekt unter https://github.com/twppsn. Besuchen Sie uns auch gerne online unter https://www.tecware-gmbh.de/.

Infos

• https://de.wikipedia.org/wiki/OdetteFileTransfer_Protocol
• https://www.myopenfactory.gmbh/myopenfactory/
• http://edi-wissen.de/edi/kommunikationswege-datenquellen-senken/eher-offentliche-wege/oftp/