MQ SERIES

1 Introduction:

MQSeries is a middleware product from IBM that runs on multiple platforms and
enables applications to send messages to other applications. Basically, the sending
application puts a message on a Queue, and the receiving application gets the
message from the Queue. The sending and receiving applications do not have to be
on the same platform, and do not have to be executing at the same time. It allows
independent and potentially non-concurrent applications on a distributed system to
communicate with each other. MQ is available on a large number of platforms (both
IBM and non-IBM), including z/OS (mainframe), OS/400 (IBM System i or AS/400),
Transaction Processing Facility, UNIX (AIX, HP-UX, Solaris), HP Nonstop, OpenVMS,
Linux, and Microsoft Windows.

MQSeries takes care of all the storage, logging and communications details required
to guarantee delivery of the message to the destination queue. In most cases, it will
take care of translating the data when the source and destination use different
character sets (EBCDIC on MVS vs. ASCII on NT or Unix). All the applications have to
do is know the name of the Queue and agree on the meaning of the message.

MQ Series API

• First connect to a Queue Manager

• Open a queue
• Put or get messages in queue
• Close a queue
• Commit or roll back
• Disconnect

FIG 1: Program A sends a message to program B via queue 1.

2. The MQSeries family:

• MQSeries Messaging never looks into the content of a message, but

reliably delivers it, supporting put, get, and commit functions to transactional
units of work that talk to each other. It provides for almost universal
application connectivity, even to many Competitive systems, by a wide
variety of application adapters available from IBM and partners.

• MQSeries Integrator is a powerful message broker that provides real-

time, intelligent rules-based message routing, database updates, data
enrichment with data obtained from databases, content transformation and
formatting. This product simplifies application integration. Without the
Integrator, for every pair of communicating applications, you would need to
make changes because the messages have changed. You must adopt
applications two by two to make them understand the messages exchanged.
For example, suppose that Application1 communicates with Application2 and
Application3. If Application1 is changed, that has impact on Application2 and
Application3. To avoid this, you may want to put the MQSI in between and
let it perform the message transformations and re-routing needed, while
leaving the application code unchanged.
• MQSeries Workflow provides a process automation system for managing
people, data, applications, and business processes throughout an
organization, including external partners via the Internet or intranets and
extranets.

• MQSeries Everyplace brings reliable connection to mobile workers. It

provides MQSeries from mobile, pervasive or handheld devices, such as
 PalmOS, Java on EPOC, WinCE, Windows 95 and 98, as well as Windows NT
and 2000

4. MQSeries Objects:

4.1 Messages

A message consists of two parts:

- Data that are sent by one program to another.
- A message descriptor or message header

• A message any arbitrary data that one program wants to send to another.
This data is called the application data.
Ex:
1. A record from an indexed or flat file
2. A row from a DB2 table
3. Individual columns from DB2 tables
4 Multiple rows or records

• Header contains elements like unique message id, routing information,

message format.

4.2 Queue manager

The heart of MQSeries is the message queue manager (MQM). Its job is to
manage queues and messages for applications. It provides the Message
Queuing Interface (MQI) for communication with applications. Application
programs invoke functions of the queue manager by issuing API calls. For
example, the MQPUT API call puts a message on a queue to be read by
another program using the MQGET API call. This scenario is shown in below
diagram.
 A program may send messages to another program that runs in the
same machine as the queue manager shown in above diagram, or to a
program that runs in a remote system, such as a server or a host. The
remote system has its own queue manager with its own queues. This
scenario is shown in below diagram.

.
The queue manager transfers messages to other queue managers via
channels using existing network facilities, such as TCP/IP, SNA or SPX.
Multiple queue managers can reside in the same machine. They also need
channels to communicate.

An application must establish a communication with the Queue manager

before it can access its resources. For this it uses the commands MQCONN or
MQCONNX. If the application no longer requires a connection to the Queue
manager, MQDISC is used to disconnect.

In order to access a Queue, an application must first open this Queue. This is
done by means of the MQOPEN call. With MQCLOSE, the Queue is closed
again.
 The queue manager logs all activity with each individual queue thus creating
an audit trail. Multiple queue managers can coexist with each other. The
limiting factor is the availability of system resources.

When installing MQSeries on a server, the Queue manager must be setup by

a systems programmer.

Creating a Queue Manager:

