🥇IBM MQ und JMeter: Erster Kontakt

Hallo, Habr!

Dies ist das Prequel zu meinem vorherigen Beitrag und gleichzeitig ein Remake des Artikels Automatisiertes Testen von Diensten, die das MQ-Protokoll mit JMeter verwenden.

Dieses Mal teile ich meine Erfahrungen mit der Integration von JMeter und IBM MQ für erfolgreiches Testen von Anwendungen auf IBM WAS. Diese Aufgabe stellte sich als nicht ganz einfach heraus, und ich möchte dazu beitragen, dass alle Interessierten Zeit sparen.

Einführung

Über das Projekt: Datenbus, zahlreiche XML-Nachrichten, drei Austauschbereiche (Warteschlangen, Datenbanken, Dateisystem), Webservices mit eigener Logik zur Nachrichtenverarbeitung. Mit der Weiterentwicklung des Projekts wurde manuelles Testen immer schwieriger. Apache JMeter wurde zur Hilfe gerufen – ein leistungsstarkes Open-Source-Tool mit einer großen Benutzer-Community und einer benutzerfreundlichen Oberfläche. Die Einfachheit der Anpassung der „Out-of-the-Box“-Version ermöglicht es, alle Szenarien abzudecken, und das Versprechen des Hauptentwicklers, bei Bedarf zu helfen wenn nötig (hat tatsächlich geholfen) hat mich in dieser Wahl endgültig bestärkt.

Vorbereitung des Anfangskontexts

Für die Interaktion mit dem Warteschlangenmanager ist ein Anfangskontext erforderlich. Es gibt mehrere Typen, hier ist hier eine ausführliche Lektüre möglich.
Für die Erstellung ist es praktisch, MQ Explorer zu verwenden:

Abbildung 1: Hinzufügen des initialen Kontextes

Wählen Sie den Dateityp des Kontextes und das Verzeichnis für die Speicherung aus .bindings Datei, die die Beschreibung der JNDI-Objekte enthält:

Abbildung 2: Auswahl des Typs des initialen Kontextes

Danach können Sie mit der Erstellung dieser Objekte beginnen. Starten Sie mit der Verbindungsfabrik:

Abbildung 3: Erstellung der Verbindungsfabrik

Wählen Sie einen aussagekräftigen 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 Möglichkeit zur Ferninteraktion mit MQ zu ermöglichen:

Abbildung 6: Auswahl des Protokolls der Verbindungsfabrik

Im nächsten Schritt können Sie eine bestehende Fabrik auswählen und die weiteren Einstellungen von dort kopieren. Drücken Sie Next, falls keine vorhanden ist:

Abbildung 7: Auswahl der Einstellungen der bestehenden Verbindungsfabrik

Im Fenster zur Auswahl von Parametern genügt es, drei festzulegen. Auf dem Tab Verbindung geben Sie den Namen des Queue-Managers und die IP-Adresse des Standorts (Port 1414 lassen Sie ihn stehen):

Abbildung 8: Konfiguration der Parameter der Verbindungsfabrik

Und auf dem Tab Channels — Kanal für die Verbindung. Klicken Sie auf Fertigstellen um abzuschließen:

Abbildung 9: Abschluss der Erstellung der Verbindungsfabrik

Jetzt erstellen wir die Verbindung zur Warteschlange:

Abbildung 10: Erstellung des Zielobjekts

Wählen Sie einen aussagekräftigen Namen (ich empfehle, den tatsächlichen Namen der Warteschlange anzugeben) und den Typ Warteschlange:

Abbildung 11: Auswahl von Namen und Typ des Zielobjekts

Analog zu Abbildung 7 können die Einstellungen von einer bestehenden Warteschlange kopiert werden. Klicken Sie auch auf Next, wenn sie die erste ist:

Abbildung 12: Auswahl der Einstellungen des bestehenden Zielobjekts

Im Einstellungsfenster genügt es, den Namen des Managers und die entsprechende Warteschlange auszuwählen, dann auf Fertigstellen. Wiederholen Sie dies so oft, bis alle Warteschlangen für die Interaktion mit JMeter erstellt sind:

Abbildung 13: Abschluss der Erstellung des Zielobjekts

Vorbereitung von JMeter

Die Vorbereitung von JMeter besteht darin, die für die Interaktion mit MQ erforderlichen Bibliotheken hinzuzufügen. Diese befinden sich in %wmq_home%/java/lib. Kopieren Sie diese nach %jmeter_home%/lib/ext vor dem Start von JMeter.

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 einer kleinen Nuance: javax.jms-api-2.0.jar anstelle von jms.jar.
Bei jms.jar tritt der Fehler NoClassDefFoundError auf, dessen Lösung ich gefunden habe 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.

Konfiguration des Testplans

Set von JMeter-Elementen, das notwendig und ausreichend ist, sieht so 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 wird die Navigation erheblich vereinfachen, wenn die Tests wachsen. In diesem Fall gibt es zwei Listen. Die erste enthält die Verbindungseinstellungen für MQ (siehe Abbildung 2 und Abbildung 4):

Abbildung 15: Verbindungsparameter für MQ

Die zweite besteht aus den Namen der Zielobjekte, die auf die Warteschlangen verweisen:

Abbildung 16: Parametrisierte Warteschlangen-Namen

Jetzt bleibt nur noch, den JMS Publisher für das Hochladen der Testnachricht in die ausgehende Warteschlange zu konfigurieren:

Abbildung 17: Konfiguration des JMS Publishers

Und den JMS Subscriber für das Auslesen der Nachricht aus der eingehenden Warteschlange:

Abbildung 18: Konfiguration des JMS Subscribers

Wenn alles richtig gemacht wurde, wird das Ergebnis der Ausführung im Listener mit lebhaften und fröhlichen grünen Farben gefüllt.

Fazit

Ich habe absichtlich die Fragen zur Routing- und Administrationsfragen ausgelassen, da dies recht intime und umfangreiche Themen für separate Veröffentlichungen sind.

Darüber hinaus gibt es eine Menge Feinheiten im Umgang mit Warteschlangen, Datenbanken und Dateien, über die ich ebenfalls ausführlich sprechen möchte.

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