Was ist der Fabric Activator? Transformieren von Datenströmen in automatisierte Aktionen

Fabric-Aktivator ist ein No-Code- und Low-Latency-Ereigniserkennungsmodul, das Automatisch Aktionen auslöst, wenn bestimmte Muster oder Bedingungen in Datenquellen erkannt werden. Die wichtigsten Funktionen sind:

Sie überwacht diese Datenquellen kontinuierlich mit Untersekundenlatenz und initiiert Aktionen, wenn Schwellenwerte erfüllt werden oder bestimmte Muster erkannt werden. Diese Aktionen können das Senden von E-Mails oder Teams-Benachrichtigungen, das Starten von Power Automate-Flüssen oder die Integration in Drittanbietersysteme umfassen.

Kernarchitektur

Aktivator ist das Ereigniserkennungs- und Regelmodul im Herzen von Fabric Real-Time Intelligence Stack. Architekturell fungiert sie als intelligenter Beobachter – verbrauchen Hochgeschwindigkeitsdatenströme, bewerten Regelbedingungen in nahezu Echtzeit und initiieren automatisierte downstream-Aktionen basierend auf Änderungen in Ereigniszuständen.

Sie passt zu einer reaktiven ereignisgesteuerten Architektur, in der Daten kontinuierlich fließen, und Entscheidungen werden basierend auf zustandsbezogenen Auswertungen von Ereignisdaten in nahezu Echtzeit getroffen.

• Ereignisquellen

  Aktivator stellt eine direkte Verbindung mit Eventstreams her, die Daten von verschiedenen Produzenten aufnehmen (Azure Event Hubs, IoT-Geräte, benutzerdefinierter Endpunkt usw.). Diese Datenströme dienen als Quelle von Ereignissen, und der Aktivator kann einen oder mehrere Ereignisstreams abonnieren, um Datenänderungen zu beobachten. Andere Ereignisquellen können Fabric- oder Azure-Ereignisse oder ein Aktivator sein, der einen Power BI-Bericht oder ein Real-Time-Dashboard überwacht.

• Ereignisse und Objekte

  Ereignisse sind einzelne Datensätze (z. B. ein Telemetriesignal oder ein Dateiabwurf), die über den Eventstream empfangen werden. Diese Ereignisse werden basierend auf einem gemeinsamen Bezeichner (zum Beispiel bikepoint_id, device_id) in Objekten gruppiert. Regeln werden dann pro Objekt ausgewertet und ermöglichen eine feinkörnige Erkennung (z. B. pro Sensor oder pro Ressource).

• Regeln und Bedingungen

  Jeder Aktivator enthält eine oder mehrere Regeln, die kontinuierlich ausgewertet werden. Diese Regeln können einfache Vergleiche (value < threshold) oder zustandsbehaftete Ausdrücke wie BECOMES, DECREASES, INCREASES, EXIT RANGE oder fehlende Daten (Heartbeat) sein. Aktivator stellt die Zustandsnachverfolgung pro Objekt sicher, wodurch die komplexe Mustererkennung im Laufe der Zeit ermöglicht wird.

• Aktionen

  Wenn eine Regelbedingung erfüllt ist, kann Aktivator Folgendes auslösen:

  • Pipelines, Notizbücher, Funktionen oder Spark-Job-Definition in Fabric.

  • Externe Aktionen über Power Automate.

  • Senden einer Teams-Nachricht an eine Einzelne, Gruppe oder einen Kanal

  • E-Mail senden

• Warnungsverwaltung und Regeltests

  Der Aktivator bietet Vorschauen und Schätzungen der Auswirkungen, bevor Regeln aktiviert werden. Zudem wird angezeigt, wie oft eine Regel in der Vergangenheit ausgelöst worden wäre. Diese Funktionen helfen, Warnungsspam und Überauslösung zu verhindern. Intern werden Zustandsübergänge verwaltet, um Rauschen zu unterdrücken (z. B. muss ein Wert einen Schwellenwert überschreiten, nicht nur unter ihm bleiben).

