Een dashboard is zo goed als de laatste run. Achter elk rapport lopen 's nachts, en vaak ook overdag, tientallen stappen: extracts uit het ERP en andere bronnen, transformaties naar feiten en dimensies, het verversen van de semantische modellen. Orkestratie zorgt dat ze in de juiste volgorde en op het juiste moment lopen; logging legt vast wat er liep, hoe lang, hoeveel rijen en welke fouten. Zonder die twee hoor je pas dat er iets mis is als een gebruiker het merkt.
Eén beeld van elke run
- Alle jobs op één plek, in plaats van per tool in Data Factory, Databricks en Power BI
- Fouten met de oorspronkelijke melding, gekoppeld aan de stap en het object
- Herhaalpogingen vastgelegd, dus een waarschuwing is zichtbaar ook als de run slaagde
- Trends in doorlooptijd en volumes, en de traagste stappen om te optimaliseren
Weten dat de cijfers klaar zijn
- Vóór het ochtendoverleg: zijn de cijfers van vandaag compleet?
- Een afgesproken tijd waarop data klaar is, en zicht op of die wordt gehaald
- Geen beslissingen op half geladen data
- Minder verrassingen rond de maandafsluiting
Laatste 24 uur: ging het goed?
- Job runs per job op een tijdlijn, gekleurd naar resultaat
- De stappen van een run per fase, met de duur van elke stap
- Tot op de activiteit: welke tabel, welk notebook, welke refresh
- Fouten en waarschuwingen met de melding uit de tool zelf
- Rijen geëxtraheerd en geschreven, en het moment waarop de data klaar was
De vraag die ertoe doet: is de data klaar?
Een gebruiker wil niet weten welke pipeline faalde, maar of de cijfers van gisteren erin staan. Daarom staat bovenaan het dashboard het moment waarop de data klaar was, en laat de trend zien of de afgesproken tijd is gehaald. Het technische detail zit één klik verder, voor wie het moet oplossen.
Waarom het framework het verschil maakt: omdat de volgorde in metadata staat en elke stap op dezelfde manier logt, is een nieuwe tabel of bron een regel in een configuratietabel, geen nieuwe pipeline met eigen logging. In de referentie-implementatie achter de screenshot: 5 connectors, waaronder Infor CloudSuite LN en Dynamics BC, 333 brontabellen, 29 transformatiestappen, 125 mapping-notebooks en 11 semantische modellen, aangestuurd door 18 pipelines.
Jobs en volgorde vastleggen
Welke bronnen, welke tabellen en welke stappen, met hun afhankelijkheden en hun planning.
Logging op elke stap
Extract, transform en load schrijven allemaal naar dezelfde log, in hetzelfde formaat.
Afspreken wanneer data klaar moet zijn
Eén afgesproken tijd per job, zodat de trend laat zien of die wordt gehaald.
Afspreken wie handelt bij een fout
Een dashboard laat het probleem zien; een eigenaar zorgt dat het wordt opgelost.
Problemen eerder dan de gebruiker
Een mislukte refresh is bekend voordat iemand een rapport opent.
Sneller herstel
De mislukte stap, het object en de melding in één regel.
Grip op doorlooptijd en kosten
De traagste notebooks en grootste extracts zijn de eerste kandidaten voor optimalisatie.
Aantoonbare betrouwbaarheid
Slagingspercentage en klaartijd over maanden, in plaats van een gevoel.
De screenshot toont het Axelio Orchestration-dashboard. De structuur (jobs, pipelines, tabellen, notebooks, semantische modellen) en de aantallen komen uit de referentie-implementatie van het Axelio BI Framework op Azure Data Factory, Azure Databricks en Power BI, met logging in Azure Log Analytics. Doorlooptijden, rijaantallen en fouten in de screenshot zijn demodata. Stand oktober 2026.