Привет, Хабр!

Это приквел моей предыдущей публикации и в то же время ремейк статьи Автоматизированное тестирование сервисов, использующих протокол MQ с помощью JMeter.

На этот раз расскажу о своем опыте примирения JMeter и IBM MQ для счастливого тестирования приложений на IBM WAS. Сталкивался с такой задачей, легко она не поддавалась. Хочу помочь сэкономить время всем заинтересованным.


Введение


О проекте: шина данных, множество xml-сообщений, три области обмена (очереди, БД, файловая система), веб-сервисы со своей логикой обработки сообщений. По мере развития проекта тестировать вручную становилось всё сложнее. На помощь был призван Apache JMeter — мощный и опенсорсный, с большим сообществом пользователей и дружелюбным интерфейсом. Легкость кастомизации версии «из коробки» позволяет покрыть любые кейсы, а обещание ведущего разработчика помочь если что (таки помог) окончательно утвердило в выборе.

Приготовление начального контекста


Для взаимодействия с менеджером очередей нужен начальный контекст. Он бывает нескольких типов, вот тут можно почитать подробнее.
Для его создания удобно использовать MQ Explorer:


Рисунок 1: Добавление начального контекста

Выбрать файловый тип контекста и директорию для хранения .bindings файла, который будет содержать описание JNDI-объектов:


Рисунок 2: Выбор типа начального контекста

После чего можно приступать к созданию этих объектов. И начать с фабрики соединений:


Рисунок 3: Создание фабрики соединений

Выбрать понятное имя…


Рисунок 4: Выбор имени фабрики соединений

… и тип Queue Connection Factory:


Рисунок 5: Выбор типа фабрики соединений

Протокол — MQ Client для возможности взаимодействия с MQ удаленно:


Рисунок 6: Выбор протокола фабрики соединений

На следующем шаге можно выбрать уже существующую фабрику и дальнейшие настройки скопировать с нее. Жмем Next, если таковой нет:


Рисунок 7: Выбор настроек существующей фабрики соединений

В окне выбора параметров достаточно задать три. На вкладке Connection указать имя менеджера очередей и ip стенда с его расположением (порт 1414 оставить):


Рисунок 8: Настройка параметров фабрики соединений

И на вкладке Channels — канал для соединения. Нажать Finish для завершения:


Рисунок 9: Завершение создания фабрики соединений

Теперь создадим подключение к очереди:


Рисунок 10: Создание целевого объекта

Выберем понятное имя (предпочитаю указывать реальное имя очереди) и тип Queue:


Рисунок 11: Выбор имени и типа целевого объекта

По аналогии с Рисунком 7 можно скопировать настройки с существующей очереди. Также жмем Next, если она первая:


Рисунок 12: Выбор настроек существующего целевого объекта

В окне настроек достаточно выбрать имя менеджера и нужную очередь, нажать Finish. После чего повторить необходимое число раз, пока все очереди, нужные для взаимодействия с JMeter, не будут созданы:


Рисунок 13: Завершение создания целевого объекта

Подготовка JMeter


Подготовка JMeter заключается в добавлении библиотек, необходимых для взаимодействия с MQ. Они располагаются в %wmq_home%/java/lib. Скопируйте их в %jmeter_home%/lib/ext перед запуском 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


Альтернативный список, предложенный polarnik в комментарии с небольшим нюансом: javax.jms-api-2.0.jar вместо jms.jar.
С jms.jar возникает ошибка NoClassDEfFoundError, решение которой нашел тут.

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


Оба списка библиотек успешно работают с JMeter 5.0 и IBM MQ 8.0.0.4.

Настройка тест-плана


Необходимый и достаточный набор элементов JMeter выглядит так:


Рисунок 14: Тест-план

В примере тест-плана пять переменных. Несмотря на малое их количество, рекомендую заводить отдельные конфигурационные элементы под разные типы переменных. По мере разрастания тестов это существенно упростит навигацию. В данном случае получается два списка. Первый содержит параметры подключения к MQ (см. Рисунок 2 и Рисунок 4):


Рисунок 15: Параметры подключения к MQ