• Überwachung und Kostenkontrolle

  Sie verursachen nur Kosten, solange die Aktivatoren aktiv sind. Aktivatorinstanzen sind auf Fabric-Kapazitäten beschränkt und können über den Arbeitsbereich überwacht werden. Laufzeitprotokolle und Telemetrie sind über Ereignisströme und Pipelineausgaben verfügbar.

Bereitstellungsmodell

Aktivatorinstanzen werden pro Arbeitsbereich bereitgestellt und an bestimmte Datenquellen gebunden. Mehrere Aktivatoren können denselben Datenstrom überwachen und parallele Regelauswertungen für unterschiedliche Geschäftsfunktionen ermöglichen. Da der Aktivator an die Kapazität gebunden ist, wird eine nutzungsabhängige Preisgestaltung nur dann angewendet, wenn Regeln aktiv ausgeführt werden, was eine Kosteneffizienz für zwischenzeitliche Erkennungsszenarien bietet.

Integrationspunkte innerhalb der Real-Time Intelligenz

Aktivator als Orchestrator

Die effektive Verwendung von Aktivierern in Echtzeitarchitekturen auf Unternehmensniveau erfordert absichtliche Orchestrierung in Microsoft Fabric-Komponenten und Leistungsoptimierungen für Ereignisvolumen, Objektkardinalität und Regelkomplexität. In diesem Abschnitt erfahren Sie, wie Sie aktivator mit anderen Diensten koordinieren und wie Sie Erkennungslogik und Laufzeitverhalten optimieren, um die kostengünstige Automatisierung im großen Maßstab zu unterstützen.

Der Aktivator spielt eine zentrale Rolle in ereignisgesteuerten Pipelines, indem Daten bei deren Ankunft ausgewertet und nachgeschaltet Aktionen ausgelöst werden. Typische Orchestrierungsmuster umfassen:

Kernkonzepte

Der Microsoft Fabric-Aktivator fungiert als leistungsstarkes, zustandsfähiges Regelmodul, das für die Auswertung von Streamingereignissen mit geringer Latenz ausgelegt ist. Im Kern verarbeitet Aktivator Echtzeitereignisse, die über eventstream ausgegeben werden, wertet Regelbedingungen pro logisches Objekt aus und initiiert downstream-Aktionen als Reaktion auf Zustandsübergänge. Eine Übersicht über den Fabric Activator finden Sie in der Einführung in den Fabric Activator.

Die folgenden Konzepte werden verwendet, um automatisierte Aktionen und Antworten in Fabric Activator zu erstellen und auszulösen.

Ereignisquellen und Ereignisse

Der Fabric-Aktivator behandelt alle Datenquellen als Ereignisströme. Ein Ereignis stellt eine Beobachtung über den Status eines Objekts dar und enthält in der Regel einen Bezeichner für das Objekt, einen Zeitstempel und Werte der zu überwachenden Felder.

Ereignisse, die in Aktivator aufgenommen werden, stammen aus:

• Eventstream, der mehrere Upstreamquellen unterstützt (z. B. Azure Event Hubs, IoT Hub, Blob Storage Trigger). Ein Eventstream ist ein bestimmter Elementtyp in Microsoft Fabric, mit dem Sie Ereignisse in Echtzeit aufnehmen, transformieren und weiterleiten können, ohne Code zu schreiben. Der Fabric-Aktivator überwacht den Ereignisstream und führt automatisch Maßnahmen aus, wenn definierte Muster oder Schwellenwerte erkannt werden. Aktivator kann auch zwei oder mehr Ereignisstreams abonnieren, um Datenänderungen zu beobachten. Ereignisstreams variieren in der Häufigkeit. IoT-Sensoren geben z. B. Ereignisse mehrmals pro Sekunde aus, und Logistiksysteme generieren sporadisch Ereignisse, z. B. wenn Pakete an Versandstandorten gescannt werden.
• Fabric-Ereignisse. Fabric-Arbeitsbereichselementereignisse sind beispielsweise diskrete Fabric-Ereignisse, die auftreten, wenn Änderungen an Ihrem Fabric-Arbeitsbereich vorgenommen werden. Zu diesen Änderungen gehören das Erstellen, Aktualisieren oder Löschen eines Fabric-Artikels.
• Azure-Ereignisse. Beispielsweise werden Azure Blob Storage-Ereignisse ausgelöst, wenn ein Client ein Blob erstellt, ersetzt, löscht usw.
• Power BI-Bericht. In diesem Fall sind Ereignisse regelmäßige Beobachtungen basierend auf dem Aktualisierungszeitplan eines Power BI-Semantikmodells (früher als Dataset bezeichnet). Diese Beobachtungen können täglich oder wöchentlich auftreten und einen langsam bewegenden Ereignisstream bilden.
• Fabric Real-Time Dashboard.

