Eher interne Wege/Quellen/Senken

Allgemeines
EDI-Systeme dienen dazu, interne und externe Systeme miteinander kommunizieren zu lassen, EAI-Systeme konzentrieren sich auf die internen Systeme, und ETL/ELT findet praktisch ausschließlich zwischen Datenbanken statt. Alle drei Konzepte brauchen also Möglichkeiten, die Systeme in Ihrem Hause, wie z.B. Datenbanken und ERP-Systeme, mit Daten zu versorgen oder Daten aus ihnen zu erhalten.
Ohne Anspruch auf Vollständigkeit wollen wir hier zumindest die wichtigsten dieser Systemtypen und Kommunikationsformen vorstellen. Sicher gibt es noch mehr in der da draußen, aber weit über 90 Prozent sollten hier abgedeckt sein.
Und vergessen wir nicht: Auch mit den eigenen Rechnern kann man so kommunizieren wie mit denen draußen im Netz, also kommen auch noch die meisten der unter „Eher extern“ aufgeführten Kommunikationsarten dazu (auch, wenn in der Praxis wohl niemand zwei Rechner im eigenen Netz via OFTP verbinden würde…).

Dateisystem
Das Dateisystem ist natürlich immer am leichtesten zu erreichen, erst recht das lokale. Hier kann man wunderbar Daten zur Verarbeitung bereitstellen und auch hinterher wieder die Ergebnisse ablegen. Vorausgesetzt natürlich, die verschiedenen Systeme, die miteinander kommunizieren, haben auch alle Zugriff auf das selbe Dateisystem.
Nun werden aber weder im EDI- noch im EAI-Umfeld alle relevanten Programme auf dem selben Rechner laufen. Die nehmen sich doch nur gegenseitig die Leistung weg, mal ganz zu schweigen von dem Risiko, dass mit einem einzigen Rechner auf einen Schlag alle geschäftskritischen Prozesse ausfallen könnten.
Eine Lösung hierfür ist sicher ein SAN, ein Storage Area Network, auf dem alle wichtigen Prozesse ihre Daten speichern. Da hat man meist gleich noch Hochverfügbarkeit usw. mit drin. Aber es geht auch eine Nummer kleiner, mit dem NAS, dem Network Attached Storage. Das ist letztlich nichts anderes als der gute, alte Fileserver, auf den mittels entsprechender Protokolle wie NFS oder SMB zugegriffen wird. Na gut, nicht nur der Fileserver, die Zugriffe erfolgen oft kreuz und quer durch’s ganze Firmennetz.

Das lokale Dateisystem ist wohl kaum einer näheren Betrachtung wert, und wenn Sie tatsächlich ein SAN aufbauen wollen, ist das ein zu großes Unterfangen, als dass man es hier nennenswert anschneiden könnte.
Interessant ist für uns eigentlich vor allem, welche Ansprüche an eine EDI-/EAI-Software zu stellen sind, die auf die Platten entfernter Rechner zugreifen muss.

NFS

NFS

NFS ist das alte Network File System aus der Unix-Welt. Es ist inzwischen ziemlich in die Jahre gekommen und weist (aus historischen Gründen) auch nicht gerade hohe Sicherheitsstandards auf. Allerdings ist die aktuelle Version 4 gegenüber dem der verbreiteten Version 3 stark verbessert und hat hier wieder gewaltig aufgeholt.
Wenn Sie in einer Unix/Linux-Umgebung unterwegs sind, können Sie sich das Leben mit NFS aber recht einfach machen. Sie mounten einfach die entsprechenden Netzlaufwerke (am besten automatisch schon beim Booten)  und greifen in Ihrer Software dann auf diese genau so leicht zu wie auf lokale Partitionen und Verzeichnisse. Und eigentlich beherrschen auch Windows-Server NFS, es wird nur kaum genutzt. Wenn der entfernte Rechner mit Windows läuft, können Sie stattdessen über Samba dessen Freigaben ebenso mounten, da gibt es erst mal kaum Unterschiede (von einigen Feinheiten im Betrieb dann mal abgesehen, das ist dann aber SMB).
Ihr EDI-/EAI-System muss also, wenn es unter Unix/Linux läuft, weiter nichts beachten, es sieht genau genommen nicht mal, dass ein Verzeichnis lokal und das andere eigentlich auf einem Server im Keller liegt. Ob da nun /user/local/data/Datei.txt steht oder /mount/fileserver/commondata/Datei.txt, der Zugriff erfolgt für die Anwendung selbst identisch.

SMB

SMB

