WEBVTT

00:00:00.370 --> 00:00:07.010
Siete pronti per dieci giorni di Microsoft 365, Copilot, EA e Azzurro alle persone che stanno plasmando il futuro del lavoro?

00:00:07.870 --> 00:00:12.050
Questo gennaio, M365 con ritorna e puntiamo ancora più in alto a

00:00:12.050 --> 00:00:18.270
Unitevi a noi per sessioni dal vivo, demo reali e conoscenze pratiche condivise da MVP ed esperti del settore di tutto il mondo.

00:00:18.830 --> 00:00:21.190
Niente slide generiche, niente parole d'ordine infinite.

00:00:21.970 --> 00:00:28.530
Affrontiamo le sfide reali, Copilot Studio, agenti IA, Fabric, Sicurezza, Governance e Automazione

00:00:28.530 --> 00:00:34.190
Che siate professionisti IT, sviluppatori o leader aziendali, ci sono sessioni pensate per voi.

00:00:35.430 --> 00:00:40.110
Con dieci giorni interi potrete esplorare molteplici tecnologie e connettervi con una community globale.

00:00:40.930 --> 00:00:44.250
Seguite dal vivo e portate intuizioni pratiche nella vostra organizzazione.

00:00:45.190 --> 00:00:47.770
Gennaio 2027, dieci giorni, un'unica community.

00:00:48.030 --> 00:00:50.610
Microsoft? Le iscrizioni sono ora aperte.

00:00:51.730 --> 00:00:52.990
Prenotate il vostro posto oggi stesso.

00:00:53.930 --> 00:00:58.110
Il sito è m365.net

00:00:58.110 --> 00:01:04.670
Iscrivetevi ora su m365.net e ci vediamo dal vivo a gennaio.

00:01:05.330 --> 00:01:08.030
Vi siete mai chiesti se i vostri dati potessero agire senza nemmeno che li tocchiate.

00:01:08.370 --> 00:01:10.510
Immaginate di rilevare un callo di inventario in tempo reale.

00:01:11.430 --> 00:01:15.670
E invece di inviare un'email o controllare una dashboard, il sistema ordina semplicemente la merce al posto vostro.

00:01:16.150 --> 00:01:16.950
Non è un'ipotesi.

00:01:17.550 --> 00:01:19.170
È Fabric Data Activator in azione.

00:01:19.170 --> 00:01:24.850
Oggi collegheremo i punti tra dati grezzi, avvisi istantanei e risposte automatizzate

00:01:24.850 --> 00:01:29.130
mostrandovi come interagisce con Power BI Synapse e il resto di Microsoft Fabric

00:01:29.130 --> 00:01:32.670
per trasformare le intuizioni in azioni senza ritardi.

00:01:34.010 --> 00:01:35.510
L'anello mancante nel vostro ciclo dati.

00:01:36.310 --> 00:01:39.610
Molti team diranno di operare in tempo reale, ma appena guardate sotto il cofano

00:01:39.610 --> 00:01:42.310
le cose sembrano molto più vicine al giorno successivo.

00:01:42.310 --> 00:01:47.290
Le dashboard si aggiornano ogni 15-30 minuti, a volte solo una volta all'ora.

00:01:48.330 --> 00:01:50.710
Per allora il pattern che dovete cogliere è già cambiato

00:01:50.710 --> 00:01:55.210
e il report che state guardando è più un'analisi post partita che un feed in diretta a

00:01:55.210 --> 00:01:58.630
state guardando la cronaca dopo che il risultato finale è già stato stabilito.

00:01:59.450 --> 00:02:01.990
Il problema non è che gli strumenti di BI non mostrino cosa sta succedendo.

00:02:02.330 --> 00:02:03.510
Di solito sono molto bravi in questo.

00:02:04.070 --> 00:02:06.050
Il pezzo mancante è ciò che accade dopo averlo visto.

00:02:06.890 --> 00:02:11.150
Al momento la maggior parte dei flussi di lavoro si affida a un umano che noti il cambiamento

00:02:11.150 --> 00:02:14.010
decida quale azioni intraprendere e poi la esegua.

00:02:14.530 --> 00:02:15.470
Questo crea un collo di bottiglie.

00:02:15.810 --> 00:02:19.430
Anche qualcosa di semplice come inviare un'email ai clienti quando una certa metrica cala

00:02:19.430 --> 00:02:23.050
finisce per essere un lavoro manuale perché il sistema non è impostato per collegare

00:02:23.050 --> 00:02:25.010
l'intuizione direttamente all'azione.

00:02:26.410 --> 00:02:28.930
È in questo ritardo che tante opportunità si raffreddano.

00:02:29.830 --> 00:02:33.250
Una promozione lanciata con tre ore di ritardo dopo un calo delle vendite perde la sua urgenza.

00:02:34.150 --> 00:02:37.710
Un picco di errori sul sito web che rimane risolto fino alla prossima riunione di revisione

00:02:37.710 --> 00:02:40.570
finisce per costarci conversioni che non recupereremo mai più.

