Qu’est-ce que l’activateur de tissu ? Transformer des flux de données en actions automatisées

Fabric Activateor est un moteur de détection d’événements sans code et à faible latence qui déclenche automatiquement des actions lorsque des modèles ou des conditions spécifiques sont détectés dans les sources de données. Les principales fonctionnalités sont les suivantes :

Il surveille en permanence ces sources de données avec une latence inférieure à la seconde et lance des actions lorsque des seuils sont atteints ou que des modèles spécifiques sont détectés. Ces actions peuvent inclure l’envoi d’e-mails ou de notifications Teams, le lancement de flux Power Automate ou l’intégration à des systèmes tiers.

Architecture principale

L’Activateur est le moteur de détection d’événements et de gestion des règles au cœur de l’ensemble d'intelligence Fabric Real-Time. Architecturalement, il agit en tant qu’observateur intelligent : consommation de flux de données à haute vitesse, évaluation des conditions de règle en quasi temps réel et lancement d’actions en aval automatisées en fonction des changements dans les états des événements.

Il s’intègre à une architecture réactive basée sur les événements où les données circulent en continu et les décisions sont prises en fonction des évaluations avec état des données d’événement en quasi-temps réel.

• sources d’événements

  L’activateur se connecte directement aux flux d’événements, qui ingèrent des données provenant de différents producteurs (Azure Event Hubs, appareils IoT, point de terminaison personnalisé, etc.). Ces flux servent de source d’événements, et Activateur peut s’abonner à un ou plusieurs flux d’événements pour observer les modifications de données. D’autres sources d’événements peuvent être des événements Fabric ou Azure ou un activateur à l’écoute d’un rapport Power BI ou d’un tableau de bord Real-Time.

• Événements et objets

  Les événements sont des enregistrements individuels (par exemple, un signal de télémétrie ou une suppression de fichier) reçus via eventstream. Ces événements sont regroupés en objets en fonction d’un identificateur partagé (par exemple, bikepoint_id, device_id). Les règles sont ensuite évaluées par objet, ce qui permet une détection affinée (par exemple, par capteur ou par ressource).

• Règles et conditions

  Chaque activateur inclut une ou plusieurs règles, qui sont évaluées en continu. Ces règles peuvent être des comparaisons simples (value < threshold) ou des expressions avec état telles que BECOMES, DECREASES, INCREASES, EXIT RANGE ou l’absence de données (heartbeat). L’activateur garantit le suivi de l’état par objet, ce qui permet la détection de modèles complexes au fil du temps.

• Actions

  Lorsqu’une condition de règle est satisfaite, l’activateur peut déclencher :

  • pipelines, notebooks, fonctions ou définition de tâche Spark dans Fabric.

  • Actions externes via Power Automate.

  • Envoyer un message Teams à un individu, un groupe ou un canal

  • Envoyer un e-mail

• Gestion des alertes et tests de règles

  Activateur fournit des estimations d’aperçu et d’impact avant l’activation des règles, montrant la fréquence à laquelle une règle aurait été déclenchée sur des données historiques. Ces fonctionnalités permettent d’empêcher le courrier indésirable et le sur-déclenchement des alertes. En interne, les transitions d’état sont gérées pour supprimer le bruit (par exemple, une valeur doit franchir un seuil, pas seulement rester sous celle-ci).

• Surveillance et contrôle des coûts

  Vous n’entraînez des coûts que lorsque les activateurs s’exécutent activement. Les instances d’activateur sont limitées aux capacités de Fabric et peuvent être surveillées via l’espace de travail. Les journaux d’exécution et les données de télémétrie sont disponibles via des flux d’événements et des sorties de pipeline.

Modèle de déploiement

Les instances d’activateur sont déployées par espace de travail et liées à des sources de données spécifiques. Plusieurs activateurs peuvent surveiller le même flux, en activant des évaluations de règles parallèles pour des fonctions métier distinctes. Étant donné que l’activateur est lié à la capacité, la tarification de paiement à l’utilisation s’applique uniquement lorsque les règles s’exécutent activement, ce qui offre une efficacité économique pour les scénarios de détection intermittente.

