Che cos'è Fabric Activator? Trasformare i flussi di dati in azioni automatizzate

Fabric Activator è un motore di rilevamento eventi senza codice e a bassa latenza che attiva automaticamente le azioni quando vengono rilevati modelli o condizioni specifici nelle origini dati. Le funzionalità principali sono:

Monitora continuamente queste origini dati con latenza di sottosecondo e avvia azioni quando vengono rilevate soglie o modelli specifici. Queste azioni possono includere l'invio di messaggi di posta elettronica o notifiche di Teams, l'avvio di flussi di Power Automate o l'integrazione con sistemi di terze parti.

Architettura di base

Activator è il motore di rilevamento e regole degli eventi al centro dello stack di intelligence di Fabric Real-Time. A livello di architettura, funge da osservatore intelligente, ovvero l'utilizzo di flussi di dati ad alta velocità, la valutazione delle condizioni delle regole quasi in tempo reale e l'avvio di azioni downstream automatizzate in base alle modifiche apportate agli stati degli eventi.

Si integra in un'architettura reattiva e guidata da eventi dove i dati scorrono continuamente, e le decisioni sono prese basandosi su valutazioni con stato dei dati degli eventi in quasi tempo reale.

• origini eventi

  L'attivatore si connette direttamente ai flussi di eventi, che inseriscono dati da vari producer (Hub eventi di Azure, dispositivi IoT, endpoint personalizzato e così via). Questi flussi fungono da origine degli eventi e Activator possono sottoscrivere uno o più flussi di eventi per osservare le modifiche dei dati. Altre sorgenti di eventi potrebbero essere eventi di Fabric o Azure o un attivatore in ascolto di un report di Power BI o di un dashboard di Real-Time.

