Delay / Vertraging in de ExactOnline PowerBI connector?

Power BI Exact Online Cache

Het antwoord op vragen vanuit Power BI aan het achterliggende platform (hier: Exact Online) wordt apart onthouden en gedurende een instelbare tijd telkens teruggegeven als dezelfde vraag nogmaals terugkomt. De “koffie” wordt warm gezet en daarna nog een tijdje op het warmhoudplaatje als van “acceptabele smaak” geserveerd.

Het verversmoment is niet per definitie een vaste tijd zoals bij ouwerwetse datawarehouses die apart geladen worden (push-principe met ontkoppeling). Als het eerste verzoek in dit geval voor ReceivablesList komt om 06:38:23 UTC, dan zal dat het startpunt van de timer zijn (pull-principe).

Een algemene uitleg is te vinden in Differentieer OData4 cachegedrag met Power BI.

Een vergelijkbare vraag met antwoord is Refresh-frequentie Exact Online.

Recent is de minimale waarde voor de meeste abonnementen verlaagd naar 1 uur. Een hogere waarde is aan te bevelen voor optimale prestaties gedurende het ontwikkelen van Power BI rapporten.

Recente optimalisaties voor meer snelheid zijn te vinden in Sneller data verwerken uit Invantive Cloud op geselecteerde OData-clients.

Update mei 2022

Sinds kort is het ook mogelijk om de cache handmatig te legen, zodat de gebruiker ook zelf kan bepalen dat echt verse data nodig zijn. Gebruik hiervoor de optie “Reset cache” in het menu rechtsboven van Invantive Bridge Online:

image

ReceivablesList

Ik kan het niet met zekerheid uit de vraag destilleren, maar mogelijkerwijs speelt nog een ander punt. In de ochtend verwerkt Exact Online meestal de bankmutaties. Dit leidt bij automatisch afletteren tot mutaties in de lijst van openstaande punten. Het inlezen van bankmutaties heeft - zoals ook zichtbaar op de statuspagina - regelmatig problemen. Het is onbekend bij mij of het inlezen ook wel altijd binnen een vaste tijdsperiode gebeurt of dat er onder de storingen ook nog meer fluctuaties zitten in het uitwisselen van bestanden met o.a. de banken. De Invantive statuspagina laat wel de responsetijden van Exact Online API’s zien, maar niet de informatie die Exact zelf al publiceert.

Om minder last te hebben van de inleesprobemen in het bankboek en ook recente mutaties uit de bankafschriften mee te nemen is het misschien verstandig om het ophalen van de openstaande posten niet te vraag te plannen. Een zinvol tijdstip is de tijd waarop de meeste mensen naar kantoor gaan.

Als Exact Online op dat moment qua bankboek nog niet bij zou zijn, dan zouden ze massaal gebeld worden. Dat geeft voldoende druk om te zorgen dat de gebruiker niet als enige aan de bel hoeft te trekken.

Voor openstaande posten valt het gebruik van AROutstandingItems en APOutstandingItems aan te raden; deze zijn veel sneller en kennen ook een variant waarbij de peildatum opgegeven kan worden zoals met APOutstandingItemsPerFinancialYearUltimo: Exact Online Openstaande Inkoopfacturen per Ultimo Boekjaar - Exact Online API Data Model.