Qu’est-ce que l’activateur Fabric ?

Fabric Activateur est un moteur de détection d’événements sans code qui transforme les flux de données en actions automatisées. Il déclenche automatiquement des actions lorsque des modèles ou des conditions spécifiques sont détectés dans les sources de données. Il surveille en permanence ces sources de données avec une faible latence (sous-seconde pour les règles sans état sur les données de streaming) et lance des actions lorsque des seuils sont atteints ou 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 règles au cœur de la pile 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, pilotée par les événements, où les flux de données sont en continu, et Activateur prend des décisions basées sur des évaluations avec état des données d’événement en quasi-temps réel.

Diagramme montrant l'architecture de Fabric Activator.

  • 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, points de terminaison personnalisés et autres sources). 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 Fabric ou Azure événements ou un activateur écoutant un rapport Power BI ou 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 basés sur un identificateur partagé (par exemple, tous les événements du même appareil sont regroupés à l’aide device_idde , ou tous les événements de station de vélo sont regroupés par bikepoint_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 conditions qui suivent les modifications au fil du temps, 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, dataflows, fonctions de données utilisateur (UDF) (préversion), ou définitions de tâche Spark dans Fabric.

    • Actions externes via Power Automate.

    • Envoyez 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 définies par les capacités 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

Déployez des instances d’activateur pour chaque espace de travail et liez-les à des sources de données spécifiques. Plusieurs activateurs peuvent surveiller le même flux. Vous pouvez donc utiliser 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 modèle tarifaire offre une efficacité économique pour les scénarios de détection intermittente. Pour connaître les contraintes connues, consultez les limitations de l’activateur.

Points d’intégration dans Real-Time intelligence

Composant Interaction avec l’activateur
Flux d’événements Envoie des données en temps réel à Activateor afin qu’elles puissent surveiller les modèles et les conditions. La création d’alertes et la gestion des règles sont également incorporées directement dans Eventstream, afin que les utilisateurs puissent créer et gérer des règles dans le contexte.
Activateur Peut créer de nouveaux événements, tels que des données enrichies ou des données classées, qui déclenchent un autre activateur.
Canalisation Cible des déclencheurs de règles de l’activateur, qui automatisent le processus en aval.
Power BI Sert de source d’événement pour les règles d'activation sur les visuels de rapport, y compris la détection des lignes du visuel de tableau. Consomme également le résultat des pipelines ou notebooks déclenchés pour les visualisations en temps réel.
Power Automate Automatise les tâches à l’aide de flux de travail prédéfinis ou personnalisés lorsque des événements se produisent.
événements Fabric Fournit des événements qui se produisent dans Fabric comme l’actualisation d’un modèle sémantique ou l’échec d’un pipeline.
Cahiers L’activateur peut déclencher l’exécution du notebook.
Définition de la tâche Spark L’activateur peut déclencher l’exécution du travail Spark.
Fonction de données utilisateur L'activateur peut déclencher l'exécution de la fonction de données des utilisateurs (UDF) (aperçu).
Flux de données L’activateur peut déclencher l’exécution du flux de données lorsqu’une condition de règle est remplie.

Activateur en tant qu’orchestrateur

Pour utiliser l’activateur efficacement dans des systèmes à grande échelle, coordonnez son fonctionnement avec d’autres composants Fabric. Optimisez les paramètres en fonction de la quantité de données que vous traitez, du nombre d’objets que vous suivez et de la complexité de vos 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 (rapide), é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 :

Modèle Description du flux
Ingestion → Détection → Transformation Les événements circulent d’Eventstream vers Activateor, ce qui déclenche un pipeline pour enrichir ou déplacer les données.
Ingestion → Détection → Notification L’activateur déclenche Power Automate pour envoyer des alertes ou mettre à jour le statut dans Teams, Outlook ou ServiceNow.
Ingestion → Détection → Évaluation du modèle L'activateur active un notebook pour évaluer un modèle ML ou effectuer des analyses avancées en fonction des anomalies en temps réel.
Boucle de commentaires avec activateur (planifié) Les résultats générés par l'activateur (par exemple, les étiquettes de confidentialité) sont intégrés aux règles de l'activateur, ce qui permet une automatisation enrichie sur le plan sémantique.

Concepts principaux

Fabric Activateur surveille en permanence vos données et détecte rapidement quand les conditions que vous définissez sont remplies, même si les données changent au fil du temps. À 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 réponse aux transitions d’état.

Utilisez les concepts suivants pour générer et déclencher des actions et des réponses automatisées dans Fabric Activateur.

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

Fabric Activateur 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 Blob Storage). 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 Activateur 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 Fabric. Par exemple, les événements d'élément dans l'espace de travail Fabric sont des événements discrets de Fabric 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, Azure Blob Storage événements sont déclenchés lorsqu’un client crée, remplace ou supprime un objet blob.
  • Événements professionnels. Vous pouvez définir des alertes directement sur les événements métier pour automatiser les actions lorsque des conditions métier spécifiques se produisent.
  • Ontology des entités métier Fabric (préversion). Les règles peuvent être définies sur les entités métier d’ontologie pour lancer des alertes et des actions automatisées, ce qui permet de prendre des décisions opérationnelles basées sur des données modélisées.
  • 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. L’activateur s’intègre également aux Power BI service pour avertir les utilisateurs lorsqu’une nouvelle ligne apparaît dans un visuel de table dans un rapport publié, ce qui permet aux règles de surveiller les modifications au niveau visuel et de déclencher des notifications ou des actions en aval.
  • Fabric Real-Time tableau de bord.

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 Activateur, 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’activateur prend également en charge la création de règles basées sur les résultats des requêtes SQL de Fabric Data Warehouse (aperçu). Vous pouvez définir des règles qui évaluent une requête SQL selon une planification configurable, vérifient les conditions par rapport au jeu de résultats et déclenchent des actions lorsque des conditions sont remplies. Cette fonctionnalité permet de surveiller les données de l’entrepôt sans nécessiter de sources de diffusion en continu. Pour plus d’informations, consultez Créer une règle d’alerte sur une requête SQL.

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.

