Langsom opdatering af Power BI fra Business Central – hvor opstår flaskehalsen?

Begynd med at præcisere symptomet. En rapport kan åbne hurtigt med gamle tal. Den kan også vise friske tal, men reagere langsomt på brugerens valg. Spørg derfor både den ansvarlige for dataopdateringen og medarbejderen, der bruger rapporten.

Vælg en identificerbar registrering, og følg den gennem løsningen. I illustrationen er T1 registreringen i BC, T2 tidspunktet, hvor udtrækket er tilgængeligt i SQL, T3 den færdige behandling i datawarehouse, T4 en afsluttet Import-modelopdatering, som indeholder registreringen, og T5 visningen i rapporten. Arkitekturen er et eksempel; jeres løsning kan have færre eller andre led.

Notér start, afslutning og ventetid mellem kørsler. Et hurtigt udtræk hjælper ikke på friskheden, hvis næste modelopdatering først starter senere. Brug Power BI-opdateringshistorik og relevante integrationslogs; ved API-udtræk kan BC-telemetri bidrage. Sammenlign tidsstempler i samme tidszone. Tiden fra T1 til T5 beskriver friskheden for den fulgte ændring. Rapportens indlæsningstid måles separat fra brugerens handling til færdig visning.

Ved direkte API- eller OData-udtræk bør I undersøge tabeller, kolonner, historik og selskaber. Flere års poster fra mange regnskaber giver en anden opgave end et afgrænset salgsudtræk. Kontrollér også fejl, gentagne forsøg og belastning under de relevante kørsler.

Query folding betyder, at understøttede Power Query-trin bliver oversat til forespørgsler, som udføres ved kilden. Filtre og kolonnevalg kan dermed begrænse det, der skal hentes. Transformationer og sammenkædninger kan ændre dette, så virkningen skal kontrolleres i den konkrete forespørgsel. Et filter i rapporten er ikke dokumentation for, at færre data blev overført.

Et deltaudtræk begrænser overførslen mellem kilden og næste datalag til relevante ændringer. BC2SQL kan indgå i dette led. Power BI incremental refresh opdeler derimod tabeller i modellen og opdaterer de partitioner, som politikken omfatter. Den ene mekanisme aktiverer ikke automatisk den anden.

Incremental refresh kræver egnet opsætning, datofiltrering og kontrol af, hvordan filtrene behandles ved kilden. Første indlæsning kan stadig være omfattende. Afklar især håndtering af ændringer, sletninger og efterposteringer uden for den valgte opdateringsperiode. Ellers risikerer I et hurtigt forløb, som ikke gengiver de nødvendige ændringer korrekt.

I Import arbejder rapporten med data, som er indlæst i Power BI-modellen. Nye kildedata bliver ikke synlige alene ved at genindlæse rapporten i browseren. Modellen skal først indeholde dem. Opdateringsplan, gennemløbstid og eventuelle fejl er derfor centrale.

Med DirectQuery sendes forespørgsler mod den understøttede datakilde, når rapporten bruges. Det flytter krav til blandt andet kildens svartid, model og belastning. Det gør ikke gamle data i et mellemliggende SQL-lag nye, og en åben rapportside er ikke automatisk konstant opdateret. Valget afhænger også af connector, kapacitet og licenser.

Hvis ventetiden opstår ved filtre og visualiseringer, kan Performance Analyzer hjælpe med at skelne mellem forespørgsler, DAX-beregninger og tegning af visualer. Undersøg relationer, beregninger og antallet af visualer frem for at antage, at BC-udtrækket er årsagen.

Bruger løsningen en gateway, skal dens kapacitet, tilgængelighed og forbindelse indgå i undersøgelsen. Ikke alle cloudforbindelser kræver en lokal gateway. Kontrollér desuden adgangsoplysninger, kildens tilgængelighed og samtidige opgaver. En kø eller en fejlet kørsel kan give gamle tal, selv om selve databehandlingen normalt er hurtig.

Aftal det nødvendige opdateringsbehov ud fra beslutningen: Skal medarbejderen reagere på en hændelse, eller skal ledelsen følge gårsdagens resultat? Den mulige frekvens afhænger af hele kæden samt modeltype, datamængder, kapacitet og licenser. Et planlagt starttidspunkt er ikke et løfte om et færdigt rapporttal.

Et datawarehouse er ikke en forudsætning for al Power BI. Microsofts standardapps til Business Central online kan være et relevant udgangspunkt for afgrænsede behov pr. selskab. Et eksisterende udtræk eller en model kan også forbedres uden at udskifte platformen.

BC2DWH er Zealand Datas SQL-baserede datawarehouse-løsning oven på BC2SQL. Den er relevant at undersøge ved store datamængder, SQL som backend eller fælles ledelsesrapportering på tværs af regnskaber, valutaer og dimensioner. SQL-udtræk, databehandling og Power BI skal fortsat tilrettelægges samlet; løsningen er ikke i sig selv en garanti for en bestemt hastighed.

Læs om BC2DWH og et fælles datagrundlag til Business Central. Som din betroede rådgiver begynder vi med behov og målinger. Resultatet skal være en begrundet prioritering af forbedringer, et aftalt kontrolgrundlag og en tydelig fordeling af ansvar.