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.
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.
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.
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.
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:
A client can subscribe to several topics at once.
MQTT supports the following wildcards when subscribing to topics:
Substitutes a level. For example, subscribing to
Substitutes a level and all its sublevels. For instance, subscribing to
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.
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.
To test the broker's functionality, you can create a SoapUI NG test that uses the MQTT-related test steps.
|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.
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.