00:02:41.150 --> 00:02:45.530
Il divario tra i sapere e l'agire è esattamente dove vive Fabric Data Activator ed è progettato

00:02:45.530 --> 00:02:47.470
per ridurre questo intervallo a pochi secondi.

00:02:48.590 --> 00:02:52.450
Poiché risiede nativamente all'interno di Microsoft Fabric, Data Activator non richiede

00:02:52.450 --> 00:02:55.490
di esportare, collegare o gestire costantemente origini dati.

00:02:56.890 --> 00:02:59.790
Legge i flussi di eventi nel momento in cui accadono e reagisce istantaneamente quando

00:02:59.790 --> 00:03:01.610
viene soddisfatta una condizione definita ad utente.

00:03:02.450 --> 00:03:05.450
La differenza è che invece di fermarsi a un avviso puoi innescare una reazione catena

00:03:05.450 --> 00:03:06.630
nel resto dei tuoi sistemi.

00:03:06.630 --> 00:03:11.350
Immagina questo, un feed di vendita dal vivo monitora le prestazioni in diverse regioni.

00:03:12.570 --> 00:03:16.250
Normalmente noteresti un calo improvviso in una regione sulla tua dashboard, indagresti,

00:03:16.310 --> 00:03:20.370
redigeresti un'offerta mirata, otterresti l'approvazione e pubblicheresti la promozione.

00:03:20.970 --> 00:03:21.810
Potrebbe richiedere un'ora.

00:03:21.810 --> 00:03:27.330
Con Data Activator lo stesso calo potrebbe attivare una chiamata API pre-approvata al

00:03:27.330 --> 00:03:31.270
tuo sistema di automazione e marketing, lanciando un'offerta mirata in pochi minuti prima ancora

00:03:31.270 --> 00:03:32.810
che i concorrenti vedano la debolezza.

00:03:34.410 --> 00:03:37.570
Nessuna attesa che la persona giusta se ne accorpia, nessun ritardo per deliberare

00:03:37.570 --> 00:03:38.410
su una mossa ovvia.

00:03:39.030 --> 00:03:39.830
Questo è il vero cambiamento.

00:03:40.270 --> 00:03:42.010
I tradizionali strumenti di BI tracciano.

00:03:42.130 --> 00:03:43.490
Data Activator ascolta e risponde.

00:03:43.490 --> 00:03:48.210
Con una tipica cadenza di aggiornamento di Power BI di, diciamo, 30 minuti, il rilevamento

00:03:48.210 --> 00:03:52.410
da solo potrebbe essere già in ritardo rispetto al momento in cui è iniziato il cambiamento.

00:03:53.550 --> 00:03:58.490
I trigger di Data Activator possono agire sui flussi di eventi quasi in tempo reale, nell'ordine

00:03:58.490 --> 00:04:02.610
di secondi a seconda della fonte, allineando il momento azionabile molto più strettamente

00:04:02.610 --> 00:04:04.090
all'evento scatenante stesso.

00:04:05.390 --> 00:04:09.550
E poiché integrato in Fabric non è limitato a una singola dashboard o set di dati, può

00:04:09.550 --> 00:04:11.970
collegarsi a qualsiasi parte dell'ecosistema abbia senso.

00:04:11.970 --> 00:04:18.130
Quel feed in streaming potrebbe far parte di una pipeline di dati Synapse, che alimenta

00:04:18.130 --> 00:04:21.830
poi diversi modelli a valle e modelli di AI.

00:04:22.430 --> 00:04:26.250
Se accade qualcosa di importante, Data Activator non si limita a inviare un avviso alla tua dashboard.

00:04:27.170 --> 00:04:31.110
Invia il segnale ai sistemi in grado di correggere o sfruttare immediatamente l'opportunità.

00:04:32.370 --> 00:04:34.190
Questo è il ponte tra osservazione ed esecuzione.

00:04:34.710 --> 00:04:38.450
Invece di riempire la chat del tuo team con messaggi informativi che il personale vedrà

00:04:38.450 --> 00:04:41.430
dopo pranzo, esegue il passaggio successivo proprio in quel momento.

00:04:42.470 --> 00:04:46.910
Trasforma ogni evento qualificante in una decisione già presa, in un'azione già compiuta.

00:04:47.810 --> 00:04:51.190
Quando lo si confronta con il flusso di lavoro BI standard, il vantaggio è ovvio.

00:04:51.890 --> 00:04:53.510
Il solo monitoraggio ti racconta la storia.

00:04:54.270 --> 00:04:56.070
Monitoraggio più risposta cambia il risultato.

00:04:57.050 --> 00:04:59.890
E in un panorama in cui le finestre di opportunità si chiudono rapidamente,

00:05:00.510 --> 00:05:02.630
questa differenza è più che comodità e competitività.

00:05:03.910 --> 00:05:07.230
Successivamente vediamo come questo si adatta naturalmente agli strumenti con cui già

00:05:07.230 --> 00:05:10.670
lavori senza aggiungere un ulteriore livello di complessità da gestire.

00:05:11.570 --> 00:05:13.430
Molto più di semplici avvisi, la rete Fabric.