Mittels SMB realisiert in erster Linie Windows sein Netzwerk-Dateisystem. Hier ist die Sache etwas komplizierter als bei NFS-Mounts. Sie kennen das berühmte, verbundene Netzlaufwerk. Meist werden dafür Buchstaben weit hinten im Alphabet genutzt (besonders gerne das T), und dann zeigt eben Laufwerk T: auf ein freigegebenes Verzeichnis irgend eines entfernten Rechners. Das ist eine nette Lösung für einen Bürocomputer, an dem man sich erst mal einloggt, dann (meist automatisch) die Netzlaufwerke verbunden werden, und wenn man dann damit arbeiten will, ist alles da.
Für Serverprozesse, die meist als Windows-Dienst auch ganz ohne User-Login laufen müssen, ist das unbrauchbar. Solche Laufwerksbuchstaben wie T: sind immer auf den eingeloggten Benutzer bezogen und existieren für einen Prozess, der beim Rechnerstart ganz automatisch mit anläuft, gar nicht. Hier ist eine andere Technik gefragt, aber auch die kennen Sie schon aus Ihrem Dateimanager (aka Windows Explorer). Man gibt den Server und den Freigabenamen des gesuchten Verzeichnisses direkt an, etwa so:

\\servername\freigabename\pfad\Datei.txt

Mit dieser sogenannten UNC-Notation kann man jeden im Netz bekannten Rechner erreichen und alle dort freigegebenen Verzeichnisse ansprechen (unter Unix geht das übrigens auch, da werden dann normale Slashes / verwendet).
Nun braucht man aber für SMB auch eine Benutzer-Authentifikation. Während man NFS-(oder Samba-)Mounts beim Bootvorgang erledigt und sich dabei entsprechend zu erkennen gibt (was bei NFSv3 kaum der Rede wert ist), erwartet ein Windows-Rechner die Authentifikation des Users, wenn er auf die Freigabe zugreifen will.
Eine Möglichkeit dieses Problem zu lösen besteht darin, die entsprechende Software mit dem Benutzerkonto eines Domänen-Administrators laufen zu lassen. Greift sie dann auf den UNC-Pfad zu, gibt sie dabei die Identität ihres Benutzers an. Ist dieser auch auf dem entfernten Rechner bekannt, gewährt dieser den Zugriff. Allerdings ist nicht jeder System- und Netzwerk-Admin damit einverstanden, irgend welche Programme im Kontext eines so mächtigen Users laufen zu lassen.
Die Alternative ist, dass sich die Software bei jedem Zugriff mit einem vorgegebenen Benutzer anmeldet. Das kann dann zum Beispiel so aussehen:

Angaben für eine SMB-Authentifikation in Lobster data

Natürlich muss die Software dazu in der Lage sein…

Der kleine Unterschied

Der kleine Unterschied

Im Prinzip kann eine Software also auf freigegebene Verzeichnisse entfernter Rechner genau so leicht zugreifen wie auf die lokalen Platten. Ein paar kleine Einschränkungen gibt es dann aber doch.
Die einfachste davon ist, dass der Server, auf dem das gewünschte Verzeichnis liegt, gerade nicht läuft oder durch eine Netzwerkstörung nicht erreichbar ist. Das kann einem allerdings beim Zugriff z.B. via FTP genau so passieren.
Eine andere Einschränkung ist die, dass man sich nicht zu sehr der Illusion hingeben sollte, dass man es mit einem lokalen Verzeichnis zu tun hat. Nicht nur ist die Zugriffszeit schlechter, da ja alles über’s Netz geht, man kann sich auch nicht auf die selben Mechanismen verlassen, die bei lokalen Laufwerken das Leben einfacher machen.
Als einfaches Beispiel seien File Events genannt. Sie kennen das vielleicht: Sie haben den Windows-Explorer offen, irgend ein Prozess legt eine neue Datei ab oder löscht eine weg, und Sie sehen die Veränderung sofort, auch ohne erst zu aktualisieren. Hier wurde das Ereignis (Datei hinzugekommen/gelöscht) als Nachricht ins System geschickt, und der Explorer konnte sofort darauf reagieren und die Anzeige aktualisieren. Über das Netz funktioniert so etwas nur sehr unzuverlässig. Der Grund mag durchaus sein, dass man die Netzwerklast nicht mit solchen Kleinigkeiten hochtreiben will. Der Nachteil ist, dass sich eine Software plötzlich, nur, weil es sich um eine Netzwerkressource handelt, auf diesen Mechanismus nicht mehr verlassen kann.

Nutzen für EDI/EAI

Nutzen für EDI/EAI

