How to Test Application Messaging Queue: IBM WebSphere MQ Intro Tutorial

Definition of Messaging Queue:

Messaging Queue (MQ), a message oriented middleware tool, is a product offered by IBM since 1992. It is highly beneficial for transmitting messages (such as XML, text files, HTML files, etc.) in SOA (Service Oriented Architecture) across more than 80 platforms.

It is a dependable and secure communication medium that serves as an excellent messaging solution for Enterprise Architecture worldwide.

This article focuses on testing Messaging Queue, which facilitates the transportation of messages between two applications/modules. It provides guidance on how to test the connectivity between applications/modules during the process of message transportation.

Real-time Example of a Messaging Queue System

Let’s consider ICICI Bank, which involves multiple parallel systems that together form a complete application. For instance, assume that ICICI Bank reported an annual profit margin of $100 Million in 2015.

This profit is an accumulation of data from various systems such as Saving Account, Credit Card Account, Home Loan Account, etc.

As a parent system, ICICI Bank requires communication from each individual system. The Messaging Queue system primarily facilitates this communication.

ICICI Bank can send a request for the gross profit of the Savings Account application. The Savings Account application calculates this information, stores it as XML, and places it in the remote queue.

The parent system then retrieves this information by accessing the remote queue.

Application with MQ

The essential configuration in MQ involves setting up the Queue Manager.

Here are a few important details about the Queue Manager:

• The Queue Manager is responsible for managing the complete functioning of the WebSphere MQ Application.
• It is not responsible for transmitting data.
• The Queue Manager includes a channel and port to transmit data to a specific destination queue or store the message internally until another queue retrieves it.
• Applications can have multiple Queue Managers and channels to communicate messages.

Technical Example

Consider the following applications: APPS, APPP, APPF, APPL, and APPD. All these applications communicate messages with each other, and some of them have two-way communication structures.

• APPS is a sales application with the following details: queue manager – APPSQM, channel – APPSCH, queue name – MQS, port number – 11112.
• APPP is a product processing application with the following details: queue manager – APPPQM, channel – APPPCH, queue name – MQP, port number – 1111.
• APPF is a finished, fully functional application with the following details: queue manager – APPFQM, channel – APPFCH, queue name – Mqf, port number – 1112.
• APPL is a logistics application with the following details: queue manager – APPLQM, channel – APPLCH, queue name – MQD, port number – 1112.
• APPD is a delivery application with the following details: queue manager – APPDQM, channel – APPDCH, queue name – MQD, port number – 1112.

Scenario 1 – APPS sends data to APPP

Each of the above applications has two configuration files: application configuration and Messaging Queue configuration. The application configuration contains details of procedures and data processing for the XML message.

The MQ config file contains information relevant to MQ, such as queue manager – APPSQM, channel – APPSCH, queue name – MQS, port number – 1111.

(Note: Click on the image for an enlarged view)

Once the APPS application processes the data, it generates the XML message and puts it into the queue. The job of APPS is completed at this point.

The other queue will pick the message when it needs to, while the Queue Manager holds the data in the meantime.

Let’s say the APPP application needs to retrieve the XML message from the MQS queue. The MQP queue is configured to fetch the XML message from the MQS queue.

The MQP queue fetches the XML message from the MQS queue and sends it to the APPP application for further processing.

Similar processes are carried out by each application to obtain data from other applications.

Scenario 2 – APPP sends data to APPS

This time, the configuration files will vary on both sides. The MQ config file at APPP will contain different queue information such as Queue Manager – APPPQMR, channel – APPPCHR, queue name – MqpR, port number – 1111.

On the other hand, APPS will have different queue information such as Queue Manager – APPSQMR, channel – APPSCHR, queue name – MqsR, port number – 1111. Note that the port number can be the same for a few applications if they are connected as peers in the same system.

Therefore, all applications must be configured accordingly to enable message communication among themselves.

It is possible for communication to occur between local applications within the same system and remote applications elsewhere. As mentioned earlier, both local and remote applications require configuration files to establish communication in their respective servers.

Functional Testing with MQ

Testers need to validate the following:

• Application configuration
• Queue configuration
• Message format
• Message correctness and completeness
• Message transmission
• Handling of message failures

MQ in SOA

MQ is a reliable technique that can be utilized in Service Oriented Architecture (SOA) to facilitate message communication among applications. As message communication is crucial for running an ERP system, MQ serves as an appropriate solution.

It is an effortless and secure method. Following an approach similar to the technical example described above, Messaging Queue can be implemented across multiple applications to fetch data from one or more apps.

By examining the application architecture, testers can gather more information about message communication connectivity between applications, end-to-end message flow, etc.

Additional details can be obtained from the MQ team or environment teams.

MQ simulators (such as IBM WebSphere) can be used to drop, monitor, and check the receipt of messages from an inbound queue to an outbound queue with variable configurations.

MQ-related Issues During Testing

While testing applications that communicate messages through Messaging Queue, various scenarios can cause messages to fail to transfer from one application to another.

Some common problems include:

• Issues with the input XML message format, such as incorrect header, metadata issues, format issues, data issues, etc.
• Incorrect queue configuration, including incorrect queue name, manager name, channel, port, etc.
• Message size exceeding the expected limit, which may cause the message to be placed in the error/dead queue folder.
• Problems with the queue server, connectivity, remote queue, etc., leading to message communication failures.

Conclusion

When testing applications that follow a Service Oriented Architecture (SOA), such as ERP systems, Messaging Queues are essential components. As testers, it is beneficial to have a basic understanding of these Queues.

We hope this article has provided an introduction to the concept of Messaging Queues and opened up avenues for further exploration and mastery.

About the author: This is a guest article by Asish K Mallik.

Please feel free to share your comments, questions, and input below.