00:05:13.870 --> 00:05:16.770
Inviarti un altro ping su Teams non è automazione, è solo altro rumore.

00:05:17.710 --> 00:05:18.430
A che tipo mi riferisco?

00:05:18.770 --> 00:05:22.170
Un'andata di pop-up su ogni schermo, ognuno che pretende la tua attenzione su qualcosa

00:05:22.170 --> 00:05:23.590
che potrebbe non avere importanza.

00:05:24.650 --> 00:05:27.110
All'inizio sembra di avere tutto sotto controllo, ma presto.

00:05:27.110 --> 00:05:31.290
Il team inizia a ignorarli e quelli importanti finiscono sepolti nel caos.

00:05:32.870 --> 00:05:36.830
L'ironia è che i sistemi pensati per tenerti informato finiscono spesso per renderti più cieco.

00:05:38.330 --> 00:05:41.550
Tutti abbiamo partecipato a quella riunione del lunedì in cui qualcuno dice di aver perso

00:05:41.550 --> 00:05:44.550
un problema importante con un cliente perché l'avviso sembrava uguale agli altri.

00:05:45.430 --> 00:05:47.650
La radice del problema non è la mancanza di rilevamento,

00:05:47.910 --> 00:05:49.890
ma la mancanza di intelligenza su cosa fare dopo.

00:05:50.790 --> 00:05:53.950
Trigger troppo sensibili trattano ogni piccola fluttuazione come una crisi,

00:05:53.950 --> 00:05:57.170
creando una cultura in cui tutti sono abituati a ignorarli, pointire.

00:05:58.170 --> 00:06:02.650
È qui che l'integrazione di Data Activator nel resto di Microsoft Fabric inizia ad avere importanza.

00:06:04.270 --> 00:06:09.230
Non è solo un'aggiunta, opera direttamente accanto a Power BI, Synapse e al Data Warehousing di Fabric.

00:06:10.390 --> 00:06:14.770
Ciò significa che opera sullo stesso campo dei tool che già gestiscono i tuoi analytics e le tue pipeline.

00:06:15.630 --> 00:06:17.630
Invece di inviarti un ping a ogni minima variazione,

00:06:17.750 --> 00:06:20.050
può decidere se vale la pena fermare tutto per quella variazione.

00:06:20.050 --> 00:06:25.690
Immaginalo come un vecchio centralinista, ma di quelli che capiscono davvero l'urgenza dietro a ogni chiamata.

00:06:26.930 --> 00:06:29.350
Quando succede qualcosa, ad esempio un feed dati invia un segnale

00:06:29.350 --> 00:06:31.690
che il formato dei nomi prodotto è errato durante il caricamento.

00:06:32.510 --> 00:06:35.170
Data Activator sa quali fili collegano i sistemi giusti,

00:06:35.670 --> 00:06:38.190
non invia al team marketing una notifica che leggeranno domani.

00:06:38.850 --> 00:06:42.190
In strada è il problema direttamente al sistema che può bloccare il caricamento fallato

00:06:42.190 --> 00:06:44.630
prima che corrompa i report a valle.

00:06:45.350 --> 00:06:46.290
Ecco un esempio pratico.

00:06:46.290 --> 00:06:50.490
Una pipeline di Synapse sta estraendo dati di transazioni finanziarie ogni pochi secondi.

00:06:51.550 --> 00:06:55.470
Uno dei sistemi a monte inizia a inviare record duplicati a causa di un problema tecnico del fornitore.

00:06:56.210 --> 00:06:59.010
Se usi solo gli avvisi, ricevi un messaggio su Teams o un'email che dice

00:06:59.010 --> 00:07:00.910
Hey, rilevato un conteggio di duplicati?

00:07:01.470 --> 00:07:02.870
Un analista delle cose da fuori di qualcuno.

00:07:03.350 --> 00:07:07.730
Con Data Activator può effettivamente mettere in pausa la pipeline non appena arrivano i duplicati,

00:07:08.350 --> 00:07:10.650
dando ai data engineer il tempo di correggere la fonte

00:07:10.650 --> 00:07:13.150
prima che i dati errati e errati arrivino nel warehouse.

00:07:13.150 --> 00:07:17.230
La correzione avviene a livello di sistema, non perché qualcuno stava controllando la dashboard.

00:07:18.070 --> 00:07:19.130
Questa è una differenza fondamentale.

00:07:19.630 --> 00:07:22.630
Data Activator non è legato a un singolo set di dati e a un flusso ristretto.

00:07:23.370 --> 00:07:24.750
Funziona su più tipi di input.

00:07:25.910 --> 00:07:29.610
Tabelle di warehouse strutturate, flussi di eventi e altre fonti di dati connessi a fabric,

00:07:29.770 --> 00:07:32.550
applicando le stesse regole logiche senza doverle supervisionare.

00:07:33.910 --> 00:07:36.890
Questa portata cross-service significa che non sa solo quando qualcosa non va.

00:07:36.890 --> 00:07:39.610
Sa esattamente quando frenare o quando accelerare.