Beim Datenaustausch von EDI-/EAI-Systemen mit anderen Prozessen sind lokale oder Netzwerk-Dateisysteme erst mal eine einfache Lösung. Allerdings sollte man dabei nicht vergessen, dass man dem betreffenden System zwar eine Datei zur Verarbeitung bereitstellen kann, es aber selbst nachsehen muss, ob es neue Arbeit gibt (File events sind, wie erwähnt, nicht verlässlich). Das bedeutet, die diversen Empfänger müssen regelmäßig „ihre“ Verzeichnisse nach neuen Dateien durchsuchen, ganz ähnlich wie beim Datenaustausch mittels FTP. Im eigenen Firmennetz muss man sich aber normalerweise wenigstens keine Sorgen um abgehörte oder gar manipulierte Übertragungen machen.
Manche etwas einfachere Software bietet schlicht nur eine solche Dateischnittstelle – oder man kann sie zumindest irgendwie dazuprogrammieren. Da bleibt einem dann also gar nichts anderes übrig. Gibt es aber andere Möglichkeiten, die gewährleisten, dass angelieferte Daten sofort in die Verarbeitung gehen, sollte man doch lieber darauf zurückgreifen.

SAP ALE und RFC
Eines vorweg: Im Folgenden geht es um die „großen“ SAP-Systeme, ehemals SAP R/3 genannt, heute Business Suite. Die kleinere Lösung SAP Business One ist ein Thema für sich, das hier nicht behandelt werden soll.

Vielleicht haben Sie den Abschnitt über die IDocs schon gelesen. Hier wird von zwei Grundformaten gesprochen, dem FixRecord- und dem XML-IDoc. Die XML-Variante hat mit SAP XI bzw. PI zu tun, das ist eine von SAP mitgelieferte Art von Schnittstelle zur Außenwelt. Hier hat man es einfach mit XML als grundlegendem Format und z.B. HTTP(S) als üblichem Kommunikationsprotokoll zu tun (natürlich geht auch anderes). Auch diese interessiert uns an dieser Stelle nicht besonders, da es sowohl zu XML wie auch zu HTTP bereits allgemeine Artikel gibt.

IDocs, die auf dem FixRecord-Format basieren, werden dagegen über eine ganz eigene, von SAP zur Verfügung gestellte, Schnittstelle transportiert: ALE
ALE steht für Application Link Enabling. Es diente ursprünglich dazu, mehrere logisch zusammengehörige SAP-Installationen miteinander zu vernetzen. Oder, um SAP selbst zu zitieren:
„Das Grundkonzept von Application Link Enabling ist die Gewährleistung einer verteilten, aber integrierten SAP-Installation. Dies umfaßt einen betriebswirtschaftlich kontrollierten Nachrichtenaustausch bei konsistenter Datenhaltung auf lose gekoppelten SAP-Anwendungssystemen.“ (Zitat siehe hier)
Allerdings kann diese Schnittstelle auch zur Kommunikation mit Fremdsoftware genutzt werden. Diese muß in der Lage sein, ALE sauber zu bedienen.
Eine Ebene tiefer wiederum liegt RFC, das steht für Remote Function Call. ALE baut letztlich auf RFC auf, so sind zum Beispiel die beiden wichtigsten Funktionsbausteine (RFCs), die von ALE genutzt werden, IDOC_INBOUND_ASYNCHRONOUS (zum Einliefern von IDocs in SAP) und IDOC_OUTBOUND_ASYNCHRONOUS (über den SAP IDocs nach draußen gibt). Es gibt aber noch eine ganze Menge mehr. Letztlich muss auch eine Fremdsoftware nicht einfach nur ALE, sondern eben RFC beherrschen.

RFC

RFC

Funktionen (oder in SAP-Sprache Funktionsbausteine), die man von außen aufrufen kann, gibt es in Hülle und Fülle. Und was nicht von SAP mitgeliefert wird, kann man dazuprogrammieren. Dafür gibt es wiederum die SAP Consultants (auch in Hülle und Fülle). Oder natürlich, Sie haben einen Spezialisten im Haus.
Oben wurden schon zwei solche Funktionen genannt:

  • Über IDOC_INBOUND_ASYNCHRONOUS kann ein IDoc von außen ins SAP eingeliefert werden, zum Beispiel ein neuer Auftrag.
  • Über IDOC_OUTBOUND_ASYNCHRONOUS wirft SAP ein IDoc aus, das zum Beispiel von einer EDI-Software konvertiert und versendet werden soll.

Es gibt noch andere, wichtige RFCs. Zum Beispiel den RFC_READ_TABLE, um sich schnell mal ein paar Daten aus einem SAP-System zu besorgen. Der kann eine ganze Menge, man kann über ihn auch herausbekommen, welche IDoc-Typen es in einem SAP-System überhaupt gibt oder welche Erweiterungen zu diesen bekannt sind. Auch Beschreibungen dazu lassen sich erfragen.

Aber RFCs existieren nicht nur im SAP-System selbst. Auch eine angeschlossene Fremdsoftware (wie z.B. ein EDI- oder EAI-System) kann RFCs bereitstellen, die wiederum das SAP-System ansprechen. So kann also diese Form der Kommunikation in beide Richtungen erfolgen.

