About this task
You might find this useful in the following situations:
- The message flow provides common processing for messages that
are received from multiple transports. For example, a single message
flow might handle:
- Data in messages received from WebSphere® MQ,
and therefore through a WebSphere MQ queue
and an MQInput node
- Messages that are received from native IP connections (a Real-timeInput node)
- You need to set standard properties on the MQInput node if input messages:
- are predefined, and
- are all received from 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. This requirement
is not necessary for self-defining messages.
- Each input node in a message flow causes the integration node
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 integration node, multiple
copies of the message flow are started in the integration server.
This is the most efficient way of handling multiple instances.