You may create as many queue managers as you like and have them running
at the same time. You create a queue manager with the command crtmqm;
to make it the default, specify the parameter /q.

The following command creates the default queue manager MYQMGR (in a
Windows NT environment):
crtmqm /q MYQMGR

4.3 Queue

Queues are defined as objects belonging to a queue manager. MQSeries

knows a number of different queue types, each with a specific purpose. The
queues you use are located either in your machine and belong to the queue
manager to which you are connected, or in your server (if you are a client).
Figure below lists different queue types and their purposes.

Local Queue
A queue is local if it is owned by the queue manager to which the application
program is connected. It is used to store messages for programs that use the
same queue manager. For example, program A and program B each has a
queue for incoming messages and another queue for outgoing messages.
Since the queue manager serves both programs, all four queues are local.

Remote Queue
A queue is “remote” if it is owned by a different queue manager. A remote
queue definition is the local definition of a remote queue. A remote queue is
 not a real queue. It is a structure that contains some of the characteristics of
a queue hosted by a different queue manager

Transmission Queue
This is a local queue with a special purpose. A remote queue is associated
with a transmission queue. Transmission queues are used as an intermediate
step when sending messages to queues that are owned by a different queue
manager.

Typically, there is only one transmission queue for each remote queue
manager (or machine). All messages written to queues owned by a remote
queue manager are actually written to the transmission queue for this
remote queue manager. The messages will then be read from the
Transmission queue and sent to the remote queue manager

Alias Queue
Alias queues are not real queues but definitions. They are used to assign
different names to the same physical queue. This allows multiple programs to
work with the same queue, accessing it under different names and with
different attributes.

Model Queue
A model queue is not a real queue. It is a collection of attributes that are
used when a dynamic queue is created.

4.4 Channel

A channel provides a communication path between Queue Managers.

There are two types of channels - Message Channels and MQI channels
(also called Client channels).

1. Message channels
A message channel connects two queue managers via message channel
agents (MCAs). Such a channel is unidirectional. It comprises two message
channel agents, a sender and a receiver, and a communication protocol. An
MCA is a program that transfers messages from a transmission queue to a
communication link and from a communication link into the target queue .For
bidirectional communication you have to define two channel pairs consisting
of a sender and a receiver. Message channel agents are also referred to as
movers.

2. MQI channels
A Message Queue Interface (MQI) channel connects an MQSeries client to a
queue manager in its server machine. Clients don’t have a queue manager of
their own. An MQI channel is bidirectional
 Above figure shows both channels types. We can see four machines, two
clients connected to their server machine via MQI channels, and the server
connected to another server or a host via two unidirectional message
channels. Some channels can be defined automatically by MQSeries.

5.1 Mqseries API calls:

Queue manager

MQCONN - connect to QM
MQDISC - disconnected from QM

Queues

MQOPEN – open a queue

MQCLOSE - close a queue

Messages

MQGET - get messages

MQPUT - put a message

ATTRIBUTES

MQINQ - inquire about object attributes (queue, queue manager)

MQSET - set object attributes

Transaction

MQBEGIN - Start transaction

MQCMIT - Commit transaction
MQBACK - Backout transaction
5.2 Application communication

We have two types off application communications

1. Fire and forget

In this method the sender application will not get any

acknowledgement from receiver application

2. Request/response

In this method the sender will get reply from the receiver
application
6. Example of a business process

MQSeries Workflow comes with two samples. We will use the smaller of them, the
processing of a credit request, to explain the principle of how to define a business
process. The below figure is the graphical representation of this Process. To accept or
reject a credit request, the following steps have to be executed

1. At the beginning of the process, data regarding the applicant has to be

Collected. This is usually done through a GUI.

2. Next, the risk has to be assessed. This can be done automatically by a

Program or by a person reviewing the data entered in the previous step. The result
of this step will be a risk factor.

3. Depending on the risk factor and the requested credit amount, there are
Two options:
• The credit request is accepted because the risk is low.
• Another step is required to approve or reject the request.
The decision what to do next can be left to Workflow.

4. If the risk factor assigned by the Assess Risk program is anything but low, a
person has to evaluate the request and make a decision based on other criteria

5. At the end, the credit request is either approved or denied.

Now we defined the steps in the business process and the order they have to be
executed. This scenario is shown in above figure. Each of the blocks in above Figure
represents an activity, to be executed by either a program or a person.
The below figure shows how this process is modeled in Build time.

The icons in above figure are called nodes. The icon on the left side is a source
node. It starts the business process. The others are called program activities.
Some comments on this graph follow:

1. Notice the solid and broken lines. The solid lines are called control connectors and
represent the logical flow in the process. The broken lines are data connectors and
represent the data flow between nodes.

2. Some of the control connectors (solid lines) are associated with a text. These are
conditions that will be evaluated by Workflow Runtime. They are specified in the
properties of the connector.

3. One of the control connectors leaving the Assess Risk node shows a small circle. This
is a default connector. Workflow will use it when the condition attached to the other
control connector is not true

4. The data necessary to do the evaluations flows over the data connectors in
"containers". Container data is used internally by Workflow. However, an application
program has access to them and can set them using APIs.

5. In this example, initial data is specified, represented by the broken line from the
source node to the first program activity.

6. Container data is information that Workflow uses to navigate through the process. In
this example this includes risk factor, credit amount and the variable Add Approval.
Of course, container data can be accessed, updated and added by the application
(through Workflow APIs).

7. There are more properties to define, such as the name of the program that has to be
executed in each node and also which person or group of persons is authorized to
perform the activity. The completed process model has to be saved in a DB2
database
7. Defining a new MQSeries Workflow user
1. Start the MQSeries Workflow Buildtime client by using the taskbar and
Selecting:

Start
Programs
MQSeries Workflow
MQSeries Workflow Buildtime – FMC

2. Enter the user ID ADMIN and password ****** to log on to Buildtime.This

brings up the window shown in below figure.

3. Select the Staff tab.

4. Right-click the Persons folder (shown in below Figure) and, from

the context menu, select New Person.
5. In the Person Properties window, shown in Figure 24, enter
the following:

a. On the General tab:

• Enter a user ID, for example WFADMIN4.

• Enter a password, for example password, and confirm it.
• Ensure that FMCGRP appears in the associated system group field.
If not, enter FMCGRP or click the Find button (flashlight icon) which
will display the Find System group window shown in Figure 25. Select
FMCGRP and click OK.
• If FMCSYS is not in the preferred system field, type it in or click the
Find button (flashlight icon) again. This causes the Find System
window to be displayed. It looks just like Figure 25, except for the
title. Select FMCSYS and click OK.
b. Now click the Information tab and enter a short description, such as
“Workflow user with maximum authorizations”

c. Click the Authorizations tab and you will see the window shown in
Figure 26
 • Check all boxes to allow the user to perform all functions.
• Select All persons and the other radio buttons as shown.

d. Click OK. We do not use the Staff tab here. On the left side of the
window you will now see two user IDs, ADMIN and WFADMIN.

8. Using MQSeries Runtime

The activities or steps in a workflow are executed in the MQSeries Workflow
Client also called the Runtime Client or RTC for short. It connects to the MQSeries
Workflow Runtime Server. This implies that the MQSeries Workflow Runtime
Server has to be not only up and running, but it also has to "know" the process
that we intend to execute.
The Workflow product comes with a Runtime Client. To use this client, you
have to know a little about models, templates and instances. For your own
applications, you will most likely write your own client.

8.1 Starting the MQSeries Workflow Client

Start the MQSeries Workflow Client by selecting from the taskbar:

Start
Programs
MQSeries Workflow
MQSeries Workflow Client - FMC
The RTC will start and bring up the logon window. Your current Windows
NT user ID will appear in the user ID field. If you have defined a workflow
user with the same ID, just enter the password and click OK. Otherwise,
change the user ID first.
9. Benefits of MQSeries

9.1 Interoperability
• across dissimilar networks
• between different computing environments

9.2 Asynchrony

Eliminates the time dependency between applications (both apps must

be alive AND have a session in synchronous models).

9.3 Fewer Network Sessions

Only Queue Mangers need to communicate using network sessions.

9.4 Administered Objects

Improves manageability of BIG systems -

Can monitor the state of a queue to determine if apps are doing what they
should:

• Does any process have queue open for reading or writing?

• Has a high water mark been reached?
• How many messages have been added and removed in a measured interval?

9.5 Message Persistence == Assured Delivery

• Queues in stable storage retain messages even if applications fail.

• Even memory-only queues persist if at least the Queue Manager stays
up.