ALE

ALE

ALE ist sozusagen eine Zwischenschicht zwischen reinen RFCs und der Außenwelt. Fremdsoftware oder andere SAP-Installationen, die IDocs mit einem SAP-System austauschen wollen, greifen auf ALE zurück. Dieses verbirgt einige Feinheiten der eigentlichen RFC-Aufrufe, die es letztlich durchführt. Und eine solche Fremdsoftware wird in vielen Fällen eben ein EDI- oder EAI-System sein.
SAP selbst spricht auch von Translatoren, die sich auf der einen Seite via ALE mit dem SAP-System unterhalten und auf der anderen Seite mit irgendeiner anderen Software kommunizieren. An einen solchen Translator werden gewisse Anforderungen gestellt (siehe auch hier). Er muss:

  • automatisch Strukturbeschreibungen von IDocS in seine eigenen Strukturdefinitionen übernehmen können.
  • ein IDoc vom SAP-System übernehmen und die Informationen entsprechend seiner Strukturdefinitionen interpretieren können.
  • ausreichend mächtige Mapping-Funktionalitäten bieten (also die Konvertierung zwischen Datenformaten beherrschen).
  • erzeugte IDocs an das SAP-System übergeben können.

Alles in allem wird also neben einer vernünftigen Kommunikation mit dem SAP-System noch die einfachste Grundfunktionalität einer EDI- bzw. EAI-Software gefordert.
Wenn Sie auf der Suche nach einer solchen Software sind und ein SAP-System einsetzen (oder dies auf Sie zukommen könnte), achten Sie darauf, dass die Software in der Lage ist, SAP ALE und RFC zu „sprechen“ und oben genannte Punkte erfüllt.

Für Software, die diese beiden Schnittstellen nutzen wollen, bietet SAP bereits Bibliotheken von Routinen an, die Programmierer nutzen können. Diesen sogenannten Connector gibt es für verschiedene Programmiersprachen, z.B. Java oder .NET. Diese wiederum nutzt dann der Hersteller der EDI/EAI-Software.

Eine recht ausführliche (und ziemlich technische) Darstellung von ALE finden Sie bei SAP selbst, inklusive Hinweisen zur Programmierung auf SAP-Seite.

Datenbanken
Datenbanken stehen für gewöhnlich nicht einfach so für sich in der Gegend herum. Vielmehr dienen sie als Unterbau für die verschiedenen Systeme, die in einem Betrieb laufen. Ob großes ERP oder kleine Lohnbuchhaltung, kaum eine Software setzt heute noch auf Datenhaltung im Dateisystem. Statt dessen werden die Fähigkeiten eines Datenbanksystemes genutzt. Manche Programme stellen sehr spezielle Anforderungen an die Datenbank oder arbeiten gar nur mit einem einzigen Produkt zusammen, andere sind da flexibler.
Stand der Technik ist heute nach wie vor das RDBMS, das Relationale Datenbank-Management-System. Anders gesagt, es sind Datenbanken, die mittels SQL (der Structured Query Language) angesprochen werden. Es gibt auch andere Ansätze, z.B. die Objektorientierten Datenbanken, die aber eher ein Nischendasein fristen. Relationale Datenbanken sind nun mal für fast alles verwendbar und ungeschlagen, wenn es darum geht, enorme Datenmengen zu schlucken und zu verwalten.

Zugriff

Damit ein Programm seine Daten in einem Datenbanksystem verwalten kann, ist eine Schnittstelle zwischen beiden nötig. Auf Windows-Systemen üblich ist ODBC (Open Database Connectivity), das es auch unter Unix/Linux gibt. Plattformunabhängig ist man mit JDBC (Java Database Connectivity), dafür muss die Software jedoch in Java geschrieben sein. Jede ernstzunehmende Datenbank stellt heute sowohl ODBC- als auch JDBC-Treiber zur Verfügung. Allerdings gibt es oft APIs (Application Programming Interfaces), also direkte Programmierschnittstellen, über die Programme auf eine Datenbank zugreifen können. Das aber setzt eine sehr enge Verbandelung zwischen Software und Datenbank voraus, die man eigentlich eher meiden sollte. Nutzt man die standardisierten Schnittstellen ODBC und JDBC, lässt sich dagegen das DB-System theoretisch einfach austauschen, ohne dass die darüber setzende Software überhaupt etwas davon merkt. Theoretisch. In der Praxis unterstützen Datenbanken eben nicht nur das reine Standard-SQL, sondern haben immer auch spezifische Eigenheiten. Das fängt bei kleinen Unterschieden in der Notation der SQL-Statements an und endet noch lange nicht bei der Aufruf-Syntax von Stored Procedures, also kleinen Progrämmchen, die in einer Datenbank-eigenen Sprache direkt im DB-System selbst geschrieben sind, um dort nützliche Arbeiten zu übernehmen. Bedient sich eine Software irgendwelcher spezifischer Features eines bestimmten DB-Systems, ist es mit dem einfachen Wechsel schon wieder Essig.
Aber das hat jetzt relativ wenig mit EDI und EAI (oder auch ETL) zu tun.

