Messaging Connectors
Using the cloud service’s UI (or API Libraries on-premises), an application can use these connectors to create connections to Azure IoT Hub, AWS IoT Core, Azure, Kafka, and REST, as illustrated in the following diagram. These connectors deliver incoming messages from data sources to real-time digital twin instances and return feedback and commands back to data sources from these instances. Message connectors are intended for use in real-time analytics.
Connectors are implemented in a scalable manner with multiple connections to a cluster of servers in the execution platform. This maximizes overall message-processing throughput and minimizes latency. Likewise, the cloud service deploys REST servers behind a load-balancer to scale delivery of REST-based messages from client applications.
When possible, all accumulated messages will be received by a connector and delivered to a real-time digital twin instance as a group for handling with a single call to the message-processing method. This minimizes message handling latency and maximizes overall throughput.
To ensure that messages are not lost, the Azure IoT Hub and Kafka connections do not acknowledge the receipt of messages from data sources until they have been processed within the execution platform. The REST API synchronously awaits the processing of an event message before returning to the client application. Note that the platform’s message-processing architecture implements “at least once” delivery, and applications need to expect possible re-delivery if a server within the platform fails during processing prior to acknowledging reception to the connector.
The following sections describe currently available connectors and the parameters they require. Many of these parameters are unique to their respective event hubs. This documentation assumes a working knowledge of each event hub’s architecture and usage.
Tip
To verify any of the below connection types, you’ll need to create and load a digital twin execution environment. This is described in further detail in API Libraries, but as a quick reminder, you need to define three classes: a message, a message processor, and a digital twin model. These classes lay the foundation for the digital twin execution environment.