You can include more than one input node in a single message
flow. You might find this useful in the following situations:
- The message flow provides common processing for messages that are received
across multiple transports. For example, a single message flow might handle:
- Data in messages received across WebSphere
MQ,
and therefore through a WebSphere
MQ queue and
an MQInput node
- Messages that are received across native IP connections (a Real-timeInput
node)
- You need to set standard properties on the MQInput node if input messages:
- are all received across WebSphere
MQ, and
- do not include an MQRFH2 header.
If the required standard properties are not always the same for every
message, you can include more than one input node and configure each to handle
a particular set of properties.
- Each input node in a message flow causes the broker to start a separate
thread of execution. Including more than one input node might improve the
message flow performance. However, if you include multiple input nodes that
access the same input source (for example, a WebSphere
MQ queue),
the order in which the messages are processed cannot be guaranteed. If you
want the message flow to process messages in the order in which they are received,
this option is not appropriate.
If you are not concerned about message
order, consider using additional instances of the same message flow rather
than multiple input nodes. If you set the Additional
Instances property of the message flow when you deploy it to
the broker, multiple copies of the message flow are started in the execution
group. This is the most efficient way of handling multiple instances.
The Scribble sample uses
two input nodes: an MQInput node and a Real-timeInput node. This enables
the sample's message flow to accept input across both WebSphere MQ transport
and native IP connections.