Itgeneor229 Exact API limiet na Itgenboe161

Terwijl we nog op Exact wachten bij het issue hieronder:

Itgenboe161: The data download was cancelled bij SalesEntries op Exact Online - invantive

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.

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.

Sync API

In deze case is het resultaat (zie ook plaatje):

Tabel Aantal Calls
TransactionLinesIncremental 4979
TransactionLinesIncremental met filter 3
AccountantInfo 1
AvailableFeatures 3
CustomerCooperations 33
SyncDeleted 24

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.

Dank voor je antwoord en de link.

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:

image

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.

Benieuwd naar het daadwerkelijke aantal.

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.

Na enkele aanpassing (komt alsnog niet door de forbidden(s) heen) gaf de api aan dat de tabel TransactionLines 1309591 regels bevat.

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:

  1. Het issue treed altijd op i.p.v. af en toe.
  2. 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”.

De user agent hiervan is:

Microsoft.Data.Mashup (Power Query documentation - Power Query | Microsoft Docs)

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 Overview of Power BI Performance and Download Size Improvement Techniques - invantive.
Voer vervolgens de query opnieuw uit.

Advies is om de stappen uit te voeren van genoemde URL; het belangrijkste is het verhogen van de time-out zoals beschreven in Vermijd time-out fout bij Power BI OData download

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.

Deze ontvang ik nu inderdaad ook, dank! Helaas stond de timeout al op een uur, dus ik vrees dat dat geen uitweg biedt voor dit probleem.

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).