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

What is Messaging Queue?

Since 1992, IBM has been offering Messaging Queue (MQ), a middleware tool designed for message orientation. This tool is useful for sending messages, including XML, text files, HTML files and more, across more than 80 platforms in a Service Oriented Architecture (SOA).

It is a trusted and secure method of communication and serves as a comprehensive messaging solution for Global Enterprise Architecture.

The purpose of this post is to highlight the testing of Messaging Queue, which supports the delivery of messages between different applications/modules. It offers insights on testing the connection between applications/modules while transporting messages.

A Real-Time Case Study of a Messaging Queue System

It’s helpful to picture ICICI Bank, where multiple linear systems build a complete application. For example, let’s say ICICI Bank declared an annual profit of $100 million in 2015.

This profit is the combination of information from different systems, including Saving Account, Credit Card Account, Home Loan Account, and more.

ICICI Bank, being a primary system, needs data from each individual system. The Messaging Queue predominantly enables this communication.

The Main System of ICICI Bank can request the total profit of the Savings Account application. In response, the Savings Account application computes this information, records it as XML, and puts it in the distant queue.

The main system can then receive this data by accessing the far-off queue.

Implementing MQ with an Application

Setting up the Queue Manager is an essential part of MQ configuration.

Significant aspects of the Queue Manager include:

• It manages the entire function of the WebSphere MQ Application.
• It does not have any responsibility to transmit data.
• The Queue Manager features a channel and port to forward data to a particular destination queue or hold the data inside until another queue retrieves it.
• Applications can be equipped with multiple Queue Managers and channels to enable message exchange.

A Practical Illustration

Imagine the applications: APPS, APPP, APPF, APPL, and APPD. All these applications deliver messages to each other, with some having two-way communication setups.

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

Scenario 1 – Data Transmission from APPS to APPP

Each of these applications comes with two configuration files: the application configuration and the Messaging Queue configuration. The application configuration features data procedures and data processing information for the XML message.

Details relevant to MQ, such as queue manager – APPSQM, channel – APPSCH, queue – MQS, port – 1111, are contained in the MQ config file.

(Note: Click on the image to view it in full size)

Once the APPS application completes data processing, it generates the XML message and store it in the queue. Following which, APPS’s job ends.

When required, the other queue fetches the message, will the Queue Manager keeps the message until then.

Now, let’s suppose the APPP application needs to extract the XML message from the MQS queue. The MQP queue is configured to draw out the XML message from MQS queue.

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

Every application conducts similar processes to collect data from other applications.

Scenario 2 – Data Delivery from APPP to APPS

This time, configuration files on both ends will be different. The MQ config file on the APPP side will have different queue details such as Queue Manager – APPPQMR, channel – APPPCHR, queue – MqpR, port – 1111.

On the other hand, APPS will have different queue details like Queue Manager – APPSQMR, channel – APPSCHR, queue – MqsR, port – 1111. It should be noted that some applications may have the same port number if they are peer connections within the same system.

In summary, all applications must be appropriately configured to facilitate message exchange among them.

Communication can be facilitated among local applications within the same system and remote applications located elsewhere. As mentioned before, both local and remote applications demand configuration files to establish their respective server communication.

Performing Functional Tests with MQ

Testers are required to validate the following:

• Configuration of the application
• Queue configuration
• Message format
• Accuracy and completeness of the message
• Message delivery
• Handling of message failure

Using MQ in SOA

MQ is a reliable method for facilitating message exchanges between applications in Service Oriented Architecture (SOA). MQ is a significant element in running an ERP system due to the importance of message communication.

It is a safe and simple method. By adopting a method similar to the above technical example, the Messaging Queue can be applied across multiple applications to retrieve data from one or more apps.

By examining the architecture of the application, testers can acquire more knowledge about the connection for message communication between applications, end-to-end message flow and more.

Further information can also be gained from the MQ team or environment teams.

MQ simulators (like IBM WebSphere) can be employed to drop, monitor, and verify the receipt of messages between an inbound and outbound queue with varying configurations.

MQ-Related Problems During Testing

In the process of testing applications that use Messaging Queue to communicate messages, there can be different scenarios leading to the failure of message transfer from one application to another.

Some frequent problems can be:

• Problems with the format of the input XML message, such as incorrect header, metadata issues, format issues, data issues, etc.
• Inaccurate queue configuration, including wrong queue name, manager name, channel, port, etc.
• Message size exceeding the prescribed limit, causing the message to be moved to the error/dead queue folder.
• Issues with the queue server, connectivity, remote queue, etc., causing communication failure of the messages.

Final Thoughts

In testing applications that use a Service Oriented Architecture (SOA), like ERP systems, the Messaging Queue is a vital component. For testers, a basic understanding of these Queues is advantageous.

We trust that this post has served as a primer to the concept of Messaging Queues, paving the way for more in-depth study and comprehension.

About the author: Asish K Mallik is a guest contributor to this post.

We welcome your comments, inquiries, and feedback below.