Applies to Ready! API 2.0, last modified on May 16, 2017

Internet of Things (or IoT) is a network of physical devices connected to each other. Devices and equipment —things— send data to other devices that can collect this data, or use the data which other devices collected. The most common example would be a smart room thermostat, or a washing machine which reports its status through the Wi-Fi network.

For now, Ready! API supports the MQTT protocol, which allows to connect these things to each other.

About MQTT Protocol

According to specifications, MQTT is a client, server publish, and subscribe messaging transport protocol. It is lightweight, open, simple, and easy to implement. These characteristics make it ideal for use in many situations. You can use it in constrained environments such as communications in Machine-to-Machine (M2M) and Internet-of-Things (IoT) contexts, which use a small code footprint and network bandwidth is at a premium.

Client-Server Message Pattern

MQTT uses the Publish and Subscribe model to deliver all messages to interested clients. In this model, a publishing client (publisher) does not send requests directly to each receiving client. Instead, it publishes the message to the server known as the broker, which, in turn, forwards data to the clients that need them.

Therefore, the publisher can send only messages to the specific address. Otherwise, it would have to update the list of clients constantly and send multiple messages on every update. This may be impossible for publishers with low processing power or limited Internet connection.

Clients, who want to receive data, subscribe to the broker. Their subscription model allows them to subscribe to specific topics and, thus, filter out the messages they do not need.

MQTT Protocol: The Publish and Subscribe model

Both publishers and clients send a Connect message to work with the broker.

This solution also allows the broker to send messages if the publisher has connection issues, or if the client is offline when a message is published. The broker stores the message and sends it to all newly connected subscribers. A Will message is sent when the publisher has connection issues.

MQTT Topics

In MQTT, topics are strings which the broker uses to filter messages sent to each connected client. You do not need to initialize a topic before posting or subscribing to it.

A topic consists of levels separated by a slash. Topics are case-sensitive. Each topic level must have at least one character.

Here are some sample topics:

sample/myhome/mysensor
sample/myhome/be89bc84-224e-11e6-b67b-9e71128cae77
sample/MyHome/mysensor
sample/MyHome/MyRoom

A client can subscribe to several topics at once.

MQTT supports the following wildcards when subscribing to topics:

Symbol Description
+

Substitutes a level. For example, subscribing to sample/+/mysensor will return messages posted to topics 1 and 3 from the example above.

#

Substitutes a level and all its sublevels. For instance, subscribing to sample/# will return messages posted to all topics.

Will Message

MQTT ensures the message delivery even if the network issues happen, or if the publisher suddenly goes offline. This mechanism is known as a Will message. The Will message is sent to the broker when the publisher connects, and it is published in case the publisher disconnects without sending the Disconnect message. If this happens, the Will message will be posted, and the broker will send it to all subscribed clients.

MQTT Testing in Ready! API

Ready! API can act both as a publisher and as a client for your MQTT broker. You can use it to create functional and load tests.

MQTT Functional Testing

To test the broker's functionality, you can create a SoapUI NG test that uses the MQTT-related test steps.

Test Step Description
Publish Using MQTT

Establishes MQTT connection and publishes the message specified in test step properties.

Receive MQTT Message

Subscribes to an MQTT topic and waits for the first message posted to it.

Drop MQTT Connection

Simulates the publisher disconnecting from the server, either in the normal way by sending a Disconnect message, or unexpectedly.

The connection is established directly to the broker, so you do not need to use set up a WebSocket server for this.

Ready! API cannot mock MQTT broker, so you will need to use a real MQTT broker.

For more information about configuring SoapUI NG tests for MQTT, see the MQTT Testing Tutorial.

MQTT Load Testing

To see how your MQTT broker performs under heavy load, you create a load test for it in LoadUI NG. You first create an MQTT test case in SoapUI NG, and then create a load test that simulates this test case with dozens and hundreds of virtual users running on a locally or remote machines. See the LoadUI NG tutorial.

See Also

MQTT Testing Tutorial
About Assertions