Using MQTT with IBM Integration Bus

Use IBM® Integration Bus to connect to applications and devices that send and receive messages by using the MQ Telemetry Transport (MQTT) messaging protocol.

You can use the built-in MQTTSubscribe and MQTTPublish nodes in IBM Integration Bus to support the following operations:
  • Receive a message that is published to one or more topics hosted on an MQTT server.
  • Publish a message, from within a flow, to a topic hosted on an MQTT server.
All MQTT messages must conform to the MQTT Protocol Specification.

You can create message flows to receive an MQTT message by using the MQTTSubscribe node to subscribe to one or more topics on an MQTT server. You can send an MQTT message by using the MQTTPublish node in your message flow to publish messages to a topic on an MQTT server. In receiving and sending messages, the MQTT nodes behave like MQTT clients.

For more information on how to use the MQTT nodes in a message flow, including how to use the Security identity node property to connect to an MQTT server that requires authentication, see the following reference topics:

An example of how an MQTT application or device can be integrated with other technologies by using IBM Integration Bus is available on GitHub as part of the mqtt-client-connector project. The example includes a simple Java™ application that simulates a blood pressure monitor, and a message flow that performs content-based routing. The message flow includes an MQTTSubscribe node to subscribe to the messages published by the blood pressure monitor application, and MQTTPublish nodes to publish blood pressure monitor readings to different topics. For more details on this example, see the MQTT Connector Sample on GitHub.

Client IDs for MQTT connections

The client ID is a string, 1 - 23 characters long, which identifies an MQTT client to an MQTT server. Each client that is connecting to a single server must use a unique client ID. If a client attempts to connect to an MQTT server with a client ID that is already in use, the server disconnects the first client connection, and the new connection is accepted instead.

When you develop a message flow, you must assign a unique client ID to each MQTT node in that message flow. Client IDs can be managed operationally by overriding the value in the BAR file, or by attaching a node policy. For more information, see mqsiapplybaroverride command and Operational policy. At deployment time, you must ensure that any MQTT nodes that are connecting to the same server have unique client IDs.

If you specify a client ID that is longer than 23 characters, only the last 23 characters are used when the MQTT node connects to the MQTT server.

Scalability

To increase the rate at which a message flow can process messages that are received by an MQTTSubscribe node, use the Additional instances property. This property increases the number of threads that the node can use to process messages, within a single integration server. Increasing the value of this property does not affect the number of input connectors available to receive messages.

Deploying the message flow across extra integration servers does not improve scalability, for the following reasons:
  • The MQTTSubscribe node in each integration server will use the same client ID, and the MQTT server only allows one instance to connect with a particular client ID.
  • If you configure each node instance to use a unique client ID, and to subscribe to the same topic, every message that is published to that topic is sent to all subscribers.