Jedes Ereignis enthält:

• Zeitstempel
• Eine Nutzlast (strukturierte oder halbstrukturierte Daten)
• Ein oder mehrere Attribute, die für die Objektidentifikation verwendet werden (z. B. device_id, bikepoint_id)

Objekte

In Fabric Activator werden die entitäten, die Sie überwachen, als Geschäftsobjekte bezeichnet, die entweder physisch oder konzeptionell sein können. Beispiele sind physische Objekte wie Gefriergeräte, Fahrzeuge, Pakete und Benutzer sowie konzeptionelle Objekte wie Werbekampagnen, Kundenkonten, Benutzersitzungen.

Um ein Geschäftsobjekt im Aktivator zu modellieren, verbinden Sie einen oder mehrere Ereignisstreams, wählen eine Spalte aus, die als Objekt-ID dienen soll, und geben Sie die Felder an, die Sie als Eigenschaften des Objekts behandeln möchten.

Die Objektinstanz bezieht sich auf ein spezifisches Beispiel für ein Geschäftsobjekt, z. B. einen bestimmten Gefrierschrank, ein Fahrzeug oder eine Benutzersitzung. Im Gegensatz dazu bezieht sich das Objekt in der Regel auf die allgemeine Definition oder Klasse (z. B. Gefrierfach als Typ). Der Begriff Population wird für die Gesamtheit der überwachten Objektinstanzen verwendet.

Die Objekterstellung ist implizit: Aktivator gruppiert Ereignisse mithilfe eines bestimmten Objektschlüssels. Regeln gelten für Objekte, was bedeutet, dass alle Auswertungslogik objektfähig und unabhängig von Instanzen ist. Beispielsweise erstellt ein Regelüberwachungssystem bikepoint_id unterschiedliche logische Auswertungen für jede einzigartige Fahrradstation.

Regeln

Regeln definieren die Bedingungen, die Sie für Ihre Objekte erkennen möchten, und die Aktionen, die ausgeführt werden sollen, wenn diese Bedingungen erfüllt sind. Beispielsweise kann eine Regel für ein Gefrierobjekt erkennen, wenn die Temperatur über einem sicheren Schwellenwert steigt und automatisch eine E-Mail-Benachrichtigung an den zugewiesenen Techniker sendet.

Regeln im Aktivator können zustandslos oder zustandsorientiert sein.

• Zustandslose Regeln werten jedes Ereignis isoliert aus (z. B. Wert < 50).
• Zustandsbehaftete Regeln behalten den Speicher über Ereignisse pro Objekt hinweg (z. B. Wert VERKLEINERN, WIRD, EXIT RANGE)

Die zustandsbehaftete Bewertung basiert auf:

• Deltaerkennung: Verfolgt Änderungen zwischen vorherigen und aktuellen Ereigniswerten.
• Zeitliche Sequenzierung: Wertet zeitbasierte Bedingungen wie das Fehlen von Ereignissen (Takterkennung) aus.
• Zustandsübergänge: Regeln werden nur beim Betreten in einen neuen Zustand ausgelöst, hindern wiederholte Feuerungen unter unveränderten Bedingungen

