WebSphere® MQ Integrator


Introduction and Planning

Version 2.1

GC34-5599-04
WebSphere® MQ Integrator


Introduction and Planning

Version 2.1

GC34-5599-04
 Note!
Before using this information and the product it supports, be sure to read the general information under Appendix C,
“Notices” on page 195.

Fifth edition (March 2002)

This edition applies to IBM® WebSphere MQ Integrator Version 2.1 and to all subsequent releases and modifications
until otherwise indicated in new editions.
© Copyright International Business Machines Corporation 2000, 2002. All rights reserved.
US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract
with IBM Corp.
 Contents
Figures . . . . . . . . . . . . . . vii Importing messages predefined by the Control
Center . . . . . . . . . . . . . . . 23
Tables . . . . . . . . . . . . . . . ix Messages predefined by the New Era of
Networks Formatter . . . . . . . . . . 23
Self-defining messages. . . . . . . . . . 24
About this book . . . . . . . . . . . xi Support for JMS messages . . . . . . . . 24
Who should read this book . . . . . . . . . xii Multipart messages . . . . . . . . . . . 24
What you need to know to understand this book. . xii Parsing messages . . . . . . . . . . . 25
Terms used in this book . . . . . . . . . . xii Associating message sets with brokers . . . . 25
Applications and clients . . . . . . . . . . 26
Summary of changes . . . . . . . . xiii Point-to-point applications . . . . . . . . 26
| Changes for this edition (GC34-5599-04) . . . . xiii | Aggregation of messages . . . . . . . . . 26
Changes for the fourth edition (GC34-5599-03) . . xiii Publish/subscribe applications . . . . . . . 27
Changes for the third edition (GC34-5599-02) . . . xiii Client connections to brokers and message flows 28
Changes for the second edition (GC34-5599-01) . . xiv The User Name Server . . . . . . . . . . 29
Resources associated with a User Name Server 30
Access control Lists. . . . . . . . . . . 30
Part 1. Introduction . . . . . . . . . 1
MQSeries Everyplace and SCADA. . . . . . . 31
MQSeries Everyplace overview . . . . . . . 31
Chapter 1. MQSeries and business Communicating with MQSeries Everyplace from
integration . . . . . . . . . . . . . 3 WebSphere MQ Integrator . . . . . . . . 33
Using MQSeries for business integration . . . . . 3 SCADA applications . . . . . . . . . . 36
MQSeries . . . . . . . . . . . . . . 4 Dependencies. . . . . . . . . . . . . . 37
WebSphere MQ Integrator . . . . . . . . . 4 MQSeries dependencies . . . . . . . . . 37
MQSeries Workflow . . . . . . . . . . . 4 Database dependencies . . . . . . . . . 38
Using WebSphere MQ Integrator in your business . . 5 Release to release migration . . . . . . . . . 40
Getting started with WebSphere MQ Integrator . . 5
WebSphere MQ Integrator Version 2.1 and previous Chapter 3. WebSphere MQ Integrator: a
IBM offerings . . . . . . . . . . . . . . 7 business scenario . . . . . . . . . . 41
The retail scenario . . . . . . . . . . . . 42
Chapter 2. WebSphere MQ Integrator Business data . . . . . . . . . . . . . 43
overview and concepts . . . . . . . . 9 Business needs . . . . . . . . . . . . 44
Overview of WebSphere MQ Integrator . . . . . 9 Business solution using WebSphere MQ
Brokers . . . . . . . . . . . . . . . . 10 Integrator Version 2 . . . . . . . . . . 44
Resources associated with a broker . . . . . 10 Implementing the business solution . . . . . 46
Adding a broker to the broker domain . . . . 10
Connecting brokers for publish/subscribe . . . 11
System management interfaces . . . . . . . 12
Part 2. Business process planning 47
The Configuration Manager . . . . . . . . . 13
Resources associated with the Configuration Chapter 4. Message flows . . . . . . 49
Manager . . . . . . . . . . . . . . 14 What is a message flow? . . . . . . . . . . 50
The Control Center . . . . . . . . . . . . 15 What does a message flow consist of? . . . . 50
Updates, assignment, and deployment . . . . 16 Message flows and units of work . . . . . . 51
Exporting and importing resource definitions . . 17 Parallel processing of message flow instances . . 51
Help and online Tour . . . . . . . . . . 17 Interaction of message flows. . . . . . . . 52
Message flows . . . . . . . . . . . . . 18 Transformation . . . . . . . . . . . . 52
Creating message flows . . . . . . . . . 18 Intelligent routing . . . . . . . . . . . 53
Transaction support . . . . . . . . . . 19 Enriching message content . . . . . . . . 53
Message flow input and output. . . . . . . 19 What is a message processing node? . . . . . . 54
Publish/subscribe services . . . . . . . . 19 Common node characteristics . . . . . . . 54
Associating message flows with brokers . . . . 20 Input and output nodes . . . . . . . . . 55
Simple message flow examples . . . . . . . 21 Processing messages . . . . . . . . . . 55
Messages and message sets . . . . . . . . . 22 Error handling . . . . . . . . . . . . 56
Messages predefined in the Control Center . . . . 23 What is an execution group? . . . . . . . . 58
Importing legacy message definitions. . . . . 23 Message flows and message sets . . . . . . . 59

© Copyright IBM Corp. 2000, 2002 iii

Message flows for publish/subscribe services . . . 60 Using wildcards with topics . . . . . . . . 98
Supplied message flows and nodes . . . . . . 61 Multiple topics . . . . . . . . . . . . 99
Primitive node types . . . . . . . . . . 61 Broker networks . . . . . . . . . . . . . 99
Supplied message flows . . . . . . . . . 64 Collectives . . . . . . . . . . . . . 100
Adding or enhancing message processing nodes . . 66 How publications and subscriptions flow through
Message flow porting issues . . . . . . . . . 66 the network . . . . . . . . . . . . . . 100
Using the Debugger to solve message flow problems 67 Topic-based security . . . . . . . . . . . 101
Principals and the User Name Server . . . . 101
Chapter 5. Messages. . . . . . . . . 69 Access control lists . . . . . . . . . . 101
Predefined and self-defining messages . . . . . 69 Checking publications and subscriptions . . . 105
Predefined messages using the MRM . . . . . 70 Summary. . . . . . . . . . . . . . . 106
Message templates . . . . . . . . . . . 70
New Era of Networks format messages . . . . 72 Part 4. Systems planning . . . . . 107
How messages are processed in a message flow 72
Exporting and importing MRM message sets . . 73
Chapter 8. System requirements . . . 109
Using message templates and messages . . . . . 73
Summary of system requirements . . . . . . 109
Client access to messages . . . . . . . . . 74
System requirements for AIX components . . . . 111
Message parsers . . . . . . . . . . . . . 74
Hardware requirements . . . . . . . . . 111
Default message parsers . . . . . . . . . 74
Disk space required . . . . . . . . . . 111
Creating additional parsers . . . . . . . . 76
Software requirements . . . . . . . . . 111
System requirements for HP-UX components . . . 113
Part 3. Application planning . . . . 77 Hardware requirements . . . . . . . . . 113
Disk space required . . . . . . . . . . 113
Chapter 6. Application design . . . . . 79 Software requirements . . . . . . . . . 113
Communication models . . . . . . . . . . 79 System requirements for Solaris components . . . 115
Point-to-point communications . . . . . . . 79 Hardware requirements . . . . . . . . . 115
Publish/subscribe communications . . . . . 80 Disk space required . . . . . . . . . . 115
Application programming . . . . . . . . . 80 Software requirements . . . . . . . . . 115
Application programming interfaces . . . . . 80 System requirements for Windows NT and
Message headers . . . . . . . . . . . 81 Windows 2000 components . . . . . . . . . 117
MQSeries queues . . . . . . . . . . . 82 Hardware requirements . . . . . . . . . 117
Message order . . . . . . . . . . . . 82 Disk space required . . . . . . . . . . 117
Transaction support . . . . . . . . . . 83 Software requirements . . . . . . . . . 117
Message persistence . . . . . . . . . . 84 System requirements for z/OS components . . . 120
Security . . . . . . . . . . . . . . 85 Hardware requirements . . . . . . . . . 120
Reusing existing applications . . . . . . . . 85 Disk space required . . . . . . . . . . 120
Send and forget . . . . . . . . . . . . 86 Software requirements . . . . . . . . . 120
Request/reply . . . . . . . . . . . . 86 Database support . . . . . . . . . . . . 121
Publish/subscribe . . . . . . . . . . . 87 Client requirements . . . . . . . . . . . 121
Writing new applications . . . . . . . . . . 87 License information . . . . . . . . . . . 121
Summary . . . . . . . . . . . . . . . 88 National language support . . . . . . . . . 122
Supported codesets . . . . . . . . . . 123
Chapter 7. Designing publish/subscribe
applications . . . . . . . . . . . . 89 Chapter 9. Planning your WebSphere
How publish/subscribe applications interact with a MQ Integrator network . . . . . . . 125
broker . . . . . . . . . . . . . . . . 89 Planning WebSphere MQ Integrator resources . . 125
Publications . . . . . . . . . . . . . . 90 Naming conventions . . . . . . . . . . 125
Retained publications . . . . . . . . . . 90 Broker domain basics. . . . . . . . . . 127
Local and global publications . . . . . . . 92 Client applications. . . . . . . . . . . 130
Conference-type applications . . . . . . . 92 Designing the MQSeries infrastructure . . . . . 131
Subscriptions . . . . . . . . . . . . . . 92 MQSeries resources for brokers . . . . . . 132
Subscription points . . . . . . . . . . . 93 MQSeries resources for the Configuration
Filters . . . . . . . . . . . . . . . 94 Manager . . . . . . . . . . . . . . 132
Local subscriptions . . . . . . . . . . . 95 MQSeries resources for the User Name Server 133
Retained publications . . . . . . . . . . 95 MQSeries resources for the Control Center . . 133
Message persistence . . . . . . . . . . 95 MQSeries resources for client applications . . . 135
Topics . . . . . . . . . . . . . . . . 96 MQSeries clusters . . . . . . . . . . . 135
Special characters in topics . . . . . . . . 97 Planning database resources . . . . . . . . 137
Topic semantics and usage . . . . . . . . 98 Database requirements . . . . . . . . . 137
Databases and code pages . . . . . . . . 138

iv WebSphere® MQ Integrator: Introduction and Planning

 Database locations. . . . . . . . . . . 138 MQSeries Publish/Subscribe . . . . . . . . 171
Database backup and recovery . . . . . . 139 Scenarios for migration and integration. . . . 172
Planning security . . . . . . . . . . . . 140 Product differences . . . . . . . . . . 172
Security and principals . . . . . . . . . 140 Scenario 1: running two independent broker
Using Windows NT security domains . . . . 142 networks . . . . . . . . . . . . . . 185
Using UNIX security domains . . . . . . . 144 Scenario 2: creating and operating a
Summary of authorizations . . . . . . . . 144 heterogeneous network . . . . . . . . . 185
Operational security . . . . . . . . . . . 147 Scenario 3: migrating MQSeries
Configurational security . . . . . . . . . 147 Publish/Subscribe brokers . . . . . . . . 186
Run-time security . . . . . . . . . . . 147
Database security . . . . . . . . . . . 148 Appendix B. The product packages 189
MQSeries security . . . . . . . . . . . . 148 The WebSphere MQ Integrator for AIX package 190
WebSphere MQ Integrator for z/OS security . . . 148 The WebSphere MQ Integrator for HP-UX package 191
Control Center security . . . . . . . . . . 148 The WebSphere MQ Integrator for Sun Solaris
The IBMMQSI2 superuser . . . . . . . . 149 package . . . . . . . . . . . . . . . 192
MQSeries authorizations. . . . . . . . . 150 The WebSphere MQ Integrator for Windows NT
Application security . . . . . . . . . . . 150 and Windows 2000 package . . . . . . . . 193
Message flow security . . . . . . . . . 150 TheWebSphere MQ Integrator for z/OS package 194
Topic-based security . . . . . . . . . . 150
Planning for data conversion . . . . . . . . 152
Appendix C. Notices . . . . . . . . 195
Trademarks . . . . . . . . . . . . . . 198
Chapter 10. Managing your
WebSphere MQ Integrator network . . 155 Glossary of terms and abbreviations 199
Managing broker domain components . . . . . 155
Managing application and business processes 156
Monitoring and analysis. . . . . . . . . . 157
Bibliography . . . . . . . . . . . . 205
Problem determination . . . . . . . . . 157 WebSphere MQ Integrator Version 2.1
Managing workload and performance . . . . 160 cross-platform publications . . . . . . . . . 205
System management . . . . . . . . . . 161 WebSphere MQ Integrator Version 2.1
platform-specific publications . . . . . . . . 205
MQSeries Everyplace publications . . . . . . 205
Chapter 11. Enhancing your broker New Era of Networks Rules and Formatter
domain . . . . . . . . . . . . . . 163 Support for WebSphere MQ Integrator publications 206
General guidance for writing plug-ins . . . . . 163 Softcopy books . . . . . . . . . . . . . 206
Writing your own message processing node types 164 Portable Document Format (PDF) . . . . . 206
Writing your own parsers . . . . . . . . . 164 MQSeries library references . . . . . . . . 207
MQSeries Publish/Subscribe publications . . . . 207
Part 5. Appendixes . . . . . . . . 165 MQSeries Workflow publications . . . . . . . 208
DB2 publications . . . . . . . . . . . . 208
MQSeries information available on the Internet . . 208
Appendix A. Planning for migration
and integration. . . . . . . . . . . 167 Index . . . . . . . . . . . . . . . 209
MQSeries Integrator Version 1 . . . . . . . . 167
Installation . . . . . . . . . . . . . 167
Run-time . . . . . . . . . . . . . . 168 Sending your comments to IBM . . . 215

Contents v
vi WebSphere® MQ Integrator: Introduction and Planning
Figures
1. The broker . . . . . . . . . . . . . 11 11. Diagram showing the relationship between
2. A collective . . . . . . . . . . . . 12 MQSeries Everyplace and WebSphere MQ
3. The Configuration Manager . . . . . . . 13 Integrator . . . . . . . . . . . . . 33
4. Message flow components . . . . . . . 18 12. SRU headquarters and branch hierarchy 42
5. A simple Compute node message flow: 13. Branches and back-end systems . . . . . . 43
MQInput -> Compute -> MQOutput . . . . 21 14. The business flow (simplified) . . . . . . 45
6. A simple Filter node message flow: MQInput 15. Publish/subscribe with a single broker 89
-> Filter -> MQOutputA or MQOutput B. . . 21 16. Example topic tree . . . . . . . . . . 96
7. A simple Database node message flow: 17. Publish/subscribe in a network . . . . . . 99
MQInput -> Database -> MQOutput . . . . 21 18. Inheriting ACLs in a topic tree . . . . . . 104
8. A simple Publication node message flow: 19. Collectives with a broker domain . . . . . 129
MQInput -> Publication . . . . . . . . 21 20. A heterogeneous network . . . . . . . 177
9. Applications connecting to a broker . . . . 28 21. Stream authorities . . . . . . . . . . 179
10. The User Name Server . . . . . . . . . 29

© Copyright IBM Corp. 2000, 2002 vii

viii WebSphere® MQ Integrator: Introduction and Planning
Tables
1. ACL permissions . . . . . . . . . . 103 6. Summary of authorizations in the Windows
2. The ACLs for inheritance . . . . . . . 104 NT environment . . . . . . . . . . 145
3. Summary of installation options . . . . . 110 7. MQRFH and MQRFH2 mapping . . . . . 173
4. Supported databases for brokers and user 8. Summary of message option support 174
data. . . . . . . . . . . . . . . 121 9. MQRFH and MQRFH2 client application
5. Summary of authorization in the UNIX options . . . . . . . . . . . . . 176
environments . . . . . . . . . . . 144 10. Migration inhibitors checklist . . . . . . 188

© Copyright IBM Corp. 2000, 2002 ix

x WebSphere® MQ Integrator: Introduction and Planning
About this book
This book provides an overview of IBM WebSphere MQ Integrator Version 2.1.

IBM MQSeries, already an important part of the WebSphere software platform for
e-business, will have an even tighter association with WebSphere. MQSeries,
responsible for dynamic integration, will be known as WebSphere MQ, to reflect
the fundamental part that it plays in dynamic e-business.

MQSeries Integrator, now called Websphere MQ Integrator, is the first product to

change its name; others will follow with new releases. References to WebSphere
MQ products, resources, and concepts within this book continue to refer to
MQSeries to reflect existing product names.

This book introduces the concepts of the product, and provides the information to
help you plan for a WebSphere MQ Integrator network.
Part 1, “Introduction” on page 1
This part gives you a broad understanding of the MQSeries family of
products, and an introduction to WebSphere MQ Integrator. It also
discusses additional, related offerings from IBM. It provides background
information that can benefit everyone working with WebSphere MQ
Integrator.
Part 2, “Business process planning” on page 47
This part builds on the introduction in Part 1, providing information that
helps your business planners develop the message structure and processing
requirements that support a successful WebSphere MQ Integrator
environment. You can find implementation details for the tasks covered in
this part in WebSphere MQ Integrator Working with Messages, WebSphere MQ
Integrator Using the Control Center and WebSphere MQ Integrator ESQL
Reference.
Part 3, “Application planning” on page 77
This part explores the application aspects of your environment, further
clarifying the introduction in Part 1, and guiding you through the
considerations for application planning and development. You can find
implementation details for the tasks covered in this part in the WebSphere
MQ Integrator Programming Guide.
Part 4, “Systems planning” on page 107
This part provides details of the infrastructure you need, and how you can
configure it, to complement your applications and achieve your business
goals. It provides system administrators with hardware and software
requirements, and the infrastructure required to support your environment.
It also tells you how you can enhance your broker domain by writing
plug-ins for new parsers and message processing nodes. You can find
implementation details for the tasks covered in this part in the WebSphere
MQ Integrator Administration Guide. Implementation details for some of the
tasks can also be found in the WebSphere MQ Integrator for z/OS
Customization and Administration Guide.

© Copyright IBM Corp. 2000, 2002 xi

About this book
Appendixes provide information on migration, and on the contents of the
WebSphere MQ Integrator product package.

A glossary and a bibliography are provided at the back of the book.

For details of installing WebSphere MQ Integrator on the supported platforms, see:

v WebSphere MQ Integrator for AIX Installation Guide
v WebSphere MQ Integrator for HP-UX Installation Guide
v WebSphere MQ Integrator for Sun Solaris Installation Guide
v WebSphere MQ Integrator for Windows NT and Windows 2000 Installation Guide
v WebSphere MQ Integrator for z/OS Program Directory

Websphere MQ Integrator for z/OS also runs on OS/390® V2R8, V2R9, and V2R10.
All references to z/OS in this book apply also to these releases of OS/390, unless
otherwise stated. Customization and configuration differences between the z/OS
and OS/390 operating systems are transparent to the user.

Who should read this book

This book is for business administrators who need an understanding of WebSphere
MQ Integrator to enable them to make a purchasing decision. When the product
has been purchased, this book provides information to business and system
administrators on how to make the best use of the product within their
environment.

What you need to know to understand this book

To understand this book, you should have some familiarity with the concepts of
application integration, and a thorough understanding of your existing and
planned business tasks and objectives.

An understanding of MQSeries concepts is also useful.

Terms used in this book

All references to Windows NT® in this book apply also to Windows® 2000, unless
otherwise stated. WebSphere MQ Integrator components that are installed and
operated on Windows NT can also be installed and operated on Windows 2000.

All new terms introduced in this book are defined in “Glossary of terms and
abbreviations” on page 199. These terms are shown like this at their first use.

The book uses the following shortened names:

v MQSeries: a general term for IBM MQSeries messaging products.
v MQSeries Publish/Subscribe: the MQSeries Publish/Subscribe SupportPac™
available on the Internet for several MQSeries® server operating systems. For
more information about the MQSeries product family web site, see “MQSeries
information available on the Internet” on page 208.
v CICS®: a general term for IBM CICS products including CICS, TXSeries™, and
WebSphere.
v DB2®: a general term to encompass IBM DB2 Universal Database® Enterprise
Edition, Connect Enterprise Edition and Extended Enterprise Edition.
v UNIX®: the UNIX-based platforms, such as AIX®, HP-UX, and Solaris.

xii WebSphere® MQ Integrator: Introduction and Planning

 Summary of changes
This section describes changes in this edition of WebSphere MQ Integrator
Introduction and Planning. Changes since the previous edition of the book are
marked by vertical lines to the left of the changes.

| Changes for this edition (GC34-5599-04)

| Changes since the previous edition of the book are marked by vertical lines to the
| left of the changes.

| These include:
| v An introduction to the concept of aggregation and the nodes that support
| aggregation.
| v Minor technical and editorial improvements throughout the book.

Changes for the fourth edition (GC34-5599-03)

The major changes to this edition are:
v IBM MQSeries, already an important part of the WebSphere software platform
for e-business, is being more tightly associated with WebSphere and is to be
known as WebSphere MQ, to reflect the fundamental part that it plays in
dynamic e-business. MQSeries Integrator, now called Websphere MQ Integrator,
is the first product to change its name; others will follow with new releases.
References to WebSphere MQ products, resources, and concepts within this book
continue to refer to MQSeries to reflect existing product names.
v Addition of the new product WebSphere MQ Integrator for z/OS Version 2.1.
v Additional information to cover the following product changes:
– Oracle XA support is available on WebSphere MQ Integrator for all platforms,
except z/OS.
– Sybase XA support is available on WebSphere MQ Integrator for all platforms,
except z/OS.
– User-written input nodes and nodes written in Java are now supported.
– Tagged delimited strings provide support for industry-standard message
formats such as S.W.I.F.T. and EDI.
v Minor technical and editorial improvements throughout the book.
v Some parts of the New Era of Networks component of WebSphere MQ
Integrator have been renamed to NNSY or Nnsy; other parts retain the term
NEON. References to NEON do not refer to NEON Systems Inc.

Changes for the third edition (GC34-5599-02)

Major changes for this edition include:
v Addition of the new product MQSeries Integrator for HP-UX Version 2.0.2.
v Additional information to cover the following product changes:
– Improved national language support
– Debugger function added to the Control Center
– Windows 2000 added as an alternative platform for MQSeries Integrator for
Windows NT

© Copyright IBM Corp. 2000, 2002 xiii

Changes
– Oracle XA support available on MQSeries Integrator for Sun Solaris
– Additional New Era of Networks nodes and a new parser added to provide
access to New Era of Networks Rules and Formatter Support
– New MQSeries Everyplace and SCADA nodes added
– Windows NT Server Version 4.0, running on an Integrated IBM Eserver
xSeries™ installed in an IBM Eserver iSeries™ 400® (AS/400®), is listed as a
suitable platform for the MQSeries Integrator components that run under
Windows NT
v Minor technical and editorial improvements throughout the book.

The usability of the Control Center is also improved in this version of WebSphere
MQ Integrator. See WebSphere MQ Integrator Using the Control Center for full details.

Changes for the second edition (GC34-5599-01)

Major changes for this edition include:
v Additional information to cover the following product changes:
– New products MQSeries Integrator for AIX Version 2.0.1 and MQSeries
Integrator for Sun Solaris Version 2.0.1.
– New IBM primitive nodes (FlowOrder, Label, and RouteToLabel)
v Minor technical and editorial improvements throughout the book.

xiv WebSphere® MQ Integrator: Introduction and Planning

 Part 1. Introduction
Chapter 1. MQSeries and business integration . . 3 Input from MQSeries Everyplace . . . . . 33
Using MQSeries for business integration . . . . . 3 MQSeries Everyplace messages in WebSphere
MQSeries . . . . . . . . . . . . . . 4 MQ Integrator . . . . . . . . . . . 34
WebSphere MQ Integrator . . . . . . . . . 4 SCADA applications . . . . . . . . . . 36
MQSeries Workflow . . . . . . . . . . . 4 Dependencies. . . . . . . . . . . . . . 37
Using WebSphere MQ Integrator in your business . . 5 MQSeries dependencies . . . . . . . . . 37
Getting started with WebSphere MQ Integrator . . 5 Database dependencies . . . . . . . . . 38
WebSphere MQ Integrator Version 2.1 and previous Release to release migration . . . . . . . . . 40
IBM offerings . . . . . . . . . . . . . . 7
Chapter 3. WebSphere MQ Integrator: a business
Chapter 2. WebSphere MQ Integrator overview scenario . . . . . . . . . . . . . . . 41
and concepts . . . . . . . . . . . . . . 9 The retail scenario . . . . . . . . . . . . 42
Overview of WebSphere MQ Integrator . . . . . 9 Business data . . . . . . . . . . . . . 43
Brokers . . . . . . . . . . . . . . . . 10 Business needs . . . . . . . . . . . . 44
Resources associated with a broker . . . . . 10 Business solution using WebSphere MQ
Adding a broker to the broker domain . . . . 10 Integrator Version 2 . . . . . . . . . . 44
Connecting brokers for publish/subscribe . . . 11 Implementing the business solution . . . . . 46
System management interfaces . . . . . . . 12
The Configuration Manager . . . . . . . . . 13
Resources associated with the Configuration
Manager . . . . . . . . . . . . . . 14
The Control Center . . . . . . . . . . . . 15
Updates, assignment, and deployment . . . . 16
Exporting and importing resource definitions . . 17
Help and online Tour . . . . . . . . . . 17
Message flows . . . . . . . . . . . . . 18
Creating message flows . . . . . . . . . 18
Transaction support . . . . . . . . . . 19
Message flow input and output. . . . . . . 19
Publish/subscribe services . . . . . . . . 19
Associating message flows with brokers . . . . 20
Simple message flow examples . . . . . . . 21
Messages and message sets . . . . . . . . . 22
Messages predefined in the Control Center . . . . 23
Importing legacy message definitions. . . . . 23
Importing messages predefined by the Control
Center . . . . . . . . . . . . . . . 23
Messages predefined by the New Era of
Networks Formatter . . . . . . . . . . 23
Self-defining messages. . . . . . . . . . 24
Support for JMS messages . . . . . . . . 24
Multipart messages . . . . . . . . . . . 24
Parsing messages . . . . . . . . . . . 25
Associating message sets with brokers . . . . 25
Applications and clients . . . . . . . . . . 26
Point-to-point applications . . . . . . . . 26
| Aggregation of messages . . . . . . . . . 26
Publish/subscribe applications . . . . . . . 27
Client connections to brokers and message flows 28
The User Name Server . . . . . . . . . . 29
Resources associated with a User Name Server 30
Access control Lists. . . . . . . . . . . 30
MQSeries Everyplace and SCADA. . . . . . . 31
MQSeries Everyplace overview . . . . . . . 31
Communicating with MQSeries Everyplace from
WebSphere MQ Integrator . . . . . . . . 33

© Copyright IBM Corp. 2000, 2002 1

2 WebSphere® MQ Integrator: Introduction and Planning
Chapter 1. MQSeries and business integration
The last few years have seen a growing interest and investment in messaging
middleware. IBM’s MQSeries is an industry leader in this area, and provides a
messaging infrastructure to many diverse businesses and applications.

IBM has developed a family of products, based around the messaging transport
layer, that provides not only the fundamental requirements of secure, reliable
information exchange, but also incorporates services and business process support
to help you to make the best use of your investment in systems and applications.
The richness and flexibility of this support enables you to respond to new
opportunities that arise when your business grows and diversifies.

Using MQSeries for business integration

MQSeries is the focal point of the IBM Business Integration strategy, which
addresses integration of applications, data, and processes from both business and
IT perspectives.

Business integration is the coordination and cooperation of all your business

processes and applications. It involves bringing together the data and process
intelligence in your enterprise, and harnessing these so that your applications and
your users can achieve their business needs.

Business integration means that:

v You can connect customers, suppliers, partners, and service providers, with
continuing security and control, to enable newly built and re-engineered
applications for more effective business processes (for example, Supply Chain
Management).
v You can make mergers and acquisitions a success by integrating dissimilar IT
infrastructures from more than one company so that they can work together as a
single entity.
v You can react more quickly to market trends and opportunities because your IT
systems are flexible and dependable, and no longer constraining.
v You can overcome the barriers of diverse computer systems, geographic
boundaries, time differences, language and format differences, and different
methods of working.

You can use the MQSeries family products to support your business integration
needs:
v MQSeries messaging provides a secure and far-reaching communications
infrastructure.
v WebSphere MQ Integrator and MQSeries Workflow provide a range of services
that allow you to apply intelligence to your business data as it travels through
your network.

© Copyright IBM Corp. 2000, 2002 3

Business integration
MQSeries
MQSeries provides assured, once-only delivery of messages between your IT
systems. It connects more than thirty industry platforms including those from IBM,
Microsoft®, and Sun Microsystems, Inc., using a variety of communications
protocols.

MQSeries provides rich support for applications:

v The Message Queue Interface (MQI) and Application Messaging Interface (AMI) are
supported in several programming languages.
v The point-to-point (including request/reply and client/server) and publish/subscribe
are supported.
v The complexities of communications programming are handled by the
messaging services and are therefore removed from the application logic.
v The applications can access other systems and interfaces through adapters and
gateways to products such as Lotus® Domino™, Microsoft Exchange/Outlook,
SAP/R3, and IBM’s CICS and IMS/ESA® products.

WebSphere MQ Integrator
WebSphere MQ Integrator works with MQSeries messaging, extending its basic
connectivity and transport capabilities to provide a powerful message broker
solution driven by business rules. Messages are formed, routed, and transformed
according to the rules defined by an easy-to-use graphical user interface (GUI).

Diverse applications can exchange information in dissimilar forms, with brokers

handling the processing required for the information to arrive in the right place in
the correct format, according to the rules that you have defined. The applications
do not need to know anything except their own conventions and requirements.

Applications also have much greater flexibility in selecting which messages they
want to receive, because they can specify a topic filter, or a content-based filter, or
both, to control the messages that are made available to them.

WebSphere MQ Integrator provides a framework that supports supplied, basic,

functions along with plug-in enhancements, to enable rapid construction and
modification of business processing rules that are applied to messages in the
system.

MQSeries Workflow
MQSeries Workflow works with MQSeries messaging to add a further dimension
to your business integration by aligning and integrating an organization’s staff
resources, processes, and capabilities with its business strategies. It enables
organizations to accelerate its process flow, optimize costs, eliminate errors and
improve workgroup productivity.

MQSeries Workflow is designed to enable the integration of all participants in the

business process, including those external to your organization. It ensures that the
right information gets to the right person at the right time.

MQSeries Workflow can be used in combination with WebSphere MQ Integrator,

providing a high level of flexibility to allow business and message processing to be
as simple or as complicated as your business demands.

4 WebSphere® MQ Integrator: Introduction and Planning

 Using WebSphere MQ Integrator

Using WebSphere MQ Integrator in your business

WebSphere MQ Integrator addresses the needs of business and application
integration by managing the flow of information. It provides services, based on
message brokers, to allow you to:
v Route a message to several destinations, using rules that act on the contents of
one or more of the fields in the message or message header.
v Transform a message, so that applications using different formats can exchange
messages in their own formats.
v Store a message, or part of a message, in a database.
v Retrieve a message, or part of a message, from a database.
v Modify the contents of a message; for example, by adding data extracted from a
database.
v Publish a message to make it available to other applications. Other applications
can choose to receive publications that relate to specific topics, or that have
specific content, or both.
v Create structured topic names, topic-based access control functions,
content-based subscriptions, and subscription points.
v Exploit a plug-in interface to develop message processing node types that can be
incorporated into the broker framework to complement or replace the supplied
nodes, or to incorporate node types developed by Independent Software
Vendors (ISVs).
v Enable instrumentation by products such as those developed by Tivoli®, using
system management hooks. Tivoli support is not available on the HP-UX or z/OS
platforms.

The benefits of WebSphere MQ Integrator can be realized both within and outside
your enterprise:
v Your processes and applications can be integrated by providing message and
data transformations in a single place, the broker. This helps reduce the cost of
application upgrades and modifications.
v You can extend your systems to reach your suppliers and customers, by meeting
their interface requirements within your brokers. This can help you improve the
quality of your interactions, and allow you to respond more quickly to changing
or additional requirements.

For a practical illustration of the use of WebSphere MQ Integrator in business, see

Chapter 3, “WebSphere MQ Integrator: a business scenario” on page 41.

Getting started with WebSphere MQ Integrator

The information in this book helps you to:
1. Assess how WebSphere MQ Integrator meets your business needs, and make a
purchasing decision.
Chapter 2, “WebSphere MQ Integrator overview and concepts” on page 9
introduces the concepts and components of WebSphere MQ Integrator, and
explains their relationships.
Chapter 3, “WebSphere MQ Integrator: a business scenario” on page 41
describes a scenario that explains how WebSphere MQ Integrator helps you to
solve business integration problems.
2. Plan the business processes that you will run in your brokers to service your
applications.

Chapter 1. MQSeries and business integration 5

Using WebSphere MQ Integrator
Part 2, “Business process planning” on page 47 discusses your business
processes and entities. It describes message flows, messages, and message sets, and
the rules that define how these messages are processed.
When you understand the concepts, and have completed the planning tasks to
define your environment, refer to WebSphere MQ Integrator Using the Control
Center for details of how to implement these plans and carry out your business
administration tasks.
3. Plan the applications that will interact with your business processes.
Part 3, “Application planning” on page 77 describes how you can integrate
existing applications, and create new ones, to complete the processing of
messages flowing through your network.
Detailed guidance for writing and deploying these applications is provided in
the WebSphere MQ Integrator Programming Guide.
4. Plan your system requirements and configuration.
Part 4, “Systems planning” on page 107 summarizes the infrastructure
requirements of your network, and discusses how you can configure the
WebSphere MQ Integrator components to provide the support your business
processing requires.
You can find full details of the system requirements for WebSphere MQ
Integrator in the MQSeries MQ Integrator Installation Guide for your operating
system. These books also contain instructions for installing WebSphere MQ
Integrator on your chosen operating system, and guides you through some
simple tasks that help you verify that installation.
You can find details for system administration tasks in the WebSphere MQ
Integrator Administration Guide, and in the WebSphere MQ Integrator for z/OS
Customization and Administration Guide.
5. Plan your migration from, and integration with, earlier integrator and
publish/subscribe products.
Appendix A, “Planning for migration and integration” on page 167 provides the
information you require if you use MQSeries Integrator Version 1, MQSeries
Integrator Version 2,Version 2.0.2, or have downloaded and deployed MQSeries
Publish/Subscribe. It helps you plan for deployment of WebSphere MQ
Integrator Version 2.1 brokers in your current environment.
For details of how you can upgrade your current environment to WebSphere
MQ Integrator Version 2.1, refer to the WebSphere MQ Integrator Administration
Guide and the WebSphere MQ Integrator for z/OS Customization and Administration
Guide.

6 WebSphere® MQ Integrator: Introduction and Planning

 Comparison with previous offerings

WebSphere MQ Integrator Version 2.1 and previous IBM offerings

The following offerings from IBM are enhanced and extended by WebSphere MQ
Integrator Version 2.1:
v MQSeries Integrator Version 1
v MQSeries Integrator Version 2
v MQSeries Publish/Subscribe

WebSphere MQ Integrator Version 2.1 extends the capabilities of MQSeries

Integrator Version 1, MQSeries Integrator Versions 2, 2.0.1 and 2.0.2, and MQSeries
Publish/Subscribe by supporting:
v Brokers running on the z/OS operating system.
v Enhanced transactional integrity, via XA technology, using DB2, Oracle, and
Sybase on all distributed platforms. IBM’s Resource Recovery Services (RRS)
provide an equivalent level of support with DB2 on z/OS.
v Enhanced message definition and processing.

You can upgrade your applications, messages, and brokers to take advantage of the
enhancements in WebSphere MQ Integrator Version 2.1. You can also continue to
use your existing applications and messages unchanged, by tailoring your
WebSphere MQ Integrator Version 2.1 system to provide compatible support.

WebSphere MQ Integrator Version 2.1 brokers can interact with MQSeries

Publish/Subscribe brokers in a common publish/subscribe environment, to
provide coexistence within a single mixed broker network.

If you already have MQSeries Integrator Version 1, MQSeries Integrator Version 2,

or MQSeries Publish/Subscribe, see Appendix A, “Planning for migration and
integration” on page 167 of the WebSphere MQ Integrator Administration Guide, and
the WebSphere MQ Integrator for z/OS Customization and Administration Guide for
details of planning for, and implementing, your migration.

Chapter 1. MQSeries and business integration 7

Comparison with previous offerings

8 WebSphere® MQ Integrator: Introduction and Planning

Chapter 2. WebSphere MQ Integrator overview and concepts
WebSphere MQ Integrator Version 2.1 is a message broker solution. It extends the
basic messaging facilities supplied by MQSeries by enabling you to route messages
and manipulate their content, according to a set of rules that you define using a
graphical interface.

This support is provided by a number of components and services that work

together to manage the resources required by your applications and business
processes. This chapter introduces these components, their relationships and the
services they provide.

Overview of WebSphere MQ Integrator

Your business processes are hosted and controlled by a broker. Typically, you
would group several brokers together to form a broker domain. The Configuration
Manager manages all the components and resources in the broker domain. You
interact with the Configuration Manager through a graphical user interface called
the Control Center. The Configuration Manager and Control Center must run on
Windows NT. The Configuration Manager and broker use databases to store and
share information about the broker domain.

The business processing rules define the processing performed on your messages
by the broker. Each action is performed by a message processing node and the
actions are grouped together to form a message flow. Because each message flow
needs to understand the structure of the messages it processes, the structure of
messages is either defined by message templates, or carried with the message
(XML message).

Applications communicate with the broker to use these services; they can connect
to any queue manager in the MQSeries network to do this. WebSphere MQ
Integrator supports both point-to-point and Publish/Subscribe application
communication models. You can also use MQSeries Everyplace and SCADA
applications with WebSphere MQ Integrator. The User Name Server provides
information about users and groups of users if you want to use topic-based
security in the Publish/Subscribe environment.

The following topics are introduced:

v “Brokers” on page 10
v “The Configuration Manager” on page 13
v “The Control Center” on page 15
v “Message flows” on page 18
v “Messages and message sets” on page 22
v “Applications and clients” on page 26
v “The User Name Server” on page 29
v “MQSeries Everyplace and SCADA” on page 31
v “Dependencies” on page 37

© Copyright IBM Corp. 2000, 2002 9

Brokers

Brokers
A broker is a named resource that hosts and controls your business processes,
which you define as message flows. Your applications communicate with the broker
to take advantage of the services provided by the message flows. Applications
send new messages to the message flow, and receive processed messages from the
message flow, using MQSeries queues and connections.

You can install, create, and start any number of brokers within a broker domain.
You can create more than one broker on any one physical system if you choose,
but you must specify a unique queue manager for each broker. However, a single
broker can share a queue manager with the Configuration Manager.

Resources associated with a broker

When you create a broker, the following resources are also created:
v A set of tables in a database to hold the broker’s data. This database can be
created using a number of database products, depending on the operating
system on which you install WebSphere MQ Integrator:
– IBM DB2 Universal Database
– Microsoft SQL Server (Windows NT only)
– Oracle
– Sybase

Note: For a broker on WebSphere MQ Integrator for z/OS, the database can be
on DB2 only.

The broker uses an ODBC connection to its database. These broker tables are
also referred to as the broker’s local persistent store. For more information about
supported databases, see Table 4 on page 121.
v A set of fixed-name queues, defined to the queue manager that hosts this broker.
You must identify this queue manager when you create the broker, and it must
exist on the same physical system as the broker. It is created when the broker is
created, unless it already exists.

Adding a broker to the broker domain

When you create a broker on the system on which you have installed the broker
component, the information about the broker’s configuration is not automatically
recorded in the configuration repository (managed by the Configuration Manager).
You must use the Control Center (the Topology view) to create a reference to this
broker with the same name that you specified when you created that broker (see
“The Control Center” on page 15 for more information about the Control Center).
Creating a reference:
v Stores the broker information in the configuration repository.
v Defines a default execution group on this broker. You can define further execution
groups if you want. Each message flow providing a service on this broker must
be deployed to an execution group before that service can be used by
applications. Execution groups are described in “What is an execution group?”
on page 58.

10 WebSphere® MQ Integrator: Introduction and Planning

 Brokers

Broker

Execution group
ODBC
connection
Message flow

Message dictionary Broker database

Queue manager

Figure 1. The broker

When you have created the broker reference, you must deploy the changes to your
broker domain for them to take effect. The deploy action:
v Initiates communications between the Configuration Manager and the broker.
v Initializes the broker so that it is ready to execute message flows. The broker
receives configuration information from the Configuration Manager, and stores it
in its database.

When you have created the broker reference, you can assign message flows (see
“Message flows” on page 18) to the broker’s execution groups, and any message
sets (see “Messages and message sets” on page 22) required by those message
flows to the broker. These changes must also be deployed before they can be
activated. You can deploy these resources individually, or together, but until all
related resources (for example, a broker, a message flow and the message set it
uses) are deployed, you cannot use the message flow on that broker.

Connecting brokers for publish/subscribe

If you plan to create message flows that provide a publish/subscribe service, you
can consider connecting a number of your brokers in a collective using the Control
Center. A collective contains a number of brokers that are all physically
interconnected; that is, each broker in the collective can be connected directly
through the network to every other broker in the collective. All the broker queue
managers must be connected by pairs of MQSeries channels.

A collective optimizes the publish/subscribe messages in your broker domain by

reducing the number of clients per broker, without increasing the hops taken by
any message by more than one. In this way, collectives are more efficient than a
tree hierarchy.

You can also connect collectives to other collectives, and to other individual
brokers. If you are connecting one collective to another collective, or to a stand
alone broker, only one broker in each collective must provide the connection.

Messages published to any one broker are propagated to all connected brokers
(whether or not they are in a collective) to which an application has subscribed to
the message’s topic or content.

Figure 2 on page 12 illustrates a collective of three brokers.

Chapter 2. WebSphere MQ Integrator overview and concepts 11

Brokers

Broker A Broker B

Queue manager A Queue manager B

Queue manager C

Broker C

Figure 2. A collective

System management interfaces

The brokers provide a service for independent system management agents. This
enables a central management facility to access information about any network that
includes an WebSphere MQ Integrator broker domain.

This support ensures that existing system management agents, such as those
developed by Tivoli, can be extended to include WebSphere MQ Integrator
resources. You can find information about using the Tivoli interface with
WebSphere MQ Integrator on the product CD. Tivoli support is not available on the
HP-UX or z/OS platforms.

WebSphere MQ Integrator brokers publish event messages, using fixed topics, in

response to configuration changes, state changes, and user actions such as
subscription registrations.

A system management agent can subscribe to these topics, or to a subset of these

topics, to receive the detailed information about activity and state changes in the
WebSphere MQ Integrator broker domain. The event messages have a fixed
structure, defined in XML (Extensible Markup Language).

For further details of this support, see the WebSphere MQ Integrator Administration
Guide.

12 WebSphere® MQ Integrator: Introduction and Planning

 Configuration Manager

The Configuration Manager

The Configuration Manager is the central component of your WebSphere MQ
Integrator environment. You must install, create, and start a single Configuration
Manager to manage your broker domain.

The Configuration Manager must be installed and configured in the Windows NT

environment. It is not supported on any other operating system. After it is started,
the Configuration Manager runs in the background.

The components and resources managed by the Configuration Manager constitute

the broker domain. The Configuration Manager serves three main functions:
v It maintains configuration details in the configuration repository. This is a set of
database tables that provide a central record of the broker domain components.
v It manages the initialization and deployment of brokers and message processing
operations in response to actions initiated through the Control Center. It
communicates with other components in the broker domain using MQSeries
transport services.
v It checks the authority of defined user IDs to initiate those actions.

JDBC
connection Configuration
repository
Configuration (shared/deployed
Manager data)
ODBC
connection

Message
Queue repository
manager

Configuration Manager system (Windows NT)

TCP/IP
connection

MQSeries Client for Java

Local
configuration Control
data Center

Figure 3. The Configuration Manager

Chapter 2. WebSphere MQ Integrator overview and concepts 13

Configuration Manager
You can view, create, modify, and delete the contents of the configuration
repository using the Control Center. The Control Center must also be installed on
Windows NT. It is not supported on any other operating system. A fuller
description of the Control Center is given in “The Control Center” on page 15.

The Configuration Manager provides a service to the other components in the

broker domain, providing them with configuration updates in response to actions
that you take from the Control Center. The Configuration Manager validates that
the user requesting each action from the Control Center is authorized to perform
that action.

Resources associated with the Configuration Manager

When you create the Configuration Manager, the following resources are also
created:
v A set of tables in a database, known as the configuration repository. This
database must be created using IBM DB2 Universal Database for Windows NT.
The Configuration Manager uses a JDBC™ (Java™ Database Connectivity)
connection to this database.
v A set of tables in a database, known as the message repository. This database must
be created using IBM DB2 Universal Database for Windows NT. The
Configuration Manager uses an ODBC (Open Database Connectivity) connection to
this database.
v A set of fixed-name queues, defined to the queue manager that hosts the
Configuration Manager. You must identify this queue manager when you create
the Configuration Manager, and it must be on the same physical system as the
Configuration Manager. It is created when the Configuration Manager is created,
unless it already exists.
v A server connection, defined to the queue manager that hosts the Configuration
Manager. This connection is used by all instances of the Control Center.

14 WebSphere® MQ Integrator: Introduction and Planning

 Control Center

The Control Center

The Control Center interacts with the Configuration Manager to allow you to
configure and control your broker domain. The Control Center and Configuration
Manager exchange messages (using MQSeries) to provide the information you
request, and to make updates to your broker domain configuration.

Figure 3 on page 13 illustrates the Control Center and its connection to the
Configuration Manager.

You can install and invoke any number of Control Center instances in the
Windows NT environment (the Control Center is not supported by any other
operating system). The Control Center depends on the MQSeries Client for Java for
its connection with the Configuration Manager. The Control Center can therefore
be installed on the same physical system as the Configuration Manager, or on any
other Windows NT system that can connect to the Configuration Manager.

The Control Center uses a client/server connection to connect to the Configuration

Manager’s queue manager (whether it is on the same or another physical system),
which it creates dynamically using information you provide when you first invoke
the program. The Control Center can use MQSeries channel security exits to
protect this connection. See the WebSphere MQ Integrator Administration Guide for
details of the Control Center security exit. This connection must be a TCP/IP
connection.

The Control Center is structured as a number of views on the configuration and

message repositories. Users can choose which set of the views are currently
included by selecting one of five roles, one of which, “All roles”, shows every
view. Within the boundaries of what you are authorized to do, the Control Center
allows you to retrieve information selectively from:
The message repository
This contains all the message templates that you (or any other user) have
created using the Control Center, those you have created by importing
legacy message definitions, and those you have imported using the
mqsiimpexpmsgset command.
The configuration repository
This contains configuration information pertaining to all other resources
within your broker domain: brokers, execution groups, collectives, message
processing nodes, message flows, topics, and subscriptions.

You can use the Control Center to:

v Develop, modify, assign, debug, and deploy message flows.
v Develop, modify, assign, and deploy message sets.
v Define your broker domain topology and create collectives.
v Control topic security of messages by topic.
v View status information.
v Export and import resource definitions (excluding message sets).

Chapter 2. WebSphere MQ Integrator overview and concepts 15

Control Center
Updates, assignment, and deployment
When you work with the configuration and message repository data using the
Control Center, you can choose to view the resources that are defined, or you can
create, modify, and delete those resources. You must be authorized to perform
these tasks.

If you want to make any changes, you must check out (request a locked copy of)
the resource you want to change. This allows updates to the central data to be
coordinated by the Configuration Manager. The Control Center shows you which
resources you currently have checked out. After you have locked a resource, you
have exclusive control over it until you return it to the configuration repository
using check in, or until you relinquish control by unlocking it.

When you have made changes, or have created new resources, you can save a local
copy if you want. You can also check in the resources to save your changes in the
message or configuration repository, if you are authorized to do so. This makes
your changes visible to all other users of the Control Center.

Checking-in an object overwrites the previous version. If you need the ability to
recover earlier versions of objects, you should consider downloading MQSeries
SupportPac IC04 ″MQSeries Integrator V2 - Change Management and naming
standards examples″. This SupportPac provides suggested procedures for version
management and change control of WebSphere MQ Integrator objects. For more
information about the MQSeries product family web site, see “MQSeries
information available on the Internet” on page 208.

When you have decided which message flows and message sets you want to use
in each broker, you can assign them from the Assignment view. Message flows are
assigned to an execution group within a broker. Message sets are assigned to the
broker itself.

Following your assignment of these resources, you must also deploy these changes
through the broker domain. Deployment results in the Configuration Manager
sending messages and information about the changes you have made to the
brokers. You can monitor the success and progress of this step using the Operations
view and the Log view.

For more detailed information about check in and check out, assignment and
deployment, and all the other tasks that the Control Center supports, refer to
WebSphere MQ Integrator Using the Control Center. This book also provides further
description of the user roles and the Control Center’s interactions with the
Configuration Manager.

16 WebSphere® MQ Integrator: Introduction and Planning

 Control Center
Exporting and importing resource definitions
The Control Center allows you to export definitions you have created for your
broker domain topology, your topics, and your message flows. When you export
these definitions, an XML file is generated containing the information retrieved
from the configuration repository. You can export individual message flows, and
choose whether the resources you export are saved in separate XML files or one
big one. You can use definitions exported in this way to populate another
configuration repository in another broker domain, by using the import function
within the Control Center, specifying the XML file.

See the WebSphere MQ Integrator Using the Control Center book and the online help
for further information about these options.

You cannot export message set definitions from the Control Center, or import them
into the Control Center. You must use an WebSphere MQ Integrator command,
mqsiimpexpmsgset, to export and import message set definitions. See Chapter 5,
“Messages” on page 69 for further details about message sets, and refer to the
WebSphere MQ Integrator Administration Guide for details of the import and export
command.

Help and online Tour

The Control Center comes with comprehensive online help: it provides context
sensitive information for specific assistance, and provides general help, including
the WebSphere MQ Integrator Tour. The Tour gives you an online overview of
WebSphere MQ Integrator, its components, and the Control Center interface itself.

The Tour is based on a scenario in which WebSphere MQ Integrator is used to

integrate the processes of an international company. It introduces WebSphere MQ
Integrator in two ways:
v Providing introductory information that you can read, with links to further
details in the WebSphere MQ Integrator books and online help.
v Providing animated sequences of actions in the Control Center. For example, you
can see how a message flow and message set are created using the Control
Center.

Chapter 2. WebSphere MQ Integrator overview and concepts 17

Message flows

Message flows
You define the processing for your messages as a set of actions, or rules, that are
executed after the receipt of the message by the broker, and before the delivery of
the message to the target applications. Each action, or subset of actions, is
performed by a message processing node. The message processing nodes are grouped
together in a sequence to form a message flow. A particular message flow provides
a particular service that is implemented by the rules that the message processing
nodes contain.

Creating message flows

You can create message flows by selecting and connecting message processing
nodes, using the Control Center. WebSphere MQ Integrator supplies a number of
predefined message processing node types, known as IBM primitives. These
provide basic functions including input, output, filter (on message data content),
and compute (manipulate message content: for example, add data from a
database). You can connect one node to another (the output terminal of the first
node and the input terminal of the second node) to form a sequence.

The primitive nodes are described in Chapter 4, “Message flows” on page 49. You
can include these primitive nodes in your message flows to define the processing
that you need for each message. If you need additional or alternative function that
is not provided by the primitives, you can create new node types, using a system
programming interface supplied by WebSphere MQ Integrator. This interface is
described in the WebSphere MQ Integrator Programming Guide.

Message flows can range from very simple, performing just one action on a
message, to complex, providing a number of actions on the message to transform
its format and content.

Figure 4 illustrates the components of a message flow.

Output Input
terminal terminal
Input Node Output
node Connection node

Figure 4. Message flow components

Within a message flow, you can define the action to be taken according to the
message template, the message topic, or the data within the message itself.
Alternatively, the identity of the message originator, or the destination to which the
message is sent, might be important. Any combination of one or more of these
attributes, or others, can define the rules by which the messages are processed, and
determine the sequence of nodes you put together to form the message flow.

A message flow can process one message in several ways to deliver a number of
output messages, perhaps with different format and content, to a number of target

18 WebSphere® MQ Integrator: Introduction and Planning

 Message flows
applications. You can embed one message flow within another, enabling you to
reuse many times a particular sequence of nodes that provides a commonly
required function.

Transaction support
You can request that the actions taken within a message flow are assured by the
implementation of XA technology. That is, all actions succeed or are rolled back to
preserve the integrity of your message processing. If the actions taken by your
message flow include updating a database, you must use a DB2, Oracle or Sybase
database to take advantage of this coordination. For more information about
transaction coordination, see “Transaction support” on page 83.

If you do not request coordination, or you are using Microsoft’s SQL Server on
WebSphere MQ Integrator for Windows NT for your external database, WebSphere
MQ Integrator commits or rolls back each action taken by the message flow but
cannot assure that success or failure is reflected by all actions.

Message flow input and output

The message flows you create receive messages at input nodes. Every message flow
must have at least one input node.

The input nodes can be one of the supplied primitives: MQInput, MQeInput, or
SCADAInput. MQInput nodes represent MQSeries queues, which can be unique
to this node, or used to supply messages to multiple nodes. MQeInput nodes
represent MQSeries Everyplace queues. SCADAInput nodes represent Supervisory,
Control, and Data Acquisition input ports (SCADA).

Note: MQeInput and SCADAInput nodes are not available on z/OS.

The sequence of nodes in a message flow usually end with one or more output
nodes that put one or more messages to one or more queues that are read by
applications that want to receive messages processed by that message flow.
SCADA message flows end with a Publication node, which knows how to handle
SCADA messages.

Several primitive output nodes are supplied, such as MQOutput, MQeOutput,

MQReply (which uses the reply-to queue), and Publication. (In exceptional
circumstances you can use the SCADAOutput node as a stand-alone node. In
normal circumstances you can use it as a sub-node within the Publication node.)
These nodes also represent unique or shared MQSeries or MQSeries Everyplace
queues. The queues for published messages are specified by the applications that
have registered an interest in the information available, although SCADA output
messages go directly to the specified SCADA port without being put to an output
queue.

Other message flows might simply store the message in a database for later
processing, and not use an output node at all.

Publish/subscribe services
Message flows that incorporate a publication node provide a particular service,
known as a publish/subscribe service. Messages are supplied to the message flow
by publishers (applications that publish messages), and retrieved from the message
flow by subscribers (applications that have registered a subscription with a broker:
the subscription defines their interest in published messages).

Chapter 2. WebSphere MQ Integrator overview and concepts 19

Message flows
A single message flow can include more than one publication node. Any number
of nodes can be included between the input nodes and the publication nodes, but
you cannot define any node to follow the publication node.

Each publication node has a subscription point. A subscription point differentiates

the publication node from other publication nodes on the same message flow, and
therefore represents a specific path through the message flow. For example, a
message including a share price might be needed in both dollars and sterling. The
message is processed, and two messages generated, one with the dollar price, the
other in sterling. The subscribers register specifying the identification of the
subscription point of the publication node that provides the currency they require.

You can include an unnamed publication node (one that does not have a specific
subscription point) in your message flow: this is known as the default subscription
point.

You can find out more details about publish/subscribe applications in

“Applications and clients” on page 26.

Associating message flows with brokers

When the broker has been defined to the broker domain topology, you can assign a
message flow to one of the broker’s execution groups. The same message flow can
be assigned to multiple brokers. Each message flow executes in an execution
group: each execution group is isolated from all others to increase data integrity
within the broker.

From the Assignment view of the Control Center you can drag and drop the
message flows you have created to the execution group in which they are to
execute. Each execution group can host multiple message flows.

20 WebSphere® MQ Integrator: Introduction and Planning

 Message flows
Simple message flow examples
Here are a few simple message flows that use the primitives nodes.
1. MQInput->Compute->MQOutput. The Compute node transforms a message
from one format to another, so that sending and receiving applications can
communicate with each other in their own formats.

MQInput Compute MQOutput

Figure 5. A simple Compute node message flow: MQInput -> Compute -> MQOutput

2. MQInput->Filter->MQOutputA or MQOutputB. A message is routed to

application A, or application B, depending on the contents of the message.

MQOutput A

MQInput Filter

MQOutput B

Figure 6. A simple Filter node message flow: MQInput -> Filter -> MQOutputA or MQOutput B

3. MQInput->Database->MQOutput. The Database node stores a copy of a

message in the database, or updates the database with information from the
message.

MQInput Database MQOutput

Figure 7. A simple Database node message flow: MQInput -> Database -> MQOutput

4. MQInput->Publication. This publish/subscribe service sends publications to

registered applications. Applications register with the publish/subscribe service,
and are sent the relevant publications directly by the Publication node.

MQInput Publication

Figure 8. A simple Publication node message flow: MQInput -> Publication

In each example, you could use MQeInput or SCADAInput nodes instead of the
MQInput nodes, and MQeOutput nodes instead of the MQOutput nodes. (The
Publication node knows how to handle SCADA messages.) A message flow could
start with an MQInput node, and end with an MQeOutput node or the SCADA

Chapter 2. WebSphere MQ Integrator overview and concepts 21

Message flows
functionality of a Publication node, but in that case you must have an MQeInput
node or a SCADAInput node, as appropriate, in a message flow in the same
execution group.

Note: MQeInput and SCADAInput nodes are not available on z/OS.

For more information on creating message flows like these, and others, and for
details on the message processing node primitives and how to use them, see
Chapter 4, “Message flows” on page 49.

If you want to know more about creating your own message processing nodes, see
Chapter 11, “Enhancing your broker domain” on page 163.

Messages and message sets

Each message flowing through your system has a specific structure, which is
important and meaningful to the applications that send or receive that message.
WebSphere MQ Integrator refers to the structure as the message template. Message
template information comprises the message domain, message set, message type, and
wire format of the message. Together these values identify the structure of the data
the message contains. Every message flow that processes a message conforming to
this template must understand the template to enable the message bit stream to be
interpreted.

You can use:

v Messages with a message template predefined to the message repository using
the Control Center. These are referred to as predefined messages.
v Messages with a message template predefined to the New Era of Networks
database using the New Era of Networks Formatter interface.
v Messages with a self-defining template. These are called self-defining messages.

22 WebSphere® MQ Integrator: Introduction and Planning

 Messages

Messages predefined in the Control Center

When you create a message using the Control Center, you define the fields
(Elements) in the message, along with any special field types you might need, and
any specific values (Value Constraints) the fields might be restricted to.

You can also create messages using the SmartGuide. This provides an easy to use
interface to define simple messages, and allows you to define and arrange the
fields within the message structure.

Every message predefined in the Control Center must be a member of a message

set. You can group related messages together in a message set: for example, request
and response messages for a bank account query can be defined in a single
message set. All message and message set definitions are maintained in the
message repository.

When you assign and deploy a message set to a broker, the definition of that
message set is sent by the Configuration Manager to the broker in the form of a
message dictionary (illustrated in Figure 1 on page 11). The broker can manage
multiple message sets simultaneously.

Importing legacy message definitions

You can use the facilities of the Control Center to import message structures
previously defined as C and COBOL data structures. The Control Center creates a
message set for you in a way that is consistent with all other message definitions
in the message repository.

The import facility allows continued use of messages defined in C and COBOL
data structures by your existing applications that use those structures. It also
enhances the existing support by giving you the flexibility to examine and modify
the data in these messages using message processing nodes. You can therefore
route and transform these messages using WebSphere MQ Integrator Version 2.1
facilities without having to redefine them.

You can find further information on how this is supported in Chapter 5,

“Messages” on page 69.

Importing messages predefined by the Control Center

If you create message templates in the message repository on one system, you can
export those definitions in XML format to a file, and import them into the message
repository on another system. The command mqsiimpexpmsgset supports both
export and import.

Messages predefined by the New Era of Networks Formatter

You can use messages that you have defined using the New Era of Networks
Formatter with WebSphere MQ Integrator Version 2.1 message flows. You can
continue to use the New Era of Networks Formatter to create new definitions of
message formats. These definitions are not held in the message repository, but in a
separate database set up specifically for this purpose and controlled by the New
Era of Networks Rules and Formatter Support for WebSphere MQ Integrator.

When you want to use these message formats in the broker, you do not assign and
deploy them through the Control Center, but must ensure that the broker has
access to the database in which the definitions exist.

Chapter 2. WebSphere MQ Integrator overview and concepts 23

Messages
Three primitive message processing nodes provide the functionality of New Era of
Networks Rules and Formatter Support.

These message processing nodes provide processing equivalent to MQSeries

Integrator Version 1.1, plus extra functionality. Note that the New Era of Networks
nodes cannot be used unless the New Era of Networks Rules and Formatter Support
component is installed.
NeonFormatter node
This transforms a message from one predefined New Era of Networks
format to another.
NEONMap node
This provides mapping function in addition to transforms provided by
New Era of Networks Formatter.
NEONTransform node
This provides richer transformation operations in addition to mapping to
extend New Era of Networks Formatter processing.
NeonRules node
This interprets message processing rules to write a message to the next
node.
NEONRulesEvaluation node
This extends the function of the NeonRules node by providing an
additional routing option.

Self-defining messages
You can create and route messages that are self-defining. These use the XML
standard to provide structure to the message, so that it can be interpreted and
modified.

Self-defining messages can also be predefined in the message repository through

the Control Center. This permits the use of the logical message template by nodes
within a message flow. However, these message set definitions do not need to be
deployed to the brokers that support those message flows.

Support for JMS messages

MQSeries Integrator supports jms_map and jms_stream messages; it does not
support any other category of JMS messages. For further information about using
JMS messages with MQSeries Integrator, see the MQSeries Using Java book.

Multipart messages
Some industry-standard message formats (for example, EDI (EDIFACT and X12)
and S.W.I.F.T.) consist of a number of messages that are logically separate but
which are combined into one large bit stream. These are known as multipart
messages.

Each multipart message is composed of several other messages, each of which is

logically complete and individually defined. Each logical message can be
interpreted and processed separately. The PROPAGATE statement in ESQL allows
a multipart message to be broken down into its parts, and each part to be
propagated through the flow as a separate message. This is much simpler and
more efficient than having message flows containing loops.

24 WebSphere® MQ Integrator: Introduction and Planning

 Messages
Multipart messages can be used as a type of transaction; either all the parts of the
message are delivered or none of them are.

A WebSphere MQ Integrator broker handles multipart messages so that the

individual messages can be processed separately for improved performance. The
individual messages can carry on through to completion or can be combined again
into an output multipart message. S.W.I.F.T. and EDIFACT messages also make use
of multipart messages.

Parsing messages
Message template information for predefined messages is usually included in the
message header, so that the message flows recognize the messages when they
receive them. Other messages might not have headers that identify the template,
but you can set up your message flow input nodes to indicate the structure of
messages that are processed by this message flow. If a message is not recognized, it
is treated as an opaque unit, known as a BLOB. A BLOB can be interpreted as a
string of hexadecimal characters, and can therefore be modified or examined in the
message flow by specifying the location of the subset of the string.

When a message is processed by the nodes in a message flow, and its header or
body is referenced by a node, the message bit stream is decoded by a message
parser. WebSphere MQ Integrator supplies several message parsers that parse
known message templates and message headers. These include parsers for all
messages defined to the Control Center or the New Era of Networks Formatter,
and generic XML messages. The complete list is given in “Message parsers” on
page 74 .

If you need to process and parse messages that the supplied parsers do not handle,
you can create new parsers using an WebSphere MQ Integrator system
programming interface. For more details of this interface, see Chapter 11,
“Enhancing your broker domain” on page 163.

Associating message sets with brokers

If you create message sets through the Control Center, you must assign them to
each broker that hosts a message flow that requires them. A single definition of a
message set can be used by the broker for all message flows, and does not have to
be assigned to a specific execution group. The same message set can be assigned to
multiple brokers. When you deploy the changes, the message set is stored in the
broker as a message dictionary.

Chapter 2. WebSphere MQ Integrator overview and concepts 25

 Applications

Applications and clients

WebSphere MQ Integrator provides support for point-to-point and
publish/subscribe application communication models.

Applications generating and consuming messages in either communication mode

can take advantage of the services provided by the message flows within the
brokers. Sending applications must place their messages on the input resources
(MQSeries or MQSeries Everyplace queues or SCADA input port) read by the
message flows providing the specific service they require. Receiving applications
must retrieve processed messages from the output resources (queues or SCADA
output ports) to which the message flow sends them when its processing is
complete.

Applications that use messages to send or receive data can communicate in several
ways. Most existing messaging middleware applications use point-to-point
communications. Now, using the services supported by WebSphere MQ Integrator
Version 2.1, applications can exploit topic and content-based filtering in a
publish/subscribe communication mode.

Point-to-point applications
WebSphere MQ Integrator continues to support existing point-to-point applications.
Typically, these applications use a request/reply or client/server model, or
broadcast a message to many target applications using distribution lists. Others send
one-way send-and-forget or datagram traffic. You can create message flows to process
these messages, in any of these ways, and assign and deploy them to your brokers.

WebSphere MQ Integrator can continue to support these existing applications

because it supports the application programming interfaces commonly used by
messaging applications today. These interfaces, the Message Queue Interface (MQI)
and the Application Messaging Interface (AMI), are unaffected by WebSphere MQ
Integrator. Existing applications written to these interfaces can usually run
unchanged in this new environment. You have only to define your message flows
to get messages from, and put messages to, the queues already used by your
applications, for the additional message processing to be completed without the
applications being aware of the change.

| Aggregation of messages
| Aggregation is an extension of the request/reply style of application. It combines
| the generation and fan-out of related requests with the fan-in of the corresponding
| replies to produce a single, aggregated, reply message.

| For example, your application might be the arrangement of a business trip. This
| task can be broken down into related subtasks:
| v book a taxi to the airport
| v book a flight
| v reserve a rental car at the destination
| v reserve a hotel room

| The original request to arrange a business trip can be split into four requests, one
| for each of the four subtasks. This is called fan-out.

| Similarly, replies from the four subtasks can be combined and handled as the
| single reply that the business trip has been arranged. This is called fan-in.

26 WebSphere® MQ Integrator: Introduction and Planning

 Applications
| The following three MQSeries Integrator nodes support aggregation:
| AggregateControl This node marks the beginning of a fan-out of
| requests that are part of an aggregation.
| AggregateRequest This node records the fact that request messages
| have been sent. It also collects information that
| helps the AggregateReply node to construct the
| aggregated reply message.
| AggregateReply This node marks the end of an aggregation fan-in.
| It collects replies and combines them into a single
| aggregated reply message.

| To use aggregation, you must construct two message flows. One message flow, the
| fan-out flow, produces related requests. The second message flow, the fan-in flow,
| collects the replies from those requests and combines them into a single reply
| message.

| Refer to WebSphere MQ Integrator Using the Control Center for more details about
| how to construct a message flow that uses the aggregation nodes.

Publish/subscribe applications
WebSphere MQ Integrator supports the publish/subscribe application
communication model. If you already have applications that are written to the
publish/subscribe model, and use the MQI and AMI, you can probably integrate
these applications into an WebSphere MQ Integrator broker domain without
change.

You can also modify these applications, or write new ones, to take advantage of
the significant enhancements in publish/subscribe processing, particularly for
subscribers.
v With WebSphere MQ Integrator Version 2.1, your subscribing applications can
now select which publications they receive based not only on the topic of the
publication, but also on specific content, or both.
v Subscribers can also use the subscription point of the publication nodes in the
message flows to receive messages that have followed a particular path through
the message flow, and have therefore been processed in a specific way.

Every message, even one used for content-based subscriptions, must have an
associated topic (specified by the publisher or defined by the input node).

A topic is used to categorize the information in the message in some way that is
understood by subscribers. Each topic has a structure, delimited by the forward
slash character (/). The use of structuring creates the topics in a topic tree, in which
each node topic attaches to the branch that contains the previous structure level.
The top level topic is known as the topic root.

A topic can be associated with the publication message by the publisher. You can
also specify a topic on the input node of your message flow: it is set as a property
of the node and is associated with a message when it arrives in the message flow
providing the publish/subscribe service. In the latter case, the topic defined by the
input node is used to determine the publication’s routing, but is not passed on to
the subscriber. Messages without explicit topics are currently treated as local only
and are not sent to other brokers in the topology.

Chapter 2. WebSphere MQ Integrator overview and concepts 27

Applications
If the publisher does not provide a topic, and the input node is not set up to
define a topic where one is needed, the Publication node treats the message as an
error and it is handled in whatever way you have determined in this message
flow.

For information about writing publish/subscribe applications see Chapter 7,

“Designing publish/subscribe applications” on page 89.

Client connections to brokers and message flows

Application A Application B

Broker
Client/server Client/server
connection connection
Queue manager

Local
connection

Application C

Figure 9. Applications connecting to a broker

All WebSphere MQ Integrator applications, like MQSeries applications, can use all
the supported MQSeries interfaces to put messages to the message flow queues. In
fact, every MQSeries application is a potential WebSphere MQ Integrator
application, and vice versa.

The applications can be connected as clients to any queue manager in the

MQSeries network, or can execute on the same system as the broker’s queue
manager, and connect locally. Figure 9 illustrates three applications connecting to a
broker.

Receiving applications can get the messages put to the output queue or queues of
a message flow when they have been processed by that message flow. The
applications must be connected, either by a client/server connection, or via a local
connection, to the queue manager that owns the queue or queues defined as the
target for their messages. If the message flow provides a publish/subscribe service,
the publication node puts the messages to the queue specified by the subscriber as
its local receiver queue.

28 WebSphere® MQ Integrator: Introduction and Planning

 User Name Server

The User Name Server

If you plan to deploy message flows that provide a publish/subscribe service to
your applications, you might want to employ topic-based security. Topic-based
security gives you the ability to control the authority of applications, identified by
the user ID under which they are executing, to publish on topics, to subscribe to
topics, and to request persistent delivery of messages on topics.

To implement topic security, you must install, create, and start one User Name
Server. (Under exceptional circumstances you might consider installing more than
one, subject to your license agreement: this is discussed in “Employing topic-based
security” on page 129.)

The User Name Server can be configured on any supported platform and works
with the security control mechanism of the underlying operating system.
Windows NT
The User Manager supports the definition and deletion of principals (users
and groups), and the assignment of user IDs to groups.
UNIX Systems
The basic user and group control in the file system supports creation,
deletion and modification of users and groups.
z/OS Systems
The User Name Server is deployed in the client domain (that is, Windows
NT, Windows 2000, or UNIX) to supply the appropriate user and group
information to the z/OS brokers. No z/OS User Name Server is required.

The User Name Server monitors the underlying security subsystem and provides
information about valid principles in the system to other components in the broker
domain. It updates the information at frequent intervals.

Figure 10 illustrates the place of the User Name Server in the broker domain.

User Name Server Security

subsystem
Queue manager

Queue manager

Configuration
Queue manager
Manager
Broker

Figure 10. The User Name Server

If you do not plan to support any publish/subscribe services in your brokers, or

you want to allow every client have full access to all topics, you do not need to
consider topic-based security, nor do you need to install and create a User Name

Chapter 2. WebSphere MQ Integrator overview and concepts 29

User Name Server
Server in your broker domain. However, if your requirements might change in the
future, it is easier to include a User Name Server in your broker domain when you
first design it. If you set global access (to all users) at the highest topic level (the
topic root), this is equivalent to having no specific topic-based security. You can
then introduce topic-based security on a more selective basis when you need to do
so.

For more information about configuring a User Name Server in your domain, and
deploying topic security, see Chapter 9, “Planning your WebSphere MQ Integrator
network” on page 125.

Resources associated with a User Name Server

When you create the User Name Server, the following resources are also created:
v A set of fixed-name queues, defined to the queue manager that hosts the User
Name Server. You must identify this queue manager when you create the User
Name Server, and it must exist on the same physical system. It is created when
the User Name Server is created, unless it already exists. The User Name Server
can share a queue manager with the Configuration Manager, or with a single
broker, or both, if supported by the product you have purchased. For a
summary of which components can be installed on which operating systems, see
“Employing topic-based security” on page 129.

Access control Lists

If you want to implement topic-based security, you must define Access Control Lists
(ACLs). You can create and maintain ACLs in the Topics view of the Control Center.
This view provides a display of the valid principals in your broker domain, and
allows you to associate these principals with specific topics. You can also view the
complete set of defined topics using the Topics view of the Control Center.

You can create an explicit ACL for any topic in the topic tree, up to and including
the topic root. An ACL allows, denies, or inherits the authority to publish, to
subscribe, and to request persistent message delivery. If any topic does not have an
explicit ACL, it is governed by the ACL it inherits from its higher level (parent)
topic in the tree. The default ACL setting for the topic root is to allow public
access. This can be modified to restrict access by introducing ACLs at specific
points in the tree.

WebSphere MQ Integrator also supports applications publishing messages on

topics created dynamically. If this option is used, the ACL applied is inherited from
the closest topic above it in the tree. For example, if the topic “Stock/IT” is defined
in the topic tree with an ACL, and a publisher publishes a message with topic
“Stock/IT/IBM” which is not defined in the topic tree, the ACL for the parent of
that topic is inherited. Therefore if this publisher is not allowed to publish on that
topic, it is prohibited from publishing on the dynamic topic, too.

For more information about publish/subscribe applications, and the use of topics
and ACLs, see “Employing topic-based security” on page 129.

30 WebSphere® MQ Integrator: Introduction and Planning

 MQSeries Everyplace

MQSeries Everyplace and SCADA

MQSeries Everyplace is designed primarily for messaging to, from and between
pervasive devices, typically small, handheld devices, such as mobile phones and
PDAs.

SCADA, similarly, provides a messaging facility for pervasive devices, but it uses a
very lightweight protocol tailored specifically for specialized applications on small
footprint devices, typically in the area of remote data acquisition and process
control.

From Version 2.0.2, input and output nodes are provided to allow messages to be
sourced from, and dispatched to, MQSeries Everyplace and SCADA

This section introduces MQSeries Everyplace concepts and outlines how MQSeries
Everyplace and WebSphere MQ Integrator work together. The WebSphere MQ
Integrator Administration Guide gives further details of the requirements needed to
achieve intercommunication between MQSeries Everyplace and WebSphere MQ
Integrator.

For further details of how to program with MQSeries Everyplace, you should refer
to the MQSeries Everyplace library. Whitepaper: MQSeries Everyplace for Windows
Version 1.1 provides a useful overview of MQSeries Everyplace. This Whitepaper is
available by following the Library-Whitepaper links from the MQSeries product
family web site; see “MQSeries information available on the Internet” on page 208
for more information.

For information specific to the use of MQSeries Everyplace nodes in WebSphere

MQ Integrator, refer to Appendix D. ″MQSeries Everyplace Nodes″ in the WebSphere
MQ Integrator Programming Guide and Chapter 5. ″Working with message flows″ in the
WebSphere MQ Integrator Using the Control Center book.

Note: Neither protocol is supported for brokers on z/OS.

MQSeries Everyplace overview

With MQSeries, you will be familiar with the concept that a client provides assured
messaging for local applications. The client can only access queues on an attached
server, which it does via a synchronous client channel connection. The server,
which can support the attachment of multiple clients, uses message channels to
provide asynchronous delivery to remote queues.

MQSeries Everyplace uses what it calls devices and gateways.

Devices
An MQSeries Everyplace device provides assured messaging for
applications through dynamic channels (see below). It allows both
synchronous local and remote queue access and asynchronous delivery to
remote queues. It therefore has the function typically associated with a
server application, although it is restricted to handling only one incoming
request at a time.
MQSeries Everyplace device code typically runs on a pervasive MQSeries
Everyplace device and is started and stopped on demand by applications
running intermittently. However, there is nothing to stop you installing a
client on any appropriate machine and running it there.

Chapter 2. WebSphere MQ Integrator overview and concepts 31

MQSeries Everyplace
This code is supplied as part of the WebSphere MQ Integrator installation
and it runs on the same machine as an WebSphere MQ Integrator
installation. It is not necessary to install the MQSeries Everyplace device
code separately.
Gateways
MQSeries Everyplace gateways have the same functionality as clients, but
also have a channel manager (which supports logical concurrent
communication) configured so they can also handle multiple incoming
requests at the same time. Gateways also support the attachment of
MQSeries servers through MQSeries client channels.
Within WebSphere MQ Integrator, the MQeInput node provides access to
the MQSeries Everyplace gateway function, as described in
“Communicating with MQSeries Everyplace from WebSphere MQ
Integrator” on page 33.
Channels
Devices and gateways use dynamic channels (so called to distinguish them
from the MQSeries client and messaging channels) to communicate.
Dynamic channels are a logical connection for sending and receiving data;
they are bidirectional, and support both synchronous and asynchronous
messaging.
Dynamic channels are established by an MQSeries Everyplace queue
manager as required so, although you should be aware of their existence,
they are not ’visible’ to the user and you not need to do anything to enable
their operation.
MQSeries Everyplace adapters
Because MQSeries Everyplace is regularly used on different pervasive
devices, it is capable of using a variety of communication protocols. These
are each implemented as an adapter so that additional protocols can easily
be handled and only those actually required need be installed.
MQSeries Everyplace queue managers
MQSeries Everyplace queue managers are similar to their MQSeries
counterparts in that they control various types of MQSeries Everyplace
queues and channels. However, their architecture is object oriented and
they run inside an instance of a Java Virtual Machine (JVM), (each queue
manager requires a separate JVM instance). Communications can be
synchronous or asynchronous.
An MQSeries Everyplace queue manager can run:
v on an MQSeries Everyplace device — handling single incoming requests.
v on an MQSeries Everyplace gateway — handling many incoming
requests simultaneously.
v as a servlet — with attributes similar to those of a queue manager
running on an MQSeries Everyplace gateway. As you would expect, only
http adapters can be used. There is no channel listener (used by typical
gateways to listen for incoming connection requests); this function is
handled by the web server.
MQSeries Everyplace queues
MQSeries Everyplace queue managers control various types of queues.
There are three which are particularly significant here:
v Local queues. This type of queue is local to, and is owned by, a specific
queue manager.

32 WebSphere® MQ Integrator: Introduction and Planning

 MQSeries Everyplace
v Remote queues. This type of queue does not reside locally. There is a
local queue definition that identifies the real queue and the queue
manager that owns it.
v MQSeries-bridge queues. These provide a path from MQSeries
Everyplace to MQSeries. A bridge queue is a remote MQSeries queue
definition on an MQSeries Everyplace gateway (see below).
MQSeries Everyplace messages
Unlike MQSeries messages (which are defined as byte arrays with a
message header and a message body), MQSeries Everyplace messages are
all passed as Java objects, derived from the base class MQeFields.
You should refer to “MQSeries Everyplace messages in WebSphere MQ
Integrator” on page 34 for details of the derived classes relevant to using
MQSeries Everyplace with WebSphere MQ Integrator.

Communicating with MQSeries Everyplace from WebSphere

MQ Integrator
Communication between MQSeries Everyplace and WebSphere MQ Integrator is
achieved through the use of MQeInput and MQeOutput nodes in message flows
deployed to WebSphere MQ Integrator brokers.

Using these nodes, you can write point-to-point applications where an MQSeries
Everyplace input message is transmitted to an MQeOutput or an MQOutput node
or publish/subscribe applications where the message is transmitted to a
Publication node.

Input from MQSeries Everyplace

MQeInput node Publish node

Intermediate MQOutput
Synchronized node
queue nodes SCADAOutput
node
MQeOutput
node
JNI
MQe device MQ gateway
MQSI_SAMPLE_QM
channel
channel

MQSeries-
Adapter Adapter bridge queue
(’MQeInputQ1’) MQeOutput
node
transformer

MQe MQe queue

queue (’inbox’) ServerQM1
ClientQM1

MQe JVM WMQI broker JVM

WMQI broker - hosted by MQSeries queue manager MQSI_SAMPLE_QM

Figure 11. Diagram showing the relationship between MQSeries Everyplace and WebSphere
MQ Integrator

In Figure 11, the MQSeries Everyplace ’client’ attached to MQSeries Integrator is an

MQSeries Everyplace device with an MQSeries Everyplace queue manager called
ClientQM1. The broker, hosted by MQSeries queue manager MQSI_SAMPLE_QM, has a

Chapter 2. WebSphere MQ Integrator overview and concepts 33

MQSeries Everyplace
message flow deployed with an MQeInput node. This has an embedded MQSeries
Everyplace gateway (with its own MQSeries Everyplace queue manager, ServerQM1
listening on an appropriate port) which treats MQSI_SAMPLE_QM as a remote
MQSeries Everyplace queue manager. You should note that only one MQSeries
Everyplace queue manager can be supported in a single instance of a JVM. So, if
you have more than one MQeInput node in the same execution group, they must
all use the same MQSeries Everyplace queue manager.

A message from the MQSeries Everyplace ’client’ destined for WebSphere MQ

Integrator must be directed to the queue belonging to the MQSeries queue
manager - MQSI_SAMPLE_QM - hosting the WebSphere MQ Integrator broker (not the
MQSeries Everyplace queue manager - ServerQM1 - running within WebSphere MQ
Integrator). Then, when the gateway receives a message destined for
MQSI_SAMPLE_QM rather than itself, the message is put on the MQSeries-bridge
queue.

At this point, the message is an MQSeries Everyplace object, so it is passed to a

transformer which creates an MQSeries form of the message and passes it back to
the MQSeries-bridge queue. The message, now an MQSeries message, is passed
over a JNI (Java Native Interface) connection and held on a synchronized
MQSeries queue belonging to MQSI_SAMPLE_QM. From this queue, it is taken into the
WebSphere MQ Integrator message flow.

Within WebSphere MQ Integrator, the message can be dealt with in different ways
depending on the message class used for the message, as explained later
(“MQSeries Everyplace messages in WebSphere MQ Integrator”). There is no
parser in WebSphere MQ Integrator directly capable of parsing messages derived
from MQSeries Everyplace.

You must ensure that all flows that communicate with MQSeries Everyplace are
within the same execution group.

You must have an associated MQeInput node, even if you are only writing
messages to MQSeries Everyplace and not receiving them from MQSeries
Everyplace. There is information (such as the queue manager name and the
listening port) that MQSeries Everyplace clients need to connect to WebSphere MQ
Integrator that is specified only in the MQeInput node.

If MQSeries Everyplace security is configured then the MQSeries Everyplace

authentication (described in the MQSeries Everyplace manuals) is used until the
message reaches the special bridge queue.

MQSeries Everyplace messages in WebSphere MQ Integrator

When MQSeries Everyplace communicates with an WebSphere MQ Integrator
network, there are two classes that are used to create MQSeries Everyplace
message objects:
v MQeMsgObject
v MQeMbMsgObject

MQeMsgObject: MQeMsgObject does not put any restrictions on the fields it can
contain, and so only predefined fields are transferred to the MQMD (the MQSeries
message descriptor) when the message is passed to an MQSeries network — the
remaining fields are put, unparsed, in the message body. The payload of a message
derived from MQeMsgObject cannot be parsed, but this type of message does enable
you to use special MQSeries Everyplace fields, such as pic, so that the message can

34 WebSphere® MQ Integrator: Introduction and Planning

 MQSeries Everyplace messages in WebSphere MQ Integrator
be reconstructed if it is sent back to MQSeries Everyplace by one of the nodes
within the message flow (primarily the MQeOutput node).

MQeMbMsgObject: A message constructed from MQeMbMsgObject has only those

fields that are compatible with the broker passed into the message flow;
unrecognized fields are ignored. Therefore, if this message is routed back to an
MQSeries Everyplace queue, these fields are not present. Although it enables you
to parse the payload, and therefore manipulate or operate on parts of that data (for
example, store it in a database), you are restricted in your use of certain MQSeries
Everyplace fields.

Chapter 2. WebSphere MQ Integrator overview and concepts 35

SCADA applications
SCADA applications
The device protocol, MQIsdp, is designed to gain access to a message broker,
typically from remote devices characterized by requiring a low bandwidth
communication. It employs TCP/IP for communication and uses a
publish/subscribe communications model. A typical system might comprise several
hundred client devices communicating with a single WebSphere MQ Integrator
broker, with each client identified by a unique ID.

You can incorporate SCADA applications into WebSphere MQ Integrator by getting

input from a SCADAInput node. But because SCADA is solely a publish/subscribe
protocol, you would normally use the Publication node (which embeds a
SCADAOutput node) to return output to the SCADA application. Only in advanced
applications might you need to use the SCADAOutput node directly — for example if
you want to write your own publication node.

Unlike both MQSeries and MQSeries Everyplace, SCADA does not incorporate any
form of security, although you can encrypt data if necessary.

SCADA has a concept of ’Quality of Service’ (QoS), similar to persistence in

MQSeries:
QoS0 ″At most once″ delivery. Delivery is not assured; no acknowledgment is
expected.
QoS1 ″At least once″ delivery. Successful delivery is assured and an
acknowledgment sent.
QoS2 ″Exactly once″ delivery. As for QoS1, but the message is assured not to be
duplicated.

The SCADAInput node listens on a defined port and receives messages from clients
using the MQIsdp protocol. A SCADA listener can be started and stopped using a
publish message with a specific topic. This can be done for all ports, or for a single
port identified in the message.

The Publication node filters and transmits the output from a message flow to
subscribers who have registered an interest in a particular set of topics. Normally,
this would be done by putting the message to the queue on the queue manager
specified in the subscription. But because the Publication node contains a
SCADAOutput node, the message can just as easily be delivered to a subscribing
SCADA client over TCP/IP.

The WebSphere MQ Integrator Administration Guide gives further details of the

requirements needed to achieve intercommunication between WebSphere MQ
Integrator and SCADA. For details of the SCADA protocol, see the WebSphere MQ
Integrator Programming Guide, and for information specific to the use of SCADA
nodes in WebSphere MQ Integrator, refer to Chapter 5. ″Working with message flows″
in the WebSphere MQ Integrator Using the Control Center book.

36 WebSphere® MQ Integrator: Introduction and Planning

 Dependencies

Dependencies
A number of dependencies have been highlighted by this discussion of WebSphere
MQ Integrator and its components. These dependencies are summarized here, to
help clarify the requirements that WebSphere MQ Integrator has on your systems.
For details of software levels for other products (databases and MQSeries), see
Chapter 8, “System requirements” on page 109.

MQSeries dependencies
WebSphere MQ Integrator is heavily dependent on the facilities of MQSeries
messaging to provide connectivity, message integrity, and some transactional
support. In summary, these dependencies are:
Queue managers
A single MQSeries queue manager can host at most one broker. The
Configuration Manager and the User Name Server both depend on a
queue manager, but can share this queue manager with each other, or with
a single broker, or both.
Communications
When you set up a network of queue managers to support WebSphere MQ
Integrator, you must define their connectivity. You can use any one of the
communications protocols supported by the underlying MQSeries product
(this varies according to operating system environment).
The client/server connection between the Control Center and the
Configuration Manager, however, is limited to a TCP/IP connection, and
the Control Center depends on the MQSeries client for Java.
The Configuration Manager
This depends on a queue manager, with a set of fixed-name queues and a
server connection channel that is defined when it is created.
The Configuration Manager also needs sender and receiver channels to be
able to communicate with every broker in the broker domain (except the
one broker, if defined, that is created with the same host queue manager).
The broker
Each broker depends on a dedicated queue manager (a broker cannot
share a queue manager with another broker, although it can share a queue
manager with the Configuration Manager, or the User Name Server, or
both). It also needs a set of fixed-name queues that are defined when the
broker is created.
The broker needs sender and receiver channels to be able to communicate
with the Configuration Manager. It also needs sender and receiver channels
to communicate with the User Name Server, and sender and receiver
channels to communicate with all brokers in the same collective, or to
which it is identified as a neighbor in the topology.
MQSeries applications
Each MQSeries application using WebSphere MQ Integrator services must
be able to connect to a queue manager in the MQSeries network to allow it
to put messages to the queue serviced by the message flow that provides
the service it requires. This connection can be local, or can use any
supported MQSeries client product, with the appropriate server and client
connection definitions.
Each MQSeries application retrieving messages from a queue populated by
a message flow must be able to connect to the queue manager that owns

Chapter 2. WebSphere MQ Integrator overview and concepts 37

Dependencies
that queue (which can be local or remote to the queue manager that hosts
the message flow putting the message). This connection can be local, or
can use any supported MQSeries client product, with the appropriate
server and client connection definitions.
If the MQSeries application retrieving messages is a subscriber to a
publish/subscribe service, the messages it receives are propagated to the
broker to which it has subscribed, regardless of the proximity of the broker
(and its queue manager) that hosts that publish/subscribe service.
SCADA and MQSeries Everyplace
Message flows containing SCADA and MQSeries Everyplace nodes must
reside in a single execution group within the broker. If a message flow uses
an MQeOutput node there must be an MQeInput node in a message flow
in the same execution group. If a message flow uses the SCADA
functionality of a Publication node there must be a SCADAInput node in a
message flow in the same execution group.
The User Name Server
This depends on a queue manager, with a set of fixed-name queues
defined when it is created. It can share a queue manager with the
Configuration Manager, or a single broker, or both.
The User Name Server also needs sender and receiver channels to be able
to communicate with the Configuration Manager, and with every broker in
the broker domain to which it provides principal definitions (except to the
Configuration Manager, or one broker, or both, with which it shares its
host queue manager).

Further information on these dependencies is provided in Chapter 9, “Planning

your WebSphere MQ Integrator network” on page 125, and full details of exactly
which component of WebSphere MQ Integrator depends on which MQSeries
component, and the software levels supported, are provided in the MQSeries MQ
Integrator Installation Guide for your product.

Database dependencies
The WebSphere MQ Integrator components use databases to store configuration
and operational information. In summary, these dependencies are:
The Configuration Manager
This needs two independent sets of tables to support the message
repository and the configuration repository.
These tables are created and initialized when the Configuration Manager is
created. The two repositories can be created within a single database, or in
two separate databases. Both repositories must be created in a DB2
database.
The Configuration Manager can use either a local connection to the
databases, or a remote connection.
The broker
Each broker needs access to a set of tables to support its operation.
These tables are created and initialized when the first broker is created.
The broker tables can be created in the following databases:
v IBM DB2 Universal Database
v Microsoft SQL Server (Windows NT only)
v Oracle
v Sybase

38 WebSphere® MQ Integrator: Introduction and Planning

 Dependencies
For a broker on WebSphere MQ Integrator for z/OS, the only database that
can be used is DB2.

For more information about the supported databases, see Table 4 on

page 121.

If you are using DB2 and your broker is on Windows NT, the broker tables
can be created within the same database as the configuration repository, or
the message repository, or both. However, restart and recovery is easier if
you have three separate databases, one for the broker tables, one for the
configuration repository, and one for the message repository.

When you subsequently create other brokers, they can share the same set
of tables, because every entry on each table (row) identifies an individual
broker. If you prefer, you can set up separate databases (and therefore sets
of tables) for each broker.

The broker can use either a local connection to the databases, or a remote
connection.

You can find instructions that tell you how to create these databases, the ODBC
connections they require, and the need for Microsoft Data Access Component
(MDAC), in the WebSphere MQ Integrator Administration Guide and the WebSphere
MQ Integrator for z/OS Customization and Administration Guide.

You must always use the Control Center to update the database tables used by
WebSphere MQ Integrator. If you access these tables directly using any other
means, you risk destroying the integrity of that data.

Further information on these dependencies is provided in Chapter 9, “Planning

your WebSphere MQ Integrator network” on page 125, and exact details of
database product levels supported are provided in the MQSeries MQ Integrator
Installation Guide for your product.

Chapter 2. WebSphere MQ Integrator overview and concepts 39

Release to release migration

Release to release migration

For information about migration, see the Appendix A, “Planning for migration and
integration” on page 167. See also the WebSphere MQ Integrator Administration Guide
and the WebSphere MQ Integrator for z/OS Customization and Administration Guide.

If you are migrating to WebSphere MQ Integrator Version 2.1 from MQSeries

Integrator Version 2.0, Version 2.0.1, or Version 2.0.2 you must refer to the
Readme.txt file that is provided on the product CD. This gives the latest
information about migration requirements. You must also be aware of the
following points:
v The WebSphere MQ Integrator Version 2.1 Control Center only operates if the
Configuration Manager is also at Version 2.1. You must upgrade all instances of
the Control Center to Version 2.1 when you upgrade the Configuration Manager
to Version 2.1.
v You must delete and recreate the Configuration Manager when you migrate it to
Version 2.1. This makes available the new nodes and message sets supplied with
the product.
v You need to migrate New Era of Networks Rules and Formats in databases used
with Version 2.0, 2.0.1, or 2.0.2 to the new format that is compatible with the
updated New Era of Networks Rules and Formatter Support included with
version 2.1.

40 WebSphere® MQ Integrator: Introduction and Planning

Chapter 3. WebSphere MQ Integrator: a business scenario
This chapter uses a hypothetical scenario to explore a company’s existing business
problems, and to summarize the ways in which WebSphere MQ Integrator solves
those problems.

This scenario illustrates the deployment of WebSphere MQ Integrator, refers to the

components and concepts discussed in Chapter 2, “WebSphere MQ Integrator
overview and concepts” on page 9, and enhances your understanding by providing
a practical application of those concepts.

However, this is just one scenario that has been chosen for more detailed
examination. Other scenarios might include:
v The financial industry, which needs to make sure that vast numbers of
transactions happen, happen correctly, and happen once and once only.
v The health-care industry, which needs accurate information to be available across
multiple, heterogeneous, and often long established, systems.

The retail scenario, and others, are available by downloading the MQSeries
SupportPac IC03 from the MQSeries product family web site. For more information
see “MQSeries information available on the Internet” on page 208.

© Copyright IBM Corp. 2000, 2002 41

Retail scenario

The retail scenario

SRU Corporation (SRU) is a chain store that sells food. It has expanded rapidly in
the last three years, with new branches opening in Amsterdam and London, and it
has greatly extended its range of products.

The company headquarters are in Vancouver, Canada. Its current warehouse

branches are in San Diego, California and Santiago, Chile, and the retail stores are
spread throughout the world. Trading information from all stores needs to be
available to many different members of SRU staff at different locations, using
different applications. A subset of the information needs to be made available to
supplier companies. In the future, SRU intends to expand its business to support
shoppers on the Internet, and wants to introduce a loyalty card system.

Figure 12 shows the overall hierarchy of the SRU IT configuration.

Santiago London

HQ:
Vancouver

San Diego Amsterdam

Headquarters

Branches

Figure 12. SRU headquarters and branch hierarchy

SRU wants to bridge the gap between its existing applications and the increased
number of back-end systems. It also wants to ensure that access to some
information can be restricted only to those applications that need it. It also needs a
solution that can be enhanced in the future. WebSphere MQ Integrator can provide
the facilities that meet these major objectives:
v Bridging the gap: WebSphere MQ Integrator provides message transformation
facilities that support the receipt of a message in one format and the distribution
of that message in one or more different formats, according to the business
needs of the target applications, without any modification of existing
applications.
v Restricting information: WebSphere MQ Integrator provides topic and
content-based message routing using controls to restrict the recipients of any
message.

42 WebSphere® MQ Integrator: Introduction and Planning

 Retail scenario
v Future extension: WebSphere MQ Integrator provides a basic framework that can
be extended by parties such as ISVs. Message processing can be enriched by the
inclusion of tailor-made nodes in the message flow. New message formats can
be added to meet new application requirements, for example when new systems
are added to the network.

Figure 13 shows the relationships between the warehouse branches and the
back-end systems.

HQ:
(Vancouver)

Santiago
San Diego
MQSeries V5.2
London WebSphere Distribution:
MQ Integrator (Santiago)
Amsterdam Version 2 (London)

Partners:
(London)
(Amsterdam)
(San Diego)

Auditors:
(Vancouver)

Figure 13. Branches and back-end systems

Business data
Data is taken from the receipts generated for each transaction that takes place
within each retail store. SRU gathers this data from its retail stores. Here is an
example of a receipt from one of the stores:
SRU
SOUTHAMPTON
HAMPSHIRE

Cashier 112 Till no. 03

Date 26/04/2001 Time 15:30

Purchases

1 tinned ham 3.99

056784637
1 tinned ham 3.99
056784637
1 garlic mash 2.92
047388567
1 skimmed milk 1.63
037809462

Total items 4
Multibuy Yes
Multibuy item tinned ham
Multibuy quantity 2
Total sales 12.53
Change 2.47

Chapter 3. WebSphere MQ Integrator: a business scenario 43

Retail scenario
Business needs
From this data, SRU has the following major information needs:
1. An audit trail of all transactions in the branches. All receipt information must
be stored for audit reasons. This information can also be used for offline data
access and mining.
2. Financial reports per store per month. With the rapid growth over the last three
years, sales within SRU are doing well. Headquarters are very happy with this,
but want to know exact figures from each store on a monthly basis. The finance
department have been instructed to gather this information from each store at
the end of each month.
3. Stock levels for products supplied for its Distribution group. As sales are doing
well, stock levels must be kept up so that customers do not go elsewhere for
their goods. To do this, the number of items sold must be sent to the Stock
Distribution department so they are prepared to maintain stock levels. The
Stock Distribution department is on a back-end system that uses a different
operating system to that in use by the warehouse branches, so information
must be formatted in such a way that it can be understood by the Stock
Distribution system and applications.
4. Predicted peaks in demand for products from its partners. Headquarters want
to keep track of products that are doing well so that they do not run out of
them. If more than one of the same product is bought on the same transaction,
this is called a “multibuy”. For each multibuy, headquarters want to inform
their partners to ensure that more of the product can be supplied.

The information required by each interested party is shown in the following table:

Recipient Information required

Auditors All data from receipts

Finance Total Sales per receipt
Distribution Branch, Item Name, Item Quantity
Partners Multibuy items

Business solution using WebSphere MQ Integrator Version 2

The business needs that are listed in the previous section, can be satisfied using a
solution with WebSphere MQ Integrator Version 2.1.

The first task is to represent the business data (that is, the receipt) as a message
with a structured format:
Store Details
Store Name
Branch No
Cashier No
Till No
Date
Time
Purchases
Item Name
Item Code
Item Price
Item Quantity
Totals
Total Items
Multibuy
Total Sales
Change

44 WebSphere® MQ Integrator: Introduction and Planning

 Retail scenario
This message can be processed to handle the specific business needs. A message
flow is created that takes the message from an input queue and processes the
message to produce the required output messages. A simplified form of the
message flow is shown in Figure 14.

The Business Flow FINANCE FLOW

Finance
Extract Trace Output
department

STOCK FLOW

Reformat Stock
Input Check Warehouse Compute Output
Distribution

PARTNER FLOW

Yes
Filter DataInsert Publication Partners
Topic Multibuy

Figure 14. The business flow (simplified)

The message flow includes four subflows that perform the processing required to
satisfy the business needs:
1. Initially, all messages are retrieved from the input queue by the MQInput node.
Each message is checked to ensure that it is a message of the correct format for
a receipt (in a Check node) and stored in a database (in a Warehouse node)
before it is passed to all three of the remaining subflows.
2. In the Finance flow, the fields Branch No, Date, Time and Total Sales are
extracted from the input message in an Extract node. Each message is then
traced by the Trace node. The records that are written to the trace log enable
you to ensure that only the data extracted by the Extract node is sent to the
Finance department by the Output node.
3. In the Stock flow, a Compute node sums up all instances of each item from the
input message. This information can then be formatted and sent in a message
containing Branch No, Item Name and Item Quantity by the Output node to
the Stock Distribution department.
4. In the Partner flow, multibuy records are placed into a database by a
DataInsert node and published to registered partners by the Publication node.
Partners subscribe to messages based on a topic (Multibuy) or refine their
subscriptions further by filtering on the content of a field (the item name) in a
message.

A reusable exception handling message flow is used to help with problem

determination while the main message flow is being developed or upgraded. This
exception handling flow can be embedded anywhere in the main flow.

Access Control Lists are defined in the Control Center to ensure that user IDs
associated with partners are restricted to subscribing to the items they produce. For
example, the partners producing the tinned ham product register a subscription
based on the topic Multibuy/tinned ham, and are not authorized to receive messages
published on any other topic.

Chapter 3. WebSphere MQ Integrator: a business scenario 45

Retail scenario
Different applications within the partner organizations can also choose to restrict
the messages they receive even further, using content based subscriptions. For
example, one application might want to process only those messages which
indicate that a quantity of ten or more items have been bought in one transaction.

Implementing the business solution

There are several steps you need to take to implement this, or any other business
solution:
1. First, you must plan your WebSphere MQ Integrator system. For example, you
must decide how many brokers you need to meet your business requirements,
what message flows you need, and so on. This chapter has identified just one
message flow, but a more complex setup is very likely. This book helps you to
plan your WebSphere MQ Integrator configuration, and to understand the
implications for the MQSeries infrastructure, security, performance and so on.
2. Next, you must implement the WebSphere MQ Integrator system you have
designed by installing and configuring the components you need on the
appropriate systems following the guidance provided in the MQSeries MQ
Integrator Installation Guide for your product, in the WebSphere MQ Integrator
Administration Guide and in the WebSphere MQ Integrator for z/OS Customization
and Administration Guide.
3. You must define your message sets and message flows. WebSphere MQ
Integrator Using the Control Center has all the information you need to achieve
this task.
4. You must write application programs to interact with the message flow using
the message structures you have created. The WebSphere MQ Integrator
Programming Guide provides the information you need to do this.
If you have existing applications on the back-end systems, you must ensure
that the message flow generates messages for those existing applications in the
correct formats, so the application source code does not have to be changed.
WebSphere MQ Integrator Using the Control Center helps you to define the
transformations you need to provide compatible message formats from your
message flows.
5. Last, but not least, you must test the applications that generate the messages
for your message flow, and check the results.

46 WebSphere® MQ Integrator: Introduction and Planning

Part 2. Business process planning
Chapter 4. Message flows . . . . . . . . . 49 Interacting with an external database . . . . 63
What is a message flow? . . . . . . . . . . 50 Recording and responding to events and
What does a message flow consist of? . . . . 50 errors . . . . . . . . . . . . . . 64
Message flows and units of work . . . . . . 51 Supplied message flows . . . . . . . . . 64
Parallel processing of message flow instances . . 51 Adding or enhancing message processing nodes . . 66
Interaction of message flows. . . . . . . . 52 Message flow porting issues . . . . . . . . . 66
Transformation . . . . . . . . . . . . 52 Using the Debugger to solve message flow problems 67
Intelligent routing . . . . . . . . . . . 53
Enriching message content . . . . . . . . 53 Chapter 5. Messages. . . . . . . . . . . 69
What is a message processing node? . . . . . . 54 Predefined and self-defining messages . . . . . 69
Common node characteristics . . . . . . . 54 Predefined messages using the MRM . . . . . 70
Input and output nodes . . . . . . . . . 55 Message templates . . . . . . . . . . . 70
Processing messages . . . . . . . . . . 55 Using predefined messages . . . . . . . 71
Error handling . . . . . . . . . . . . 56 New Era of Networks format messages . . . . 72
What is an execution group? . . . . . . . . 58 How messages are processed in a message flow 72
Message flows and message sets . . . . . . . 59 Exporting and importing MRM message sets . . 73
Message flows for publish/subscribe services . . . 60 Using message templates and messages . . . . . 73
Supplied message flows and nodes . . . . . . 61 Client access to messages . . . . . . . . . 74
Primitive node types . . . . . . . . . . 61 Message parsers . . . . . . . . . . . . . 74
Receiving and routing . . . . . . . . . 61 Default message parsers . . . . . . . . . 74
Message transformation . . . . . . . . 62 Creating additional parsers . . . . . . . . 76
Selecting a message based on content. . . . 63

The information here is an introduction to the detail provided in WebSphere MQ

Integrator Using the Control Center.

© Copyright IBM Corp. 2000, 2002 47

48 WebSphere® MQ Integrator: Introduction and Planning
Chapter 4. Message flows
This chapter gives you more information on message flows, and how they are
constructed and deployed in your broker domain. It covers the following:
v “What is a message flow?” on page 50
v “What is a message processing node?” on page 54
v “What is an execution group?” on page 58
v “Message flows and message sets” on page 59
v “Message flows for publish/subscribe services” on page 60
v “Supplied message flows and nodes” on page 61
v “Adding or enhancing message processing nodes” on page 66
v “Message flow porting issues” on page 66
v “Using the Debugger to solve message flow problems” on page 67

© Copyright IBM Corp. 2000, 2002 49

What is a message flow?

What is a message flow?

The WebSphere MQ Integrator message broker supports the processing of
messages after one application has put a message to a queue, and before another
application gets that message from a queue. It provides this support by directing
the message from the initial queue to the target queue (or queues) through a
message flow.

Note: In SCADA applications, messages arrive and leave via a port rather than a
queue, but the principle is the same.

The content and execution characteristics of a message flow are discussed in the
following sections:
v “What does a message flow consist of?”
v “Message flows and units of work” on page 51
v “Parallel processing of message flow instances” on page 51
v “Interaction of message flows” on page 52
v “Transformation” on page 52
v “Intelligent routing” on page 53
v “Enriching message content” on page 53

What does a message flow consist of?

A message flow is a sequence of operations performed on a message by a series of
message processing nodes. The actions are defined in terms of the message format,
its content, and the results of individual actions along the message flow.

WebSphere MQ Integrator includes a range of message processing nodes, called

primitives, that provide most of the function that you need in most situations.
Some of these nodes are used to illustrate the nature of a message flow in this
discussion. For details of these nodes, see “Primitive node types” on page 61. For
details of how you can define your own message processing nodes to extend the
function available to a message flow, see Chapter 11, “Enhancing your broker
domain” on page 163.

A message flow and the message processing nodes it contains describes the
transformation and routing applied to an incoming message to transform it into
outgoing messages. These actions form the rules by which the message is
processed.

A message flow can also be made up of a sequence of other message flows that are
joined together. This function allows you to define a message flow containing a
specific sequence of message processing nodes, and reuse that message flow in
other message flows wherever that action is needed.

One example of why you would use this technique is error handling. You can
define a message flow of one or two nodes that perform the action you want taken
when an error is encountered, and include that message flow as a sub-message
flow in all your other message flows.

When you complete the creation of your message flow, you can assign it for
execution to one or more brokers. When you do this, the message flow must be
operationally complete. That is, it must contain at least one of the supplied input
nodes, such as MQInput node (one of the primitives). Most message flows also
contain at least one output node, such as MQOutput, or one Publication node,
although this is not required (both of these nodes are also primitives).

50 WebSphere® MQ Integrator: Introduction and Planning

 What is a message flow?
You can choose to limit the number or the type of message flows (and therefore, by
inference, the type of messages processed) to run in any broker according to the
criteria you decide.

For example, you could deploy all message flows that access a particular database
to a single broker. You could choose to deploy the message flows that provide a
publish/subscribe service to a specialized group of brokers.

You can also control some aspects of how your message flows run, within a single
broker. Each broker can host a number of execution groups. An execution group
provides an execution environment, that offers protection and isolation.“What is an
execution group?” on page 58 has more information about using execution groups.

Message flows and units of work

A message flow is transactional: you can define your message flows to perform all
processing within a single unit of work. Therefore the receipt of every message by
the input node, and the database operations performed as a result of that message
being received and processed by the message flow, are coordinated.

If an error occurs within a transactional message flow, the transaction is rolled

back and the message is handled according to normal error handling rules
(described in “Error handling” on page 56).

You can also define a message flow to work outside of a unit of work if you do
not want this support.

Parallel processing of message flow instances

When you define, assign, and deploy a message flow, the broker automatically
starts an instance of the message flow for each input node (one or more). This is
the default behavior. Each instance retrieves a message from the input node, and
runs in parallel with other instances that retrieve a message from other input
nodes.

If you want to further increase the throughput of this message flow, you can set a
property of the assigned message flow (that is, the property is available when you
have assigned the message flow to the broker’s execution group) that defines how
many additional instances are to be started by the broker for that message flow.
You can set properties of the input node to exercise control over the order in which
messages are processed: for example, you can force all messages received from a
single client to be processed in order. This is discussed further in “Message order”
on page 82.

You can also increase message flow throughput by assigning more than one copy
of the message flow to the same broker. However, this is only appropriate if the
message order is not important, because the multiple copies of the message flow
are handled independently by the broker, with no correlation between them.

Therefore, if more than one copy of the same message flow is active within the
broker, each copy can be processing a message at the same time, from the same
queue. It is possible for the processing time of a message flow to vary, and
multiple message flows accessing the same queue could therefore read the
messages from the queue in a random order. Also, the order of messages produced
by the message flows might not correspond to the order of the original messages.
You can influence the order in which the input node removes messages from the
queue (using the Order Mode property).

Chapter 4. Message flows 51

What is a message flow?
You are therefore recommended to increase the instances of a single copy of the
message flow if you want to increase throughput and parallel processing but want
to have control over the message order.

Interaction of message flows

In general, the message flows that you define and deploy do not interact with
other message flows, and the processing of one message by the message flow does
not influence the processing of another message.

It is possible, however, to create message flows that do interact to achieve

particular outcomes. For example, one message flow could store a message in a
database: a second message flow could retrieve that message and use its contents
(for example, a currency exchange rate) to influence the contents of the message
currently being processed, by inserting fields, or recalculating a value.

Each instance of a message flow handles strictly one message at a time. A message
flow instance does not accept a second message (that is, read a new message from
the input queue or SCADA port) until the first message has been completely
processed.

Transformation
Most enterprises have applications that have been developed over many years, on
different systems, using different programming languages, and different methods
of communication. Standard message queuing technology can bridge differences
like these, but applications still need to be aware of, and negotiate, the format in
which the messages flow.

WebSphere MQ Integrator changes all that. The knowledge of each application is

stored just once in the broker and each message is translated into the receiving
application’s format.

For example, personal names are held in many forms in different applications.
Surname first or last, with or without middle initials, upper or lower case: these
are just some of the permutations. Because the broker knows the requirements of
each application, it can transform the message to the correct format without the
sending or receiving application needing any modification.

A message flow can completely rebuild a message, convert it from one format to
another (whether format means order of fields, byte order, language, and so on),
remove content from the message, or introduce specific data into it. For example, a
node can interact with a database to retrieve additional information, or store a
copy of the message (whole or part) in the database for offline processing.

The following examples show how important message transformation can be:
v An order entry application has a Part ID in the body of the message, but its
partner stock application expects it in the message header. The message is
directed to a message flow that has knowledge of the two different formats, and
can therefore reformat the information as it is needed.
v A data-entry application creates messages containing stock trade information.
Some applications receiving this message need the information as provided, but
others need additional information added to the message about the price to
earnings (PE) ratio. The stock trade messages are directed to a message flow
which passes the message unchanged to some output nodes, but calculates and
adds the extra information for the others. The message flow does this by looking

52 WebSphere® MQ Integrator: Introduction and Planning

 What is a message flow?
up the current stock price in a database, and uses this value and the trade
information in the original message to calculate the PE value before passing on
the updated message.

Intelligent routing
Intelligent routing encapsulates business knowledge of how information should be
distributed between sending and receiving applications throughout the enterprise.
This knowledge is stored in the broker as a set of rules that are applied to each
message as it passes through the broker. Routing is independent of the requirement
for message transformation, although you will usually define sets of rules, as
message flows, that combine the two in some way. Messages are distributed
according to criteria applied to the values of fields within the message.

For example, a money transfer application always sends messages to one other
application. You might decide that every message with a transfer value of more
than $10,000 must now also be sent to a second application, to enable all
high-value transactions to be recorded.

In another example, a national auto club offers a premier service to specific

members for orders above a threshold value. Most orders are routed through the
usual channels, but if the membership number and order value meet certain
criteria, the order gets special treatment.

You can also establish a more dynamic routing option by building additional
routing information into the message when it is processed. Optional sets of rules
are set up to receive messages according to values (destinations) set into the
message. You can establish these rules such that a message is processed by one or
more of the optional sets of rules, in an order determined by the added message
content.

You can create, modify, and use these rules to develop a very flexible approach to
the distribution of information. New ideas and requirements can be stated clearly,
and turned into new or changed rules in the broker, and your business goals are
met. You don’t need to rework your applications.

Your business processes range from the simple to the very complex. You can create
rules to cover every case, building new rules, and reusing and combining existing
ones to develop even the most complex solution.

Enriching message content

When a message is processed by a message flow, it is possible to update and add
to the message content. This allows you to add value between sender and receiver
in any way you choose.

A typical way in which you can enhance the message content is by adding data
from a database. This could be done by appending fields to the message, or
merging information from the two sources, for example by calculating a new field
value using the database information.

Chapter 4. Message flows 53

What is a message processing node?

What is a message processing node?

A message processing node is a stand-alone procedure defined within a message
flow that receives a message, performs a specific action against it, and outputs zero
or more messages as a result of the action it has taken.

This section describes the types of nodes, using the primitives included in
WebSphere MQ Integrator to illustrate the function they provide.

You can create additional message processing nodes to provide enhanced or

replacement function if you choose, except where noted. For further information
about this extension to WebSphere MQ Integrator, see “Adding or enhancing
message processing nodes” on page 66.

Common node characteristics

Every message processing node has a fixed number of input points and output
points. These points are known as terminals. Each node normally has one input
terminal (on which it receives messages), and multiple output terminals to handle
a variety of situations. Output terminals are defined according to the characteristics
of the individual node. For example, a filter node has true, false, failure, and
unknown output terminals.

A connector joins an output terminal of one node to an input terminal of the next
node in the message flow. You can leave an output terminal unconnected, or you
can connect a single output terminal to more than one target node. (Figure 4 on
page 18 illustrates the relationships between connectors, terminals, and nodes.)

After a node has finished processing a message, the connectors defined from the
node’s output terminals determine which node, or nodes, process the message
next. If a node has more than one output terminal connected to a target node, the
node determines the order in which the different execution paths are executed. If a
single output terminal has more than one connector to a target node, the broker
determines the order in which the different execution paths are executed. You
cannot change the order of processing determined by the node or broker.

A node does not always produce an output message for every output terminal:
often it produces one output for a specific terminal depending on the message
received. For example, a filter node typically sends a message on either the true
terminal, or the false terminal, but not on both.

When the processing determined by one connector has been completed, the node
issues the message again to the next connector, until all possible paths have been
completed. Updates to a message are never propagated to previously executed
nodes, only to nodes following the node in which the update has been made.

The message flow can only accept a new message for processing when all paths
through the message flow (that is, all connected nodes from all output terminals,
as appropriate) have been completed.

54 WebSphere® MQ Integrator: Introduction and Planning

 What is a message processing node?
Input and output nodes
Some message nodes have special characteristics: they define points in the message
flow to which clients send messages (input nodes such as MQInput), or from
which clients receive messages (output nodes such as MQOutput). These special
nodes reference MQSeries or MQSeries Everyplace queues or SCADA ports —
referred to here as I/O resources. Client applications interact with these nodes by
putting messages to, or getting messages from, these I/O resources.

A message flow has a set of (one or more) input nodes to which senders can post
their messages, and a set of output nodes from which receivers can pick up
messages. Although a message flow must include an input node, you do not need
to include an output node. For example, you might just want to store a message in
a database for audit purposes.

If a message is being processed under transactional control, the output node only
puts the message to the destination I/O resource when all processing by the
message flow has been successfully completed, unless the output node is set up to
put the message outside the global (message flow) transaction.

Before you can use a message flow, the input nodes must be associated with I/O
resources that represent the sources of messages. An output node must also be
associated with an I/O resource in most cases. However, you can set an output
node property that causes the node to put the message to every I/O resource in a
destination list, which is contained within the message itself.

You must use one of the supplied primitive nodes for every message flow input
node: or you can write one of your own. You should use the MQInput node in
most cases, but you should use the MQeInput node when interfacing with
MQSeries Everyplace applications, and the SCADAInput node when interfacing
with remote SCADA devices.

You can use the supplied MQOutput node, or you can replace it with one you
have written, if you choose. Use the supplied MQeOutput node for MQSeries
Everyplace applications, and the Publication node for typical SCADA applications.
(The Publication node knows how to handle SCADA messages — you only need
to use the SCADAOutput node in exceptional circumstances.)

Publication nodes are a special type of output node that use the queues identified
by current subscribers whose subscriptions match the characteristics of the current
message. Subscribers provide the identity of the queue on which they want to
receive all matching publications.

Processing messages
All nodes other than the input and output nodes receive an input message from
the previous node in the message flow and transform it into zero or more output
messages to be made available to the next node (or nodes) in the message flow.
Messages passing between nodes are not put to an intermediate queue: each
message is held in local memory.

These nodes can perform any kind of processing on a message. For example, they
can:
v Transform the message (Compute).
v Extract fields from the data within the message (Extract).
v Route the message to one or more targets (RouteToLabel).

Chapter 4. Message flows 55

What is a message processing node?
v Archive the message in a message warehouse (Warehouse).
v Update database information from the message content (Database).

You can customize the processing of these nodes by using Extended Structured
Query Language (ESQL). This is a specialized form of standard database SQL and
allows you to manipulate the content of messages.

In addition, these nodes provide a menu of valid ESQL statements. You can
highlight statements to see their syntax. You can drag and drop statements into the
ESQL editor. You can also drag and drop to insert message field references into the
ESQL statements. The ESQL statements are processed when the node is invoked as
part of a message flow.

Note: Only some nodes support full ESQL editing and the new ESQL statement
menu (Filter, Compute, Database).

Error handling
All primitive message processing nodes have a failure output terminal, to which a
message is transferred if an error is detected within the node. If the failure
terminal is not connected to a target node, an exception is generated and
propagated back towards the input node:
v If a TryCatch node is encountered before the exception reaches the input node,
the flow of control proceeds down the catch terminal. The message that is
propagated through the catch terminal is the message originally received by the
TryCatch node: any changes made to the message by later nodes in the message
flow are not preserved. However, any external processing (for example, updates
to a database through a Database node) are preserved. It is not possible to roll
back these database updates from within the message flow.
Before the TryCatch node passes on the message to the node connected to the
catch terminal, it adds the exception information to the ExceptionList item in the
message tree. Existing information in the ExceptionList field in the message is
written to the local error log, and then overwritten with the new exception
information.
For further information about ExceptionLists, see the WebSphere MQ Integrator
Working with Messages book.
v If the message reaches the input node:
– If the input node’s catch terminal is connected to another node, the message
is propagated to that node. In this case, an error is not recorded in the local
error log (for further details of how WebSphere MQ Integrator logs errors, see
“Problem determination” on page 157).
– If the input node’s catch terminal is not connected, and the message is being
processed under transactional control, the message is returned to the input
queue. An error is recorded in the local error log. The input node then reads
the message again for retry. It first checks to see if the backout count for this
message has now exceeded the backout threshold:
- If the backout count has not exceeded the threshold, the message
processing is retried.
- If the backout count has exceeded the threshold, and the failure terminal is
connected to another node, the message is propagated to that node.
If the failure terminal is not connected, the message is put on the backout
queue, if one is defined for this input queue, or the queue manager’s
dead-letter queue (DLQ), if a backout queue does not exist.

56 WebSphere® MQ Integrator: Introduction and Planning

 What is a message processing node?
If the queue manager does not have a DLQ defined, the message is left on
the input queue. (If the broker’s queue manager has been created by the
create broker command mqsicreatebroker, a DLQ has been defined and
enabled for this queue manager.)
– If the catch terminal is not connected and the message is not being processed
under transactional control, the message is discarded.

For more information about message processing under transactional control, see
“Transaction support” on page 83.

You can provide a minimum level of error handling within every message flow
you define if you choose. This minimum level might include:
v Define a dead-letter queue (DLQ) on the broker’s queue manager (or use the
default supplied DLQ).
v Change the queue manager’s attributes to use this DLQ.

For details of incorporating more sophisticated error handling, for example, the use
of the TryCatch node, see WebSphere MQ Integrator Using the Control Center.

Chapter 4. Message flows 57

What is an execution group?

What is an execution group?

The broker provides the run-time environment for a set of deployed message
flows: this environment is called an execution group. An execution group provides
an isolated execution environment, because each is started as a separate operating
system process.

One execution group, the default execution group, is set up ready for use
whenever you create a broker. By setting up additional execution groups, you can
isolate message flows that handle sensitive data such as payroll records, or security
information, or unannounced product information, from other nonsensitive
message flows.

For example, you might want to set up one execution group to support a
connected set of applications and their messages, and a second execution group for
another distinct set of applications and their messages.

The broker guarantees operating isolation of each execution group, thus

guaranteeing data integrity between execution groups, and improving robustness
of message flows.

Within an execution group, the assigned message flows run in different thread
pools. You can specify the size of the thread pool (that is, the number of threads)
that are assigned for each message flow by specifying the number of additional
instances of each message flow (this is also discussed in “Parallel processing of
message flow instances” on page 51).

If you create additional execution groups, you must give each group a name that is
unique within the broker, and assign and deploy one or more message flows to
each one.

You do the creation, deployment, and assignment (of message flows and threads
for the message flows) using the Control Center.

58 WebSphere® MQ Integrator: Introduction and Planning

 Message flows and message sets

Message flows and message sets

When you have created your message flows using the Control Center, you must
assign them to the brokers on which you want them to run, again using the
Control Center. Their assignment and subsequent deployment prompts the
Configuration Manager to send data and control information to the broker,
enabling it to load and execute the code contained within the message flow.

The same message flow can be assigned to any number of brokers, perhaps for
workload distribution. Similarly, a number of different message flows can be
assigned to the same broker.

However many message flows a broker hosts, the broker needs access to the
definitions of your predefined (that is, not self-defining) messages expected or
generated by those message flows.

Therefore if you assign a message flow that uses predefined messages to an

execution group, you must also assign one or more message sets to that broker, to
ensure the details of the messages are available when the message flow executes.

The message sets are assigned and deployed to the broker, but message flows are
assigned and deployed to an individual execution group.

The relationship between message flows and message sets is unlikely to be one to
one. You are very likely to have a number of related message flows executing in
one broker that use some or all of the same message sets.

For further details about messages and message sets, and how you define them,
refer to Chapter 5, “Messages” on page 69.

Chapter 4. Message flows 59

Publish/subscribe services

Message flows for publish/subscribe services

WebSphere MQ Integrator supports message flows that provide publish/subscribe
services. If you define a message flow to support publish/subscribe, you must:
v Define the publish/subscribe topology that identifies a broker’s neighbors, to
which publications are propagated, using the Control Center. A publication is
only routed to a broker if there is a subscriber at that broker who has registered
an interest in the topic of that publication.
v Include a Publication node as the last message processing node in at least one
path through the message flow. A message flow can have a path in which the
end node is a Publication node as well as a path in which the end node is an
output node. It is also possible to have more than one Publication node or
output node on each path.
This node handles published messages by forwarding them on to all registered
subscribers, that is to applications that have registered an interest on the topic,
or content, or both, of the message at this node.

To support publish/subscribe applications, you must define at least one message

flow as described above, and design applications that publish to the input queue
of the publish/subscribe message flow (the publication queue, identified by the
input node) and applications that register subscriptions for the published
messages.

You can increase the throughput of this publish/subscribe message flow from
publication queue to subscribers by increasing the number of instances of that
message flow operating in the execution group. You can also deploy the same
message flow to multiple brokers, as you can with any message flow.

For more information about publish/subscribe processing, see Chapter 7,

“Designing publish/subscribe applications” on page 89.

60 WebSphere® MQ Integrator: Introduction and Planning

 Supplied message flows and nodes

Supplied message flows and nodes

WebSphere MQ Integrator includes a number of message processing nodes and
message flows that you can use.

Primitive node types

Message processing nodes perform the real work of handling the message within
the message flows deployed to the broker. WebSphere MQ Integrator incorporates
a set of node types that provide basic out-of-the-box message processing function.
These are known as the primitive node types, and can be considered in the
following categories:
v Receiving and routing messages
v Transforming a message to an alternative representation
v Selecting a message for further processing based upon the message’s content
v Interacting with an external repository to augment a message or store the whole
or part of a message
v Responding to events and errors

Receiving and routing

Label Provide a target for routing from the RouteToLabel node. The identity of
the Label node is used to match message content and thus determine the
route a particular message takes at a particular point in the message flow.
FlowOrder
Define the exact order in which subsequent subflows in the message flow
are executed. The order is normally unpredictable: you can use this node
to force one particular path to process the message before another path.
MQeInput
Allows MQSeries Everyplace clients to connect and propagate messages
into the broker using an MQSeries Everyplace queue, and retrieve
messages from the MQSeries Everyplace queues. You must use this node
for MQSeries Everyplace input, you cannot replace this with your own
input node. This node is not available on z/OS.
MQeOutput
Write the current message to the MQSeries Everyplace queue specified by
the node properties, or defined by a destination list associated with the
message, or to the reply queue specified in the message header. This node
is not available on z/OS.
MQInput
Read the next message from the input queue and establish the processing
environment for this message (for example, the transactional context). You
cannot replace this node with your own input node.
MQOutput
Write the current message to the queue specified by the node properties, or
defined by a destination list associated with the message.
MQReply
Write the current message to the reply queue defined by the message’s
header or the node properties.
NEONRulesEvaluation
Invoke the New Era of Networks Rules engine. This provides routing
function defined by the New Era of Networks Rules GUI.

Chapter 4. Message flows 61

Supplied message flows and nodes
Note that the New Era of Networks nodes cannot be used unless the New Era of
Networks Rules and Formatter Support component is installed.
NeonRules
Invoke the New Era of Networks Rules engine. This provides routing
function defined by the New Era of Networks Rules GUI.
Note that the New Era of Networks nodes cannot be used unless the New Era of
Networks Rules and Formatter Support component is installed.
Publication
Deliver the message to a set of MQSeries, MQSeries Everyplace or SCADA
subscribers that are defined in the subscription table and have a
subscription for the node’s subscription point. This node also stores retained
publications when appropriate.
RouteToLabel
Interrogate the destination list in the message to determine the identity of
the Label node within the current message flow to which the message
must be sent for processing. You can create or modify a destination list
within the Compute node.
SCADAInput
Allows clients that use the MQIsdp protocol (see the WebSphere MQ
Integrator Programming Guide for details) to publish and subscribe to the
information within a publication node using the port specified within this
node. This node is not available on z/OS.
SCADAOutput
Write the current message to all the subscribed SCADA clients defined by
the destination list associated with the message. This node is available, and
typically used, as a sub-node within the Publication node. You should use
it as a stand-alone node only in advanced solutions where the normal
publish/subscribe environment is not suitable. This node is not available
on z/OS.

Message transformation
Compute
Derive an output message from the contents of an input message.
Output message elements (including destination lists and exception lists)
can be defined using expressions, defined in ESQL, based on input
message elements and external data sources. The expressions can use
arithmetic operators, text operators (for example, concatenation), logical
operators, and other built-in functions.
The subset of ESQL operations you can specify in this node is described in
WebSphere MQ Integrator ESQL Reference.
The output message can inherit all the headers associated with the input
message, or the node can be set up to select a subset of those headers for
the input header, or to insert a new header (or headers), replacing the
input message headers.
The Compute node can be used to make a copy of a message (that is,
duplicate the message), prior to manipulating the message content.
Extract
Create a new message from the input message using only specified
elements. Any elements from the input message that are not specified for
the output message are discarded. This is a specialized form of Compute.

62 WebSphere® MQ Integrator: Introduction and Planning

 Supplied message flows and nodes
NEONTransform
Invoke the New Era of Networks Formatter to map and transform
(reformat) a message from a known input format to a specified output
format. For details, see New Era of Networks Rules and Formatter Support for
WebSphere MQ Integrator Formatter Programming Reference. The message
definitions and transformations are defined using the New Era of
Networks Formatter GUI.
Note that the New Era of Networks nodes cannot be used unless the New Era of
Networks Rules and Formatter Support component is installed.
NeonFormatter
Invoke the New Era of Networks Formatter to transform a message from a
known input format to a specified output format. The message definitions
and transformations are defined using the New Era of Networks Formatter
GUI (a method of defining messages provided in addition to the Control
Center).
Note that the New Era of Networks nodes cannot be used unless the New Era of
Networks Rules and Formatter Support component is installed.
NEONMap
This node provides the map function of the NEONTransform node, but no
output operations are carried out.
Note that the New Era of Networks nodes cannot be used unless the New Era of
Networks Rules and Formatter Support component is installed.
ResetContentDescriptor
Reparse the bit stream of an input message. This node provides equivalent
function to an MQOutput node followed by an MQInput node. It allows
the message to be interpreted by an additional message parser within a
single message flow.

Selecting a message based on content

Check
Test one or more of the message properties within the message template.
The exact nature of the test is defined by the node properties.
The Check node validates the message properties in the message header
against values specified in the node: it does not check the message body. If
the test fails, the message is passed to the failure terminal.
Filter Route the message according to message content, using a filter expression
specified in ESQL. In addition to including elements of the message or
message properties, the filter expressions can also reference data held in an
external database.
The rich subset of ESQL operations you can specify in this node is
described in WebSphere MQ Integrator ESQL Reference.

Interacting with an external database

Database
Modify the content of one or more database tables using a specified ESQL
expression. The expression can contain elements derived from the input
message. The input message is propagated along the message flow without
change. The Control Center provides customized nodes for simple tasks

Chapter 4. Message flows 63

Supplied message flows and nodes
such as inserting a single row into a table (DataInsert), updating a single
row in a table (DataUpdate), and deleting a single row from a table
(DataDelete).
The rich subset of ESQL operations you can specify in this node is
described in WebSphere MQ Integrator ESQL Reference.
Warehouse
Write a message to a data warehouse. This is a specialization of the
Database node that inserts a single row into the specified database table,
and provides additional options for time-stamping the message and
including the entire message content as a BLOB.

Recording and responding to events and errors

TryCatch
Provide a special handler for exception processing. The input message is
initially propagated on this node’s try terminal. If an exception is thrown
by a downstream node it is caught by this node, which then propagates
the original input message on its catch terminal.
Throw
Provide a means to throw an explicit exception in a message flow.
Trace Write a specified expression (that can include the content of the fields in
the message) to the user trace log, or to a file specified as a property of the
node.

Supplied message flows

A set of message flows are supplied with WebSphere MQ Integrator. These are in
two broad categories:
Default message flows
The Version 1 Migration/Compatibility flow for WebSphere MQ
Integrator Version 2.1.
This message flow can be deployed in any Version 2.1 broker in
your broker domain to provide equivalence to an MQSeries
Integrator Version 1.1 daemon. It incorporates the
NEONRulesEvaluation node to process messages according to the
rules engine. An input node, to read messages from an input
queue, and a set of output nodes, that provide failure, no-hit and
process action functions, are connected to the
NEONRulesEvaluation node.
The publish/subscribe message flow
This message flow provides the simplest message flow processing
that provides a publish/subscribe service. It emulates exactly the
basic publish/subscribe function supported by the MQSeries
Publish/Subscribe SupportPac, and is equally appropriate for all
publish/subscribe services in which no additional processing of the
message content is required.

64 WebSphere® MQ Integrator: Introduction and Planning

 Supplied message flows and nodes
Installation verification message flows
The ScribbleInversion message flow
This is the message flow required by the Scribble application,
described in the WebSphereMQ Integrator Installation Guide for your
product.
The Soccer message flow
This is the message flow required by the Soccer Results Service,
described in the WebSphereMQ Integrator Installation Guide for your
product.
The Postcard message flow
This is the message flow required by the Postcard application,
described in the WebSphereMQ Integrator Installation Guide for your
product.

The definitions of these message flows are provided in the import file
SamplesWorkspaceForImport. The import file PostcardMS.mrp provides the
definitions for the message set required by the Postcard message flow. Each
WebSphereMQ Integrator Installation Guide describes the Installation Verification
Program (IVP) message flows and message set in detail, and tells you how to
import the supplied files and save the definitions for future use. WebSphere MQ
Integrator Using the Control Center provides more information about the default
message flows, and guidelines for using them.

A collection of sample business scenarios is available by downloading the

MQSeries SupportPac IC03 from the MQSeries product family web site. See
“MQSeries information available on the Internet” on page 208 for more
information.

Chapter 4. Message flows 65

Adding message processing nodes

Adding or enhancing message processing nodes

WebSphere MQ Integrator provides an external interface that allows you to add
new capabilities to the broker by implementing new node types. The interface
comprises a set of calls implemented in the C or Java language. These calls are of
two kinds:
v Calls that the broker makes to the node, for example to initialize the node.
v Calls that the node makes to the broker, for example, to inquire about the
content of the message being processed.

Examples of additional node types include:

v A timer node, that re-invokes itself periodically at a set timer interval, to
perform a series of actions before passing the message on to the next node in the
message flow.
v Reading one or more records from a specified data file: this node type might be
used in conjunction with a timer node to provide a mechanism for performing
batch processing at predetermined intervals, or times of day.
v Raising events that get displayed in a systems management console.
v Retrieving a message from a different source, by using your own input node.

You can find more details about this facility in Chapter 11, “Enhancing your broker
domain” on page 163. The implementation details of the system programming
interface are given in the WebSphere MQ Integrator Programming Guide.

Message flow porting issues

The following ’porting issues’ need to be considered when deploying existing
message flow to a z/OS broker:

DB2
v Table and Column names cannot be greater than eighteen characters.
v Trigger and Constraint names cannot be greater than eight characters.
v SQL batch jobs that have been run in a distributed DB2 environment must be
reviewed and revised. This is because some Data Definition Language (DDL)
and Data Manipulation Language (DML) commands and statements are
inappropriate or incorrect for DB2 running on z/OS.

Queue Manager and Queue names

v The Queue Manager name cannot be greater than four characters.
v All Queue names should be in upper case. Although the use of quotes preserves
the case, certain z/OS MQ activities cannot find the queue names being
referenced.

File system references

v File system references must reflect a UNIX file path, unlike Windows which
would be DOS based. This is not an issue for message flow already deployed to
UNIX brokers on AIX, Sun Solaris or HP-UX.

66 WebSphere® MQ Integrator: Introduction and Planning

 Debugging message flow problems

Using the Debugger to solve message flow problems

The Control Center provides facilities that help you to validate that a message flow
is performing the desired actions under all conditions, and determine the cause of
unexpected processing within a message flow. As well as user tracing and trace
nodes, you can use the Debugger, which is presented as an alternative screen
under the Message Flows view of the Control Center.

The Debugger lets you define break points within a message flow. When a break
point is encountered during message processing, control is returned to you, and
you can then inspect and modify the message contents. This helps you to analyze
and solve unexpected situations with message flows, such as:
v Wrongly connected nodes, such as outputs connected to incorrect inputs
v Filter nodes with incorrect conditions
v Compute nodes with incorrect logic
v Database nodes making incorrect entries into their target databases
v Incorrect messages generated by applications, or having contents that the
message flow does not expect
v Feedback loops that are never exited
v User-programmed plug-in nodes that contain errors, or are not reentrant

An example use of the Debugger is to track a single message through a message

flow one step at a time. Another example is to put a breakpoint on a filter output,
triggered by an erroneous message; there might be hundreds of messages
generated by the input application before the bad message occurs and triggers the
breakpoint.

Full details of the Debugger are provided in WebSphere MQ Integrator Using the
Control Center. More information on solving problems is given in the WebSphere
MQ Integrator Problem Determination Guide.

Chapter 4. Message flows 67

Debugging message flow problems

68 WebSphere® MQ Integrator: Introduction and Planning

Chapter 5. Messages
Data is generated and distributed through your broker domain in the form of
messages. This chapter describes the messages that WebSphere MQ Integrator
supports, and how they are interpreted by the message flows.
v “Predefined and self-defining messages”
v “Using message templates and messages” on page 73
v “Message parsers” on page 74

Predefined and self-defining messages

The format and content of each message has to be known by the process that is
constructing or examining it. In WebSphere MQ Integrator, messages are always in
one of two broad categories:

Predefined Messages

The content of a predefined message is described by the message template.

Predefined messages are stored in the message repository, which is created and
maintained in your database to hold all message templates in the broker domain.
The message repository is managed by a component within the Configuration
Manager known as the Message Repository Manager (MRM).

Self-defining Messages

The content of a self-defining message is described by the message itself.

A self-defining message uses the XML standard to structure its content. XML is an
open messaging standard, providing a cross-platform portable mechanism for
exchanging data. XML refers to a family of specifications based on a tagged
message format for metadata. The tag language has been developed from older
markup standards including GML and SGML.

XML definitions for specific business objects (for example, messages used by EDI
or financial applications) are grouped using “schemas” or document type definitions
(DTDs).

The XML standard is fast-growing, and is being adapted to, and supported by,
increasing numbers of products. WebSphere MQ Integrator’s ability to support it is
therefore critical to providing comprehensive business integration.

For up-to-date information about XML, and further references, see the IBM Web
site:
http://www.ibm.com/developer/xml

JMS messages are also identified by the XML domain. You can use self-defining
JMS messages in exactly the same way that you can use XML messages.

© Copyright IBM Corp. 2000, 2002 69

Predefined messages
Predefined messages using the MRM
A message can be considered in two ways:
v It has a logical structure. This defines the contents of the message using a tree
structure that identifies each field and its relation to other fields. For example, a
message might contain the following three fields:
AccountNumber
AccountName
AccountBalance
v It has a physical structure, also known as a wire format. The applications
sending and receiving messages like this understand this format, and the type of
each field. WebSphere MQ Integrator supports several wire formats (described
below).

The Control Center provides the main Graphical User Interface (GUI) for message
definition and management.

You can define messages and their content and structure to the MRM within
message sets. Message sets keep the individual message templates linked together,
and simplify their administration and distribution.

The MRM supports the following wire formats:

CWF Custom Wire Format, for messages exchanged by applications that use C
or COBOL data structures.
XML Supporting the XML standard and DTDs.
TDS Tagged delimited strings with preset values for the S.W.I.F.T. (ISO 15022),
EDI (EDIFACT and X.12 (ISO 9735)), ACORD AL3, and customer-written
message formats.
PDF Portable data format, the native format of the GOLD messaging standard
used in financial messaging applications. It is specific to the Control Center
and the message repository, and has no relation to Adobe’s Portable
Document Format, also known as PDF.

This rich level of support allows you to create, manipulate, and manage a wide
variety of messages encompassing many of the industry standards of today.

You can use the MRM to model XML, JMS, and tagged or delimited messages. You
can then use the model to define the message processing that your message flows
will perform on these messages.

The MRM also provides the ability to base messages on existing messages, and to
control any updates on the underlying message model.

Message templates
The message model in the MRM is defined by the following four values that make
up the message template:

The message domain describes the source of the message definition:

MRM Identifies messages that are defined using the Control Center, or are
imported
NEONMSG and NEON
Identifies messages that are defined using the New Era of Networks user
interfaces

70 WebSphere® MQ Integrator: Introduction and Planning

 Message templates
XML Identifies self-defining messages, including JMS messages
BLOB Identifies messages that have no defined format

The message set identifies the grouping of messages within the message domain,
as you have defined it. Typically, a message set contains a number of related
messages that provide the definitions required for a specific business task or
application suite.

The message type identifies the message.

The message format describes the wire format of the message; its physical
representation in the bit-stream.

The message type identifier refers to a message structure that is made up of

elements that define the business purpose of your message (for example an
Account Number). The elements must all have a defined type, either a simple type
defined by the MRM itself, or a compound type that you create to build up a more
complex element.

The simple types are:

v BINARY
v BOOLEAN
v DATETIME
v DECIMAL
v FLOAT
v INTEGER
v STRING

For further details of the message model, see the WebSphere MQ Integrator Working
with Messages book.

Using predefined messages

When you have created message definitions, you must distribute them to the
brokers through which your applications exchange messages. This is known as
deployment.

If you have messages that are already defined within another message repository
(MRM), you can do one of the following:
v Use the command, mqsiimpexpmsgset, that is provided by WebSphere MQ
Integrator, to import or export whole message sets.
v Export these messages to C or COBOL format and use the Control Center to
import the headers or copybooks created into your WebSphere MQ Integrator
environment.
v Provide a parser that interprets these messages. For more details, see “Creating
additional parsers” on page 76.

To get full integration across your enterprise, you might need a variety of message
templates. For example:

Internally defined messages

You can define your own standards for messages between newly developed pieces
of software. For example, messages of this type can contain XML.

Chapter 5. Messages 71
Message templates
Legacy message formats

These are determined by the legacy applications themselves. They include, for
example, COBOL record structures used for interacting with CICS or IMS
applications. Other examples are 3270 data-streams and other forms of screen map.

Inter-enterprise message sets

For example, EDI.

Java message formats

Defined by JMS.

Your application programmers create and receive messages based on the message
type, the environment the programmer is working in, and the language that the
programmer is using. For example, a COBOL programmer manipulates a message
as a COBOL data structure, and a Lotus Notes™ programmer views it as a Notes
document.

New Era of Networks format messages

If you have existing MQSeries Integrator Version 1 messages, or plan to create new
messages using New Era of Networks formats, or both, you can use these
messages by defining message flows that include the NeonFormatter, NEONMap,
NeonRules, NEONRulesEvaluation and NEONTransform, and message processing
nodes. For more details about using New Era of Networks format messages, see
the WebSphere MQ Integrator Working with Messages book.

You can use the New Era of Networks Formatter interface, (accessible through the
Control Center, or directly), to view these existing messages and to create new
message formats. For more information, refer to the New Era of Networks Rules and
Formatter Support for WebSphere MQ Integrator User’s Guide. You cannot edit New
Era of Networks messages using the Control Center, you can only view them. You
must use the New Era of Networks Formatter to edit New Era of Networks
messages.

How messages are processed in a message flow

The characteristics of MQSeries messages are identified by the input node of a
message flow in the following ways:
v If the message has an MQRFH or MQRFH2 architected header, the input node
checks values in that message header.
See the WebSphere MQ Integrator Programming Guide for more details about the
content and use of these headers.
v If the message does not have an MQRFH or MQRFH2 header, the input node
uses the default message template, defined as a property of the input node, to
determine how the message must be parsed.
v If the header immediately preceding the message body is recognized, it is
examined to check for a supported value in the format field.

The SCADAInput node creates messages with MQRFH2 headers from the
messages received by the listener on the TCP/IP port.

In publish/subscribe message flows, the MQeInput node creates messages with

MQRFH2 headers from the messages received by the listener on the TCP/IP port.

72 WebSphere® MQ Integrator: Introduction and Planning

 How messages are processed
In non publish/subscribe message flows, the MQeInput node action depends on
the type of message received by the listener on the TCP/IP port:
MQeMsgObject
For MQeMsgObject messages, the MQeInput node creates MQSeries
messages with an MQRFH2 header, and the whole dumped-data
representation of the message is copied into the message payload.
MQeMbMsgObject
For MQeMbMsgObject (message broker) messages, the MQeInput node
creates MQSeries messages with an MQRFH2 header. The fields defined in
the MQeMbMsgObject class are available inside the broker; all other fields
are discarded.

Exporting and importing MRM message sets

You can export the MRM message sets you have created in the message repository
using a command provided by WebSphere MQ Integrator. This command,
mqsiimpexpmsgset, works on whole message sets (that is, you cannot export an
individual message within the message set) and generates an XML file that
contains the message set definition for the message repository (export) or reads an
XML file and creates a definition for message repository (import).

The Control Center does not provide import or export functions for message sets,
you must use the command. See the WebSphere MQ Integrator Administration Guide
for further information.

Using message templates and messages

You must make the information about your predefined message templates and
messages available in the broker domain, where it is needed: that is, in any broker
that hosts message flows that use these particular templates.

When you develop the topology of your broker domain using the Control Center,
you make decisions about which message flows run on which brokers, and
therefore need to decide at the same time which message templates are required by
each broker.

If you define message templates using the Control Center, you specify the message
sets that are required at each broker by assigning them to that broker, in the same
way that you assign the message flows that are to be executed in that broker. You
do this using the Control Center.

When you have made these decisions, you must update the repository with your
changes, by checking in all the resources you have been working with. You must
then request that these changes are propagated as required through the broker
domain. This function, known as deployment, is handled by the Configuration
Manager when you request the deploy using the Control Center.

Each message set is sent to the broker in the form of a message dictionary, which
allows the broker to interpret the messages it receives. Each broker can manage a
number of message dictionaries concurrently. You can’t modify dictionaries in the
broker directly. However, you can delete and add message sets using the Control
Center, and deploy the updated configuration, which achieves the same result.

Chapter 5. Messages 73
Using messages
If you create new message sets, or modify existing ones, you can assign and
deploy these through the Control Center. Message flows can access new message
dictionaries when the broker has implemented these changes.

If you define message templates using the New Era of Networks Formatter, you
must make these available to the broker by setting values in the configuration file
located by the NN_CONFIG_FILE_PATH environment variable. If you update
these message templates, you must force the New Era of Networks nodes in the
message flows to re-access the database by stopping and restarting the broker.

See WebSphere MQ Integrator Working with Messages for details of creating messages
and see WebSphere MQ Integrator Using the Control Center for details of assigning
message sets to brokers.

If you are using self-defining messages you do not have to distribute message
template information to brokers.

Client access to messages

Client applications also need access to message definitions to be able to construct
messages they send, and interpret messages they receive.
v If the message formats in the message repository have been imported from C or
COBOL structures using the Control Center, your applications can continue to
use the same C and COBOL data structures that were imported to create the
message dictionary (that will be used by the brokers).
v If the messages are defined to the New Era of Networks Formatter, you must
ensure the clients have access to the database in which the formats are stored (a
local or remote connection is valid).
v If the messages are self-defining XML, the client applications must construct
valid messages using structures that can be understood by the recipients of the
message.

Message parsers
WebSphere MQ Integrator can handle any message template for which a suitable
parser is available. The parsers interact with the message templates stored in
message dictionaries or interpret self-defining messages on receipt. You can extend
the range of messages supported by creating your own message parsers.
WebSphere MQ Integrator provides an external interface to enable you to do this.

Default message parsers

A number of parsers are included with WebSphere MQ Integrator. These can be
considered in two broad groups, depending on the source of the message
definitions.
Messages managed using the Control Center
When you use the Control Center to define new messages and message sets,
the Control Center and Configuration Manager accept, check, and maintain
the definition of these messages in the broker domain’s message repository.
When a message set is assigned to a broker, the information passed to the
broker allows it to determine correct use of them (and therefore correct
message manipulation) by the message flows.
Record-oriented data structures
If you want to communicate with existing applications that generate

74 WebSphere® MQ Integrator: Introduction and Planning

 Message parsers
messages by overlaying a data structure (typically COBOL or C) on
an array of bytes, you need a definition for these that can be
interpreted by the parsers.
You can achieve this by:
v Creating or purchasing a plug-in to construct and parse the
messages. See “Creating additional parsers” on page 76 for further
information about plug-in facilities for message parsers.
v Using the Control Center to import data structures created using
any other method. See WebSphere MQ Integrator Using the Control
Center for full details of import options.
XML and JMS messages
You can define messages to the message repository with a wire
format of XML. Their format is specific to the Control Center, and the
DTD for these messages is controlled by the MRM.
Tagged or delimited messages
You can also define messages to the message repository with a wire
format of TDS. These might have preset values for the S.W.I.F.T. (ISO
15022), EDI (EDIFACT and X.12 (ISO 9735)), or ACORD AL3 message
formats.
All other messages
Messages not managed by the Control Center and Configuration Manager
are also supported. These include:
Generic XML
The broker performs simple content-based routing and manipulation
on any well-formed XML or JMS message. These messages are treated
as self-defining, so no schema is required. The message content can
be manipulated, but no validation of the resulting message content is
possible
Message formats defined in the New Era of Networks dictionary
If you already have messages defined using the New Era of Networks
tools, you can continue to use these formats: WebSphere MQ
Integrator correctly parses these formats. You can add new formats to
your existing ones by using the New Era of Networks Formatter
interface.

Any other message, for which no parser can be identified (either because the
format field in the immediately preceding header is not set, or is set to an
unknown value), is handled as a BLOB and managed by the BLOB parser. That is,
the remaining body of the message is passed through the message flow intact, and
the content is left untouched. A message flow that receives a BLOB message
therefore can’t perform content-based routing or message transformation. However,
the message can be stored in a database, be routed according to topic, or have
headers added or removed. Limited message manipulation is possible if the
message content is predictable.

Parsers are also provided in the product for the following headers:
v MQCFH (the programmable command format (PCF) headers).
v MQCIH (the CICS bridge header).
v MQDLH (the DLQ header).
v MQIIH (the IMS bridge header).
v MQMD (message descriptor).
v MQMDE (message descriptor extension).

Chapter 5. Messages 75
Message parsers
v MQRFH and MQRFH2 (rules and format headers).
v MQRMH (reference message header).
v MQSAPH (the SAP link header).
v MQWIH (the workload information header).
v SMQ_BMH (the SAP link bad message header).

The broker needs to deal with all messages in a general way, and therefore it does
not handle the sequence of bytes directly but instead references syntax elements
around which it navigates to deduce the structure of the message. This
implementation allows parsers to navigate the message tree structure, in any way.
For example, a parser can access an element’s parent, or its children or siblings.
Other functions allow manipulation of the elements themselves, for example to set
or query the values, to insert new elements into the tree or to remove elements
from the tree.

Refer to the WebSphere MQ Integrator Working with Messages book for more detailed
information about how parsers work with messages.

Creating additional parsers

You can create additional parsers if you need to process messages (bit-streams) that
don’t fit into the categories of messages supported by the default parsers for some
reason.

WebSphere MQ Integrator provides a system programming interface, in the C

language, that allows you to construct a parser to work with message processing
nodes.

You can use your new parsers with existing message processing nodes (that is,
those provided by WebSphere MQ Integrator) and with your own additional
plug-in message processing nodes.

You’ll find further information about using this interface in Chapter 11, “Enhancing
your broker domain” on page 163. Implementation details of the programming
interface are in the WebSphere MQ Integrator Programming Guide.

76 WebSphere® MQ Integrator: Introduction and Planning

Part 3. Application planning
Chapter 6. Application design . . . . . . . 79 Example . . . . . . . . . . . . . 94
Communication models . . . . . . . . . . 79 Filters . . . . . . . . . . . . . . . 94
Point-to-point communications . . . . . . . 79 Local subscriptions . . . . . . . . . . . 95
Publish/subscribe communications . . . . . 80 Retained publications . . . . . . . . . . 95
Application programming . . . . . . . . . 80 Publish on request only . . . . . . . . 95
Application programming interfaces . . . . . 80 New publications only. . . . . . . . . 95
Message headers . . . . . . . . . . . 81 Message persistence . . . . . . . . . . 95
MQSeries queues . . . . . . . . . . . 82 Topics . . . . . . . . . . . . . . . . 96
Message order . . . . . . . . . . . . 82 Special characters in topics . . . . . . . . 97
Publish/subscribe . . . . . . . . . . 83 The topic level separator . . . . . . . . 97
Transaction support . . . . . . . . . . 83 The multi-level wildcard . . . . . . . . 97
Message persistence . . . . . . . . . . 84 The single-level wildcard . . . . . . . . 97
Security . . . . . . . . . . . . . . 85 Topic semantics and usage . . . . . . . . 98
Reusing existing applications . . . . . . . . 85 Using wildcards with topics . . . . . . . . 98
Send and forget . . . . . . . . . . . . 86 Multiple topics . . . . . . . . . . . . 99
Request/reply . . . . . . . . . . . . 86 Broker networks . . . . . . . . . . . . . 99
Publish/subscribe . . . . . . . . . . . 87 Collectives . . . . . . . . . . . . . 100
Writing new applications . . . . . . . . . . 87 How publications and subscriptions flow through
Summary . . . . . . . . . . . . . . . 88 the network . . . . . . . . . . . . . . 100
Topic-based security . . . . . . . . . . . 101
Chapter 7. Designing publish/subscribe Principals and the User Name Server . . . . 101
applications . . . . . . . . . . . . . . 89 Access control lists . . . . . . . . . . 101
How publish/subscribe applications interact with a Resolving ACL conflicts . . . . . . . . 101
broker . . . . . . . . . . . . . . . . 89 PublicGroup authorizations. . . . . . . 102
Publications . . . . . . . . . . . . . . 90 mqbrkrs authorizations . . . . . . . . 102
Retained publications . . . . . . . . . . 90 ACLs and system topics . . . . . . . . 103
State and event information . . . . . . . 90 Setting access control on topics . . . . . 103
Using retained publications . . . . . . . 91 Inheritance of security policies . . . . . 103
Local and global publications . . . . . . . 92 Dynamically created topics . . . . . . . 104
Global publication . . . . . . . . . . 92 ACLs and wildcard topics . . . . . . . 104
Local publication . . . . . . . . . . 92 ACLs and subscription resolution . . . . 105
Conference-type applications . . . . . . . 92 Activating topic ACL updates . . . . . . 105
Subscriptions . . . . . . . . . . . . . . 92 Checking publications and subscriptions . . . 105
Subscription points . . . . . . . . . . . 93 The publisher . . . . . . . . . . . 105
The default subscription point . . . . . . 93 The subscriber . . . . . . . . . . . 105
Using subscription points. . . . . . . . 94 Summary. . . . . . . . . . . . . . . 106

The information here is an introduction to the detail in the WebSphere MQ

Integrator Programming Guide.

© Copyright IBM Corp. 2000, 2002 77

78 WebSphere® MQ Integrator: Introduction and Planning
Chapter 6. Application design
This chapter introduces the main aspects of application design that you need to
consider for your particular environment and applications.

This chapter covers:

v “Communication models”
v “Application programming” on page 80
v “Reusing existing applications” on page 85
v “Writing new applications” on page 87
v “Summary” on page 88

If you are writing publish/subscribe applications, refer to Chapter 7, “Designing

publish/subscribe applications” on page 89 for additional information.

Communication models
WebSphere MQ Integrator supports two general application communication
models; point-to-point and publish/subscribe. These two models, introduced in
Chapter 2, “WebSphere MQ Integrator overview and concepts” on page 9, are
explored in more detail in this chapter and the next.

In point-to-point, one application sends messages to a queue associated with an

input node of a message flow, such as MQInput. After processing by the nodes in
the message flow, the resultant message is sent directly to the receiving
application’s queue by an output node, such as MQOutput.

In publish/subscribe, one application (the publisher) sends messages to a queue

associated with an input node of a message flow that contains a Publication node.
Another application (a subscriber) can send a subscription request to the broker,
which then sends relevant publication messages to the subscriber’s queue.
However, with SCADA applications the source of the message for publication is
the port that the SCADAInput node is listening to.

A single application can also mix the two styles, if appropriate. In this case the
message flow contains at least one output node and at least one publication node
(in addition to one or more input nodes). The retail scenario introduced in
Chapter 3, “WebSphere MQ Integrator: a business scenario” on page 41 is
implemented using the two styles. This scenario, and others, are available by
downloading the MQSeries SupportPac IC03. For information about the MQSeries
product family web site, see“MQSeries information available on the Internet” on
page 208.

This broad application support enables you to exploit your existing MQSeries,
MQSeries Everyplace, and SCADA clients and applications, and to develop new
applications to take advantage of the more advanced features of WebSphere MQ
Integrator. Both existing and new applications work together before and after a
broker is introduced into the network.

Point-to-point communications
Point-to-point applications exchange information with known partners. Each
application is aware of the identity of the one or more applications with which it is

© Copyright IBM Corp. 2000, 2002 79

Communication models
communicating. In some cases, messages are sent from one application to another,
but no response is required. These are known as send and forget messages or
datagrams. In other cases, data exchange involves pairs of messages sent as requests
and replies. This is called request/response messaging.

Your existing applications written using the point-to-point model can run
unchanged in an WebSphere MQ Integrator environment. However, you should
check “Reusing existing applications” on page 85 for more detailed guidance.

You can enhance and extend your existing application function by using the
facilities of the broker to include additional partners. For example, an application
that handles similar data but in a different format can now participate, because the
original message can be transformed by the broker into the expected format,
without the sending or receiving application changing.

If you identify a message that needs additional application processing, you can
create another copy of the message in the message flow, and send it to a new
application developed to provide that processing. The original applications are
unaware of the new action on the message and continue to work unchanged.

Publish/subscribe communications
Some applications are not tied to particular partners. They deal with data and have
no specific requirements as to who is receiving that information, or where the
message comes from. The publish/subscribe model allows data to be made
available at any time, to whoever is interested at that time, without the sender or
receiver being aware of the other.

Messages published by any one publisher can be received by any number of

subscribers. Subscribers might also receive messages, on the same or different
topics, from any number of publishers.

Your existing applications written using MQSeries Publish/Subscribe can run

unchanged in an WebSphere MQ Integrator environment. However, you should
check “Reusing existing applications” on page 85 for more detailed guidance.

Application programming
This section discusses the following application programming topics:
v “Application programming interfaces”
v “Message headers” on page 81
v “MQSeries queues” on page 82
v “Message order” on page 82
v “Transaction support” on page 83
v “Message persistence” on page 84
v “Security” on page 85

Application programming interfaces

WebSphere MQ Integrator does not provide any new application programming
interfaces. Applications can be written to the existing Message Queue Interface
(MQI), Java Message Service (JMS), and Application Messaging Interface (AMI).

80 WebSphere® MQ Integrator: Introduction and Planning

 Application programming
If you need to write SCADA applications, you should refer to the SCADA device
protocol appendix in the WebSphere MQ Integrator Programming Guide, and for
MQSeries Everyplace applications refer to the MQSeries Everyplace appendix in
the same book.

The MQI provides a small number of calls that allow an application to interact
with other applications across an MQSeries network of queue managers. The calls
support a large range of parameters that allow a rich choice of processing options
for each and every message.

The JMS is a Java Messaging API developed by IBM and other messaging vendors,
in partnership with Sun Microsystems, Inc. It provides a common API to access
different enterprise messaging systems, such as MQSeries, through the Java
programming language. Two messaging models are provided: point-to-point and
publish/subscribe.

The AMI is designed to simplify the application programmer’s task, by centralizing

the selection of optional parameters outside the application program. It also
provides support for the more advanced functions available from the message
broker. The AMI is designed for general messaging applications whether a broker
is involved or not.

The principal functions of the AMI are administrator-defined packets of options

known as policies and services. An application specifies a service to determine the
underlying messaging support required, and associates a policy with sending or
receiving a message to control attributes for message processing, such as priority.

Client applications using the MQI can run on any supported MQSeries operating
system, and therefore any limitations as to language or function are defined by the
relevant product for that operating system.

Client applications using the JMS interface are written in the Java programming
language, and are therefore restricted to the levels of JVM that are supported on
the operating system in question. For further information, see the MQSeries Using
Java book, or visit the MQSeries Web site (identified in “MQSeries information
available on the Internet” on page 208).

Client applications using the AMI are restricted to the operating systems and
programming languages supported by this interface. Check the current level of the
MQSeries Application Messaging Interface book for details, or visit the MQSeries Web
site (identified in “MQSeries information available on the Internet” on page 208).

Message headers
WebSphere MQ Integrator supports applications that use different headers.

Messages begin with an MQSeries Message Descriptor, or MQMD. Defined by the

MQSeries products, this precedes user or application data in every message. The
MQMD contains basic control information that must travel with the message, such
as:
v The message identifier
v The destination of the reply, if one is to be sent
v Reply and report options (for example, confirm on delivery report)
v The format of any following data in the message

Chapter 6. Application design 81

Application programming
When a message is used in an WebSphere MQ Integrator system, it usually (but
not necessarily) has one or more additional headers. The header following the
MQMD is always identified in the format field within the MQMD, and itself
contains another format field to identify what follows.

The additional headers can include:

MQRFH
The Rules and Formatting header is used by MQSeries Integrator Version 1
applications and MQSeries Publish/Subscribe.
MQRFH2
The updated version of MQRFH allows Unicode strings to be transported
without translation, and it can carry numeric datatypes. The MQRFH2
header carries a description of the message contents, so that WebSphere
MQ Integrator can select the correct message parser when content-based
processing is carried out on the message. In addition, this header contains
publish/subscribe command messages. Messages created by the
SCADAInput node always have MQRFH2 headers.
Use the MQRFH2 header in all new applications written for the WebSphere
MQ Integrator environment. The MQRFH2 header should be immediately
before the body of the message.

MQSeries queues
WebSphere MQ Integrator uses a number of dedicated queues, defined by each
broker, the Configuration Manager and the User Name Server, for specific
functions. You can find a full list of these queues, and their purpose, in the
MQSeries MQ Integrator Installation Guide.

Application designers need to be aware of the system-defined queues with which

they need to interact: for example, the broker control queue for publish/subscribe
(SYSTEM.BROKER.CONTROL.QUEUE).

As you develop new applications, or integrate existing applications into your

broker environment, you must agree on a naming convention for the queues you
use for message exchange. (Input and output queues for point-to-point; input and
subscriber queues for publish/subscribe.) Make sure these names do not start with
the characters SYSTEM.BROKER, to avoid conflict with the system defined queues.

A subscribing application can specify a temporary dynamic queue as its subscriber

queue (the queue to which publications should be sent). In this case, the broker
automatically de-registers the subscription when the queue is deleted.

Message order
If message ordering is important, you can use the techniques recommended for all
MQI and AMI users. See the MQSeries Application Programming Guide for programs
written to the MQI, and MQSeries Application Messaging Interface for programs
written to the AMI. MQSeries Everyplace and SCADA applications use a different
method of message ordering — refer to the WebSphere MQ Integrator Programming
Guide for details.

82 WebSphere® MQ Integrator: Introduction and Planning

 Message order
If you have set the ‘Additional Instances’ property of a message flow to define
more than one instance of that message flow, you can use the ‘Order Mode’
property of each input node within that message flow to influence the order of
message processing by that node:
v If you set ‘Order Mode’ to ‘By User ID’, the node ensures that messages from a
specific user (identified by UserIdentifier field in the MQMD) are processed in
guaranteed order. A second message from one user is not processed by an
instance of the message flow if a previous message from this user is currently
being processed by another instance of the message flow.
v If you set ‘Order Mode’ to ‘By Queue Order’, the node processes one message at
a time to preserve the order in which the messages are read from the queue.
Therefore, this node behaves as though the ‘Additional Instances’ property of
the message flow is set to zero.

Publish/subscribe
Additional considerations apply to publish/subscribe applications. For any given
topic, messages are published by brokers in the same order as they are received
from publishers (subject to reordering based on message priority). This normally
means that each subscriber receives messages from a particular broker, on a
particular topic, from a particular publisher, in the order that they are published by
that publisher.

However, in common with all messages using the MQSeries transport layer, it is
possible for messages, occasionally, to be delivered out of order. This could
happen, for example, if a link in the network fails and subsequent messages are
routed via another link.

If you need to ensure the order in which messages are received, you can use either
the SeqNum (sequence number) or PubTime (publish time stamp) parameter on the
Publish command for each published message, to calculate the order of
publishing. Check the WebSphere MQ Integrator Programming Guide for details of
how to implement these message ordering techniques.

Transaction support
Message flows hosted by brokers might provide vital processing and data
manipulation that must have full transactional integrity. That is, the message flow
must complete all processing successfully, or must complete none. Any part of the
processing that completed successfully (for example, the reading of the input
message from the input queue) must be rolled back if there are problems that
prevent later processing from completing successfully.

If the message flow processing includes interaction with an external database, the
transaction can be coordinated using XA technology to assure all participants
update or return to a consistent state. This external coordination support is
provided by the underlying MQSeries facilities and the ODBC support provided
for the database. This level of XA support is only available if the database you are
using is DB2, Oracle, or Sybase.

An equivalent level of support is provided by IBM’s Resource Recovery Services

(RRS) with DB2 on z/OS.

WebSphere MQ Integrator provides the required level of transactional integrity in

several ways.
v You can specify that a message flow is to be fully globally coordinated, which
means that MQSeries itself is used as an XA Transaction Manager to coordinate

Chapter 6. Application design 83

Transaction support
the transaction associated with the message flow. The reading and writing of
MQSeries messages and all interactions with capable external databases are
coordinated in a single unit of work (UOW).
Fully globally coordinated transactions are only possible if the external databases
are DB2, Oracle or Sybase.
You must configure your external databases and MQSeries to enable this
support. All actions in the message flow therefore either complete successfully,
or are rolled back to the point where the original input message is restored on
the input queue (or in the DB2 table for SCADA message flows).
This feature is controlled using the ‘Coordinated Transaction’ property of the
message flow: the default is for the transaction not to be globally coordinated.
v A message flow that is not fully globally coordinated is said to be fully broker
coordinated by default. The reading and writing of MQSeries messages and
interactions with external databases are not coordinated within a single unit of
work (UOW). However, the message flow ensures that all database transactions
are committed automatically at the completion of processing a message through
that flow.
v A message flow can also be partially broker coordinated. This means that some
processing nodes commit their operation immediately, instead of waiting until
message flow completion as in a fully broker coordinated message flow. You can
specify property values on the nodes that interact with databases to allow their
processing to be committed immediately.
v In a fully globally coordinated or partially broker coordinated message flow, all
messages subsequently sent by any output node in the same instance of the
message flow are put under syncpoint, unless you set the output node
properties to explicitly override this. If you do this, then the message flow is
also be said to be partially broker coordinated.

You can mix these different transaction types by using different settings in multiple
nodes with one message flow. The WebSphere MQ Integrator Administration Guide
has details of how to work with transactions in this way.

Message persistence
MQSeries messaging products provide an additional level of support for message
integrity. This is message persistence, which defines the longevity of the message in
the system. Nonpersistent messages are lost in the event of system or queue
manager failure. Persistent messages are always recovered if a failure occurs.
SCADA applications use appropriate settings of quality of service instead of message
persistence.

Message persistence is controlled by these factors:

v The option specified by the application putting the message to the queue (using
the MQI or AMI calls)
v The default message persistence of the input queue, or the quality of service of
the SCADA message
v The action taken by a message processing node in the message flow
v The option specified by the output node’s persistence property
v The message persistence requested by the subscriber

When a message is read from an input queue by the input node, the default action
is to use the persistence defined in the MQSeries message header (MQMD), that
has been set either by the application creating the message, or by the default

84 WebSphere® MQ Integrator: Introduction and Planning

 Transaction support
persistence of the input queue. The message retains this persistence throughout the
message flow, unless it is changed in a subsequent message processing node.

You can override the persistence value of each message when the message flow
terminates at an output node. This node has a property that allows you to specify
the message persistence of each message when it is put to the output queue, either
as the required value, or as a default value. If you specify default, the message
takes the persistence value defined for the (one or more) queues to which the
messages are written.

If a subscriber has requested persistent message delivery, and is authorized to do

so by explicit or implicit (inherited) ACL, the message is delivered persistently
regardless of its existing persistence property. Also, if the user has requested
nonpersistent message delivery, the message is delivered nonpersistent regardless
of its existing persistence property.

Security
Access and authority requirements for MQSeries client applications to connect to
queue managers and use MQSeries resources are unchanged by the introduction of
WebSphere MQ Integrator into your application environment.

You must therefore ensure that applications are authorized to put messages to
input queues serviced by the message flow that provides the required processing,
and can get messages from the message flow output queues.

SCADA applications have less control over access, because any device can connect
using any client ID it chooses, and can therefore masquerade as an authorized ID.

For publish/subscribe applications, additional control is available to you. This is

defined in “Topic-based security” on page 101.

Reusing existing applications

Existing MQSeries applications are supported unchanged by WebSphere MQ
Integrator. The broker can be added into an existing MQSeries network, and
therefore into the path taken by a message, to provide additional function, such as
warehousing of message traffic. The applications that send and receive the message
are not aware that the broker is now intercepting that message.

WebSphere MQ Integrator Version 2:

v Accepts messages without MQRFH or MQRFH2 headers. If content-based
processing of the message is to be carried out in a message flow, you need to
describe the message contents in the properties of the input node (see WebSphere
MQ Integrator Using the Control Center).
v Provides the MQSeries Integrator Version 1 function via the
NEONRulesEvaluation, NEONTransform, and NEONMap nodes (and the
superseded NeonRules and NeonFormatter nodes) as compatible message
processing nodes, ready to be included as required in any message flow defined
to the broker. The graphical user interface tools for creation and management of
the rules and formats used by these nodes, and the Visual Tester, are also
supplied with WebSphere MQ Integrator Version 2.
For more details of how to incorporate these nodes into message flows, refer to
WebSphere MQ Integrator Using the Control Center.

Chapter 6. Application design 85

Application reuse
v Accepts publish/subscribe messages from MQSeries Publish/Subscribe using the
MQRFH header, in addition to the more comprehensive MQRFH2 header used
in WebSphere MQ Integrator Version 2.
For details of the MQRFH header, see the MQSeries Publish/Subscribe User’s
Guide, and for the MQRFH2 header, see the WebSphere MQ Integrator
Programming Guide.

Send and forget

For simple one-way message flows, additional function is easily achieved. You can
design and deploy a message flow that implements the desired functions within
the broker, and use queue aliasing to redirect the original message stream to the
new input queue for this new message flow.

Define the nodes that provide the new processing you require, then define the
output node of the message flow to represent the original queue. This results in a
message being processed by the new message flow, and being written to the queue
read by the receiving application after processing is complete.

Request/reply
WebSphere MQ Integrator also supports request/reply applications. You can set up
a message flow to process the request in whatever way you need. Somewhere
within that message flow (in a database, for example), record the parameters you
need from the sending application’s message descriptor (MQMD). You need the
reply-to queue and queue manager, and perhaps other fields such as the report
options. You might find it necessary or most convenient to save the complete
MQMD.

You must then update the original MQMD with the required new values. For
example, insert a new reply-to queue and queue manager to represent the input
node of the message flow you create to handle the responses.

When the reply is processed by this second message flow, the processing must
include retrieval of the original MQMD values (such as the reply-to queue
identifier recorded by the first message flow) or the entire saved MQMD to ensure
the message is delivered as expected.

This technique works regardless of the number of replies expected to any request
message. You have to provide the extra logic and processing within the message
flows created to handle both request and reply, but this leaves the applications
themselves unchanged. This can be particularly valuable if you do not own these
applications, but are interacting with other departments or businesses.

If the reply message does not have to be processed in any way, you do not need to
create a second message flow, and the first message flow (processing the request
message) can simply propagate the original reply-to field in the message header
intact.

If you have a client/server suite of applications, where multiple clients expect

responses from a single server, you might find the applications need modifying to
use additional techniques to match requests and replies (such as a CorrelId) and
ensure the replies are correctly delivered.

86 WebSphere® MQ Integrator: Introduction and Planning

 Application reuse
Publish/subscribe
Publish/subscribe client applications written to the MQSeries Publish/Subscribe
interface execute unchanged. You need to create and deploy a message flow that
contains a Publication node, define the publication queue to the broker’s queue
manager, and specify it in the input node of the message flow.

WebSphere MQ Integrator uses the same broker control queue as MQSeries

Publish/Subscribe (SYSTEM.BROKER.CONTROL.QUEUE), therefore existing
subscriber applications do not have to be changed.

Every WebSphere MQ Integrator broker that you integrate into a WebSphere MQ

Publish/Subscribe network, must have a minimum of two queues available:
v SYSTEM.BROKER.DEFAULT.STREAM
This queue supports the default publication stream. You must create this queue
on every broker. You must also create and deploy a message flow that services
this stream queue.
v SYSTEM.BROKER.INTER.BROKER.COMMUNICATIONS
This queue is used by the broker to communicate with neighboring WebSphere
MQ Publish/Subscribe brokers. You must create this queue on every broker,
however the message flow for this queue is created internally by the broker.
For more information about how to set up these queues, refer to the WebSphere MQ
Integrator Administration Guide, SC34-5792.

For other migration considerations, check Appendix A, “Planning for migration

and integration” on page 167.

Writing new applications

You can write applications that use more of the function of the WebSphere MQ
Integrator broker by adding the MQRFH2 header to some or all of your messages.

The MQRFH2 header (described in detail in the WebSphere MQ Integrator

Programming Guide) is used to define the message set and format for the body of
the message, and to define publish/subscribe command messages. This header is
extensible, allowing client applications to define fields that can be accessed and
processed by customized message processing nodes. This header must immediately
precede the body of the message.

If you are writing a request/reply application, you can store the ReplyTo queue
and queue manager for the reply message (and any other options you require) in a
folder contained in the MQRFH2 header, instead of using a database node as
described in “Reusing existing applications” on page 85.

In some applications, it might be convenient to carry the application data in folders

in the MQRFH2 header. You can create your own folders within the header. The
MQRFH2 header, and suggested naming conventions for your own folders, are
described in the WebSphere MQ Integrator Programming Guide.

If you are writing new client applications, use the MQRFH2 header. This enables
your applications to exploit all the function contained in WebSphere MQ
Integrator.

Chapter 6. Application design 87

Summary

Summary
This chapter has provided the information you require to make the following
design decisions for your applications:
v What message header to use (MQRFH2 for new applications, MQRFH or no
header for existing applications)
v What queues or ports to use for sending and receiving messages (they need to
be set up in the message flow nodes)
v What programming interface to use (MQI, JMS, or AMI)
v What communication model to use (point-to-point, publish/subscribe, or both)
v What other features you need (transactional processing, message persistence,
message ordering)

For more information about publish/subscribe applications, see Chapter 7,

“Designing publish/subscribe applications” on page 89.

For information about writing the applications, having made the design decisions,
see the WebSphere MQ Integrator Programming Guide.

88 WebSphere® MQ Integrator: Introduction and Planning

Chapter 7. Designing publish/subscribe applications
If you are using the publish/subscribe facilities of WebSphere MQ Integrator, you
need to consider the following aspects of application design in addition to those
discussed in Chapter 6, “Application design” on page 79. This chapter covers:
v “How publish/subscribe applications interact with a broker”
v “Publications” on page 90
v “Subscriptions” on page 92
v “Topics” on page 96
v “Broker networks” on page 99
v “Topic-based security” on page 101
v “Summary” on page 106

How publish/subscribe applications interact with a broker

The simplest model of publish/subscribe communications involves a single broker,
one application that publishes messages, and one application that subscribes to
messages.

Figure 15 shows the messages that pass between a broker and a publisher, and
between the broker and a subscriber.

Publisher

Publish

Broker

Publish Subscribe

Subscriber

Figure 15. Publish/subscribe with a single broker

The publisher generates a message it wants to publish on a topic. The behavior of

the publisher and the ways in which it can publish a message are discussed in
“Publications” on page 90. “Topics” on page 96 describes topics and explains how
they can be constructed.

A message flow running in the broker retrieves the publication from its input
queue (read by the input node), performs any processing that is defined for

© Copyright IBM Corp. 2000, 2002 89

Interactions
publications received in that message flow, and passes the message to a publication
node for distribution to a subscriber. With SCADA applications, the SCADAInput
node receives the message from the SCADA port before processing by the message
flow.

The publication node only knows about, and can therefore only provide messages
to, an application that has registered as a subscriber. When the application registers
as a subscriber, it must specify a queue on which it wants to receive messages, and
a definition that restricts the messages it wants to receive. This definition is based
on a combination of the topic of the message, or specific content within the
message, or both. This is discussed in detail in “Subscriptions” on page 92. SCADA
subscribers need to specify the topic or topics that they are interested in.

Publications
When designing a publish/subscribe system, you need to consider if publications
should be retained by the broker after they have been sent to subscribers. You can
also choose to publish to subscribers at your local broker only, instead of allowing
publications to be propagated throughout the network of brokers. These options
are described in the following sections.

Retained publications
By default, a broker discards a publication when it has sent that publication to all
interested subscribers. However, a publisher can specify that it wants the broker to
keep a copy of a publication, which is then called a retained publication. The copy
can be sent by the broker to subsequent subscribers who register an interest in the
topic. This means that new subscribers don’t have to wait for information to be
published again before they receive it.

For example, a subscriber registering a subscription to a stock price would receive

the current price straightaway, without waiting for the stock price to change (and
hence be republished).

The broker retains only one publication for each topic and subscription point, so
the old publication is deleted when a new one arrives. See “Subscription points”
on page 93 for further details about subscription points.

State and event information

Information being published can be categorized as state information or event
information. This section explains these concepts, and helps you to understand why
you might want to use retained publications to provide these two categories of
information.

State information is information about the current state of something, such as the
price of stock or the current score in a soccer match. When something happens (for
example, the stock price falls, or the soccer score changes), the previous state
information is no longer required because it is superseded by the new information.

A subscriber usually wants to receive the current version of the state information
when it starts up, and to be sent new information whenever the state changes.

Event information is information about individual events that occur, such as a trade
in some stock or the scoring of a particular goal. Each event is independent of the
others.

A subscriber usually wants to receive information about events when they happen.

90 WebSphere® MQ Integrator: Introduction and Planning

 Publications
Using retained publications
When deciding whether to use retained publications, you must consider several
factors:
v What kind of information will your publications contain?
Event information does not usually have to be retained, but state information is
often retained. However, if all the subscriptions to a topic are in place before any
publications are made on that topic, and no new subscriptions are expected,
there is no need to retain publications even for state information, because they
are delivered to all the subscribers as soon as they are published.
Publications of state information might also not need to be retained if they are
very frequent (for example, every second). With this frequency of publishing,
any new subscriber, or a subscriber recovering from a failure, receives the
current state information almost immediately after it subscribes.
v Do you want to receive publications on request only?
If you use retained publications, subscribers can register using the ‘Publish on
Request Only’ option. This means that the broker does not send any publications
to that subscriber until the subscriber requests an update. The broker then sends
to the subscriber the current retained publication that matches the subscription.
v Can retained publications be mixed with non-retained publications on the same
topic?
This is not recommended. If you have a retained publication, and then publish a
non-retained publication on the same topic, the existing retained publication is
still retained; it is not updated by the non-retained publication. If you have a
subscriber that has registered with the ‘Publish on Request Only’ option, it
cannot access any non-retained publications; the broker sends only the current
retained publication in response to a request for an update.
v Can you have more than one application publishing retained publications on the
same topic?
Do not have more than one application publishing retained publications on the
same topic. If you do and the timing is close to simultaneous, it is indeterminate
which publication is retained. If the publishers use different brokers, it is
possible that different retained publications for the same topic could be held at
each broker.
v How does the subscriber application recover from failure?
If the publisher does not use retained publications, the subscriber application
might need to store its current state locally. If the publisher does use retained
publications, the subscriber can request an update to refresh its state information
after a restart.
The broker continues to send publications to a registered subscriber even if that
subscriber is not running. This could lead to a buildup of messages on the
subscriber queue, which can be avoided if the subscriber registers with the
‘Publish on Request Only’ option. The subscriber must then refresh its state
periodically by requesting an update or by using a temporary dynamic queue.
v What are the performance implications of retaining publications?
The broker needs to store retained publications in a database, which reduces
throughput. If the publications are very large, a considerable amount of disk
space is needed to store the retained publication of each topic. In a multi-broker
environment, retained publications are stored by all other connected brokers that
have a matching subscription.

The sample verification applications that are shipped with WebSphere MQ

Integrator include the Soccer Results service. This sample uses retained

Chapter 7. Designing publish/subscribe applications 91

Publications
publications to record the latest score in each soccer match it is monitoring. The
sample code illustrates the programming required to support this option.

Local and global publications

Publications can be categorized as either global or local.

Global publication
A global publication is distributed throughout the broker domain to all connected
brokers. Each broker delivers a global publication to all its neighbors that have a
subscriber registered with a subscription that matches the publication. Controls are
in place to ensure these publications do not get into a loop.

It is possible to have more than one group of connected brokers within a single
broker domain. A global publication can only be delivered to brokers that are
interconnected, so its distribution is limited by the topology of your broker
domain.

Local publication
Publishers can choose to restrict access to their publications to subscribers
registered to the same broker as the publisher.

The publisher can specify the ‘Local’ option when it sends a publication. Local
publications are not forwarded to other brokers.

Conference-type applications
In some cases, a publisher might also be a subscriber. For example, a group of
applications can all subscribe to the same topic (such as “Conference”), and receive
publications on this topic. Using the ‘Other Subscribers Only’ option ensures that
each application receives publications from the other applications, but not those
that it has published itself.

Subscriptions
Subscriptions are supported by WebSphere MQ Integrator in a dynamic fashion.
The broker is unaware of the intention of the subscriber to register, and cannot
know at any time about any subscribers other than those currently subscribed.
Subscribers can register and de-register at any time, and as often as they choose.

Client applications (subscribers) issue subscription registration requests to their

local broker when they want to receive published messages. All the information
associated with the subscription is recorded by the broker in the subscription table.
It can only be removed from this table when the subscriber de-registers, or when
the subscription expires, or is deleted by the Control Center.

If the subscriber specifies a temporary dynamic queue as the queue to which

publications should be sent, the broker de-registers the subscription automatically
when the queue is deleted.

The subscribing application specifies the following information on the registration

request:
v The topic or topics of the published messages in which it has an interest (see
“Topics” on page 96).

92 WebSphere® MQ Integrator: Introduction and Planning

 Subscriptions
If you specify the multi-level wildcard (“#”) by itself, all published messages with
matching subscription points and content filters (if specified) are valid, including
event publications. (For more information about the multi-level wildcard, see
“The multi-level wildcard” on page 97.)
v The subscription point (see “Subscription points”) from which it wants to receive
publications.
This value should match the subscription point property set for at least one
publication node defined in this broker (this could be the default subscription
point). If it does not match, the subscriber does not receive any publications
(unless a publication node is defined subsequently with this subscription point
name). For SCADA applications, the SCADA connection port is the implied
subscription point.
v The content filter (see “Filters” on page 94) to be applied to the published
message.
This information is optional: the subscriber does not have to include a content
filter. If it does not, all published messages with matching subscription points
and topics, if specified, are valid. Content filters cannot be used with SCADA
messages.
v The identity of the queue (the subscriber queue) on which it wants to receive
publications that match the criteria it has selected.
An optional CorrelId can be specified (this is useful if several subscribers share
the same queue). For SCADA applications, the SCADA port receives the
publications without needing to be specified.

When the publication node receives a message, it checks through the subscription
table to determine if there are any subscription requests that specify this particular
node’s subscription point, that match the content, or topic, or both, of the message
received.

For every match found, the node delivers the published message on the subscriber
queue, using the optional CorrelId if specified (otherwise a fixed value is used).
Each subscriber receives a single copy of each publication regardless of the number
of matching subscriptions the client has. SCADA applications subscribe and
publish via the SCADA port, and CorrelId is not applicable.

When the node has sent the publication to any subscribers that have a matching
subscription, the publication is discarded (unless it is a retained publication).

Subscription points
A message flow used for publish/subscribe must contain at least one of the
supplied input nodes, such as MQInput, and at least one Publication node. (Note
that SCADA publish/subscribe applications also need the publication node, or
exceptionally the SCADAOutput node.) A subscription point is the name by which
a subscriber requests publications from a particular set of publication nodes. You
can use the default subscription point, or set up specific subscription points, and
you can have more than one publication node associated with a particular
subscription point.

The default subscription point

If you define a publication node without specifying its subscription point property,
it is associated with the default subscription point. A subscriber that registers a
subscription without specifying a subscription point receives publications from any
such publication node, provided that they match the topic and filter specified by
the subscriber.

Chapter 7. Designing publish/subscribe applications 93

Subscriptions
This applies to all message flows running in all brokers connected in the same
network (unless the ‘Local’ option has been specified).

Using subscription points

If you have more than one publication node in a message flow, you can
differentiate between them by specifying subscription points. These should have
values that reflect the nature of the messages routed to each publication node.

For example, a message flow might apply a filter to a message for publication, and
apply two different compute operations to the outputs of the Filter node before
sending the resultant messages to separate publication nodes. In this case, the
subscription point names for these publication nodes should reflect the operations
carried out by the message flow. Other message flows could have publication
nodes associated with either or both of these subscription points, if appropriate.

Alternatively, allow one publication node to have the default subscription point,
and apply a meaningful name to the subscription point of each additional
publication node. If more than one publication node in a message flow has the
same subscription point property, subscribers might receive more than one copy of
each publication, unless the conditions under which messages reach publication
nodes are mutually exclusive.

Example
Suppose you have an application that publishes stock prices. The prices that are
available from the first publication node in the message flow are in dollars. This
publication node uses the default subscription point.

You can define a second path through the message flow that takes the price in
dollars, and converts this using some defined conversion value, to produce the
same message but with the stock price in pounds. These messages are published at
a second publication node that has its subscription point property set to ‘Pounds’.

You might have another message flow (running in the same broker, or a connected
broker) that publishes stock prices in pounds on the same topic. Make sure it uses
the ‘Pounds’ subscription point, and that any other message flows publishing their
stock prices in dollars use the default subscription point.

Subscribers specifying the relevant topic (for example, ‘stock’) can then choose to
receive the information in dollars or pounds, by using the default subscription
point or the ‘Pounds’ subscription point when they subscribe.

Filters
When you register a subscription, you can specify a content-based filter to select
publications according to their contents, in addition to specifying a topic and
subscription point. WebSphere MQ Integrator needs to know how to parse the
contents of the message correctly. This can be achieved in a number of ways:
v The message is a self-defining XML message.
v The message template is defined in the MQRFH2 header.
v If the message has an MQRFH header, the message set and type are taken from
that header.
v Otherwise, the message is assumed to be as defined in the properties (domain,
set, type and format) of the input node.

94 WebSphere® MQ Integrator: Introduction and Planning

 Subscriptions
The filter itself is entered as an expression with ESQL syntax, for example:
Body.Name LIKE ‘Smit%’

This means that the contents of a field called Name in the body of a publication
message (that is, the publication data that follows the MQRFH2 header) are
extracted and compared to the string given in the expression. If the string in the
message starts with the characters “Smit”, the expression evaluates to TRUE and
the publication is sent to the subscriber.

The language used in the specification of filters for content-based routing forms a
proper subset of the Filter node language. For more information about the syntax
of filter expressions, see the WebSphere MQ Integrator Programming Guide.

If you want to select publications using filters only, without specifying a topic, you
can register a subscription with the required filter and a topic of “#” (all topics).
You then receive publications only on those topics for which you have access
authority. However, this subscription results in all publications from all connected
brokers being sent to the broker that is local to the subscriber. If you have set up a
network of brokers, you are not advised to use this technique for performance
reasons.

Local subscriptions
Subscribers can specify a local option on registration. If they do so, they are
requesting that their subscription registration is not forwarded to other brokers,
but held by the local broker. Any message published at this broker that matches
the subscription is received by this subscriber, but messages published to other
brokers are not normally available (unless the subscriber has also registered a
global subscription with an overlapping topic and the same subscription point).

Retained publications
If retained publications are used, the subscriber can specify the following options
when it registers a subscription.

Publish on request only

If the ‘Publish on Request Only’ option is used, the broker does not send
publications to the subscriber until the subscriber sends a ‘Request Update’
message to the broker. The broker then sends any current retained publication that
matches the subscription.

New publications only

Normally the broker sends the current retained publication that matches the
subscription when a subscriber registers that subscription. If the subscriber uses
the ‘New Publications Only’ option, the broker waits until a new publication is
received before sending it to the subscriber.

Message persistence
Send all subscription registration messages as persistent messages. All
subscriptions are maintained persistently by the broker.

Brokers maintain the persistence of publications as set by the publisher, unless

changed by options specified when the subscription is registered. These options are
nonpersistent, persistent, persistence as queue, or persistence as publisher (the
default).

Chapter 7. Designing publish/subscribe applications 95

Subscriptions
The system administrator decides which users are allowed to have publications
sent persistently (see “Access control lists” on page 101).

Topics
A topic specifies a subject of common interest to producers and consumers of
messages (publishers and subscribers). Almost any string of characters can act as a
topic to describe the topic category of a message. However, there are three reserved
characters, described in “Special characters in topics” on page 97.

Topics provide the key to the delivery of messages between publishers and
subscribers. They provide an anonymous alternative to citing specific destination
addresses. The broker attempts to match a topic on a published message with a list
of clients who have subscribed to that topic. Topics can also be used to control
which subscribers are authorized to receive publications.

You create the topics needed by your messages in a tree hierarchy, using the
facilities of the Control Center. The tree can be defined before being used, and, if
you choose, added to dynamically when new topics are created by client
applications.

Thoughtful design of topic names and topic trees can save time and effort later for
routine operations, including:
v Subscribing to multiple topics.
v Establishing security policies.
v Automatically reacting to messages on a specific topic, for example sending an
alert to a manager’s pager.

Individual topics serve as elements (that is, nodes) in the topic tree. New elements
are added as you define them through the Control Center, or are specified by
applications, to create topic trees. Although it can be flat (linear), a topic tree
usually builds from one or more root topics, adding other topics in levels of
parent/child relationships to create a hierarchical naming structure.

The following figure illustrates a topic tree structure.

USA

Alabama Alaska

Auburn Mobile Montgomery Juneau

Figure 16. Example topic tree

The structure of the tree follows a format with levels of increasing granularity:
“country/state/city”. Each string in the figure represents a node on the topic tree.
Complete topic names aggregate nodes at one or more levels in the topic tree.
Levels are separated by the “/” character (see “Special characters in topics” on
page 97). Topic names fully specify the path to a specific node from the root of the
tree in this format: “root/level2/level3”.

96 WebSphere® MQ Integrator: Introduction and Planning

 Topics
In Figure 16 on page 96, the string “USA” acts as a root node, the first level of a
topic name for topics in this tree. Valid topics include “USA”, “USA/Alabama”
and “USA/Alabama/Montgomery”.

When you design topic names and topic trees, it is important to remember that the
message broker does not interpret or attempt to derive meaning from the topic
name itself. It only uses the topic name to send related messages to clients who
have subscribed to that topic.

Note: A finer level of filtering can be provided using content filters (see “Filters”
on page 94).

Special characters in topics

The topic of a message can contain any of the characters found in the Unicode
character set. Three of these characters have a special meaning for WebSphere MQ
Integrator.

The three are the topic level separator “/”, the multi-level wildcard “#”, and the
single-level wildcard “+”. The first of these is used to introduce structure to the
topic, and can therefore be specified within the topic for that purpose. The latter
two are wildcards used for subscriptions (see “Using wildcards with topics” on
page 98) and cannot be used within a topic when a message is published.

Note: If you are migrating your applications from MQSeries Publish/Subscribe

environment, refer to Appendix A, “Planning for migration and integration”
on page 167 for further details about topics and wildcards.

The topic level separator

The topic level separator character “/” provides a hierarchical structure to the
topic space. It must be used by applications to denote levels within a topic tree.
The use of the topic level separator is significant when the two wildcard characters
are encountered in topics specified by subscribers.

Topic hierarchy is important in administration of access control, described in

“Access control lists” on page 101.

The multi-level wildcard

The multi-level wildcard character “#” is used to match any number of levels
within a topic, typically an unknown number. It can be used only at the beginning
or the end of a topic (but not both). For example, you can subscribe to “USA/#”,
and receive messages on topics “USA/Alabama” and “USA/Alabama/Auburn”.

The way the multi-level wildcard is implemented means it can represent zero or
more levels. Therefore “USA/#” can also match the singular “USA”, where #
represents zero levels. The topic level separator is meaningless in this context,
because there is no level to separate.

You can only use the multi-level wildcard next to the topic level separator
character unless you specify the multi-level wildcard on its own. For example,
“USA#” is not valid, but “#” is.

The single-level wildcard

The single-level wildcard character “+” matches one (and only one) topic level. For
example, “USA/+” matches “USA/Alabama” but not “USA/Alabama/Auburn”.
Also, because the single-level wildcard matches a single level only, “USA/+” does
not match “USA”.

Chapter 7. Designing publish/subscribe applications 97

Topics
This wildcard can be used at any level in the topic tree, and in conjunction with
the multi-level wildcard. However, you can only use the single-level wildcard next
to the topic level separator character unless you specify the single-level wildcard
on its own. For example, “USA+” is not valid, but “+” is valid.

Topic semantics and usage

When you build an application, the topic tree design is important to the
application’s communication model. The design should account for the following
principles of topic name syntax and semantics:
v Topic names are case sensitive. For example, WebSphere MQ Integrator
recognizes “ACCOUNTS” and “Accounts” as two different topics.
v Topic names can include the space character. For example, you can define
“Accounts payable” as a valid topic.
v Though not recommended, a topic level can be an empty string. For example,
“a//c” is a three level topic name with an empty middle level.
v A leading “/” creates a distinct topic: “/USA” is different from “USA” and
“/USA’ matches “+/+” and “/+”, but not “+”.
v For portability reasons, you should not include the null character (Unicode
\x0000) in any topic.

WebSphere MQ Integrator applies the following conditions to the construction and

content of a topic tree:
v There is no limit to the levels of depth (the number of topic levels) in the tree.
v There is no limit to the length of any level name in the tree.
v There can be any number of “root” nodes (that is, any number of topic trees).
These are defined below the root “”, which is the root of all root nodes. It is
referred to as “topicRoot”, although there is no corresponding topic name.
Applications cannot publish or subscribe to this virtual root.
v The topic trees with roots of “$SYS” and “$ISYS” are reserved for use by
WebSphere MQ Integrator.
If you are using topic-based security, only brokers can publish messages on these
topics, and only brokers can subscribe to messages with a topic of “$ISYS”,
regardless of the topic Access Control Lists (ACLs) defined using the Control
Center. For more details about topic-based security and ACLs, see “Topic-based
security” on page 101.

Using wildcards with topics

Wildcards are used only when subscribing to topics, de-registering, requesting
updates, and deleting publications. Messages must always be published with a
fully specified topic name.

Using wildcards in subscriptions is not difficult, but needs to be done with care.
Remember that wildcards can be used at any level in the topic name string (within
the restrictions already discussed). However, use them only at the end of a topic
name. Although the single-level wildcard is accepted anywhere, the product is
optimized to it being specified at the end of the string. The multi-level wildcard
can only be used at the beginning or end of the string.

You should create well-formed applications that structure topics into subject trees.
This allows the applications to subscribe to sub-trees by placing the multi-level
wildcard “#” at the end of a topic.

98 WebSphere® MQ Integrator: Introduction and Planning

 Topics
You can specify more than one wildcard within a subscription, if their use
conforms to the guidelines given. For example, “+/Alabama/#” is valid.

If you subscribe with “#”, you receive all publications from all connected brokers.
Therefore, use this type of subscription with care, to minimize the impact of
workload in your broker network.

Multiple topics
You can specify more than one topic for a publication. One use of this is as
follows.

Suppose an application publishes information under the topic ‘Topic 1’. The
application might then be enhanced to provide additional information, which it
might publish under the topic ‘Topic 1 enhanced’. If the new publications specify
the original ‘Topic 1’ as well, then existing subscribers receive both old and new
publications, whereas subscribers who want to receive only the enhanced
publications can register with ‘Topic 1 enhanced’.

Note that an application that subscribes to both topics receives one copy only of
each publication.

Broker networks
The interactions between a broker and its publishing and subscribing applications,
described in “How publish/subscribe applications interact with a broker” on
page 89, are equally valid in a broker network, in which publish/subscribe
applications are interacting with any one of a number of connected brokers.

Publisher 1 Publisher 2

Publish 1 Publish 2

Publish 2
Broker Broker
Subscribe
(Forwarded)
Publish 1
Subscribe
Publish 2

Subscriber

Figure 17. Publish/subscribe in a network

Figure 17 illustrates a simple example of the publish and subscribe messages

flowing through a network of two brokers.

Chapter 7. Designing publish/subscribe applications 99

Broker networks
Subscriptions and published messages are propagated through the WebSphere MQ
Integrator broker domain. You can set up a network of brokers using the Control
Center so that each has an explicit or implicit connection to a group of other
brokers. You can have more than one group of connected brokers in the broker
domain. Brokers propagate subscription registrations through each network of
connected brokers, and publications are forwarded to all brokers that have
matching subscriptions.

It doesn’t matter, therefore, which broker a message is published to. Any

application that has registered a subscription to a connected broker receives
publications matching that subscription.

Each broker records subscription information from its local subscribers and
information from remote subscribers forwarded by its neighbor brokers in its
subscription table, which holds all the current subscription information known to
that broker (for all execution groups and message flows).

Collectives
You can group your brokers in collectives. This is a way of organizing a network
of brokers to get the most effective environment for publish/subscribe applications.

You can define collectives and organize your brokers using the Control Center.

How publications and subscriptions flow through the network

When a client registers a subscription, the broker registers a matching subscription
with its neighbors. This is called a “proxy subscription”. If an identical
subscription has already been registered, the broker does not register again: only
one proxy subscription can be in effect at any one time. Likewise, when a client
de-registers a subscription from a broker, the broker de-registers the proxy
subscription from its neighbors, if the client is the last (or only) client for which the
broker is holding the proxy.

Content-based filters are not included in proxy subscriptions. Therefore a superset

of messages might be received by the broker to which a subscriber that specified a
content filter is registered, but are not passed to that subscriber by its local broker,
unless the content matches.

All proxy subscriptions are made with the PersistenceAsPublisher option. This
results in messages being delivered to neighboring brokers with the persistence
specified by the publisher. Client subscription persistence options only take effect
at the local broker (that is, the broker with which the clients have registered).

Therefore a subscriber that requests persistent delivery always receives a persistent

message for matching publications. However, the message could be delivered
through the broker network as a nonpersistent message if this was specified by the
publisher. If a problem occurs during the transmission of a message between
publisher and subscriber, it is therefore possible that the subscriber never gets the
message, despite specifying persistent delivery as an option on subscription
registration.

100 WebSphere® MQ Integrator: Introduction and Planning

 Topic-based security

Topic-based security
You can control access to messages on particular topics by implementing security
measures governed by Access Control Lists (ACLs), which are based on the
definition of principals to the underlying security control facility. A principal can
be an individual user ID (for example, a logon ID), or a user group which can
contain individual users.

Principals and the User Name Server

The message descriptor assigned to each message transmitted by MQSeries
contains the identity of the principal that initiated the message. MQSeries sets this
identity in an operating system dependent manner, but this can be augmented at
an MQSeries installation by use of standard MQSeries exits. The principal in the
message descriptor is used to determine authority for the topic being published or
subscribed to.

WebSphere MQ Integrator security architecture is based on the assumption that the

network is heterogeneous: although MQSeries includes a form of Windows NT
domain information for client platform identification, WebSphere MQ Integrator
does not exploit this information.

The WebSphere MQ Integrator User Name Server manages the set of principals
already defined in your network, on behalf of the brokers and the Configuration
Manager, for use in publish/subscribe. On Windows NT, this list of users is drawn
from the domain specified on the mqsicreateconfigmgr command.

The User Name Server is made known to both the broker and the Configuration
Manager by specifying the User Name Server queue manager on the create
command for both components.

All brokers within the broker domain interact with the User Name Server to
retrieve the total set of users and groups against which the access control lists are
built and publish/subscribe requests validated. The Configuration Manager
interacts with the User Name Server and displays users/groups in ACL creation in
the Topics view from the Control Center.

Access control lists

ACLs allow you to define, for any topic and principal, the right of that principal to
publish on or subscribe to a given topic, or to request persistent delivery. You
specify these definitions using the Topics view in the Control Center.

Access control is set explicitly on an individual topic, but can be inherited if there
is no explicit ACL in place. Inheritance is from an ancestor (parent) topic, defined
by the hierarchical structure of the topic tree. If none of the parent topics up to the
topic root has an explicit ACL, the individual topic inherits the ACL of the topic
root.

Any defined principal (user or group) known to the User Name Server can be
associated with the topic in this way.

Resolving ACL conflicts

If the principals in your broker domain include one or more users in more than
one group, it is possible that the explicit or inherited ACL values conflict.
v If the user has an explicit user ACL on the topic of interest, this always takes
priority and the broker verifies the current operation on that basis.

Chapter 7. Designing publish/subscribe applications 101

Topic-based security
v If the user does not have an explicit user ACL on the topic of interest, but has
explicit user ACLs against an ancestor in the topic tree, the closest ancestor ACL
for that user takes priority and the broker verifies the current operation on that
basis.
v If there are no explicit user ACLs for the user on the topic of interest or its
ancestors, the broker attempts to verify the current operation on the basis of
group ACLs:
– If the user is a member of a group that has an explicit group ACL on the
topic of interest, the broker verifies the current operation on the basis of that
group ACL.
– If the user is not a member of a group that has an explicit group ACL on the
topic of interest, but is a member of a group with explicit group ACLs against
an ancestor in the topic tree, the closest ancestor ACL takes priority and the
broker verifies the current operation on that basis.
– If, at a particular level in the topic tree, the user ID is contained in more than
one group with an explicit ACL, permission is granted if any of the
specifications are positive, otherwise it is denied.

You can’t associate ACLs with topics that include one or more wildcards. However,
your client application access is resolved correctly when the subscription
registration is made, even when that application specifies a wildcard in the topic.

PublicGroup authorizations
In addition to the groups that you define, WebSphere MQ Integrator provides an
implicit group, “PublicGroup”, to which all users automatically belong. This
implicit group simplifies the specification of ACLs in a topic tree. In particular, this
group is used in the specification of the ACL for the topic root. Note that the
default setting of the topic root allows publish and subscribe operation for the
“PublicGroup”. You can view and change this ACL using the Control Center, but
you cannot remove it. It determines the default permissions for the entire topic
tree. You can specify ACLs for the “PublicGroup” elsewhere in the topic tree,
wherever you want to define permissions for all users.

If you have a principal named “Public” defined in your existing security

environment, you cannot use this for topic-based security. If you specify this
principal within any ACL, it is equated to “PublicGroup” and therefore provides
global access in all cases.

mqbrkrs authorizations
WebSphere MQ Integrator grants special publish/subscribe access control
privileges to members of the mqbrkrs group, and to the corresponding Domain
mqbrkrs global group if appropriate (see “Using Windows NT security domains”
on page 142 for details).

Brokers need special privileges to perform internal publish and subscribe

operations in networks where access control is enabled. When you create a broker
in such a network, you must specify a user ID that belongs to the group mqbrkrs
as the service user ID for the broker (as shown in Table 6 on page 145). The
mqbrkrs group is given implicit privileges that allow its members to publish,
subscribe and request the persistent delivery of messages on the topic root (“”). All
other topics inherit these permissions. If you attempt to configure any ACLs for the
mqbrkrs group through the Control Center, these ACLs are ignored by WebSphere
MQ Integrator.

102 WebSphere® MQ Integrator: Introduction and Planning

 Topic-based security
ACLs and system topics
Messages that are used for internal publish and subscribe operations are published
throughout the broker domain using system topics, which begin with the strings
“$SYS” and “$ISYS”. These topics must be published and subscribed to by
members of mqbrkrs only, with the exception of the following two scenarios:
1. If you are migrating topics from MQSeries Publish/Subscribe, you can
configure ACLs on topics that begin with the string “$SYS/STREAM” (see
“MQSeries Publish/Subscribe” on page 171 for further details about migration).
2. Clients can subscribe to topics that begin with the string “$SYS”, which allows
applications that provide a management function to subscribe to the broker for
administrative events.

Do not configure ACLs on topics that begin with the string “$ISYS”. You are not
prevented from doing so, but they are ignored.

Setting access control on topics

All members of the group mqbrtpic are permitted to define and manipulate the
ACLs that define which principals are permitted to publish on and subscribe to
topics. ACLs can also limit delivery of persistent messages. All defined principals
(users or groups) can be associated with any topic: the permissions that can be set
are shown in Table 1.
Table 1. ACL permissions
Option Description
Publish Permits or denies the principal to publish messages on this topic.
Subscribe Permits or denies the principal to subscribe to messages on this topic.
Persistent Specifies whether the principal can receive messages persistently. If the
principal is not permitted, all messages are sent nonpersistently. Each
individual subscription indicates whether the subscriber requires
persistent messages.

Persistent access control behavior is not identical to the publish and subscribe
control:
v Clients that are denied Publish access have their publication messages refused.
v Clients that are denied Subscribe access do not receive the publication.
v The persistent access control does not deny the message to subscribers, but
denies them persistence, so denied subscribers always receive messages (subject
to their subscribe access control), but always have the message sent to them
nonpersistently, regardless of the persistence of the original message.

Inheritance of security policies

Topics are organized in a hierarchical tree. The ACL of a parent topic can be
inherited by some or all of its descendent topics that do not have an explicit ACL.
Therefore, it is not necessary to have an explicit ACL associated with each and
every topic. Every topic has an ACL policy which is that of its parent. If all parent
topics up to the root topic do not have explicit ACLs, that topic inherits the ACL of
the root topic.

For example, in the topic tree in Figure 18 on page 104, the topic root is not shown
but is assumed to have an ACL for “PublicGroup” that allows permission to
publish, subscribe, and receive persistent publications. (The symbol “¬” means
“not”.) Table 2 on page 104 summarizes the ACL for each topic in the tree shown.

Chapter 7. Designing publish/subscribe applications 103

Topic-based security

Publish ACL: joe

A Subscribe ACL: Public Group
Persistent ACL: Public Group

Publish ACL: joe

K P Persistent ACL: joe

Publish ACL: allen B

Subscribe ACL: HR, Public Group
M

Publish ACL: mary, joe

N Subscribe ACL: nat
Persistent ACL: Public Group, nat

Figure 18. Inheriting ACLs in a topic tree

Table 2. The ACLs for inheritance

Topic Publishers Subscribers Persistent
A only joe everyone no-one
A/P only joe everyone only joe
A/K only joe everyone no-one
A/K/M only joe everyone no-one
A/K/M/N only mary, joe everyone everyone except nat
A/B allen, joe HR no-one

Dynamically created topics

Topics that are not explicitly administered, but are created dynamically in response
to client publish or subscribe messages, are treated in the same way as those that
are administered, but have no explicit ACLs. That is, the ACLs for dynamically
created topics are inherited from the closest ancestor in the topic tree that has an
explicit policy. It is therefore not necessary to define leaf topics in the tree if they
do not have explicit ACLs.

ACLs and wildcard topics

WebSphere MQ Integrator does not allow you to associate an explicit security
policy with a wildcard topic (for example, you cannot associate an ACL with topic
“A/+”, which represents a two level hierarchy and includes “A/B”, “A/K”, and
“A/P”).

However, WebSphere MQ Integrator does guarantee correct access mediation when

a client subscribes to a wildcard topic.

For example, the topic “A/+” does not (and cannot) have a security policy
associated with it. Therefore, “A/+” inherits its policy from “A”. Any user can
subscribe to “A/+” because the subscribe ACL includes everyone.

When a message is published on “A/P” or “A/K”, the broker delivers it to the

user who subscribed to “A/+”. However, when a message is published to “A/B”,
that message is only delivered to subscribers who are in the HR group.

If the system administrator changes the subscribe ACL of any topic that matches
“A/+”, the broker correctly enforces the ACL when the message is delivered.

104 WebSphere® MQ Integrator: Introduction and Planning

 Topic-based security
Subscribing to a wildcard topic has the semantics to deliver messages on all topics
that match the wildcard, and for which the subscriber has authorization to receive
that message.

ACLs and subscription resolution

The broker enforces access control through the topic of the message to be
delivered. Messages are only delivered to those clients that have not had subscribe
access denied, either explicitly or through inheritance. The final decision to deliver
a message to a subscriber cannot be made by the broker until a specific message
with a topic is being processed. A subscription can contain a wildcard, therefore
the actual match against the topic namespace, and hence the topic ACLs, cannot be
made at the time the subscription is received.

Activating topic ACL updates

Updates to a topic ACL do not become active until deployed and activated across
the WebSphere MQ Integrator broker domain from the Control Center. You must
be a member of the group mqbrops to deploy ACLs.

Checking publications and subscriptions

The broker makes a number of checks on requests from publishers and subscribers.

The publisher
When a publisher application publishes a message on a topic, the broker verifies
that the publisher is authorized to publish on that topic:
v If the publisher is not authorized, the broker rejects the publish request and
returns a warning message to the publisher.
v If the publisher is authorized, the broker delivers the message to all authorized
subscribers to the topic.

The subscriber
When a broker receives a subscription request, it verifies the following:
v The subscriber has authority to put to the subscriber queue specified in the
subscription request. You must set up this authorization using MQSeries
facilities: this is independent of the authorizations established for the subscriber
in the Control Center.
v No other user is using the same combination of queue name, queue manager
name, and correlation ID (if specified).
v The client is permitted to subscribe to the topic, according to the ACL in force
for the combination of that topic and user. This can only be checked at this time
if the client has not specified a wildcard in the topic for subscription.

If any of these checks fail, the broker rejects the subscription request.

When a broker is ready to deliver a publication, it checks the following:

v The subscriber is authorized to receive persistent publications, if persistent
delivery on the topic has been requested. If the subscriber is not authorized to
receive persistent publications, the publication is sent as a nonpersistent
publication.
v The client is permitted to subscribe to that topic, according to the ACL in force
for the combination of that topic and user. (Any wildcard the client specified is
resolved when a specific message is available: publications have fully-specified
topics that do not contain any wildcards.) Messages are delivered only to those
clients that have not had subscribe access denied, either explicitly or through
inheritance. If this check fails, the publication is not delivered to the subscriber.

Chapter 7. Designing publish/subscribe applications 105

Topic-based security
v If a client has subscribed by content, the broker matches the content specified,
then checks the topic in the publication and consults the appropriate ACL for
permission.
If this check fails, the publication is not delivered to the subscriber.

Detailed information about creating and managing ACLs is provided in WebSphere

MQ Integrator Using the Control Center.

Summary
This chapter has provided the information you require to make the following
design decisions for your publish/subscribe applications:
v The topic trees you use for publications (including the use of wildcards for
subscriptions)
v The options you want to use as a publisher (retained, local, other subscribers
only)
v The options you want to use as a subscriber (subscription point, filter, local, new
publications only, publish on request only)
v The subscriber queues you use to receive publications (with optional correlation
identifiers)
v The use of access control lists

For information about writing the applications, having made the design decisions,
see the WebSphere MQ Integrator Programming Guide.

106 WebSphere® MQ Integrator: Introduction and Planning

Part 4. Systems planning
Chapter 8. System requirements . . . . . . 109 Client applications. . . . . . . . . . . 130
Summary of system requirements . . . . . . 109 The Control Center application . . . . . 131
System requirements for AIX components . . . . 111 Designing the MQSeries infrastructure . . . . . 131
Hardware requirements . . . . . . . . . 111 MQSeries resources for brokers . . . . . . 132
Disk space required . . . . . . . . . . 111 MQSeries resources for the Configuration
Software requirements . . . . . . . . . 111 Manager . . . . . . . . . . . . . . 132
AIX. . . . . . . . . . . . . . . 111 MQSeries resources for the User Name Server 133
Java . . . . . . . . . . . . . . 111 MQSeries resources for the Control Center . . 133
MQSeries for AIX . . . . . . . . . . 111 MQSeries resources for client applications . . . 135
Databases . . . . . . . . . . . . 112 MQSeries clusters . . . . . . . . . . . 135
System requirements for HP-UX components . . . 113 Planning database resources . . . . . . . . 137
Hardware requirements . . . . . . . . . 113 Database requirements . . . . . . . . . 137
Disk space required . . . . . . . . . . 113 Databases and code pages . . . . . . . . 138
Software requirements . . . . . . . . . 113 Database locations. . . . . . . . . . . 138
HP-UX . . . . . . . . . . . . . 113 Database backup and recovery . . . . . . 139
MQSeries for HP-UX . . . . . . . . . 113 Planning security . . . . . . . . . . . . 140
Databases . . . . . . . . . . . . 113 Security and principals . . . . . . . . . 140
System requirements for Solaris components . . . 115 Groups . . . . . . . . . . . . . 140
Hardware requirements . . . . . . . . . 115 Principals . . . . . . . . . . . . 142
Disk space required . . . . . . . . . . 115 Using Windows NT security domains . . . . 142
Software requirements . . . . . . . . . 115 Using UNIX security domains . . . . . . . 144
Solaris . . . . . . . . . . . . . . 115 Summary of authorizations . . . . . . . . 144
MQSeries for Solaris . . . . . . . . . 115 Operational security . . . . . . . . . . . 147
Databases . . . . . . . . . . . . 115 Configurational security . . . . . . . . . 147
System requirements for Windows NT and Run-time security . . . . . . . . . . . 147
Windows 2000 components . . . . . . . . . 117 Database security . . . . . . . . . . . 148
Hardware requirements . . . . . . . . . 117 MQSeries security . . . . . . . . . . . . 148
Disk space required . . . . . . . . . . 117 WebSphere MQ Integrator for z/OS security . . . 148
Software requirements . . . . . . . . . 117 Control Center security . . . . . . . . . . 148
Windows NT . . . . . . . . . . . 118 The IBMMQSI2 superuser . . . . . . . . 149
MQSeries for Windows NT and Windows MQSeries authorizations. . . . . . . . . 150
2000 . . . . . . . . . . . . . . 118 Application security . . . . . . . . . . . 150
Database support for the Configuration Message flow security . . . . . . . . . 150
Manager . . . . . . . . . . . . . 118 Topic-based security . . . . . . . . . . 150
Database support for the broker . . . . . 119 Planning for data conversion . . . . . . . . 152
System requirements for z/OS components . . . 120
Hardware requirements . . . . . . . . . 120 Chapter 10. Managing your WebSphere MQ
Disk space required . . . . . . . . . . 120 Integrator network . . . . . . . . . . . 155
Software requirements . . . . . . . . . 120 Managing broker domain components . . . . . 155
Database support . . . . . . . . . . . . 121 Managing application and business processes 156
Client requirements . . . . . . . . . . . 121 Monitoring and analysis. . . . . . . . . . 157
License information . . . . . . . . . . . 121 Problem determination . . . . . . . . . 157
National language support . . . . . . . . . 122 Traces . . . . . . . . . . . . . . 157
Supported codesets . . . . . . . . . . 123 Messages . . . . . . . . . . . . . 159
Information available from other sources . . 159
Chapter 9. Planning your WebSphere MQ Managing workload and performance . . . . 160
Integrator network . . . . . . . . . . . 125 Using MQSeries trusted applications . . . 160
Planning WebSphere MQ Integrator resources . . 125 Tuning message flow performance . . . . 161
Naming conventions . . . . . . . . . . 125 System management . . . . . . . . . . 161
WebSphere MQ Integrator resources . . . . 125
MQSeries resources . . . . . . . . . 126 Chapter 11. Enhancing your broker domain . . 163
Database resources . . . . . . . . . 127 General guidance for writing plug-ins . . . . . 163
Broker domain basics. . . . . . . . . . 127 Writing your own message processing node types 164
Setting up publish/subscribe collectives . . 128 Writing your own parsers . . . . . . . . . 164
Employing topic-based security . . . . . 129

© Copyright IBM Corp. 2000, 2002 107

 The information here is an introduction to the detail provided in the WebSphere
MQ Integrator Administration Guide and in the WebSphere MQ Integrator for z/OS
Customization and Administration Guide.

108 WebSphere® MQ Integrator: Introduction and Planning

Chapter 8. System requirements
This chapter summarizes the hardware and software requirements for WebSphere
MQ Integrator. It also includes information about licensing agreements and
national language support.

The information provided here is an overview: for full details you must refer to the
WebSphere MQ Integrator Installation Guide for your operating system, or to the
WebSphere MQ Integrator for z/OS Program Directory and to the Readme.txt file
provided on your product CD which gives the latest and most complete
information.

Summary of system requirements

WebSphere MQ Integrator is supported on these operating systems:
v AIX
v HP-UX
v Solaris
v Windows NT — this includes Windows NT Server 4.0 running on an Integrated
IBM Eserver xSeries installed in an IBM Eserver iSeries 400 (AS/400)
v Windows 2000
v z/OS

Table 3 on page 110 summarizes the installation options for all components of each
WebSphere MQ Integrator product.

The key points to note are:

v You can install and configure the broker only on the operating system for which
you have purchased WebSphere MQ Integrator.
v You can install the User Name Server on either Windows NT or the operating
system for which you have purchased WebSphere MQ Integrator.
v You must install and configure the Configuration Manager and Control Center
on Windows NT.

The WebSphere MQ Integrator for AIX, WebSphere MQ Integrator for HP-UX

WebSphere MQ Integrator for Sun Solaris and WebSphere MQ Integrator for z/OS
products include the WebSphere MQ Integrator for Windows NT and Windows
2000 CD from which you must install the components that run on Windows NT.
Full package details are provided in Appendix B, “The product packages” on
page 189.

© Copyright IBM Corp. 2000, 2002 109

Systems summary
Table 3. Summary of installation options
Product Component System to install on
WebSphere MQ Configuration Manager Windows NT and Windows 2000
Integrator for AIX
Control Center Windows NT and Windows 2000
Broker AIX only
User Name Server¹ AIX, Windows NT or Windows
2000
SDK AIX only
Online documentation AIX, Windows NT or Windows
2000
WebSphere MQ Configuration Manager Windows NT and Windows 2000
Integrator for HP-UX
Control Center Windows NT and Windows 2000
Broker HP-UX only
User Name Server¹ HP-UX, Windows NT or
Windows 2000
SDK HP-UX only
Online documentation HP-UX, Windows NT or
Windows 2000
WebSphere MQ Configuration Manager Windows NT and Windows 2000
Integrator for Sun
Control Center Windows NT and Windows 2000
Solaris
Broker Solaris only
User Name Server¹ Solaris, Windows NT or
Windows 2000
SDK Solaris only
Online documentation Solaris, Windows NT or
Windows 2000
WebSphere MQ Configuration Manager Windows NT and Windows 2000
Integrator for z/OS
Control Center Windows NT and Windows 2000
Broker z/OS only
User Name Server¹ z/OS, Windows NT or Windows
2000
SDK z/OS only
Online documentation Windows NT and Windows 2000
WebSphere MQ All components including online Windows NT and Windows 2000
Integrator for documentation
Windows NT and
Windows 2000
Notes:
1. If you choose to control topic-based security on Windows NT or Windows 2000, you
can install the User Name Server component on Windows NT or Windows 2000. A
single licence entitles you to configure a single User Name Server. Therefore if you
install the User Name Server component on Windows NT or Windows 2000, you
cannot configure a second User Name Server on UNIX or z/OS systems.

The following sections identify the requirements for the components that can be
installed on each operating system.

110 WebSphere® MQ Integrator: Introduction and Planning

 AIX requirements

System requirements for AIX components

This section summarizes the system requirements for the following components
that can be installed on AIX:
v Broker
v User Name Server
v New Era of Networks Rules and Formatter Support
v Tivoli Interface
v SDK
v Online documentation
v NLS messages

Hardware requirements
The hardware required for AIX components of WebSphere MQ Integrator are:
v One of the following:
– IBM Eserver pSeries™ (RS/6000®)
– IBM RS/6000 POWERserver®
– IBM RS/6000 POWERstation
– IBM Scalable POWERparallel®
v Any communications hardware supporting NetBIOS, SNA LU6.2, SPX, or
TCP/IP
v A minimum of 512MB of RAM to support run-time operation

Disk space required

The installation requirements depend on which components you install. Full details
are in the WebSphere MQ Integrator for AIX Installation Guide: requirements range
from a minimum of 280MB to approximately 400MB.

Temporary space of approximately 150MB is required in the /tmp directory. This

temporary space is freed up when installation is complete.

Software requirements
The following software products are prerequisites for operating WebSphere MQ
Integrator. If AIX, MQSeries, and the IBM Runtime Environment for the Java™
Platform are not at the correct level, installation will not continue. For optional
products that you can use with WebSphere MQ Integrator see the WebSphere MQ
Integrator for AIX Installation Guide.

Minimum supported levels are shown. Later compatible levels, if any, are
supported unless otherwise stated. You must refer to the WebSphere MQ Integrator
for AIX Installation Guide and the Readme.txt file to check latest Corrective Service
Diskette (CSD) and FixPack details for these products.

AIX
AIX version 4.3.3 or version 5.1.

Java
You must ensure that your AIX system includes IBM Runtime Environment for
AIX, Java™ edition, version 1.3. This level is supplied as part of the AIX product
installation, and is included in the WebSphere MQ Integrator package.

MQSeries for AIX

MQSeries for AIX Version 5.2

Chapter 8. System requirements 111

AIX requirements
Databases
The WebSphere MQ Integrator broker requires access to a database for internal
caching and for storing internal control information.

If you already have a database product in the supported list below, you can use it
to support WebSphere MQ Integrator.

Supported databases are:

v DB2 Universal Database for AIX Version 6.1 or 7.1 (Enterprise Edition, Connect
Enterprise Edition, or Extended Enterprise Edition)
v Oracle Version 8.1.6 or 8.1.7
v Sybase Version 12

Each database requires an ODBC driver: the driver for DB2 is supplied by DB2, the
drivers for Oracle and Sybase are included with WebSphere MQ Integrator.

If you do not have a suitable database installed, you can install DB2 Version 7.1,
which is included in the WebSphere MQ Integrator package. DB2 installation
requires an additional 250MB of disk storage. You also need approximately 10MB
for each set of tables you create (for the broker tables, for the configuration
repository, and for message repository). DB2 has no additional prerequisites.

This DB2 product has restricted license terms and agreements. You must only use
this DB2 installation in association with your licensed use of WebSphere MQ
Integrator for message management, and only the WebSphere MQ Integrator
components can make calls to the DB2 database.

The use of a database by the WebSphere MQ Integrator components is

independent of the use of databases by your applications. You are not restricted to
the databases listed here for application and data storage and retrieval. If you have
a requirement for XA coordination, your choice of database can be affected. See the
WebSphere MQ Integrator Administration Guide for more details about how
WebSphere MQ Integrator supports transactions.

For further details of database support for brokers, see Table 4 on page 121.

112 WebSphere® MQ Integrator: Introduction and Planning

 HP-UX requirements

System requirements for HP-UX components

This section summarizes the system requirements for the following components
that can be installed on HP-UX:
v Broker
v User Name Server
v New Era of Networks Rules and Formatter Support
v SDK
v Online documentation
v NLS messages

Hardware requirements
The hardware requirements for the HP-UX components of WebSphere MQ
Integrator are:
v Any HP-UX desktop or server system
v Any communications hardware supporting NetBIOS, SNA LU6.2, SPX, or
TCP/IP
v A minimum of 512MB of RAM to support runtime operation

Disk space required

The installation requirements depend on which components you install. Full details
are in the WebSphere MQ Integrator for HP-UX Installation Guide: requirements range
from a minimum of 280MB to approximately 400MB.

Temporary space of approximately 150MB is required in the /tmp directory. This

temporary space is freed up when installation is complete.

Software requirements
The following software products are prerequisites for operating WebSphere MQ
Integrator. These prerequisites are checked at installation time but do not cause
installation to fail. However, you must ensure these prerequisite products are
available before you start to use WebSphere MQ Integrator. For optional products
that you can use with WebSphere MQ Integrator see the WebSphere MQ Integrator
for HP-UX Installation Guide.

Minimum supported levels are shown. Later compatible levels, if any, are
supported unless otherwise stated. You must refer to the WebSphere MQ Integrator
for HP-UX Installation Guide and the Readme.txt file to check latest Corrective
Service Diskette (CSD) and FixPack details for these products.

HP-UX
HP-UX Version 11

MQSeries for HP-UX

IBM MQSeries for HP-UX Version 5.2

Databases
The WebSphere MQ Integrator broker requires access to a database for internal
caching and for storing internal control information.

If you already have a database product in the supported list below, you can use it
to support WebSphere MQ Integrator.

Chapter 8. System requirements 113

HP-UX requirements
Supported databases are:
v DB2 Universal Database for HP-UX Version 7.1 (Enterprise Edition, Connect
Enterprise Edition, or Extended Enterprise Edition)
v Oracle Version 8.1.6 or 8.1.7
v Sybase Version 12

Each database requires an ODBC driver: the driver for DB2 is supplied by DB2, the
drivers for Oracle and Sybase are included with WebSphere MQ Integrator.

If you do not have a suitable database installed, you can install DB2 Version 7.1,
which is included in the WebSphere MQ Integrator package.

DB2 installation requires an additional 250MB of disk storage. You also need
approximately 10MB for each set of tables you create (for the broker tables, for the
configuration repository, and for message repository).

DB2 has no additional prerequisites.

This DB2 product has restricted license terms and agreements. You must only use
this DB2 installation in association with your licensed use of WebSphere MQ
Integrator for message management, and only the WebSphere MQ Integrator
components can make calls to the DB2 database.

The use of a database by the WebSphere MQ Integrator components is

independent of the use of databases by your applications. You are not restricted to
the databases listed here for application and data storage and retrieval. If you have
a requirement for XA coordination, your choice of database can be affected. See the
WebSphere MQ Integrator Administration Guide for more details about how
WebSphere MQ Integrator supports transactions.

For further details of database support, see Table 4 on page 121.

114 WebSphere® MQ Integrator: Introduction and Planning

 Solaris requirements

System requirements for Solaris components

This section summarizes the system requirements for the following components
that can be installed on Solaris:
v Broker
v User Name Server
v New Era of Networks Rules and Formatter Support
v Tivoli Interface
v SDK
v Online documentation
v NLS messages

Hardware requirements
The hardware requirements for the Solaris components of WebSphere MQ
Integrator are:
v Any Sun SPARC or UltraSPARC desktop or server system
v Any communications hardware supporting NetBIOS, SNA LU6.2, SPX, and
TCP/IP
v A minimum of 512MB of RAM to support runtime operation

Disk space required

The installation requirements depend on which components you install. Full details
are in the WebSphere MQ Integrator for Sun Solaris Installation Guide: requirements
range from a minimum of 280MB to approximately 400MB.

Temporary space of approximately 150MB is required in the /tmp directory. This

temporary space is freed up when installation is complete.

Software requirements
The following software products are prerequisites for operating WebSphere MQ
Integrator. These prerequisites are checked at installation time but do not cause
installation to fail. However, you must ensure these prerequisite products are
available before you start to use WebSphere MQ Integrator. For optional products
that you can use with WebSphere MQ Integrator see the WebSphere MQ Integrator
for Sun Solaris Installation Guide.

Minimum supported levels are shown. Later compatible levels, if any, are
supported unless otherwise stated. You must refer to the WebSphere MQ Integrator
for Sun Solaris Installation Guide and the Readme.txt file to check latest Corrective
Service Diskette (CSD) and FixPack details for these products.

Solaris
Solaris 8 with the latest Sun Microsystems, Inc., recommended patches

MQSeries for Solaris

IBM MQSeries for Solaris Version 5.2

Databases
The WebSphere MQ Integrator broker requires access to a database for internal
caching and for storing internal control information.

Chapter 8. System requirements 115

Disk space
If you already have a database product in the supported list below, you can use it
to support WebSphere MQ Integrator.

Supported databases are:

v DB2 Universal Database for Solaris Version 6.1 or 7.1 (Enterprise Edition,
Connect Enterprise Edition, or Extended Enterprise Edition)
v Oracle Version 8.1.6 or 8.1.7
v Sybase Version 12

Each database requires an ODBC driver: the driver for DB2 is supplied by DB2, the
drivers for Oracle and Sybase are included with WebSphere MQ Integrator.

If you do not have a suitable database installed, you can install DB2 Version 7.1,
which is included in the WebSphere MQ Integrator package.

DB2 installation requires an additional 250MB of disk storage. You also need
approximately 10MB for each set of tables you create (for the broker tables, for the
configuration repository, and for message repository).

DB2 has no additional prerequisites.

This DB2 product has restricted license terms and agreements. You must only use
this DB2 installation in association with your licensed use of WebSphere MQ
Integrator for message management, and only the WebSphere MQ Integrator
components can make calls to the DB2 database.

The use of a database by the WebSphere MQ Integrator components is

independent of the use of databases by your applications. You are not restricted to
the databases listed here for application and data storage and retrieval. If you have
a requirement for XA coordination, your choice of database can be affected. See the
WebSphere MQ Integrator Administration Guide for more details about how
WebSphere MQ Integrator supports transactions.

For further details of database support, see Table 4 on page 121.

116 WebSphere® MQ Integrator: Introduction and Planning

 Windows requirements

System requirements for Windows NT and Windows 2000 components

This section summarizes the system requirements for the following components
that can be installed on Windows NT and Windows 2000:
v Configuration Manager
v Control Center
v Broker
v User Name Server
v New Era of Networks Rules and Formatter Support
v Tivoli Interface
v SDK
v Online documentation
v NLS messages

Hardware requirements
The hardware requirements for the Windows NT components are:
v Any Year 2000 ready Intel Pentium® II (or above) processor-based IBM PC
machine or compatible, that is explicitly compatible and fully capable of running
the specified operating system, all the corresponding supporting software shown
below, and any associated applications unmodified. This machine could be an
Integrated IBM Eserver xSeries Server installed in an IBM Eserver iSeries 400
(AS/400).
v Any communications hardware supporting NetBIOS, SNA LU 6.2, SPX, and
TCP/IP.
v If all components are installed on a single system (WebSphere MQ Integrator for
Windows NT and Windows 2000 only), a minimum of 512MB of RAM are
recommended to support run-time operation.
v If only the Configuration Manager and Control Center components are installed
on a single system, a minimum of 300MB of RAM are recommended to support
runtime operation.
v If the Configuration Manager, the Control Center, and the User Name Server are
installed on a single system, a minimum of 350MB of RAM are recommended to
support runtime operation.

Disk space required

The installation requirements depend on which components you install and how
much working space you need. See the MQSeries MQ Integrator Installation Guide
for the appropriate operating system for full details.

If DB2 is installed by the WebSphere MQ Integrator installation program, an

additional 250MB is required.

Temporary space of 150MB (for a full installation) to 300MB (for a custom

installation) is required on the operating system drive.

Software requirements
The following software products are prerequisites for operating WebSphere MQ
Integrator. These prerequisites are checked at installation time but do not cause
installation to fail. However, you must ensure these prerequisite products are
available before you start to use WebSphere MQ Integrator. For optional products
that you can use with WebSphere MQ Integrator see the WebSphere MQ Integrator
for Windows NT and Windows 2000 Installation Guide.

Chapter 8. System requirements 117

Windows requirements
Minimum supported levels are shown. Later compatible levels, if any, are
supported unless otherwise stated. You must refer to the WebSphere MQ Integrator
for Windows NT and Windows 2000 Installation Guide and the Readme.txt file to
check latest Corrective Service Diskette (CSD) and FixPack details for these
products.

Windows NT
Microsoft Windows NT Version 4.0, including TCP/IP, NetBIOS, and SPX, with
Service Pack 6A, which provides relevant Year 2000 fixes and Euro support.

Both Windows NT Workstation and Windows NT Server products are supported.

You can download Windows NT upgrades from the Microsoft Web site at:
http://support.microsoft.com/directory/

If you intend to run the Tour feature of the Control Center, you must install
Microsoft Internet Explorer Version 5.

MQSeries for Windows NT and Windows 2000

IBM MQSeries for Windows NT and Windows 2000 Version 5.2.1.

MQSeries for Windows NT requires a number of other software products to install

and operate a server successfully.

MQSeries for Windows NT server prerequisites are:

v Internet Explorer Version 5.
This is available from the Microsoft Web site at:
http://www.microsoft.com
v Active Directory Services Interface Version 2.0.
This is provided on the MQSeries CD.
v Microsoft Management Console Version 1.1.
This is provided on the MQSeries CD.
v Microsoft Data Access Component (MDAC) Version 2.5
WebSphere MQ Integrator Version 2.1 uses ODBC drivers, and these require that
the level of the installed Microsoft Data Access Component (MDAC) on your
system is 2.5. The install program for WebSphere MQ Integrator Version 2.1
checks this level and issues a warning if there is a need to update your system,
however the install does not automatically upgrade your system. In order to
update your system you can run the MDAC setup program from the
supplemental materials CD supplied with the product. You are recommended to
download the latest level of MDAC from http://www.microsoft.com/ — note
that different countries require different setup programs.

If you install only an MQSeries client with your WebSphere MQ Integrator

components, check the client installation details in the MQSeries Release Notes
folder to determine the client’s prerequisites.

Database support for the Configuration Manager

The Configuration Manager requires DB2 Universal Database for Windows NT
Version 6.1 or 7.1 (Enterprise Edition, Connect Enterprise Edition, or Extended
Enterprise Edition). This database can also be used with the broker component.
The installation process checks for a current DB2 installation, and determines the
level installed. If DB2 is not present, or needs to be upgraded, the WebSphere MQ
Integrator installation program launches the installation program for DB2 7.1,
which is included in the WebSphere MQ Integrator package.

118 WebSphere® MQ Integrator: Introduction and Planning

 Windows requirements
Database support for the broker
WebSphere MQ Integrator broker and Configuration Manager components require
access to a database for internal caching and for storing internal control
information. The Control Center and User Name Server do not need access to a
database.

You can use any of the following database products:

v DB2 Universal Database for Windows NT Version 6.1 or 7.1 (Enterprise Edition,
Connect Enterprise Edition, or Extended Enterprise Edition). This database is
also used by the Configuration Manager.
v Microsoft SQL Server Version 6.5 with Service Pack 5a or Version 7.0 with
Service Pack 2, both of which are Year 2000 ready. 1
v Oracle Version 8.1.6 or 8.1.7.
v Sybase Version 12.

The installation program checks for a current DB2 installation, and determines the
level installed. If DB2 is not present, or needs to be upgraded, installation asks you
if you want to install DB2 7.1 from the WebSphere MQ Integrator Version 2.1
product package. You can cancel this if you are using another database, or plan to
install a suitable database product after you have installed WebSphere MQ
Integrator.

Each database requires an ODBC driver: the drivers for DB2 and SQL Server are
supplied by the database product, the drivers for Oracle and Sybase are included
with WebSphere MQ Integrator.

DB2 installation requires an additional 420MB of disk storage. You also need
approximately 10MB for each set of tables you create (for the broker tables, for the
configuration repository, and for message repository). DB2 has no additional
prerequisites.

This DB2 product has restricted license terms and agreements. You must only use
this DB2 installation in association with your licensed use of WebSphere MQ
Integrator for message management, and only the WebSphere MQ Integrator
components can make calls to the DB2 database.

The use of a database by the WebSphere MQ Integrator components is

independent of the use of databases by your applications. You are not restricted to
the databases listed here for application and data storage and retrieval. If you have
a requirement for XA coordination, your choice of database can be affected. See the
WebSphere MQ Integrator Administration Guide for more details about how
WebSphere MQ Integrator supports transactions.

For further details of database support, see Table 4 on page 121.

1. SQL Server 6.5 is not supported on Windows 2000. However, SQL Server 2000 is supported. See Table 4 on page 121.

Chapter 8. System requirements 119

z/OS requirements

System requirements for z/OS components

This section summarizes the system requirements for the following components
that can be installed on z/OS:
v Broker
v User Name Server
v SDK
v Online documentation
v New Era of Networks Rules and Formatter Support

This section does not provide you with the detailed information that you need to
perform an installation of WebSphere MQ Integrator. That information is provided
in the WebSphere MQ Integrator program directory.

Hardware requirements
The hardware requirements for the z/OS components are:
v Any processor that supports OS/390 or z/OS.

The minimum real storage requirements for a broker are around 110MB plus
230MB for each execution group. A User Name Server requires a minimum of
110MB of real storage.

Disk space required

If z/OS does not have sufficient real storage to accommodate your WebSphere MQ
Integrator brokers and User Name Servers, you must ensure that enough page data
set space is available.

Software requirements
The following software products are prerequisites for operating WebSphere MQ
Integrator. These prerequisites are checked at installation time but do not cause
installation to fail. However, you must ensure that these prerequisite products are
available before you start to use WebSphere MQ Integrator.

Minimum supported levels are shown. Any later, compatible, levels are supported,
unless otherwise stated.
v OS/390 (Versions 2.8, 2.9 or 2.10) or z/OS (Versions 1.1 or 1.2)
v OS/390 UNIX System Services (USS) Version 2.8 or later
v Hierarchical File System (HFS)
v Recoverable Resource Services (RRS)
v Language Environment Version 2.8 or later
v IBM Runtime Environment for the Java™ Platform, Version 1.3
v DB2 Version 6.1 or Version 7.1
v MQSeries for OS/390, Version 5.2

120 WebSphere® MQ Integrator: Introduction and Planning

 Databases

Database support
Table 4 summarizes the supported versions of databases that you can use for the
broker database and for user databases accessed in message flow nodes on each
operating system.
Table 4. Supported databases for brokers and user data
Operating system DB2¹² Microsoft SQL Oracle¹ Sybase¹
Server
AIX 6.1³⁴ not applicable 8.1.6⁴ 12
7.1³ 8.1.7
HP-UX 7.1³ not applicable 8.1.6 12⁵
8.1.7
Solaris 6.1³ not applicable 8.1.6 12
7.1³ 8.1.7
Windows NT 6.1³ 6.5 plus SP5a 8.1.6 12
7.1³ 7.0 plus SP2 8.1.7
Windows 2000 6.1³ 7.0 plus SP2 8.1.6 12
7.1³ 2000 8.1.7
OS/390⁶ 6.1⁶ not applicable not supported not applicable
7.1⁶
z/OS™ 6.1⁶ not applicable not supported not applicable
7.1⁶
Notes:
1. Supported releases of DB2, Oracle, and Sybase can participate as a Resource Manager in a distributed XA
transaction, and can be coordinated by MQSeries as the XA Transaction Manager. In WebSphere MQ Integrator,
this is referred to as supporting a globally coordinated message flow. On z/OS, all transactions are coordinated
by RRS.
2. You must use DB2 for the configuration and message repository databases maintained by the Configuration
Manager. No other database is supported for this purpose.
3. Please check the Readme.txt file for your product to check if a Fixpack is required.
4. This version of the database is not supported on AIX Version 5.1. It is supported on AIX Version 4.3.3.
5. You must apply Sybase patch EBF9641 on HP-UX.
6. PTFs are required with this product. See the WebSphere MQ Integrator for z/OS Program Directory for further
details.

Client requirements
You can run WebSphere MQ Integrator applications on all platforms for which
MQSeries provides a client.

License information
Under the terms of the WebSphere MQ Integrator Version 2.1 license agreement,
you can install one instance of each component at any one time on any one system,
with the exception of the Control Center. You can install the Control Center on
multiple systems provided that each Control Center is interacting with the same
single Configuration Manager. You can create multiple brokers on a single system.

For details of which component can be installed on which operating system, see
Table 3 on page 110.

Chapter 8. System requirements 121

National language support

National language support

WebSphere MQ Integrator Version 2.1 is enabled for national language support.
The user interface and message catalogs are provided in the following languages
on distributed systems:
v Brazilian Portuguese
v French
v German
v Italian
v Japanese
v Korean
v Simplified Chinese
v Spanish
v Traditional Chinese
v US English
The message catalogs are provided in the following languages on z/OS:
v Japanese
v Simplified Chinese
v US English
The messages written to the z/OS operator console (which are a subset of the
messages written to the syslog) are in US English only, and are written in mixed
case or in uppercase depending on your chosen system configuration.

WebSphere MQ Integrator provides a selection of message catalogs that are used

by the product components to report any problems that occur. Products that are
used in conjunction with WebSphere MQ Integrator might cause WebSphere MQ
Integrator to report errors using its message catalogs, or might report problems
using their own techniques.

You must refer to the documentation supplied with any other products that you
use to determine the process they employ. In particular, you must check the
documentation supplied by the databases that you use, the New Era of Networks
Rules and Formatter Support documentation, and documentation provided with
any plug-in node or parser that you integrate into the WebSphere MQ Integrator
environment.

The New Era of Networks graphical user interfaces (Formatter, Rules, and Visual
Tester), supplied on Windows NT, are available in US English and Japanese only.

You can install WebSphere MQ Integrator and MQSeries in any supported

language; all language versions for each product are compatible with all language
versions for the other product. All languages for the MQSeries messaging products
are included on the MQSeries server CD supplied with WebSphere MQ Integrator.

All messages generated for internal intercomponent message exchange (for

example, deployed configuration messages and log files for mqsireadlog) are
generated in code page 1208 (utf-8).

DB2 Version 7.1 is fully NLS-enabled and is provided in all supported languages.

For further information about changing language settings, refer to the WebSphere
MQ Integrator Administration Guide.

122 WebSphere® MQ Integrator: Introduction and Planning

 National language support
Supported codesets
WebSphere MQ Integrator Version 2.1 can process and construct application
messages in any code page for which MQSeries supports conversion to and from
Unicode, on all operating systems. Supported code pages are listed in the MQSeries
Application Programming Reference.

This behavior might be affected by the use of other products in conjunction with
WebSphere MQ Integrator Version 2.1. You must check the documentation for other
products, including any databases that you use, and the New Era of Networks
Rules and Formatter Support component, for further specific codeset support
information.

Chapter 8. System requirements 123

National language support

124 WebSphere® MQ Integrator: Introduction and Planning

Chapter 9. Planning your WebSphere MQ Integrator network
This chapter provides information about how to plan a network of WebSphere MQ
Integrator resources that supports your business processes. It discusses:
v “Planning WebSphere MQ Integrator resources”
v “Designing the MQSeries infrastructure” on page 131
v “Planning database resources” on page 137
v “Planning security” on page 140
v “Planning for data conversion” on page 152

Planning WebSphere MQ Integrator resources

When you plan an WebSphere MQ Integrator network, you must consider what
components you will install, and where, and how you will organize and use them
together. The information here helps you to do that, by explaining the initial
considerations and by identifying decisions you must make.

Note: You must configure your broker domain subject to your license agreement,
described in “License information” on page 121.

The following areas are discussed:

v “Naming conventions”
v “Broker domain basics” on page 127
v “Client applications” on page 130

Naming conventions
When you plan a new WebSphere MQ Integrator network, one of your first tasks
must be to establish a convention for naming the resources that you create within
this network. There are three aspects to this:
v “WebSphere MQ Integrator resources”
v “MQSeries resources” on page 126
v “Database resources” on page 127

WebSphere MQ Integrator resources

A naming convention for WebSphere MQ Integrator resources throughout your
network ensures that names are unique, and that users creating new resources can
be confident of not introducing duplication or confusion.

The resources you must create and name within an WebSphere MQ Integrator
network are:
Brokers
When you create a broker, you give it a name that must be unique within
your broker domain. You must use the same name for the same broker
when you create it on the system in which it is installed (using the
command mqsicreatebroker) and when you create a reference to that broker
in the broker domain topology in the Control Center. The latter is a
representation of the physical broker (created by mqsicreatebroker) in the
configuration repository, and this single name links the two. Broker names
are case-sensitive except on Windows NT.
Execution groups
Each execution group name must be unique within a broker.

© Copyright IBM Corp. 2000, 2002 125

WebSphere MQ Integrator network
Message flows and message processing nodes
Each message processing node must be unique within the message flow it is
assigned to. For example, if you include two MQOutput nodes in a single
message flow, you must provide a unique name for each.
Message flow names must be unique within the broker domain. Any
reference to that name within the broker domain is always to the same
message flow. You can assign the same message flow to many brokers.
Message sets and messages
Each message name must be unique within the message set to which it
belongs.
Message set names must be unique within the broker domain. Any reference
to that name within the broker domain is always to the same message set.
You can therefore assign the same message set to many brokers.

The Configuration Manager and User Name Server are not allocated names when
you create them. They are identified only by the name of the MQSeries queue
manager that hosts the services they provide.

There are a few restrictions for naming resources: see the WebSphere MQ Integrator
Administration Guide and the WebSphere MQ Integrator for z/OS Customization and
Administration Guide for details.

MQSeries resources
All WebSphere MQ Integrator resources have dependencies on MQSeries services
and objects. You must therefore also consider what conventions to adopt for
MQSeries object names. If you already have an MQSeries naming convention, you
are recommended to use a compatible extension of this convention for WebSphere
MQ Integrator resources.

When you create a broker or a Configuration Manager, you must specify a queue
manager name. This queue manager is created for you if it does not already exist.
Because the broker and Configuration Manager each use a unique set of MQSeries
queues, they can share one queue manager, if appropriate. However, every broker
must have a dedicated queue manager. Note that the MQSeries Everyplace queue
manager name specified must be unique across MQSeries Everyplace and
MQSeries, within WebSphere MQ Integrator.

If you set up a User Name Server in your broker domain, this also uses a unique
set of MQSeries queues. The User Name Server can therefore also share a queue
manager with a broker, or the Configuration Manager, or both.

You must ensure that every queue manager name is unique within your network
of interconnected queue managers, whether or not every queue manager is in your
WebSphere MQ Integrator network. This ensures that each queue manager can
unambiguously identify the target queue manager to which any given message
must be sent, and that WebSphere MQ Integrator applications can also interact
with basic MQSeries applications.

MQSeries supports a number of objects defined to queue managers. These objects

(queues, channels, and processes) also have naming conventions and restrictions,
that are defined in the MQSeries MQSC Command Reference.

126 WebSphere® MQ Integrator: Introduction and Planning

 WebSphere MQ Integrator network
In summary, the restrictions are:
v All names must be a maximum of 48 characters in length (channels have a
maximum of 20 characters).
v The name of each object must be unique within its type (for example, queue or
channel).
v Names for all objects starting with the characters “SYSTEM.” are reserved for
use by IBM.

Database resources
You must consider the naming conventions you use for databases, both for
databases you create for WebSphere MQ Integrator product use (for broker tables,
the configuration repository, and the message repository), and for databases you
create for application use.

Your configuration and message repositories are owned and managed by the
Configuration Manager: because there is only one Configuration Manager you
should not find any conflict with names. Database tables used for brokers can be
unique and local to the broker, or can be shared because the rows of the tables
specific to each individual broker incorporate the name of the broker. You might
need to align the naming of all these databases with other databases that are in use
in your broker domain.

For details of the database tables created for WebSphere MQ Integrator use, see the
WebSphere MQ Integrator Installation Guide for your product.

You must also ensure that the databases used for application data (accessed
through message flows) are uniquely named throughout your network, so there is
no opportunity for confusion or error.

Broker domain basics

Before you start planning a full deployment of WebSphere MQ Integrator, you
must understand a few basic rules and recommendations:
v You must install and initialize a single Configuration Manager within your
broker domain. This component controls and maintains all configuration and
administration information for all the components, and the resources defined to
those components in the configuration repository. It also manages the message
repository that contains all definitions created through the Control Center. The
Configuration Manager therefore defines the scope of the broker domain. It is in
constant contact with all other components created and deployed in the broker
domain.
When you create the Configuration Manager, you specify the security domain
that is used to check users’ authority to complete tasks in the broker domain.
For a discussion of security in the broker domain, see “Planning security” on
page 140.
v You must install at least one Control Center. This provides your only means of
viewing and managing the configuration and message repositories maintained
by the Configuration Manager. The Control Center is a central point of control
for the business processes of your broker domain, enabling you to create and
modify messages and message flows, and assign and deploy these resources to
the brokers.
The Control Center does not control system administration aspects of the broker
domain. System administration (for example, creation and activation of a broker)
is supported by a set of commands.

Chapter 9. Planning your WebSphere MQ Integrator network 127

WebSphere MQ Integrator network
v You must install and initialize at least one broker. The broker supports the
services (defined as message flows acting on messages) that are required by your
applications. You must also use the Control Center to define this broker to the
Configuration Manager (using the same name in both places), and deploy the
broker domain topology, to register and activate this broker in the broker
domain. Deployment initiates the communications between the Configuration
Manager and the broker.

The WebSphere MQ Integrator Installation Guide illustrates a step-by-step approach to

setting up a very simple broker domain configuration using the components listed
above. It also illustrates how you can expand that simple broker domain by
creating a User Name Server to employ topic-based security.

The configuration tasks for establishing a broker domain are supported by a set of
commands you can enter at the command prompt. A subset of these commands (to
create, modify, and delete) are also available through a graphical administrative
interface, the WebSphere MQ Integrator Command Assistant. For example, you can
create a broker using the command mqsicreatebroker, delete it using the command
mqsideletebroker, and modify its properties using the command
mqsichangebroker. For full details of all these commands, see the WebSphere MQ
Integrator Administration Guide and the WebSphere MQ Integrator for z/OS
Customization and Administration Guide. For full details on the Command Assistant,
see the WebSphere MQ Integrator Administration Guide.

Setting up publish/subscribe collectives

A collective is a set of one or more brokers that are directly connected to each
other. A single broker can belong to only one collective. Brokers within one
collective can exist on the same physical system, or on separate systems.

A collective provides these benefits:

v Messages destined for a specific broker in the same collective are transported
directly to that broker and do not need to pass through any intermediate broker.
This improves broker performance and optimizes inter-broker publish/subscribe
traffic, relative to a hierarchical tree configuration.
v If your clients are geographically dispersed, you can set up a collective in each
location, and connect the collectives (by joining a single broker in each
collective) to optimize the flow of publications and subscription registrations
through the network.
v You can group clients according to the shared topics they publish and subscribe
to.
Clients that share common topics can connect to brokers within a collective. The
common publications are transported efficiently within the collective, because
they do not pass through any brokers that do not have clients with an interest in
those common topics.
v A client can connect to its nearest broker, to improve its own performance. The
broker receives all messages that match the subscription registration of the client
from all brokers within the collective.
Client application performance is also enhanced for any other service requested
from this broker, or the broker’s queue manager. A single client application can
use both publish/subscribe and point-to-point messaging.
v The number of clients per broker can be reduced by adding more brokers to the
collective to share workload within that collective.

128 WebSphere® MQ Integrator: Introduction and Planning

 WebSphere MQ Integrator network
Figure 19 illustrates one way of connecting your publish/subscribe brokers in
collectives.

Collective

Collective
Collective
Operating system
image
Collective

Collective

Collective

Figure 19. Collectives with a broker domain

When you create a collective, the Control Center ensures that the connections you
make to other collectives and brokers are valid. You are prevented from making
connections that would cause messages to cycle forever within the network. You
are also prevented from deploying a collective of brokers that does not have the
required MQSeries connections already defined.

Each broker in the collective maintains a list of its neighbors. A neighbor is a

broker in the same collective, or a broker outside its own collective to which it has
an explicit connection (that is, for which it is acting as a gateway). The complete
list of neighboring brokers forms a broker’s neighborhood.

Any broker with at least one deployed execution group can receive publications
and subscription registrations, and receive and pass on publications from or to its
neighbors, even if you have not assigned and deployed any message flow
containing a publication node to that broker.

Employing topic-based security

You can choose to limit application access to particular messages. For example, if a
client application publishes messages containing sensitive company finance
information, or personnel details, you might want to restrict who has access to
those messages.

If you want to restrict message access in this way, you must:

v Install and configure a User Name Server to provide information on the
principals valid in your broker domain.
When you create the User Name Server, you specify the security domain that is
used to check users’ authority to publish on and subscribe to specific topics, and
their authority to request persistent delivery. For a discussion of security in the
broker domain, see “Planning security” on page 140.

Chapter 9. Planning your WebSphere MQ Integrator network 129

 WebSphere MQ Integrator network
v Ensure that a topic is associated with every message that is to be restricted
(either specified explicitly in the message by the publisher, or associated with the
message by the input node when it gets the message from the input queue).
v Create Access Control Lists (ACLs), through the Control Center to associate
principals with topics.

| You are strongly recommended to configure only one User Name Server in your
| broker domain. However, in the following circumstances, you might consider
| creating more than one (subject to your license agreement), but be aware that this
| is currently untested and therefore not recommended.
v Performance
If you have a large number of brokers in your broker domain, the requests they
send to the User Name Server can be handled more quickly if there is more than
one User Name Server. You might also benefit if your broker domain
configuration is complex, and brokers can interact more efficiently (in terms of
network traffic) if more than one User Name Server is installed.
v Resilience
Although no standby mechanism is provided by WebSphere MQ Integrator, you
might want to be able to redirect requests to a second User Name Server if a
system error occurs on the system of your first User Name Server.

If you have more than one User Name Server, and more than one is active at the
same time, you must ensure that they all can reference a single source of principal
definitions.

You must also ensure that each User Name Server is associated with a unique
MQSeries queue manager, to ensure that the User Name Server associated with the
Configuration Manager and each broker can be identified, and that there is no
conflict in the User Name Server’s use of MQSeries fixed name queues.

For more details of administering User Name Servers in your broker domain, see
the WebSphere MQ Integrator Administration Guide and the WebSphere MQ Integrator
for z/OS Customization and Administration Guide.

Client applications
WebSphere MQ Integrator client applications are applications that use the services
provided by the message flows deployed within one or more brokers in the broker
domain.

These applications can use one of two techniques for gaining access to the broker’s
services:
v An application can use an MQSeries client connection. You can use all the
MQSeries clients that are supported by MQSeries Version 5.1 or later. This
allows you to connect applications running in a wide variety of environments
into your broker domain. An application running on the same system as the
queue manager to which it connects can also use a client connection.
v An application running on the same system as a broker can use a local
connection to the queue manager that hosts that broker.

For more details about applications, putting and getting messages, and the use of
MQSeries clients, see MQSeries Clients and the MQSeries Application Programming
Guide. WebSphere MQ Integrator does not impose any particular conditions or
restrictions on applications.

130 WebSphere® MQ Integrator: Introduction and Planning

 WebSphere MQ Integrator network
The Control Center application
The Control Center is a special WebSphere MQ Integrator client application. It uses
an MQSeries client for Java connection over TCP/IP to the broker that hosts the
Configuration Manager, regardless of whether the Configuration Manager is on the
same system as the Control Center or a different system.

When the Configuration Manager is created, the required server connection

channel is defined. This allows any number of Control Center clients to connect to
the Configuration Manager’s queue manager. When you invoke the Control Center,
it dynamically creates the client connection channel to complete the connection
with the Configuration Manager.

Designing the MQSeries infrastructure

WebSphere MQ Integrator depends on the MQSeries transport services to support
internally generated communications between components. Some of these
resources are created for you, when you create WebSphere MQ Integrator
components that depend on them. Others depend on the exact setup of your
broker domain, and you must therefore create these resources yourself.

Communications between WebSphere MQ Integrator components are

protocol-independent, with the exception of the connection between every instance
of the Control Center and the Configuration Manager. This must be a TCP/IP
connection, as must connections to the MQSeries Everyplace and SCADA nodes.
Other connections can use any of the protocols supported by the MQSeries
messaging product for the operating system for your WebSphere MQ Integrator
product.

Except for MQSeries Everyplace and SCADA applications, applications that use
broker services must also use MQSeries to send and receive all messages. The
resources required by your applications (queues and client connection and server
connection channels) are application specific, and you must therefore create these
resources yourself.

The information here concentrates on the specific requirements that WebSphere

MQ Integrator imposes on an MQSeries network. For a full description of
designing and connecting an MQSeries network, see MQSeries Intercommunication,
which covers the basics, such as setting up transmission queues and channels, in
detail.

For more specific details of how to implement the MQSeries infrastructure for your
WebSphere MQ Integrator broker domain, see the WebSphere MQ Integrator
Administration Guide and the WebSphere MQ Integrator for z/OS Customization and
Administration Guide.

This section includes the following information:

v “MQSeries resources for brokers” on page 132
v “MQSeries resources for the Configuration Manager” on page 132
v “MQSeries resources for the User Name Server” on page 133
v “MQSeries resources for the Control Center” on page 133
v “MQSeries resources for client applications” on page 135
v “MQSeries clusters” on page 135

Chapter 9. Planning your WebSphere MQ Integrator network 131

MQSeries
MQSeries resources for brokers
Each broker depends on a number of MQSeries resources, some of which are
always required, others are dependent on the broker domain setup:
1. Each broker must be associated with a queue manager to host its services. You
must specify a queue manager name when you create the broker. If this queue
manager does not exist, it is created for you. However, this is not the case for
MQSeries Integrator on z/OS, you must create a queue manager in MQSeries
for your broker. Refer to the WebSphere MQ Integrator for z/OS Customization and
Administration Guide for more details.
The broker cannot share a queue manager with any other broker. It can share a
queue manager with the Configuration Manager (if the broker is on Windows
NT), or the User Name Server, or both.
The broker and its queue manager can share the same name, subject to naming
restrictions for both products.
2. Each broker must have a number of fixed-name queues on its queue manager.
These allow it to exchange information with other components in the broker
domain. These queues are defined for you when the broker is created. The use
of these fixed-name queues dictates that each broker to be hosted by a unique
queue manager.
3. Each broker must communicate with the Configuration Manager. If the broker
and the Configuration Manager do not share a queue manager, you must
define the channels and transmission queues that support communications
between the two queue managers.
4. If you have included a User Name Server in your broker domain, each broker
must communicate with it. If the broker and the User Name Server do not
share a queue manager, you must define transmission queues and channels that
support two-way communications between the two queue managers.
5. The broker’s queue manager must have a listener to receive messages from
other components that do not share its queue manager, and from clients on
other physical systems. You must create a listener for every protocol used for
connections to the broker. If any connection uses the TCP/IP protocol, you
must decide which port the listener must listen on.
6. If the broker is connected to other brokers, either in a collective, or to
communicate with another collective, the queue manager needs transmission
queues and channel definitions to support two-way communications with each
of the other brokers’ queue managers.

MQSeries resources for the Configuration Manager

The Configuration Manager depends on a number of MQSeries resources, some of
which must be available, others are dependent on the broker domain setup:
1. The Configuration Manager must be associated with a queue manager to host
its services. You must specify a queue manager name when you create the
Configuration Manager. If this queue manager does not exist, it is created for
you. The Configuration Manager can share a queue manager with a broker, or
the User Name Server, or both if they are on Windows NT.
2. The Configuration Manager must have a number of fixed-name queues on its
queue manager. These allow it to exchange information with other components
in the broker domain. These queues are defined for you when the
Configuration Manager is created.
3. The Configuration Manager must communicate with every broker in the broker
domain. You must define transmission queues and channels to support

132 WebSphere® MQ Integrator: Introduction and Planning

 MQSeries
two-way communications between the Configuration Manager and every
broker except the one (if defined) that shares its queue manager.
4. If you have included a User Name Server in your broker domain, the
Configuration Manager must communicate with it. If the Configuration
Manager and the User Name Server do not share a queue manager, you must
define transmission queues and channels to support two-way communications
between the two queue managers.
5. The Configuration Manager’s queue manager must have a listener to receive
messages from the Control Center, and from other components and clients that
do not share its queue manager. You must create a listener for every protocol
used for the inter component connections. If the connection is TCP/IP you
must also decide which port the listener must listen on: no other listener must
be active on this port.
6. The Configuration Manager’s queue manager must have a server connection
This is defined for you when the Configuration Manager is created. Every
Control Center client can use this single definition.

MQSeries resources for the User Name Server

The User Name Server depends on a number of MQSeries resources, some of
which must be available, others are dependent on the broker domain setup:
1. The User Name Server must be associated with a queue manager to host its
services. You must specify a queue manager name when you create the User
Name Server. If this queue manager does not exist, it is created for you.
However, this is not the case for MQSeries Integrator on z/OS, you must create
a queue manager in MQSeries for your broker. Refer to the WebSphere MQ
Integrator for z/OS Customization and Administration Guide for more details.
The User Name Server can share a queue manager with a broker, or the
Configuration Manager, or both, if they are on Windows NT.
2. The User Name Server must have a number of fixed-name queues on its queue
manager. These allow it to exchange information with other components in the
broker domain. These queues are defined for you when the User Name Server
is created.
3. The User Name Server must communicate with the Configuration Manager. If
the two do not share a queue manager, you must define the transmission
queues and channels to support two-way communications between the two
queue managers.
4. The User Name Server must communicate with every broker in the broker
domain. You must define transmission queues and channels to support
two-way communications between the User Name Server and every broker
except the one (if defined) that shares its queue manager.
5. The User Name Server’s queue manager must have a listener to receive
messages from other components that do not share its queue manager. You
must create a listener for every protocol used for connections to the User Name
Server. If you create a TCP/IP listener, you must also decide which port it must
listen on.

MQSeries resources for the Control Center

The Control Center depends on a number of required MQSeries resources:
1. The fixed-name queues defined by the Configuration Manager (described
above).
2. The Configuration Managers’s listener (described above).

Chapter 9. Planning your WebSphere MQ Integrator network 133

MQSeries
3. The server connection defined to the Configuration Manager’s queue manager
(described above). This is always defined as a TCP/IP connection and cannot
be changed.
4. The client connection. This is dynamically created when you initialize the
Control Center.

All necessary resources are defined and created for you, and you do not have to
take any additional action to enable the Control Center.

134 WebSphere® MQ Integrator: Introduction and Planning

 MQSeries
MQSeries resources for client applications
A client application can run on a system anywhere in the MQSeries network. The
application can access WebSphere MQ Integrator services in two ways.
1. The application can make a local connection to either:
v The broker’s queue manager
You do not have to define any MQSeries or MQSeries Everyplace resources
to support this client configuration.
v Another queue manager in the network
You must ensure that definitions are in place to support communications
between the queue manager to which the client has connected and the queue
manager that hosts the broker that provides the required service.
2. The application can make an MQSeries or MQSeries Everyplace client
connection to either:
v The broker’s queue manager
You must set up the appropriate client connection and server connection
definitions to support this option.
v Another queue manager in the network
You must ensure that definitions are in place to support communications
between the queue manager to which the client has connected and the queue
manager that hosts the broker that provides the required service.

MQSeries applications can only get messages from queues owned by the queue
manager to which it is connected, although MQSeries Everyplace supports a
″remote get″ function. Therefore, if an application expects to receive messages from
a queue populated by a service within a particular broker and owned by that
broker’s queue manager, it must connect to that broker’s queue manager (either
local, or using an MQSeries or MQSeries Everyplace client connection).

An application that puts messages, however, can be connected to any queue

manager in the network, provided that the queue manager can resolve the target
destination in some way. In all cases, the queue manager to which the client
application is connected must know the whereabouts of the queue or queues to
which the application puts messages (for example using remote queue definitions).

MQSeries clusters
When you design the MQSeries network underlying your WebSphere MQ
Integrator broker domain, you must consider whether it is desirable to use
clustering. Queue manager clusters bring two significant benefits:
Reduced system administration
Clusters need fewer definitions to establish a network, and allow you to
set up and change your network more quickly and easily.
Increased availability and workload balancing
In addition to simpler administration, you can benefit by defining instances
of the same queue on more than one queue manager, thus distributing
workload through the cluster.

You can use clusters with WebSphere MQ Integrator, but must consider the
following points:
For broker, Configuration Manager, and User Name Server administration:
If you define the queue managers that support your brokers, the
Configuration Manager, and the User Name Server to a cluster, you can

Chapter 9. Planning your WebSphere MQ Integrator network 135

MQSeries
benefit from the simplified administration provided by MQSeries clusters.
You might find this particularly relevant for the brokers in a collective,
which must all have MQSeries interconnections.
For SYSTEM.BROKER queues:
The SYSTEM.BROKER queues are defined for you when you create
WebSphere MQ Integrator components, and are not defined as cluster
queues. You must not change this attribute.
For message flow input queues:
If you define an input queue as a cluster queue, you must consider the
implications for the order of messages or the segments of a segmented
message. The implications are the same as they are for any MQSeries
cluster queue. In particular, the application must ensure that if it is sending
segmented messages, all segments are processed by the same target queue,
and therefore by the same instance of the message flow at the same broker.
For message flow output queues:
v WebSphere MQ Integrator always specifies MQOO_BIND_AS_Q_DEF
when it opens a queue for output. If you expect segmented messages to
be put to an output queue, or want a series of messages to be handled
by the same process, you must specify DEFBIND(OPEN) when you
define that queue. This ensures that all segments of a single message, or
all messages within a sequence, are put to the same target queue and are
processed by the same instance of the receiving application.
v If you create your own output nodes, you are recommended to specify
MQOO_BIND_AS_Q_DEF when you open the output queue, and
DEFBIND(OPEN) when you define the queue, if you need to guarantee
message order, or ensure a single target for segmented messages.
For publish/subscribe:
v If the target queue for a publication is a cluster queue, you must deploy
the publish/subscribe message flow to all the brokers on queue
managers in the cluster. However, the cluster does not provide any of
the failover function to the broker domain topology and function. If a
broker to which a message is published, or a subscriber registers, is
unavailable, the distribution of the publication or registration is not
taken over by another broker.
v When a client registers a subscription with a broker running on a queue
manager that is a member of a cluster, the broker forwards a proxy
registration to its neighbors within the broker domain: the registration
details are not advertised to other members of the cluster.

For a fuller understanding and discussion of clusters, and the implications of using
cluster queues, see the MQSeries Queue Manager Clusters book.

136 WebSphere® MQ Integrator: Introduction and Planning

 Databases

Planning database resources

WebSphere MQ Integrator requires a number of databases to contain control and
configuration information. You must create these immediately after installation,
because they are populated when you create your WebSphere MQ Integrator
components and resources.

Under normal circumstances, you do not need to be aware of the nature of these
databases, or how the various components use, or update, the information they
contain. However, it is useful to understand these basics:
v “Database requirements”
v “Databases and code pages” on page 138
v “Database locations” on page 138
v “Database backup and recovery” on page 139

Database requirements
WebSphere MQ Integrator uses three sets of tables within databases. You can
choose to create these in a single DB2 database if appropriate, or you can create a
different database for each set.

The three sets of tables required by WebSphere MQ Integrator are:

1. The configuration repository. This set of tables is managed by the Configuration
Manager. It contains all configuration information for you broker domain.
When you create and modify the resources in your broker domain using the
Control Center (for example, if you create message flows), the changes you
make are initially stored in your local system. You must deploy these changes
for those updates to be processed by the Configuration Manager and reflected
in the configuration repository.
The Configuration Manager is the only component that accesses this database.
You can view and manage the data in this repository using the Control Center,
which interacts with the Configuration Manager on your behalf.
You must create this database using DB2.
2. The broker database (also known as the broker’s local persistent storage). This
contains control information used by the brokers in maintaining their state and
other internal information. The database contains one set of tables: the rows
within each table include the broker name to ensure the integrity of the data.
When you make changes to the broker’s environment, and deploy those
changes, the Configuration Manager sends messages to the broker to update its
local persistent store. For example, if you assign and deploy a new message
flow to the broker, the data is updated.
You can create the broker database to hold this information using the following
database products:
v IBM DB2 Universal Database
v Microsoft SQL Server (on Windows NT only)
v Oracle
v Sybase

Note: The z/OS broker can only use DB2.

You can use a separate database for each broker if you choose. For more
information about supported databases, see Table 4 on page 121.
3. The message repository. This set of tables is managed by the Configuration
Manager. It contains all the message and message set definitions you have

Chapter 9. Planning your WebSphere MQ Integrator network 137

 Databases
created using the Control Center and deployed in your broker domain. If you
import externally defined message definitions using the Control Center, these
are also stored in this repository.
You must create this database using DB2.
This repository does not contain definitions for messages created using the
New Era of Networks Formatter user interface. For information on the database
requirements for these message formats, see Appendix A, “Planning for
migration and integration” on page 167.

WebSphere MQ Integrator uses ODBC to connect to the message repository and

the broker databases: ODBC drivers for DB2 and SQL Server are provided with the
database products, ODBC drivers for Oracle and Sybase are provided by
WebSphere MQ Integrator. The Configuration Manager uses JDBC to connect to the
configuration repository, see Figure 3 on page 13.

Databases and code pages

Subscription data retrieved from client applications (for example, topics from
publishers and subscribers, or content filters from subscribers) and the character
data entered using the Control Center (for example, message flow names) are
stored in the configuration and message repositories. This data is translated from
its originating code page to the code page of the process in which the broker or
Configuration Manager is running, and then by the database manager to the code
page in which the database or databases were created. To preserve data
consistency and integrity, you must ensure that all this subscription data and
Control Center character data is originated in a code page that is compatible with
the two code pages to which it is translated. If you do not do so, unpredictable
| results and loss of data might result. If the data is to be shared by users using
| different locales, the databases need to be located in code page 1208 (UTF-8).

Data stored in the broker’s local persistent store is not affected in this way.

The restrictions described above are not applicable to user data in messages. It is
your responsibility to ensure that any data in messages generated by your
applications is compatible with the code page of any database you access from
your message flows.

ESQL statements generated as a result of explicit reference to databases within

message processing nodes can contain character data that has a variety of sources.
For example, it might have been entered through the Control Center, derived from
message content, or read from another database. All this data is translated from its
originating code page to the code page in which the broker is running, and then
by the database manager to the code page in which the database was created. You
must ensure that these three code pages are compatible to avoid data conversion
problems.

Database locations
The databases used by the product components can be located on any system that
is accessible by the component that creates and maintains the tables within them.

You can set up a local database for each component if you choose, or you can set
up a central database on a shared server, and set up remote access to that server
for each and every system hosting a component that requires that access.

138 WebSphere® MQ Integrator: Introduction and Planning

 Databases
There are advantages and disadvantages to local and remote database usage. You
must refer to the documentation supporting the database you are using for
WebSphere MQ Integrator to determine the best options for your specific
environment.

Note: The User Name Server has no requirement for access to any of these
databases.

Database backup and recovery

You must include the databases used by WebSphere MQ Integrator in your regular
database backup routines to ensure that the data critical to the operation of your
broker domain is secure and recoverable in the event of system or disk storage
failure.

For more details of the databases and tables, see the WebSphere MQ Integrator
Installation Guide for your product. For more information about recovery
procedures, see the WebSphere MQ Integrator Administration Guide and the
WebSphere MQ Integrator for z/OS Customization and Administration Guide.

Chapter 9. Planning your WebSphere MQ Integrator network 139

Security

Planning security
An important part of planning your broker domain is considering the security
controls that are available, and the levels of security you want to implement for
those controls.

WebSphere MQ Integrator exploits MQSeries and the operating system facilities to

control security of components and tasks:
v Topic-based security.
The WebSphere MQ Integrator User Name Server interacts with the operating
system security system to control user and group access to publications and
subscriptions.
v Operational control of components.
WebSphere MQ Integrator uses the operating system access control.
v Operational roles used in the Control Center.
WebSphere MQ Integrator uses Windows NT access control. (The Control Center
runs on Windows NT only.)

You must review the following information to understand the implications for your
configuration. The following sections describe the controls that are available, and
how they affect the operation of your broker domain:
v “Security and principals”
v “Operational security” on page 147
v “Control Center security” on page 148
v “Application security” on page 150
v “Message flow security” on page 150
You should also review the Setting up security section in the WebSphere MQ
Integrator Administration Guide, and the WebSphere MQ Integrator for z/OS
Customization and Administration Guide for further information about implementing
a security setup.

Security and principals

Security control of WebSphere MQ Integrator components, resources, and tasks
depends on the definition of users and groups of users (principals) to the security
subsystem of the operating system (the Windows NT User Manager or the UNIX
user/group database).

Groups
The WebSphere MQ Integrator local groups are:
v mqbrkrs
v mqbrasgn
v mqbrdevt
v mqbrops
v mqbrtpic

You must assign users (or other groups) to the local groups to allow them to
perform specific tasks. These assignments are summarized in Table 6 on page 145
and Table 5 on page 144.

The local groups provide the following authorities:

mqbrkrs
Users in this group are authorized as service user IDs for the brokers, the

140 WebSphere® MQ Integrator: Introduction and Planning

 Security
Configuration Manager, and the User Name Server. Note that service user
IDs have other authority requirements. These are detailed in Table 6 on
page 145.
mqbrdevt
Users in this group are permitted to perform the following tasks in the
Control Center:
v Design messages, message sets, and message flows.
mqbrasgn
Users in this group are permitted to perform the following tasks in the
Control Center:
v Manage execution groups within brokers.
v View messages and message flows.
v Assign message flows to execution groups.
v Assign message sets to brokers.
mqbrops
Users in this group are permitted to perform the following tasks in the
Control Center:
v Create brokers. (This creates a reference within the Control Center and
the configuration repository to a broker you have created on the system
on which it is to execute. This reference must have the same name as the
physical broker).
v Deploy, start, and stop message flows.
v Start and stop trace activity on message flows.
v Manage and deploy the broker domain topology, including collectives.
v View the whole deployed system, including messages, message flows,
and subscriptions.
v Deploy topics.
v View logs that report on the deployment activity.
mqbrtpic
Users in this group are permitted to perform the following tasks in the
Control Center:
v Manage topics, and the access controls lists for the topic tree.
v Deploy topics.
v View the logs that report on that deployment activity.

The requirement for and creation of these groups differs on each operating system:
v On Windows NT, WebSphere MQ Integrator creates all these groups on the
system on which it is installed.
v On AIX systems, WebSphere MQ Integrator creates the local group mqbrkrs on
the system on which a component is installed.
v On HP-UX systems, you must create the local group mqbrkrs yourself, before
you install WebSphere MQ Integrator components.
v On Solaris systems, you must create the local group mqbrkrs yourself, before
you install WebSphere MQ Integrator components.
v The groups other than mqbrkrs are used to control Control Center tasks and
configuration repository access, and therefore are not required on UNIX
systems.

Chapter 9. Planning your WebSphere MQ Integrator network 141

 Security
Principals
WebSphere MQ Integrator has three primary sets of principals:
v Operational user IDs. These are defined as:
– The user IDs that configure and manage WebSphere MQ Integrator
components.
– The service user IDs under which the major components (broker,
Configuration Manager, and User Name Server) operate. You must specify a
service user ID when you create each component.

For more details about operational user IDs, see “Operational security” on
page 147.
v Control Center user IDs. You must assign these to the WebSphere MQ Integrator
groups according to the set of tasks they undertake. These groups are checked
by the Configuration Manager, and must be defined to the security domain that
you specify when you create the Configuration Manager. The user IDs you
assign to these groups must be defined to the same security domain.
For more details about Control Center user IDs, see “Control Center security” on
page 148.
v Application user IDs. Users that participate in publish/subscribe must be
assigned to groups that you create to control topic-based security. These groups
and users must be defined to the security domain that you specify when you
create the User Name Server. If you create the User Name Server on Windows
NT, you are recommended to specify the same security domain as the one you
specify when you create the Configuration Manager, but you are not forced to
do this.
For more details about application user IDs, see “Application security” on
page 150.

WebSphere MQ Integrator security architecture is designed to be platform

independent. If you are running WebSphere MQ Integrator in an environment that
includes clients on heterogeneous platforms, you are recommended to ensure that
all the principals you define for WebSphere MQ Integrator task authorizations are
limited to eight characters or less. If you have a Windows NT only environment,
you can create principals of up to twelve bytes (the limit set by the user identifier
field in the MQSeries MQMD, which is used by WebSphere MQ Integrator), but
you must only use these longer names if you are sure you will not later include a
UNIX system in your WebSphere MQ Integrator network.

Using Windows NT security domains

WebSphere MQ Integrator draws principals from either a Windows NT local
account security domain, or a Windows NT primary domain, or a Windows NT
trusted domain. For more information about Windows NT security domains, refer
to the Microsoft Web site at
| http://www.microsoft.com/ntserver/techresources/security/default.asp

Principals must be defined to a specific Windows NT security domain. You must

decide which domain you want to use for WebSphere MQ Integrator, and define
your principals to that domain (using the Windows NT User Manager on the
security domain server). If you already have a security domain set up to control
access to MQSeries resources, use this same domain for WebSphere MQ Integrator;
this does not cause any conflict and eases your security administration.

142 WebSphere® MQ Integrator: Introduction and Planning

 Security
If you plan to use WebSphere MQ Integrator within a primary or trusted security
domain, global groups are created in your primary or trusted security domain
controller during installation. The global groups, that mirror the local groups, are:
v Domain mqbrkrs
v Domain mqbrasgn
v Domain mqbrdevt
v Domain mqbrops
v Domain mqbrtpic

Because these groups are not used by MQSeries, the 12-character restriction does
not apply.

These groups must be made members of the local security domain’s equivalent
WebSphere MQ Integrator groups (Domain mqbrkrs must be a member of
mqbrkrs, and so on).
v If you install WebSphere MQ Integrator on the domain controller of a primary or
a trusted security domain, the WebSphere MQ Integrator installation program
creates the local and global groups, and adds the global groups to the local
groups.
If you do not intend to install WebSphere MQ Integrator on the domain
controller, you can create these groups yourself using the Windows NT User
Manager. These groups should be defined exactly as they appear in the list
above. So, for example, from the Windows NT User Manager for domains select
User–>New User and enter Domain mqbrasgn in the username field, and so on
for the other groups.
v If you install WebSphere MQ Integrator on a workstation member of a primary
security domain, the WebSphere MQ Integrator installation program creates the
local groups. If the global groups already exist in the primary security domain, it
also adds each global group to the appropriate local group in the local domain.
If you intend to install on a primary domain controller, it is recommended that
you install on the domain controller first so that the domain groups are created
for you, and are then automatically added to the local groups created during
install on a workstation.
v If you install WebSphere MQ Integrator on a workstation member of a trusted
domain, WebSphere MQ Integrator cannot recognize the trusted domain, and
does not add the global groups to the local groups. You must do this step
yourself.
v If you install WebSphere MQ Integrator on a workstation that is a member of
both a trusted security domain and a primary security domain, the installation
program creates the local groups. If the global groups already exist in the
primary security domain, it also adds each global group to the appropriate local
group in the local domain. It cannot detect the trusted domain and therefore
does not add the global groups of the trusted security domain to the local
groups. If you want these trusted security domain global groups in the local
groups instead of, or in addition to, the primary security global groups, you
must make these updates yourself.

When you define a new user ID to your security domain, you must assign this ID
to the domain group that is authorized for the tasks this user ID is to perform, so
that it is authorized globally.

For further details of how to implement security in the Windows NT environment,

see the WebSphere MQ Integrator Administration Guide.

Chapter 9. Planning your WebSphere MQ Integrator network 143

Security
Using UNIX security domains
On UNIX platforms, WebSphere MQ Integrator draws principals from the
operating system’s user and group tables.

Summary of authorizations
The authorizations required for the major tasks in both Windows NT and UNIX
environments are summarized here. For further details, refer to the WebSphere MQ
Integrator Administration Guide.

Table 5 summarizes the authorization and security requirements for some of the
major tasks in the UNIX environments.
Table 5. Summary of authorization in the UNIX environments
User is... UNIX domain
Creating broker, User Name Server v Member of mqbrkrs and mqm.
v In most situations, the Broker or User Name Server runs under
the login ID used to issue the create command. When root is
used to issue the create command, it can nominate any user to
run the Broker or User Name Server.
Installing Superuser.
Uninstalling Superuser.
Changing broker, User Name Server Member of mqbrkrs.
Deleting broker, User Name Server Member of mqbrkrs and mqm.
Starting broker, User Name Server v Member of mqbrkrs.
v Member of mqm.
v Service user ID¹.
Stopping broker, User Name Server v Member of mqbrkrs.
v Member of mqm if –q is specified
v Service user ID¹.
Listing broker, User Name Server Member of mqbrkrs.
Changing, displaying, retrieving trace Member of mqbrkrs.
information
Running User Name Server (login ID) Member of mqbrkrs. The broker or User Name Server runs
under the login ID specified in the create command.
Running broker (MQSeries non-trusted Member of mqbrkrs. The broker or User Name Server runs
application) (login ID) under the login ID specified in the create command.
Running broker (MQSeries trusted application) v login ID must be mqm.
(login ID) v mqm must be a member of mqbrkrs.
Clearing, joining, listing MQSeries Member of mqbrkrs.
publish/subscribe brokers
Running publish/subscribe applications Any user, subject to WebSphere MQ Integrator topic and
MQSeries queue access control.
Warning:
1. When the service user ID is root, all libraries loaded by the broker, including all user-written plug-in libraries
and all shared libraries that they might access, also have root access to all system resources (for example,
filesets). You must review and assess the risk involved in granting this level of authorization.

144 WebSphere® MQ Integrator: Introduction and Planning

 Security
Table 6 summarizes the security requirements for the major tasks in the Windows
NT environment. It illustrates what group memberships are required if you are
using a local security domain defined on your local system SALONE, or a primary
domain named PRIMARY, or a trusted domain named TRUSTED. The contents of
this table assume that you have created both the Configuration Manager and the
User Name Server with the same security domain.
Table 6. Summary of authorizations in the Windows NT environment
User is... Local domain (SALONE) Primary Domain (PRIMARY) Trusted domain (TRUSTED)
Installing v Member of Administrators Not applicable. Not applicable.
Uninstalling v Member of Administrators Not applicable. Not applicable.
Creating broker, v Must be a user ID defined in v Must be a user ID defined in v Must be a user ID defined in
Configuration SALONE PRIMARY TRUSTED
Manager, User v Member of Administrators v Member of v Member of
Name Server SALONE\Administrators SALONE\Administrators
Starting broker, v Member of Administrators Not applicable. Not applicable.
Configuration
Manager, User
Name Server
Running User v Must be a user ID defined in v Must be a user ID defined in v Must be a user ID defined in
Name Server SALONE PRIMARY TRUSTED
(service user ID) v Member of mqbrkrs v Member of v Member of
PRIMARY\Domain mqbrkrs TRUSTED\Domain mqbrkrs
Running v Must be a user ID defined in v Must be a user ID defined in v Must be a user ID defined in
Configuration SALONE PRIMARY TRUSTED
Manager (service v Member of mqbrkrs v Member of v Member of
user ID) v Member of mqm PRIMARY\Domain mqbrkrs TRUSTED\Domain mqbrkrs
v Member of SALONE\mqm (see v Member of
note 1) SALONE\Domain mqm (see note
2)
Running broker v Must be a user ID defined in v Must be a user ID defined in v Must be a user ID defined in
(service user ID) SALONE PRIMARY TRUSTED
(see note 5) v Member of mqbrkrs v Member of v Member of
PRIMARY\Domain mqbrkrs TRUSTED\Domain mqbrkrs
Running Control v Must be a user ID defined in v Must be a user ID defined in v Must be a user ID defined in
Center (see note 3) SALONE (see note 4) For PRIMARY (see note 4) For TRUSTED (see note 4) For
example, SALONE\User1 is example, PRIMARY\User2 is valid, example, TRUSTED\User3 is valid,
valid, PRIMARY\User2 and SALONE\User1 and SALONE\User1 and
TRUSTED\User3 are not TRUSTED\User3 are not. PRIMARY\User2 are not.
v Member of one or more of v Member of one or more of v Member of one or more of
mqbrasgn, mqbrdevt, PRIMARY\Domain mqbrasgn, TRUSTED\Domain mqbrasgn,
mqbrops, mqbrtpic PRIMARY\Domain mqbrdevt, TRUSTED\Domain mqbrdevt,
and so on. and so on.
Running v Must be a user ID defined in v Must be a user ID defined in v Must be a user ID defined in
publish/subscribe SALONE For example, PRIMARY For example, TRUSTED For example,
applications SALONE\User1 is valid, PRIMARY\User2 is valid, TRUSTED\User3 is valid,
PRIMARY\User2 and SALONE\User1 and SALONE\User1 and
TRUSTED\User3 are not. TRUSTED\User3 are not. PRIMARY\User2 are not.

Notes:
1. If you are running in a primary domain, you can also:
v Define the user ID in the domain PRIMARY.
v Add this ID to the group PRIMARY\Domain mqm.
v Add the PRIMARY\Domain mqm group to the group
SALONE\mqm.

Chapter 9. Planning your WebSphere MQ Integrator network 145

Security
2. Ifyou are running in a trusted domain, you can also:
v Define the user ID in the domain TRUSTED.
v Add this ID to the group TRUSTED\Domain mqm.
v Add the TRUSTED\Domain mqm group to the group
SALONE\mqm.
3. All Control Center users need read access to the MQSeries java\lib
subdirectory of the MQSeries home directory (the default is
X:\Program Files\MQSeries, where X: is the operating system disk).
This access is restricted to users in the local group mqm by MQSeries.
WebSphere MQ Integrator installation overrides this restriction and
gives read access for this subdirectory to all users.
4. If a valid user ID is defined in the domain used by the Configuration
Manager (for example, PRIMARY\User4) an identical user ID defined
in a different domain (for example, DOMAIN2\User4) can access the
Control Center with the authorities of PRIMARY\User4.
5. The broker can be run as an MQSeries trusted application. If it is,
security requirements are changed. See the WebSphere MQ Integrator
Administration Guide for full details.

146 WebSphere® MQ Integrator: Introduction and Planning

 Security

Operational security
When you create and activate your broker domain, there are two aspects of
security that control the authorizations of users to perform these tasks:
Configurational security
Controls the right of users to configure and manage WebSphere MQ
Integrator resources using the supplied commands.
Run-time security
Controls the right of users to execute processes as service user IDs.

For a full definition of the commands that support these tasks and the authority
required to invoke each one, see the WebSphere MQ Integrator Administration Guide
and the WebSphere MQ Integrator for z/OS Customization and Administration Guide.

For a better understanding of MQSeries and database resource security for

WebSphere MQ Integrator components, see the WebSphere MQ Integrator
Administration Guide and the WebSphere MQ Integrator for z/OS Customization and
Administration Guide. For further information on securing MQSeries resources used
by WebSphere MQ Integrator components, refer to the section Securing MQSeries
resources in the WebSphere MQ Integrator Administration Guide. For further details of
MQSeries security, refer to the MQSeries System Administration. For further details
of database security, refer to the documentation for the database you are using.

Configurational security
WebSphere MQ Integrator provides a set of configuration and operation
commands that support system administration tasks that are not available through
the Control Center.

The authorizations required by the user invoking these commands varies,

depending on the task the command performs. These tasks are:
v Creating, changing, and deleting broker, the Configuration Manager, and the
User Name Server
v Starting, stopping, listing, and tracing brokers, the Configuration Manager, and
the User Name Server

The authorizations required for a subset of these commands is illustrated in Table 6

on page 145 and Table 5 on page 144. You can find a more complete summary of
authorizations in the WebSphere MQ Integrator Administration Guide and the
WebSphere MQ Integrator for z/OS Customization and Administration Guide.

Run-time security
When you start the broker, Configuration Manager, and User Name Server
components on Windows NT, they are started up as Windows NT services running
under the user ID that you specify as the service user ID when you create that
component. When you start the broker or the User Name Server components on
UNIX, they are started as normal processes running under the service user ID.

The authorizations required by these user IDs are illustrated in Table 6 on page 145
and Table 5 on page 144. You can find a more complete summary of authorizations
in the WebSphere MQ Integrator Administration Guide and the WebSphere MQ
Integrator for z/OS Customization and Administration Guide.

Chapter 9. Planning your WebSphere MQ Integrator network 147

Security
You must also use the MQSeries facilities to authorize the broker service user IDs
to access the message flow input and output queues. Typically, this needs to be set
for get and inq for input queues, and put and setall for output queues. See
MQSeries System Administration for more information about setting queue access
authorities.

Database security
The service user IDs for the brokers and the User Name Server must also be
authorized to access databases:
v The Configuration Manager service user ID must be authorized for create and
update tasks on the database in which both configuration and message
repositories are defined. (This might be one or two databases: both must be
DB2.)
v Each broker service user ID must be authorized for create and update tasks on
the database that contains the broker internal tables.
v Each broker service user ID must also be authorized for the appropriate access
for every database referenced and accessed by a message processing node in any
deployed message flow.

MQSeries security
Use existing MQSeries facilities for securing connections between components,
except if you use the channel security exit. You have to specify this as a parameter
when you invoke the Control Center. See the WebSphere MQ Integrator
Administration Guide for details on how to do this. See the MQSeries System
Administration for details on MQSeries security.

WebSphere MQ Integrator for z/OS security

It is necessary to secure your WebSphere MQ Integrator for z/OS installation as
well as your DB2 and MQSeries objects. For details on how to do this, see the
WebSphere MQ Integrator for z/OS Customization and Administration Guide.

Control Center security

All users can invoke the Control Center: there is no initial check when the program
is invoked. However, to perform Control Center tasks, a user must choose the role
they want to assume during this session. The role maps to a Windows NT group,
and you must therefore define and configure the user and groups to meet your
requirements, using the guidelines that are summarized in Table 6 on page 145. The
domain that users are drawn from is set on the create command for the
Configuration Manager – see the WebSphere MQ Integrator Administration Guide for
details of the command syntax. This configuration is independent of the
implementation of topic-based security and the installation of a User Name Server.

To select a specific role, the user must choose one of the following from the
File->Preferences dialog (User’s role pane):
1. Message flow and message set developer
This role equates to the permissions of the mqbrdevt group members.
2. Message flow and message set assigner
This role equates to the permissions of the mqbrasgn group members.
3. Operational domain controller
This role equates to the permissions of the mqbrops group members.

148 WebSphere® MQ Integrator: Introduction and Planning

 Security
4. Topic security administrator
This role equates to the permissions of the mqbrtpic group members.
5. All roles
This role combines all four roles, authorizing the user to perform all tasks.

The role determines what the user can view within the Control Center, and
therefore limits the tasks that are available to that user. However, the authorization
of that user to perform a given task is not checked until the request is processed
by the Configuration Manager. To be able to perform any action, therefore, a user
must be defined to the security domain specified when you created the
Configuration Manager.

The Control Center passes the request in a message to the queue

SYSTEM.BROKER.CONFIG.QUEUE: the Configuration Manager sends responses
to the queue SYSTEM.BROKER.CONFIG.REPLY (both queues are defined to the
Configuration Manager’s queue manager). All groups in the Configuration
Manager’s security domain have get and put authority to both queues. On receipt
of the message, the Configuration Manager checks that the user ID is in the group
that is authorized to complete the specific task. Therefore you are recommended to
encourage Control Center users to assume the role that corresponds to their
authorization.

Additional authorizations required by users of the Control Center are summarized

in Table 6 on page 145. For more details of the roles defined, and the facilities of
the Control Center, see WebSphere MQ Integrator Using the Control Center.

The IBMMQSI2 superuser

A superuser user ID is recognized by the Control Center and the Configuration
Manager. This user ID, IBMMQSI2, is a privileged user ID that provides these
essential functions:
v It has the authority to unlock any resources locked to another user ID. If a user
ID is removed for any reason (for example, if an employee leaves the company)
and resources are left locked to that user ID, you can start the Control Center
with the privileged user ID and unlock the locked resources.
v The IBM primitive message processing nodes (described in “Primitive node
types” on page 61) are locked under this user ID. If maintenance that includes
updates to these nodes is supplied by IBM, you must use this user ID to check
out the existing primitive nodes, import the replacement nodes, and check them
in to the configuration repository.

You must define the user ID IBMMQSI2 yourself (using the Windows NT User
Manager) to the security domain specified when you create the Configuration
Manager using the mqsicreateconfigmgr command. You must also add this user
ID to the WebSphere MQ Integrator groups necessary for it to be authorized to
complete the task required on the system on which you are running the Control
Center:
v If you are using a primary or trusted security domain, you must add this user
ID to the appropriate Domain mqbrxxxx groups.
v If you are using a local security domain, you must add this user ID to the
appropriate local mqbrxxx groups.

Chapter 9. Planning your WebSphere MQ Integrator network 149

Security
MQSeries authorizations
The Control Center connects to the Configuration Manager using an MQSeries
client/server connection. For details of the security available for this connection,
see the MQSeries Clients book (the chapter entitled “Setting up MQSeries client
security”).

Application security
You need to consider application security in two areas:
v “Message flow security”.
v “Topic-based security”.

Message flow security

When you deploy a message flow on one or more brokers, applications can start to
feed messages into the message flow by putting messages to the queue that is
identified as the input queue. You set up the association between the input node
and the queue by setting the queue name as a property of the node.

Similarly, applications access queues to receive messages placed on those queues

by output or Publication nodes, when the message flow has completed processing
for those messages.

The user IDs under which applications are executing must therefore be authorized
to write to, or read from, the queues used by the message flow the applications are
interacting with.

You must also authorize every subscriber (that is, every application making a
subscription registration) to put messages to the queue
SYSTEM.BROKER.CONTROL.QUEUE. (This does not apply to MQSeries
Everyplace applications.)

You must use the facilities provided by MQSeries to restrict which users are
permitted to have “put” or “get” access to the queues. (This does not apply to
MQSeries Everyplace applications.) For more details of applying security to
MQSeries resources, see MQSeries System Administration.

Note that SCADA applications do not support message flow security. The
SCADAInput node accepts all messages that the listener detects at the connected
port.

Topic-based security
If you have applications that use the publish/subscribe services of a broker, you
have the option of applying an additional level of security to the topics on which
messages are published and subscribed. This additional security, known as
topic-based security, is managed by the User Name Server. The User Name Server
and the benefits of topic-based security are discussed in “Employing topic-based
security” on page 129.

If you want to take advantage of topic-based security in your WebSphere MQ

Integrator broker domain, you must create, or update, your brokers and the
Configuration Manager to recognize the User Name Server. You can identify the
User Name Server to the brokers and the Configuration Manager by specifying the

150 WebSphere® MQ Integrator: Introduction and Planning

 Security
User Name Server’s queue manager name as the -s parameter on the commands
mqsicreatebroker, mqsicreateconfigmgr, mqsichangebroker, and
mqsichangeconfigmgr.

If you have already created the Configuration Manager and one or more brokers,
you must stop them (using mqsistop) before you make these changes. You can
then restart the Configuration Manager and the brokers. and start the User Name
Server, using mqsistart. These steps are illustrated in the MQSeries MQ Integrator
Installation Guide.

When you have configured your broker domain components to incorporate the
User Name Server, you can implement topic-based security by setting up Access
Control Lists (ACLs) from the Topics view of the Control Center. ACLs are lists of
principals, and are assigned to topics to control which principals can publish,
subscribe, and request persistent delivery on those topics.

The principals you can include in an ACL are notified to the Control Center by the
Configuration Manager, which requests the information from the User Name
Server.
v If you created the User Name Server on Windows NT, it extracts principal
information from the domain server of the security domain that you specified
when you created the User Name Server. You must therefore define all users and
groups required by your implementation of topic security to the security domain
specified when you created the User Name Server.
v If you created the User Name Server on UNIX, it extracts principal information
from the user/group database. You must therefore define all users and groups
required by your implementation to the database accessed by the User Name
Server.

When a publisher publishes a message to a broker, or a match for a published

message for a particular subscriber is found, the broker checks its local copy of
principal and ACL information to determine if the user request is authorized by an
ACL for the specified topic.

After the broker has determined that a client has the authority to receive a
particular publication, it makes a further check as to whether the client is
authorized to request persistent delivery on this topic. If the client has requested
persistent delivery, but is not authorized to do so, the broker does make the
message available to the client, but nonpersistently.

For more details on how to implement topic security, see WebSphere MQ Integrator
Using the Control Center, and for more detailed information on aspects of topic
security, see “Topic-based security” on page 101.

Chapter 9. Planning your WebSphere MQ Integrator network 151

Data conversion

Planning for data conversion

If you are using a network of systems that use different methods for storing
numeric values, or you need to communicate between users who view data in
different code pages, you need to consider how to implement data conversion.
Numeric order
For numeric and encoding aspects, you must consider:
v Big Endian versus Little Endian
v Encoding values in MQSeries (field Encoding in the MQMD)
Encoding values are system specific. For example, Windows NT usually
has an encoding of 546, hexadecimal value X’00000222’. The three final
hexadecimal digits identify:
1. The float number format
This value can be 1 (IEEE format byte order normal), 2 (IEEE format
byte order reversed) or 3 (System/390® format byte order normal).
2. The packed decimal number format
This value can be 1 (byte order normal) or 2 (byte order reversed).
3. The hexadecimal number format
This value can be 1 (byte order normal) or 2 (byte order reversed).

The bit order within a byte is never reversed. Byte order normal means
that the least significant digit occupies the highest address.

Systems that process numbers in normal byte order are Big Endian
(System/390, AS/400, and UNIX). Systems that process numbers in
reversed byte order are Little Endian (mainly PCs).

For further details about numeric order, see Appendix D, Machine

Encodings, in the MQSeries Application Programming Reference.
Code page conversions
Code page conversion might be required for any of the following reasons:
v ASCII versus EBCDIC
v National languages
v Operating system specific code pages

For more information about code page support in MQSeries, see the
MQSeries Application Programming Reference book.

When you use WebSphere MQ Integrator, you can use the data conversion facilities
of MQSeries, or WebSphere MQ Integrator, or both.
MQSeries facilities
Headers and message body are converted according to the MQMD values,
and other header format names. You might have to set up data conversion
exits to convert the body of your messages.
When you use MQSeries facilities, the whole message is converted to the
specified encoding and CCSID, according to the setting of the format in the
MQSeries header.

152 WebSphere® MQ Integrator: Introduction and Planning

 Data conversion
For more detail about data conversion using MQSeries facilities, see
Appendix F, Data Conversion, in the MQSeries Application Programming
Reference.
WebSphere MQ Integrator facilities
You must define your messages in the message repository (using the
Control Center), or use self-defining messages. You can then use the
Compute node to define encoding and CCSIDs. The predefined elements of
the messages are converted according to their type and Custom Wire
Format characteristics. You do not need MQSeries data conversion exits.
v String data is converted according to the CCSID setting.
v Decimal integer and Float Extended Decimal types are converted
according to the CCSID setting.
v Decimal integer and Float (other physical data types) are converted
according to the Encoding setting.
v Binary and Boolean data is not converted.

WebSphere MQ Integrator can also convert those MQSeries headers for

which parsers are provided (listed in “Default message parsers” on
page 74).

When you use WebSphere MQ Integrator facilities, the whole message is

not converted to the specified encoding and CCSID: you can specify a
different encoding, or CCSID, or both, in each header to perform a
different conversion for the following part of the message. The encoding
and CCSID in the last header therefore defines the values for the message
body.

For an example of data conversion using WebSphere MQ Integrator

facilities, see the WebSphere MQ Integrator ESQL Reference book.

Chapter 9. Planning your WebSphere MQ Integrator network 153

Data conversion

154 WebSphere® MQ Integrator: Introduction and Planning

Chapter 10. Managing your WebSphere MQ Integrator network
This chapter provides the information you need to understand how to manage
your WebSphere MQ Integrator network, when you have planned and created it.

It covers the following topics:

v “Managing broker domain components”
v “Monitoring and analysis” on page 157

Managing broker domain components

When your configuration work is complete, you need to manage the components
on a day-to-day basis. WebSphere MQ Integrator provides a set of commands that
enable you to control the broker domain in two ways:
Starting and stopping components
Start a component
You can use the command mqsistart to start up the instances of
broker, Configuration Manager and User Name Server created by
command. You must identify which component is to be started as the
first parameter on the command. If appropriate, the associated queue
manager is also started.
Stop a component
The command mqsistop terminates the component specified by the
first parameter on this command. You can also request that the
associated queue manager is stopped by this command.
Viewing and modifying components
List components or subcomponents available on a system
You can use the command mqsilist to return a list of the
components created on this system, with the name of the queue
manager that supports them
If you specify a broker name as a parameter on the command, it
returns a list of the broker’s execution groups. If you specify a
broker name and identify an execution group, it returns the message
flows within that execution group.
Change parameters of a component
If you need to update the parameters currently set for a component,
use the mqsichangebroker, mqsichangeconfigmgr, or
mqsichangeusernameserver command. These set the newly
specified value for each operand included on the command, and
leave all others unchanged.

On WebSphere MQ Integrator for z/OS, the functionality of the commands is

restricted. To change component parameters, you must update the Configuration
Input File and execute mqsicustomize. For details of how to do this, see the
WebSphere MQ Integrator for z/OS Customization and Administration Guide.

The change commands listed, like the create and delete commands discussed in
“Planning WebSphere MQ Integrator resources” on page 125, can be invoked using
the Command Assistant.

© Copyright IBM Corp. 2000, 2002 155

Managing the network
For full details of all these commands, and how to use the Command Assistant, see
the WebSphere MQ Integrator Administration Guide.

For information on the commands that can be used on the z/OS platform, see the
WebSphere MQ Integrator for z/OS Customization and Administration Guide. For more
information about managing the MQSeries resources associated with these
WebSphere MQ Integrator components, see MQSeries System Administration,
MQSeries Clients, and MQSeries Intercommunication.

Managing application and business processes

The Control Center provides all the facilities for managing application and
business processes. You can use the Control Center to:
Define your broker domain, using the Topology view
v Add new brokers and collectives.
v Remove a broker or collective.
v Change the connectivity between brokers and collectives.
Work with message flows, using the Message Flow and Assignments views
v Create new message flows using existing node types.
v Assign message flows to execution groups in brokers.
v Remove message flows from execution groups.
v Solve message flow problems using the Debugger, an alternative screen
under Message Flow.
Organize your messages, from the Messages and Assignments views
v Define new message templates and message sets.
v Update message templates.
v Assign message sets to brokers.
v Delete messages or message sets.
Control your publish/subscribe network, in the Topics and Subscriptions views
v Define your topics.
v Ensure authorizations are valid and complete.
v Examine the subscriptions currently active.
Manage your broker domain, using the Topology and Operations views
v Deploy assigned resources to brokers.
v Check on the status of the latest resources deployed.
v Check on broker status.
v Switch on problem diagnosis tools.
Monitor the success of deployments by viewing responses in the Log view
Access the New Era of Networks GUIs (rules, formatter, and tester) in the
Messages view

For further information, and details of how to complete the tasks outlined here, see
WebSphere MQ Integrator Using the Control Center.

156 WebSphere® MQ Integrator: Introduction and Planning

 Monitoring the network

Monitoring and analysis

When you have completed initial configuration and activation of your WebSphere
MQ Integrator network, you need to be sure that it is running as efficiently as
possible, and that it is behaving as you want and expect.

The following topics describe how you can monitor your broker domain, and
analyze its activities to achieve these goals:
v “Problem determination”
v “Managing workload and performance” on page 160
v “System management” on page 161

Problem determination
When your broker domain is configured and activated, you might want to view
further information about how its operation is progressing, or you might need to
detect why it is not behaving as you expect.

WebSphere MQ Integrator provides commands and facilities that help you

understand what is happening in your broker domain, and allow you to generate
and review more information when you need to. It provides two major sources of
information:
v Traces generated by components
v Messages generated by commands

These facilities are fully described in the WebSphere MQ Integrator Problem

Determination Guide.

You can also use information generated by other products used by WebSphere MQ
Integrator (MQSeries, the databases, and ODBC) to help resolve problems.

To solve problems at the message flow level, see “Using the Debugger to solve
message flow problems” on page 67 where the Debugger facility of the Control
Center is described.

Traces
WebSphere MQ Integrator always records a minimum level of activity in the
broker domain. You can activate further traces of the major components (broker,
Configuration Manager, and User Name Server), of the execution groups and
message flows you create within brokers, and for command utility programs.

Every level of additional tracing affects the performance of your system.

Local error log messages: WebSphere MQ Integrator writes some events to local
logs supported by the operating system in which the errors are generated.

The logs used are:

The UNIX syslog
You can extract readable syslog content to a file to view the entries recorded.
For further information on how to use the syslog, see the WebSphere MQ
Integrator Problem Determination Guide.
The Windows NT event log (Application View)
You can access the records in this log using the Windows NT Event Viewer
service.

Chapter 10. Managing your WebSphere MQ Integrator network 157

Monitoring the network
The z/OS error log and the operator console.
For further information, see the WebSphere MQ Integrator Problem
Determination Guide and the WebSphere MQ Integrator for z/OS Customization
and Administration Guide.

Although you cannot select whether WebSphere MQ Integrator takes the action to
write these events to the Application event log, you can control the activity of the
event log itself, at the operating system level.

Records in the local log are written by all product components to record significant
events. For example, a record is written when you stop and start brokers, the
Configuration Manager, or the User Name Server. If an interaction with a database
fails, this is also recorded. In some situations (for example, when you start the
Configuration Manager), you are advised to view this information to ensure that
the action you have taken completes successfully. You can also use the contents of
this log for reference and error information when you are developing and running
message flows.

The local logs are of interest to your local operations department because they
provide initial information about failures and unexpected behaviors. The
information in these logs might also be requested to support the service trace
information generated at the request of your IBM Support Center.

Optional traces: Optional traces are provided by WebSphere MQ Integrator:

User tracing
You can trace brokers, execution groups, and message flows. You can use
this facility when you are looking at problems or unexpected behavior
exhibited by your message flows.
Service tracing
You can activate a more comprehensive broker trace, and start tracing for
the Configuration Manager, User Name Server, and Control Center, and for
the command utility programs (for example, mqsicreatebroker). You are
recommended to use these traces only when directed to do so by your IBM
Support Center. If you encounter a problem that you have to report to IBM
for resolution, you are likely to be given instructions to create and access the
service logs to provide supporting information.

Controlling user trace: Four commands are provided to activate optional traces,
and to access and review the contents of the logs generated. These commands are:
mqsichangetrace
to activate and deactivate trace, or to change trace settings (for example,
trace logfile size).
mqsireporttrace
to report the current trace settings.
mqsireadlog
to access and retrieve log file contents in XML format.
mqsiformatlog
to format an XML log file (generated by mqsireadlog) for easier
interpretation.

For details of these commands and their usage, see the WebSphere MQ Integrator
Administration Guide or the WebSphere MQ Integrator for z/OS Customization and
Administration Guide.

158 WebSphere® MQ Integrator: Introduction and Planning

 Monitoring the network
The Control Center also has an interface to start and stop tracing for execution
groups and message flows on specific brokers. You can use this method as an
alternative to the commands provided.

For example, if you do not have command line access on the system on which the
broker is running, the Control Center communicates with the remote broker to
achieve the same actions. The options available through this interface are a subset
of the support provided by the commands invoked on the command line on the
broker’s local system. However, you must have local access to be able to extract
the trace output from the system on which it is generated.

For details of trace options in the Control Center see WebSphere MQ Integrator
Using the Control Center.

Tracing message flows: When you create a message flow, you can include a Trace
node. You can use the trace node to record additional information about the
message being processed. The information generated is written to the standard
trace logs or to a separate file.

Monitoring Control Center deployment: The Control Center displays additional

activity records in its Log view. These records provide information about the
success or failure of the actions taken by the user of the Control Center. For
example, if you deploy a message flow to a broker, a series of records are
displayed for you to check the progress of that deployment.

For more details about these options, see WebSphere MQ Integrator Using the Control
Center.

Messages
When you invoke any of the commands that WebSphere MQ Integrator supplies
(for example, mqsicreatebroker or mqsistart), responses are returned in the form
of messages. On z/OS systems, messages are returned to the operator console.
These messages have the prefix BIP and a numeric value. Some messages are also
generated by the installation and un-installation programs, and by the Control
Center. You can check the full meaning of these messages, and the actions you can
take, in the WebSphere MQ Integrator Messages book.

For more information about WebSphere MQ Integrator messages, see the WebSphere
MQ Integrator Administration Guide.

Information available from other sources

In addition to WebSphere MQ Integrator trace, you can refer to:
The database messages and logs
You can determine additional information about WebSphere MQ Integrator’s
use of databases from the messages issued by the database products, and
from log information generated by database trace activity.
MQSeries messages and logs
You can access trace information generated by MQSeries in its log files. You
can also gain further information from MQSeries messages when these are
returned by WebSphere MQ Integrator activities.
MQSeries events
You can control the generation of event messages by MQSeries queue
managers in response to specific conditions. For example, you can request
an event is generated when a queue becomes full.

Chapter 10. Managing your WebSphere MQ Integrator network 159

Monitoring the network
ODBC traces
You can initiate trace for ODBC activity. On Windows NT, you must select
the Trace tab of the ODBC function available in the Control Panel. On
UNIX, you must modify the .odbc.ini file to activate the trace.

You can find more information about these additional sources in the WebSphere MQ
Integrator Administration Guide.

Managing workload and performance

When you have configured and activated your broker domain, its performance
depends very heavily on the level of activity that it is supporting.

There are several areas you can consider in making best use of the resources you
have defined. These are:
v “Using MQSeries trusted applications”
v “Tuning message flow performance” on page 161

Using MQSeries trusted applications

When you create the broker using the mqsicreatebroker command, you can
configure it to run as an “MQSeries trusted application”. This causes the broker
and the MQSeries queue manager agent to run in the same process, thus
improving overall system performance. By default the broker does not run as a
trusted application.

Note: Trusted applications are not supported on WebSphere MQ Integratorfor

z/OS.

This does not affect the operation of any MQSeries channel agents or listeners. If
you want to run these as trusted applications, you must follow the guidance in
MQSeries Intercommunication, in the section entitled “Running channels and
listeners as trusted applications”.

You must be aware that MQSeries places a number of restrictions on the operation
of a trusted MQSeries application. If you want to enable a broker as a trusted
application, you must first review these restrictions for applicability to your own
environment. They are documented in the MQSeries Application Programming Guide,
in the section entitled “Connecting to a queue manager using the MQCONNX
call”.

You must also consider:

v MQSeries trusted applications must run with an effective user ID and group ID
of mqm. You must therefore have created the broker to run under this user ID.
v You must be careful if you are deploying plug-in nodes, or parsers, or both.
Because the trusted application (the broker) is running in the same operating
system process as the queue manager, an ill-behaved plug-in could compromise
the integrity of the queue manager.
You are therefore recommended to develop all plug-in components with full
consideration of the restrictions. You are also advised to test plug-in components
in a non-trusted environment before deploying them in a trusted broker.

160 WebSphere® MQ Integrator: Introduction and Planning

 Monitoring the network
Tuning message flow performance
When you have assigned a message flow to a broker, you can modify the default
values of some of its properties to improve its throughput.

For more details of these properties, see WebSphere MQ Integrator Using the Control
Center and the Control Center online help.

System management
WebSphere MQ Integrator uses architected messages to publish events related to
the status, and change in status, of the brokers. These messages are published
using the reserved topic root $SYS in code page 1208.

The format of these messages, constructed in XML, is detailed in the WebSphere

MQ Integrator Administration Guide. The messages cover configuration changes,
state changes, error notifications, and detailed subscription and topic information
(for example, a subscription registration).

You can develop or purchase system management adapters or customized

administrative applications. These subscribe to the system management topics
generated by WebSphere MQ Integrator to receive information on the broker
domain activity.

Chapter 10. Managing your WebSphere MQ Integrator network 161

Monitoring the network

162 WebSphere® MQ Integrator: Introduction and Planning

Chapter 11. Enhancing your broker domain
This chapter discusses advanced options that extend the basic functions of the
broker and other components, and hence allow you to enhance your broker
domain.

Details of implementing the advanced functions discussed here are provided in the
WebSphere MQ Integrator Programming Guide.

The topics covered are:

v “General guidance for writing plug-ins”
v “Writing your own message processing node types” on page 164
v “Writing your own parsers” on page 164

General guidance for writing plug-ins

WebSphere MQ Integrator provides support for you to extend your system by
writing components that plug in to the framework provided by the product. The
“plug-ins” supported are message processing node types and message parsers. The
guidelines you need to understand and follow are mostly the same for both
plug-in types. The common considerations are discussed here, followed by sections
that indicate the special considerations for each plug-in type in turn.

A plug-in, or broker extension, must be written in the C or Java (for a plug-in

node) programming language. It must be distributed as a shared library. The file
type of the shared library must be set to the value required by the operating
system on which it runs. These values are given in the WebSphere MQ Integrator
Programming Guide.

If you plan to program using either of the supplied plug-in interfaces, you must
install the “Samples and SDK” optional component on at least one system. The
SDK provides the required header files and contains samples that you can modify
to your own requirements.

You can use your new node types or parsers on more than one operating system, if
you make them platform independent. You can achieve this platform independence
by using the ANSI standard C or Java programming languages.

Refer to the WebSphere MQ Integrator Programming Guide for further information on:
v The programming interface for both plug-in types, including all the calls and
parameters
v How to create the icon, signature, and help files for the message processing node
type using the Plug-in SmartGuide in the Control Center
v How to build the required components for each interface
v The content of the supplied sample files

© Copyright IBM Corp. 2000, 2002 163

Writing message processing nodes

Writing your own message processing node types

You can create your own message processing node types to complement the
primitive node types provided by WebSphere MQ Integrator.

You might want to do this, for example:

v If your messages need additional transformation not provided by the primitive
nodes. For example, you might need a currency converter node.
v If you want to write messages into a flat file on the local system for later
processing by another application or utility program.

You can use your new node types with existing primitive node types to create
message flows to achieve the processing your messages require.

Writing your own parsers

Message parsers are invoked by the processes within a broker to interpret the
bit-stream forming a message and its header (or headers). WebSphere MQ
Integrator provides a number of message parsers that handle a wide range of
messages and headers, and cover the majority of formats that are expected to be
processed within a broker domain. These default parsers are described in “Message
parsers” on page 74.

However, you might need to use messages that are not covered by these default
parsers. To allow for this possibility, WebSphere MQ Integrator provides an
external interface that enables you to supply your own parsers. These can be
invoked by the broker processes whenever a message of this new type is received,
and can work in the broker alongside the default parsers.

When you define a message, one of its attributes is the message domain. This is
the value that tells the broker which parser must be invoked to interpret the
bit-stream.

164 WebSphere® MQ Integrator: Introduction and Planning

Part 5. Appendixes

© Copyright IBM Corp. 2000, 2002 165

166 WebSphere® MQ Integrator: Introduction and Planning
Appendix A. Planning for migration and integration
This chapter helps you plan for migration to WebSphere MQ Integrator Version 2.1
from compatible IBM offerings. It gives you an overview of the tasks involved, and
provides references to the detailed information you need to complete these tasks.

Refer to the section giving details for your existing product:

v “MQSeries Integrator Version 1”
v “MQSeries Publish/Subscribe” on page 171

If you are migrating from MQSeries Integrator Version 2.0, Version 2.0.1 or Version
2.0.2 to WebSphere MQ Integrator Version 2.1, see “Release to release migration”
on page 40, see also the Appendix A, “Planning for migration and integration”.
You should also refer to the Readme.txt file that is provided on the product CD.
This gives the latest information about migration requirements.

MQSeries Integrator Version 1

Migration to WebSphere MQ Integrator Version 2.1 is supported from the following
products:
v MQSeries Integrator Version 1.02
v MQSeries Integrator Version 1.1

Migration information can be found in the WebSphere MQ Integrator Administration

Guide and in the WebSphere MQ Integrator for z/OS Customization and Administration
Guide.

The tasks you must plan for are:

“Installation”:
This identifies tasks you must complete before and immediately after
installation of WebSphere MQ Integrator Version 2.1
These tasks are fully described in the WebSphere MQ Integrator Installation
Guide for your product.
“Run-time” on page 168:
This identifies tasks you must complete during normal operation to enable
the continued use of your Version 1 resources.
These tasks are fully described in either the WebSphere MQ Integrator
Administration Guide, or in WebSphere MQ Integrator Using the Control Center.

Installation
You should consider these areas when you plan the installation of WebSphere MQ
Integrator Version 2.1:
v “Backing up configuration files” on page 168
v “Preserving your MQSeries Integrator Version 1 rules and formats” on page 168
v “Uninstallation of MQSeries Integrator Version 1” on page 168

2. It is also possible to upgrade from New Era of Networks’s MQIntegrator product. The tasks required are identical to those
specified for migrating from MQSeries Integrator Version 1.0. However, the presence of this product is not detected by the
WebSphere MQ Integrator Version 2.1 installation program.

© Copyright IBM Corp. 2000, 2002 167

MQSeries Integrator Version 1
Backing up configuration files
MQSeries Integrator Version 1 uses a number of configuration files to control
various aspects of its operation. Some of these files are reused by WebSphere MQ
Integrator Version 2.1, and can be updated in some circumstances.

You are therefore advised, but not forced, to back up your MQSeries Integrator
Version 1 configuration files.

For details of configuration files, see the WebSphere MQ Integrator Installation Guide
for your product.

Preserving your MQSeries Integrator Version 1 rules and formats

All the rules and formats you have defined in MQSeries Integrator Version 1 can
be reused by WebSphere MQ Integrator Version 2.1. The message processing nodes
NEONRulesEvaluation, NEONTransform, NEONMap, NeonRules and
NeonFormatter nodes) provide the New Era of Networks Rules and Formatter
function in WebSphere MQ Integrator Version 2.1 and can reproduce the MQSeries
Integrator Version 1.1 behavior.

If you have rules and formats defined by any previous version of MQSeries
Integrator (including Version 1.1, Version 2.0.1, and Version 2.0.2) that you want to
reuse, you must export this data from your previous version (using the tools
supplied with that version) then import it into WebSphere MQ Integrator Version
2.1 (using the tools supplied with V2.1). This converts the data into a format
suitable for use with WebSphere MQ Integrator V2.1.

Uninstallation of MQSeries Integrator Version 1

You must remove all previous versions of MQSeries Integrator (versions 1.0, 1.1,
1.1.1, 2.0, 2.0.1, and 2.0.2) before you install WebSphere MQ Integrator Version 2.1.

Run-time
You must consider these operational aspects when planning your migration from
MQSeries Integrator Version 1 to WebSphere MQ Integrator Version 2.1. These are:
v “New Era of Networks rules and formats”
v “Setting up a message flow that emulates the functionality of the Version 1 Rules
engine” on page 169

New Era of Networks rules and formats

WebSphere MQ Integrator Version 2.1 provides message parsers that interpret the
New Era of Networks message formats, and these are used by any message
processing node that detects a New Era of Networks message has been received.
Therefore interpretation of messages in New Era of Networks formats can be
provided to any message processing node, not just the NEONRulesEvaluation,
NEONTransform, NEONMap, NeonRules and NeonFormatter nodes).

Update of message content is provided by the NEONTransform, NEONMap and

NeonFormatter nodes and the Compute node.

Access to the database containing existing definitions is defined by the nnsyreg.dat

configuration file (it was MQSIruleng.mpf in MQSeries Integrator Version 1).
WebSphere MQ Integrator Version 2.1 accesses the configuration file by
interrogating the environment variable NN_CONFIG_FILE_PATH. You must set
this variable to point to the default file supplied by WebSphere MQ Integrator
Version 2.1.

168 WebSphere® MQ Integrator: Introduction and Planning

 MQSeries Integrator Version 1
Note that:
v You can modify the version given in the examples directory.
v You can modify the version created by the New Era of Networks Rules and
Formatter Support component when the setup program inst_db is run.
v On Windows NT, you must restart your system to enable these changes.

You can encrypt the nnsyreg.dat file to protect the password. See the New Era of
Networks Rules and Formatter Support for WebSphere MQ Integrator System
Management Guide for more details.

You must be aware that the New Era of Networks Rules and Formats defined by
the New Era of Networks Rules and Formatter GUI tools are not distributed
automatically to all brokers that need them, as those defined by the WebSphere
MQ Integrator Version 2.1 Control Center are. You must configure your system so
that every broker running a message flow that accesses your New Era of Networks
Rules and Formats has access to the database that contains these definitions. It
should also be noted that only one rules and formatter database can be accessed
per machine. This means that if two brokers are installed in the same machine they
must both access the same rules and formatter database — there can only be one
nnsyreg.dat on a particular machine.

WebSphere MQ Integrator Version 2.1 provides full support for MQRFH headers,
as well as MQRFH2 headers. If you are developing new applications, you are
recommended to use the new MQRFH2, which offers superior function.

For further details of these tasks, see the WebSphere MQ Integrator Administration
Guide.

Enhancing existing rules and formats: WebSphere MQ Integrator Version 2.1

provides support for you to continue to develop new and modify existing rules
and formats. It does this by installing the New Era of Networks Rules and Formats
graphical utility programs.

You can therefore continue to maintain existing data, and can add new definitions
to your existing set. Refer to the New Era of Networks Rules and Formatter Support for
WebSphere MQ Integrator User’s Guide for information on using these user
interfaces.

The New Era of Networks Formats are represented in the Control Center under the
Message Sets tab. This is so that New Era of Networks Formats can be used as
Inputs or Outputs for the purpose of defining field mappings in the Compute or
Database properties panels. Although the New Era of Networks Formats can be
viewed from the Message Sets tab, they cannot be edited, and you are
recommended to use the New Era of Networks Formatter GUI (which can be
launched from the Control Center) for viewing as well as editing existing New Era
of Networks Formats or creating new ones.

Setting up a message flow that emulates the functionality of the

Version 1 Rules engine
To provide continued support for your existing MQSeries Integrator Version 1
applications, you must deploy an WebSphere MQ Integrator Version 2.1 message
flow that emulates the function of the MQSeries Integrator Version 1 product
daemon.

Appendix A. Planning for migration and integration 169

MQSeries Integrator Version 1
Default MQSeries Integrator Version 1 message flows are provided for your use.
The message flow for Version 2.0.2 includes the NEONRulesEvaluation message
processing node and the NeonRules node3. The default message flow for Version
2.0.1 and earlier includes the NeonRules message processing node. In addition,
they include:
v An MQInput node, that reads input messages from an input queue and delivers
them to the NEONRulesEvaluation or the NeonRules node.
v Three MQOutput nodes, that handle messages for Output, Failure, and NoHit
processing.

Before you deploy either default message flow, you must edit the node properties
of the MQInput and MQOutput nodes to align with your MQSeries Integrator
Version 1 use of queues.

You must also ensure that any broker to which you assign this message flow can
access the database in which your formats and rules are defined.

You can also use New Era of Networks format messages with other message
processing nodes within a message flow. You must define a message flow with the
message processing nodes providing the function your message processing
requires. The nodes detect the presence of a New Era of Networks header and
invoke the New Era of Networks parser to interpret the message.

If you want to change the content of the message, you must use the
NEONTransform node, the NeonFormatter node or the NEONMap node. You can
also use the Compute node to write New Era of Networks format messages.

You can also modify the default message flow supplied to include additional
function. For example, you can cause all messages to be stored in a warehouse by
adding a Warehouse node into the message flow before the NEONRulesEvaluation
node.

If you include the NEONRulesEvaluation message processing node in your

message flow, you can continue to use existing subscriptions with that message
flow. You can also continue to use the New Era of Networks Rules user interface to
modify existing and create new subscriptions. Or you could replace the node
handling messages destined for the NoHit queue with one that updates the
message and returns it to the originator.

WebSphere MQ Integrator Using the Control Center provides details on how to define,
modify, assign, and deploy message flows.

You can increase the throughput of New Era of Networks messages by assigning
the same message flow to multiple execution groups on a single broker, or to
multiple brokers, or both. WebSphere MQ Integrator Version 2.1 implements
synchronization controls around the New Era of Networks message processing
nodes to ensure the integrity of the multiple flows.

3. The message flows only emulate the function of an unmodified MQSeries Integrator Version 1.1 daemon. If you have modified
the daemon in your MQSeries Integrator Version 1.1 product, these message flows do not provide identical function. You must
also modify these message flows to recreate the modifications you have made to the daemon.

170 WebSphere® MQ Integrator: Introduction and Planning

 MQSeries Integrator Version 1
User exits
You can continue to use your existing MQSeries Integrator Version 1.1 user exits
with WebSphere MQ Integrator Version 2.1 message processing nodes. The source
of your exit programs can be used unchanged. However, you must rebuild them to
use the new dynamic link interface that is required by the WebSphere MQ
Integrator Version 2.1 modules that provide the WebSphere MQ Integrator Version
2.1 function. For further information see the New Era of Networks Rules and
Formatter Support for WebSphere MQ Integrator User’s Guide and the WebSphere MQ
Integrator Administration Guide.

If you are migrating from MQSeries Integrator Version 1.0, your user exits must be
modified to be compatible with MQSeries Integrator Version 1.1 before they can be
used with WebSphere MQ Integrator Version 2.1.

MQSeries Publish/Subscribe
MQSeries Publish/Subscribe is supported software that provides publish/subscribe
application support for MQSeries applications. It is available from the IBM Web
site, and can be installed on several MQSeries Messaging products servers,
including:
v AIX
v HP-UX
v Solaris
v Windows NT and Windows 2000
v OS/390 and z/OS

You can find latest details of MQSeries Publish/Subscribe, including how to

download the product code, on the following web site:
http://www.ibm.com/software/ts/mqseries/txppacs/ma0c.html

If you plan to create a heterogeneous network including WebSphere MQ Integrator

brokers and MQSeries Publish/Subscribe brokers, you must ensure your systems
have the appropriate level of MQSeries to run your brokers.
MQSeries Version 5.0
For MQSeries Publish/Subscribe brokers, you must install CSD7.

Note: You cannot run WebSphere MQ Integrator brokers on MQSeries

Version 5.0 at any service level. This option is only valid for MQSeries
Publish/Subscribe brokers.
MQSeries Version 5.1
For MQSeries Publish/Subscribe brokers, you must install CSD3 on
Windows NT, or CSD1 on AIX and Solaris platforms.

Note: You cannot run WebSphere MQ Integrator brokers on MQSeries

Version 5.1 at any service level. This option is only valid for MQSeries
Publish/Subscribe brokers.
MQSeries Version 5.2.
This is the minimum level for the HP-UX, z/OS and OS/390 platforms.

If you do not upgrade MQSeries to these specified service levels, some publications
sent by WebSphere MQ Integrator brokers might be wrongly put to the dead-letter
queue (DLQ) by an MQSeries Publish/Subscribe neighbor.

Appendix A. Planning for migration and integration 171

MQSeries Publish/Subscribe
Scenarios for migration and integration
If you are already using MQSeries Publish/Subscribe, you can take advantage of
the improved message processing function provided by WebSphere MQ Integrator
by integrating your two networks of brokers and creating a heterogeneous
network.

You can also migrate individual MQSeries Publish/Subscribe brokers to create

replacement WebSphere MQ Integrator brokers, with support for their client
applications intact.

These two possibilities offer you a number of advantages:

v Publications from within the MQSeries Publish/Subscribe network can be
targeted by WebSphere MQ Integrator subscribers. This includes messages
originating in environments not yet supported by WebSphere MQ Integrator.
v Message flows can be created and deployed on WebSphere MQ Integrator
brokers to:
– Analyze the information that is flowing around your enterprise.
– Invoke additional business logic dependent upon the content of the
publications.
– Consolidate the information within your enterprise in the form of new
publications, which can then be republished as a series of additional topics
available to both WebSphere MQ Integrator and MQSeries Publish/Subscribe
clients.

There are three possible scenarios for exploiting the two networks:
1. You can choose to have two independent broker networks, and therefore have
two separate broker domains for publish/subscribe applications. This scenario
is described in “Scenario 1: running two independent broker networks” on
page 185.
2. You can connect the two networks to allow publications and subscriptions to
flow throughout the integrated network. Further details are provided in
“Scenario 2: creating and operating a heterogeneous network” on page 185.
3. You can selectively and gradually migrate individual brokers from MQSeries
Publish/Subscribe to WebSphere MQ Integrator Version 2.1. For more guidance
on this option, see “Scenario 3: migrating MQSeries Publish/Subscribe brokers”
on page 186.

Before you can make this choice, and create your migration plan, you must be
aware of the differences in the two products, described in “Product differences”.

Product differences
There are differences in the support provided by the two products that you must
consider when you plan how to integrate your two networks. These are discussed
in the following sections:
v “Message formats” on page 173
v “Streams” on page 175
v “Stream authority” on page 178
v “Topics” on page 180
v “Wildcards” on page 180
v “Default topic routing” on page 182
v “Retained publications” on page 182
v “Metatopics” on page 182
v “Subscription points” on page 183

172 WebSphere® MQ Integrator: Introduction and Planning

 MQSeries Publish/Subscribe
v “Content-based filtering” on page 183
v “Throughput” on page 184

Message formats
You are recommended to use the MQRFH2 header for new client applications
developed for the WebSphere MQ Integrator broker. These applications can then
access all the functions that are provided by WebSphere MQ Integrator.

Existing MQSeries Publish/Subscribe applications using the MQRFH header are

also supported by WebSphere MQ Integrator, but function is limited to that
provided by MQSeries Publish/Subscribe. MQSeries Publish/Subscribe does not
support the MQRFH2 format. Clients connected to MQSeries Publish/Subscribe
brokers must use the MQRFH format.

However, client applications that need to communicate with one another using
publish/subscribe can do so regardless of the format of the messages they are
using: WebSphere MQ Integrator provides automatic conversion to ensure the
subscriber receives the message in the desired format.

Table 7 shows the mapping between equivalent fields in the MQRFH and
MQRFH2 headers.
Table 7. MQRFH and MQRFH2 mapping
MQRFH field name MQRFH2 field name
MQPSCommand Command
MQPSDelOpts DelOpt
MQPSPubOpts PubOpt
MQPSPubTime PubTime
MQPSQMgrName QMgrName
MQPSQName QName
MQPSRegOpts RegOpt
MQPSSeqNum SeqNum
MQPSTopic Topic

All the MQRFH2 fields shown are contained in a <psc> folder.

Field names that are not included in Table 7 do not have a common meaning, or
are only valid in one header or the other. Field names that are not recognized, or
not appropriate to the other format, are not copied. For example, the following
name-value area of an MQRFH:
MQPSCommand Publish
MQPSPubOpts RetainPub
MQPSStreamName SAMPLE.BROKER.RESULTS.STREAM
MQPSTopic "Sport/Soccer/State/LatestScore/Team1 Team2"

is converted to this MQRFH2 folder:

<psc>
<Command>Publish</Command>
<PubOpt>RetainPub</PubOpt>
<Topic>Sport/Soccer/State/LatestScore/Team1 Team2</Topic>
</psc>

Appendix A. Planning for migration and integration 173

MQSeries Publish/Subscribe
Using these mapping rules, WebSphere MQ Integrator ensures that MQRFH2
publications can still be received by MQRFH subscribers, and MQRFH publications
can be received by MQRFH2 subscribers.

Content-filters can also be specified by MQRFH2 subscribers even if the topic that
they are subscribing to is one published in MQRFH format by an MQSeries
Publish/Subscribe client, although there is some limit to compatibility. For more
information, see “Content-based filtering” on page 183.

Table 8 summarizes the valid options for clients using the different message
formats.
Table 8. Summary of message option support
Message Option Name Option Value Support
All requests MQPSCommand DeletePub yes
(client to broker) DeregPub yes1
DeregSub yes
Publish yes
RegPub yes1
RegSub yes
ReqUpdate yes
MQMD.Format MQFMT_PCF no
MQFMT_RF_HEADER yes
MQMD.Report MQRO_PAN yes
MQRO_NAN yes
MQMD.MsgType MQMT_REQUEST yes
MQMT_DATAGRAM yes
MQMD.MsgId yes
MQMD.CorrelId yes4
MQMD.ReplyToQ yes
MQMD.ReplyToQMgr yes
MQPSStreamName prefixed on topic3
MQPSTopic yes
All requests except MQPSQMgrName yes
Delete Publication
MQPSQName yes
MQPSRegOpts CorrelAsId yes
Delete Publication MQPSDelOpts Local yes5
Deregister Publisher1 MQPSRegOpts DeregAll yes
Deregister Subscriber MQPSRegOpts DeregAll yes
Publish MQMD fields As specified by MQPS2 yes
MQPSRegOpts Anon yes7
Local yes5
DirectReq yes1
MQPSPubOpts NoReg yes1
RetainPub yes (set by publisher)
IsRetainedPub yes (set by broker)
OtherSubsOnly yes
MQPSPubTime yes
MQPSSeqNum yes
1
MQPSStringData yes
MQPSIntData1 yes

174 WebSphere® MQ Integrator: Introduction and Planning

 MQSeries Publish/Subscribe
Table 8. Summary of message option support (continued)
Message Option Name Option Value Support
1
Register Publisher MQPSRegOpts Anon yes7
Local yes5
DirectReq yes1
Register Subscriber MQPSRegOpts Anon yes7
Local yes5
NewPubsOnly yes
PubOnReqOnly yes
InclStreamName no3
InformIfRet yes
All responses MQPSCompCode new values added6
(broker to client)
MQPSReason new values added6
MQPSReasonText new values added6
MQPSCommand command to which
this is a response
Notes:
1. This option is supported for migration purposes.
2. MQPS is MQSeries Publish/Subscribe.
3. The stream name parameter is effectively prefixed on the topic. The stream name can be deduced from the queue name if the
property implicitStreamNaming of the Publication node is set (see “Streams”).
4. The client identity is determined as the concatenation of the queue manager name, the queue name, and optionally the
correlation id (when the correlation ID as identity option is set). The application identifier is thus
“MQPSQMgrName:MQPSQName[:correlId]”. The default values specified by MQSeries Publish/Subscribe are used if these
values are not present in a message.
5. The behavior of this option differs. See the WebSphere MQ Integrator Programming Guide for an explanation of this option.
6. New values have been added. See the WebSphere MQ Integrator Programming Guide for details.
7. Ignored by WebSphere MQ Integrator Version 2.1.

Special rules also apply for MQRFH2 subscribers if the information is being
published on an MQSeries Publish/Subscribe stream other than the default stream,
SYSTEM.BROKER.DEFAULT.STREAM.

These rules are summarized in Table 9 on page 176.

Streams
MQSeries Publish/Subscribe primarily use streams as a means to partition the
topic name space. Sets of related topics could be grouped together into separate
streams allowing different security controls to be applied, and the publishing
workload of the broker to be better balanced.

WebSphere MQ Integrator provides more flexible controls to achieve both of these

behaviors. The concept of a stream is only supported for MQRFH application
compatibility.

Stream names now only have the partitioning effect on the topic name space.
WebSphere MQ Integrator provides more flexible security controls that allow
authorization to be applied to an individual topic level. Also, the publishing
workload of the broker can be more easily controlled by creating additional
instances of publication message flows either serving the same or different input
queues.

WebSphere MQ Integrator still allows MQRFH client applications to specify an

MQPSStreamName command parameter in their subscriptions and publications.

Appendix A. Planning for migration and integration 175

MQSeries Publish/Subscribe
However, the stream name is only used to modify the topic in order to preserve
the partitioning characteristic of MQSeries Publish/Subscribe.

When the stream-name associated with a message is set to something other than
SYSTEM.BROKER.DEFAULT.STREAM, the message is processed as if the topic (or
topics) mentioned within the message had been prefixed with the string
“$SYS/STREAM/<streamname>/”. That is, a subscription to Topic1 that specifies
a stream name of StreamX is processed as if the subscription had been made to
topic “$SYS/STREAM/StreamX/Topic1”.

MQRFH2 publishing and subscribing applications can still target stream-related

topics, even though they themselves are not allowed to specify a stream name in
the messages they send to the WebSphere MQ Integrator broker. To do this, they
must prefix the topics with the appropriate stream prefix.

For example, an MQRFH2 subscriber must specify topic

“$SYS/STREAM/STOCK.STREAM/IBM/Latest” in order to subscribe to topic
“IBM/Latest” that is published on stream STOCK.STREAM within the MQSeries
Publish/Subscribe network.

MQSeries Publish/Subscribe only allows a stream-related publication to be sent to

a queue with the same name as the stream. However, WebSphere MQ Integrator
allows publishing clients to send their publications to any input queue in a
message flow. MQRFH applications choosing explicitly to specify a stream name
parameter within a publication can send it to any publication queue being serviced
by the WebSphere MQ Integrator broker. The queue no longer needs to have the
same name as the stream. However, this behavior could affect the order in which
publications are received, and you must consider the importance of ordering for
your applications. For more details about ordering, see “Throughput” on page 184.

Each Publication node has an Implicit Stream Naming property that defaults to true.
This default option results in behavior identical to that in MQSeries
Publish/Subscribe when an MQRFH publication does not contain an explicit
stream name. If this property is false, and the publication contains no explicit
stream name, SYSTEM.BROKER.DEFAULT.STREAM is assumed.

Table 9 summarizes the options available to both MQRFH and MQRFH2 client
applications publishing messages to either the default stream, or a specific
MQSeries Publish/Subscribe stream. An example stream name of StreamX is used
to illustrate the options.
Table 9. MQRFH and MQRFH2 client application options
MQRFH publisher MQRFH2 publisher

default stream StreamX default stream StreamX

MQRFH subscriber S1,P1 S2,P2 S1,P3 S2,P4

MQRFH2 subscriber S3,P1 S4,P2 S3,P3 S4,P4

Subscriber notes:
S1 Subscriber subscribes either without a stream name or
with stream name “SYSTEM.BROKER.DEFAULT.STREAM”.
S2 Subscriber subscribes with stream name “StreamX”.
S3 Subscriber subscribes on topic without adding
“$SYS/STREAM/<streamname>/”.

176 WebSphere® MQ Integrator: Introduction and Planning

 MQSeries Publish/Subscribe
S4 Subscriber subscribes prefixes topic with
“$SYS/STREAM/StreamX/”.

Publisher notes:
P1 Publisher publishes on any queue specifying stream name
“SYSTEM.BROKER.DEFAULT.STREAM”. or publishes without
specifying a stream name on any queue with the Implicit
Stream Naming property set to false.
P2 Publisher publishes on any queue specifying stream name
“StreamX”, or publishes without specifying a stream name on
queue “StreamX” with the Implicit Stream Naming property set
to true.
P3 Publisher publishes on any queue without adding the
prefix “$SYS/STREAM/<Stream>/” to the topic.
P4 Publisher publishes on any queue and adds the prefix
“$SYS/STREAM/StreamX/” to the topic.

Note: The “$SYS/STREAM/<streamname>/” prefix is removed from all topics in

an MQRFH2 publication when it is delivered to an MQRFH subscriber.

Streams and neighbor brokers: In an MQSeries Publish/Subscribe network it is

not mandatory for all brokers to support the same set of streams as its neighbors.
If a broker does not support a stream that is supported by one of its neighboring
brokers, publications associated with the uncommon stream are simply not
available to clients at that broker.

When an WebSphere MQ Integrator broker joins the network, it acts as if it

supports all the streams of its neighboring MQSeries Publish/Subscribe broker.
This means that clients of the WebSphere MQ Integrator broker can target
publications for any stream supported by any of its MQSeries Publish/Subscribe
neighbors.

However, to make these publications available, you must define the stream queues,
and define and deploy the message flows that support them, to the WebSphere
MQ Integrator broker.

The effects of adding an WebSphere MQ Integrator broker into a multi-stream

MQSeries Publish/Subscribe environment are illustrated by the example in
Figure 20. The WebSphere MQ Integrator broker, NEWBROKER, has been used to
join MQSeries Publish/Subscribe brokers, BROKERA, and BROKERB.

BROKERA NEWBROKER BROKERB

Streams: Streams:
BULLETIN.STREAM BULLETIN.STREAM
RESULTS.STREAM SYSTEM.BROKER.DEFAULT.STREAM
STOCK.STREAM WEATHER.STREAM
SYSTEM.BROKER.DEFAULT.STREAM

Figure 20. A heterogeneous network

The default stream queue SYSTEM.BROKER.DEFAULT.STREAM is always

supported by every broker in an MQSeries Publish/Subscribe network, and must
be defined at every WebSphere MQ Integrator broker in a heterogeneous network.
You must also define and deploy a message flow at each broker to service this
queue.

Appendix A. Planning for migration and integration 177

MQSeries Publish/Subscribe
When an WebSphere MQ Integrator broker is integrated into an MQSeries
Publish/Subscribe network, and links two or more MQSeries Publish/Subscribe
brokers that share common streams, you must define the common stream queues,
and define and deploy the message flows that service them, to the WebSphere MQ
Integrator broker.

For example, the WebSphere MQ Integrator broker NEWBROKER shown in

Figure 20 on page 177 must have a stream queue defined for BULLETIN.STREAM.
It must also have a message flow defined and deployed to provide a publication
service for that queue.

You only need to define stream queues and associated message flows to the
WebSphere MQ Integrator broker for the other streams shown in Figure 20 on
page 177 if one of its MQSeries Publish/Subscribe neighbors can send a message to
one of these queues. A message is sent if one of the following occurs:
1. A subscription to a publication on one of these streams is registered by a client
of the WebSphere MQ Integrator broker.
2. A DeletePublication command for the stream is issued by a client anywhere
within the broker network.

If you are unsure about whether the above cases might occur, it is recommended
that you create stream queues and message flows in the WebSphere MQ Integrator
broker for every stream that is supported by an MQSeries Publish/Subscribe
neighbor. If you do not do this, you might see the following results:
v Messages sent from MQSeries Publish/Subscribe brokers are put on the
dead-letter queue (DLQ) of the WebSphere MQ Integrator broker if the stream
queue does not exist on that broker.
v Messages build up on stream queues on the WebSphere MQ Integrator broker if
the stream queue exists but no message flow is deployed to service it.

Streams and migration: When an MQSeries Publish/Subscribe broker is migrated

to an WebSphere MQ Integrator broker (using the migmqbrk command), the
streams supported at the time of the migration are replicated exactly in the
WebSphere MQ Integrator broker: no subsequent changes can be made (that is, no
streams can be added or removed from this replicated set). The migration is not
complete until you have created and deployed message flows that process all these
streams.

Stream authority
In MQSeries Publish/Subscribe, all publish and subscribe authority checks are
performed against the stream queue. Publishing applications need authority to put
messages to the stream queue. The MQSeries Publish/Subscribe broker also checks
the authority of subscribing applications which require browse authority on the
stream queue. A subscribing application also needs to have put authority for the
queue that it nominated to receive its publications.

The same check is made by WebSphere MQ Integrator brokers, but the subscribe
authority (browse) is no longer checked. Instead, WebSphere MQ Integrator
provides a more granular security model in which both publish and subscribe
access can be defined in a hierarchical manner right down to an individual topic
level. You can implement this model by creating Access Control Lists (ACLs) using
the Control Center. For more information about ACLs, refer to WebSphere MQ
Integrator Using the Control Center.

178 WebSphere® MQ Integrator: Introduction and Planning

 MQSeries Publish/Subscribe
Before you migrate an MQSeries Publish/Subscribe broker to a replacement
WebSphere MQ Integrator broker, or migrate your MQSeries Publish/Subscribe
applications to run on WebSphere MQ Integrator, you must consider the security
implications:
v Publishing applications are subject to the same checks even if your broker is not
running with topic security enabled, because the authority to put a message to
the stream or publication queue continues to be checked by MQSeries.
However, stream publications can be processed by WebSphere MQ Integrator on
any input queue, because publishers no longer need to put to a queue with the
same name as the stream. You are therefore recommended to set up equivalent
ACLs for all streams using their corresponding topic level qualifiers
v The WebSphere MQ Integrator broker does not check that subscribing
applications have browse authority on the stream queue. Instead, WebSphere
MQ Integrator models streams by prefixing all topics that aren’t part of the
default stream with a unique prefix, $SYS/STREAM/<streamname>/. This
maintains the partitioning characteristics of streams and allows stream-specific
ACLs to be set up. Topics in the default stream are not altered by the broker,
therefore the root topic can be used to specify authorities for default stream
topics.

Figure 21 illustrates the stream authorities that are required. This example assumes
(1) “ ” (root topic)

(2) “$SYS/STREAM/”

(3) “$SYS/STREAM/StreamX/” (4) “$SYS/STREAM/StreamY/”

Figure 21. Stream authorities

that you have updated the default ACL on the topic root for principal PublicGroup
with authority for publish, subscribe, and persistent delivery all set to deny.

Using this example, assume that the following groups are defined:
v PDefault: the group of users authorized to publish on the default stream
v SDefault: the group of users authorized to subscribe to the default stream
v PStreamX: the group of users authorized to publish on StreamX
v SStreamX: the group of users authorized to subscribe to StreamX
v PStreamY: the group of users authorized to publish on StreamY
v SStreamY: the group of users authorized to subscribe to StreamY

Appendix A. Planning for migration and integration 179

MQSeries Publish/Subscribe
You must grant and deny authorities by setting up ACLs as follows:
1. PDefault must be granted publish authority on the root, SDefault must be
granted subscribe authority on the root.
2. PDefault must be denied publish authority on $SYS/STREAM/, SDefault must
be denied subscribe authority on $SYS/STREAM/.
These settings ensure that publishers and subscribers on the default stream are
unable to publish on or subscribe to other streams automatically (that is,
without an explicit ACL that overrides that setting).
3. PStreamX must be granted publish authority on $SYS/STREAM/StreamX/,
SStreamX must be granted subscribe authority on $SYS/STREAM/StreamX/.
These settings override any setting on parent topics and limit publish and
subscribe activity to users within these specific groups.
4. PStreamY must be granted publish authority on $SYS/STREAM/StreamY/,
SStreamY must be granted subscribe authority on $SYS/STREAM/StreamY/.
These settings override any setting on parent topics and limit publish and
subscribe activity to users within these specific groups.

If you wanted to set up exceptions to this situation, you can do so by introducing

an ACL at the appropriate point. For example, if you wanted to grant authority to
publishers to the default stream (PDefault) to publish on StreamX, you must create
an explicit ACL at point (3) to grant that authority, thus overriding the denial at
point (2). In this scenario, users in PDefault could still not publish on StreamY.

Topics
In MQSeries Publish/Subscribe, all publications must be tagged with an arbitrary
character string called a topic. This defines the subject matter of the publication.
MQSeries Publish/Subscribe recommends, though does not enforce, that topic
strings are structured into a number of fields or levels using the forward slash,
“/”, as a delimiter.

WebSphere MQ Integrator publications also have an associated topic, and the topic
structure is delimited by the forward slash character. Therefore, if your existing
applications follow the MQSeries Publish/Subscribe recommendation, they are
better positioned to exploit the function provided by WebSphere MQ Integrator,
which allows the structure of the topic to be externalized.

WebSphere MQ Integrator allows you to control users’ authority to publish on, and
subscribe to, any topic at any level within the topic structure.

Wildcards
Wildcards can be used by subscribing applications to broaden the scope of
publications they register an interest in. By specifying a wildcard, the subscriber is
specifying a general pattern of the topics they are interested in, rather than an
explicit topic.

This function is provided by both MQSeries Publish/Subscribe and WebSphere

MQ Integrator. However, WebSphere MQ Integrator provides a different set of
wildcards that allow a more extensive and flexible use of wildcards by subscribers.
v MQSeries Publish/Subscribe wildcards:
– An asterisk (*) matches zero or more characters.
– A question mark (?) matches exactly one character.
– The percent sign (%) can be used as an escape character to use an “*”, a “?”,
or a “%” character within a topic.

180 WebSphere® MQ Integrator: Introduction and Planning

 MQSeries Publish/Subscribe
v WebSphere MQ Integrator wildcards:
The wildcard characters are used to match specific levels within the structured
topic. The characters used are:
– The multi-level wildcard (the character #), that matches any number of levels
at the start or end of the topic.
– The single-level wildcard (the character +), that matches a single level within
the topic.

The full range of function of the WebSphere MQ Integrator wildcards are only
available to MQRFH2 clients. Subscriptions made by MQRFH clients to WebSphere
MQ Integrator brokers for topics that contain either of the WebSphere MQ
Integrator wildcards are rejected with the MQRCCF_TOPIC_ERROR reason code.

Applications using MQRFH and connecting to MQSeries Publish/Subscribe

brokers in a heterogeneous network are therefore recommended not to publish on,
or subscribe to, topics containing either the multi-level wildcard (#) or single-level
wildcard (+) characters. MQSeries Publish/Subscribe brokers do not police this: if
your applications specify the WebSphere MQ Integrator wildcards in topics when
they publish or register a subscription in a heterogeneous broker network, these
publications and subscriptions are ignored by WebSphere MQ Integrator brokers
within the network. You are therefore strongly advised to review and if necessary
change the topics being used within an MQSeries Publish/Subscribe
implementation before adding an WebSphere MQ Integrator broker to the network.

When applications that use MQRFH2 use the WebSphere MQ Integrator wildcards
to target multiple publications from within the MQSeries Publish/Subscribe
network, wildcard mapping is performed. In most cases, the broker replaces both
the multi-level wildcard and single-level wildcard characters with an asterisk. This
does not provide an exact match for either of the WebSphere MQ Integrator
wildcards, but ensures a superset of the required publications are sent to the
WebSphere MQ Integrator broker. The WebSphere MQ Integrator broker evaluates
the “#” and “+” wildcards to match the correct publications.

For example, the topic “employee/+/development” is propagated as

“employee/*/development” to an MQSeries Publish/Subscribe neighbor. This
might cause redundant publications to be sent to the WebSphere MQ Integrator
broker from its MQSeries Publish/Subscribe neighbor. However, none of these
would be sent to the original client when the WebSphere MQ Integrator evaluates
the original subscription. The exception to this is a subscription to the topic “+”
which is never propagated: it cannot be represented as an “*” because this is the
topic that is propagated if a subscription to topic “#” is made at the WebSphere
MQ Integrator broker.

You are recommended not to specify the MQSeries Publish/Subscribe wildcard

characters in MQRFH2 client subscriptions. If you do specify one or more, they are
assumed by WebSphere MQ Integrator to be part of the topic, and are therefore
prefixed by the escape character (%) before the subscription is sent on to an
MQSeries Publish/Subscribe neighbor.

For example, if your MQRFH2 client subscribes with a topic of

“USA/Alaska*/Juneau?”, this is modified and passed to an MQSeries
Publish/Subscribe broker neighbor as “USA/Alaska%*/Juneau%?”.

If an application using MQRFH connects to an WebSphere MQ Integrator broker,

WebSphere MQ Integrator emulates the behavior of the MQSeries

Appendix A. Planning for migration and integration 181

MQSeries Publish/Subscribe
Publish/Subscribe wildcard characters * and ? using a mixture of its own wildcard
characters and filter expressions. Existing MQRFH applications that subscribe to an
WebSphere MQ Integrator broker therefore receive the same publications as they
would receive if they subscribe to an MQSeries Publish/Subscribe broker.

Default topic routing

In WebSphere MQ Integrator, the Topic property of the MQInput node can be used
to route messages that do not contain publish/subscribe parameters. This feature
does not apply to MQRFH subscribers.

MQRFH subscribers expect to receive publications, with a well-formed MQRFH

header, from both MQSeries Publish/Subscribe and WebSphere MQ Integrator
clients. In the latter case, the original MQRFH2 header is converted as described in
Table 7 on page 173. However, if the message does not contain publish/subscribe
information in either an MQRFH or an MQRFH2 header, the default topic is not
used to send publications to an MQRFH subscriber.

Retained publications
In MQSeries Publish/Subscribe, retained publications are published as
nonpersistent messages and are therefore automatically deleted when the broker’s
queue manager is restarted. In WebSphere MQ Integrator, retained publications are
persistent and are preserved across queue manager restarts.

Metatopics
MQSeries Publish/Subscribe brokers provide information about publishers and
subscribers via a special set of topics called metatopics. These topics start with the
“MQ/S/” or “MQ/SA/” prefix, and are subscribed to by two categories of
applications, administration programs and clients.

WebSphere MQ Integrator does not provide equivalent metatopics, and therefore

any existing program (administration or client) that subscribes to MQSeries
Publish/Subscribe metatopics cannot work with an WebSphere MQ Integrator
broker. However, WebSphere MQ Integrator does publish information about
subscription events using its own set of system topics. These are described in the
WebSphere MQ Integrator Administration Guide.

The following considerations apply for the two categories of application in the
WebSphere MQ Integrator environment:
v Administration programs such as the amqspsd sample use the MQSeries
Publish/Subscribe metatopics to display subscription information. This
information is provided by WebSphere MQ Integrator in the Control Center,
which provides an interface to view and delete subscriptions throughout the
broker network.
v Applications use messages published on MQSeries Publish/Subscribe
metatopics, for example, to request information about their own current
subscriptions.
A client program can subscribe to WebSphere MQ Integrator system topics and
process the event publications. WebSphere MQ Integrator does not provide a
topic that reports all current subscriptions for a particular topic or client, but
does publish whenever subscriptions are added or removed. This information is
published as event information not state information (MQSeries
Publish/Subscribe metatopics are published as state information). For more
information about event and state publications, see “State and event
information” on page 90.

182 WebSphere® MQ Integrator: Introduction and Planning

 MQSeries Publish/Subscribe
Subscription points
Subscriptions points are a feature provided by WebSphere MQ Integrator that can
be used to make information associated with a particular topic available in a
number of different formats.

For example, stock prices might be published with a default currency of dollars,
but might be required by subscribers in a number of other currencies.

This can be achieved by defining additional paths through the message flow that
take each publication and convert the dollar stock price into another currency, for
example sterling, before it is passed to its Publication node.

Each additional currency must be associated with a different subscription point

and therefore a Publication node. The original publication in dollars is associated
with the default subscription point.

Subscribers can then subscribe to stock prices using a combination of topic and the
subscription point that provides the data in the correct currency.

Subscription points are not supported by MQSeries Publish/Subscribe. You must

therefore consider their use in a heterogeneous network carefully. In particular,
publications can only pass between WebSphere MQ Integrator and MQSeries
Publish/Subscribe brokers on the default subscription point.

Also, all topics published in an MQSeries Publish/Subscribe broker domain are on

the default subscription point. These topics are only available to MQRFH2
subscribers that subscribe to the topics without specifying a subscription point
(that is, they are using the default subscription point).

Similarly, clients at MQSeries Publish/Subscribe brokers can only subscribe to

topics that are published on the default subscription point at WebSphere MQ
Integrator brokers (at Publication nodes that do not have a subscription point set).

Content-based filtering
WebSphere MQ Integrator supports content-based filtering of publications. This is
a powerful and flexible option for publish/subscribe application suites. This option
significantly enhances the ability of the MQRFH2 subscriber to restrict the
messages they want to receive.

When an MQRFH2 client registers a subscription with the local broker, it can
specify a filter to be applied to the content of fields within each publication
message.

An MQRFH2 subscriber can subscribe to MQRFH publications within the

MQSeries Publish/Subscribe part of a mixed broker network based upon the
restrictions mentioned in this chapter. All MQRFH publications are converted to
MQRFH2 format by the broker before delivery to the MQRFH2 client (see Table 7
on page 173 for conversion details).

An MQRFH2 subscriber can also request some very restricted content-based

filtering to be performed on the MQRFH publications they are subscribing to. This
can only be done if the body of the publication is in a format that can be parsed by
the broker: that is, it can be interpreted by one of the broker’s default parsers
(described in “Message parsers” on page 74). For example, messages in XML or
MQPCF format can be processed in this way.

Appendix A. Planning for migration and integration 183

MQSeries Publish/Subscribe
If you want to make full use of content-based filtering, you must convert
publications into MQRFH2 format. This enables all messages defined in the
message repository to be interpreted by the brokers parsers. MQRFH clients cannot
specify a content filter.

For more details about message formats, their construction, and the message
repository, see WebSphere MQ Integrator Programming Guide and WebSphere MQ
Integrator Working with Messages.

Throughput
In MQSeries Publish/Subscribe a single thread processes publications on each of
the stream queues. This guaranteed the order in which publications were processed
from the queue. When you consider throughput for publications in an WebSphere
MQ Integrator broker domain, you must also consider the importance of the order
in which messages are published. The techniques to increase throughput do not
necessarily guarantee order.

WebSphere MQ Integrator supports two options that increase throughput:

1. You can configure the message flow with additional threads by setting the
Additional Instances property of the MQInput node. This property instructs the
broker to schedule additional threads to read messages from the input queue,
thus allowing publications from that queue to be processed concurrently by the
broker. You must also ensure that the stream (input) queue has the share
attribute set (MQSeries Publish/Subscribe required stream queues to have
noshare set).
If multiple threads process messages from a single queue, publications are not
guaranteed to be delivered to subscribers in the order in which they are placed
on the input queue. Therefore WebSphere MQ Integrator provides a simple
ordering facility that can be used to allow concurrent processing of publications
whilst still maintaining some sequence:
You can set the Order Mode property of the MQInput node to the value By User
ID. This ensures the order of delivery of publications sent to the broker by a
given user. When this property is set, the processing of messages that carry a
given UserIdentifier field in the MQMD is held up if any other thread servicing
that message flow is currently processing a message that carries the same
UserIdentifier.
The benefits of running additional instances of the message flow are negated if
all publishing applications are running under the same user ID. This might be
the case for publishing applications connected to a queue manager remote to
the broker’s queue manager. Messages from these remote publishers arrive at
the broker via a channel that might have been set up to insert the channel
program’s user ID instead of the originating client’s user ID. Refer to the
MQSeries Intercommunications book for more information on how to set the
PUTAUT channel attribute to change the default channel behavior.
2. You can configure one or more additional message flows (not instances) that
read publications from different queues. You must also update some of your
publishing applications to publish to the new queue (or queues). This has the
effect of splitting the stream, and therefore spreading the workload.
If you choose to increase throughput using this method, you must consider the
impact this has on the order in which publications are delivered. In particular
you must ensure that the publisher applications are split with respect to the
topics they are publishing on to ensure that order can be maintained per topic,
if this is important. If your applications publish to different queues (message
flows) on the same topic order cannot be guaranteed.

184 WebSphere® MQ Integrator: Introduction and Planning

 MQSeries Publish/Subscribe
If you update the publisher applications to send publications to a new queue
which has a different name to the stream on which they are publishing, you
must also update these applications to explicitly include the stream name
within their publications using the MQPSStreamName parameter.
Publishing applications that specify a stream parameter do not need to be
modified, as this parameter takes precedence. However, if publishing
applications do not specify the stream parameter, the behavior is determined by
the setting of the Implicit Stream Naming property of the publication node in the
message flow:
v If the property is set to false, the default stream is assumed.
v If the property is set to true, the stream name is assumed to be the same as
the name of the stream input queue.

Scenario 1: running two independent broker networks

If you already have an MQSeries Publish/Subscribe broker network, you can
continue to use this network unchanged. The introduction of WebSphere MQ
Integrator Version 2.1 to your environment, and the creation of brokers in that
broker domain, does not affect your MQSeries Publish/Subscribe broker domain
until you take specific action to connect the two networks.

If you want to run in this mode with two separate, independent networks, you do
not have to take any specific actions. You can retain your existing MQSeries
Publish/Subscribe network, and install and configure an WebSphere MQ Integrator
Version 2.1 network, without any interaction.

Your existing applications can continue to work unchanged. However, there can be
no interchange of publications in this scenario.

You must be aware that a single queue manager cannot support both an MQSeries
Publish/Subscribe broker and an WebSphere MQ Integrator Version 2.1 broker. If
you have brokers of both types on the same system, each broker must have its
own dedicated queue manager.

You can implement this scenario while you assess the new product and the extra
functions contained within the publish/subscribe support. It also lets you plan for
the extent of integration or migration, or both, that you require, without affecting
your current environment.

Scenario 2: creating and operating a heterogeneous network

When you have operated two separate networks for a while, and understand the
benefits that WebSphere MQ Integrator Version 2.1 provides, you can take the next
step of setting up an integrated network with a mix of MQSeries
Publish/Subscribe and WebSphere MQ Integrator brokers.

A heterogeneous network enables publications and subscriptions to be propagated

through one logical network, made up of two physical networks.

Applications registered with all brokers (WebSphere MQ Integrator Version 2.1 and
MQSeries Publish/Subscribe) are not aware that there is a heterogeneous network,
and, subject to authorizations being in place and the product differences addressed,
can publish and subscribe freely.

One of the advantages of creating and operating a heterogeneous network is that it

allows you to integrate MQSeries Publish/Subscribe brokers running on operating

Appendix A. Planning for migration and integration 185

MQSeries Publish/Subscribe
systems where you currently do not have WebSphere MQ Integrator Version 2.1
installed. You can integrate them with new WebSphere MQ Integrator Version 2.1
brokers, or with those migrated from MQSeries Publish/Subscribe brokers on the
same operating system, or both.

You also create and operate a heterogeneous network while you implement
migration, because you are not required to migrate your whole MQSeries
Publish/Subscribe broker network in one step. See “Scenario 3: migrating
MQSeries Publish/Subscribe brokers” for details about migrating individual
brokers.

To achieve a heterogeneous network, you must:

v Select the brokers that are to join the two networks together.
The hierarchical structure of the MQSeries Publish/Subscribe network, with a
single root broker (node) and a number of leaf nodes, allows you to integrate the
two networks in two ways:
– You can add a single WebSphere MQ Integrator Version 2.1 broker to the
MQSeries Publish/Subscribe network as a root node. The MQSeries
Publish/Subscribe hierarchy results in the heaviest workload at the root node.
If you add an WebSphere MQ Integrator Version 2.1 broker as a new root, all
MQSeries Publish/Subscribe message traffic is processed by this node.
– You can add one or more WebSphere MQ Integrator Version 2.1 brokers to the
MQSeries Publish/Subscribe network as leaf nodes. This option minimizes
the additional workload placed on the WebSphere MQ Integrator Version 2.1
broker.
v Establish message flows that provide the publish/subscribe services required in
the WebSphere MQ Integrator broker.
The choices you have for implementing these message flows have already been
discussed in “Throughput” on page 184.

Details of how you implement these actions are described in the WebSphere MQ
Integrator Administration Guide.

Scenario 3: migrating MQSeries Publish/Subscribe brokers

This third scenario describes the planning you must do when you decide to
migrate your MQSeries Publish/Subscribe brokers. This is likely to be the final
stage of your adoption of WebSphere MQ Integrator into your current MQSeries
Publish/Subscribe environment.

The action of migrating an MQSeries Publish/Subscribe broker to an WebSphere

MQ Integrator broker replaces the broker. This is a final step, from which it is
difficult to return.

You must therefore ensure you have considered the move carefully, and have taken
any actions or decisions necessary to ensure a smooth transition.

You might need to consider the following:

v The order in which you migrate the brokers
You do not have to migrate all the brokers in the network immediately. You can
migrate brokers one at a time, thus creating an intermediate state in which the
network consists of a mixture of MQSeries Publish/Subscribe and WebSphere
MQ Integrator brokers.

186 WebSphere® MQ Integrator: Introduction and Planning

 MQSeries Publish/Subscribe
In fact, a mixed network of this nature might be the final state of the network,
because you cannot migrate brokers that have been created on an operating
system that is not supported by WebSphere MQ Integrator.
If you have a choice of which brokers to migrate first, migrate leaf nodes first.
These brokers have a single relation in the network (a parent) and their
migration is therefore easier to plan and implement.
v The place of each broker in the network
Each broker you migrate has at least one neighbor, its parent. Quiesce the client
applications on all related brokers, and stop the brokers, in addition to the one
you are migrating.
v The use of collectives in the WebSphere MQ Integrator network
A collective removes a single point of failure, and therefore increases the
resilience of every individual node in the publish/subscribe network.

Table 10 on page 188 identifies the areas of potential incompatibility due to the
upgraded behavior of WebSphere MQ Integrator. It provides some hints as to
when, and how, you might need to make changes to your client applications, or
the topics they use.

If you do make changes, you must test your changes for correctness by running
the changed items in your MQSeries Publish/Subscribe network for a reasonable
period of time before migrating to WebSphere MQ Integrator.

Migration checklist
When you have identified the MQSeries Publish/Subscribe broker or brokers that
you want to migrate to WebSphere MQ Integrator, you must work through the
items presented in Table 10 on page 188 to ensure that the migration has no effect
on your client applications.

You need an in-depth knowledge of both the broker, and the client applications
that are using it, to determine exactly which items affect your environment.

The MQSeries Publish/Subscribe sample administration program, amqspsd, which

reports on the state of an MQSeries Publish/Subscribe broker, helps you to identify
some of the problem areas listed here. Refer to the MQSeries Publish/Subscribe User’s
Guide for full details of the operation of this program.

Appendix A. Planning for migration and integration 187

MQSeries Publish/Subscribe
Table 10. Migration inhibitors checklist
Item Suggested discovery Suggested resolution Chkd
Topics
No topics contain the # or Check full output from Redesign topics1
the + character amqspsd.
No applications are Check full output from No equivalent product
subscribing to metatopics amqspsd for subscription to functions2
topics starting with either
“MQ/S/” or “MQ/SA/”
Streams
No user-defined topics have Check topics returned in the Move subscriptions and
been added to the output from amqspsd publications to existing or
administration stream filtered by administration new stream3
stream
Common streams shared No new common streams are After migration, remove the
between broker and its needed in the future broker from the MQSeries
relations do not need to Publish/Subscribe network
change4 and add it again
Capacity
Is the broker running near to Any reported instances of After migration, create
full capacity messages building up on the additional message flow
control queue or any of the instances to spread the
stream queues workload5
Message formats
No publishing applications Check publishing Change applications to use
are using MQPCF messages6 applications MQRFH format
User exit
No routing exit is being used Check for the presence of the No equivalent product
routingexit configuration functions7
parameter
Notes:
1. If the topics being used by your publisher and subscriber applications need to be redesigned, this
might involve more than simply changing the affected client applications. Subscriptions and
retained publications that reference the invalid topics need to be removed. Also brokers need to be
stopped so that all processing on the affected topics is suitably quiesced in the entire broker
network, befor deploying the modified publisher and subscriber applications.
2. This issue is discussed in “Metatopics” on page 182. MQSeries Publish/Subscribe and WebSphere
MQ Integrator do not provide fully compatible function for metatopics.
3. If the administration stream (stream queue SYSTEM.BROKER.ADMIN.STREAM) has been used for
convenience by client applications, these topics need to be moved to another stream supported by
all brokers in the network. No subscriptions or retained publications are migrated on this stream.
4. If the broker is part of a multibroker network, WebSphere MQ Integrator brokers do not respond
to stream support changes at neighboring MQSeries Publish/Subscribe brokers. If you require the
replacement broker to support other streams, the WebSphere MQ Integrator broker must be
removed from the MQSeries Publish/Subscribe network, and added again.
5. MQSeries Publish/Subscribe and WebSphere MQ Integrator have different operational
characteristics that make it difficult to compare their performance directly. In particular, WebSphere
MQ Integrator stores its persistent data within a database. Model your broker’s current workload
with an WebSphere MQ Integrator broker before you start migration. WebSphere MQ Integrator
throughput can be increased in two ways: see “Throughput” on page 184 for details.
6. WebSphere MQ Integrator brokers only accept publications made in MQRFH or MQRFH2 format.
The migmqbrk command does not export MQPCF retained publications to the replacement
WebSphere MQ Integrator broker.
7. If only a small majority of publications need to be processed by the user exit, an additional
MQSeries Publish/Subscribe broker could be created to host affected subscribers before migration.
The subscribing applications themselves do not need to be moved to the new broker, but their
subscriptions do need to be rerouted. The user exit code can then run at the new broker which
would not be migrated.

188 WebSphere® MQ Integrator: Introduction and Planning

Appendix B. The product packages
The following sections provide a summary of the contents of the packages for
WebSphere MQ Integrator for AIX, WebSphere MQ Integrator for HP-UX,
WebSphere MQ Integrator for Sun Solaris, and WebSphere MQ Integrator for
Windows NT and Windows 2000. For exact details, you must refer to the product
Readme.txt file, and to the MQSeries MQ Integrator Installation Guide for your
product.

WebSphere MQ Integrator provides a separately orderable CD-ROM that contains

English and national language versions of the product books in PDF format. The
order number of this CD-ROM is SK3T 6922.

© Copyright IBM Corp. 2000, 2002 189

Product package for AIX

The WebSphere MQ Integrator for AIX package

The WebSphere MQ Integrator for AIX package includes the following CD-ROMs:
1. WebSphere MQ Integrator for AIX V2.1
This primary-product CD-ROM provides the product in all available national
languages. It also includes the installable documentation package, the New Era
of Networks Rules and Formatter Support, and the Tivoli interface support
files and documentation. For more information, see the Readme.txt.
2. WebSphere MQ Integrator for Windows NT and Windows 2000 V2.1
3. WebSphere MQ Integrator for AIX V2.1 ’Supplement’, which includes:
v The WebSphere MQ Integrator Version 2.1 documentation PDF package that
can be viewed without installation. You are recommended to install the PDF
package from the primary product CD, but you might choose to refer to the
product library before installation.
v Some additional product service updates that might be required. These are
provided to avoid unnecessary web downloads. However, you should refer
to the readme.txt file on the primary product CD for a full list of the service
levels required.
4. WebSphere MQ Integrator for AIX V2.1 ’DB2 for AIX 7.1’
This is supplied for specific use with WebSphere MQ Integrator. If you do not
already have a suitable database to use, you must install this product before
you install WebSphere MQ Integrator.
5. Either WebSphere MQ Integrator for Windows NT and Windows 2000 V2.1
’DB2 for Windows 7.1’ (English and EMEA (Europe, Middle East and Africa)
Languages) or WebSphere MQ Integrator for Windows NT and Windows 2000
V2.1 ’DB2 for Windows 7.1’ (English and AP (Asia Pacific) Languages)
This is supplied for specific use with WebSphere MQ Integrator and should not
be used to support other non-WebSphere MQ Integrator applications.
6. MQSeries for AIX V5.2 (Server)
The WebSphere MQ Integrator installation program checks that you have the
appropriate components of MQSeries installed on your system. The Runtime
component requires the MQSeries for AIX server at V5.2 or later. Other
components have no MQSeries dependency.
If any MQSeries component is required for WebSphere MQ Integrator
installation, and you do not have the correct level already installed, you must
install this CD. If you already have Version 5.0 or Version 5.1, you can use
these CDs to migrate to Version 5.2.
7. MQSeries for Windows NT V5.2 (Server)
The installation program checks that you have the appropriate components of
MQSeries installed on your system. Some WebSphere MQ Integrator
components require MQSeries for Windows NT Server at V5.2 or later.
If any MQSeries component is required for WebSphere MQ Integrator
installation, and you do not have the correct level already installed, you must
install this CD. If you already have Version 5.0 or Version 5.1, you can use
these CDs to migrate to Version 5.2.
8. MQSeries V5.2 Clients
MQSeries Clients for all platforms in all available national languages are
included on this CD.

190 WebSphere® MQ Integrator: Introduction and Planning

 Product package for HP-UX

The WebSphere MQ Integrator for HP-UX package

The WebSphere MQ Integrator for HP-UX package includes the following
CD-ROMs:
1. WebSphere MQ Integrator for HP-UX V2.1.
This primary-product CD-ROM provides the product in all available national
languages. It also includes the installable documentation package and the New
Era of Networks Rules and Formatter Support. For more information, see the
Readme.txt.
2. WebSphere MQ Integrator for Windows NT and Windows 2000 V2.1.
3. WebSphere MQ Integrator for HP-UX V2.1 ’Supplement’, which includes:
v The WebSphere MQ Integrator Version 2.1 documentation PDF package that
can be viewed without installation. You are recommended to install the PDF
package from the primary product CD, but you might choose to refer to the
product library before installation.
v Some additional product service updates that might be required. These are
provided to avoid unnecessary web downloads. However, you should refer
to the readme.txt file on the primary product CD for a full list of the service
levels required.
4. WebSphere MQ Integrator for HP-UX V2.1 ’DB2 for HP-UX 7.1’
This is supplied for specific use with WebSphere MQ Integrator. If you do not
already have a suitable database to use, you must install DB2 from this CD
(before or after WebSphere MQ Integrator installation).
5. WebSphere MQ Integrator for Windows NT and Windows 2000 V2.1 ’DB2 for
Windows 7.1’
This is supplied for specific use with WebSphere MQ Integrator and should not
be used to support non-WebSphere MQ Integrator applications.
6. MQSeries for HP-UX V5.2 (HP 11 Server)
The WebSphere MQ Integrator installation program checks that you have the
appropriate components of MQSeries installed on your system. The runtime
component requires the MQSeries for HP-UX V5.2 server. Other components
have no MQSeries dependency.
If any MQSeries component is required for WebSphere MQ Integrator
installation, and you do not have the correct level already installed, you must
install this CD.
7. MQSeries for Windows NT V5.2 (Server)
The installation program checks that you have the appropriate components of
MQSeries installed on your system. Some WebSphere MQ Integrator
components require MQSeries for Windows NT Server at V5.2 or later.
If any MQSeries component is required for WebSphere MQ Integrator
installation, and you do not have the correct level already installed, you must
install this CD. If you already have Version 5.0 or Version 5.1, you can use
these CDs to migrate to Version 5.2.
8. MQSeries V5.2 Clients
MQSeries Clients for all platforms in all available national languages are
included on this CD.

Appendix B. The product packages 191

Product package for Solaris

The WebSphere MQ Integrator for Sun Solaris package

The WebSphere MQ Integrator for Sun Solaris package includes the following
CD-ROMs:
1. WebSphere MQ Integrator for Sun Solaris V2.1.
This primary product CD-ROM provides the product in all available national
languages. It also includes the installable documentation package, the New Era
of Networks Rules and Formatter Support, and the Tivoli interface support
files and documentation. For more information, see the Readme.txt.
2. WebSphere MQ Integrator for Windows NT and Windows 2000 V2.1.
3. WebSphere MQ Integrator for Sun Solaris V2.1. ’Supplement’, which includes:
v The WebSphere MQ Integrator Version 2.1 documentation PDF package that
can be viewed without installation. You are recommended to install the PDF
package from the primary product CD, but you might choose to refer to the
product library before installation.
v Some additional product service updates that might be required. These are
provided to avoid unnecessary web downloads. However, you should refer
to the readme.txt file on the primary product CD for a full list of the service
levels required.
4. WebSphere MQ Integrator for Sun Solaris V2.1 ’DB2 for Solaris 7.1’
This is supplied for specific use with WebSphere MQ Integrator. If you do not
already have a suitable database to use, you must install DB2 from this CD
(before or after WebSphere MQ Integrator installation).
5. WebSphere MQ Integrator for Windows NT and Windows 2000 V2.1 ’DB2 for
Windows 7.1’
This is supplied for specific use with WebSphere MQ Integrator and should not
be used to support non-WebSphere MQ Integrator applications.
6. MQSeries for Solaris V5.2 (Server)
The WebSphere MQ Integrator installation program checks that you have the
appropriate components of MQSeries installed on your system. The runtime
component requires the MQSeries for Solaris server at V5.2 or later. Other
components have no MQSeries dependency.
If any MQSeries component is required for WebSphere MQ Integrator
installation, and you do not have the correct level already installed, you must
install this CD. If you already have Version 5.0 or Version 5.1, you can use
these CDs to upgrade to Version 5.2.
7. MQSeries for Windows NT V5.2 (Server)
The installation program checks that you have the appropriate components of
MQSeries installed on your system. Some WebSphere MQ Integrator
components require MQSeries for Windows NT Server at V5.2 or later, the
Control Center and the Configuration Manager require the MQSeries Client for
Java. Some components have no MQSeries dependency.
If any MQSeries component is required for WebSphere MQ Integrator
installation, and you do not have the correct level already installed, you must
install this CD. If you already have Version 5.0 or Version 5.1, you can use
these CDs to upgrade to Version 5.2.
8. MQSeries V5.2 Clients
MQSeries Clients for all platforms in all available national languages are
included on this CD.

192 WebSphere® MQ Integrator: Introduction and Planning

 Product package for Windows NT

The WebSphere MQ Integrator for Windows NT and Windows 2000

package
The WebSphere MQ Integrator for Windows NT and Windows 2000 package
includes the following CD-ROMs:
1. WebSphere MQ Integrator for Windows NT and Windows 2000 V2.1
This primary-product CD-ROM provides the product in English. It also
includes the installable documentation package and the New Era of Networks
Rules and Formatter Support, and the Tivoli interface support files and
documentation. For more information, see the Readme.txt.
Service Pack 2 must be applied for Windows 2000.
2. WebSphere MQ Integrator for Windows NT and Windows 2000 V2.1 ’DB2 for
Windows 7.1’
This is supplied for specific use with WebSphere MQ Integrator. If you do not
have a suitable version of DB2 installed, the WebSphere MQ Integrator Version
2.1 install process will offer to install DB2 for you.
3. WebSphere MQ Integrator for Windows NT and Windows 2000 V2.1
’Supplement’, which includes:
v The WebSphere MQ Integrator Version 2.1 documentation PDF package that
can be viewed without installation. You are recommended to install the PDF
package from the primary product CD, but you might choose to refer to the
product library before installation.
v Any additional product service updates required for any product supplied in
this package are included on this CD. Up-to-date details of the service levels
required are included in the WebSphere MQ Integrator Version 2.1
Readme.txt file on the primary product CD.
4. MQSeries for Windows NT V5.2 (Server)
The WebSphere MQ Integrator installation program checks that you have the
appropriate components of MQSeries installed on your system. Some
WebSphere MQ Integrator components require MQSeries for Windows NT
server at V5.2 or later. Version 5.2 is supplied primarily for those customers
who do not have an existing MQSeries installation. However, you can also use
this CD to upgrade an existing MQSeries Version 5.1 installation to Version 5.2.
If you do this upgrade, refer to the migration instructions supplied with
MQSeries Version 5.2.
5. MQSeries V5.2 Clients
MQSeries Clients for all platforms are included on this CD, in English.

Appendix B. The product packages 193

Product package for z/OS

TheWebSphere MQ Integrator for z/OS package

The WebSphere MQ Integrator for z/OS package includes the following:
1. WebSphere MQ Integrator for z/OS Version 2.1.
These primary-product tapes provide the product in all available national
languages.
2. WebSphere MQ Integrator for New Era of Networks feature.
This primary-product tape provides the product in all available national
languages.
3. WebSphere MQ Integrator for Windows NT and Windows 2000 V2.1.
4. WebSphere MQ Integrator for Windows NT and Windows 2000 V2.1 ’DB2 for
Windows 7.1’
This is supplied for specific use with WebSphere MQ Integrator. If you do not
have a suitable version of DB2 installed, the WebSphere MQ Integrator Version
2.1 install process will offer to install DB2 for you.
5. WebSphere MQ Integrator for Windows NT and Windows 2000 V2.1
’Supplement’, which includes:
v The WebSphere MQ Integrator Version 2.1 documentation PDF package that
can be viewed without installation. You are recommended to install the PDF
package from the primary product CD, but you might choose to refer to the
product library before installation.
v Any additional product service updates required for any product supplied in
this package are included on this CD. Up-to-date details of the service levels
required are included in the WebSphere MQ Integrator Version 2.1
Readme.txt file on the primary product CD.
6. MQSeries for Windows NT V5.2.1 (Server)
The WebSphere MQ Integrator installation program checks that you have the
appropriate components of MQSeries installed on your system. Version 5.2 is
supplied primarily for those customers who do not have an existing MQSeries
installation. However, you can also use this CD to upgrade an existing
MQSeries Version 5.1 installation to Version 5.2. If you do this upgrade, refer to
the migration instructions supplied with MQSeries Version 5.2.
7. MQSeries V5.2 Clients
MQSeries Clients for all platforms in all available national languages are
included on this CD.

The following hardcopy installation books are supplied:

v WebSphere MQ Integrator for z/OS Program Directory
v WebSphere MQ Integrator for Windows NT and Windows 2000 Installation Guide
v WebSphere MQ for Windows NT and Windows 2000 Quick Beginnings

194 WebSphere® MQ Integrator: Introduction and Planning

Appendix C. Notices
This information was developed for products and services offered in the United
States. IBM may not offer the products, services, or features discussed in this
information in other countries. Consult your local IBM representative for
information on the products and services currently available in your area. Any
reference to an IBM product, program, or service is not intended to state or imply
that only that IBM product, program, or service may be used. Any functionally
equivalent product, program, or service that does not infringe any IBM intellectual
property right may be used instead. However, it is the user’s responsibility to
evaluate and verify the operation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matter
described in this information. The furnishing of this information does not give you
any license to these patents. You can send license inquiries, in writing, to:
IBM Director of Licensing
IBM Corporation
North Castle Drive
Armonk, NY 10504-1785
U.S.A.

For license inquiries regarding double-byte (DBCS) information, contact the IBM
Intellectual Property Department in your country or send inquiries, in writing, to:
IBM World Trade Asia Corporation
Licensing
2-31 Roppongi 3-chome, Minato-ku
Tokyo 106, Japan

The following paragraph does not apply to the United Kingdom or any other
country where such provisions are inconsistent with local law:
INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS
PUBLICATION “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY, OR FITNESS
FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or
implied warranties in certain transactions, therefore this statement may not apply
to you.

This information could include technical inaccuracies or typographical errors.

Changes are periodically made to the information herein; these changes will be
incorporated in new editions of the information. IBM may make improvements
and/or changes in the product(s) and/or the program(s) described in this
information at any time without notice.

Any references in this information to non-IBM Web sites are provided for
convenience only and do not in any manner serve as an endorsement of those Web
sites. The materials at those Web sites are not part of the materials for this IBM
product and use of those Web sites is at your own risk.

IBM may use or distribute any of the information you supply in any way it
believes appropriate without incurring any obligation to you.

© Copyright IBM Corp. 2000, 2002 195

Notices
Licensees of this program who wish to have information about it for the purpose
of enabling: (i) the exchange of information between independently created
programs and other programs (including this one) and (ii) the mutual use of the
information which has been exchanged, should contact:
IBM United Kingdom Laboratories,
Mail Point 151,
Hursley Park,
Winchester,
Hampshire,
England
SO21 2JN.

Such information may be available, subject to appropriate terms and conditions,

including in some cases, payment of a fee.

The licensed program described in this information and all licensed material
available for it are provided by IBM under terms of the IBM Customer Agreement,
IBM International Programming License Agreement, or any equivalent agreement
between us.

Information concerning non-IBM products was obtained from the suppliers of

those products, their published announcements or other publicly available sources.
IBM has not tested those products and cannot confirm the accuracy of
performance, compatibility or any other claims related to non-IBM products.
Questions on the capabilities of non-IBM products should be addressed to the
suppliers of those products.

196 WebSphere® MQ Integrator: Introduction and Planning

 Notices
This product includes software developed by the Apache Software Foundation
(http://www.apache.org/).

The following permission statements and conditions only apply to the XML library
files built using software from Apache Software Foundation, and not to any code
developed solely by IBM Corporation. They do not invalidate any of the terms of
the IBM International Program License Agreement for this IBM product.

Copyright © 1999-2000 The Apache Software Foundation. All rights reserved.

Redistribution and use in source and binary forms, with or without modification,
are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list
of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this
list of conditions and the following disclaimer in the documentation and/or
other materials provided with the distribution.
3. The end-user documentation included with the redistribution, if any, must
include the following acknowledgment: “This product includes software
developed by the Apache Software Foundation (http://www.apache.org/).”
Alternately, this acknowledgment may appear in the software itself, if and
wherever such third-party acknowledgments normally appear.
4. The names “Xerces” and “Apache Software Foundation” must not be used to
endorse or promote products derived from this software without prior written
permission. For written permission, please contact apache\@apache.org.
5. Products derived from this software may not be called “Apache”, nor may
“Apache” appear in their name, without prior written permission of the
Apache Software Foundation.

THIS SOFTWARE IS PROVIDED “AS IS” AND ANY EXPRESSED OR IMPLIED

WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE
FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE.

Appendix C. Notices 197

Notices

Trademarks
The following terms are trademarks of International Business Machines
Corporation in the United States, other countries, or both:

AIX AS/400 CICS

DB2 DB2 Universal Database IBM
IBMLink IMS/ESA iSeries
MQSeries POWERparallel POWERserver
pSeries RS/6000 SupportPac
System/390 TXSeries WebSphere
xSeries 400 Eserver

Lotus, Notes, and Domino are trademarks of Lotus Development Corporation in

the United States, other countries, or both.

Tivoli is a trademark of Tivoli Systems Inc. in the United States, other countries, or
both.

Pentium is a trademark of Intel Corporation in the United States, other countries,

or both.

Java, JDBC, and JDK are registered trademarks of Sun Microsystems, Inc. in the
United States, other countries, or both.

Microsoft, Windows, and Windows NT are trademarks of Microsoft Corporation in

the United States, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and other
countries.

Other company, product, and service names might be trademarks or service marks
of others.

198 WebSphere® MQ Integrator: Introduction and Planning

Glossary of terms and abbreviations
This glossary defines WebSphere MQ Integrator check in. The Control Center action that stores a new
terms and abbreviations used in this book. If you or updated resource in the configuration or message
do not find the term you are looking for, see the repository.
index or the IBM Dictionary of Computing, New
check out. The Control Center action that extracts and
York: McGraw-Hill, 1994. locks a resource from the configuration or message
repository for local modification by a user. Resources
This glossary includes terms and definitions from from the two repositories can only be worked on when
the American National Dictionary for Information they are checked out by an authorized user, but can be
Systems, ANSI X3.172-1990, copyright 1990 by the viewed (read only) without being checked out.
American National Standards Institute. Copies
may be ordered from the American National collective. A hyperconnected (totally connected) set of
brokers forming part of a multi-broker network for
Standards Institute, 11 West 42 Street, New York,
publish/subscribe applications.
New York 10036. Definitions are identified by the
symbol (A) after the definition. configuration. In the broker domain, the brokers,
execution groups, message flows and message sets
A assigned to them, topics and access control
specifications.
Access Control List (ACL). The list of principals that
Configuration Manager. A component of WebSphere
have explicit permissions (to publish, to subscribe to,
MQ Integrator that acts as the interface between the
and to request persistent delivery of a publication
configuration repository and an executing set of
message) against a topic in the topic tree. The ACLs
brokers. It provides brokers with their initial
define the implementation of topic-based security.
configuration, and updates them with any subsequent
ACL. Access Control List. changes. It maintains the broker domain configuration.

AMI. Application Messaging Interface. configuration repository. Persistent storage for broker
configuration and topology definition.
Application Messaging Interface (AMI). The
programming interface provided by MQSeries that connector. See message processing node connector.
defines a high level interface to message queuing
content-based filter. An expression that is applied to
services. See also MQI and JMS.
the content of a message to determine how the message
is to be processed.
B
context tag. See element qualifier.
BLOB. Binary Large OBject. A block of bytes of data
Control Center. The graphical interface that provides
(for example, the body of a message) that has no
facilities for defining, configuring, deploying, and
discernible meaning, but is treated as one solid entity
monitoring resources of the WebSphere MQ Integrator
that cannot be interpreted.
network.
broker. See message broker.

broker domain. A collection of brokers that share a

D
common configuration, together with the single
datagram. The simplest form of message that
Configuration Manager that controls them.
MQSeries supports. Also known as send-and-forget. This
type of message does not require a reply. Compare with
C request/reply.

callback function. See implementation function. debugger. A facility on the Message Flows view in the
Control Center that enables message flows to be
category. An optional grouping of messages that are debugged.
related in some way. For example, messages that relate
to a particular application. deploy. Make operational the configuration and
topology of the broker domain.

© Copyright IBM Corp. 2000, 2002 199

Glossary
destination list. See local environment. length of a string element might be defined in one
message set but used in several message sets.
distribution list. A list of MQSeries queues to which a
message can be put using a single statement. External Security Manager. A program that provides
security management for users and resources on z/OS.
Document Type Definition (DTD). The rules that
specify the structure for a particular class of SGML or
XML documents. The DTD defines the structure with F
elements, attributes, and notations, and it establishes
constraints for how each element, attribute, and field reference. A sequence of period-separated values
notation can be used within the particular class of that identify a specific field (which might be a
documents. A DTD is analogous to a database schema structure) within a message tree. An example of a field
in that the DTD completely describes the structure for a reference might be something like
particular markup language. Body.Invoice.InvoiceNo.

DTD. Document Type Definition. filter. An expression that is applied to the content of a
message to determine how the message is to be
processed.
E
format. A format defines the internal structure of a
e-business. A term describing the commercial use of message, in terms of the fields and order of those
the Internet and World Wide Web to conduct business fields. A format can be self-defining, in which case the
(short for electronic-business). message is interpreted dynamically when read.

element. A unit of data within a message that has

business meaning, for example, street name G
element qualifier. A tag that is applied to an element graphical user interface (GUI). An interface to a
within a message to enable that element to be treated software product that is graphical rather than textual. It
differently in different contexts. For example, an refers to window-based operational characteristics.
element could be mandatory in one context and
optional in another.
I
environment. User-defined variable information
associated with a message while it is being processed IBM Developer Kit. IBM Developer Kit for the Java
by a message flow. This information can be created and Platform, a software package that can be used to write,
used by nodes within the message flow. compile, debug, and run Java applets and applications.

ESM. External Security Manager. IBM Runtime Environment. IBM Runtime

Environment for the Java Platform. A subset of the IBM
ESQL. Extended SQL. Developer Kit for the Java Platform, that contains the
core executables and files that constitute the standard
exception list. A list of exceptions that have been Java platform. The IBM Runtime Environment includes
generated during the processing of a message, with the Java Virtual Machine, core classes and supporting
supporting information. files.

execution group. A named grouping of message flows implementation function. Function written by a
that have been assigned to a broker. The broker is third-party developer for a plug-in node or parser. Also
guaranteed to enforce some degree of isolation between known as a callback function.
message flows in distinct execution groups by ensuring
that they execute in separate address spaces, or as input node. A message flow node that represents a
unique processes. source of messages for the message flow.

Extended SQL. A specialized set of SQL functions and installation mode. The installation mode can be Full,
statements based on regular SQL, extended with Custom, or Broker only. The mode defines the
functions and statements unique to WebSphere MQ components of the product installed by the installation
Integrator. process on Windows NT systems.

Extensible Markup Language (XML). A W3C

standard for the representation of data.

external reference. A reference within a message set to

a component that has been defined outside the current
message set. For example, an integer that defines the

200 WebSphere® MQ Integrator: Introduction and Planning

 Glossary

J message dictionary. A repository for (predefined)

message type specifications.
Java Database Connectivity (JDBC). An application message domain. The value that determines how the
programming interface that has the same characteristics message is interpreted (parsed). The following domains
as ODBC but is specifically designed for use by Java are recognized:
database applications. v MRM, which identifies messages defined using the
Control Center.
Java Message Service (JMS). An application
v NEONMSG and NEON, which identify messages
programming interface that provides Java language
created using the New Era of Networks user
functions for handling messages.
interfaces.
JDBC. Java Database Connectivity. v XML, JMSMap, and JMSStream, which identify
messages that are self-defining.
JMS. Java Message Service. See also AMI and MQI. v BLOB, which identifies messages that are undefined.
You can also create your own message domains: if you
L do so, you must supply your own message parser.

local environment. Information associated with a message flow. A directed graph that represents the set
message while it is being processed by a message flow. of activities performed on a message or event as it
This information includes: passes through a broker. A message flow consists of a
v User-defined variable information that can be created set of message processing nodes and message
and used by nodes within the message flow. processing node connectors.
v A user-defined list of internal and external
message flow component. See message flow.
destinations to which a message is sent. These can be
nodes within a message flow (for example, when message parser. A program that interprets the bit
using the RouteToLabel and Label nodes) or stream of an incoming message and creates an internal
MQSeries queues (when the list is examined by an representation of the message in a tree structure, and
MQOutput node to determine the final target for the that regenerates a bit stream for an outgoing message
message). from the internal representation.
v A list of destinations to which a message has been
sent. This list is created by an output node only if it message processing node. A node in the message
is connected to another node in the message flow. flow, representing a well defined processing stage. A
message processing node can be one of several
Also known as destination list in previous MQSeries primitive types or can represent a subflow.
Integrator releases. Destination list is valid and can be
used for compatibility. message processing node connector. An entity that
connects the output terminal of one message processing
local error log. A generic term that refers to the logs node to the input terminal of another. A message
to which WebSphere MQ Integrator writes records on processing node connector represents the flow of
the local system. control and data between two message flow nodes.
v On UNIX systems, this is the syslog.
v On Windows NT, this is the Event Viewer message queue interface (MQI). The programming
(Application View). interface provided by MQSeries queue managers. The
v On z/OS systems, this is the operator console. programming interface allows application programs to
access message queuing services. See also AMI and
Entries written to this log include records that provide JMS.
information about events that are not errors, but that
occur normally during operation, for example, message repository. A database holding message
successful deployment of a configuration. template definitions.

Also known as system log. message repository manager (MRM). A component of

the Configuration Manager that handles message
definition and control. A message defined to the MRM
M has a message domain set to MRM.

message broker. A set of execution processes hosting message set. A grouping of related messages.
one or more message flows.
message template. A named and managed entity that
messages. Entities exchanged between a broker and its represents the format of a particular message. Message
clients. templates represent a business asset of an organization.

Glossary of terms and abbreviations 201

Glossary
message type. The logical structure of the data within point-to-point. Style of messaging application in
a message. For example, the number and location of which the sending application knows the destination of
character strings. the message. Compare with publish/subscribe.

metadata. Data that describes the characteristic of POSIX. Portable Operating System Interface For
stored data. Computer Environments. An IEEE standard for
computer operating systems (for example, AIX and
MQI. Message queue interface. Solaris).

MQIsdp. WebSphere MQ Integrator SCADA device predefined message. A message with a structure that
protocol. A lightweight publish/subscribe protocol is defined before the message is created or referenced.
flowing over TCP/IP. Compare with self-defining message.

MQRFH. An architected message header that is used primitive. A message processing node that is supplied
to provide metadata for the processing of a message. with the product.
This header is supported by MQSeries
Publish/Subscribe. principal. An individual user ID (for example, a log-in
ID) or a group. A group can contain individual user
MQRFH2. An extended version of MQRFH, providing IDs and other groups, to the level of nesting supported
enhanced function in message processing. by the underlying facility.

MQSeries Everyplace™. A generally available property. One of a set of characteristics that define the
MQSeries product that provides proven MQSeries values and behaviors of objects in the Control Center.
reliability and security in a mobile environment. For example, message processing nodes and deployed
message flows have properties.
MRM. Message Repository Manager.
publication node. An end point of a specific path
multilevel wildcard. A wildcard that can be specified through a message flow to which a client application
in subscriptions to match any number of levels in a subscribes. A publication node has an property,
topic. subscription point. If this is not specified, the
publication node represents the default subscription
N point for the message flow.

node. See message processing node. publish/subscribe. Style of messaging application in

which the providers of information (publishers) are
decoupled from the consumers of that information
O (subscribers) using a broker. Compare with
point-to-point. See also topic.
ODBC. Open Database Connectivity.
publisher. An application that makes information
Open Database Connectivity. A standard application about a specified topic available to a broker in a
programming interface (API) for accessing data in both publish/subscribe system.
relational and non-relational database management
systems. Using this API, database applications can
access data stored in database management systems on Q
a variety of computers even if each database
management system uses a different data storage queue. An MQSeries object. Message queuing
format and programming interface. ODBC is based on applications can put messages on, and get messages
the call level interface (CLI) specification of the from, a queue. A queue is owned and maintained by a
X/Open SQL Access Group. queue manager. Local queues can contain a list of
messages waiting to be processed. Queues of other
output node. A message processing node that types cannot contain messages: they point to other
represents a point at which messages flow out of the queues, or can be used as models for dynamic queues.
message flow.
queue manager. A system program that provides
queuing services to applications. It provides an
P application programming interface (the MQI) so that
programs can access messages on the queues that the
plug-in. An extension to the broker, written by a queue manager owns.
third-party developer, to provide a new message
processing node or message parser in addition to those
supplied with the product. See also implementation
function and utility function.

202 WebSphere® MQ Integrator: Introduction and Planning

 Glossary

R subscription. Information held by a broker that

records the details of a subscriber application, including
the identity of the queue on which that subscriber
retained publication. A published message that is
wants to receive relevant publications.
kept at the broker for propagation to clients that
subscribe at some point in the future. subscription filter. A predicate that specifies a subset
of messages to be delivered to a particular subscriber.
request/reply. Type of messaging application in which
a request message is used to request a reply from subscription point. A property of a publication node
another application. Compare with datagram. that differentiates it from other publication nodes on
the same message flow and therefore represents a
rule. A rule is a definition of a process, or set of
specific path through the message flow. An unnamed
processes, applied to a message on receipt by the
publication node (that is, one without a specific
broker. Rules are defined on a message format basis, so
subscription point) is known as the default publication
any message of a particular format will be subjected to
node.
the same set of rules.
Supervisory, Control, And Data Acquisition. A broad
S term, used to describe any form of remote telemetry
system used for gathering data from remote sensor
SCADA. Supervisory, Control, And Data Acquisition. devices (for example, flow rate meters on an oil
pipeline) and for the near real time control of remote
self-defining message. A message that defines its equipment (for example, pipeline valves).
structure within its content. For example, a message
coded in XML is self-defining. Compare with pre-defined system log. See local error log.
message.

send and forget. See datagram.

T
setup type. The definition of the type of installation terminal. The point at which one node in a message
requested on Windows NT systems. This can be one of flow is connected to another node. Terminals enable
Full, Broker only, or Custom. you to control the route that a message takes,
depending whether the operation performed by a node
shared. All configuration data that is shared by users on that message is successful.
of the Control Center. This data is not operational until
it has been deployed. topic. A character string that describes the nature of
the data that is being published in a publish/subscribe
signature. The definition of the external characteristics system.
of a message processing node.
topic based subscription. A subscription specified by
single-level wildcard. A wildcard that can be a subscribing application that includes a topic for
specified in subscriptions to match a single level in a filtering of publications.
topic.
topic security. The use of ACLs applied to one or
SQL. Structured Query Language. more topics to control subscriber access to published
messages.
stream. A method of topic partitioning used by
MQSeries Publish/Subscribe applications. topology. In the broker domain, the brokers,
collectives, and connections between them.
Structured Query Language. A programming
language that is used to define and manipulate data in transform. A defined way in which a message of one
a relational database. The language used by WebSphere format is converted into one or more messages of
MQ Integrator, ESQL, is based on SQL, and has many another format.
similar constructs.

subflow. A sequence of message processing nodes that U

can be included within a message flow. A subflow does
not have to include an input node or an output node, Uniform Resource Identifier. The generic set of all
but can do so if required. names and addresses that refer to World Wide Web
resources.
subscriber. An application that requests information
about a specified topic from a publish/subscribe Uniform Resource Locator. A specific form of URI
broker. that identifies the address of an item on the World
Wide Web. It includes the protocol followed by the
fully qualified domain name (sometimes called the host

Glossary of terms and abbreviations 203

Glossary
name) and the request. The Web server typically maps
the request portion of the URL to a path and file name.
Also known as Universal Resource Locator.

URI. Uniform Resource Identifier

URL. Uniform Resource Locator

User Name Server. The WebSphere MQ Integrator

component that interfaces with operating system
facilities to determine valid users and groups.

utility function. Function provided by WebSphere MQ

Integrator for the benefit of third-party developers
writing plug-in nodes or parsers.

W
warehouse. A persistent, historical datastore for events
(or messages). The Warehouse node within a message
flow supports the recording of information in a
database for subsequent retrieval and processing by
other applications.

wildcard. A character that can be specified in

subscriptions to match a range of topics. See also
multilevel wildcard and single-level wildcard.

wire format. This describes the physical representation

of a message within the bit-stream.

W3C. World Wide Web Consortium. An international

industry consortium set up to develop common
protocols to promote evolution and interoperability of
the World Wide Web.

X
XML. Extensible Markup Language.

204 WebSphere® MQ Integrator: Introduction and Planning

Bibliography
This section describes the documentation
available for all current WebSphere MQ Integrator
WebSphere MQ Integrator
products. Version 2.1 platform-specific
publications
WebSphere MQ Integrator Each WebSphere MQ Integrator product is
Version 2.1 cross-platform documented in at least one platform-specific
publications publication, in addition to the family books.
WebSphere MQ Integrator for AIX Version 2.1
The WebSphere MQ Integrator cross-platform
publications are: WebSphere MQ Integrator for AIX
Installation Guide, GC34-5841
v WebSphere MQ Integrator Introduction and
Planning, GC34-5599 WebSphere MQ Integrator for HP-UX Version
v WebSphere MQ Integrator Using the Control 2.1
Center, SC34-5602 WebSphere MQ Integrator for HP-UX
v WebSphere MQ Integrator Messages, GC34-5601 Installation Guide, GC34-5907
v WebSphere MQ Integrator Programming Guide, WebSphere MQ Integrator for Sun Solaris
SC34-5603 Version 2.1
v WebSphere MQ Integrator Administration Guide, WebSphere MQ Integrator for Sun Solaris
SC34-5792 Installation Guide, GC34-5842
v WebSphere MQ Integrator ESQL Reference, WebSphere MQ Integrator for Windows NT and
SC34-5923 Windows 2000 Version 2.1
v WebSphere MQ Integrator Problem Determination WebSphere MQ Integrator for Windows
Guide, GC34-5920 NT and Windows 2000 Installation
v WebSphere MQ Integrator Working with Messages, Guide, GC34-5600
SC34-6039
WebSphere MQ Integrator for z/OS Version 2.1
These books are all available in hardcopy. WebSphere MQ Integrator for z/OS
Customization and Administration Guide,
You can order publications from the IBMLink™ SC34-5919
Web site at: WebSphere MQ Integrator for z/OS
http://www.ibm.com/ibmlink Program Directory, GI10-2536

In the United States, you can also order MQSeries Everyplace

publications by dialing 1-800-879-2755.
publications
In Canada, you can order publications by dialing If you intend to connect MQSeries Everyplace
1-800-IBM-4YOU (1-800-426-4968). applications to message flows that include the
MQSeries Everyplace message flow nodes, you
For further information about ordering will find the following publications useful:
publications contact your IBM authorized dealer
v MQSeries Everyplace for Multiplatforms Version
or marketing representative.
1.2 Introduction, GC34-5843
v MQSeries Everyplace for Multiplatforms Version
1.2 Programming Guide, SC34-5845
v MQSeries Everyplace for Multiplatforms Version
1.2 Programming Reference, SC34-5846
v MQSeries Everyplace for Multiplatforms Version
1.2 Native Client Information, SC34-5880

© Copyright IBM Corp. 2000, 2002 205

 Bibliography
You can find these books on the MQSeries Web softcopy publications provided on the CD for
site (see “MQSeries information available on the Windows NT components.
Internet” on page 208). Translated versions of
these books are also available in some languages | The searchable PDF package comprises a set of
from the same Web site. | panels, books, and index files that are linked
| together to provide a stand-alone method of
| searching the WebSphere MQ Integrator library. It
New Era of Networks Rules and | contains the following usability enhancements:
Formatter Support for | v One searchable index per book
WebSphere MQ Integrator | v One searchable index file for the entire
publications | WebSphere MQ Integrator library
| v Logical page numbering of PDF files to match
The following publications are supplied on the | printed books
product CD in PDF format, and are installed with
the Documentation component. They are also | v Full cross-referencing within books that allows
available in hardcopy. | you to jump to other parts of the same
| document
v New Era of Networks Rules and Formatter Support
for WebSphere MQ Integrator User’s Guide, | v Hyperlinked URLs to enable transparent
SC34-6084 | integration with the Web
v New Era of Networks Rules and Formatter Support | v An expandable list of PDF Bookmarks that
for WebSphere MQ Integrator System Management | allows you to jump directly to a specific section
Guide, SC34-6083 | within a book
v New Era of Networks Rules and Formatter Support | v Thumbnail images of all pages in the book to
for WebSphere MQ Integrator Rules Programming | allow you to scan for diagrams, tables, and so
Reference, SC34-6085 | on
v New Era of Networks Rules and Formatter Support You can install the searchable PDF package as
for WebSphere MQ Integrator Formatter follows:
Programming Reference, SC34-6086
v On AIX, invoke install —d and select the
v New Era of Networks Rules and Formatter Support documentation fileset. After installation, run the
for WebSphere MQ Integrator Application command mqsidocs. This launches Acrobat
Development Guide, SC34-6082 Reader and opens the PDF package.
These books are provided in US English only. v On HP-UX, invoke swinstall —d and select
WMQI-DOCS from the menu. After installation,
run the command mqsidocs. This launches
Softcopy books Acrobat Reader and opens the PDF package.
All the WebSphere MQ Integrator books are v On Solaris, invoke pkgadd —d and select
available in softcopy formats. wmqi-docs from the menu. After installation,
run the command mqsidocs. This launches
Portable Document Format (PDF) Acrobat Reader and opens the PDF package.
| The WebSphere MQ Integrator library is supplied v On Windows NT, select the Online
| in a searchable PDF package in US English only Documentation component on a custom
| on the product CD. (This package excludes the installation, or do a full installation. After
| WebSphere MQ Integrator for z/OS Program installation, select Start—>Programs—>IBM
| Directory.) The searchable PDF package is also WebSphere MQ Integrator 2.1—>Documentation.
| supplied in the DOC directory on the product | Translated books for national language versions of
| Supplemental CD. The contents of the DOC | this product are provided as stand-alone PDFs
| directory can be viewed without installing the | with the US English PDF package and
| product. | stand-alone PDFs of US English books (for
| WebSphere MQ Integrator and New Era of
Softcopy publications are not provided for the | Networks Rules and Formatter Support for
z/OS operating system. If you have WebSphere | WebSphere MQ Integrator) on a documentation
MQ Integrator for z/OS Version 2.1, refer to the | CD (order number SK3T–6922), which you can

206 WebSphere® MQ Integrator: Introduction and Planning

 Bibliography
| order following general availability. (Not every For Solaris tasks you might need:
| book is available in every supported language.) v WebSphere MQ for Sun Solaris Quick Beginnings,
GC33-1870
| PDF files can be viewed and printed using the
| Adobe Acrobat Reader. To take advantage of the For Windows NT installation tasks you might
| usability enhancements provided in the need:
| searchable library, you will need Adobe Acrobat
v WebSphere MQ for Windows NT and Windows
| Reader with Search Version 4.05 on Windows NT,
2000 Quick Beginnings, GC33-1871
| or Adobe Acrobat Reader with Search Version 4.5
| on UNIX systems. You are not recommended to
For planning and configuration tasks you might
| use this package with Adobe Acrobat Reader with
need:
| Search Version 3.xx.
v MQSeries Intercommunication, SC33-1872
If you need to obtain the Adobe Acrobat Reader, v MQSeries System Administration, SC33-1873
or would like up-to-date information about the v MQSeries Queue Manager Clusters, SC34–5349
platforms on which the Acrobat Reader is
v MQSeries MQSC Command Reference, SC33-1369
supported, visit the Adobe Systems Inc. web site
at: v WebSphere MQ for AIX Quick Beginnings,
GC33-1632
http://www.adobe.com/
v MQSeries Messages, GC33-1876
| If you want to generate your own searchable
| index files for this collection of PDF files, you will For application programming tasks you might
| need Adobe Acrobat Catalog 4 (part of Adobe need:
| Acrobat Version 4). If you want to make your v MQSeries Application Programming Reference,
| own softcopy annotations in the files, you will SC33-1673
| need the full version of Adobe Acrobat Version 4 v MQSeries Application Programming Guide,
| (formerly Adobe Acrobat Exchange Version 3.01). SC33-0807
v MQSeries Application Messaging Interface,
If you cut and paste examples of commands from
SC34–5604
PDF files to a command line for execution, you
must check that the content is correct before you v MQSeries Using Java, SC34-5456
press Enter. Some characters might be corrupted
by local system and font settings. For migrating from MQSeries Integrator Version 1
you might need:
PDF versions of all current WebSphere MQ v MQSeries Integrator Version 1.1 Installation and
Integrator books are also available from the Configuration Guide, GC34-5503
MQSeries product family Web site at:
http://www.ibm.com/software/mqseries/ MQSeries Publish/Subscribe
publications
MQSeries library references
If you have installed MQSeries Publish/Subscribe
The following MQSeries product publications are and plan to migrate brokers to WebSphere MQ
referenced in this book to point you to the Integrator Version 2.1, or to establish a mixed
information you need to complete MQSeries network, refer to the following publication:
messaging product tasks as part of WebSphere
MQ Integrator tasks. v IBM MQSeries Publish/Subscribe User’s Guide,
GC34-5269
For AIX installation tasks you might need:
You can download this book and the MQSeries
v WebSphere MQ for AIX Quick Beginnings, Publish/Subscribe Product Extension package
GC33-1867 from the MQSeries Web site.

For HP-UX installation tasks you might need:

v WebSphere MQ for HP-UX Quick Beginnings,
GC33-1869

Bibliography 207
 MQSeries library

MQSeries Workflow publications

The MQSeries Workflow product has a
comprehensive library. Refer to the following
book for introductory information, and for details
about other product publications:
v IBM MQSeries Workflow Concepts and
Architecture, GH12-6285

For a complete list of MQSeries Workflow

publications, refer to the information on the
MQSeries Web site.

DB2 publications
If you want more information about DB2, you can
download the product publications from the DB2
Web site at:
http://www.ibm.com/software/data/db2

MQSeries information available

on the Internet
The MQSeries product family Web site is at:
http://www.ibm.com/software/mqseries/

By following links from this Web site you can:

v Obtain latest information about the MQSeries
product family.
v Access the MQSeries books in HTML and PDF
formats.
v Obtain information about complementary
offerings by following these links:
– IBM Business Partners
– Partner Offerings (within Related links)
v Download an MQSeries SupportPac.
| v Access Redbooks.

208 WebSphere® MQ Integrator: Introduction and Planning

Index
A broker domain
advanced options 163
Configuration Manager (continued)
queue manager 14
access control list 30 basics 127 configuration repository 13
activating 105 business processes 156 Control Center 15
checking 105 changing components 155 assigning 16
deployment 105 client applications 130 Assignment view 20
dynamic topics 104 Control Center 131 change management 16
explicit 101 listing components 155 check in 16
inheritance 101, 103 managing components 155 check out 16
permissions 103 monitoring 157 connection to Configuration
persistent delivery 103 MQSeries infrastructure 131 Manager 15
PublicGroup 102 performance 160 Debugger 67
resolution of conflicts 101 planning 125 deploying 16
setting 103 plug-ins 163 export 17
settings 101 starting components 155 import 17
subscription resolution 105 stopping components 155 MQSeries authority 150
system topics 103 system management 161 MQSeries resources 133
wildcards 104 workload 160 roles 148
aggregation nodes business integration 3 security 148
AggregateControl 27 MQSeries family 3 security exit 15
AggregateReply 27 business process rules 4 superuser 149
AggregateRequest 27 message flows 18 updating 16
aggregation of messages 26 business scenario 41, 45 custom wire format messages 70
AIX installation business data 43 CWF messages 70
delivery media 190 business needs 44
disk space requirements 111 finance flow 45
hardware requirements 111
software requirements 111
implementation 46
partner flow 45
D
system requirements 111 data conversion 152
retail 42
Application Messaging Interface 26, 80 code pages 152
stock flow 45
applications numeric order 152
WebSphere MQ Integrator
communication models 79 database 38, 137
solution 44
design 79 backup and recovery 139
existing 85 code page support 138
MQSeries resources 135 location 138
point-to-point 79 C ODBC drivers 121, 138
programming interfaces 80 change management ODBC drivers (AIX) 112
publish/subscribe 79, 80, 87 SupportPac IC04 16 ODBC drivers (HP-UX) 114
request/reply 86 CICS 4 ODBC drivers (Solaris) 116
security 85 clusters, MQSeries 135 ODBC drivers (Windows NT) 119
send and forget 86 code page support 122 requirements 137
transaction support 83 code page, database 138 support 121
writing new 87 codeset DB2 122
Assignment view 20 New Era of Networks Rules and Debugger
Formatter Support 123 solving problems using 67
other products 123 delimited string messages 70
B support 123
collective 11, 128
deployment 71
document type definitions (DTDs) 69
broker 10 commands 155 documentation CD 189
associating message flows 20 commit 19 domain 22
associating message sets 25 communication models drag and drop ESQL statements 56
broker tables 10 point-to-point 4, 26 DTDs 69
client connections 28 publish/subscribe 4, 27 dynamic routing 53
collective 11 complementary offerings message flow 53
connections for publish/subscribe 11 IBM Business Partners 208 dynamic topics
creating a reference 10 Partner Offerings 208 ACLs 104
execution group 58 Configuration Manager 13
message flows 11 configuration repository 13, 14
message sets 11
MQSeries resources 132
message repository 14
Message Repository Manager
E
publish/subscribe interactions 89 error handling 157
(MRM) 70
system management interface 12 use of local logs 157
MQSeries resources 132

© Copyright IBM Corp. 2000, 2002 209

error handling in message flows 56 inter-enterprise message sets 72 message flow (continued)
ESQL 56, 62 internally defined messages 71 enriching message content 53
events 12 error handling 56
execution group 58 examples 21
export message set 73
exporting resource definitions 17
J exception list 56
execution group 58
Java message formats 72
input 19
Java nodes 66
interaction 52
JMS
F jms_map 24
message order 51
message processing node 18, 54
finance flow jms_stream 24
output 19
business scenario 45 JMS messages 69
parallel processing 51
processing messages 55
publish/subscribe 19, 60
H L routing 53
header legacy message formats 72 solving problems using the
message 72 license agreement Debugger 67
Help 17 DB2 on AIX 112 subflow 50
HP-UX installation DB2 on HP-UX 114 supplied 65
delivery media 191 DB2 on Solaris 116 supplied defaults 64
hardware requirements 113 DB2 on Windows NT 119 throughput 51
system requirements 113 WebSphere MQ Integrator 121 tracing 159
HP–UX installation Lotus Domino 4 transformation 52
disk space requirements 113 tuning for performance 161
software requirements 113 unit of work 51
M using the DLQ 57
message header 72
message 24, 69
I client access 74
MQRFH 72
MQRFH2 72
IBM Business Partners 208 Control Center definition 23
message header parser
IBMMQSI2 149 creating with SmartGuide 23
MQCFH 75
IBMPrimitive nodes deployment 71
MQCIH 75
check 63 dictionaries 73
MQDLH 75
compute 62 domain 22
MQIIH 75
database 63 headers 81
MQMD 75
extract 62 importing 23
MQMDE 75
filter 63 JMS 69
MQRFH 76
FlowOrder 61 message flows 49
MQRFH2 76
Label 61 message set 23
MQRMH 76
MQeInput 61 MQRFH and MQRFH2 mapping 173
MQSAPH 76
MQeOutput 61 New Era of Networks definition 72
MQWIH 76
MQInput 61 New Era of Networks definitions 23
SMQ_BMH 76
MQOutput 61 order 82
message headers
MQReply 61 parsing 25, 74, 164
MQRFH 82
NeonFormatter 63 persistence 84, 95
MQRFH2 82, 87
NEONMap 63 predefined 23, 70
message parser 25, 74, 164
NeonRules 61, 62 processing in message flow 72
adding 76
NEONRulesEvaluation 61 set 22
message parsers
NEONTransform 63 template 22, 70
default 74
publication 62 using messages 73
message processing node
reset content descriptor 63 using templates 73
adding 66
RouteToLabel 62 wire format 70
common node characteristics 54
SCADAInput 62 within transactions 83
creating new 164
SCADAOutput 62 message catalog
enhancing 66
throw 64 NLV 122
IBMPrimitives 61
trace 64 plug-ins 122
input 55
trycatch 64 z/OS 122
input node 19
warehouse 64 message dictionary
MQeInput 19
import message set 73 using with clients 73
MQInput 19
importing resource definitions 17 message flow 49
MQOutput 19
IMS/ESA 4 assigning to brokers 59
output 55
information on the Internet business process rules 18
output node 19
complementary offerings 208 common node characteristics 54
primitives 18
MQSeries family libraries 208 contents 50
publication node 19
MQSeries products 208 creating 18
SCADAInput 19
MQSeries SupportPacs 208 default 65
SCADAOutput 19
input terminal 18 definition 50
Message Queue Interface 26, 80
integration 167 dynamic routing 53

210 WebSphere® MQ Integrator: Introduction and Planning

message set
assigning to brokers 59
MQSeries Publish/Subscribe migration
(continued)
P
assignment 23 checklist 187 parsers 74
deployment 23 heterogeneous networks 185 partner flow 45
export 73 independent networks 185 Partner Offerings 208
import 73 migrating a network 186 PDF (Portable Document Format) 206
message sets MQSeries support 171 PDF messages 70
inter-enterprise 72 product differences 172 planning
message template 18, 70 content-based filtering 183 database resources 127
messages default topic routing 182 MQSeries resources 126
internally defined 71 message formats 173 naming conventions 125
Java 72 metatopics 182 WebSphere MQ Integrator
legacy formats 72 stream authority 178 resources 125
predefined 69 streams 175 plug-ins
self-defining 69 streams and migration 178 guidelines 163
XML 69 streams and neighbor brokers 177 message parser 164
Microsoft Exchange 4 subscription points 183 message processing node 164
migration 40, 167 throughput 184 plug-ins, message catalog 122
MQIntegrator 167 topics 180 Portable Document Format (PDF) 206
MQSeries Integrator Version 1 167 wildcards 180 porting
MQSeries Publish/Subscribe 171 scenarios 172 issues 66
modifying components 155 MQSeries Publish/SubscribeMQSeries predefined messages 22, 69
mqbrasgn 141 Publish/Subscribe primary security domain 142
mqbrdevt 141 mixed network principals 29, 140
mqbrkrs 140 MQSeries queues 87 IBMMQSI2 149
mqbrops 141 MQSeries resources mqbrasgn 141
mqbrtpic 141 application use of queues 82 mqbrdevt 141
MQeInput node MQSeries Workflow 3 mqbrkrs 102, 140
in example message flows 21 MQSeries, NLV support 122 mqbrops 141
MQeMbMsgObject 73 multilevel wildcards 97 mqbrtpic 141
MQeMsgObject 73 multipart messages 24 problem determination 157
MQeOutput node commands 158
in example message flows 21 database logs 159
database messages 159
MQRFH 82
mapping to MQRFH2 173
N messages 159
naming conventions 125 MQSeries events 159
message header 72
National Language Support 122 MQSeries logs 159
MQRFH2 82
New Era of Networks MQSeries messages 159
mapping to MQRFH 173
accessing rules and formats 170 ODBC traces 159
message header 72
existing rules and formats 168 optional traces 158
MQSeries
message definitions 23 service trace 158
AMI 4
rules and formats 168 UNIX syslog 157
business integration 3
New Era of Networks Rules and user trace 158
channel security exits 15
Formatter Support user traces 157
clusters 135
code page support restrictions 122 Windows NT event log 157
MQI 4
New Era of Networks Rules and problems
trusted applications 160
Formatter Support publications 206 solving using the Debugger 67
MQSeries Everyplace
nodes 55, 66 PROPAGATE statement 24
special considerations 31
MQSeries Everyplace publications 205 publication access 105
MQSeries family publications
business integration 3 O MQSeries Everyplace 205
MQSeries messaging 4 ODBC publish/subscribe
MQSeries Workflow 4 drivers 138 event information 90
WebSphere MQ Integrator 4 drivers on AIX 112 global 92
MQSeries Integrator Version 1 migration drivers on HP-UX 114 local 92
backing up files 168 drivers on Solaris 116 retained 90, 95
considerations for installation 167 drivers on Windows NT 119 state information 90
enhancing rules and formats 169 online Help 17 retained 91
existing rules and formats 168 online Tour 17 WebSphere MQ Integrator 205
preserving data 168 Order Mode publications CD 189
run-time tasks 168 By Queue Order 83 publish/subscribe 89
uninstalling 168 By User ID 83 ACLs 30
user exits 171 property 82 collectives 100, 128
WebSphere MQ Integrator Version 2.1 output terminal 18 default ACL 30
message flow 169 default subscription point 20
MQSeries Publish/Subscribe filters 94
migration 171 interactions with broker 89, 99
messages 100

Index 211
publish/subscribe (continued) security subsystem transformation
multiple topics 99 principals 29 message flow 52
publication node 20 self-defining messages 22, 69 trusted security domain 142
reserved characters 97 simple message types 71
security 101 single-level wildcards 97
special characters 97
subscription point 20
SmartGuide for message creation 23
softcopy books 206
U
User Name Server 29, 129
throughput 60 Solaris installation
MQSeries resources 133
topic 27 delivery media 192
multiple 130
topic root 29 disk space requirements 115
principals 101
topic-based security 29, 129 hardware requirements 115
topics 96 software requirements 115
unnamed publication node 20 system requirements 115
wildcards 97 solving problems V
using the Debugger 67 version control
special characters SupportPac IC04 16
Q topic level separator 97
stock flow 45
viewing components 155
quality of service 84
subscription options
new publications only 95
publish on request only 95
W
R subscription points 93
WebSphere MQ Integrator for z/OS
security 148
Redbooks 208 default 20, 93
WebSphere MQ Integrator on the
resource definition using 94
Internet 208
import and export 17 subscriptions
WebSphere MQ Integrator
retained publications 90, 91, 95 content filter 93
publications 205
performance implications 91 local 95
national language 206
roll back 19 registration 92
platform–specific 205
routing subscriber queue 93
WebSphere MQ Integrator Version 2.1
message flow 53 subscription point 93
applications 26
rules 4 superuser, IBMMQSI2 149
broker 10
Supply Chain Management 3
business integration 5
supported codesets 123
components 9
S SupportPac 208
system management 12, 161
Configuration Manager 13
SAP/R3 4 Control Center 15
system requirements 109
SCADA dependencies 37
AIX installation 111
quality of service 84 database 38
HP-UX installation 113
security 85 MQSeries 37
Solaris installation 115
special considerations 31 enhancements 7
summary 109
SCADA applications 36 getting started 5
Windows NT installation 117
SCADAInput node migrating from previous products 7
z/OS installation 120
in example message flows 21 package contents 189
scenario Tour 17
business 41 User Name Server 29
retail 42 T wildcards
security tagged delimited string messages 70 multi-level 98
ACLs 103, 151 tagged messages 70 multilevel 97
applications 85, 150 TDS messages 70 single-level 97, 98
configuration 147 template 18, 22 Windows 2000 xii
Control Center roles 148 throughput Windows NT installation
database 148 message flow 51 database 118
domain 140 publish/subscribe message flow 60 delivery media 193
message flows 150 Tivoli 12 disk space requirements 117
operational 147 topic access 105 hardware requirements 117
primary security domain 142 topic root 27 MQSeries 118
principals 140 topic tree 27 operating system software 118
public access 102 topic-based security 101, 129 software requirements 117
run-time 147 topics system requirements 117
SCADA 85 publish/subscribe 96 wire format 22
topic-based 150 semantics 98
trusted security domain 142 wildcards 98
WebSphere MQ Integrator for
z/OS 148
Tour 17
trace commands 158
X
XA
security domains transactionality 55
commit 19
UNIX 144 transactions 83
roll back 19
Windows NT 142 database interactions 83
technology 19
Security exit for Control Center 15

212 WebSphere® MQ Integrator: Introduction and Planning

XML messages 69

Z
z/OS commands 156
z/OS installation
delivery media 194
disk space requirements 120
hardware requirements 120
software requirements 120
system requirements 120

Index 213
214 WebSphere® MQ Integrator: Introduction and Planning
Sending your comments to IBM
If you especially like or dislike anything about this book, please use one of the
methods listed below to send your comments to IBM.

Feel free to comment on what you regard as specific errors or omissions, and on
the accuracy, organization, subject matter, or completeness of this book.

Please limit your comments to the information in this book and the way in which
the information is presented.

To make comments about the functions of IBM products or systems, talk to your
IBM representative or to your IBM authorized remarketer.

When you send comments to IBM, you grant IBM a nonexclusive right to use or
distribute your comments in any way it believes appropriate, without incurring
any obligation to you.

You can send your comments to IBM in any of the following ways:
v By mail, to this address:
User Technologies Department (MP095)
IBM United Kingdom Laboratories
Hursley Park
WINCHESTER,
Hampshire
SO21 2JN
United Kingdom
v By fax:
– From outside the U.K., after your international access code use
44–1962–842327
– From within the U.K., use 01962–842327
v Electronically, use the appropriate network ID:
– IBM Mail Exchange: GBIBM2Q9 at IBMMAIL
– IBMLink: HURSLEY(IDRCF)
– Internet: [email protected]

Whichever method you use, ensure that you include:

v The publication title and order number
v The topic to which your comment applies
v Your name and address/telephone number/fax number/network ID.

© Copyright IBM Corp. 2000, 2002 215

216 WebSphere® MQ Integrator: Introduction and Planning



Printed in the United States of America

on recycled paper containing 10%
recovered post-consumer fiber.

GC34-5599-04
Spine information:

 WebSphere® MQ Integrator Introduction and Planning Version 2.1