What is Messaging Queue?
Messaging Queue (MQ), a message oriented middleware tool, is an IBM product since 1992. It is very helpful to communicate messages (XML/text file/HTML file etc.) in SOA (service Oriented Architecture) on over 80 platforms.
It is reliable and provides a secured, assured communication medium and an excellent messaging solution to Enterprise Architecture across the globe.
Today’s article is about testing Messaging Queue that facilitates transportation of messages between two applications/modules. This will help you test the connectivity between applications/modules during message transportation.
What You Will Learn:
Real time example of Messaging Queue system
Let’s take ICICI Bank that includes many systems running in parallel to make one complete application. Assume that the ICICI Bank shows an annual profit margin of $100 Million for the year 2015.
This profit would be an aggregate of all systems such as Saving Account, Credit Card Account, Home Loan Account and so on.
ICICI bank as a parent system seeks communication from each of its individual systems. This communication can primarily be carried out by Messaging Queue system.
Parent ICICI bank can send a request that it needs the gross profit of the Savings account application. The saving account application then calculates this information, stores it in the form of XML and places it in the remote queue.
The parent system then will call the remote queue to retrieve this information.
Application with MQ
The key configuration in MQ is setting up the Queue Manager.
A few important details about the Queue Manager are mentioned below
- It owns/manages the complete functioning of the WebSphere MQ Application.
- It’s not responsible for transmitting data.
- Contains a channel and port to transmit data to a particular destination queue or to store the message internally till other queue picks the message.
- Applications could have multiple Queue Managers/channels to communicate messages.
Let’s assume there are applications APPS, APPP, APPF, APPL, APPD. All are communicating messages among each other. Some of them have two-way communication structures.
- APPS is a sales applications, with queue manager-APPSQM, channel-APPSCH, queue name-MQS, portnum-11112
- APPP is a product processing application, with queue manager-APPPQM, channel-APPPCH, queue name-MQP, portnum-1111
- APPF is a finished, fully functional application, with queue manager-APPFQM, channel-APPFCH, queue name-Mqf, portnum-1112
- APPL is a logistics application, with queue manager-APPLQM, channel-APPLCH, queue name-MQD, portnum-1112
- APPD is a delivery application, with queue manager-APPDQM, channel-APPDCH, queue name-MQD, portnum-1112
Scenario 1 – APPS sends data to APPP
Each of the above applications will have two config 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 will have the MQ related details like queue manager-APPSQM, channel-APPSCH, queue name-MQS, portnum-1111.
(Note: Click on the image for enlarged view)
Once the APPS application processes the data, it generates the XML message and puts it into the queue. APPS job is done.
It’s time to pick the message by the other queue until then the Queue Manager will hold the data.
Now let’s say the APPP application should pick the XML message from the MQS queue. The APPP MQ config file is configured to fetch the XML message from the MQS queue.
The MQP queue will fetch the XML message from the MQS queue and sends it to 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 config files will be different at both sides. The MQ config file at APPP will have different queue info like Queue Manager-APPPQMR, channel-APPPCHR, queue name-MqpR, portnum-1111.
And the APPS will have different queue info like Queue manager-APPSQMR, channel-APPSCHR, queue name-MqsR, portnum-1111. Remember that the port number can be same for few applications as they could be connected as peers in the same system.
Therefore, all the applications will have to be configured accordingly to communicate messages among themselves.
There is a possibility that a communication can happen between local applications that are in a current system with a remote application elsewhere. As mentioned above, both local and remote applications should have configuration files to set up in their server to enable communication.
As mentioned above, both local and remote applications should have configuration files to set up in their server to enable communication.
Functional Testing with MQ
Testers will have to validate the following
- Application configuration
- Queue configuration
- Message format
- Message correctness and completeness
- Message transmission
- Message failures, when they occur
MQ in SOA
MQ is a reliable technique that can be used in SOA architecture to communicate messages among applications. As message communication is a key concept for running an ERP system, MQ provides the right solution for it.
It is effortless and secure. Following an approach similar to the one shown in the technical example,
Following an approach similar to the one shown in the technical example, Messaging Queue can be set on multiple applications to fetch data from one or more apps.
By taking a look at the application architecture, more information can be obtained by testers about message communication connectivity between applications, E2E message flow, etc.
In any case, MQ team or environment teams can provide additional details.
MQ simulator (such as IBM WebSphere), which can transfer the messages from inbound queue to an outbound queue can be used to drop messages, monitor them and check the receipt at the outbound queue with variable configurations.
While testing the applications that communicate messages through Messaging Queue, there are many scenarios where messages can fail to transfer from one application to another.
Some of the Common problems are mentioned below
- Input XML message format issues like incorrect header, metadata issue, format issues, data issues, etc..
- Incorrect queue config such as incorrect queue name, manager name, channel, port, etc.
- Message size may be more than expected message will fall into error/dead queue folder.
- Queue server issue, connectivity issue, remote queue issue, etc. leads to failure of message communication.
When testing apps that follow SOA, such as ERP systems, MQs are integral elements and as testers, it is a good idea to understand basic details about the same.
We hope this article has succeeded in introducing the concept and opened avenues for further exploration and mastery.
About the author: This is a guest article by Asish K Mallik.
Please share your comments, questions, and inputs below.