Message Broker Nodes

Message broker nodes are used in Message flows. A message flow node is a processingstep
in a message flow.A message flow node receives a message, performs a set of actions against
the message,and optionally passes the message on to the next node in the message flow. A
messageflow node can be a built-in node, a user-defined node, or a subflow node.A
built-in node
is a message flow node that is supplied by WebSphere MessageBroker. The built-in nodes
provide input and output, manipulation and transformation,decision making, collating
requests, and error handling and reporting functions.A
user-defined node
is an extension to the broker that provides a new message flownode in addition to those
supplied with the product. It must be written to the user-definednode API provided by
WebSphere Message Broker for both C and Java languages.A
subflow
is a directed graph that is composed of message flow nodes and connectorsand is designed to
be embedded in a message flow or in another subflow. A subflow mustinclude at least one
Input node or one Output node. A subflow can be executed by a broker only as part of the
message flow in which it is embedded, and therefore cannot beindependently deployed.A
message flow node has a fixed number of input and output points known as
terminals
.You can make connections between the terminals to define the routes that a message cantake
through a message flow.Input and output nodes define points in the message flow to which
client applicationssend messages, and from which client applications receive messages.Client
applicationsinteract with these nodes by putting messages to, or getting messages from, the
I/Oresource that is specified by the node as the source or target of the messages. Although
amessage flow must include at least one input node, it does not need to include an
outputnode.
Overview of all the nodes available in WMB v6.0, 6.1 and 7.0

Input Nodes:

MQInput
Use an MQInput node if the messages arrive at the broker on a WebSphere MQ queue,and
the node is to be at the start of a message flow.
MQGet
Use an MQGet node if the messages arrive at the broker on a WebSphere MQ queueand the
node is not to be at the start of a message flow.
SCADAInput
Use a SCADAInput node if the messages are sent by a telemetry device
HTTP
Input
Use an HTTPInput node if the messages are sent by a Web services client.
Real-timeInput or Real-timeOptimizedFlow
Use one of these nodes if the messages are sent by a JMS or multicast application.The Real-
timeInput node is an input node and the Real-timeOptimizedFlow node is acomplete message
flow that provides a high performance publish/subscribe messageflow.
JMSInput
Use a JMSInput node if the messages are sent by a JMS application.
User-defined input node
Use a user-defined input node if the message source is a client or application that usesa
different protocol or transport.
Input node
If you are creating a message flow that you want to embed in another message flow
(asubflow) that you will not deploy as a stand-alone message flow, you must include atleast
one Input node to receive messages into the subflow.
Output Nodes:

Publication
Use a Publication node to distribute the messages using the publish/subscribe network for
applications that subscribe to the broker across all supported protocols.
MQOutput
Use an MQOutput node if the target application expects to receive messages on aWebSphere
MQ queue, or on the WebSphere MQ reply-to queue that is specified in theinput message
MQMD
MQReply
Use an MQReply node if the target application expects to receive messages on
theWebSphere MQ reply-to queue that is specified in the input message MQMD.
SCADAOutput
Use a SCADAOutput node if a telemetry device is the target of the output messages,and the
Publication node is not suitable.
HTTPReply
Use an HTTPReply node if the messages are in response to a Web services clientrequest.
HTTPRequest
Use an HTTPRequest node if your message flow interacts with a Web service.
Real-timeOptimizedFlow
Use a Real-timeOptimizedFlow node if the target application is a JMS or
multicastapplication.
JMSOutput
Use a JMSOutput node if the messages are for a JMS destination.
User-defined output node


Use the XMLTransformation node to transform an input XML message into another format
using XSLT style sheets.It, can perform the following actions:* Sort the data* Select data
elements to include or exclude based on some criteria* Transform the data into another
format
JMSMQ
Transform
Use the JMSMQTransform node to transform a message with a JMS message tree intoa
message that has a tree structure that is compatible with the format of messages that
are produced by the WebSphere MQ JMS provider.
MQJMSTransform
Use the MQJMSTransform node to receive messages that have a WebSphere MQ
JMS provider message tree format, and transform them into a format that is compatible
withmessages that are to be sent to JMS destinations.
MQOptimizedFlow
Use the MQOptimizedFlow node to replace a publish/subscribe message flow thatconsists of
an MQInput node connected to a Publication node, and that uses the JMS over WebSphere
MQ transport.
User-defined
Use a user-defined node to handle specific requirements that are not met by the built-
innodes.
Decision making nodes

