以下是我对您的结论的评论。
我从下图中了解到,每当事物通过消息代理向平台发送数据时,事物影子和规则引擎部分都会同时获取相同的传感器数据并对其进行处理。
事物影子中的更改可以触发在规则引擎中注册的操作。有与事物影子相关联的特定主题,您可以订阅规则引擎,以便执行一个或多个操作作为响应。
事物影子系统订阅消息代理并获取传感器数据,更新其影子演员。影子端还负责存储传感器数据,例如事件溯源机制。
您可以使用REST API或专用 MQTT 主题来更新设备影子,以在特定影子主题上发布。正如您所说,影子本身并不构成事件源系统,而是与物理设备关联的数据模型的表示。
但是,您可以创建一个规则来侦听一个或多个影子实例上的更改,并以时间序列方式将更改注册到 DynamoDB 中。然后,您将拥有一个事件源系统,允许您存储设备在任意时间内发送的先前状态或更改。
事物影子系统不执行任何规则,它仅用于执行事件溯源并在虚拟事物参与者中保持最后已知状态。
事物影子保持云中物理设备的期望和报告状态。它不执行规则,而是在影子内发生事件时发出有关 MQTT 主题的消息。然后,规则引擎可以捕获这些消息以执行操作。
同样的传感器数据也是规则引擎的入站数据。规则引擎只是处理流数据并决定如何处理流数据的 ECA(事件条件操作)类型系统。这意味着每个传入的数据最终都将在规则引擎部分进行处理。
默认情况下,规则引擎不会侦听 MQTT 主题,因此不会侦听设备发送到设备网关的数据。您必须在规则引擎中注册您想收听的主题及其相关操作。
除此之外,规则引擎允许您在ANSI SQL中描述您的规则,这意味着您可以指定数据的来源(FROM
在您的 SQL 语句中)、您有兴趣捕获的 JSON 有效负载中的特定字段(SELECT
),以及一个可选条件,指定应在什么条件下触发规则 ( WHERE
)。
device/+/telemetry
侦听虚构主题并有兴趣捕获接收到的有效负载中的所有字段的规则示例如下:
SELECT * FROM device/+/telemetry
请注意如何将+
其用作任何设备标识符的占位符。