Второй — имена целевых объектов, ссылающихся на очереди:


Рисунок 16: Параметризованные имена очередей

Остается настроить JMS Publisher для загрузки тестового сообщения в исходящую очередь:


Рисунок 17: Настройка JMS Publisher

И JMS Subscriber для вычитывания сообщения из входящей очереди:


Рисунок 18: Настройка JMS Subscriber

Если всё сделано правильно, результат выполнения в листнере наполнится яркими и жизнерадостными зелёными красками.

Заключение


Намеренно опустил вопросы маршрутизации и администрирования, это довольно интимные и обширные темы для отдельных публикаций.

Кроме того, есть солидная порция нюансов в работе с очередями, базами и файлами, о которых также хотелось бы поговорить отдельно и обстоятельно.

Берегите своё время. И спасибо за внимание.

image

Комментарии (8)


  1. Lehas
    04.02.2019 11:17

    Зачем ты некрофилишь IBM?


    1. rahna Автор
      04.02.2019 18:10

      Предпочел бы без перверсий.
      Выбери на свой вкус — «классика» или «что мертво, умереть не может»


  1. Autowired
    04.02.2019 17:50
    +1

    Какая же это все х… (я об IBM)

    Но спасибо за статью, помогла


  1. polarnik
    04.02.2019 23:17

    Предполагая, что JMS Publiser и JMS Subscriber предназначены только для топиков, а не для очередей. Что предположил после просмотра скриншота в документации на Publisher:

    JMS Publiser: dinamicTopics/myStaticTopic1
    dinamicTopics/myStaticTopic1
    указано:
    dinamicTopics/myStaticTopic1


    1. rahna Автор
      05.02.2019 12:11
      +1

      Спасибо, что обратили внимание на пару JMS Point-to-Point (request_only) + JMS Point-to-Point (read). Попробовал передачу — справляется не хуже JMS Publisher + JMS Subscriber.

      Использовал ранее JMS Point-to-Point (request_reply) и столкнулся с тем, что кроме запроса по jms-селектору сэмплер вычитывает и все другие сообщения в очереди. Вероятно, я не до конца разобрался в его настройках.

      хм..
      Попробовал сейчас аналогичный кейс — и всё прошло хорошо. Возможно, влияние оказывало то, что несколько JMS Point-to-Point (request_reply) из разных трэдов, запущенных одновременно, смотрели в одну очередь и «мешали» друг другу…


      1. polarnik
        05.02.2019 20:29

        Тоже оценил, что в JMS Publisher + JMS Subscriber есть разные форматы, есть возможность передать Object, который сериализуется в XML самостоятельно, прочитать файл — удобно. Думаю изучить эту связку.
        Ещё раз спасибо


  1. polarnik
    05.02.2019 20:52

    При подключении библиотек использую комбо-набор из:

    • com.ibm.mq.allclient.jar — 8,2 МБайт
    • fscontext.jar — 22,8 кБайт
    • jms.jar — 58,3 кБайт
    • providerutil.jar — 77,1 кБайт

    Архив allclient содержит в себе многие отдельные компоненты. Проверил — это минимальный набор, необходимый для работы с IBM MQ из Apache.JMeter. Он короче набора, указанного в статье за счёт большого allclient.jar.

    Пришел к нему из ответа Jmeter JMS point to point to connect IBM MQ error ( java.lang.IllegalStateException: QueueConnectionFactory expected, but got com.ibm.mq.jms со stackoverflow.

    Библиотеки из ответа на stackoverflow ...
    I believe you don't need that many jars, you should download the relevant 8.x.x.x-WS-MQ-Install-Java-All.jar package from the Fix Central and come up with libraries like:

    com.ibm.mq.allclient.jar
    com.ibm.mq.traceControl.jar
    fscontext.jar
    jms.jar
    JSON4J.jar
    providerutil.jar


    1. rahna Автор
      06.02.2019 12:04

      Комбо-набор работает отлично после обновления версии jms.jar до версии 2.0.
      Спасибо за подсказку!
      Включил предложенный список в статью и вытащил исходный из спойлера.