Zu Beginn dieses Handbuchs wurden u.a. die Begriffe EDI und EAI (Electronic Data Interchange und Enterprise Application Integration) beschrieben. Vereinfacht gesprochen handelt es sich hierbei um den Transport von Daten zwischen verschiedenen Software-Systemen und die Umwandlung dieser Daten in unterschiedliche Formate. Die Unterscheidung zwischen EDI und EAI ist dabei mehr organisatorischer als technischer Natur.
Im klassischen EDI/EAI beschränkt sich die Umwandlung auf syntaktische Änderungen. So wird z.B. aus XML, CSV, EDIFACT,… ein CSV, FixRecord, Excel, IDOC erstellt. Die Feldinhalte werden entweder unverändert übertragen oder formal umgewandelt. Beispiele für formale Umwandlungen sind unterschiedliche Datumsformate, Dezimaltrenner, Füllzeichen, Mengeneinheiten usw.
Mit zunehmender Komplexität der Schnittstellen wachsen jedoch auch die Anforderungen an die inhaltliche Logik der Schnittstellen. Aus diesem Grund werden immer mehr inhaltliche Funktionalitäten in die Schnittstellen verlagert. Die inhaltlichen Funktionalitäten können typische Geschäftslogik betreffen (Artikelnummer, Liefersperre, Lieferdatum prüfen, etc).
In anderen Fällen ist vielleicht eine eigene Logik erforderlich, die ausschließlich für die Rückmeldung von Daten an den Absender gebraucht wird. Zusätzlich können bei der Konvertierung auch Daten erzeugt werden, die die bisher im Unternehmen vorhandene Logik erweitern bzw. ergänzen.
Nachfolgend sind einige Beispiele gelistet, die über den klassischen Begriff von EDI/EAI hinausgehen und die obigen Ausführungen verdeutlichen:
- Referenzdaten prüfen
Bei der Konvertierung der Daten werden Stammdaten wie Artikelnummer und Kundennummer auf Gültigkeit geprüft. Sind enthaltene Werte ungültig, werden die Daten z.B. mit einer Fehlermeldung abgewiesen oder die falschen Daten mit Dummy-Werten ersetzt.
Beim Ersetzen mit Dummy-Werten wird der erhaltene Wert entweder in einem Textfeld ins Zielsystem transportiert oder via Email weitergegeben. Diese Lösung wird angewendet, wenn das Zielsystem Fehler in den Stammdaten nicht mit dem gewünschten Komfort behandeln kann.
- Benachrichtigung an Fachabteilungen
Bei der Konvertierung wird geprüft ob es sich um einen Eilauftrag handelt. Ist dies der Fall, wird zusätzlich zur Konvertierung die Fachabteilung per Email benachrichtigt, um keine Zeit zu verlieren. Diese Lösung wird angewendet, wenn das Zielsystem den Benutzern eingegangene Eilaufträge nicht eigenständig, schnell oder deutlich genug anzeigen kann.
- Anreicherung von erhaltenen Daten
Bei der Konvertierung werden die Daten mit weiteren Daten aus einem internen System angereichert. Beispielsweise werden Daten eines zuständigen Sachbearbeiters beim Partner um die zugehörige Emailadresse ergänzt.
- Aufbau eines Trackingsystems
Bei Unternehmen mit einer heterogenen Softwarelandschaft durchlaufen Aufträge nach dem Erhalt der Bestelldaten verschiedene Programme, bis die Waren schließlich das Unternehmen verlassen. Kommt es dabei zu Fragen nach dem Status des Auftrags, müssen Mitarbeiter diesen umständlich recherchieren. Dieser Aufwand kann vereinfacht werden, indem der Status während der Konvertierung zwischen den verschiedenen Programmen in eine Datenbank geschrieben wird. Die Recherche beschränkt sich damit auf ein einziges System. Auch bietet dies die Möglichkeit, sogar externen Partnern die eigenständige Recherche über ein Web-Interface zu ermöglichen.
- Zwischenspeicherung von Referenzwerten des Partners
Der Partner sendet in seinen Daten Referenzwerte, die in den Rückmeldungen an ihn wieder enthalten sein müssen. Die Referenzwerte werden im Zielsystem nicht gebraucht und es sind auch keine Felder dafür vorhanden.
Bei der Konvertierung werden die Referenzwerte in eine Datenbank zwischengespeichert und bei der Rückmeldung wieder ausgelesen. (siehe oben ‚Anreicherung von Daten‘). Dank dieser Lösung kann man den Missbrauch von Feldern in Schnittstelle und Zielsystem umgehen. Auch ist so eine alternative Anpassung des Zielsystems vermeidbar.
- Kumulierung von Bestellpositionen
Bei der Konvertierung werden z. B. mehrfach vorkommende Artikel in einem Auftrag oder mehrfache Lieferungen an den gleichen Kunden innerhalb einer Übertragung kumuliert. Hierbei handelt es sich um typische Business-Logik, die nur dann in der Konvertierung realisiert werden sollte, wenn das Zielsystem die erforderliche Funktionalität nicht leisten kann.
- Daten für statistische Zwecke protokollieren
Bei der Konvertierung werden zusätzlich Daten wie Volumen, Versicherungswerte, Anzahl Positionen, etc. in eine Datenbank geschrieben. Diese Daten können später mit externen Programmen statistisch ausgewertet werden.
- Zusätzliche Begleitdokumente für EDI-Abläufe erstellen
Bei der Konvertierung werden aus den Daten zusätzlich noch für Menschen lesbare Dokumente wie PDF oder Excel erstellt und an den Partner versendet. Bei manchen Firmen sind solche Dokumente z. B. bei Sammelrechnungen vorgeschrieben.