WEBVTT 00:00:00.140 --> 00:00:07.520 Klaar voor 10 dagen Microsoft 365, Copilot, AI, Azure en de mensen die de toekomst van werk vormgeven? 00:00:07.940 --> 00:00:12.360 Deze januari is M365, kom terug en pakken we groter uit. 00:00:12.840 --> 00:00:18.420 Doe mee voor live sessies, praktijkdemo's en praktische kennis van MVP's en experts wereldwijd. 00:00:18.700 --> 00:00:21.480 Geen algemene slieders, geen eindeloos jargon. 00:00:21.760 --> 00:00:23.580 We pakken de echte uitdagingen aan. 00:00:23.780 --> 00:00:29.040 Copilot Studio, AI Agents, Fabric, Beveiliging, Governance en Automatisering. 00:00:29.040 --> 00:00:34.900 Of je nu IT-professional, ontwikkelaar of zakelijk leider bent, er zijn sessies speciaal voor jou. 00:00:35.240 --> 00:00:40.460 Met 10 volledige dagen kun je meerdere technologieën verkennen en contact leggen met een wereldwijde community. 00:00:40.880 --> 00:00:44.540 Kijk live mee en neem praktische inzichten mee terug naar je organisatie. 00:00:44.900 --> 00:00:49.180 Januari 2027, 10 dagen, 1 Microsoft Community. 00:00:49.460 --> 00:00:51.060 De inschrijving is nu geopend. 00:00:51.940 --> 00:00:53.240 Claim vandaag nog je plek. 00:00:55.360 --> 00:00:57.640 Dat is m365.com.net 00:00:57.640 --> 00:01:04.700 Meld je nu aan op m365.com.net en we zien je live in januari. 00:01:04.860 --> 00:01:08.320 Ooit afgevraagd of je dataactie kan ondernemen zonder dat je het hoeft aan te raken. 00:01:08.600 --> 00:01:11.060 Stel je voor dat je real-time een tekort in de voorraad ziet. 00:01:11.280 --> 00:01:16.000 En in plaats van een e-mail sturen of een dashboard checken, bestelt je systeem de voorraad gewoon voor je. 00:01:16.240 --> 00:01:17.440 Dat is geen hypothese. 00:01:17.720 --> 00:01:20.000 Dat is Fabric Data Activator in actie. 00:01:20.000 --> 00:01:25.260 Vandaag leggen we het verband tussen ruwe data, directe meldingen en geautomatiseerde reacties... 00:01:25.260 --> 00:01:30.520 en laten we zien hoe het samenwerkt met Power BI, Synapse en de rest van Microsoft Fabric... 00:01:30.520 --> 00:01:32.880 om inzichten direct om te zetten in actie. 00:01:33.480 --> 00:01:36.000 De ontbrekende schakel in je datacyclus. 00:01:36.320 --> 00:01:42.760 De meeste teams zeggen dat ze real-time werken, maar zodra je onder de motorkap kijkt, voelt het vaak eerder als de volgende dag. 00:01:43.620 --> 00:01:48.220 Dashboards verversen elke 15 of 30 minuten, soms slechts één keer per uur. 00:01:48.220 --> 00:01:55.360 Tegen die tijd is het patroon dat je moest opvangen al verschoven en is het rapport dat je bekijkt eerder een analyse achteraf dan een live feed. 00:01:55.740 --> 00:01:58.900 Je kijkt naar de samenvatting nadat de wedstrijd al is gespeeld. 00:01:59.140 --> 00:02:02.140 Het probleem is niet dat B-Tools niet laten zien wat er gebeurt. 00:02:02.400 --> 00:02:03.940 Daar zijn ze meestal heel goed in. 00:02:04.160 --> 00:02:06.880 Het ontbrekende stuk is wat er gebeurt nadat je het ziet. 00:02:06.880 --> 00:02:10.880 Op dit moment vertrouwen de meeste workflows op een mens om de verandering op te merken... 00:02:11.500 --> 00:02:14.220 te beslissen welke actie nodig is en deze uit te voeren. 00:02:14.440 --> 00:02:15.880 Dat creëert een knelpunt. 00:02:15.880 --> 00:02:20.820 Zelfs zoiets bazaals als een e-mail sturen naar klanten wanneer een bepaalde metriek daalt... 00:02:20.820 --> 00:02:25.940 is vaak handmatig werk omdat het systeem niet is ingericht om het inzicht direct aan de actie te koppelen. 00:02:26.820 --> 00:02:29.200 Door deze vertraging gaan veel kansen verloren. 00:02:29.460 --> 00:02:34.000 Een promotie die drie uur te laat wordt gelanceerd na een verkoopdiep verliest zijn urgentie. 00:02:34.000 --> 00:02:38.400 Een piek in website, fouten die onbehandeld blijft tot de volgende vergadering... 00:02:38.400 --> 00:02:41.020 kost ons conversies die we nooit meer terugkrijgen. 00:02:41.220 --> 00:02:45.740 De kloof tussen weten en handelen is precies waar Fabric Data Activator zich bevindt... 00:02:45.740 --> 00:02:48.200 en het is ontworpen om die kloof te verkleinen tot seconden. 00:02:48.340 --> 00:02:50.680 Omdat het inherent deel uitmaakt van Microsoft Fabric... 00:02:50.680 --> 00:02:56.400 hoef je met Data Activator niet constant gegevensbronnen te exporteren, te koppelen of te beheren. 00:02:56.540 --> 00:03:02.180 Het Laced Event streams terwijl ze plaatsvinden en reageert direct zodra aan een door jou gedefinieerde voorwaarde is voldaan. 00:03:02.180 --> 00:03:04.680 Het verschil is dat het niet stopt bij een waarschuwing... 00:03:04.680 --> 00:03:07.520 maar een kettingreactie kan veroorzaken in de rest van je systemen. 00:03:07.720 --> 00:03:11.980 Stel je voor een live verkoopveed die de prestaties in verschillende regio's bewaakt. 00:03:11.980 --> 00:03:15.960 Normaal gesproken zie je een plotselinge daling in één regio op je dashboard. 00:03:16.200 --> 00:03:20.800 Ga je op onderzoek uit, stel je een gericht aanbod op, krijg je goedkeuring en zet je de promotie live. 00:03:21.000 --> 00:03:22.160 Dat kan wel een uur duren. 00:03:22.440 --> 00:03:26.440 Met Data Activator kan diezelfde daling een vooraf goedgekeurde API aanroep... 00:03:26.440 --> 00:03:28.440 naar je marketing automatiseringssysteem activeren... 00:03:29.300 --> 00:03:31.940 waardoor binnen enkele minuten een gericht aanbod wordt gelanceerd... 00:03:31.940 --> 00:03:33.900 voordat concurrenten überhaupt een zwakte zien. 00:03:34.140 --> 00:03:35.900 Niet wachten tot de juiste persoon het opmerkt. 00:03:36.080 --> 00:03:38.860 Geen vertraging door beraadslaging over een voor de hand liggende stap. 00:03:38.860 --> 00:03:40.240 Dat is de echte omslag. 00:03:40.440 --> 00:03:44.520 Traditionele B-tools monitoren, Data Activator luistert en reageert. 00:03:44.740 --> 00:03:48.860 Bij een typische power bieferversingsfrequentie van bijvoorbeeld elke 30 minuten... 00:03:49.520 --> 00:03:52.940 loopt de detectie zelf al achter vanaf het moment dat de verandering begon. 00:03:53.900 --> 00:03:58.680 Data Activator triggers kunnen bijna in real-time reageren op event streams... 00:03:58.680 --> 00:04:01.140 binnen enkele seconden afhankelijk van de bron... 00:04:01.140 --> 00:04:04.260 waardoor het actiemoment veel nauwer aansluit bij de trigger zelf. 00:04:04.840 --> 00:04:08.940 En omdat het in Fabric is verweven, is het niet beperkt tot één dashboard of dataset. 00:04:09.260 --> 00:04:13.280 Het kan worden gekoppeld aan elk willekeurig onderdeel van het ecosysteem dat logisch is. 00:04:14.100 --> 00:04:17.980 Die streaming feed kan deel uitmaken van een Synapse data-pijplijn... 00:04:17.980 --> 00:04:20.880 die vervolgens meerdere downstream- en AI-modellen voedt. 00:04:21.880 --> 00:04:26.660 Als er iets belangrijks gebeurt, fluistert Data Activator niet alleen naar je dashboard. 00:04:26.660 --> 00:04:31.820 Het stuurt het signaal direct naar de systemen die de kans kunnen benutten of het probleem kunnen oplossen. 00:04:32.140 --> 00:04:34.600 Dit is de brug tussen observatie en uitvoering. 00:04:34.820 --> 00:04:40.300 In plaats van de chat van je team te vullen met ter info berichten die je medewerkers pas na de launch zien... 00:04:40.300 --> 00:04:41.960 voert het de volgende stap direct uit. 00:04:42.160 --> 00:04:47.520 Het verandert elke gekwalificeerde gebeurtenis in een besluit dat al is genomen en een actie die al is uitgevoerd. 00:04:47.760 --> 00:04:51.720 Wanneer je het vergelijkt met de standaard bie-workflow, is het voordeel duidelijk. 00:04:51.920 --> 00:04:53.860 Alleen monitoren vertelt je het verhaal. 00:04:53.860 --> 00:04:56.800 Monitoren plus reageren verandert het resultaat. 00:04:57.160 --> 00:05:01.220 En in een landschap waar kansen snel vervliegen, is dat verschil meer dan gemak. 00:05:01.420 --> 00:05:02.860 Het is concurrentievermogen. 00:05:04.220 --> 00:05:08.180 Laten we nu kijken hoe dit naadloos aansluit bij de tools waarmee je al werkt... 00:05:08.180 --> 00:05:10.580 zonder een extra laag complexiteit toe te voegen. 00:05:11.420 --> 00:05:13.640 Meer dan alleen waarschuwingen, het Fabric Web. 00:05:13.820 --> 00:05:17.420 Nog een teamspin sturen is geen automatisering, het is gewoon meer ruis. 00:05:17.420 --> 00:05:24.480 Je weet wel, dat soort, een vloedgolf aan pop-ups op elk scherm, die elk van je vragen om ergens naar te kijken dat er wel of niet toe doet. 00:05:24.880 --> 00:05:31.600 Eerst heb je het gevoel dat je alles onder controle hebt, maar al snel negeert je teamzen en gaan belangrijke zaken verloren in de chaos. 00:05:31.600 --> 00:05:37.520 De ironie is dat de systemen die je op de hoogte moeten houden, je vaak juist blinder maken. 00:05:37.900 --> 00:05:42.840 We hebben allemaal wel eens bij die maandagstaandap gezeten waarbij iemand vertelt dat ze een groot klantprobleem hebben gemist. 00:05:43.080 --> 00:05:45.180 Simpelweg omdat de melding op alle anderen leek. 00:05:45.320 --> 00:05:50.640 De kern van het probleem is niet een gebrek aan detectie, maar een gebrek aan intelligentie over wat de volgende stap moet zijn. 00:05:50.640 --> 00:05:57.680 Over gevoelige triggers behandelen elke kleine fluctuatie als een crisis en dat creëert een cultuur waarin iedereen getraind is om ze te negeren. 00:05:57.860 --> 00:06:03.900 Dit is waar de rol van Microsoft Fabric Data Activator, naast de rest van Microsoft Fabric, van belang begint te worden. 00:06:04.100 --> 00:06:09.900 Het is niet zomaar toegevoegd, het werkt direct naast Power BI, Synapse en de data warehousing van Fabric. 00:06:10.140 --> 00:06:15.140 Dat betekent dat het op hetzelfde speelveld werkt als de tools die je Analytics en Pipeline zal aansturen. 00:06:15.140 --> 00:06:21.000 In plaats van je te pingen bij elke kleine afwijking in een metrie, kan het beslissen of die afwijking de moeite waard is om het proces te stoppen. 00:06:21.200 --> 00:06:26.380 Zie het als een ouderwetse telefoniste, maar dan een die daadwerkelijk de urgentie achter elk gesprek begrijpt. 00:06:26.620 --> 00:06:32.060 Wanneer er iets gebeurt, bijvoorbeeld als een data feed een signaal stuurt dat de productnaam notatie tijdens het laden is verbroken. 00:06:32.340 --> 00:06:35.560 Data Activator weet welke lijnen verbonden zijn met de juiste systemen. 00:06:35.700 --> 00:06:38.840 Het stuurt het marketingteam niet een melding die ze pas morgen zullen lezen. 00:06:38.840 --> 00:06:45.000 Het stuurt het probleem direct door naar het systeem dat de foutieve lading kan bevriezen voordat deze stroomafwaartse rapporten vervuilt. 00:06:45.140 --> 00:06:46.640 Hier is een praktisch voorbeeld. 00:06:46.840 --> 00:06:51.080 Een Synapse Pipeline haalt elke paar seconden financiële transactiegegevens binnen. 00:06:51.280 --> 00:06:55.800 Een van de bronsystemen begint dubbele records te sturen vanwege een fout bij de leverancier. 00:06:56.000 --> 00:07:01.240 Als je alleen meldingen gebruikt, zie je een teamsbericht of e-mail met, hoi, dubbel aantal gedetecteerd. 00:07:01.440 --> 00:07:03.400 Dus nu staat het op iemands takenlijst. 00:07:03.400 --> 00:07:08.780 Met Data Activator in de mix kan de pipeline direct worden gepauzeerd zodra de dubbele gegevens binnenkomen, 00:07:08.960 --> 00:07:13.500 wat je data engineers de tijd geeft om de bron te herstellen voordat de slechte data in je warehouse belandt. 00:07:13.500 --> 00:07:17.840 De oplossing vindt plaats op systeemniveau, niet omdat iemand toevallig het dashboard aan het bekijken was. 00:07:18.060 --> 00:07:19.380 Dat is een cruciaal verschil. 00:07:19.620 --> 00:07:23.060 Data Activator is niet gebonden aan een enkele dataset of een beperkte stroom. 00:07:23.260 --> 00:07:29.660 Het werkt met verschillende invoertypen, gestructureerde warehouse tabellen, event streams en andere met fabric verbonden databronnen, 00:07:29.660 --> 00:07:33.620 waarbij dezelfde logische regels worden toegepast zonder dat jij ze in de gaten hoeft te houden. 00:07:33.800 --> 00:07:37.420 Door deze cross-surface rijkwijten weet het niet alleen wanneer er iets mis is. 00:07:37.420 --> 00:07:40.300 Het weet precies wanneer het moet remmen of gas moet geven. 00:07:40.800 --> 00:07:47.140 En omdat het in hetzelfde ecosysteem leeft als je transformatielogica en opslag, vecht het niet tegen de datastromen. 00:07:47.340 --> 00:07:48.560 Het zit erin verweven. 00:07:48.900 --> 00:07:57.140 Daarom kun je een keten opzetten waarin ingestie, transformatie, validatie en resolutie in één stroom gebeuren zonder dat mensen achter elkaar aan rennen voor overdrachten. 00:07:57.680 --> 00:08:04.340 Het is het verschil tussen reageren op data en je systemen halverwege laten aanpassen om de kwaliteit en tijdigheid te waarborgen. 00:08:04.340 --> 00:08:11.240 Maar het echte voordeel komt naar voren als je dit niet ziet als een waarschuwingstol, maar als een laag voor operationele besluitvorming. 00:08:12.260 --> 00:08:19.840 Het reageert op basis van context, wat de hoeveelheid ruis drastisch vermindert terwijl het percentage meldingen dat echt actie vereist toeneemt. 00:08:20.840 --> 00:08:22.600 Je wordt niet langer overspoeld. 00:08:22.960 --> 00:08:26.260 Je krijgt signalen boven de ruis uit met minder handmatig werk. 00:08:26.260 --> 00:08:36.200 En omdat die beslissingen daadwerkelijke veranderingen kunnen teweeg brengen, zoals jobs pauseren, records bijwerken of herstelacties starten, verkleint dit niet alleen de vertraging tussen weten en handelen. 00:08:36.380 --> 00:08:38.200 Het elimineert de kloof volledig. 00:08:38.400 --> 00:08:43.380 Laten we nu kijken naar het onderdeel dat opvalt, APIs aanroepen en communiceren met de wereld buiten Microsoft. 00:08:43.780 --> 00:08:49.100 Wanneer het systeem de buitenwereld aanroept, kan je data een telefoontje plegen nog voordat je de gemiste oproep ziet. 00:08:49.100 --> 00:08:58.060 Dat is geen figuurlijke uitspraak, we hebben het over dezelfde eventstream die je al volgt en die in realtime iets buiten het Microsoft Fabric Ecosysteem laat triggeren. 00:08:59.080 --> 00:09:10.720 In plaats van te wachten tot je een dashboard leest of op een Teams melding klikt, belt het systeem zelf, metaforisch of letterlijk, om actie te ondernemen in een andere applicatie zodra aan de voorwaarden is voldaan. 00:09:10.720 --> 00:09:22.180 De meeste bi-opstellingen falen precies hier. Ze zijn uitstekend in het tonen van inzichten, soms zelfs met flitsende visuals en AI-gestuurde toelichtingen, maar ze leggen de bal bij jou neer en verwachten dat jij actie onderneemt. 00:09:22.180 --> 00:09:31.340 Je moet nog steeds het CRM openen, de bestelling versturen, het erp bijwerken of het proces handmatig starten. Die kloof is waar de menselijke bottleneck weer toeslaat. 00:09:31.480 --> 00:09:37.960 Je detecteert het probleem misschien binnen minuten, maar de uitvoering volgt pas uren later omdat het wacht tot iemand tijd heeft om te handelen. 00:09:37.960 --> 00:09:46.260 Met Data Activator wordt die stap niet alleen verkort, hij is verdwenen. Stel je voor dat je voorraad halverwege de dag onder de besteldrempel zakt. 00:09:47.400 --> 00:09:53.500 In een normale opstelling ziet iemand bij Operations Lit in Powerbee, stuurt een bericht naar inkoop en wacht op bevestiging. 00:09:54.080 --> 00:09:57.220 Ondertussen verkoop je het product nog steeds en nader je een tekort. 00:09:57.760 --> 00:10:04.740 In plaats daarvan kan Data Activator direct een API-aanroep naar het bestelsysteem van je leverancier sturen zodra de data die grens overschrijdt. 00:10:04.740 --> 00:10:11.200 Een inkooporder wordt geplaatst, de levering staat in de wachtrij, niemand van je team heeft de melding nog gelezen en de oplossing is al in gang gezet. 00:10:11.400 --> 00:10:14.860 Dat is de waarde van het direct aansturen van externe processen vanuit Fabric. 00:10:15.020 --> 00:10:23.140 Je bent niet beperkt tot Microsoft Tools of het nu gaat om een SaaS CRM, een legacy ERP, een aangepast rest-eindpunt of zelfs de API van een partner. 00:10:23.440 --> 00:10:27.340 Je kunt die real-time trigger inzetten om de kloof tussen detectie en oplossing te dichten. 00:10:27.340 --> 00:10:38.620 De output kan zo simpel zijn als het posten van gegevens naar een webhoek of zo gestructureerd als het versturen van een geformateerde payload die een meerstaps workflow in een compleet ander platform activeert. 00:10:39.080 --> 00:10:47.940 Dit is het punt waarop Fabric niet langer slechts een verzameling analyse tools is, maar zich gaat gedragen als het centrale zenuwstelsel van je operationele omgeving. 00:10:48.520 --> 00:10:55.400 Wanneer er iets gebeurt, stuurt de zenuw niet alleen een signaal naar je ogen, maar geeft het ook instructies aan de ledematen die direct kunnen handelen. 00:10:55.400 --> 00:11:00.460 Zo ga je over van het monitoren van processen naar processen die zichzelf grotendeels reguleren. 00:11:00.620 --> 00:11:03.560 Je ziet dit terug in sectoren met een sterke focus op IoT. 00:11:04.300 --> 00:11:07.600 Stel je een fabriek voor met trilling-sensoren op kritieke machines. 00:11:08.500 --> 00:11:11.360 Deze sensoren streamen data in real-time naar Fabric. 00:11:11.600 --> 00:11:22.300 Zodra een meting in het bereik van een storingswaarschuwing komt, kan dataactivator een werkorder in Dynamics 365 aanmaken en toewijzen en een techniek eens inplannen voordat de machine überhaupt uitvalt. 00:11:22.300 --> 00:11:25.200 Geen supervisor hoeft hun dag te onderbreken om te bellen. 00:11:25.300 --> 00:11:29.740 Het systeem zet de taak automatisch uit, compleet met de context die de techniek eens nodig heeft. 00:11:30.720 --> 00:11:34.120 Reparatiewerkzaamheden starten voordat uitvaltijd überhaupt een onderwerp van gesprek wordt. 00:11:34.300 --> 00:11:39.000 De combinatie van geautomatiseerde monitoring en uitgaande apies is waar de echte autonomie begint. 00:11:39.180 --> 00:11:44.720 Je filtert niet alleen meldingen op relevantie, je koppelt die gefilterde triggers aan concrete acties die direct plaatsvinden. 00:11:44.720 --> 00:11:52.220 Dat is een sprong van data gestuurd naar data geactiveerd, waarbij het vermogen van het systeem om te reageren net zo snel is als het vermogen om te detecteren. 00:11:52.660 --> 00:12:02.020 Als je het goed instelt, slaan je processen niet alleen micromanagement over, ze verbeteren actief omdat de lust tussen detectie en actie strak, consistent en altijd actief is. 00:12:02.520 --> 00:12:08.480 Je kunt je concentreren op het ontwerpen van betere regels en logica in plaats van je zorgen te maken of iemand de melding wel heeft gezien. 00:12:08.480 --> 00:12:12.760 Maar zelfs het meest responsieve zenuwstelsel heeft drempelwaarde die je niet kunt negeren. 00:12:12.880 --> 00:12:16.540 En als je die niet kent voordat je begint, kunnen de resultaten snel rommelig worden. 00:12:17.040 --> 00:12:24.480 Ken de grenzen voordat je bouwt, elke automatiseringsheld heeft een ontstaansgeschiedenis en een lijst met valkuilen waarvan ze wensten dat ze die hadden zien aankomen. 00:12:25.500 --> 00:12:33.200 Bij Data Activator is de realiteit dat, hoewel het idee van detectie plus reactie grenzeloos klinkt, er een zeer praktisch kader onder ligt. 00:12:33.200 --> 00:12:43.200 Het is geen magie, het draait nog steeds op de architectuur van Fabric, gebonden aan dezelfde capaciteitsmodellen, servicelimieten en ontwerpuitgangspunten die gelden voor al het andere in het ecosysteem. 00:12:44.140 --> 00:12:49.980 Negeer die grenzen en je zult snel merken wat er gebeurt als goed bedoelde automatisering volledig tot stilstand komt. 00:12:50.220 --> 00:12:54.600 Het lastige is dat de knelpunten meestal niet naar voren komen tijdens je Proof of Concept. 00:12:54.920 --> 00:12:57.060 Bij een kleine test voelt alles onmiddellijk aan. 00:12:57.260 --> 00:13:01.160 Condities worden geactiveerd, acties uitgevoerd en je ziet het resultaat vrijwel direct. 00:13:01.160 --> 00:13:08.940 Pas als je opschaalt, meerdere externe systemen koppelt, het aantal triggers verhoogd en complexe logica toevoegt, laten de beperkingen hun tanden zien. 00:13:09.160 --> 00:13:11.700 Latentie loopt op, capaciteitsgebruik piekt. 00:13:12.140 --> 00:13:16.520 Plotseling wordt die real-time beslissings-engine vertraagd of in de wachtrij geplaatst. 00:13:16.960 --> 00:13:24.760 Denk eens na over wat er gebeurt als een trigger afhankelijk is van een bron die weliswaar technisch verbonden is, maar niet binnen de native services van Fabric draait. 00:13:25.200 --> 00:13:29.160 Misschien heb je een datastroom van een externe event-hap die je rapporten voedt. 00:13:29.160 --> 00:13:40.780 Als data-activator afhankelijk is van die feed voor een kritiek proces, maar het verwerkingsinterval aan de bronkant trager is dan de reactietijd van Fabric, krijg je nooit de responsiviteit die je verwacht. 00:13:40.980 --> 00:13:47.180 Ik heb uitholprojecten zien stagneren omdat condities gebaseerd waren op semi-statische data die de triggerlogica simpelweg niet kon bijhouden. 00:13:47.360 --> 00:13:50.480 De automatisering faalde niet, maar was simpelweg te laat om nog relevant te zijn. 00:13:50.480 --> 00:13:54.580 Er is ook de verleiding om alles in de gaten te houden. Dat lijkt in het begin logisch. 00:13:54.820 --> 00:14:02.480 Meer monitorcondities zouden meer reactiemogelijkheden moeten betekenen, maar elke trigger die je definieert draagt bij aan de werklast op je Fabric capaciteit. 00:14:03.580 --> 00:14:10.300 Dat betekent dat je dezelfde capaciteit verbruikt die ook je biverversingen, data flows en warehouse queries ondersteunt. 00:14:10.500 --> 00:14:16.640 Ga je te ver, dan zie je een domino-effect waarbij andere werklasten vertragen omdat je triggers de rekenkracht opslokken. 00:14:16.640 --> 00:14:22.660 Capaciteitsplanning is hier geen optie, maar de discipline die voorkomt dat automatisering verandert in zelf veroorzaakte uitvaltijd. 00:14:23.020 --> 00:14:24.340 Latentiedoelen zijn ook van belang. 00:14:24.560 --> 00:14:30.080 Data Activator kan binnen enkele seconden reageren, maar alleen als de upstream- en downstream-systemen die snelheid aankunnen. 00:14:30.220 --> 00:14:37.840 Als je getriggerde API aanroept naar een ERP-integratie wijst die elke 15 minuten in batches wordt verwerkt, heb je feitelijk ingebouwde vertragingen gecreëerd. 00:14:38.040 --> 00:14:41.960 De trigger wordt uitgevoerd, maar het eindresultaat wacht nog steeds op de volgende batch. 00:14:41.960 --> 00:14:46.720 Die verschillen in service-ritme moeten in kaart worden gebracht voordat je systemen aan elkaar koppelt. 00:14:46.880 --> 00:14:50.980 De veiligere route is beginnen met waardevolle condities die minder vaak voorkomen. 00:14:51.220 --> 00:14:58.080 Dat betekent scenario's kiezen waarbij, zelfs als ze maar een paar keer per dag worden geactiveerd, elke actie een duidelijke impact heeft die automatisering waard is. 00:14:58.260 --> 00:15:03.940 Het gaat erom de effectiviteit te bewijzen zonder je capaciteit te overspoelen of downstream-services te overbelasten. 00:15:04.160 --> 00:15:09.180 Je verfijnt de trigger-logica, begrijpt het verwerkingsprofiel en pas daarna ga je uitbreiden. 00:15:09.180 --> 00:15:14.420 Het is ook goed om te onthouden dat prijzen en capaciteit niet alleen over opslag of verversingen gaan. 00:15:14.640 --> 00:15:18.440 Trigger-evaluatie en de uitvoering van acties verbruiken middelen uit dezelfde pool. 00:15:18.660 --> 00:15:21.140 Die uitgaande API-aanroep, dat is rekenkracht. 00:15:21.340 --> 00:15:25.200 De transformatie die je uitvoert voor het controleren van een voorwaarde, kost ook rekenkracht. 00:15:25.380 --> 00:15:32.300 Als je voorwaarden en verbindingen opschaalt zonder rekening te houden met de capaciteit van je fabric units, bereik je sneller je limiet dan verwacht. 00:15:32.460 --> 00:15:36.440 Het goede nieuws is dat zodra je weet waar de limieten liggen, je daarop kunt ontwerpen. 00:15:36.440 --> 00:15:38.440 Je bouwt processen die zichzelf...