Eher interne Wege/Quellen/Senken

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

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

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

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.

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 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.

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

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

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.

„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:

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:

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.

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.