Points d’intégration dans Real-Time intelligence

Activateur en tant qu’orchestrateur

L’utilisation efficace de Activateor dans les architectures en temps réel de niveau entreprise nécessite une orchestration intentionnelle entre les composants Microsoft Fabric et le réglage des performances pour le volume d’événements, la cardinalité des objets et la complexité des règles. Cette section explique comment orchestrer Activateor avec d’autres services et comment optimiser la logique de détection et le comportement d’exécution pour prendre en charge une automatisation à faible latence et économique à grande échelle.

L’activateur joue un rôle central dans les pipelines pilotés par les événements en évaluant les données au point d’arrivée et en déclenchant des actions en aval. Les modèles d’orchestration classiques sont les suivants :

Concepts principaux

Microsoft Fabric Activator fonctionne comme un moteur de règles haute performance et conscient de l'état, conçu pour une évaluation à faible latence des événements en streaming. À son cœur, Activateur traite les événements en temps réel émis via eventstream, évalue les conditions de règle par objet logique et lance des actions en aval en réponse aux transitions d’état. Pour obtenir une vue d’ensemble de Fabric Activator, consultez Introduction à Fabric Activator.

Les concepts suivants sont utilisés pour générer et déclencher des actions et des réponses automatisées dans Fabric Activateor.

Sources d’événements et événements

Fabric Activateor traite toutes les sources de données comme des flux d’événements. Un événement représente une observation sur l’état d’un objet et inclut généralement un identificateur pour l’objet, un horodatage et des valeurs des champs surveillés.

Les événements ingérés dans Activateur proviennent des suivants :

• Eventstream, qui prend en charge plusieurs sources en amont (par exemple, Azure Event Hubs, IoT Hub, déclencheurs stockage Blob). Un eventstream est un type d’élément spécifique dans Microsoft Fabric, qui vous permet d’ingérer, de transformer et d’acheminer des événements en temps réel sans écrire de code. Fabric Activateor surveille le flux d’événements et prend automatiquement des mesures lorsque des modèles ou des seuils définis sont détectés. L’activateur peut également s’abonner à deux flux d’événements ou plus pour observer les modifications de données. Les flux d’événements varient en fréquence. Par exemple, les capteurs IoT émettent des événements plusieurs fois par seconde, et les systèmes logistiques génèrent des événements sporadiquement, par exemple lorsque les packages sont analysés aux emplacements d’expédition.
• Événements de toile. Par exemple, les événements d’élément d’espace de travail Fabric sont des événements Fabric discrets qui se produisent lorsque des modifications sont apportées à votre espace de travail Fabric. Ces modifications incluent la création, la mise à jour ou la suppression d’un élément Fabric.
• Événements Azure. Par exemple, les événements stockage Blob Azure sont déclenchés lorsqu’un client crée, remplace, supprime un objet blob, etc.
• Rapport Power BI. Dans ce cas, les événements sont des observations périodiques basées sur la planification d’actualisation d’un modèle sémantique Power BI (anciennement appelé jeu de données). Ces observations peuvent se produire quotidiennement ou hebdomadairement, formant un flux d’événements à déplacement lent.
• Tableau de bord Fabric Real-Time.

Chaque événement contient :

• Un timestamp
• Charge utile (données structurées ou semi-structurées)
• Un ou plusieurs attributs utilisés pour l’identification d’objet (par exemple, device_id, bikepoint_id)

Objets

Dans Fabric Activateor, les entités que vous surveillez sont appelées objets métier, qui peuvent être physiques ou conceptuels. Par exemple, citons des objets physiques tels que des congélateurs, des véhicules, des packages et des utilisateurs, ainsi que des objets conceptuels tels que des campagnes publicitaires, des comptes clients, des sessions utilisateur.

Pour modéliser un objet métier dans Activateor, vous connectez un ou plusieurs flux d’événements, sélectionnez une colonne pour servir d’ID d’objet et spécifiez les champs que vous souhaitez traiter comme des propriétés de l’objet.

