Configurare gli avvisi direttamente nei report di Power BI usando flussi di attività translitici

I flussi di attività translitiche consentono ai team di analisi di configurare gli avvisi direttamente nei report di Power BI, in modo che i consumer di report rimangano informati sulle modifiche dei dati e sugli eventi imprevisti senza messaggi di posta elettronica di massa. Gli avvisi basati su posta elettronica tendono a soffrire di due problemi: diventano rumore di fondo che gli utenti imparano a ignorare o non raggiungono il pubblico giusto al momento giusto.

Se il team affronta la sfida dei report che offrono un ampio set di stakeholder senza alcun modo affidabile per mantenerli informati su problemi di dati, aggiornamenti o modifiche, i flussi di attività translitiche offrono una soluzione leggera e senza posta elettronica che inserisce le notifiche direttamente nei report Power BI.

Questo articolo illustra come configurare un sistema di notifica in-report che mostra gli avvisi al gruppo di destinatari corretto, con un'unica fonte di verità e nessuna lista di distribuzione di posta elettronica.

È possibile usare questo modello per scenari comuni, ad esempio eventi imprevisti relativi alla qualità dei dati, finestre di manutenzione pianificata e messaggistica specifica del report.

Comprendere il problema risolto da questo modello

I flussi di lavoro di notifica tradizionali per i report di analisi soffrono di diverse carenze:

• Puoi inviare facilmente email, ma indirizzarle ai destinatari giusti è difficile.
• Le liste di distribuzione spesso includono persone che non usano il report in questione oppure escludono persone che invece lo usano.
• Dopo l'invio di un messaggio di posta elettronica, non è presente alcun record centrale degli avvisi attivi associati a un report specifico.
• Gli utenti che aprono un report dopo l'invio del messaggio di posta elettronica potrebbero non visualizzare mai l'avviso.

Il risultato è un divario tra le persone che conoscono un problema e le persone che hanno bisogno di sapere. Un sistema dinamico di notifiche integrato nel report colma questo divario.

Esamina il flusso dall'inizio alla fine

Questa soluzione usa alcuni componenti di base Fabric per creare una pipeline di notifica self-service leggera. Le funzioni dati utente gestiscono la maggior parte del lavoro. Il ciclo di vita delle notifiche segue quattro passaggi:

1. Crea – un utente apre un report dedicato per il "Writeback dell'avviso dati", seleziona il report di destinazione da un elenco predefinito, digita un messaggio di notifica e seleziona Registra avviso dati.
2. Store: il pulsante attiva una funzione dati utente connessa, che esegue una stored procedure SQL per inserire un nuovo record in una tabella di notifica nel database SQL in Fabric.
3. Replica – un collegamento al Lakehouse rispecchia la tabella delle notifiche, quindi i dati sono immediatamente disponibili per il modello semantico Direct Lake senza una fase ETL (estrazione, trasformazione e caricamento) separata.
4. Mostra : ogni report che fa riferimento al modello semantico può visualizzare notifiche pertinenti, filtrate in base al nome del report, in modo che gli utenti visualizzino solo gli avvisi applicabili.

Poiché la tabella di notifica è resa disponibile tramite un collegamento diretto da un database SQL a una Lakehouse in un modello Direct Lake, i dati fluiscono in modo naturale.

Definire il modello di dati di notifica

Considerare le notifiche come dati e progettare una tabella che supporta sia la destinazione che la gestione del ciclo di vita. Includere almeno:

• ID della notifica
• Creato da
• Data/ora di creazione
• Report di destinazione
• Messaggio di notifica
• Stato attivo

A seconda dei requisiti, è anche possibile includere gravità, orari di inizio e fine effettivi e un collegamento facoltativo per indicazioni sulla correzione.

Mantieni questa tabella come riferimento autorevole per tutti gli avvisi attivi, in modo che ogni report a valle usi la stessa unica fonte attendibile.

Creare una notifica

Per creare una notifica, usare un report Power BI creato appositamente che usa flussi di attività translitici. Questo report offre un'esperienza guidata:

1. Selezionare il report di produzione di destinazione da un menu a discesa. In questo scenario, compila un elenco di report validi eseguendo lo scraping dell'area di lavoro di produzione con SemPy.

2. Immettere un messaggio chiaro e conciso che descrive il problema o l'aggiornamento. Per esempio:

   "Report A sta riscontrando problemi di qualità dei dati. Previsto aggiornamento successivo alle 2:00 PST."

3. Selezionare Avviso dati di log da inviare.

Tenere traccia della visibilità delle notifiche

Entro pochi secondi dall'invio, i collegamenti e Direct Lake aggiungono la notifica al modello semantico. Una visualizzazione di rilevamento dedicata consente agli amministratori e ai proprietari dei report di monitorare immediatamente tutte le notifiche attive. I campi chiave includono:

