WebSphere
Event Broker includes
a large number of message processing nodes that you can use within your message
flows. You can also choose from user-defined nodes that
have been created and supplied by users,
or other vendors and companies.
Your
decision about which nodes to use depends on the processing that you want
to perform on your messages.
- Input and output nodes
- Input and output nodes define points in the message flow to which client
applications send messages (input nodes such as MQInput) and from which client
applications receive messages (output nodes such as MQOutput). Client applications
interact with these nodes by putting messages to, or getting messages from,
the I/O resource that is specified by the node as the source or target of
the messages. Although a message flow must include at least one input node,
it does not have to include an output node.
- If you are creating a message flow that you want to deploy to a broker,
you must include at least one input node to receive messages. The input node
that you choose depends on the source of the input messages and where in the
flow you want to receive the messages:
- 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.
The use of message
flows that contain MQeInput nodes in WebSphere Event Broker Version
6.0 is
deprecated. Redesign your message flows to remove the MQe nodes and replace
them with MQ nodes that are configured to your own specifications and coordinated
with your MQe Gateway configuration. For more details, see Migrating a message flow that contains WebSphere MQ Everyplace nodes.
- MQGet
- Use an MQGet node if the messages arrive at the broker on a WebSphere
MQ queue and 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.
- 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 a complete message flow that provides a high performance publish/subscribe message
flow.
- 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 uses a different protocol or transport.
- Input node
- If you are creating a message flow that you want to embed in another message
flow (a subflow) that you will not deploy as a standalone message flow, you
must include at least one Input node to receive messages into the subflow.
An
instance of the Input node represents an In terminal. For example, if you
have included one instance of the Input node, the subflow icon shows one In
terminal, which you can connect to other nodes in the main flow in the same
way that you connect any other node.
To deploy a message flow, it must
have at least one input node. If your message flow does not contain an input
node, you are prevented from adding it to the broker archive file. The input
node can be in the main flow, or in a message flow that is embedded in the
main flow.
You can use more than one input node in a message flow. For
more information, see Using more than one input node.
- If you want to send the messages produced by the message flow to a target
application, you can include one or more output nodes. The output node that
you choose depends on the transport across which the target application expects
to receive those messages:
- Publication
- Use a Publication node if you want to distribute the messages using the
publish/subscribe network for applications that subscribe to the broker across
all supported protocols. A Publication node is an output node that uses output
destinations that are identified by subscribers whose subscriptions match
the characteristics of the current message.
- MQOutput
- Use an MQOutput node if the target application expects to receive messages
on a WebSphere MQ queue, or on the WebSphere MQ reply-to
queue specified in the input message MQMD.
The use of message flows that
contain MQeOutput nodes in WebSphere Event Broker Version
6.0 is
deprecated. Redesign your message flows to remove the MQe nodes and replace
them with MQ nodes that are configured to your own specifications and coordinated
with your MQe Gateway configuration. For more details, see Migrating a message flow that contains WebSphere MQ Everyplace nodes.
- MQReply
- Use an MQReply node if the target application expects to receive messages
on the WebSphere MQ reply-to queue specified
in the input message MQMD.
- SCADAOutput
- Use a SCADAInput node if a telemetry device is the target of the output
messages, and the Publication node is not suitable.
- Real-timeOptimizedFlow
- Use a Real-timeOptimizedFlow node if the target application is a JMS or
multicast application.
- JMSOutput
- Use a JMSOutput node if the messages are for a JMS destination.
- User-defined output node
- Use a user-defined output node if the target is a client or application
that uses a different protocol or transport.
- Output node
- If you are creating a message flow that you want to embed in another message
flow (a subflow) that you will not deploy as a standalone message flow, you
must include at least one Output node to propagate messages to subsequent
nodes that you connect to the subflow.
An instance of the Output node represents
an Out terminal. For example, if you have included two instances of the Output
node, the subflow icon shows two Out terminals, which you can connect to other
nodes in the main flow in the same way that you connect any other node.