Jede Regelbedingung wird in einen Ausführungsgraphen kompiliert, der kontinuierlich, im Arbeitsspeicher und nahezu sofort ausgewertet wird. Das System ist für eine Entscheidungsfindungslatenz im Subsekundenbereich nach Eintreffen eines Ereignisses optimiert.

Aktionen

Wenn die Bedingungen einer Regel erfüllt sind und eine Aktion initiiert wird, wird die Regel als aktiviert bezeichnet. Zu den unterstützten Zielen für Aktionen gehören:

• Fabric-Pipelines (für Datenübertragung und Datenanreicherung)
• Fabric-Notizbücher (für die Bewertung von Maschinellem Lernen, Diagnose)
• Fabric-Spark-Aufträge (für Batch-/Streamingaufträge)
• Fabric-Funktionen (für benutzerdefinierte Geschäftslogik mit Code)
• Power Automate-Flows (zur Integration von Geschäftsprozessen)
• Teams-Benachrichtigungen (mithilfe von vorlagenbasiertem Messaging)
• E-Mail-Benachrichtigungen

Aktivator gibt eine Triggernachricht mit den aktuellen Objektstatus- und Regelmetadaten aus, und Aktionen sind nicht blockiert, d. h. aktivator wartet nicht auf Abschluss von Aktionen, um skalierbare asynchrone Flüsse zu ermöglichen.

Eigenschaften

Eigenschaften sind bestimmte Felder oder Attribute eines Geschäftsobjekts, das Sie überwachen möchten. Dies können physikalische oder konzeptionelle Merkmale sein, z. B.:

• Temperatur eines Pakets
• Status einer Sendung
• Saldo eines Kundenkontos
• Engagementbewertung einer Benutzersitzung

Sie werden von Eventstreams abgeleitet, die fortlaufende Datenflüsse aus Quellen wie IoT-Sensoren, Power BI-Berichten oder anderen Systemen sind.

Wenn Sie ein Geschäftsobjekt im Aktivator definieren, verbinden Sie einen oder mehrere Ereignisstreams, wählen eine Spalte aus, die als Objekt-ID dienen soll, und wählen Sie andere Spalten aus, die als Eigenschaften dieses Objekts behandelt werden sollen. Sie können Regeln für diese Eigenschaften erstellen, um Änderungen im Laufe der Zeit nachzuverfolgen, zu erkennen, wann eine Eigenschaft einen Schwellenwert überschreitet oder außerhalb eines Bereichs liegt, oder Aktionen wie Warnungen, Workflows oder Benachrichtigungen auslösen.

Eigenschaften sind auch hilfreich, wenn Sie Logik für mehrere Regeln wiederverwenden möchten. Beispielsweise können Sie in einem Gefrierobjekt eine Eigenschaft definieren, die einen Temperaturdurchschnitt über einen Zeitraum von einer Stunde berechnet. Nach der Definition kann auf diese Eigenschaft in mehreren Regeln verwiesen werden, z. B. auf solche, die Überhitzung, Temperaturschwankungen oder Wartungsschwellen erkennen , ohne die Logik zu duplizieren. Durch die Zentralisierung von Logik in Eigenschaften machen Sie die Verwaltung Ihrer Regeln einfacher, konsistenter und ermöglichen eine einfachere Aktualisierung im Laufe der Zeit.

Rückblickperiode

Der Betrachtungszeitraum bezieht sich auf die Dauer der Verlaufsdaten, die der Aktivator analysiert, um eine Regel auszuwerten. Es stellt sicher, dass genügend vergangene Daten verfügbar sind, um Muster oder Berechnungsaggregationen wie Mittelwerte genau zu erkennen, auch wenn Daten verspätet oder unregelmäßig eintreffen.

Der Lookbackzeitraum wird durch Folgendes bestimmt:

• Wie die Regel definiert wird, z. B. ob eine Analyse von Trends, das Erkennen von Anomalien oder das Vergleichen von Werten im Laufe der Zeit erforderlich ist.
• Das Volumen eingehender Daten, z. B. die Anzahl der Ereignisse pro Sekunde im Eventstream.