Validate
Use the Validate node to check that the message that arrives on its input terminal is
asexpected.
Filter
Use the Filter node with an ESQL statement to determine the next node to which themessage
is sent by this node.
FlowOrder
You can connect the terminals of this node to force the message to be processed by
onesequence of nodes, followed by a second sequence of nodes.
Passthrough
Use the Passthrough node to enable version control of a subflow at run time. Use thisnode to
add a label to your subflow.
RouteToLabel and Label
Use the RouteToLabel node following a Compute node for complex routing. Define alist of
destinations in a Compute node that are acted on by the RouteToLabel node,
whichinterrogates the destinations and passes the message on to the corresponding Label
node.
ResetContentDescriptor
Use the ResetContentDescriptor node to set new message properties that are used whenthe
message bit stream is next parsed by a subsequent node in the message flow.

Nodes for controlling time-sensitive operations

TimeoutControl
Use a TimeoutControl node and a TimeoutNotification node together in a messageflow to
control events that occur at a specific time or at defined time intervals. TheTimeoutControl
node receives an input message that contains a timeout request. All or part of this input
message is validated and stored to be propagated by an associatedTimeoutNotification node
in the message flow. The input message is also propagatedunchanged to the next node in the
message flow.
TimeoutNotification
Use a stand-alone TimeoutNotification node to generate messages that are propagatedat
configured times or time intervals to the next node in the message flow for
further processing.
Nodes for collating requests
Use the
AggregateControl, AggregateReply, and AggregateRequest
nodes to collaterelated requests and responses. Use these nodes to generate several requests in
responseto one input message, to control and coordinate the responses that are received
inresponse to those requests, and to combine the information that is provided by theresponses
to continue processing.
Error handling and reporting nodes

Trace
Include a Trace node to generate one or more trace entries to record what is happeningin the
message flow at this point.
TryCatch
Include a TryCatch node to control the error processing when exceptions are thrown.
Throw
Include a Throw node to force an exception to be thrown, and specify the identity of the
exception, to make it easier to diagnose the problem.
New nodes in v6.1

File and FTP nodes

FileInput node
reads files from the local file system or FTP server
FileOutput node
writes files to the local file system or FTP server
R oute, database route nodes:
The new
Route node
provides a graphical technique to enable incoming requests to beexamined, and flow sent
down the appropriate part of the message flow, depending on the

specified criteria.The
DatabaseRoute
node provides a similar function to the Route node, but the routingdecision is based on the
contents of a relational database.
DatabaseRetrieve
node enables data to be retrieved from one of more relationaldatabases, and use a similar
dialogue to the DatabaseRoute node.
New nodes in V7
V7 introduced new nodes for SCA (service component architecture). These are nodes
are basically for use with websphere process server which uses SCA.
SCA Input Node
: A WebSphere Process Server SCA Import component can useMessage Broker as an SCA
endpoint. The message received by the broker can be a SOAPover HTTP message or an MQ
message on a queue, depending on the binding used bythe node.
SCA Reply Node
: This allows a response message to be sent from the broker back to theoriginating Process
Server SCA client, in response to a prior message received by anSCA Input Node.
SCA Request Node:
This allows synchronous requests to be made from the broker,allowing the broker to
participate in synchronous message exchange patterns with aProcess Server SCA export
component. The message sent by the broker can be a SOAPmessage over HTTP, or an MQ
message, depending on the binding used by the node. Thenode will perform a blocked wait
for a specified time period until a response is received