Datenbanken und EDI/EAI/ETL

Datenbanken und EDI/EAI/ETL

Software aus diesem Bereich hat die Aufgabe, viele unterschiedliche Systeme miteinander zu verknüpfen. Ein solches Programm darf also per se keine Sonderwünsche bzgl. der angesprochenen Datenbanken haben. Es muss vielmehr in der Lage sein, möglichst viele unterschiedliche Datenbanksysteme anzusprechen. Sicher kann auch das Programm selbst einiges in eigenen Datenbanktabellen ablegen, aber da es für seine tägliche Arbeit sehr flexibel sein muss, wäre es eigenartig, wenn es für die eigenen Daten eine Extrawurst verlangt.
Kurz und gut: Die Systeme, um die es hier geht, müssen ODBC und/oder JDBC beherrschen. Für ganz besonders eigenwillige Datenbanken, die womöglich nur via API ansprechbar sind, kann man zur Not noch etwas „dranstricken“, aber der Standard muss abgedeckt sein. Das Tool hat sich nach den Gegebenheiten in Ihrer Firma zu richten, nicht umgekehrt.

Allerdings sollten Sie nicht euphorisch die Datenbanken aller möglichen Programme mit einem eventuell neu angeschafften EDI- oder EAI-Programm anzapfen und wie wild Daten hineinschreiben. Solange Sie nur lesen, kann wenig passieren, aber komplexere Software (von etwas so großem wie einem SAP ERP mal ganz zu Schweigen) mag es gar nicht, wenn man an ihr vorbei einfach in ihren Tabellen herumpfuscht. Zu viele Abhängigkeiten sind zu beachten, da können Sie sich ganz schnell etwas „zerschießen“. Hier sind andere Schnittstellen zu bevorzugen – sofern sie existieren.
Auch, wenn Sie ETL-Prozesse aufsetzen wollen, sollten sie wirklich wissen, was Sie tun.

Sei’s drum, alleine für Lookups (also das Nachsehen von Informationen, zum Beispiel das Auslesen einer Adresse zu einer Kundennummer) ist der direkte Zugriff auf Datenbanken einfach eine feine Sache. Und da Sie womöglich nicht nur ein einziges Datenbanksystem im Hause haben, sollte sich der Zugriff auf die Systeme nicht allzu schwierig gestalten. Wenn Sie einen halben Tag damit verbringen, Zugriff auf eine weitere Datenbank zu erhalten oder bei der Definition jedes neuen Prozesses wieder alles einzeln konfigurieren müssen, passt was nicht. Auch sollte es möglich sein in einem Prozess mehrere, unterschiedliche Datenbanken anzusprechen, die jeweils Teile der benötigten Daten beinhalten.
Ist das DB-System selbst erst mal angesprochen, muss man sich mit den Tabellen herumschlagen. Das kann einfach sein oder kompliziert, je nach Software. Je mehr Unterstützung Sie hierbei von Ihrer Software erhalten, desto besser können Sie sich auf die eigentliche Definition eines EDI- oder EAI-Prozesses konzentrieren.

Bleibt noch eine Sache zu erwähnen: Wenn man von Datenbanken spricht, spricht man auch ganz schnell mal von Massendaten. Da werden ganze Artikelstämme hin und her geschaufelt, und auch der Kundenstamm ist hoffentlich groß; da prasseln im Sekundentakt Aufträge, Rechnungen, Lieferscheine und und und herein, die entweder direkt in die verschiedenen Datenbanken geschrieben oder daraus gelesen werden, oder die zumindest mengenweise Lookups erfordern. All das muss performant ablaufen. Datenbanken sind normalerweise auf Performance getrimmt, aber auch das Programm, das sie anspricht, muss mit diesen Datenmengen klarkommen. Auch Millionen von Datensätzen müssen klaglos ausgelesen, verarbeitet und gespeichert werden.

Fazit

Fazit