Betrachten Sie einen pharmazeutischen Logistikbetrieb, der Arzneimittelpakete in einer Kältekette transportiert. Ziel ist es, eine Benachrichtigung zu erhalten, wenn ein Paket zu warm wird.

Angenommen, die Regel ist definiert für:

• Bewertung der Durchschnittstemperatur jedes einzelnen Pakets über einen Zeitraum von drei Stunden
• Auslösen einer Warnung, wenn die Durchschnittliche Temperatur 8°C überschreitet

Um diese Regel genau zu berechnen, muss der Fabric-Aktivator ein breiteres Fenster von historischen Daten analysieren, insbesondere einen Sechs-Stunden-Lookbackzeitraum. Es stellt sicher, dass genügend Daten verfügbar sind, um den Drei-Stunden-Durchschnitt zu einem beliebigen Zeitpunkt zu berechnen, auch wenn Daten mit einer verzögerungs- oder unregelmäßigen Verschiebung eingehen.

Der Lookbackzeitraum ist unerlässlich, um die rechtzeitige und genaue Erkennung von Bedingungen zu ermöglichen, insbesondere in Szenarien, in denen sich Datenmuster im Laufe der Zeit entwickeln.

Unterschiedliche, aktive Objekt-IDs

Regeln, die auf Attributen basieren, werden verwendet, um zu überwachen, wie sich bestimmte Attribute eines Objekts im Laufe der Zeit ändern. Im Pharmalogistikbeispiel wird jedes Arzneimittelpaket durch eine eindeutige Objekt-ID dargestellt, und das System empfängt regelmäßige Temperaturwerte für jedes Paket.

Um diese Regeln effektiv auszuwerten, verfolgt Fabric Activator aktive Objekt-IDs, d. h. Objekte, für die Ereignisse innerhalb des definierten Lookbackzeitraums ankommen. Dieses Verhalten stellt sicher, dass nur relevante, derzeit aktive Objekte beim Anwenden von Regeln berücksichtigt werden.

Beispielsweise kann eine Mautstation Fahrzeuge (Objekt-IDs) nachverfolgen, während sie durchfahren. Jedes Fahrzeug generiert Ereignisse (z. B. Eingangs- und Ausgangsscans), und nur die Objekte mit der letzten Aktivität werden vom System als aktiv und ausgewertet.

Es gibt auch Grenzwerte, die auf der Anzahl der unterschiedlichen Objekt-IDs (Anzahl der Pakete) basieren, die im Lookbackfenster nachverfolgt werden.

Gängige Anwendungsfälle

Hier sind einige reale Szenarien, in denen Sie Fabric-Aktivator verwenden können:

• Automatische Auslösung von Anzeigenkampagnen, wenn der Umsatz in bestehenden Filialen abnimmt, was dazu beiträgt, die Leistung an Standorten mit schlechter Leistung zu steigern.
• Benachrichtigen Sie die Filialleiter, Lebensmittel aus defekten Gefrierschränken zu verlagern, bevor der Verderb eintritt.
• Lösen Sie Kampagnen für gezielte Ansprache aus, wenn die Interaktion eines Kunden mit Apps, Websites oder anderen Touchpoints auf eine negative Erfahrung hindeutet.
• Proaktive Einleitung von Untersuchungsworkflows, wenn der Status einer Sendung nicht innerhalb eines definierten Zeitrahmens aktualisiert wurde, was dazu beiträgt, verloren gegangene Pakete schneller zu finden.
• Benachrichtigen Sie Kontoteams, wenn Kunden in Rückstände fallen, wobei angepasste Schwellenwerte für Zeit- oder ausstehende Saldos pro Kunde verwendet werden.
• Überwachen Sie den Pipelinestatus, und führen Sie fehlerhafte Aufträge automatisch erneut aus, oder benachrichtigen Sie Teams, wenn Anomalien oder Fehler erkannt werden.

Nächster Schritt

Siehe Lernprogramm: Erstellen und Aktivieren einer Fabric-Aktivatorregel.