00:07:39.610 --> 00:07:44.430
E poiché vive nello stesso ecosistema della logica di trasformazione e dell'archiviazione,

00:07:44.850 --> 00:07:48.390
non ostacola i flussi di dati e integrati in essi.

00:07:48.830 --> 00:07:52.630
Ecco perché puoi creare una catena in cui ingestione e trasformazione con valida risoluzione

00:07:52.630 --> 00:07:56.410
avvengono in un unico flusso senza rincorrersi per i passaggi di consegne.

00:07:57.190 --> 00:08:01.850
È la differenza tra reagire ai dati e fare in modo che i sistemi si adattino in corso d'opera

00:08:01.850 --> 00:08:03.610
per preservare qualità e tempestività.

00:08:03.610 --> 00:08:08.370
Tuttavia il vero vantaggio emerge quando lo si vede non come uno strumento di avviso

00:08:08.370 --> 00:08:10.510
ma come un livello di processo decisionale operativo.

00:08:11.330 --> 00:08:14.990
Risponde in base al contesto, il che riduce drasticamente il volume di rumore

00:08:14.990 --> 00:08:19.590
aumentando al contempo la percentuale di avvisi che attivano azioni significative.

00:08:20.930 --> 00:08:22.310
Non sei più sommerso.

00:08:23.270 --> 00:08:25.610
Ottieni segnali chiari dal rumore con meno lavoro manuale.

00:08:25.610 --> 00:08:29.350
E poiché tali decisioni possono rischiare cambiamenti reali

00:08:29.350 --> 00:08:32.750
come mettere in pausa processi, aggiornare record o avviare riparazioni

00:08:32.750 --> 00:08:35.830
questo non serve solo a ridurre il ritardo tra la consapevolezza e l'azione

00:08:35.830 --> 00:08:37.730
elimina completamente il divano.

00:08:38.090 --> 00:08:39.910
Ora passiamo alla parte che attira l'attenzione

00:08:39.910 --> 00:08:42.750
chiamare API e interagire con il mondo esterno Microsoft.

00:08:43.750 --> 00:08:45.250
Quando l'interno chiama il mondo esterno

00:08:45.250 --> 00:08:48.430
i tuoi dati possono fare una telefonata prima ancora che tu veda la chiamata persa.

00:08:49.050 --> 00:08:51.450
Non è un modo di dire parliamo di prendere lo stesso flusso di eventi

00:08:51.450 --> 00:08:53.850
che stai già monitorando e permettergli di attivare qualcosa

00:08:53.850 --> 00:08:56.810
al di fuori dell'ecosistema Microsoft Fabric in tempo reale.

00:08:57.250 --> 00:08:58.050
In tempo reale.

00:08:58.570 --> 00:09:01.950
Invece di aspettare che tu legga una dashboard o faccia clic su un avviso di Teams

00:09:01.950 --> 00:09:04.750
il sistema stesso chiama verso l'esterno

00:09:04.750 --> 00:09:06.630
metaforicamente o letteralmente

00:09:06.630 --> 00:09:09.630
per avviare un'azione in un'altra applicazione o servizio

00:09:09.630 --> 00:09:11.130
non appena la condizione è soddisfatta.

00:09:11.990 --> 00:09:13.610
La maggior parte le configurazioni BI fallisce proprio.

00:09:14.170 --> 00:09:15.810
Sono eccellenti nell'emergere intuizioni

00:09:15.810 --> 00:09:18.630
a volte anche con grafiche accattivanti e commenti assistiti dall'Ii

00:09:18.630 --> 00:09:20.930
ma ti passano la palla e si aspettano che sia tu a giocare.

00:09:20.930 --> 00:09:25.070
Devi ancora aprire il CRM e inviare l'ordine e aggiornare l'ERP

00:09:25.070 --> 00:09:27.770
o avviare il processo manualmente

00:09:27.770 --> 00:09:30.670
e in quel divario che si insinua nuovamente il collo di bottiglia umano.

00:09:32.130 --> 00:09:33.970
Potresti rilevare il problema in pochi minuti

00:09:33.970 --> 00:09:35.270
ma l'esecuzione avviene ore dopo

00:09:35.270 --> 00:09:37.190
perché si attende che qualcuno sia libero di agire.

00:09:38.330 --> 00:09:40.450
Con Data Activator quel passaggio non è solo abbreviato

00:09:40.450 --> 00:09:41.130
è sparito.

00:09:42.270 --> 00:09:43.610
Immagina che i livelli di inventario

00:09:43.610 --> 00:09:46.050
scendano sotto la soglia di rifornimento a metà giornata.

00:09:46.050 --> 00:09:49.890
In una configurazione normale qualcuno alle operazioni lo nota

00:09:49.890 --> 00:09:51.950
in Power BI invia una nota agli approvvigionamenti

00:09:51.950 --> 00:09:52.990
e attende conferma.

00:09:53.710 --> 00:09:55.370
Nel frattempo continua a vendere il prodotto

00:09:55.370 --> 00:09:56.870
avvicinandoti alla rottura di stock.

