Message validation in runtime

Introduction

In this tutorial, you'll learn how to validate messages (events) that are sent to your AsyncAPI application.

Background context

Message validation can be performed at both the producer and consumer levels. Message validation requires the participation of the producer, consumer, and broker. We will learn how to validate messages at the consumer level by discarding invalid messages based on the parameters provided.

You will be using the Eclipse Mosquitto broker. The MQTT protocol provides a lightweight method of messaging using a publish/subscribe model. You will also use an MQTT client that runs an MQTT library and connects to an MQTT broker over a network. Here producers and consumers are MQTT clients. The producer and consumer labels refer to whether the client is sending or receiving messages.

In the previous tutorial, you generated an application that uses Glee framework. Now you will be validating the messages that you will be sending to your application using a Mosquitto broker and an MQTT client.

Validate messages

In this step, you will send a message to your application using an MQTT broker and check the errors logged when you accidentally send an invalid message.

1. Start your generated application:

1npm run dev

2. Send a message:

1mqtt pub -t 'light/measured' -h 'test.mosquitto.org' -m '{"id": 1, "lumens": "3", "sentAt": "2017-06-07T12:34:32.000Z"}'

Go back to the previous terminal and check if your application logged the streetlight condition you just sent, with errors related to the invalid message. You should see something displayed in the terminal similar to the following:

1lightMeasured was received from mosquitto:
2{ id: 1, lumens: '3', sentAt: '2017-06-07T12:34:32.000Z' }
3x You have received a malformed event or there has been error processing it. Please review the error below:
4TYPE should be integer
5 
6  1 | {
7  2 |   "id": 1,
8> 3 |   "lumens": "3",
9    |             ^^^ 👈🏽  type should be integer
10  4 |   "sentAt": "2017-06-07T12:34:32.000Z"
11  5 | }
12 
13ONEOF should match exactly one schema in oneOf
14 
15> 1 | {
16    | ^
17> 2 |   "id": 1,
18    | ^^^^^^^^^^
19> 3 |   "lumens": "3",
20    | ^^^^^^^^^^
21> 4 |   "sentAt": "2017-06-07T12:34:32.000Z"
22    | ^^^^^^^^^^
23> 5 | }
24    | ^^ 👈🏽  oneOf should match exactly one schema in oneOf

Here, you can see that the property lumens has type integer, but you are sending a message with type string:

1  message:
2        name: lumensInfo
3        payload:
4          type: object
5          properties:
6            id:
7              type: integer
8              minimum: 0
9              description: Id of the streetlight.
10            lumens:
11              type: integer
12              minimum: 0
13              description: Light intensity measured in lumens.

3. Send a correct message to your application:

1mqtt pub -t 'light/measured' -h 'test.mosquitto.org' -m '{"id": 1, "lumens": 3, "sentAt": "2017-06-07T12:34:32.000Z"}'

You can see that your generated application received a message in the terminal:

1lightMeasured was received from mosquitto:
2{ id: 1, lumens: 3, sentAt: '2017-06-07T12:34:32.000Z' }
3Streetlight with id "1" updated its lighting information to 3 lumens at 2017-06-07T12:34:32.000Z.

Such a terminal message indicates that your message is valid and the application received it correctly.

Summary

In this tutorial, you learned how to connect your generated application to an MQTT broker, send messages through it, identify when an invalid message is sent to your application, and how to correct an invalid message.

Next steps

Now that you've completed this tutorial, enjoy our AsyncAPI message validation guide.