This document describes the available connectors:
- HTTP Callback (Webhook) mechanism if the connection is initiated from an alert rule.
- Google Pub Sub Connector if your application is hosted on Google Cloud
- AWS Kinesis Stream/Firehose Connector if your application is hosted on Amazon Web Services.
- Micorsoft Azure EventHub Connector if your application is hosted on Microsoft Azure.
- AMQP Connector if you have an application to open the stream and handle a high level of messages
Many public APIs use callbacks to notify API consumers of specific events. For example, if you configure the callback url when creating an alert rule, an HTTP request will be sent to a specified URL when the alert is raised.
This is a stateless procedure and messages are sent in JSON format with the content-type “application/json”. Messages sent to an unreachable endpoint will be lost.
To receive messages throughout HTTP callbacks, you can contact our support team or use the APIs likely to raise events.
The Google Pub sub mechanism is a publish-subscribe connector for applications hosted on the Google Cloud Platform.
AirVantage publishes the new operations status, the alerts and the new raw data in your topic using the fully-documented JSON format below. No password is stored on Sierra Wireless’ side: AirVantage uses IAM authentication. Messages are sent using https. Optimized to handle a high volume of messages (retry mechanism, bulk send). You can easily operate and scale your application. You maintain control over your topic: you can stop or unauthorize Sierra Wireless’s access to your topic at any time using Google Cloud Platform, as explained here .
Have a look to the Google Howto for a full description about how to configure this connector.
The AWS Kinesis mechanism is a publish-subscribe connector for applications hosted on the Amazon Web Services Cloud.
AirVantage publishes the new operations status, the alerts and the new raw data in your stream using the fully-documented JSON format below. No password is stored on Sierra Wireless’ side: AirVantage uses IAM authentication.
Messages are sent using https. Optimized to handle a high volume of messages (retry mechanism, bulk send). You can easily operate and scale your application. You maintain control over your topic: you can stop or unauthorize Sierra Wireless’s access to your topic at any time using AWS.
This connector uses a random partition key to evenly spread the load across destination shards.
Kinesis supplies several great features if you have a huge amount of data to send but on the other hand, it can be complex to implement. Here some tips to help you to make your choice. Select kinesis if:
Using Firehose connector, you can send event to some third party tool like QLikview, Splunk, …
Go to the Kinesis Howto for a full description about how to configure the Kinesis Stream connector.
Go to the Firehose Howto for a full description about how to configure the Kinesis Firehose connector.
The Mircosoft Azure EventHub stream is a producer-consumer connector for applications hosted on the Microsoft Azure Services Cloud.
AirVantage publishes the new operations status, the alerts and the new raw data in your stream using the fully-documented JSON format
. No password is stored on Sierra Wireless’ side: AirVantage uses a connection string
you have to generate in the Microsoft Azure Console in order to give access to AirVantage.
Messages are sent using https. Optimized to handle a high volume of messages (retry mechanism, bulk send), you can easily operate and scale your application, you maintain control over your stream: you can stop or unauthorize Sierra Wireless’s access to your topic at any time using the Microsoft Azure Administration console.
EventHub is limited to event lesser than 256k (see this page , section
Batch event send operations
). So you may avoid to push over-sized data.Other limitations can be applied according to the selected offer (see Event Hubs Pricing page).
Have a look to the Azure EventHub Howto for a full description about how to configure this connector.
The Advanced Message Queuing Protocol (AMQP) is an open standard for passing messages between applications. Visit official AMQP site for further information. Currently the version 0.9.1 of the protocol is used.
To connect to the broker you will need some configuration elements in your remote system:
car1.engine.sparkplug.state, car1.engine.speed
to specify the data (contact your support team if you want to activate this option).AirVantage can provide an AMQP broker for our partners to consume event messages from our server. Configuration elements are provided by Sierra Wireless. Please contact our support team.
Permissions will be set to “basic.get” and “basic.consume” only.
Once your connection established to your AMQP broker, it will remain alive. All messages put into the queue will be available for a week. After this period the messages will expire if they are not consumed.
The standard operating mode of AMQP message consumption is a “Push” mode. Once the remote system is connected to the broker and bound to a queue, any new message will be received automatically.
During the message consumption by a remote service, the message needs to be acknowledged. Each time a message is acknowledged, it will be removed definitively from the queue. If a message is consumed but not acknowledged, it will be put back in the queue and then available again.
Tip: avoid using the client API “auto acknowledgment” system.
See the sample code with a tutorial and read it carefully to know all the best practices.