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 QueueA 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 QueueA 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 QueueThis 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 QueueAlias 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 QueueA 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 channelsA 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 channelsA 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:

StartPrograms

MQSeries WorkflowMQSeries 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, fromthe context menu, select New Person.

5. In the Person Properties window, shown in Figure 24, enterthe 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 WorkflowClient 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 WorkflowMQSeries 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.