00:09:58.110 --> 00:10:00.310
Invece Data Activator può inviare una chiamata API

00:10:00.310 --> 00:10:02.270
direttamente al sistema di ordini del tuo fornitore

00:10:02.270 --> 00:10:04.090
nel momento in cui i dati superano con la soglia.

00:10:05.390 --> 00:10:07.150
L'ordine di acquisto arriva, la consegna in coda

00:10:07.150 --> 00:10:09.050
nessuno nel team ha ancora letto l'avviso

00:10:09.050 --> 00:10:10.450
e la soluzione è già in corso.

00:10:10.450 --> 00:10:12.810
E' questo il valore di inviare chiamate esterne

00:10:12.810 --> 00:10:14.150
direttamente dall'interno di Fabric.

00:10:15.490 --> 00:10:17.410
Non se è limitato agli strumenti Microsoft

00:10:17.410 --> 00:10:19.830
che si tratti di un CRM SaaS, di un ERP legacy

00:10:19.830 --> 00:10:21.290
di un endpoint rest personalizzato

00:10:21.290 --> 00:10:22.350
o dell'APA di un partner

00:10:22.350 --> 00:10:24.070
puoi collegare quel trigger in tempo reale

00:10:24.070 --> 00:10:26.030
per colmare il divario tra rilevamento e risoluzione.

00:10:27.610 --> 00:10:29.110
L'output può essere semplice

00:10:29.110 --> 00:10:30.410
come inviare dati a un webbook

00:10:30.410 --> 00:10:32.890
o strutturato come l'invio di un payload formattato

00:10:32.890 --> 00:10:34.310
che attiva un flusso di lavoro in più

00:10:34.310 --> 00:10:37.310
passaggi su una piattaforma completamente diversa.

00:10:37.310 --> 00:10:41.450
E' qui che Fabric smette di essere

00:10:41.450 --> 00:10:42.910
solo una serie di strumenti di analisi

00:10:42.910 --> 00:10:44.070
e inizia a comportarsi

00:10:44.070 --> 00:10:45.750
come il sistema nervoso centrale

00:10:45.750 --> 00:10:46.930
del tuo ambiente operativo.

00:10:48.710 --> 00:10:49.770
Quando si verifica un evento

00:10:49.770 --> 00:10:51.450
il nervo non invia solo un segnale agli occhi

00:10:51.450 --> 00:10:53.030
ma trasmette istruzioni agli arti

00:10:53.030 --> 00:10:55.130
affinché possano agire immediatamente.

00:10:55.790 --> 00:10:58.090
E' così che passi dal monitoraggio delle operazioni

00:10:58.090 --> 00:11:00.050
al fatto che esse si regolino in gran parte da sole.

00:11:00.670 --> 00:11:01.430
Puoi notarlo nei settori

00:11:01.430 --> 00:11:02.670
con una forte presenza di IoT.

00:11:03.810 --> 00:11:05.270
Immagina uno stabilimento produttivo

00:11:05.270 --> 00:11:07.810
con sensori di vibrazione installati sui macchinari critici.

00:11:08.890 --> 00:11:11.370
Questi sensori trasmettono dati a Fabric in tempo reale.

00:11:11.630 --> 00:11:12.990
Nel momento in cui una lettura rientra

00:11:12.990 --> 00:11:14.410
in un intervallo di allerta a guasto

00:11:14.410 --> 00:11:16.330
Data Activator può creare e assegnare

00:11:16.330 --> 00:11:18.090
un ordine di lavoro in Dynamics 365

00:11:18.090 --> 00:11:19.270
programmando un tecnico

00:11:19.270 --> 00:11:21.350
prima ancora che la macchina si avvicini al guasto.

00:11:22.890 --> 00:11:24.750
Nessun supervisore deve interrompere la giornata

00:11:24.750 --> 00:11:25.570
per fare una chiamata

00:11:25.570 --> 00:11:27.390
il sistema in strada lavora automaticamente

00:11:27.390 --> 00:11:29.450
formendo il contesto necessario al tecnico.

00:11:30.090 --> 00:11:32.030
I lavori di riparazione iniziano prima ancora

00:11:32.030 --> 00:11:33.510
che si parli di tempi di inattività.

00:11:34.110 --> 00:11:35.810
La combinazione di monitoraggio automatizzato

00:11:35.810 --> 00:11:36.730
e app in uscita è

00:11:36.730 --> 00:11:38.430
dove entra in gioco la vera autonomia.

00:11:39.110 --> 00:11:41.010
Non ti limiti a filtrare gli avvisi per pertinenza

00:11:41.010 --> 00:11:43.190
ma colleghi quei trigger filtrati ad azioni tangibili

00:11:43.190 --> 00:11:44.210
che avvengono immediatamente.

00:11:44.930 --> 00:11:46.090
E' un salto dall'essere orientati

00:11:46.090 --> 00:11:47.670
all'essere attivati dai dati

00:11:47.670 --> 00:11:49.710
dove la capacità di risposta del sistema è rapida

