IBM WebSphere MQ Tutorial

IBM MQ is robust messaging middleware that simplifies and accelerates the integration of diverse applications and business data across multiple platforms. IBM MQ facilitates the assured, secure and reliable exchange of information between applications, systems, services and file by sending and receiving message data via messaging queues, thereby simplifying the creation and maintenance of business applications. It delivers Universal Messaging with a broad set of offerings to meet enterprise-wide messaging needs, as well as connectivity for the internet of things and mobile devices.

What is WebSphere MQ?

This document contains step by step technical information to learn MQ series, by using this one can start working with control and WebSphere MQ script commands through the Windows Explorer and UNIX/AIX Command line interface.

MQSeries runs on a variety of platforms. The MQSeries products enable programs to Communicate with each other across a network of unlike components, such as processors, subsystems, operating systems and communication protocols. MQSeries programs use a consistent application program interface (API) across all platforms.

MQSeries can be configured to provide assured delivery of the messages. Assured delivery means that even if the hardware or software platform crashes the messages within the system will still be delivered, once the platforms are brought back up. On a typical target system MQSeries consists of a queue manager and a number of queues and channels.

Message in MQ

An WebSphere MQ Series message is simply a collection of data sent by one program and intended for another program. The message consists of control information and application specific data. The control information is required in order to route the message between the programs to some extent. A message can be classed as persistent or non- persistent. A persistent message will survive a software or hardware crash / reboot, once communicated to a queue manager, whereas a non-persistent message will not survive. Persistent messages are used as part of the implementation of the assured delivery service supported by MQSeries.

MQ Queue Manager

It is the queue manager that provides the queuing services to the application programs. A queue manager in MQ Series also provides additional functions so that administrators can create new queues, alter the properties of existing queues and control the operation of the queue manager. Many applications can make use of the queue manager’s facilities at the same time, and they can be completely unrelated. It is possible to connect queue managers on different platforms together, this is achieved via a mechanism called channels.

Websphere Message Queues

Queues are named message repositories upon which messages accumulate until they are retrieved by programs that service those queues. WebSphere MQ Queues reside in, and are managed by, a queue manager. Programs access queues via the services provided by the queue manager. They can open a queue, put messages on it, get messages from it, and close the queue. It is also possible to programmatically set, and inquire about, the attributes of queues. Queues are either defined as local or remote. Local queues allow programs to both put messages on, and get messages off, while remote queues only allow programs to put messages on. Remote queues are used in order to provide put access to queues that are local to another platform. Any message put onto a remote queue is automatically routed to the associated platform and local queue by the queue manager via the channels mechanism.

Channels

Channels are named links between platforms across which messages are transmitted. On the source platform the channel would be defined as a sender and on the destination platform as a receiver. It is the sender channel definition that contains the connectivity information, such as the destination platform’s name or IP address. MQ Series Channels must have the same name on both the source and destination platform.

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 massage transportation.

What is System Testing

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.

Get On-Demand IBM Websphere MQ Training from TOP-Rated Instructors

• Instructor-led Sessions
• Real-life Case Studies
• Assignments

Explore Curriculum

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 applications, with queue manager-APPSQM, channel-APPSCH, queue name-MQS, portnum-11112
• APPP is a product processing application, with queue manager-APP PQM, 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.

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 – APP sends data to APPS

This time the config files will be different at both sides. The MQ config file at APP will have different queue info like Queue Manager-APPQMR, channel-APP CHR, 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.

MQ related issues during testing

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.

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  has succeeded in introducing the concept and opened avenues for further exploration and mastery.