{{announcement.body}}
{{announcement.title}}

Building a Serverless IoT Backend Integration

DZone 's Guide to

Building a Serverless IoT Backend Integration

Serverless IoT backend integration using Kumologica, AWS Lambda and MQTT.

· Integration Zone ·
Free Resource

Having a lightweight protocol which delivers messages over low bandwidth or unreliable networks is the foundation for a system that can facilitate the transports of data in near real time.

MQTT is one such protocol which designed to overcome following limitations:

Network limitations:

  • Limited network bandwidth
  • High latency
  • Fragile connections

Device limitation:

  • Limited memory
  • Processing capabilities

MQTT is an open OASIS and ISO standard lightweight, publish-subscribe network protocol that transports messages between devices. The protocol usually runs over TCP/IP; however, any network protocol that provides ordered, lossless, bi-directional connections can support MQTT.

In this article, we will be building a serverless backend service on AWS lambda which will integrate with a MQTT broker for publishing the passenger service request to the right group of taxi drivers. We will be building the passenger request API using Kumologica. Kumologica is a free low-code development tool to build serverless integrations. You can learn more about Kumologica in this Medium article or subscribe to our YouTube channel for the latest videos.

Use Case

In this use case we are having a passenger making a request from his mobile app for a taxi. The mobile app makes a call to the Kumologica passenger requester API which accepts the request and verifies in the database for the availability of the cab. Based on the availability status and the type of taxi requested by the passenger the flow will route the message to publish in the appropriate taxi topic on MQTT broker. The driver app will receive the message from the MQTT broker.

Taxi API architectue

Note: In this article, we are not covering the section where the driver app accepts the request and sends the confirmation to the passenger. If you are interested in this section please let us know and we will put another article covering this use case.


Prerequisite

  1. Kumologica designer installed in your machine. https://kumologica.com/download.html
  2. https://www.hivemq.com/public-mqtt-broker/

3. DynamoDB table with the following records.


Implementation

In order to implement the Passenger request API we will be following the below-given logic.

API logic

1. Open Kumologica Designer, click the Home button and choose Create New Kumologica Project.

Enter the name (for example PassengerRequestAPI), select directory for project and switch Source into From Existing Flow.

2. Copy and Paste the following flow.

3. Press Create Button.

Install MQTT Node

MQTT node is a contribution node and must be explicitly installed in Kumologica Designer. Press Add more nodes button located in the bottom left corner of the designer. You will be presented a screen with all contribution nodes that are currently available. Choose MQTT node, press Install button. After a few seconds, the plugin will be installed and you will be prompted to restart Kumologica Designer. MQTT node will be located under the new category: Platforms after a restart.

MQTT notde

You should be seeing two flows as given below on the designer canvas.

The first flow is the API endpoint with the resource path /passenger/request. This flow accepts the request from the mobile app and drops the message to Amazon SQS queue (PassengerSQS). This is done as an event-driven model in order to acknowledge back (to the mobile app) quickly.

First flow

The second flow is having the logic to fetch the driver data from the DynamoDB based on the area code (area_code primary key) which is passed as request by the passenger. The flow picks the message from the SQS queue and invokes the DynamoDB. The flow will then check the availability field in the DynamoDB response data. If the availability is having the value as yes then the flow checks for the appropriate MQTT topic to be selected. This done by checking the vehicle_type field in the DynamoDB response data. Based on the vehiclet_type the MQTT node is invoked to publish the message to the MQTT broker topic in Hive.

Note: The configuration for the Hive MQTT broker for this use case is available in the HiveMQTT site.

HiveMQTT flow

Note: To try out the above flow ensure to furnish the settings of MQTT node, SQS node and AWS DynamoDB node with appropriate connection configuration.

Deploy Flow to AWS Lambda

Select CLOUD tab on the right panel of Kumologica designer, choose AWS Profile and press Deploy button. This will trigger build and deployment of flow into AWS Lambda. On the trigger section you need to add to triggers.

  1. API Gateway
  2. Amazon SQS

Amazon SQS

Testing

  1. Paste the below give payload in your postman or any rest client of your choice.
JSON
 




x


1
{
2
 "areacode" : "2331",
3
 "name" : "John",
4
 "seat" : "4"
5
}


Provide the urls as https://<<your hostname>>/test/passenger/request. Method as POST and data format as application/json.

2. Open the HiveMQTT browser client and click connect. Once the status changes to green. Add the topic subscription as given below.

Plain Text
 




xxxxxxxxxx
1


1
testtopic/3seater
2
testtopic/4seater
3
testtopic/5seater


All the 3 topic subscriptions are ready to fetch the messages from the appropriate topic.

3. Now click Send in the postman. Now when you check the HiveMQTT browser client you should see the event in the appropriate topic.

HiveMQTT client

Conclusion

This article presented how easy Kumologica Designer flow orchestrates and integrates with a MQTT broker platform using MQTT node. Within a few minutes we have created and deployed the passenger request Kumologica flow.

Remember Kumologica is totally free to download and use. Go ahead and give it a try, we would love to hear your feedback.

In the meantime, if there is any specific use case that you would like to see in a future article please let us know in the comments section.

Topics:
aws, integration, interner of things, lambda, low code, microservice, mqtt, serverless

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}