Monday, February 2, 2009

MQ Installation and Server to Server Communication on Solaris

Objective:

This article describes the detailed instructions of Websphere MQ installation, configuration of Queue Managers and setting up Server to Server Communication between two MQ Servers.

Before going into the main part, would like to walk through on MQ and it's components.

About MQ

As a whole, MQSeries enables messages to be exchanged, either synchronously or asynchronously, between application programs running on one or more target systems. Messages traveling between programs are stored on message queues, which are under the control of a service provider called a queue manager. In general,a queue manager is required on each target system.

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

An MQSeries 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, and, to some extent, describe the contents of the application data section. The application data is free-form and MQSeries places no overall constraint on the contents. 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.

Queue Managers

It is the queue manager that provides the queuing services to the application programs. A queue manager 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. It is possible to connect queue managers on different platforms together, this is achieved via a mechanism called channels.

Queues

Queues are named message repositories upon which messages accumulate until they are retrieved by programs that service those queues. Queues reside in, and are managed by, a queue manager. They can open a queue, put messages on it, get messages from it, and close the queue. 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. Channels must have the same name on both the source and destination platform.

Installation

Download MQ 6 trial version from the below URL to the Solaris system

https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?S_PKG=sparc&source=wsmq90&S_TACT=105AGX28&S_CMP=TRIALS

  • Create a mqm group < groupadd -g 998 mqm >
  • Create an user and add it to the group < useradd -u 999 -g mqm -c "mq user" mqm >
  • Change the password of the newly created user < passwd mqm >

Most of the installables are in the form of .gz/.z extensions, we need to extract them using gunzip/gzip utility.

  1. gunzip WMQv600Trial-sparc_solaris.tar.Z this extracts the actual installable to current directory. After running this command, user can observe this file in the current directory, WMQv600Trial-sparc_solaris.tar, which is the archive package for installables
  2. Untar the file using tar command tar xvf WMQv600Trial-sparc_solaris.tar which extracts the installation into current directory
  3. Agree the license by executing mqlicense.sh file in the extracted directory
  4. Run the installations by adding packages into system using the pkgadd utility
  5. pkgadd –d. (This command shows the available packages in the current directory)
    Add all packages


Setup of sample Queue Manager & Queue

  1. Create a Queue Manager
    • crtmqm –q qmDefault
  2. Start the queue manager
    • strmqm qmDefault
  3. Create a Queue
    • runmqsc (To enable MQSC commands)
    • define qlocal (‘qTest’)
    • end (To stop MQSC)
  4. Put a Message in queue
    • cd /opt/mqm/samp/bin
    • ./amqsput qTest
    • Enter the input text as "This is a sample message" and press Enter twice
  5. Retrieve a Message
    • cd /opt/mqm/samp/bin
    • ./amqsget qTest

SERVER TO SERVER COMMUNICATION

Setup of Sender Workstation

  1. Create a default queue manager called QMSENDER. At a command prompt in a window, enter the following command:
crtmqm -q QMSENDER

The -q option specifies that this queue manager is the default queue manager.

Messages tell you that the queue manager is created, and that the default WebSphere® MQ objects are created.

  1. Start the default queue manager. Enter the following command:
strmqm QMSENDER

A message tells you when the queue manager starts.

  1. Enable MQSC commands. Enter the following command:
runmqsc

The message Starting WebSphere MQ Commands is displayed when MQSC has started. MQSC has no command prompt.

  1. In the MQSC command window, define a local queue to use as a transmission queue called QMA. Enter the following command:
define qlocal(TRANSMITQSENDER) usage(xmitq)

The message WebSphere MQ queue created is displayed when the queue is created.

  1. In the MQSC command window, create a local definition of the remote queue. Enter the following command:

define qremote(LOCAL.DEF.OF.REMOTE.QUEUE) rname(SAMPLE.QUEUE) rqmname('QMRECEIVER') xmitq(TRANSMITQSENDER)

The rname parameter specifies the name of the queue on the remote machine to which the message will be sent. Therefore, the name that the rname parameter specifies must be the name of the queue to which you want to send the message (that is, sample.queue on the receiver workstation). rqmname is the queue manager name on the remote machine.

  1. In the MQSC command window, define a sender channel. Enter the following command:

define channel(QMSENDER.QMRECEIVER) chltype(sdr) conname("con-name(port)") xmitq(TRANSMITQSENDER) trptype(tcp)

Where:  

con-name is the TCP/IP address of the receiver workstation.

port is the port on which the listener will be running on the receiver machine, the default value is 1414.

  1. In the MQSC command window, stop MQSC. Stop MQSC. Enter the Command: end

You have now defined the following objects:

  • A default queue manager called QMSENDER
  • A transmission queue called TRANSMITQSENDER
  • A remote queue called LOCAL.DEF.OF.REMOTE.QUEUE
  • A sender channel called QMSENDER.QMRECEIVER

Setup of Receiver Workstation

  1. Create a default queue manager called QMRECEIVER. At the command prompt, enter the following command:

crtmqm -q QMRECEIVER

Messages tell you that the queue manager is created, and that the default WebSphere® MQ objects are created.

  1. Start the queue manager. Enter the following command:

strmqm

A message tells you when the queue manager starts.

  1. Open a new command prompt window and enable MQSC commands. Enter the following command:

runmqsc

The message Starting WebSphere MQ Commands is displayed when MQSC starts. MQSC has no command prompt.

  1. In the MQSC window, define a local queue called SAMPLE.QUEUE. Enter the following command:

define qlocal(SAMPLE.QUEUE)

The message WebSphere MQ queue created is displayed when the queue is created.

  1. In the MQSC window, create a receiver channel. Enter the following command:

define channel(QMSENDER.QMRECEIVER) chltype(rcvr) trptype(tcp)

  1. In the MQSC window, start the default WebSphere MQ listener by entering the following command:

start listener(SYSTEM.DEFAULT.LISTENER.TCP)

  1. In the MQSC window, verify the listener process has started by executing the command:

display lsstatus(SYSTEM.DEFAULT.LISTENER.TCP)

  1. In the MQSC window, stop MQSC. Enter the following command:

end

You have now defined the following objects:

  • A default queue manager called QMRECEIVER
  • A queue called SAMPLE.QUEUE
  • A receiver channel called QMSENDER.QMRECEIVER

Starting Channel

  1. If the queue managers on the two workstations have stopped for any reason, restart them now using the strmqm command.
  2. On the sender workstation, enable MQSC commands. Enter the following:

runmqsc

  1. Using the MQSC window, start the sender channel. Enter the following command:

start channel(QMSENDER.QMRECEIVER)

The receiver channel on the receiver workstation is started automatically when the sender channel starts.

  1. Using the MQSC window, stop MQSC. Enter the following command:

end

Testing Communication between the Workstations

  1. On the sender workstation, in a new command window, put a message on the queue by entering the following command from /opt/mqm/samp/bin directory
amqsput LOCAL.DEF.OF.REMOTE.QUEUE

This puts the message to the local definition of the remote queue, which in turn specifies the name of the remote queue.

  1. Type the text message, then press Enter twice.
  2. On the receiver workstation, get the message from the queue by entering the following command from /opt/mqm/samp/bin directory
amqsget SAMPLE.QUEUE

The sample program starts, and your message is displayed. After a short pause, the sample ends and the command prompt is displayed again.

Thus it proves the server to server communication by sending one message from the remote queue on the sender workstation to the local queue on the receiver workstation using XMITQ, Sender/Receiver Channels and Listener.


No comments: