Krijgen we nu de volgende melding na een aantal van zulke fouten:
itgeneor229
Er is geen dagcapaciteit meer beschikbaar voor Exact Online API gebruik op Exact Online divisie ‘108 - … B.V. (2557641)’.
Optimaliseer uw API-gebruik of neem contact op met Exact Online Support om meer API-aanroepen per dag te krijgen dan de huidige limiet van 5,000-aanroepen, of probeer het morgen opnieuw.
(ExactOnlineREST.Incremental.TransactionLinesIncremental).
Kan het zijn dat bij/door/voor de eerste fout, Invantive veel calls (per keer) genereert?
Voor zover wij kunnen checken lopen enkel calls via Invantive, maar ik kan deze specifieke aantallen niet monitoren.
Voor de genoemde divisie zijn er vandaag in het scherm Sessie I/O’s op Invantive Cloud 5.043 API-calls zichtbaar, waarvan een deel niet geslaagd is. Dit scherm is te vinden in het menu aan de linkerzijde onder “Sessie I/O’s” of rechtstreeks via deze URL.
Op basis van dit aantal klopt de itgeneor229 melding (voor Exact Online XML API’s kan om vergelijkbare redenen itgenexl150 optreden).
Analyse
Het scherm Sessie I/O’s toont alle geregistreerde calls, zowel voor on-premises als online applicaties vanaf 0:00 UTC. Oudere API-calls zijn alleen geaggregeerd beschikbaar via bijvoorbeeld “Monthly Aggregated Session I/Os” onder het menu “Diagnostics”
Advies is om de sessie I/O’s bijvoorbeeld naar Excel te exporteren en te analyseren:
Kies eerst “Show All entries”.
Kies daarna de knop “Export to Excel” in het scherm.
De export duurt circa 10 seconden.
Open het Excel werkboek.
Maak via bijvoorbeeld een draaitabel een analyse te maken van de meestgebruikte tabellen.
Op basis daarvan kan het gebruik geoptimaliseerd worden.
Er worden veel calls gedaan naar de Exact Online sync API. Dit is hetzij een bug in de Invantive Exact Online SQL driver, hetzij er zijn gewoon veel rijen (pakweg meer dan 5.000 miljoen boekstukregels) die voor de eerste keer opgehaald worden.
Advies is om morgen zoals beschreven met de “Supersnel schatten”-methode in Schatten omvang Exact Online administratie een telling uit te voeren van de omvang. Gelieve voor de grootste tabellen deze hier toe te voegen als antwoord.
Ik zal morgen de grote van de tabellen checken, maar ik schat dat de volledige tabel TransactionLinesIncremental rond de 2 miljoen regels zal zijn, de gefilterde tabel (na onze selectie criteria) 80-90 duizend.
Ik zie wel het volgende vanuit de link die je mee gaf. Er zijn vele calls (soms honderden achter elkaar) die 0 regels teruggeven. Bijvoorbeeld de volgende drie, waarbij de rest ook enkel in de ‘skiptoken’ verschilt:
Helaas klopt de waarde in de kolom “Rijen” niet. Die is momenteel altijd 0, ook als het 1.000 is. Dit wordt in een volgende release opgelost, maar kan langere tijd duren.
Het skiptoken geeft (in dit geval) een positie in een opvolgende reeks aan en een wijziging betekent normaliter een nieuwe reeks data.
Bij het initieel opstellen van TransactionLinesIncremental zullen alle rijen gedownload worden. Bij 2 miljoen regels zijn dat 2.000 API calls. Daarna kan pas gefilterd worden; dit is een zij-effect van de door Exact gemaakte strategische keuzes vorig jaar.
Het ophalen van het aantal rijen op deze manier lukt helaas niet, de $count manier geeft vanwege rechten geen resultaat.
Qua calls lijkt het erop dat dezelfde set rijen opgehaald worden, wat faalt, waardoor er per keer 50+ calls gedaan worden.
Het zal inderdaad via $count moeten. Waarschijnlijk zijn het meer dan 5 minuten rijen en sowieso zal het waarschijnlijk langer dan 3 minuten duren (de ingestelde maximale duur van een query op de SQL editor op Invantive Cloud).
Echter, het moet kunnen qua rechten voor specifiek TransactionLinesIncremental, maar waarschijnlijk zijn er onvoldoende rechten op andere tabellen. Gelieve de waarde van fail_on_error op true in plaats van false in te stellen. Hij zal dan de tabellen waar er geen rechten op zijn stilletje overslaan.
De false in het artikel voor het schatten is uitgebreid met commentaar om dat duidelijker te maken.
Ook nog een opmerking hierbij: “Bij het initieel opstellen van TransactionLinesIncremental[…]” We gebruiken deze tabel ondertussen een aantal maanden. Het lijkt hetzelfde issue te zijn als ik in de OP beschreef, alleen nu zijn er dus twee dingen bij gekomen:
Het issue treed altijd op i.p.v. af en toe.
Het issue zorgt voor excessieve API calls, wat uiteindelijk tot een time-out lijdt.
Het eigenaardige is dat eenzelfde URL zoals https://start.exactonline.nl/api/v1/2557641/sync/financial/TransactionLines?$filter=Timestamp%20gt%208293365310L&$select=*&$skiptoken=8300166561L tien keer in een korte tijd opgehaald wordt zoals zichtbaar in het scherm Sessie I/O’s. Dezelfde URL komt terug op:
Positie
Tijd
7
09:59:08
278
10:04:56
531
10:10:40
807
10:16:25
1061
10:22:06
1363
10:27:50
1621
10:33:35
1896
10:39:19
2042
10:42:20
2179
10:45:02
De waarde voor het Exact Online skiptoken (de positie in de oplopende reeks) varieert tot maximaal 8300542239. Het lijkt alsof de download afgebroken wordt en enige tijd later opnieuw gestart.
Een analyse tussen 10:04:00 en 10:05:00 geeft aan dat er dan 269,000 rijen opgehaald zijn als om 10:04:52 de download afgebroken wordt doordat het downloadende programma verdwijnt op IP-adres “::ffff:40.74.30.107”.
En dat lijkt in combinatie met het IP-adres van Microsoft op PowerBI.com.
Volgens de log zou er een foutmelding getoond moeten zijn en een begeleidende e-mail gestuurd met tekst:
itgenboe161
De gegevensdownload werd geannuleerd na 5 minutes, 46 seconds, waarschijnlijk door de gebruiker.
Optimaliseer uw query zoals beschreven op https://go.invantive.com/en/power-bi-tuning.
Voer vervolgens de query opnieuw uit.
PowerBI.com heeft niet altijd even stabiele downloads. De HTTP en response cache maken dat de impact daarvan beperkt is. Een idee is geregistreerd om ook het initieel laden van de incrementele tabellen minder afhankelijk te maken van de stabiliteit en inrichting.
Op dit moment zien we bij meerdere gebruikers dat PowerBI.com opeens na 5 minuten de “hoorn” er op
gooit, onafhankelijk van de time-out instelling. De oorzaak is onbekend; mogelijk is dit een bug in PowerBI.com.
Het is aan te bevelen dit bij Microsoft via een ticket te melden.
Als workaround beveel ik aan om eenmalig via Power BI Desktop het rapport te verversen. Daarna is de data initieel geladen na pakweg 30…120 minuten en zal het ook via PowerBI.com significant sneller gaan.
Deze week zal ook gekeken worden of we het idee kunnen realiseren zodat dergelijke problemen zich minder voordoen en ook datasets met meer dan 5 miljoen rijen zonder exceptie bij Exact Online opgebouwd kunnen worden.
Het initieel laden van Exact Online tabellen met meer dan 5 miljoen rijen wordt nu ook ondersteund. De data kan over meerdere dagen verspreid geleidelijk geladen worden. Hier is geen configuratie voor nodig, anders dan zekerheidshalve de twee cache waardes op de database initieel op 7 dagen te zetten (604800 seconden).
