EAI
In einem Unternehmen sammelt sich im Laufe der Zeit eine ganze Menge Software an. Lagerverwaltung, Auftragsbearbeitung, ERP-System, Lohnbuchhaltung und und und. Oft werden die einzelnen Programme nach und nach eingeführt, jedes Mal das für die
Aufgabe am geeignetsten Scheinende ausgewählt. Dabei stammt fast zwangs-
läufig jedes Programm von einem anderen Hersteller. Und jedes arbeitet mit seinen eigenen Dateiformaten, Datenbanken usw.
Nun wäre es durchaus sinnvoll, verschiedene Programme miteinander in Verbindung zu setzen, da sie eigentlich auch auf – zumindest in der Unternehmenslogik – denselben Daten arbeiten. Beispielsweise wäre es doch super, wenn ein Programm, mit dem
Aufträge erfasst werden, gleich mal bei der Lagerverwaltung nachfragen kann, ob ein bestimmter, eben bestellter Artikel vorrätig ist oder erst neu bestellt werden muss. Dann
könnte man dem Kunden gegenüber gleich eine vernünftige Aussage zur Lieferzeit geben. Und das, ohne dass der Sachbearbeiter erst den Lageristen anrufen und nachfragen muss. Vollautomatisch.
Hier kommt EAI ins Spiel. Denn die Lagerverwaltung und die Auftragserfassung sind nicht die einzigen beiden Systeme, die miteinander reden müssen. Am Ende muss wahrscheinlich jedes IT-System mit mindestens der Hälfte aller anderen reden. Und bevor wir jetzt jedem
die Dialekte (aka Schnittstellen) all der anderen beibringen, wickeln wir diese Kommunikation lieber zentral über ein einziges System, eine Art Dolmetscher, ab. Das ist das EAI-System.
Einfaches Beispiel
Natürlich ist das Beispiel von eben arg klein gewählt, aber als Einstieg genügt es. Nehmen wir also an, ein Sachbearbeiter gibt einen neuen Auftrag ins System ein. Ins Auftragserfassungssystem. Dieses System ist in der Lage, eine Auftragsbestätigung zu produzieren, die zum Kunden gesendet werden kann. Dass beides heute eher automatisiert ablaufen sollte, ist ein anderes Thema (nämlich EDI).
In dieser Auftragsbestätigung soll nun auch der – zumindest annähernde – Liefertermin stehen. Dazu ist es nun wichtig zu wissen, ob alle bestellten Artikel vorrätig sind, oder ob sie evtl. nachbestellt werden müssen. Und wenn sie denn nachbestellt werden müssen, sollte man die Lieferzeit dafür auch gleich in Erfahrung bringen. Aber der Reihe nach.
Der Auftrag kommt also rein. Das Auftragserfassungssystem – nennen wir es kurz AES bekommt also eine Liste von Positionen in die Hand. Unter anderem ist da der Artikel mit der Nummer 4711. Zwei Stück. Die Frage ist: Haben wir zwei Stück auf Lager? Das checkt das EAI-System für uns.
Netterweise arbeitet die Lagerverwaltung mit einer normalen SQL-Datenbank. Ganz egal, ob das eine Oracle ist, eine MySql oder auch eine MSSQL. Wir müssen also lediglich ein Statement an die Datenbank abfeuern, das uns den aktuellen Bestand des betreffenden Artikels liefert. Wer SQL kann, wird’s verstehen:
SELECT bestand FROM lagerbestaende WHERE artikelnummer = “4711“
Für die anderen die Übersetzung: Gib mir aus der Tabelle „lagerbestaende“ den Wert
„bestand“, und zwar aus der Zeile mit der Artikelnummer „4711“. Die Datenbank liefert nun z.B. eine 543 zurück. Heißt, da haben wir aber mehr als genug vorrätig. Also können wir für diese Position eine sehr kurze Lieferzeit angeben, da wir die zwei Stück noch heute auf die Reise schicken könnten.
Das ist EAI. Simpel, nicht wahr?
Wichtig ist: Das AES weiß nichts vom LVS (Lagerverwaltungssystem) oder seiner Datenbank. Es gibt nur auf irgendeine Weise dem EAI-System Bescheid (oder das bringt’s selbst in Erfahrung), dass ein neuer Auftrag da ist. Das macht dann den Abgleich mit dem LVS und gibt die Informationen an das AES zurück, damit das eine Auftragsbestätigung mit sinnigen Lieferzeiten auswerfen kann.
Na gut, fast zu simpel! Es kann durchaus sein, dass die Lagerbestände nicht so schön einfach aus der Datenbank zu holen sind. Oder diese meldet, dass nicht mehr genug Stück vor-
rätig sind. Sagen wir mal, Artikel 4711 ist aus und muss nachbestellt werden. Nun wird die Sache schon komplizierter.
Komplexeres Beispiel
Artikel 4711 ist aus. Wir müssen ihn bei unserem Lieferanten nachbestellen. Dummerweise führt der ihn aber unter seiner eigenen Artikelnummer. Die kennt jedoch unser AES nicht. Ergo muss es nachdem unser LVS den Kopf geschüttelt hat, erst mal die Artikelnummer des Lieferanten für diesen Artikel in Erfahrung bringen. Und natürlich, wer uns das Ding denn liefern soll.
Machen wir es uns noch einmal einfach und nehmen wieder eine Datenbank an, in der die Umsetzung steht. Es ist diesmal eine andere Datenbank, aber dasselbe Prinzip. Das Statement spare ich mir, wir machen hier ja keinen SQL-Kurs. Retour kommt eine Artikelnummer „A08/15“ und der Lieferant „Hardwarequelle“, weil es sich bei dem Artikel um Hardware handelt. Genau so gut könnten diese Informationen auch aus einem SAP kommen, dann liefe die Anfrage über einen RFC-Aufruf.
Nun haben wir uns in eine blöde Situation manövriert, weil wir nämlich eigentlich über EAI schreiben wollten, also die Integration interner Systeme, nun jedoch die Anfrage bei der Firma Hardwarequelle ansteht, die die Grenzen der Firma verlässt und somit zum Bereich EDI gehört. Das ist das Doofe mit diesen Dingern, die lassen sich nicht so richtig trennen.
Wir könnten jetzt natürlich folgendes machen: Wir nehmen an, dass wir zusätzlich zu unserer EAI-Software auch noch eine EDI-Software haben und fragen nun bei der an. Die soll bitte für uns bei der Hardwarequelle anfragen, wann Artikel 4711 alias A08/15 denn an uns geliefert werden kann. Unsere EDI-Software ist dafür mit einer SOAP-Schnittstelle ausgerüstet, ansprechbar als WebService. Also basteln wir uns eine kleine Anfrage:
<?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>
Die EDI-Software leitet die Anfrage, womöglich als WebService-Aufruf, an das System der Hardwarequelle weiter und liefert uns das Ergebnis zurück. Netterweise muss sie dazu erst einmal nachschauen, was das denn für ein Laden ist, wie man den erreichen kann usw. Diese Infos holt sie womöglich aus einer Datenbank, die … wir doch genau so gut selbst hätten abklappern können!
Wenn Sie sich jetzt denken „Was für ein Quatsch, zwei Systeme, wenn die Arbeit doch von einem erledigt werden kann!“, dann liegen Sie richtig. Unser EDI-System soll nun also auch Datenbanken abfragen können wie das EAI-System? Das EAI-System kann WebServices abfragen wie ein EDI-System? Dann sind doch zwei unterschiedliche Systeme völliger Unsinn.
Eben drum sollte eigentlich alles in einem System zusammengefasst sein. Aber es geht ja zunächst darum, die Begrifflichkeiten zu erklären, und die machen eben einen Unterschied zwischen der Integration von Systemen innerhalb einer Firma und der Kommunikation zwischen Systemen verschiedener Firmen. Dass beides technisch so eng verwandt ist und eine Trennung in verschiedene Systeme oft Unfug, interessiert die Theorie nicht sonderlich.
Um das Beispiel noch kurz zu Ende zu führen: Nach der Bestandsanfrage in unserem eigenen LVS und/oder beim Lieferanten kann der Auftrag weiter bearbeitet werden, indem wir gleich die passende Lieferzeit reinschreiben und eine Auftragsbestätigung mit voraussichtlichem Liefertermin an den Besteller schicken. Oh, hoppla, das ist dann wieder EDI. 🙂
Alles in Allem
Man kann also sagen, EAI ist die Verknüpfung mehrerer interner IT-Systeme miteinander, und zwar nicht in vielen 1:1-Beziehungen, sondern eher stern- oder eben busförmig. Man spricht in diesem Zusammenhang gerne von „hub and spoke“, zu Deutsch „Nabe und Speiche(n)“, wobei letztlich das EAI-System die Nabe darstellt, die über die vielen Speichen mit den verschiedenen Systemen in ihrer IT-Landschaft kommuniziert.