Using more than one input node

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 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 integration server. This is the most efficient way of handling multiple instances.