Connecting to WebSphere MQ
All network communication with WebSphere® MQ queue managers, including communication related to WebSphere MQ File Transfer Edition, involves WebSphere MQ channels. A WebSphere MQ channel represents one end of a network link. Channels are classified as either message channels or MQI channels.
WebSphere MQ File Transfer Edition and channels
MQI channels are used by applications in client
mode (rather than bindings mode) to connect to queue managers. MQI
channels are bidirectional; they carry WebSphere MQ API calls (for example, GET
a message from queue XYZ
) from the application to the queue manager.
They also carry responses to those calls from the queue manager back
to the application. There are two types of MQI channel: server connection
(SVRCONN) and client connection (CLNTCONN). SVRCONN channels define
the queue manager endpoint of the link. CLNTCONN channels can be used
by some kinds of client to define the client endpoint, but are not
used by WebSphere MQ
File Transfer Edition.
WebSphere MQ File Transfer Edition uses MQI channels to connect agents in client mode to their agent queue managers, and to connect command applications (for example, fteCreateTransfer) to their command and coordination queue managers. In the default configuration, these connections are made using a SVRCONN channel called SYSTEM.DEF.SVRCONN, which exists by default on all queue managers. Because of these defaults, you do not need to alter any MQI channels for a basic WebSphere MQ File Transfer Edition installation.
Message channels carry fully-formed WebSphere MQ messages between queue managers. Message channels are unidirectional; if you need messages to flow in both directions you must create a pair of channels, one for each direction. WebSphere MQ queue managers do not communicate with one another except through these channels, so although WebSphere MQ File Transfer Edition does not directly interact with message channels, the channels are vital to configuring a functioning WebSphere MQ File Transfer Edition network.
There are six types of message channel, but this topic covers only sender-receiver pairs. See Message channels for information about other channel combinations.
Required message paths
WebSphere MQ messages can travel over message channels only, so you must ensure that channels are available for all message paths required by WebSphere MQ File Transfer Edition. These paths do not need to be direct; messages can travel through intermediate queue managers if required. This topic covers only direct point-to-point communication. See How to get to the remote queue manager in the IBM® WebSphere MQ Version 7.0.1 product documentation.- Agent to agent
- Any two agents that files are transferred between require bidirectional communication between their associated queue managers. Because this path carries the bulk data, consider making the path as short, fast, or cheap as possible according to your needs.
- Agent to coordination
- Log messages from the agents that participate in a transfer must be able to reach the coordination queue manager.
- Command to agent
- Any queue manager that command applications or the WebSphere MQ Explorer (using the command queue manager) connect to must be able to send messages to the queue managers of the agents that those command applications are used to control. To enable feedback messages to be shown by the commands, use a bidirectional connection.
Creating a sender-receiver channel
The following instructions show you how to create a standard point-to-point channel using the TCP network protocol. The channel goes from an example queue manager called LONDON to an example queue manager called NEWYORK and is created using either the WebSphere MQ Explorer or the command line. The link created by these instructions operates in one direction only: from LONDON to NEWYORK. If you need bidirectional communication, you must repeat the steps with queue manager names reversed to create a link in the opposite direction.Using the WebSphere MQ Explorer
- Create the LONDON endpoint:
- In the Navigator view, ensure that the WebSphere MQ Explorer is connected to queue manager LONDON and expand LONDON.
- Right-click the Channels folder and select .
- Type a channel name. For example: LONDON.TO.NEWYORK and click Next.
- In the Connection Name field, type the host name and port of the NEWYORK queue manager. For example: mq.newyork.example.com(1414).
- In the Transmission Queue field, type NEWYORK. This value must be the name of the queue manager that this channel connects to. Click Finish.
- Create the transmission queue:
A transmission queue is required to hold messages waiting to go through the channel. Messages for a remote queue manager are placed on the transmission queue named after that queue manager, so in this example the transmission queue must be called NEWYORK.
- In the Navigator view, under the LONDON queue manager right-click the Queues folder and select .
- Type the queue name NEWYORK. Click Next.
- Change the value of the Usage field from Normal to Transmission. Click Finish.
- Create the NEWYORK endpoint:
- In the Navigator view, ensure that the WebSphere MQ Explorer is connected to the queue manager NEWYORK. Expand NEWYORK.
- Right-click the Channels folder and select .
- Type the name of the channel. This name must be the same name as the matching sender channel. For example: LONDON.TO.NEWYORK. Click Finish.
- Start the channel:
- In the Channels folder of queue manager LONDON, right-click the new channel and select Start.
Using MQSC
If you want to create the channel using MQSC, run the following example commands. Change the queue manager and channel details as required:echo "define channel(LONDON.TO.NEWYORK) chltype(SDR) conname('mq.newyork.example.com(1414)') xmitq(NEWYORK)" | runmqsc LONDON
echo "define qlocal(NEWYORK) usage(XMITQ)" | runmqsc LONDON
echo "define channel(LONDON.TO.NEWYORK) chltype(RCVR)" | runmqsc NEWYORK
The
preceding MQSC syntax applies to a UNIX system
with the target queue manager running on the same system as the command.
You can also use runmqsc on Windows and with remote queue managers. The
channel names used on each side of the link must be the same. The
name used for the transmission queue must be the name of the queue
manager that the link points to. For information about using MQSC, see Performing local administration tasks using MQSC commands.
Listeners
Because a queue manager can receive connections on multiple network interfaces, and on multiple ports on each TCP interface, objects called listeners are used to configure each connection point. Each listener can receive connections from many peers and route the traffic through many separate channels, so often only a single listener is needed. However, by default, queue managers have no listeners configured and so you might need to create one.- In the Navigator view, expand the Queue Managers section and click the Listeners folder.
- Examine the list of listeners in the Content pane. If at least one listener shows a status of Running, the queue manager is listening on the port shown in that listener's Port column. If this port is acceptable, you do not need to do any further configuration and you can use the port number when configuring sender channels to point to this queue manager.
- By default, the list of listeners contains a listener called
SYSTEM.DEFAULT.LISTENER.TCP
, with Control set to Manual and Port set to 0. You can configure this listener to make the queue manager listen to a particular port: Right-click the listener and select Properties.- Change the Port field to your preferred port number (1414 is the standard for WebSphere MQ queue managers). Each port number on a system can only be used by a single application.
- Change the Control field to Queue Manager to avoid the need to manually start the listener when the queue manager is restarted.
- If the listener you want to use is not running, right-click the listener and select Start.
Using MQSC
If you want to use MQSC to work with the listener, run the following example commands. Change the queue manager and port number as required:echo "alter listener(SYSTEM.DEFAULT.LISTENER.TCP) trptype(TCP) port(1414) control(QMGR)" | runmqsc NEWYORK
echo "start listener(SYSTEM.DEFAULT.LISTENER.TCP) " | runmqsc NEWYORK
For more information about using MQSC, see Performing local administration tasks using MQSC
commands.