Lobster Experten Fragen

EDI

Was ist EDI?
Während EAI die Kommunikation der IT-Systeme innerhalb eines Unternehmens behandelt, betrifft EDI den Datenaustausch zwischen mehreren Unternehmen. Auch hier aber „sprechen“ die IT-Systeme direkt miteinander, der Mensch sollte nur noch Kontrollfunktion haben.

Wenn schon innerhalb einer Firma oftmals Software unterschiedlicher Hersteller im Einsatz ist, so wird die Welt noch wesentlich bunter, wenn verschiedene Unternehmen miteinander zu tun haben. Nicht nur gibt es verschiedene Standard-Softwaresysteme, oft geistern komplette Eigenentwicklungen durch die Prozessoren, die geschrieben wurden, als die IT noch in den Kinderschuhen steckte. Sie wissen ja: Nichts hält länger als ein Provisorium.

Wie bringt man nun die Software verschiedener Unternehmen, die bunter zusammengewürfelt ist als jedes Osternest, zur Zusammenarbeit? Jedes Programm hat sein eigenes Datenformat, als „Kommunikationsschnittstelle“ kann man oft bestenfalls die Textdateien bezeichnen, die ausgeworfen und eingelesen werden können – das artet in babylonische Sprachenverwirrung aus.

Dafür gibt es zum einen gewisse Datenformate, die von großen Organisationen (bis hin zu UNO-Abteilungen) als Standards entwickelt wurden, zum anderen Software, die in der Lage ist, Daten von einem ins andere Format umzusetzen. Man könnte hier von Dolmetschern sprechen, die zwischen all den vielen Sprachen und Dialekten übersetzen können. Und wie bei den Dolmetschern der UNO wird meist nicht direkt von Afrikaans in Thai übersetzt, sondern in eine der Standard-Sprachen (bspw. Englisch oder Französisch) und von der in die Zielsprache. In der Welt des EDI heißen die Standards EDIfact, Fortras oder BMEcat, die Äquivalente zu den regionalen Sprachen sind meist CSV-Dateien oder Texte im „Feste Länge“-Format (alias FixRecord), die gerne unter dem Begriff „inhouse“ laufen. Also eben das Format, das im eigenen Hause genutzt wird und sonst womöglich nirgends auf der Welt.

Haben nun beide an der Kommunikation beteiligten Unternehmen solche „Dolmetscher“-Software im Hause, können sie Daten vom eigenen Format in eines der Standard-Formate umsetzen auf beliebigem – elektronischem – Wege an den Partner schicken. Der setzt den Standard wiederum in sein Format um und füttert damit seine Systeme. Die Kommunikation ist somit der Dritte im Bunde, der EDI erst komplett macht. Wie im richtigen Leben: Man muss miteinander reden, sonst geht nichts.

Beispiel 1 – Kurze Frage
Im komplexeren Beispiel zu EAI mussten wir einen Lieferanten fragen, wie lange es denn dauert, bis er uns einen bestimmten Artikel liefern kann, da wir den in einer Kundenbestellung gefunden haben und unser Lager leider keinen mehr vorrätig hat. Für so etwas ist die EDI-Software zuständig (wobei wir schon festgestellt haben, dass es ziemlich unpraktisch ist, EAI und EDI so strikt zu trennen. Ist doch nur eine kurze Frage nach draußen, mitten im EAI-Prozess.).

Die EDI-Software bekommt also, z.B. als SOAP-Anfrage (hier über einen WebService), den Auftrag, beim Lieferanten „Hardwarequelle“ nachzufragen, wie schnell er uns zwei Artikel mit der Artikelnummer „A08/15“ liefern kann. Die Artikelnummer ist bereits die, die der Lieferant benutzt, in unserem System hat der selbe Artikel die Nummer „4711“.

Für solche kurzen Anfragen ist ein WebService die optimale Lösung. WebServices werden via HTTP angesprochen, in einer festgelegten Art und Weise. Das wichtigste daran ist: Man schickt dem WebService die Anfrage als XML-Datei, und er antwortet auch in diesem Format. Um die reine Anfrage bzw. die Antwort wird noch ein sogenannter SOAP-Envelope gepackt, der ein paar Zusatzinfos enthält, das war’s auch schon. Die Antwort kommt auf jeden Fall sehr schnell, und darauf kommt es hier ja an.

Hier das Beispiel, wie unsere EDI-Software vom EAI-System die Anfrage bekommt:

<?xml version=“1.0″ encoding=“UTF-8″?>
<soapenv:Envelope
xmlns:soapenv=“http://www.w3.org/2003/05/soap-envelope“
xmlns:xsd=“http://www.w3.org/2001/XMLSchema“
xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance“>
<soapenv:Header />
<soapenv:Body>
<AnfrageLieferzeit>
<Lieferant>Hardwarequelle</Lieferant>
<ArtNr>A08/15</ArtNr>
</AnfrageLieferzeit>
</soapenv:Body>
</soapenv:Envelope>

Das EDI-System muss jetzt in Erfahrung bringen, wie es denn die Firma „Hardwarequelle“ kontaktieren kann. Diese Informationen können aus einer Datenbank kommen, aus einem SAP-System (ja, das wären eigentlich schon wieder EAI-Themen) oder auch in irgend einer Weise direkt im EDI-System hinterlegt sein. Egal wie, es kommt raus, dass wir den Lieferanten auch wieder über WebService ansprechen können. Wie gesagt, für solche Anfragen ist das optimal, da es einfach schnell geht.

Sparen wir uns ein anderes XML-Beispiel, sagen wir einfach, der Lieferant sichert uns Lieferung in drei Tagen zu. Genauer gesagt, seine IT-Systeme sichern uns das zu. Denn eine Antwort innerhalb einer HTTP-Verbindung stammt sicher nicht von einem Sachbearbeiter, sondern wird vollautomatisch in dessen IT-Landschaft generiert. Auf seiner Seite sind da EDI- und EAI-Prozesse beteiligt. Diese drei Tage melden wir aus unserem EDI-System nun an unsere EAI-Software, damit diese die Bestellung weiter bearbeiten kann.

Beispiel 2 – Kundenbestellung
So eine Kundenbestellung, wie wir sie im EAI-Beispiel angesprochen haben, sollte heute nicht mehr wirklich von einem Sachbearbeiter eingegeben werden. Das ist – nun ja – etwas mittelalterlich. Bestellungen sollten heute elektronisch eintreffen, z.B. als Mail oder über das Bestellformular einer Website. Oder, wenn wir im B2B-Bereich bleiben, per EDIfact-Datei direkt aus dem EDI-System unserer Kunden.

Da trudelt nun also eine Mail ein, an der eine Bestellung im EDIfact-Format hängt. Die Nachrichtenart heißt – raten Sie! – ORDERS. Wie so etwas aussehen kann, ist im Artikel zu EDIfact genauer beschrieben.

Die EDI-Software nimmt sich die Mail vor und holt den Anhang mit der Bestellung heraus. Anhand des Dateinamens oder vielleicht des Betreffs erkennt sie, um was es geht. Zur Not muss sie in den Inhalt schauen, falls die anderen Merkmale nicht ausreichen. Dann liest sie die Daten ein und speist sie ins Auftragserfassungssystem (kurz AES). Ab hier übernimmt unsere EAI-Software, da wir hier bei den Begriffserklärungen ja strikt zwischen beiden trennen. Diese ist irgendwann mit der Bearbeitung fertig, der Auftrag mit allen Lieferzeiten, voraussichtlichem Liefertermin für den Kunden, evtl. Sonderkonditionen usw. steht im AES, und es kann nun eine Auftragsbestätigung mit allem Drum und Dran an den Besteller rausgehen. Da übernimmt dann wieder EDI.

Eine Möglichkeit wäre, dass die EAI-Software aus dem AES alle Daten für die Auftragsbestätigung zieht und als kleine CSV-Datei in ein Verzeichnis legt, aus dem das EDI-System sie wieder ausliest und in ein EDIfact-Dokument einbaut. Der entsprechende Nachrichtentyp heißt in diesem Fall ORDRSP (Die Namen aller Nachrichtentypen haben sechs Buchstaben, dieser Name hier steht für Order Response.).
Ist das ORDRSP erst mal erstellt, bekommt der Kunde eine Mail von uns, die als Anhang diese EDIfact-Nachricht enthält und wahrscheinlich sofort wieder von seinem EDI-System verarbeitet wird. Es lebe die moderne Technik!