Les règles sont évaluées en continu. Pour les règles sans état sur les données de streaming, le système répond en millisecondes. Pour les règles avec agrégations, la latence dépend de la fenêtre de retour en arrière et de la tolérance d’arrivée tardive. Pour plus d’informations, consultez Latence dans Activateor.

Actions

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

  • Fabric pipelines (pour le déplacement des données, l’enrichissement).
  • Fabric notebooks (pour l'évaluation du machine learning et les diagnostics).
  • Fabric jobs Spark (pour les tâches par lots/streaming).
  • Fabric dataflows (pour le déplacement et la transformation des données).
  • Fonctions de données utilisateur Fabric (préversion) (pour la logique métier personnalisée avec du code).
  • Flux de travail Power Automate (pour l'intégration des processus métiers).
  • Notifications de Teams (utilisant la messagerie basée sur des modèles).
  • Notifications par e-mail.

Lorsqu’une règle est déclenchée, Activateur envoie des informations sur ce qui s’est passé et continue la surveillance sans attendre la fin de l’action. Cette approche permet des flux de travail évolutifs qui peuvent traiter plusieurs événements simultanément.

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

Les propriétés proviennent 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, vous pouvez référencer cette propriété 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étrospective est la durée des données historiques analysées par Activator pour évaluer une règle. Il garantit qu’il existe suffisamment de données passées 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.

Vous déterminez la période de rétroaction par :

  • Comment définir 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, comme 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.

Supposons que vous définissez la règle suivante :

  • É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 Activateur doit analyser une fenêtre plus large de données historiques (par exemple, une période de recherche de six heures pour une moyenne de trois heures). Ce processus garantit qu’il y a suffisamment de données pour calculer la moyenne de trois heures à un moment donné, même si les données arrivent avec un certain retard 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

Utilisez des règles basées sur des attributs 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 effectue le suivi des ID d’objet 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 le système considère uniquement les objets pertinents et actuellement actifs 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 le système évalue uniquement ces objets ayant une activité récente.

Le nombre d'ID d'objet distincts (nombre de paquets) que vous suivez dans la fenêtre de rétroaction détermine également des limites.

Cas d’utilisation courants

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

  • 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’est pas 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.

Contenu connexe

  • Last updated on