00:11:49.710 --> 00:11:51.330
quanto la sua capacità di rilevamento.

00:11:52.550 --> 00:11:53.750
Se configurati correttamente

00:11:53.750 --> 00:11:56.370
i tuoi processi non solo evitano la microgestione umana

00:11:56.370 --> 00:11:57.910
ma migliorano attivamente

00:11:57.910 --> 00:11:59.750
perché il ciclo tra rilevamento e azione

00:11:59.750 --> 00:12:01.910
è stretto, coerente e sempre attivo.

00:12:03.290 --> 00:12:05.150
Puoi concentrarti sulla progettazione di regole

00:12:05.150 --> 00:12:06.270
e logiche migliori invece

00:12:06.270 --> 00:12:07.910
di preoccuparti che qualcuno veda l'avviso

00:12:07.910 --> 00:12:10.510
ma anche il sistema nervoso più reattivo

00:12:10.510 --> 00:12:11.870
delle soglie che non puoi ignorare.

00:12:12.810 --> 00:12:14.030
Se non le conosci prima di iniziare

00:12:14.030 --> 00:12:16.010
i risultati possono diventare caotici rapidamente.

00:12:17.090 --> 00:12:18.630
Conoscere i limiti prima di costruire

00:12:18.630 --> 00:12:19.530
è fondamentale

00:12:19.530 --> 00:12:20.850
ogni eroe dell'automazione

00:12:20.850 --> 00:12:21.950
ha una storia d'origine

00:12:21.950 --> 00:12:23.330
e una lista di insidie

00:12:23.330 --> 00:12:24.530
che avrebbe voluto prevedere.

00:12:25.850 --> 00:12:26.630
Con Data Activator

00:12:26.630 --> 00:12:27.450
la realtà è che

00:12:27.450 --> 00:12:27.950
sebbene

00:12:27.950 --> 00:12:29.050
l'idea di rilevamento

00:12:29.050 --> 00:12:30.490
più reazione sembri limitata

00:12:30.490 --> 00:12:32.490
c'è un framework molto pratico alla base.

00:12:33.530 --> 00:12:34.030
Non è magia

00:12:34.030 --> 00:12:34.750
funziona ancora

00:12:34.750 --> 00:12:35.910
sull'architettura di Fabric

00:12:35.910 --> 00:12:37.050
vincolato dagli stessi

00:12:37.050 --> 00:12:38.190
modelli di capacità

00:12:38.190 --> 00:12:39.190
limiti di servizio

00:12:39.190 --> 00:12:40.550
e presupposti di progettazione

00:12:40.550 --> 00:12:41.350
che si applicano

00:12:41.350 --> 00:12:42.950
a tutto il resto dell'ecosistema.

00:12:44.330 --> 00:12:45.070
Ignora quei limiti

00:12:45.070 --> 00:12:45.970
e scoprirai presto

00:12:45.970 --> 00:12:46.530
cosa succede

00:12:46.530 --> 00:12:48.150
quando un'automazione ben intenzionata

00:12:48.150 --> 00:12:49.350
si blocca completamente.

00:12:50.610 --> 00:12:51.310
La parte complicata

00:12:51.310 --> 00:12:52.370
è che i punti di errore di solito

00:12:52.370 --> 00:12:52.890
non emergono

00:12:52.890 --> 00:12:54.170
durante la tua prova di concetto.

00:12:54.930 --> 00:12:55.730
In un test limitato

00:12:55.730 --> 00:12:56.830
tutto sembra istantaneo.

00:12:57.390 --> 00:12:58.310
Le condizioni si attivano

00:12:58.310 --> 00:12:59.070
le azioni partono

00:12:59.070 --> 00:12:59.770
e vedi il risultato

00:12:59.770 --> 00:13:00.490
quasi immediatamente.

00:13:01.050 --> 00:13:02.230
E' quando passi su larga scala

00:13:02.230 --> 00:13:03.850
connettendo più sistemi esterni

00:13:03.850 --> 00:13:04.510
aumentando il volume

00:13:04.510 --> 00:13:04.930
dei trigger

00:13:04.930 --> 00:13:06.510
e stratificando logiche complesse

00:13:06.510 --> 00:13:07.110
che i vincoli

00:13:07.110 --> 00:13:08.410
mostrano i denti.

00:13:08.970 --> 00:13:09.690
La latenza aumenta

00:13:09.690 --> 00:13:10.590
l'utilizzo della capacità

00:13:10.590 --> 00:13:11.370
schizza alle stelle.

00:13:12.030 --> 00:13:12.610
All'improvviso

00:13:12.610 --> 00:13:13.910
quel motore decisionale

00:13:13.910 --> 00:13:14.530
in tempo reale

00:13:14.530 --> 00:13:15.190
viene limitato

00:13:15.190 --> 00:13:15.950
o messo in coda.

00:13:17.250 --> 00:13:18.210
Pensa a cosa succede

00:13:18.210 --> 00:13:18.850
quando un trigger

00:13:18.850 --> 00:13:19.710
dipende da una fonte

00:13:19.710 --> 00:13:20.830
tecnicamente connessa

