Und wieder mal ein Projekt mit asynchroner Kommunikation über IBM MQ – hieß es früher nicht schon mal WebSphereMQ oder MQ Series? Nun gut, die Welt dreht sich weiter. Ein beständiger Faktor ist die große Bedeutung von Message-Queues, um Anwendungen voneinander zu separieren. Eine Entwickler-Instanz steht temporär der Entwicklung nicht zur Verfügung: Hier müssen erst noch die Berechtigungen geklärt werden. Kein Beinbruch – mein Entwicklerrechner ist gut ausgestattet – und IBM bietet ein Docker-Image an!
IBM MQ als Container starten
Um alles aus einem Hause zu haben, installiere ich eine virtuelle Maschine mit RedHat8 und darauf das Podman-Paket. Schon kann es losgehen.
Listing 1: docker – Image für IBM MQ über Docker laden
Listing 2: docker – Listing zeigt das heruntergeladene Image
Beim Start des Images sind einige Parameter mitzugeben.
Listing 3: docker – Start von IBM MQ
Ich starte das Image in einem Terminalfenster – so kann ich mir problemlos die Log-Meldungen ansehen. Ich habe durch die Umgebungsvariablen beim Start des Containers definiert, dass der Queue-Manager QM1 heißt und der Connection-Port – wie gewohnt – 1414 ist.
MQ-Konfiguration ermitteln
Was kann ich mit dem Standard-Image anfangen? Dazu muss ich erst einmal ein wenig MQ-Administration ergoogeln. Ein Universal (?)-Werkzeug ist wohl die MQ-Service-Konsole. Also verbinde ich mich mit dem Container. Dazu ermittle ich als erstes die CONTAINER ID.
Listing 4: docker – Starten eines Prozesses im MQ-Container
In der bash dann in das Verzeichnis /opt/mqm/bin wechseln und die MQ-Service-Konsole starten.
Listing 5: bash – Starten der MQ-Service-Konsole
Nun gehe ich auf die Suche nach der bereitgestellten Konfiguration. Dabei suche ich nach brauchbaren Informationen zu den Parametern, die ich für eine Client-Verbindung zum Queue-Manager benötige. Als Erstes kommt mir der Channel in den Sinn. Ich verstehe unter dem Channel einen Verbindungskanal – also in meinem Fall für die Netzwerkverbindung zwischen Client und Server. Das Programm runmqsc starte ich mit dem Namen des Queue-Managers in der Erwartung, dass alle Angaben sich genau auf diesen Queue-Manager beziehen.
Listing 6: runmqsc – Auflisten aller vorhandenen Channel
Unter den vielen eingerichteten Channels identifiziere ich zwei, die mir bekannt vorkommen. DEV.APP.SVRCONN wird in den Beispielanwendungen von IBM für die Client-Verbindung verwendet. Gut – dann benötige ich noch eine Queue.
Listing 7: runmqsc – Auflistung der Server-Queues
Die Vielzahl der eingerichteten Queues überrascht mich; dass eine Dead-Letter-Queue mit dem Namen DEV.DEAD.LETTER.QUEUE eingerichtet ist, finde ich gut – so etwas brauche ich auf jeden Fall. Die Queue DEV.QUEUE.1 sieht so aus, als könnte ich die für einen Test verwenden. Vielleicht ist ja schon alles paletti – und ich kann direkt loslegen.
Testprogramm ausführen
Auf der Seite https://developer.ibm.com/components/ibm-mq/tutorials/mq-develop-mq-jms/ finde ich einen Link zur Klasse JmsPutGet. Darin sind auch die Parameter APP_USER und APP_PASSWORD anzupassen. Die lasse ich erst einmal leer – und es funktioniert!
Listing 8: JMSPutGet.java – Nachrichten können eingestellt und ermittelt werden
Nachspann
Ganz ehrlich: Dargestellt habe ich nur die Zusammenfassung von ungefähr acht Stunden Arbeit. Ich konnte mir nicht vorstellen, dass der Zugriff auf MQ ohne User/Kennwort möglich ist – also habe ich erst mal root als Application-User angegeben.
Listing 9: JMSPutGet.java - Verbindungsfehler wenn ich root als AppUser angebe
Auf der Standardausgabe des Docker-Images lese ich für diesen Fall.
Listing 10: Ausgabe des IBM MQ Docker-Containers wenn ich root als AppUser angebe
Danach bin ich mit der Dokumentation von MQ, Startpunkt https://www.ibm.com/support/knowledgecenter/de/SSFKSJ_9.0.0/com.ibm.mq.con.doc/q114495_.html auf die Reise gegangen und habe mich durchgewurschtelt, bis ich einen autorisierten Zugriff auf meine MQ bekommen habe…