Fassen wir einfach mal kurz zusammen, was eine Software für EAI, EDI oder ETL (oder alles zusammen) im Datenbankbereich bieten sollte:

  • Zugriff auf (annähernd) beliebige Datenbanken via ODBC und/oder JDBC
  • Einfache, schnelle Anbindung neuer Datenbanksysteme
  • Unkomplizierter Zugriff nicht nur auf die DB-Systeme, sondern auch auf die Tabellenstrukturen darin
  • Einfache Methoden sowohl zum Auslesen und Speichern größerer Datenmengen als auch für schnelle Lookups oder kleinere Insert-/Update-Statements, nicht zu vergessen zum Aufruf von Stored Procedures
  • Performante Bearbeitung auch wirklich großer Datenmassen
  • Die Fähigkeit, Daten aus verschiedenen Datenbanken zu sammeln und gemeinsam zu verarbeiten

Auch, wenn Sie in einem ersten Schritt noch nicht mit direktem Datenbank-Zugriff rechnen, achten Sie trotzdem bei der Auswahl eines Produktes darauf, dass es diesen Anforderungen genügt. Wenn Sie es nicht tun, und sich später eine solche Aufgabe ergibt, stehen Sie womöglich mit einem Fehlgriff da. Außerdem lassen sich Datenbanken manchmal ganz wunderbar als Hilfsmittel in EDI- und EAI-Prozessen nutzen, um die verarbeiteten Daten zwischenzuspeichern und sich danach – zum Beispiel mittels „order by“ sortiert – wiederzuholen.

Message Services
Message Service ist ein sehr allgemeiner Begriff. So ein Message Service dient schlicht dazu, Nachrichten zwischen diversen Systemen auszutauschen, die voneinander im Prinzip gar nichts wissen müssen. Jedes angeschlossene System schickt einfach Nachrichten an diesen Service, die von anderen Systemen empfangen werden. Und jedes System, das solche Nachrichten empfangen will, registriert sich für bestimmte Kanäle oder Themen. Das Interessante dabei ist, dass der Sender gar nicht genau wissen muss, wer seine Nachricht empfängt, ja oft nicht einmal mitbekommt, ob sie überhaupt empfangen wurde. Und wie die Nachricht letztlich verarbeitet wurde, interessiert ihn eigentlich auch nicht. Das entkoppelt die verschiedenen Systeme voneinander, logisch und auch zeitlich. Die Nachricht wird dem Message Service übergeben, und gut.

Grundlegende Varianten der Nachrichtenverteilung

„Kanäle oder Themen“ war jetzt etwas kurz gehalten. Genauer gesagt gibt es bei Message Services verschiedene Wege, Nachrichten zu verteilen. Im Großen und Ganzen kann man folgende Ansätze unterscheiden:

  • Queues: Nachrichten werden in Warteschlangen gestellt und der Reihe nach (FIFO-Prinzip) an interessierte Empfänger verteilt. Dabei kann es mehrere mögliche Empfänger pro Nachricht geben, aber nur einer davon erhält eine bestimmte Nachricht auch wirklich.
  • Publish/Subscribe: Nachrichten werden in einem bestimmten Pool versenkt, und jeder Empfänger, der sich für diesen Pool interessiert, erhält die zugehörigen Nachrichten. Man kann auch Broadcasting dazu sagen.
  • Routing: Ähnlich dem Publish/Subscribe-Verfahren, aber hier bekommen die Nachrichten noch eine zusätzliche Eigenschaft mit, den sogenannten Routing Key. Die möglichen Empfänger interessieren sich nur für Nachrichten mit bestimmten Keys. Sie filtern sozusagen für sie interessante Nachrichten heraus. Diese Keys sind völlig frei wählbar. Und ein Empfänger kann sich durchaus für mehrere Keys interessieren.
  • Topics: Ein bisschen ähnlich wie Routing. Nur, dass Topics nicht nur einen einzelnen Wert beinhalten, sondern aus mehreren Teilen bestehen. Beispielsweise „Erde.Europa.Deutschland“ (Trennzeichen ist hier der Punkt) oder „Politik.Wirtschaft.Deutschland“. Empfänger können sich nun für das exakte Topic registrieren oder für einen Teil davon, etwa „Erde.Europa.*“ (alles, was zu Erde.Europa gehört, der * ersetzt ein Wort), „Politik.#“ (alles Politische, das # ersetzt beliebig viele Worte) oder auch „#.Deutschland“ (egal, ob es um die geografische oder die politische Einteilung handelt).
  • RPC: Remote Procedure Call. Eine Message fordert die Ausführung einer bestimmte Prozedur auf einem anderen Server an und teilt dabei auch gleichzeitig mit, an wen anschließend das Ergebnis geschickt werden soll. Empfänger registrieren sich sinnigerweise auf Nachrichten, für die sie auch die entsprechenden Prozeduren bereitstellen.

