Browse Prior Art Database

A Generic Input and Output Concept for Message Flows in MQSeries Integrator V2 Supporting Physical Segregation of Organizational Units Disclosure Number: IPCOM000014775D
Original Publication Date: 2001-Jun-15
Included in the Prior Art Database: 2003-Jun-20

Publishing Venue



1. Introduction

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 26% of the total text.

Page 1 of 10

  A Generic Input and Output Concept for Message Flows in MQSeries Integrator V2 Supporting Physical Segregation of Organizational Units

1. Introduction

    MQSeries Integrator V2 (MQSI) is a message broker product that helps integrate applications by managing the flow of information between them.

    It provides services that let you route messages by using rules that can do any of the following: - Read the contents of the message or message header and act accordingly - Transform a message - Store a message (or part of it) in a database, or retrieve a message (or part of it) from a database - Modify a message - Publish a message

    MQSI provides a graphical user interface called the Control Center, with which you can model message flows by placing MQSeries Integrator processing nodes or primitives onto a modeling area, and connecting them. Each message flow must start with at least one input primitive 'MQInput' and typically ends with one output primitive 'MQOutput'. As its communication layer, MQSI uses the MQSeries messaging products. Each input primitive has assigned to it exactly one MQSeries queue, whereas each output primitive can have one or more MQSeries queues assigned to it. The output queue name(s) can be changed during runtime, but for the name of the input queue is specified at configuration time and cannot be changed during runtime. You can connect more than one input primitive to a processing node. Each input primitive then starts a new thread of the same message flow.

Simple message flow with two input primitives


Page 2 of 10

2. Problem Statement

    Service centers, especially those of financial institutions (FIs) provide services for organizational units (OUs). The OUs can be departments within the service centers, or can be other FIs. These business processes are often the same for nearly all of the OUs. Because of security aspects of the financial sector, physical storage (for example queues within MQSeries, or tables in the database) must be separate for every OU.

3. State of the Art

    There are several ways to design a message flow that meets these requirements using MQSI. One way would be to create two message flows (one with the required business logic, and a second that contains the input and output primitives), and to place between them as a processing node the flow with the business logic. The second flow must be created for every OU.

One Message Flow per OU with a Common Message Flow as Processing Node


[This page contains 2 pictures or other non-text objects]

Page 3 of 10

Common Message Flow 'Processing Flow1'

OU-specific Message Flow using the Common Message Flow before

    Another solution would be a common message flow for all OUs starting with as many input primitives as OUs. Before the output primitive, a compute node must be inserted to determine the destination MQSeries queue and to insert this queue name in the destination list of the message.


[This page contains 4 pictures or other non-text objects]

Page 4 of...