• Eventi e oggetti

  Gli eventi sono singoli record (ad esempio, un segnale di telemetria o un'eliminazione di file) ricevuti tramite eventstream. Questi eventi vengono raggruppati in oggetti basati su un identificatore condiviso ( ad esempio , bikepoint_id). device_id Le regole vengono quindi valutate per oggetto, consentendo il rilevamento con granularità fine (ad esempio, per sensore o per asset).

• Regole e condizioni

  Ogni attivatore include una o più regole, che vengono valutate continuamente. Queste regole possono essere semplici confronti (value < threshold) o espressioni con stato come BECOMES, DECREASES, INCREASES, EXIT RANGE o assenza di dati (heartbeat). L'attivatore garantisce il rilevamento dello stato per ogni oggetto, che consente il rilevamento di criteri complessi nel tempo.

• Azioni

  Quando viene soddisfatta una condizione della regola, Activator può attivare:

  • pipeline, notebook o definizione di lavoro Spark in Fabric.

    • Azioni esterne tramite Power Automate.
    • Inviare un messaggio di Teams a un singolo, gruppo o canale
    • Invia posta elettronica

• Gestione degli avvisi e test delle regole

  L'attivatore fornisce una stima anticipata e delle valutazioni d'impatto prima dell'attivazione delle regole, mostrando la frequenza con cui una regola sarebbe stata attivata sui dati storici. Queste funzionalità consentono di evitare lo spam degli avvisi e l'attivazione eccessiva. Internamente, le transizioni di stato vengono gestite per eliminare il rumore (ad esempio, un valore deve superare una soglia, non solo rimanere sotto di esso).

• Monitoraggio e controllo dei costi

  I costi vengono addebitati solo quando gli attivatori sono in esecuzione. Le istanze di Activator hanno come ambito le capacità dell'infrastruttura e possono essere monitorate tramite l'area di lavoro. I log di runtime e i dati di telemetria sono disponibili tramite flussi di eventi e output della pipeline.

Modello di distribuzione

Le istanze di Activator vengono distribuite per area di lavoro e associate a origini dati specifiche. Più attivatori possono monitorare lo stesso flusso, abilitando valutazioni parallele delle regole per funzioni aziendali distinte. Poiché l'attivatore è vincolato alla capacità, la tariffazione a consumo si applica solo quando le regole sono attive, offrendo un'efficienza dei costi per gli scenari di rilevamento intermittente.

Punti di integrazione all'interno di Real-Time intelligence

Activator come agente di orchestrazione

L'uso efficace di Activator nelle architetture in tempo reale di livello aziendale richiede orchestrazione intenzionale tra i componenti di Microsoft Fabric e l'ottimizzazione delle prestazioni per il volume di eventi, la cardinalità degli oggetti e la complessità delle regole. Questa sezione illustra come orchestrare Activator con altri servizi e come ottimizzare la logica di rilevamento e il comportamento di runtime per supportare l'automazione a bassa latenza e conveniente su larga scala.

L'attivatore svolge un ruolo centrale nelle pipeline guidate dagli eventi valutando i dati al momento dell'arrivo e attivando azioni downstream. I modelli di orchestrazione tipici includono:

Concetti principali

Microsoft Fabric Activator opera come motore regole con riconoscimento dello stato ad alte prestazioni progettato per la valutazione a bassa latenza degli eventi di streaming. Al suo centro, Activator elabora gli eventi in tempo reale generati tramite eventstream, valuta le condizioni delle regole per ogni oggetto logico e avvia le azioni downstream in risposta alle transizioni di stato. Per una panoramica di Fabric Activator, vedere Introduzione a Fabric Activator.

I concetti seguenti vengono usati per creare e attivare azioni e risposte automatizzate in Fabric Activator.

Origini eventi ed eventi

Fabric Activator considera tutte le origini dati come flussi di eventi. Un evento rappresenta un'osservazione sullo stato di un oggetto e in genere include un identificatore per l'oggetto, un timestamp e i valori dei campi monitorati.

Gli eventi inseriti in Activator hanno origine da:

• Eventstream, che supporta più origini upstream, ad esempio Hub eventi di Azure, Hub IoT, trigger di archiviazione BLOB. Un eventstream è un tipo di elemento specifico in Microsoft Fabric, che consente di inserire, trasformare e instradare eventi in tempo reale senza scrivere codice. Fabric Activator monitora il flusso di eventi e esegue automaticamente l'azione quando vengono rilevati modelli o soglie definiti. L'attivatore può anche sottoscrivere due o più flussi di eventi per osservare le modifiche dei dati. I flussi di eventi variano in frequenza. Ad esempio, i sensori IoT generano eventi più volte al secondo e i sistemi logistici generano eventi sporadicamente, ad esempio quando i pacchetti vengono analizzati nelle località di spedizione.
• Eventi del tessuto. Ad esempio, gli eventi degli elementi dell'area di lavoro di Fabric sono eventi discreti che si verificano quando vengono apportate modifiche all'area di lavoro di Fabric. Queste modifiche includono la creazione, l'aggiornamento o l'eliminazione di un elemento Fabric.
• Eventi di Azure. Ad esempio, gli eventi di Archiviazione BLOB di Azure vengono attivati quando un client crea, sostituisce, elimina un BLOB e così via.
• Report di Power BI. In questo caso, gli eventi sono osservazioni periodiche in base alla pianificazione dell'aggiornamento di un modello semantico di Power BI (noto in precedenza come set di dati). Queste osservazioni possono verificarsi quotidianamente o settimanalmente, formando un flusso di eventi in movimento lento.
• Dashboard Fabric Real-Time.

Ogni evento contiene:

• Timestamp
• Il payload (dati strutturati o semistrutturati)
• Uno o più attributi usati per l'identificazione degli oggetti (ad esempio, device_id, bikepoint_id)

Oggetti

In Fabric Activator le entità monitorate sono denominate oggetti business, che possono essere fisici o concettuali. Alcuni esempi includono oggetti fisici, ad esempiogelatori, veicoli, pacchetti e utenti, e oggetti concettuali come campagne pubblicitarie, account cliente, sessioni utente.

Per modellare un oggetto business in Activator, connettersi a uno o più flussi di eventi, selezionare una colonna da usare come ID oggetto e specificare i campi da considerare come proprietà dell'oggetto.

Il termine istanza dell'oggetto fa riferimento a un esempio specifico di un oggetto business, ad esempio un particolare freezer, veicolo o sessione utente. Al contrario, l'oggetto in genere fa riferimento alla definizione o alla classe generale (ad esempio, il freezer come tipo). Il termine popolamento viene usato per il set completo di istanze di oggetti monitorate.

La creazione dell'oggetto è implicita: Activator raggruppa gli eventi usando una chiave dell'oggetto designata. Le regole hanno come ambito oggetti, ovvero tutta la logica di valutazione è compatibile con oggetti e indipendente tra istanze. Ad esempio, un monitoraggio bikepoint_id delle regole crea valutazioni logiche distinte per ogni stazione di biciclette univoca.

Regole

Le regole definiscono le condizioni che si desidera rilevare sugli oggetti e le azioni da eseguire quando vengono soddisfatte tali condizioni. Ad esempio, una regola su un oggetto freezer potrebbe rilevare quando la temperatura aumenta al di sopra di una soglia sicura e invia automaticamente un avviso di posta elettronica al tecnico assegnato.

Le regole in Activator possono essere senza stato o con stato:

• Le regole senza stato valutano ogni evento in isolamento (ad esempio, valore < 50).
• Le regole con stato mantengono la memoria tra gli eventi per oggetto (ad esempio, valore DIMINUISCE, DIVENTA, ESCE DALLA GAMMA)

La valutazione basata sullo stato si basa su:

• Rilevamento delta: traccia le modifiche tra i valori degli eventi precedenti e quelli correnti.
• Sequenziazione temporale: valuta le condizioni basate sul tempo, ad esempio l'assenza di eventi (rilevamento heartbeat)
• Transizioni di stato: le regole vengono attivate solo all'ingresso in un nuovo stato, impedendo ripetute attivazioni in condizioni non modificate

Ogni condizione della regola viene compilata in un grafico di esecuzione valutato in modo continuo, in memoria e quasi istantaneamente. Il sistema è ottimizzato per una latenza di decisione inferiore al secondo dopo l'arrivo dell'evento.

Azioni

Quando vengono soddisfatte le condizioni di una regola e viene avviata un'azione, si dice che la regola venga attivata. Destinazioni supportate per le azioni includono:

• Pipeline di infrastruttura (per lo spostamento dei dati, arricchimento)
• Notebook Fabric (per il punteggio e la diagnostica del Machine Learning)
• Flussi di Power Automate (per l'integrazione dei processi aziendali)
• Notifiche di Teams (tramite messaggistica basata su modelli)

L'Activator genera un messaggio di trigger con lo stato dell'oggetto corrente e i metadati delle regole, e le azioni non sono bloccanti, cioè l'Activator non attende il completamento delle azioni per abilitare flussi asincroni scalabili.

Proprietà

Le proprietà sono campi o attributi specifici di un oggetto business che si desidera monitorare. Queste possono essere caratteristiche fisiche o concettuali, ad esempio:

• Temperatura di un pacchetto
• Stato di una spedizione
• Saldo di un account cliente
• Punteggio di engagement di una sessione utente

Sono derivati da flussi di eventi, che sono flussi continui di dati provenienti da origini come sensori IoT, report di Power BI o altri sistemi.

Quando si definisce un oggetto business in Activator, si connettono uno o più flussi di eventi, si sceglie una colonna da usare come ID oggetto e si selezionano altre colonne da considerare come proprietà di tale oggetto. È possibile creare regole su queste proprietà per tenere traccia delle modifiche nel tempo, rilevare quando una proprietà supera una soglia o non rientra in un intervallo o attivare azioni come avvisi, flussi di lavoro o notifiche.

Le proprietà sono utili anche quando si vuole riutilizzare la logica tra più regole. Ad esempio, in un oggetto freezer, è possibile definire una proprietà che calcola una media di temperatura in un periodo di un'ora. Una volta definita, è possibile fare riferimento a questa proprietà in più regole, ad esempio quelle che rilevano il surriscaldamento, le fluttuazioni della temperatura o le soglie di manutenzione, senza duplicare la logica. Centralizzando la logica nelle proprietà, è possibile semplificare la gestione, la coerenza e la facilità di aggiornamento delle regole nel tempo.

Periodo di osservazione

Il periodo di lookback si riferisce alla durata dei dati cronologici analizzati da Activator per valutare una regola. Garantisce che dati passati sufficienti siano disponibili per rilevare in modo accurato modelli o aggregazioni di calcolo come medie, anche se i dati arrivano in ritardo o irregolarmente.

Il periodo di analisi retrospettiva è determinato da:

• Come viene definita la regola, ad esempio se richiede l'analisi delle tendenze, il rilevamento di anomalie o il confronto dei valori nel tempo.
• Volume di dati in ingresso, ad esempio il numero di eventi al secondo nel flusso di eventi.

Si consideri un'operazione di logistica farmaceutica che trasporta i pacchetti di medicinali in una catena fredda. L'obiettivo è ricevere un avviso quando un pacchetto diventa troppo caldo.

Si supponga che la regola sia definita per:

• Valutare la temperatura media di ogni pacchetto in un intervallo di tre ore
• Attivare un avviso se la temperatura media supera gli 8°C

Per calcolare questa regola in modo accurato, Fabric Activator deve analizzare una finestra più ampia di dati cronologici, in particolare un periodo di lookback di sei ore. Garantisce che siano disponibili dati sufficienti per calcolare la media di tre ore in qualsiasi momento, anche se i dati arrivano con un ritardo o un'irregolarità.

Il periodo di lookback è essenziale per abilitare il rilevamento tempestivo e accurato delle condizioni, soprattutto negli scenari in cui i modelli di dati si evolvono nel tempo.

Identificativi oggetto distinti e attivi

Le regole basate sugli attributi vengono usate per monitorare il modo in cui gli attributi specifici di un oggetto cambiano nel tempo. Nell'esempio di logistica farmaceutica ogni pacchetto di medicina è rappresentato da un ID oggetto univoco e il sistema riceve letture periodiche della temperatura per ogni pacchetto.

Per valutare queste regole in modo efficace, Fabric Activator tiene traccia degli ID oggetto attivi, ovvero gli oggetti per i quali gli eventi arrivano entro il periodo di lookback definito. Questo comportamento garantisce che solo gli oggetti attualmente attivi siano considerati quando si applicano regole.

Ad esempio, una stazione a pedaggio potrebbe tenere traccia dei veicoli (ID oggetto) durante il passaggio. Ogni veicolo genera eventi (ad esempio, analisi di ingresso e uscita) e solo gli oggetti con attività recenti vengono considerati attivi e valutati dal sistema.

Esistono anche limiti in base al numero di ID oggetto distinti (numero di pacchetti) monitorati all'interno della finestra temporale di controllo.

Casi d'uso comuni

Ecco alcuni scenari reali in cui è possibile usare Fabric Activator:

• Avvia automaticamente campagne pubblicitarie quando le vendite dello stesso negozio diminuiscono, contribuendo a migliorare le prestazioni in posizioni sottoperformi.
• Notificare ai responsabili del negozio di alimentari di spostare il cibo dai congelatori malfunzionanti prima che si verifichi il deterioramento.
• Attivare flussi di lavoro di sensibilizzazione personalizzati quando il percorso di un cliente tra app, siti Web o altri punti di contatto indica un'esperienza negativa.
• Avviare in modo proattivo i flussi di lavoro di indagine quando lo stato di una spedizione non è stato aggiornato entro un intervallo di tempo definito, consentendo di individuare più velocemente i pacchetti persi.
• Avvisare i team di account quando i clienti sono in arretrato, usando soglie personalizzate per il tempo o saldi in sospeso per cliente.
• Monitorare l'integrità della pipeline e rieseguire automaticamente attività non riuscite o allertare i team quando vengono rilevate anomalie o errori.

Passo successivo

Consultare Esercitazione: Creare e attivare una regola Fabric Activator.