IBM MQ und JMeter: Erster Kontakt

Hallo Habr!

Dies ist eine Fortsetzung meiner vorherigen Veröffentlichung und gleichzeitig ein Remake des Artikels Automatisiertes Testen von Diensten mit dem MQ-Protokoll mit JMeter .

Dieses Mal erzähle ich Ihnen von meinen Erfahrungen mit der Abstimmung von JMeter und IBM MQ zum erfolgreichen Testen von Anwendungen auf IBM WAS. Angesichts einer solchen Aufgabe gab es leicht nicht nach. Ich möchte allen Interessierten helfen, Zeit zu sparen.

Einführung

Über das Projekt: Datenbus, viele XML-Nachrichten, drei Austauschbereiche (Warteschlangen, Datenbanken, Dateisystem), Webdienste mit eigener Nachrichtenverarbeitungslogik. Mit der Entwicklung des Projekts wurde das manuelle Testen schwieriger. Apache JMeter wurde gerufen, um zu helfen - leistungsstark und Open Source, mit einer großen Benutzergemeinschaft und einer benutzerfreundlichen Oberfläche. Die einfache Anpassung der "out of the box" -Version ermöglicht es Ihnen, alle Fälle abzudecken, und das Versprechen des leitenden Entwicklers, zu helfen, wenn etwas (hat geholfen) endgültig in der Auswahl genehmigt wird.

Den anfänglichen Kontext vorbereiten

Für die Interaktion mit dem Warteschlangenmanager benötigen Sie einen anfänglichen Kontext. Es kann verschiedene Arten geben, hier können Sie mehr lesen.
Es ist praktisch, MQ Explorer zu verwenden, um es zu erstellen:


^{Abbildung 1: Hinzufügen eines Anfangskontexts}

Wählen Sie den Dateityp des Kontexts und das Verzeichnis zum Speichern der .bindings der Datei aus, die die Beschreibung der JNDI-Objekte enthalten sollen:


^{Abbildung 2: Auswählen eines anfänglichen Kontexttyps}

Dann können Sie beginnen, diese Objekte zu erstellen. Und beginnen Sie mit einer Verbindungsfabrik:


^{Abbildung 3: Erstellen einer Verbindungsfactory}

Wähle einen freundlichen Namen ...


^{Abbildung 4: Auswählen eines Verbindungsfactory-Namens}

... und der Queue Connection Factory-Typ :


^{Abbildung 5: Auswählen eines Verbindungsfactory-Typs}

Protokoll - MQ-Client für die Möglichkeit der Remote-Interaktion mit MQ:


^{Abbildung 6: Auswählen eines Verbindungsfactory-Protokolls}

Im nächsten Schritt können Sie eine vorhandene Fabrik auswählen und weitere Einstellungen daraus kopieren. Klicken Sie auf Weiter , wenn es keine gibt:


^{Abbildung 7: Auswählen von Einstellungen für eine vorhandene Verbindungsfactory}

Stellen Sie im Parameterauswahlfenster einfach drei ein. Geben Sie auf der Registerkarte Verbindung den Namen des Warteschlangenmanagers und die IP des Standes mit seinem Standort an (verlassen Sie Port 1414 ):


^{Abbildung 8: Konfigurieren der Verbindungsfactory-Einstellungen}

Und auf der Registerkarte Kanäle den Kanal für die Verbindung. Klicken Sie auf Fertig stellen , um den Vorgang abzuschließen:


^{Abbildung 9: Abschluss der Verbindungsfactory}

Stellen Sie nun eine Verbindung zur Warteschlange her:


^{Abbildung 10: Erstellen eines Ziels}

Wählen Sie einen Anzeigenamen (ich bevorzuge es, den tatsächlichen Namen der Warteschlange anzugeben) und den Warteschlangentyp :


^{Abbildung 11: Auswahl des Namens und des Typs des Ziels}

In Analogie zu Abbildung 7 können Sie die Einstellungen aus einer vorhandenen Warteschlange kopieren. Klicken Sie auch auf Weiter, wenn es das erste ist:


^{Abbildung 12: Auswählen der Einstellungen eines vorhandenen Ziels}

Wählen Sie im Einstellungsfenster einfach den Managernamen und die gewünschte Warteschlange aus und klicken Sie auf Fertig stellen . Wiederholen Sie dann die erforderliche Anzahl von Malen, bis alle für die Interaktion mit JMeter erforderlichen Warteschlangen erstellt wurden:


^{Abbildung 13: Abschluss der Erstellung des Ziels}

JMeter vorbereiten

Die Vorbereitung von JMeter besteht darin, die Bibliotheken hinzuzufügen, die für die Interaktion mit MQ erforderlich sind. Sie befinden sich in% wmq_home% / java / lib. Kopieren Sie sie nach% 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

Eine alternative Liste, die von polarnik in einem Kommentar mit einer leichten Nuance vorgeschlagen wurde: javax.jms-api-2.0.jar anstelle von jms.jar.
Bei jms.jar tritt ein NoClassDEfFoundError-Fehler auf, dessen Lösung hier zu finden ist .

• 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 einrichten

Ein notwendiger und ausreichender Satz von JMeter-Elementen sieht folgendermaßen aus:


^{Abbildung 14: Testplan}

Das Testplanbeispiel enthält fünf Variablen. Trotz ihrer geringen Anzahl empfehle ich, separate Konfigurationselemente für verschiedene Arten von Variablen zu starten. Wenn die Tests zunehmen, wird dies die Navigation erheblich vereinfachen. In diesem Fall werden zwei Listen erhalten. Der erste enthält die Parameter für die Verbindung mit MQ (siehe Abbildung 2 und Abbildung 4 ):


^{Abbildung 15: MQ-Verbindungseinstellungen}

Das zweite sind die Namen der Ziele, die auf die Warteschlange verweisen:


^{Abbildung 16: Parametrisierte Warteschlangennamen}

Es bleibt JMS Publisher so zu konfigurieren, dass die Testnachricht in die ausgehende Warteschlange geladen wird:


^{Abbildung 17: Konfigurieren von JMS Publisher}

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


^{Abbildung 18: Konfigurieren des JMS-Abonnenten}

Wenn alles richtig gemacht ist, wird das Ergebnis im Listener mit hellen und fröhlichen grünen Farben gefüllt.

Fazit

Er hat die Themen Routing und Administration bewusst weggelassen, dies sind eher intime und umfangreiche Themen für einzelne Veröffentlichungen.

Darüber hinaus gibt es einen erheblichen Teil der Nuancen bei der Arbeit mit Warteschlangen, Datenbanken und Dateien, über die ich auch separat und gründlich sprechen möchte.

Pass auf deine Zeit auf. Und danke fürs Zuschauen.