L’instance d’objet terme fait référence à un exemple spécifique d’un objet métier tel qu’un congélateur, un véhicule ou une session utilisateur particulière. En revanche, l’objet fait généralement référence à la définition ou à la classe générale (par exemple, congélateur en tant que type). Le terme population est utilisé pour l’ensemble complet d’instances d’objet surveillées.

La création d’objet est implicite : activateur regroupe les événements à l’aide d’une clé d’objet désignée. Les règles sont limitées aux objets, ce qui signifie que toute logique d’évaluation est prenant en charge les objets et indépendante entre les instances. Par exemple, une règle surveillant bikepoint_id crée des évaluations logiques distinctes pour chaque station de vélo unique.

Règles

Les règles définissent les conditions que vous souhaitez détecter sur vos objets et les actions à entreprendre lorsque ces conditions sont remplies. Par exemple, une règle sur un objet congélateur peut détecter quand la température augmente au-dessus d’un seuil sûr et envoyer automatiquement une alerte par e-mail au technicien affecté.

Les règles de l’activateur peuvent être sans état ou avec état :

• Les règles sans état évaluent chaque événement isolé (par exemple, valeur < 50).
• Les règles avec état conservent la mémoire entre les événements par objet (par exemple, value DECREASES, BECOMES, EXIT RANGE)

L’évaluation avec état s’appuie sur :

• Détection delta : effectue le suivi des modifications entre les valeurs d’événement antérieures et actuelles.
• Séquencement temporel : évalue les conditions temporelles comme l’absence d’événements (détection de pulsations)
• Transitions d’état : les règles se déclenchent uniquement lors de l’entrée dans un nouvel état, empêchant les déclenchements répétés dans des conditions inchangées

Chaque condition de règle est compilée dans un graphique d’exécution qui est évalué en continu, en mémoire et presque instantanément. Le système est optimisé pour la latence de décision en sous-seconde après l’arrivée de l’événement.

Actions

Lorsque les conditions d’une règle sont remplies et qu’une action est lancée, la règle est dite activée. Les cibles prises en charge pour les actions sont les suivantes :

