Using MQTT with IBM App Connect Enterprise
Use IBM® App Connect Enterprise to connect to applications and devices that send and receive messages by using the MQ Telemetry Transport (MQTT) messaging protocol.
- 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.
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.
An example of how an MQTT application or device can be integrated with other technologies by using IBM App Connect Enterprise 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 Overriding properties at run time with policies. 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.
- 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.