Messaging Connections
Using the cloud service’s UI (or API Libraries on-premises), an application can use connections to Azure IoT Hub, AWS IoT Core, Azure, Kafka, and REST, as illustrated in the following diagram. These connections 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 connections are intended for use in real-time analytics.
Connections to external event hubs 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 ScaleOut Digital Twins 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 connection 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 connection.
The following sections describe how to define and configure connections to each of the above message 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.