• Infrastructures de pipelines (pour le déplacement et l'enrichissement des données)
• Notebooks Fabric (pour le machine-learning scoring, les diagnostics)
• Tâches Spark Fabric (pour les tâches par lots/en continu)
• Fonctions fabric (pour une logique métier personnalisée avec du code)
• Flux de travail Power Automate (pour l’intégration de processus métier)
• Notifications Teams (en utilisant la messagerie basée sur des modèles)
• Notifications par e-mail

L’activateur émet un message de déclencheur avec l’état de l’objet actuel et les métadonnées de règle, et les actions ne sont pas bloquantes, c’est-à-dire que l’activateur n’attend pas la fin des actions pour activer des flux asynchrones évolutifs.

Propriétés

Les propriétés sont des champs ou attributs spécifiques d’un objet métier que vous souhaitez surveiller. Il peut s’agir de caractéristiques physiques ou conceptuelles, telles que :

• Température d’un package
• État d’une expédition
• Solde d’un compte client
• Score d’engagement d’une session utilisateur

Ils sont dérivés de flux d’événements, qui sont des flux continus de données provenant de sources telles que des capteurs IoT, des rapports Power BI ou d’autres systèmes.

Lorsque vous définissez un objet métier dans Activateor, vous connectez un ou plusieurs flux d’événements, choisissez une colonne pour servir d’ID d’objet et sélectionnez d’autres colonnes à traiter comme des propriétés de cet objet. Vous pouvez créer des règles sur ces propriétés pour suivre les modifications au fil du temps, détecter quand une propriété dépasse un seuil ou se situe en dehors d’une plage, ou déclencher des actions telles que les alertes, les flux de travail ou les notifications.

Les propriétés sont également utiles lorsque vous souhaitez réutiliser la logique entre plusieurs règles. Par exemple, sur un objet congélateur, vous pouvez définir une propriété qui calcule une moyenne de température sur une période d’une heure. Une fois définie, cette propriété peut être référencée dans plusieurs règles, telles que celles qui détectent la surchauffe, les fluctuations de température ou les seuils de maintenance, sans dupliquer la logique. En centralisant la logique dans les propriétés, vous facilitez la gestion, la cohérence et la mise à jour de vos règles au fil du temps.

Période de rétrospective

La période de rétrospection fait référence à la durée des données historiques qu'Activator analyse pour évaluer une règle. Il garantit que suffisamment de données passées sont disponibles pour détecter avec précision des modèles ou des agrégations de calcul comme des moyennes, même si les données arrivent en retard ou de manière irrégulière.

La période de rétrospective est déterminée par :

• Définition de la règle, par exemple, si elle nécessite l’analyse des tendances, la détection d’anomalies ou la comparaison des valeurs au fil du temps.
• Volume de données entrantes, telles que le nombre d’événements par seconde dans le flux d’événements.

Envisagez une opération logistique pharmaceutique transportant des packages de médicaments dans une chaîne froide. L’objectif est de recevoir une alerte lorsqu’un package devient trop chaud.

Imaginons que la règle soit définie à

• Évaluer la température moyenne de chaque paquet sur une fenêtre de trois heures
• Déclencher une alerte si la température moyenne dépasse 8 °C

Pour calculer cette règle avec précision, Fabric Activator doit analyser une fenêtre plus large de données historiques, en particulier une période de rétrospection de six heures. Il garantit que suffisamment de données sont disponibles pour calculer la moyenne de trois heures à un moment donné, même si les données arrivent avec un certain délai ou une irrégularité.

La période de recherche est essentielle pour permettre une détection rapide et précise des conditions, en particulier dans les scénarios où les modèles de données évoluent au fil du temps.

Identifiants d'objets distincts et actifs

Les règles basées sur les attributs sont utilisées pour surveiller la façon dont les attributs spécifiques d’un objet changent au fil du temps. Dans l’exemple de logistique pharmaceutique, chaque package de médicaments est représenté par un ID d’objet unique et le système reçoit des lectures de température périodiques pour chaque package.

Pour évaluer efficacement ces règles, Fabric Activator suit les ID d'objets actifs, c’est-à-dire les objets pour lesquels les événements arrivent dans la période de rétrospection définie. Ce comportement garantit que seuls les objets actifs pertinents et actuellement actifs sont pris en compte lors de l’application de règles.

Par exemple, une station de péage peut suivre les véhicules (ID d’objet) au fur et à mesure qu’ils passent. Chaque véhicule génère des événements (par exemple, des analyses d’entrée et de sortie), et seuls les objets ayant une activité récente sont considérés comme actifs et évalués par le système.

Il existe également des limites en fonction du nombre d’ID d’objet distincts (nombre de paquets) suivis dans la fenêtre de rétrospection.

Cas d’utilisation courants

Voici quelques scénarios réels dans lesquels vous pouvez utiliser Fabric Activateor :

• Lancez automatiquement des campagnes publicitaires lorsque les ventes du même magasin diminuent, ce qui contribue à améliorer les performances dans des emplacements sous-performants.
• Informez les gestionnaires de magasins d’épicerie de déplacer les aliments des congélateurs défectueux avant qu'ils ne se gâtent.
• Déclencher des flux de travail de sensibilisation personnalisés lorsque le parcours d’un client entre des applications, des sites web ou d’autres points de contact indique une expérience négative.
• Lancez de manière proactive les flux de travail d’investigation quand l’état d’une expédition n’a pas été mis à jour dans un délai défini, ce qui permet de localiser les packages perdus plus rapidement.
• Alerter les équipes de compte lorsque les clients sont en retard de paiement, en utilisant des seuils personnalisés pour le délai ou les soldes impayés par clients.
• Surveillez l’intégrité du pipeline et réexécutez automatiquement les tâches, ou alertez les équipes lorsque des anomalies ou des échecs sont détectés.

Étape suivante

Consultez Tutorial: Créer et activer une règle pour l'activateur de Fabric.