Mehr wollen wir nicht über die Arbeitsweise von Message Services sagen. Wer mehr wissen will, kann sich das Tutorial von Rabbit MQ anschauen, das ist ein Message Service Provider. Interessanter ist eigentlich, was es für Message Services gibt. Kurze Antwort: Viele.
Da ist zum Beispiel der Java Message Service JMS. Das ist eine API, also eine Programmierschnittstelle, die alle wichtigen Funktionen für den Aufbau eines Message Service bereitstellt. Eine verbreitete Implementierung hiervon ist Apache ActiveMQ, es gibt aber einige Dutzend weitere.
Aber nicht nur mit Java kann man Message Services bereitstellen bzw. implementieren, auch viele andere Programmiersprachen sind dafür geeignet. Dementsprechend gibt es Message Services wie Sand am Meer. Womit sich ein Problem auftut: Eigentlich sollte so ein Message Service ja gerade so flexibel wie möglich sein, um beliebige Systeme als Sender und/oder Empfänger von Nachrichten anbinden zu können. Deshalb bietet zum Beispiel das bereits genannte Rabbit MQ Schnittstellen zu mehr als einem halben Dutzend Sprachen. Neben der Anbindung diverser Programmiersprachen gibt es noch etwas, das einen Message Service flexibel machen kann, nämlich eine Schnittstelle, die nicht per Programmierung, sondern einfach über das Netz angesprochen wird. Ein Vertreter dieser Art Protokolle ist STOMP (Simple Text Oriented Protocol), ein anderer AMQP, das Advanced Message Queuing Protocol. Letzteres ist kein Text-, sondern ein binäres Protokoll und kann dementsprechend auch mehr als STOMP. Sehen wir es uns noch etwas genauer an:

AMQP

Die reale, serverseitige Implementierung eines Message Services nennt man auch „Broker“. Mit welcher Technologie dieser Broker unter der Haube arbeitet, sollte nach außen hin verborgen bleiben. Stattdessen soll er eine Schnittstelle bieten, über die Nachrichten von Clients angeliefert bzw. an diese ausgeliefert werden. AMQP ist eine solche Schnittstelle. Sie wurde von einem ziemlich großen Firmenkonsortium entwickelt und ist inzwischen auch ein OASIS-Standard. Einer der Vorzüge von AMQP: Es kostet nichts. Jeder darf in seinem Broker oder seinem Client das Protokoll implementieren und nutzen. Ein anderer Vorteil: Immer mehr Broker (wie z.B. Rabbit MQ oder auch Apache ActiveMQ) nutzen diese Schnittstelle. Sollten Sie bereits einen Message Service in Ihrem Hause betreiben, stehen die Chancen sehr gut, dass es auch eine AMQP-Anbindung dafür gibt. (Hier übrigens noch der Wikipedia-Artikel zu AMQP)
Clients und Server (alias Broker) kommunizieren bei AMQP über TCP. Wer am jeweils anderen Ende sitzt und wie (z.B. in welcher Sprache) derjenige implementiert ist, spielt keine Rolle. Das ist im Prinzip genau so wie bei Webservern und Browsern. Also eine ideale Voraussetzung für die Vernetzung unterschiedlicher Systeme: was uns zum eigentlich wichtigen Punkt bringt:

Message Services und EDI/EAI

Was genau hat denn nun das Thema Message Services auf diesen Seiten zu suchen?
Nun ja, an sich ist ein Message Service die ideale Möglichkeit für Systeme innerhalb eines Firmennetzes miteinander zu kommunizieren. Okay, SAP bietet sein ALE als direkte Kommunikationsform an, das ist aber eben sehr SAP-spezifisch. Andere Produkte stützen sich auf HTTP oder gar auf einfache Dateisystem-Schnittstellen, aber diese Formen der Kommunikation sind eigentlich nur Notbehelfe. Während HTTP oder auch FTP für die Kommunikation zwischen verschiedenen Firmen im Internet geeignet sind und AS2 z.B. geradezu dafür entworfen, ist das Dateisystem in erster Linie zur Datenhaltung, aber nicht zur Kommunikation gemacht. Für den Datenaustausch im selben lokalen Netz dagegen sind alle diese Wege nur zweckentfremdet worden.
Message Services sind hingegen exakt dafür entworfen. Ob EAI- oder EDI-System (oder eines, das beides beherrscht), es muss immer mit anderen Produkten im Haus (bzw. im LAN) kommuniziert werden. Dazu gibt es ein Konzept wie den ESB, aber wie dort schon gesagt, das ist ziemlich schwammig. Die reale Implementierung dieser Kommunikation dagegen kann sehr gut ein Message Service sein. Vorausgesetzt natürlich, die bereits im Hause vorhandene Software ist fähig, mit einem solchen Message Service zu arbeiten. Eine gute Möglichkeit dazu ist wiederum die Nutzung von AMQP.
Wenn Sie vor der Entscheidung stehen, eine EDI- oder EAI-Software anzuschaffen, klopfen Sie doch mal die schon existierenden (oder noch anzuschaffenden) Systeme daraufhin ab, ob sie diese Fähigkeit besitzen. Und sollte das in Frage kommen, achten Sie auch bei Ihrer EDI/EAI-Wahl darauf.