00:13:20.830 --> 00:13:21.850
ma non in esecuzione

00:13:21.850 --> 00:13:22.950
all'interno dei servizi

00:13:22.950 --> 00:13:23.790
nativi di Fabric.

00:13:25.010 --> 00:13:25.950
Magari è un flusso di dati

00:13:25.950 --> 00:13:27.350
proveniente da un event hub esterno

00:13:27.350 --> 00:13:27.870
che alimenta

00:13:27.870 --> 00:13:28.730
i tuoi report.

00:13:30.090 --> 00:13:30.970
Se Data Activator

00:13:30.970 --> 00:13:31.830
si affida a quel feed

00:13:31.830 --> 00:13:33.150
per avviare un processo critico

00:13:33.150 --> 00:13:34.030
ma l'intervallo

00:13:34.030 --> 00:13:35.350
di elaborazione alla fonte

00:13:35.350 --> 00:13:36.370
è più lento del tempo

00:13:36.370 --> 00:13:37.490
di reazione di Fabric

00:13:37.490 --> 00:13:38.470
non otterrai mai

00:13:38.470 --> 00:13:39.390
la reattività

00:13:39.390 --> 00:13:40.350
che ti aspetti.

00:13:41.550 --> 00:13:42.390
Ho visto implementazioni

00:13:42.390 --> 00:13:43.610
bloccarsi perché le condizioni

00:13:43.610 --> 00:13:44.930
erano basate su dati semistatici

00:13:44.930 --> 00:13:45.890
che non riuscivano a stare al passo

00:13:45.890 --> 00:13:46.890
con la logica del trigger.

00:13:47.770 --> 00:13:48.650
L'automazione non ha fallito

00:13:48.650 --> 00:13:49.590
è arrivata solo troppo tardi

00:13:49.590 --> 00:13:50.110
per essere utile.

00:13:50.690 --> 00:13:51.450
C'è anche la tentazione

00:13:51.450 --> 00:13:52.230
di monitorare tutto.

00:13:52.630 --> 00:13:53.870
All'inizio sembra avere senso.

00:13:54.390 --> 00:13:55.630
Più condizioni di monitoraggio

00:13:55.630 --> 00:13:56.570
dovrebbero significare

00:13:56.570 --> 00:13:57.890
più opportunità di reagire

00:13:57.890 --> 00:13:59.490
ma ogni trigger

00:13:59.490 --> 00:14:00.050
che definisci

00:14:00.050 --> 00:14:01.370
contribuisce al carico di lavoro

00:14:01.370 --> 00:14:02.150
sulla tua capacità

00:14:02.150 --> 00:14:02.750
Fabric.

00:14:03.970 --> 00:14:04.390
Ciò significa

00:14:04.390 --> 00:14:05.070
che stai consumando

00:14:05.070 --> 00:14:05.750
la stessa capacità

00:14:05.750 --> 00:14:06.310
che supporta

00:14:06.310 --> 00:14:07.170
i tuoi aggiornamenti BI

00:14:07.170 --> 00:14:07.890
i tuoi data flow

00:14:07.890 --> 00:14:08.650
e le tue query

00:14:08.650 --> 00:14:09.430
nel warehouse.

00:14:10.350 --> 00:14:10.810
Se esageri

00:14:10.810 --> 00:14:11.730
vedrai un effetto a catena

00:14:11.730 --> 00:14:12.870
in cui altri carichi di lavoro

00:14:12.870 --> 00:14:13.670
rallentano

00:14:13.670 --> 00:14:14.430
perché i tuoi trigger

00:14:14.430 --> 00:14:15.990
stanno consumando risorse di calcolo.

00:14:17.150 --> 00:14:17.750
La pianificazione

00:14:17.750 --> 00:14:18.270
della capacità

00:14:18.270 --> 00:14:19.110
non è facoltativa qui

00:14:19.110 --> 00:14:19.950
poiché è la disciplina

00:14:19.950 --> 00:14:20.370
che impedisce

00:14:20.370 --> 00:14:20.830
l'automazione

00:14:20.830 --> 00:14:21.390
di trasformarsi

00:14:21.390 --> 00:14:22.530
in tempi di inattività auto-infriti.

00:14:22.910 --> 00:14:23.390
Anche gli obiettivi

00:14:23.390 --> 00:14:23.930
di ratenza sempre.

00:14:24.470 --> 00:14:25.190
Data Activator

00:14:25.190 --> 00:14:26.410
può reagire in pochi secondi

00:14:26.410 --> 00:14:27.150
ma solo se i sistemi

00:14:27.150 --> 00:14:27.770
a monte e a valle

00:14:27.770 --> 00:14:28.450
possono gestire

00:14:28.450 --> 00:14:29.350
tale velocità.

00:14:30.070 --> 00:14:30.690
Se la tua chiamata

00:14:30.690 --> 00:14:31.750
API attivata

00:14:31.750 --> 00:14:32.690
punta a un'integrazione

00:14:32.690 --> 00:14:33.170
ERP

