Lobster Experten Fragen

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

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