Let us see what the Messaging Queue is:
Messaging Queue (MQ), a message oriented middleware tool, has been 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 secure, 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.
Table of Contents:
Real time example of Messaging Queue system
Take ICICI Bank, which 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 Savings 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 savings account application then calculates this information, stores it in the form of XML and places it in the remote queue.
The parent system will then 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.
- We are not responsible for transmitting data.
- Contains a channel and port to transmit data to a particular destination queue or to store the message internally until another queue picks the message.
- Applications can have multiple Queue Managers/channels to communicate messages.
Technical example
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 application, 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 an enlarged view)
Once the APPS application processes the data, it generates the XML message and puts it into the queue. The APPS job is done.
It’s time to pick the message from 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 send 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 on both sides. The MQ config file at APPP will have different queue info like Queue Manager-APPPQMR, channel-APPPCHR, queue name-MqpR, portnum-1111.
The APPS will have different queue info like Queue manager-APPSQMR, channel-APPSCHR, queue name-MqsR, portnum-1111. Remember that the port numbers can be the same for a few applications as they can 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 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 greater than expected messages will fall into the error/dead queue folder.
- Queue server issues, connectivity issues, remote queue issues, etc. leads to failure of message communication.
Conclusion
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.
Great Article !
@Jafar Shaikh
If you would like to simulate the outside system to enable testing of your application you should use an API simulation tool (search wikipedia for “comparison of API simulation tools”).
Just make sure you use a tool that supports IBM MQ. An example of a tool that can simulate and mock IBM MQ for the purpose of testing is Traffic Parrot.
It would be great if you provide sample testcases to validate below functionalities?
• Application configuration
• Queue configuration
• Message format
• Message correctness and completeness
• Message transmission
• Message failures, when they occur
Can you provide sample testcases to validate below functionalities?
• Application configuration
• Queue configuration
• Message format
• Message correctness and completeness
• Message transmission
• Message failures, when they occur
Very Informative article on MQ testing.I have couple of questions, What are the testing tools in the market for MQ testing?What are the challenges we foresee with third party inbound/outbound receivers?
> What are the testing tools in the market for MQ testing?
There are several categories of tools when it comes to testing systems communicating via IBM MQ queues or topics.
You can send test messages using tools like JMeter (system A on the first diagram in the article above), see this tutorial as an example: https://www.blazemeter.com/blog/ibm-mq-testing-with-jmeter-learn-how/
You can simulate response messages (system B on the first diagram in the article above) using service virtualization tools such as Traffic Parrot.
To be able to create test environments, you might need to create additional IBM MQ brokers, you can do it by using the IBM MQ for Developers: https://hub.docker.com/r/ibmcom/mq/
> What are the challenges we foresee with third party inbound/outbound receivers?
Sometimes third-party systems can cause issues when testing your enterprise systems, for example:
* Third-party system is not available 24/7 for testing, you need to schedule time on test environments as it is shared between many teams which result in the lower time to market
* Third-party system does not allow for simulating
* Third-party test environment might not support the load you require for running your performance tests
In this case, you can use service virtualization or mocking tool to simulate the third party system.
Here is a list of these tools:
https://en.wikipedia.org/wiki/Comparison_of_API_simulation_tools
Can the application determine the messages by queue name ?
for example;
Queue Name A:
01,Token01,Line1,Unique01,Pallet01,DDMMYYYYHHMMSS, 9100,,ASN01,Item01,1.00,…..?[CRLF]
Queue Name B:
01,Token01,Line1,Wave01,Pallet01,AssortRef01,DDMMYYYYHHMMSS,,Item01,100.00,…..?[CRL
Those two messages expected to pickup and process in different purpose on application side.
Basic and really helpful to understand what is MQ and how it works.
In Real test scenario – I have one Test system which connects to outside system using MQ in production. How can i simulate that outside system in my test environment ? Is there any way out for this case?
Let me give example: ICICI Bank sends message to Processing system with XML fields of ACCNO, NAME, AMT, DATE etc. I am tester of ICICI Bank Application. I want to verify the request and response. How can I do that? I.e. I am a sender and receiver but other system is outside my test environment. How to simulate it?
Nice And very Informative with brief explanation