Che cos'è Fabric Activator?

Fabric Activator è un motore di rilevamento eventi senza codice che trasforma i flussi di dati in azioni automatizzate. Attiva automaticamente le azioni quando vengono rilevati modelli o condizioni specifici nelle origini dati. Monitora continuamente queste origini dati con bassa latenza (sottosecondo per le regole senza stato sui dati di streaming) 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 Power Automate o l'integrazione con sistemi di terze parti.

Architettura di base

Activator è il motore di rilevamento di eventi e regole al centro dello stack di intelligence in tempo reale Fabric. 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 basata su eventi in cui i flussi di dati vengono continuamente e Activator prende decisioni in base alle valutazioni con stato dei dati degli eventi quasi in tempo reale.

• fonti di eventi

  Activator si connette direttamente ai flussi di eventi, che inseriscono dati da vari producer (Hub eventi di Azure, dispositivi IoT, endpoint personalizzati e altre origini). Questi flussi fungono da origine degli eventi e Activator possono sottoscrivere uno o più flussi di eventi per osservare le modifiche dei dati. Altre origini eventi possono essere eventi Fabric o Azure o un Attivatore che ascolta un report Power BI o una dashboard in tempo reale.

• 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, tutti gli eventi dello stesso dispositivo vengono raggruppati usando device_ido tutti gli eventi della stazione di biciclette sono raggruppati per bikepoint_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 condizioni che tengono traccia delle modifiche nel tempo, come ad esempio BECOMES, DECREASES, INCREASES, EXIT RANGE, o l'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, flussi di dati, funzioni dati utente (UDF) (anteprima) o definizioni di processi Spark in Fabric.

  • Azioni esterne tramite Power Automate.

  • Inviare un messaggio di Teams a un singolo, gruppo o canale.

  • Inviare un messaggio di 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 sono attribuite a capacità di Fabric e possono essere monitorate attraverso 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

Distribuire istanze di attivatore per ogni area di lavoro e associarle a origini dati specifiche. Più attivatori possono monitorare lo stesso flusso, in modo da poter usare valutazioni parallele delle regole per funzioni aziendali distinte. Poiché l'attivatore è associato alla capacità, i prezzi con pagamento in base al consumo si applicano solo quando le regole sono in esecuzione attivamente. Questo modello di determinazione prezzi offre un'efficienza dei costi per scenari di rilevamento intermittenti. Per i vincoli noti, vedere Limitazioni di Activator.

Punti di integrazione all'interno di Real-Time intelligence

Activator come agente di orchestrazione

Per usare in modo efficace Activator in sistemi su larga scala, coordinare il funzionamento con altri componenti Fabric. Ottimizzare le impostazioni in base alla quantità di dati elaborati, al numero di oggetti monitorati e alla 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 (veloce), 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

Fabric Activator monitora continuamente i dati e rileva rapidamente quando vengono soddisfatte le condizioni definite, anche quando i dati cambiano nel tempo. 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 in risposta alle transizioni di stato.

Usare i concetti seguenti 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 gestione rete virtuale di Azure). 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.
• Fabric eventi. Ad esempio, gli eventi degli elementi dell'area di lavoro di Fabric sono eventi discreti che si verificano quando vengono apportate modifiche alla tua area di lavoro Fabric. Queste modifiche includono la creazione, l'aggiornamento o l'eliminazione di un elemento Fabric.
• Azure eventi. Ad esempio, Archiviazione BLOB di Azure eventi vengono attivati quando un client crea, sostituisce o elimina un BLOB.
• Eventi aziendali. È possibile impostare avvisi direttamente sugli eventi aziendali per automatizzare le azioni quando si verificano condizioni aziendali specifiche.
• Fabric ontologia delle entità aziendali (anteprima). Le regole possono essere definite sulle entità aziendali di ontologia per avviare avvisi e azioni automatizzate, abilitando il processo decisionale operativo in base ai dati modellati.
• Power BI report. In questo caso, gli eventi sono osservazioni periodiche in base alla pianificazione dell'aggiornamento di un modello semantico Power BI (noto in precedenza come set di dati). Queste osservazioni possono verificarsi quotidianamente o settimanalmente, formando un flusso di eventi in movimento lento. Activator si integra anche con il servizio Power BI per notificare agli utenti quando viene visualizzata una nuova riga in un oggetto visivo tabella in un report pubblicato, consentendo alle regole di monitorare le modifiche a livello di oggetto visivo e attivare notifiche o azioni downstream.
• Fabric Real-Time dashboard.

Ogni evento contiene:

• Un 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 DAL GAMMA).

Activator supporta anche la creazione di regole basate sui risultati delle query SQL di Fabric Data Warehouse (anteprima). È possibile definire regole che valutano una query SQL in base a una pianificazione configurabile, controllano le condizioni rispetto al set di risultati e attivano le azioni quando vengono soddisfatte le condizioni. Questa funzionalità consente il monitoraggio dei dati del warehouse senza richiedere origini di streaming. Per altre informazioni, vedere Creare una regola di avviso in una query SQL.

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, evitando attivazioni ripetute in condizioni invariate.

Le regole vengono valutate continuamente. Per le regole senza stato sui dati in streaming, il sistema risponde nel giro di pochi millisecondi. Per le regole con aggregazioni, la latenza dipende dalla finestra di lookback e dalla tolleranza di arrivo in ritardo. Per altre informazioni, vedere Latenza in Activator.

Azioni

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

• Fabbriche di pipeline (per lo spostamento dei dati e l'arricchimento).
• Fabric notebook (per l'assegnazione dei punteggi e la diagnostica di Machine Learning).
• Processi Spark di Fabric (per processi di batch/streaming).
• Dataflow di Fabric (per lo spostamento e la trasformazione dei dati).
• Fabric Funzioni dei dati utente (in anteprima) (per la logica aziendale personalizzata con codice).
• flussi di Power Automate (per l'integrazione dei processi aziendali).
• Notifiche di Teams (tramite la messaggistica basata su modello).
• Notifiche email.

Quando viene attivata una regola, Activator invia informazioni su ciò che è accaduto e continua il monitoraggio senza attendere il completamento dell'azione. Questo approccio consente flussi di lavoro scalabili che possono elaborare più eventi contemporaneamente.

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

Le proprietà provengono da flussi di eventi, che sono flussi continui di dati provenienti da origini come sensori IoT, Power BI report 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 è la durata dei dati cronologici analizzati da Activator per valutare una regola. Garantisce che i dati passati siano sufficienti per rilevare in modo accurato modelli o aggregazioni di calcolo come medie, anche se i dati arrivano in ritardo o irregolarmente.

Per determinare il periodo di lookback, eseguire le seguenti attività:

• Come definire 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 di definire la regola 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 esaminare una finestra di dati storici più ampia, ad esempio un periodo di lookback di sei ore per una media di tre ore. Questo processo garantisce che siano presenti 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

Usare le regole basate sugli attributi 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 il sistema consideri solo gli oggetti attualmente attivi pertinenti 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 il sistema valuta solo gli oggetti con attività recenti.

Il numero di ID oggetto distinti (numero di pacchetti) di cui tieni traccia all'interno della finestra di lookback pone anche dei limiti.

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 viene 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.

Contenuti correlati

• Tutorial: creare e attivare una regola di attivazione Fabric
• Panoramica delle regole di attivazione
• Attiva gli elementi Fabric da una regola di attivazione
• Condizioni di rilevamento in Activator
• Limitazioni dell'attivatore
• Creare una regola di avviso in una query SQL
• Latenza in Activator