AS/400 DataQueue
Data Queues sind ein Konzept der IBM AS/400 (bzw. heute System i, oder auch iSeries oder i5) zur schnellen Kommunikation von Prozessen sowohl auf der iSeries, als auch außerhalb. Auch wenn der Name „Queue“ (also Schlange bzw. Warteschlange) auf eine FIFO-Verarbeitung hinweist, sind im Prinzip drei Arbeitsmoden möglich:

  • FIFO: First In First Out, also das typische Warteschlangenkonzept, bei dem die Einträge der Eingangsreihenfolge nach abgearbeitet werden.
  • LIFO: Last In First Out, was man eigentlich eher als Stack (=Stapel) bezeichnen würde; hier wird immer der neueste Eintrag zuerst ausgelesen.
  • Keyed: Hier entscheidet nicht die Reihenfolge der Einträge, sondern sie werden über einen Key ausgelesen, der jedem Queue-Eintrag zugeordnet ist.

Egal, welcher Modus genutzt wird, immer gibt es einen oder mehrere Prozesse, die Einträge auf der Data Queue einstellen, und einen oder mehrere andere, die die Data Queue regelmäßig abfragen und vorhandene Einträge wieder herausholen.

Was nutzt uns das?

Was kann man nun im Bereich EDI/EAI mit so einer Data Queue anfangen? Nun, die AS/400 hat ja den Ruf „rock solid“ zu sein und durch annähernd nichts in die Knie gezwungen zu werden. Daher ist sie nach wie vor sehr beliebt, wenn es um geschäftskritische Prozesse geht. Es gibt sogar große Unternehmen, die für solch lebenswichtige Aufgaben auf nichts anderes als eine AS/400 vertrauen.
Andererseits ist die AS/400 (speziell ihr ganz eigenes Betriebssystem OS/400 bzw. i5/OS) eine Welt für sich. Sie hat ein komplett eigenes Dateisystem (ist aber in der Lage, ein System, wie man es von Unix kennt, zu emulieren) und kann von außen nicht auf X-beliebige Weise angesprochen werden. Oft werden Daten per FTP übertragen, oder man greift direkt auf die AS/400-Dateien über SQL zu, denn letztlich sind sie so etwas wie Datenbank-Tabellen.
Nun haben wir im Artikel über FTP schon angemerkt, dass dieses Protokoll ja eigentlich nur Dateien transportiert. Sich solche Dateien zu besorgen oder eingegangene Dateien zu verarbeiten, das muss meist über eine Art Zeitsteuerung gelöst werden. Und auch Datenbanktabellen kann man nur aktiv abfragen, auch hier ist normalerweise eine Zeitsteuerung nötig. Möchte man nun möglichst rasch auf neue Daten – sagen wir mal, einen neuen Auftrag – reagieren, dann muss man in sehr kurzen Abständen nach neuen Dateien suchen oder select-Statements abfeuern. Etwas unbefriedigend.
Eine Data Queue dagegen ist gerade darauf ausgelegt, in kurzen Abständen auf neue Einträge geprüft zu werden. Hier stellt man nicht gerade den kompletten, neuen Auftrag ein, der versendet werden soll, sondern zum Beispiel nur die Auftragsnummer. Anhand dieser kann der komplette Auftrag per SQL eingelesen werden. So erzeugt man einerseits wenig Last, da man nur in kurzen Abständen nach einer neuen Auftragsnummer in der Queue sucht, kann andererseits aber sehr schnell reagieren, wenn tatsächlich etwas zum Versand ansteht.

Wie schon gesagt, so eine Data Queue ist auch für Prozesse erreichbar, die selbst nicht auf der iSeries laufen. Den Zugriff darauf erhält man über Treiber von IBM, für Java ist dies zum Beispiel die Java Toolbox. Und so kann die Konfiguration für einen solchen Zugriff aussehen:

Einstellungen für eine AS400 DataQueue in Lobster_data

Im Beispiel wird der aus der Queue ausgelesene Wert zugleich als Parameter in einem SQL-Statement verwendet (Platzhalter „&1“). Das Ergebnis dieses Statements kann dann weiterverarbeitet werden.
Falls Sie also eine AS/400 betreiben, ist das einer der Wege, auf denen sie in Ihr EAI- bzw. EDI-Konzept eingebunden werden kann.

Hier übrigens noch ein Artikel von IBM selbst zur Data Queue, und dann darf natürlich auch der ausführliche Wikipedia-Artikel zur AS/400 alias System i nicht fehlen.