WebSphere Message Broker Version 6.1.0.10 > Developing applications > Developing message flow
applications
Message flows overview
A message flow is a sequence of processing steps that
run in the broker when an input message is received.
You define a message flow in the workbench by including a number of message flow
nodes, each of which represents a set of actions that define a processing step. The way
in which you join the message flow nodes together determine which processing steps are
carried out, in which order, and under which conditions. The path that you create
between one node and another is known as a connection.
A message flow must include an input node that provides the source of the messages
that are processed. You can process the message in one or more ways, and optionally
deliver it through one or more output nodes. The message is received as a bit stream,
and is converted by a parser into a tree structure that is used internally in the message
flow. Before the message is delivered to a final destination, it is converted back into a bit
stream. For more information about these conversions, see Parsers and The message
tree.
When you want to exchange messages between multiple applications, you might find
that the applications do not understand or expect messages in the same format. You
might must provide some processing between the sending and receiving applications
that ensures that both can continue to work unchanged, but can exchange messages
successfully.
You define the processing that is required when you create and configure a message
flow. You can include built-in nodes, nodes that are supplied by a vendor, nodes that you
have created yourself (user-defined nodes), or other message flows (known as
subflows).
The processing that you set up determines what actions are performed on a message
when it is received, the order in which the actions are completed, and the final
destinations of the message. All these actions manage the route that a message takes
through a message flow.
You can configure additional properties to make your message flow transactional, or
multithreaded. You can also add error paths that ensure every message is handled in an
appropriate way.
When you want to run a message flow to process messages, you deploy it to a broker,
where it is run in an execution group.
The mode in which your broker is working, can affect the number of execution groups
and message flows that you can deploy, and the types of node that you can use.
See Restrictions that apply in each operation mode.
The following topics describe the concepts that you must understand to design, create,
and configure a message flow and its associated resources:
Projects
Nodes
WebSphere Adapters nodes
IBM Information Management System (IMS)
Configurable services
Version and keywords
Message flow connections
Threading
Execution and threading models in a message flow
The message tree
Parsers
Properties
Message flow transactions
Broker schemas
Business-level monitoring
Accounting and statistics data
Aggregation
Message collections
Converting data with message flows
User exits
For a basic introduction to developing message flows, see the IBM Redbooks
publication WebSphere Message Broker Basics.
Related concepts:
Brokers
Execution groups
End-user application support
Message modeling
Properties
Related tasks:
Developing message flows
Related reference:
Message flows
Publish/subscribe
Notices | Trademarks | Downloads | Library | Support | Feedback

Copyright IBM Corporation 1999, 2011.

Last updated : 2011-11-10 13:36:06



Concept topic | Version 6.1.0.10 | ac00310_

http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r1m0/topic/com.ibm.etools.mft.doc/ac00310_.htm










