Integrate and extend your AirVantage platform
Here we give you an overview of what you can do with the AirVantage Cloud Connector via a simple use case: getting raw data from your system, then send them to a MQTT topic.
We’ll explain all the technical aspects needed for a robust, secure & reliable interface:
- principles & best practices
- configuration & authentication
- how to get messages
This section explains why to use the Cloud connector, what it is and the available options.
The Cloud Connector is an AMQP queue mechanism which allows:
When setting a queue on AirVantage, you have to define the notification you want: operations, data, alert or usages.
According the data, you can filter the data to send them in one of several queues.
For example, you want to send data for your internal application and for a partner application. You can send all your data to your internal application (default) and filter to send not-confidential data to your partner.
Have a look to this page about reliability and which explains how messages are stacked on the producer side (AirVantage) if no consumer gets the messages.
If no acknowledgement, the message is sent after a delay.
Don’t use a cron task to reinitialize your connection as it is not efficient.
This section explains how to configure your client to be robust, reliable and secure. It is the most important section in this page.
Supply the following information using the CRM
In all the cases, SSL is enabled.
You can require to use your own AMQP server. In this case, you have to supply these information as well:
- AMQP hostname
- queue name
Current connector limitations:
- use default exchange “”, with queue name as routing key
- vhost should start with “/”
- only connect with TLSv1.2
When subscribing to the Cloud Connector option, Sierra Wireless will supply these parameters:
5671(for a SSL connection)
You have to use the following parameters when creating the factory to create your queue consumer:
Acknowledgements with stale delivery tags will not be sent. Applications that use manual acknowledgements and automatic recovery must be capable of handling redeliveries.
This section explains you how to consume the messages from the server in order to support a high load of messages.
AMQP consumer prefetch setting
The prefetch value is used to specify how many messages are sent to the consumer at the same time. It is used to get as much out of your consumers as possible.
Default prefetch setting gives clients an unlimited buffer, meaning that the server by default sends as many messages as it can to any consumer that looks ready to accept them. Messages that are sent are cached by the client library (in the consumer) until it has been processed. Prefetch limits how many messages the client can receive before acknowledging a message.
A typical mistake is to have an unlimited prefetch (default setting), where one client receives all messages and runs out of memory and crashes, and then all messages are re-delivered again.
Of course, caching messages on the consumer side has repercussions. All pre-fetched messages are removed from the queue and become invisible to other consumers. Hence setting prefetch count to a high value will skew message distribution between different consumers. A too small prefetch count, on the other hand, may hurt performance since the server is most of the time waiting to get permission to send more messages.
- If you have one single or few consumers processing messages quickly, we recommend prefetching many messages at once (e.g anything between 30 and 50).
- If you have many consumers, and a short processing time, we recommend a lower prefetch value than for one single or few consumers (e.g anything between 20 and 30).
- If you have many consumers, and/or a long processing time, we recommend you to set prefetch count to 1 so that messages are evenly distributed among all your workers.
model.BasicQos(0, 50, false);
For more details :
BasicConsume(queueName, noAck, consumer)
Why don’t you use auto-acknowledgment? because if for any reason, the data is not correctly processed on the consumer side and the message is lost (application reboot), this message and its content will be definitively lost. If you use manual acknowledge, until the message content is not processed and stored adn then acknowledged, AirVantage will be able to send it again after the reconnection.
See Message Format section for a description of the message format.
Both two formats must be supported because you can receive messages with the two formats.
AMQP2MQTT : This java sample read whatever comes from the data push connector to a MQTT topic. It is structurated to show you the best practices. About AMQP, have a look to / src / main / java / amqptomqttadapter / amqp: