Notions de base des rulechains

La section Rulechains est le cœur du traitement des données basé sur des règles dans optiCLOUD. Même si de nombreuses fonctions de la plateforme sont configurées via des interfaces telles que Devices, Dashboards ou Automation, la logique de réaction et de traitement proprement dite se trouve souvent dans la Rule Engine.

Les modifications apportées aux rulechains doivent donc toujours être effectuées avec prudence. Des règles erronées ou des connexions ambiguës peuvent avoir des répercussions directes sur le traitement des données, les alarmes, les notifications ou les intégrations.

Vue d'ensemble

Dans la vue d'ensemble de la section Rulechains, les rulechains existantes sont affichées sous forme de tableau.

Vue d'ensemble de la section Rulechains

Quelques principes de base s'appliquent :

La Root Rule Chain est la chaîne d'entrée active centrale.
Elle est généralement nettement mise en évidence.
Les autres rulechains ne sont d'abord que des modèles ou des chaînes partielles.
Elles ne deviennent actives que lorsqu'elles sont définies comme Root Rule Chain ou intégrées dans une rule chain active.

La barre d'actions permet de :

créer
importer
exporter
supprimer

des rulechains.

Principe de base de la Rule Engine

La Rule Engine est le mécanisme central de traitement des événements et des données dans optiCLOUD. Elle traite notamment :

les données de télémétrie
les attributs
les requêtes RPC
les événements du cycle de vie des appareils
les événements basés sur REST
les fichiers
les logs

La Rule Engine repose sur trois éléments principaux :

le message comme événement ou objet de données entrant
le nœud de règle comme étape de traitement
la chaîne de règles comme assemblage de plusieurs nœuds en un workflow

Messages

Un message de la Rule Engine est une structure de données sérialisable et immuable qui décrit un événement dans le système.

En voici des exemples :

télémétrie entrante d'un appareil
mise à jour d'attribut
appel RPC
événement d'entité tel que créé, mis à jour ou supprimé
événements d'état tels que connecté, déconnecté, actif ou inactif

Un message contient :

l'ID du message
l'expéditeur ou l'origine du message
le type de message
les données utiles sous forme de corps JSON
les métadonnées sous forme de paires clé-valeur supplémentaires

Nœuds de règle

Un nœud de règle traite à chaque fois un message entrant et en génère un ou plusieurs messages sortants ou des actions.

Selon son type, un nœud peut :

filtrer des messages
transformer des données
enrichir des données
créer ou supprimer des alarmes
appeler des systèmes externes
transmettre des messages à d'autres nœuds

Chaque nœud constitue ainsi une unité logique clairement délimitée au sein de la rulechain.

Connexions et relations

Les nœuds de règle sont reliés entre eux par des connexions. Chaque connexion possède un type de relation qui détermine à quelle condition un message est transmis au nœud suivant.

Les types de relation courants sont :

Success
Failure
True
False

Selon le type de nœud, d'autres désignations peuvent aussi être utilisées, par exemple :

Post Telemetry
Attributes Updated
Entity Created

La signification fonctionnelle d'un flux de données peut ainsi être représentée directement dans la rulechain.

Principales caractéristiques des rulechains

Les rulechains offrent plusieurs propriétés essentielles dans optiCLOUD :

Traitement en flux pour les données et événements entrants immédiats
Structure de workflow grâce à des nœuds de règle reliés entre eux
Flexibilité grâce à des nœuds intégrés et à des scripts personnalisés
Capacité d'intégration via HTTP, MQTT, Kafka ou d'autres interfaces
Réactivité pour les alarmes, les notifications et les actions subséquentes

Il est ainsi possible de modéliser aussi bien de simples règles de filtrage que des processus d'automatisation complexes.

Cas d'utilisation typiques

Les rulechains sont utilisées pour des tâches telles que :

validation et transformation des données entrantes
gestion des alarmes et notifications, p. ex. en cas de dépassement de seuil par le haut ou par le bas
surveillance du cycle de vie des appareils
intégration de systèmes externes ou transmission à des pipelines de données ou plateformes externes
commande à distance via RPC

Fonctionnement dans l'éditeur

Lorsqu'une rulechain est ouverte, un éditeur low-code basé sur des nœuds et des connexions apparaît. Sa conception rappelle des outils tels que Node-RED ou n8n.

Cet éditeur permet de définir :

quels messages entrent dans la chaîne
quelles conditions sont vérifiées
quelles actions sont déclenchées
comment les chemins de succès ou d'erreur se poursuivent

Rulechain de base

La rulechain de base, ou Root RuleChain, constitue la base du traitement des données et est déjà configurée par défaut. Elle se présente comme suit :

Chaque message entrant provenant d'un appareil ou d'ailleurs parvient dans le système via le nœud Input et est immédiatement transmis à un Message Type Switch qui détermine, d'après le type de message, comment le message doit être traité ensuite.

À partir de là, le traitement se ramifie en plusieurs chemins spécialisés :

Traitement de base des messages

Type de message	Transmission	Nœud récepteur	Explication
Post Attributes	vers Save Client Attributes	Save Client Attributes	Les messages de ce type sont traités afin d'enregistrer durablement les attributs des appareils dans la base de données.
Post Telemetry	vers Save to Time Series	Save to Time Series	Les données de télémétrie, telles que les valeurs de capteurs, sont enregistrées sous forme de séries temporelles dans la base de données.
RPC Request from Device	transmis à Log RPC	Log RPC from Device	Sert à la surveillance ou au dépannage des appels RPC entrants provenant de l'appareil.
RPC request to the device	vers RPC Call Request	RPC Call Request	Déclenche un Remote Procedure Call en direction de l'appareil.
Send alarms	vers Save Alarms	Save Alarms	Les états d'alarme sont enregistrés dans la base de données.
Other	vers Log Other	Log Other	Les types de messages non pris en charge ou inconnus sont journalisés pour le suivi.
Blob storage request	vers Process Blob Storage	Blob Storage Processing	Démarre le traitement des téléversements de fichiers dans le stockage de fichiers.

Exemple

Pour les premières étapes pratiques, un exemple simple et clair est recommandé. Un tel exemple est l'alerte en cas de dépassement de température.

Suite avec la règle d'exemple :