WebSphere Message Broker Version 6.1.0.10 > Developing applications > Developing message flow
applications > Message flows overview
Message flow nodes
A message flow node is a processing step in a message
flow. It can be a built-in node, a user-defined node, or
a subflow node.
A message flow node receives a message, performs a set of actions against the
message, and optionally passes the original message, and none or more other
messages, to the next node in the message flow.
A message flow node has a fixed number of input and output points known as terminals.
You can make connections between the terminals to define the routes that a message
can take through a message flow. Message flow nodes are displayed in the node
palette associated with the Message Flow editor. The palette is arranged in categories,
which group together nodes that provide related processing; for example,
transformation.
Input nodes do not have input terminals. The message flow starts when a message is
retrieved from an input device; for example, a WebSphere MQ queue. The message
flow ends when none or more output messages have been sent by one or more output
nodes, and control returns back to the input node. The input node either commits or rolls
back the transaction. Input and output nodes can be protocol-specific, to interact with
particular systems such as Web Services.
Most nodes are processing nodes, that you can include between your input and output
nodes and connect together to define the flow of control. These nodes typically
transform a message from one format to another, or route a message along a particular
path, or provide more complex options such as aggregation or filtering.
You can configure a node by setting or changing the values for its properties. Some
nodes have mandatory properties, for which you must set a value. Other properties must
have a value, but are assigned a default value which you can leave unchanged. The
remaining properties are optional properties; no value is required.
When you develop a message flow, the way in which you set the properties of the nodes
in that flow influences the way in which the messages are processed by that flow. For
example, by setting properties that define input and output WebSphere MQ queue
names, you determine where the message flow receives the message from, and where it
delivers the message.
You can also configure nodes by using promoted properties; promote one or more node
properties to become properties of the message flow that contains those nodes. You can
then change these properties at the flow level, rather than having to update one or more
individual nodes. You can also promote equivalent properties from more than one node
to the same message flow property; for example, you might use this technique to set, at
the flow level, the name of the database that all the nodes in the message flow must
connect to.
A subset of node properties are configurable properties; that is, you can change their
values when you deploy the message flow to a broker for execution. You might find this
ability useful if you deploy a message flow to more than one broker, and want it to
behave in a slightly different way on each broker. For example, when you deploy the
message flow to a test broker, you can set a configurable property to force the flow to
interact with a test database. When you deploy the same message flow to a production
broker, you can set the same property to the value of a production database, without
having to update the message flow itself.
The mode that your broker is working in can affect the types of node that you can use;
seeRestrictions that apply in each operation mode.
You can add nodes of three types into your message flows:
Built-in node
A built-in node is a message flow node that is supplied by WebSphere Message
Broker. The built-in nodes provide input and output, manipulation and
transformation, decision making, collating requests, and error handling and
reporting functions.
For information about all of the built-in nodes supplied by WebSphere Message
Broker, see Built-in nodes.
User-defined node
A user-defined node is an extension to the broker that provides a new message
flow node in addition to those supplied with the product. It must be written to the
user-defined node API provided by WebSphere Message Broker for both C and
Java languages. The following sample demonstrates how you can write your own
nodes in both C and Java languages.
User-defined Extension
You can view information about samples only when you use the information
center that is integrated with the Message Broker Toolkit. You can run samples
only when you use the information center that is integrated with the Message
Broker Toolkit.
Subflow
A subflow is a directed graph that is composed of message flow nodes and
connectors and is designed to be embedded in a message flow or in another
subflow. A subflow must include at least one Input node or oneOutput node. A
subflow can be executed by a broker only as part of the message flow in which it
is embedded, and therefore cannot be independently deployed.
A message is received by an Input node and processed according to the definition
of the subflow. That might include being stored through a Warehouse node, or
delivered to another message target, for example through an MQOutput node. If
required, the message can be passed through an Output node back to the main
flow for further processing.
The subflow, when it is embedded in a main flow, is represented by a subflow
node, which has a unique icon. The icon is displayed with the correct number of
terminals to represent the Input and Output nodes that you have included in the
subflow definition.
The most common use of a subflow is to provide processing that is required in
many places within a message flow, or is to be shared between several message
flows. For example, you might code some error processing in a subflow, or create
a subflow to provide an audit trail (storing the entire message and writing a trace
entry).
For more information, see Using subflows.
A node does not always produce an output message for every output terminal:
often it produces one output for a single terminal based on the message received
or the result of the operation of the node. For example, aFilter node typically
sends a message on either the True terminal or the False terminal, but not both.
If you have connected more than one terminal to another node, the processing in
the node determines the order in which the message is propagated to the nodes
that it is connected to; you cannot change this order. The node sends the output
message on each terminal, but sends on the next terminal only when the
processing has completed for the current terminal.
Updates to a message are never propagated to nodes which have been previously
executed, only to nodes that follow the node in which the update has been made.
The order in which the message is propagated to the different output terminals is
determined by the broker; you cannot change this order. The only exception to
this rule is the FlowOrder node, in which the terminals indicate the order in which
the message is propagated to each.
All built-in nodes include error handling as part of their processing. If an error is
detected within the node, the message is propagated to the failure terminal. What
happens then depends on the structure of your message flow. You can use only
the basic error handling provided by the broker, or you can enhance your flow by
adding error processing nodes and flows to provide more comprehensive failure
processing. For more information about these options, see Handling errors in
message flows.
The message flow can accept a new message for processing only when all paths
through the message flow (that is, all connected nodes from all output terminals)
have been completed, and control has returned to the input node which commits
or rolls back the transaction.
The following sample uses environment variables in the XML_Reservation sample
to store information that has been taken from a database table and to pass that
information to a node downstream in the message flow.
Airline Reservations
You can view information about samples only when you use the information
center that is integrated with the Message Broker Toolkit. You can run samples
only when you use the information center that is integrated with the Message
Broker Toolkit.
Related concepts:
Message flow projects
Message flow connections
Message modeling
Related tasks:
Defining a promoted property
Developing message flows
Related reference:
Message flow projects and files
Built-in nodes
Related information
Java user-defined extensions API
Notices | Trademarks | Downloads | Library | Support | Feedback

