Overview

Once real-time digital twin models have been deployed to the ScaleOut ScaleOut Digital Twins™ service (or on-premises with ScaleOut StreamServer), the next step is to connect data sources such as IoT devices to the execution platform for processing. This is accomplished using connectors to various popular event hubs or by making web service calls to the ScaleOut REST service.

You also can use a connector to integrate a digital twin model with an Azure Digital Twins model for the purpose of retrieving and persisting properties stored in digital twin instances. Please see the topic Azure Digital Twins Integration for a full description of this feature.

You can also persist both real-time and simulation digital twin properties to a SQL Server or SQLite database and optionally retrieve theri properties when digital twins are created.

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.

image1

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.

Persistence Connectors

Persistence connectors let you connect the ScaleOut Digital Twins service with other services to periodically persist digital twin instances and their state properties. Once a connection has been established, digital twin instances can optionally retrieve their state properties from the connected service when they are created. Coonectors are provided to connect either to Azure Digital Twin service or to a SQL database:

  • An Azure Digital Twins connector lets you connect the ScaleOut Digital Twins service with your account in the Azure Digital Twins service. Once the connection has been established, instances will automatically persist their state properties to the Azure Digital Twins service.

  • SQL Persistence providers allow you to connect to a SQLite or SQL Server database to persist digital twin instances.