00:14:33.170 --> 00:14:33.850
elaborata a blocchi

00:14:33.850 --> 00:14:34.670
ogni 15 minuti

00:14:34.670 --> 00:14:35.770
ti sei effettivamente

00:14:35.770 --> 00:14:36.690
creato dei ritardi

00:14:36.690 --> 00:14:37.410
intrinseci

00:14:37.410 --> 00:14:39.170
il trigger viene eseguito

00:14:39.170 --> 00:14:39.970
ma il risultato finale

00:14:39.970 --> 00:14:40.550
resta in attesa

00:14:40.550 --> 00:14:41.450
fino al blocco successivo.

00:14:42.190 --> 00:14:42.770
Quelle differenze

00:14:42.770 --> 00:14:43.650
nel ritmo di servizio

00:14:43.650 --> 00:14:44.170
vanno mappate

00:14:44.170 --> 00:14:44.750
prima di iniziare

00:14:44.750 --> 00:14:45.490
a collegare i sistemi

00:14:45.490 --> 00:14:45.930
tra loro.

00:14:47.150 --> 00:14:47.850
La strada più sicura

00:14:47.850 --> 00:14:48.190
è iniziare

00:14:48.190 --> 00:14:48.890
con condizioni

00:14:48.890 --> 00:14:49.710
ad alto valore

00:14:49.710 --> 00:14:50.690
e bassa frequenza.

00:14:51.330 --> 00:14:51.810
Ciò significa

00:14:51.810 --> 00:14:52.490
scegliere scenari

00:14:52.490 --> 00:14:53.270
in cui anche se attivi

00:14:53.270 --> 00:14:53.650
il sistema

00:14:53.650 --> 00:14:54.650
solo poche volte al giorno

00:14:54.650 --> 00:14:55.310
ogni evento

00:14:55.310 --> 00:14:56.250
ha un impatto chiaro

00:14:56.250 --> 00:14:56.730
che giustifica

00:14:56.730 --> 00:14:57.370
l'automazione.

00:14:58.210 --> 00:14:59.070
Si tratta di dimostrare

00:14:59.070 --> 00:14:59.610
l'efficacia

00:14:59.610 --> 00:15:00.650
senza inondare

00:15:00.650 --> 00:15:01.310
la tua capacità

00:15:01.310 --> 00:15:02.070
o sovraccaricare

00:15:02.070 --> 00:15:02.870
i servizi a valle.

00:15:04.150 --> 00:15:04.930
Ottimizzi la logica

00:15:04.930 --> 00:15:05.450
del trigger

00:15:05.450 --> 00:15:06.510
comprendi il profilo

00:15:06.510 --> 00:15:07.130
di elaborazione

00:15:07.130 --> 00:15:07.710
e solo allora

00:15:07.710 --> 00:15:08.790
inizia a espanderti.

00:15:09.690 --> 00:15:10.190
Vale anche la pena

00:15:10.190 --> 00:15:11.230
ricordare che il prezzo

00:15:11.230 --> 00:15:11.890
e la capacità

00:15:11.890 --> 00:15:12.450
non riguardano

00:15:12.450 --> 00:15:13.370
solo l'archiviazione

00:15:13.370 --> 00:15:14.270
o gli aggiornamenti.

00:15:15.030 --> 00:15:15.490
La valutazione

00:15:15.490 --> 00:15:15.910
dei trigger

00:15:15.910 --> 00:15:16.490
e l'esecuzione

00:15:16.490 --> 00:15:16.950
delle azioni

00:15:16.950 --> 00:15:17.750
consumano risorse

00:15:17.750 --> 00:15:18.390
dello stesso pool.

00:15:18.710 --> 00:15:19.330
Con la chiamata API

00:15:19.330 --> 00:15:19.790
in uscita

00:15:19.790 --> 00:15:20.810
calcolo tu.

00:15:21.190 --> 00:15:21.850
La trasformazione

00:15:21.850 --> 00:15:22.430
che esegui prima

00:15:22.430 --> 00:15:23.470
di verificare una condizione

00:15:23.470 --> 00:15:24.450
richiede anche se calcoli.

00:15:25.290 --> 00:15:26.230
Se aumenti condizioni

00:15:26.230 --> 00:15:26.970
e connessioni

00:15:26.970 --> 00:15:27.870
senza considerare

00:15:27.870 --> 00:15:28.210
il pool

00:15:28.210 --> 00:15:29.230
sulle tue unità fabric

00:15:29.230 --> 00:15:29.910
raggiungerai

00:15:29.910 --> 00:15:30.550
i limiti

00:15:30.550 --> 00:15:31.530
prima del previsto.

00:15:32.650 --> 00:15:33.270
La buona notizia

00:15:33.270 --> 00:15:33.750
è che una volta

00:15:33.750 --> 00:15:34.350
noti i limiti

00:15:34.350 --> 00:15:34.870
per progettare

00:15:34.870 --> 00:15:36.050
le soluzioni aggirandoli.

00:15:36.050 --> 00:15:37.410
costruisci i processi

00:15:37.410 --> 00:15:37.810
che si otto