Copyright IBM Corporation 1999, 2011.

Last updated : 2011-11-10 13:36:41



Concept topic | Version 6.1.0.10 | ac12640_

http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r1m0/topic/com.ibm.etools.mft.doc/ac12640_.htm




WebSphere Message Broker Version 6.1.0.10 > Developing applications > Developing message flow
applications > Developing message mappings > Message mappings overview
Message flows, ESQL, and mappings
A message flow represents the set of actions that are performed on a message when it is
received and processed by a broker.
The content and behavior of a message flow is defined by a set of files that you create
when you complete your definition and configuration of the message flow content and
structure:
The message flow definition file <message_flow_name>.msgflow. This file is
mandatory, and is created automatically for you. It contains details about the
message flow characteristics and contents (for example, what nodes it includes,
its promoted properties, and so on).
The ESQL resources file <message_flow_name>.esql. This file is required only if
your message flow includes one or more of the nodes that you can customize by
using ESQL modules. You can create this file yourself, or you can cause it to be
created for you by requesting specific actions against a node.
You can customize the following built-in nodes by creating free-form ESQL
statements that use the built-in ESQL statements and functions, and your own
user-defined functions:
o Compute
o Database
o Filter
The message mappings file <message_flow_name><_nodename>.msgmap. This file
is required only if your message flow contains one or more of the nodes that you
can customize by using mappings. You can create this file yourself, or you can
cause it to be created for you by requesting specific actions against a node. A
different file is required for each node in the message flow that uses the Message
Mapping editor.
You can customize the following built-in nodes by specifying how input values
map to output values.
Node Usage
Node Usage
DataDelete
node
Use this node to delete one or more rows from a database table without creating an
output message.
DataInsert
node
Use this node to insert one or more rows in a database table without creating an output
message.
DataUpdate
node
Use this node to update one or more rows in a database table without creating an output
message.
Mapping
node
Use this node to construct output messages and populate them with information that is
new, modified from the input message, or taken from a database. You can also use
the Mapping node to update, insert, or delete rows in a database table.
Warehouse
node
Use this node to store all or part of a message in a database table without creating an
output message.
You can use built-in ESQL functions and statements to define message mappings,
and you can use your own ESQL functions.
The Extract node also uses mappings to create a new output message that
contains a subset of the contents of the input message. However,
the Extract node is deprecated in WebSphere Message Broker Version 6.0 and
later releases. Although message flows that contain an Extract node remain valid
inWebSphere Message Broker Version 6.0, redesign your message flows to
replace Extract nodes byMapping nodes to take advantage of later enhancements.
Related concepts:
Message flows overview
Promoted properties
ESQL overview
Message mappings overview
Related tasks:
Developing message flows
Using message mappings
Developing ESQL
Related reference:
Built-in nodes
Notices | Trademarks | Downloads | Library | Support | Feedback

Copyright IBM Corporation 1999, 2011.

Last updated : 2011-11-10 13:36:11



Concept topic | Version 6.1.0.10 | ac00430_

http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r1m0/topic/com.ibm.etools.mft.doc/ac00430_.htm