• Creato da
• Data di creazione (PST)
• Messaggio di notifica
• Report di destinazione

Poiché il modello semantico funge da singola origine di verità per tutti i report downstream, ogni dashboard connesso trae vantaggio dagli stessi dati di notifica.

Controllare gli avvisi visualizzati in ogni report

Non tutte le notifiche vanno inserite in tutti i report. Il framework usa il filtro predefinito di Power BI per consentire a ogni proprietario del report di decidere quali avvisi sono rilevanti. Una configurazione di filtro tipica può includere:

• Report = "All" – per annunci estesi all’intero servizio, visibili ovunque.
• Report = "Report A" : per gli avvisi specifici di un singolo report.

Quando usare questo modello

Questo modello funziona meglio quando i consumer di report necessitano di aggiornamenti tempestivi e mirati nel contesto:

• Eventi imprevisti relativi alla qualità dei dati: informare gli utenti quando i dati vengono ritardati, incompleti o sottoposti a indagine.
• Finestre di manutenzione pianificata: comunicare le modifiche, le migrazioni o i tempi di inattività previsti per l'aggiornamento imminente.
• Messaggistica specifica del report: condividere avvertenze, note sulla versione o indicazioni temporanee per un report o un gruppo di report specifico.

Mostra avvisi all'interno del report

Gli utenti interagiscono con le notifiche tramite una barra dell'utilità nella parte superiore di ogni report:

• Indicatore persistente: Un pulsante Avvisi è sempre visibile nella barra dell'utilità.
• Conteggio in tempo reale: Un indicatore sul pulsante indica il numero di notifiche attive in base alla configurazione del filtro del report.
• Visualizzazione dettagli: Selezionando il pulsante si apre una visualizzazione dettagli che elenca ogni notifica attiva con la data, il messaggio, il report di destinazione e l'autore.

Questa progettazione mantiene visibili gli avvisi ma non intrusivi. Gli utenti vengono informati nel momento in cui aprono il report e possono esaminare i dettagli su richiesta.

Adattare il modello per i modelli non Direct Lake

Se il modello semantico non usa la modalità Direct Lake, i dati di notifica non verranno visualizzati automaticamente dopo l'aggiornamento del collegamento Lakehouse. In questo caso, estendere l'architettura con altri due componenti:

• Trigger: Data Activator monitora la tabella delle notifiche alla ricerca di nuovi record.
• Pipeline di aggiornamento: Una pipeline Fabric usa un'attività del modello semantico di aggiornamento per selezionare e idratare una singola tabella (la tabella di notifica) quando viene attivato l'attivatore.

Per questa variante, mantenere l'ambito di aggiornamento il più piccolo possibile (solo tabella di notifica) in modo da ridurre la latenza ed evitare l'elaborazione del modello non necessaria.

La sequenza di implementazione è:

1. Configurare Data Activator per rilevare notifiche attive nuove o modificate.
2. Attiva l'esecuzione di una pipeline di Fabric quando si verifica quell'evento.
3. Aggiornare solo la tabella di notifica nel modello semantico.
4. Verificare che i filtri del report continuino a definire l'ambito delle notifiche in base al nome del report.

Il resto del flusso rimane identico. Gli utenti creano ancora notifiche tramite lo stesso report di writeback e i report downstream li usano ancora tramite il modello semantico.

Sommario

Usando i flussi di attività translitici in Fabric, è possibile visualizzare notifiche mirate nel contesto senza un singolo messaggio di posta elettronica. I vantaggi includono:

• Gli utenti visualizzano gli avvisi nel punto in cui lavorano, all'interno del report.
• La destinazione degli avvisi è precisa e controllata a livello di report.
• Esiste una singola fonte di verità per tutti i dati di notifica.
• Il framework è leggero e costruito interamente su Fabric.

Se il modello semantico usa Direct Lake o le tabelle di importazione, questo modello è adattabile e inserisce le informazioni corrette davanti alle persone giuste al momento giusto.

Sei pronto per iniziare? Iniziare con la panoramica del flusso di attività translitica o esplorare Funzioni dati utente per configurare la prima pipeline di notifica.

Contenuti correlati

• Informazioni sui flussi di attività translitiche: informazioni sui concetti di base relativi ai flussi di attività translitici in Microsoft Fabric.
• Panoramica delle funzioni dei dati utente – Scopri come le funzioni dei dati utente eseguono procedure memorizzate per alimentare il flusso di notifiche.
• Usare il database SQL come motore dati di origine per applicazioni translitiche: usare questa architettura come modello per modelli translitici supportati da SQL in Fabric.
• Introduzione a Data Activator : configurare i trigger per monitorare la tabella di notifica per i modelli non Direct Lake.
• Collegamenti al Lakehouse in Microsoft Fabric – Scopri come i collegamenti replicano la tabella delle notifiche nel Lakehouse.