Sehen wir uns kurz mal den B2C-Bereich an, also die Kommunikation und den Handel zwischen Unternehmen und Endkunden, wie z.B. Privatleuten.

In diesem Fall gingen sicher keine EDIfact-Dateien hin und her. Wahrscheinlicher ist, dass der Kunde über ein Webformular seine Bestellung macht, z.B. in einem Webshop mit Warenkorb und allem Schnickschnack. Auch er wird zwar eine Auftragsbestätigung erhalten, diese dürfte dann aber eher folgende Form haben:

Sehr geehrte Frau Musterfrau,

wir bedanken uns sehr für Ihren Auftrag und bestätigen hiermit ihre Bestellung.

Artikelnummer Bezeichnung Menge Einzelpreis Gesamtpreis
4711 Nette Überraschung 2 € 9.99 € 19.98

Gesamtsumme: € 19.98
enth. MwSt: € 2.76
Voraussichtlicher Liefertermin: 30.02.2099

Mit freundlichen Grüßen,
Ihr Kramerladen-Team

Die Kommunikation nach außen läuft ganz anders, im Eingang haben wir womöglich eine CSV-Datei, die uns ein PHP-Script des Webshops per FTP liefert, und die Antwortmail enthält keinen EDIfact-Anhang, sondern einen Fließtext. Der Prozess dazwischen allerdings ist derselbe. Deshalb ist es nur sinnvoll, wenn die verschiedenen Aspekte eines solchen Vorgangs möglichst modular aufgebaut sind:

  • Kommunikation über verschiedene Kanäle
  • Einlesen der Daten aus unterschiedlichen Formaten
  • Verarbeitung im Zusammenspiel mit internen Systemen
  • Ausgabe der Antwortdaten in diverse Formate
  • Kommunikation der Ergebnisse nach draußen auf verschiedenen Wegen

Hier der ganze Ablauf noch mal schematisch dargestellt:

EDI-Schema

Einerseits ist eine Trennung der Abläufe des EDI- und des EAI-Bereichs so gesehen ganz sinnvoll, da es das EAI-System nicht im Mindesten interessiert, wie die Aufträge ins AES kamen und wie die Bestätigungen rausgehen, andererseits hat man oft die selben technischen Vorgänge auf beiden Seiten, wie hier zum Beispiel die Kommunikation mit dem AES oder auch mit Datenbanken. Zu allem Überfluss schicken wir eine WebService-Anfrage vom EAI- zum EDI-System, das diese wiederum nach außen zu unserem Lieferanten weiterleitet, nur, um alles zwanghaft getrennt zu halten. Besser ist es da doch, ein System zu haben, das alles kann, und die Modularität eher innerhalb der Abläufe dieses Systems aufzubauen.

Zusammenfassung
EDI steht für alle Vorgänge der automatisierten Kommunikation zwischen den eigenen IT-Systemen und der Außenwelt. Dazu gehört nicht nur die reine Übertragung der Daten (Mail, FTP, WebService, AS2, …), sondern auch die Umsetzung zwischen verschiedenen Datenformaten (oft über Standardformate als Zwischenschritt), die Anreicherung mit zusätzlichen Informationen, der Datenabgleich und das Einpflegen in bzw. Auslesen aus den internen Systemen. Der Mensch sollte hier nur noch überwachende Funktion haben, um bei Fehlern (z.B. durch unsaubere Daten oder Netzprobleme) eingreifen und nach den entsprechenden Korrekturen die Nachbearbeitung anstoßen zu können. EDI- wie EAI-Systeme sollten daher ein übersichtliches Monitoring bieten sowie umfassende Möglichkeiten, auf Fehler schnell und effizient zu reagieren.

Zu EDI gibt es auch noch einen langen Artikel in der Wikipedia.