IBM MQ und JMeter: Erster Kontakt

Hallo, Habra!

Das ist das Prequel meines vorherige Veröffentlichung und gleichzeitig ein Remake des Artikels Automatisiertes Testen von Diensten, die das MQ-Protokoll mit JMeter verwenden.

Dieses Mal möchte ich über meine Erfahrungen mit der Integration von JMeter und IBM MQ berichten, um ein reibungsloses Testen von Anwendungen auf IBM WAS zu gewährleisten. Ich bin mit dieser Aufgabe konfrontiert worden, und sie war nicht einfach zu bewältigen. Ich möchte helfen, allen Interessierten Zeit zu sparen.

Einführung

Über das Projekt: Datenbus, zahlreiche XML-Nachrichten, drei Austauschbereiche (Warteschlangen, Datenbank, Dateisystem), Webdienste mit eigener Logik zur Nachrichtenverarbeitung. Mit der Entwicklung des Projekts wurde das manuelle Testen zunehmend komplizierter. Apache JMeter wurde zu Hilfe gerufen – ein leistungsfähiges und Open-Source-Tool mit einer großen Benutzergemeinschaft und benutzerfreundlicher Oberfläche. Die einfache Anpassbarkeit der 'Out-of-the-Box'-Version ermöglicht es, alle Anwendungsfälle abzudecken, und das Versprechen des Hauptentwicklers, zu helfen falls nötig (hat tatsächlich geholfen) hat mich in meiner Entscheidung bestärkt.

Erstellung des Anfangskontexts

Für die Interaktion mit dem Warteschlangenmanager wird ein Anfangskontext benötigt. Es gibt mehrere Typen, hier hier kann man mehr darüber lesen.
Zur Erstellung ist es praktisch, MQ Explorer zu verwenden:

Abbildung 1: Hinzufügen des Anfangskontexts

Wählt den Dateityp des Kontexts und das Verzeichnis für die Speicherung .bindings Datei, die die Beschreibung der JNDI-Objekte enthalten wird:

Abbildung 2: Auswahl des Typs des Anfangskontexts

Danach kann man mit der Erstellung dieser Objekte beginnen. Beginnen Sie mit der Verbindungsfabrik:

Abbildung 3: Erstellung der Verbindungsfabrik

Wählen Sie einen verständlichen Namen...

Abbildung 4: Auswahl des Namens der Verbindungsfabrik

... und den Typ Queue Connection Factory:

Abbildung 5: Auswahl des Typs der Verbindungsfabrik

Protokoll — MQ Client um die Interaktion mit MQ aus der Ferne zu ermöglichen:

Abbildung 6: Auswahl des Protokolls der Verbindungsfabrik

Im nächsten Schritt können Sie eine bereits vorhandene Fabrik auswählen und die weiteren Einstellungen von ihr kopieren. Klicken Sie auf Weiter, falls keine vorhanden ist:

Abbildung 7: Auswahl der Einstellungen der vorhandenen Verbindungsfabrik

Im Fenster zur Auswahl der Parameter müssen nur drei angegeben werden. Auf dem Tab Verbindung geben Sie den Namen des Warteschlangenmanagers und die IP-Adresse des Standorts an (Port 1414 belassen):

Abbildung 8: Konfiguration der Parameter der Verbindungsfabrik

Und auf dem Tab Channels — Kanal für die Verbindung. Klicken Sie auf Fertigstellen zum Abschluss:

Abbildung 9: Abschluss der Erstellung der Verbindungsfabrik

Jetzt erstellen wir eine Verbindung zur Warteschlange:

Abbildung 10: Erstellung eines Zielobjekts

Wählen wir einen verständlichen Namen (ich bevorzuge es, den tatsächlichen Namen der Warteschlange anzugeben) und den Typ Warteschlange:

Abbildung 11: Auswahl von Namen und Typ des Zielobjekts

Analog zu Abbildung 7 kann man die Einstellungen von einer bestehenden Warteschlange kopieren. Drücken Sie auch Weiter, wenn sie die erste ist:

Abbildung 12: Auswahl der Einstellungen des bestehenden Zielobjekts

Im Einstellungsfenster reicht es aus, den Namen des Managers und die benötigte Warteschlange auszuwählen und auf Fertigstellenzu klicken. Danach wiederholen Sie dies so oft, bis alle benötigten Warteschlangen zur Interaktion mit JMeter erstellt sind:

Abbildung 13: Abschluss der Erstellung des Zielobjekts

JMeter Vorbereitung

Die Vorbereitung von JMeter besteht darin, die Bibliotheken hinzuzufügen, die für die Interaktion mit MQ notwendig sind. Diese befinden sich im %wmq_home%/java/lib. Kopieren Sie diese in %jmeter_home%/lib/ext, bevor Sie JMeter starten.

• com.ibm.mq.commonservices.jar
• com.ibm.mq.headers.jar
• com.ibm.mq.jar
• com.ibm.mq.jmqi.jar
• com.ibm.mq.pcf.jar
• com.ibm.mqjms.jar
• dhbcore.jar
• fscontext.jar
• jms.jar
• jta.jar
• providerutil.jar

Alternativliste, vorgeschlagen von polarnik in Kommentare mit einem kleinen Hinweis: javax.jms-api-2.0.jar statt jms.jar.
Mit jms.jar tritt der Fehler NoClassDEfFoundError auf, die Lösung dafür fand hier.

• com.ibm.mq.allclient.jar
• fscontext.jar
• javax.jms-api-2.0.jar
• providerutil.jar

Beide Bibliothekslisten funktionieren erfolgreich mit JMeter 5.0 und IBM MQ 8.0.0.4.

Testplan-Konfiguration

Der notwendige und ausreichende Satz von JMeter-Elementen sieht folgendermaßen aus:

Abbildung 14: Testplan

Im Beispiel des Testplans gibt es fünf Variablen. Trotz ihrer geringen Anzahl empfehle ich, separate Konfigurationselemente für verschiedene Variablenarten zu erstellen. Dies erleichtert die Navigation erheblich, wenn die Tests wachsen. In diesem Fall ergeben sich zwei Listen. Die erste enthält die Verbindungsparameter zu MQ (siehe Abbildung 2 und Abbildung 4):

Abbildung 15: Verbindungsparameter zu MQ

Die zweite – die Namen der Zielobjekte, die auf die Warteschlangen verweisen:

Abbildung 16: Parametrisierte Namen von Warteschlangen

Es bleibt, den JMS Publisher für das Laden der Testnachricht in die ausgehende Warteschlange einzurichten:

Abbildung 17: Einrichtung des JMS Publishers

Und JMS Subscriber, um die Nachricht aus der eingehenden Warteschlange zu lesen:

Abbildung 18: Einrichtung des JMS Subscribers

Wenn alles richtig gemacht wurde, wird das Ergebnis der Ausführung im Listener in leuchtenden und fröhlichen Grüntönen gefüllt sein.

Fazit

Ich habe absichtlich die Fragen zur Routing- und Verwaltungsproblematik ausgelassen, da dies recht intime und umfangreiche Themen für separate Publikationen sind.

Darüber hinaus gibt es eine beträchtliche Reihe von Nuancen bei der Arbeit mit Warteschlangen, Datenbanken und Dateien, über die ich auch gerne separat und ausführlich sprechen würde.

Schützen Sie Ihre Zeit. Vielen Dank für Ihre Aufmerksamkeit.

Quelle: habr.com