Itgeneor229 bij kleine administratie

Vragen
, ,
1

Op een Exact database van een klant van ons krijg ik steeds vaker foutmelding itgeneor229, waarin aangegeven wordt dat ik over de 5000 API-aanroepen heen ga op een dag. Hierbij gaat het om de volgende Query:

Tabelnaam: ExactOnlineREST.Incremental.TransactionLinesIncremental SQL Select-statement:

select t.*
from   ExactOnlineREST.Incremental.TransactionLinesIncremental@eol t
where  ([FinancialYear] >= :w1)

Hierbij wordt gekeken naar de transactielijnen vanaf 2023, wat in de praktijk gaat om iets minder dan 200,000 rijen.

Dit is dus een kleine database welke niet altijd dit probleem vertoond en welke het eerder zonder problemen gedaan heeft.

Sinds gisteren krijg ik ook onderstaande foutmelding van PowerBI en werkt de refresh ook niet meer:

OData:
Request failed:
The underlying connection was closed:
An unexpected error occurred on a receive..
Microsoft.Data.Mashup.ErrorCode = 10122.
DataSourceKind = OData.
DataSourcePath = https://bridge-online.cloud/acme-exactonline/odata4/ExactOnlineREST.Incremental.TransactionLinesIncremental@eol.
The exception was raised by the IDbCommand interface.
Table: Incremental - Transaction Lines Incremental.

Ook refreshen in de desktop werkt momenteel niet voor de transactielijnen tabel. Andere tabellen zoals AccountsIncremental refreshen hier wel.

Graag kom ik in contact om te kijken hoe we dit zo snel en efficiënt mogelijk op kunnen lossen.

2

Via het scherm Systeemberichten is itgeneor229 terug te vinden. Het betreft een administratie met divisiecode 1784267. De tabel waarbij itgeneor229 optreedt is niet altijd degene die het probleem veroorzaakt; de oorzaak ligt meestal eerder doordat er 5.000 API-calls reeds geweest zijn die dag.

Via het scherm Sessie I/O’s is te achterhalen welke I/O’s er geweest zijn. Kies “Show all entries” en vul rechtsboven de divisiecode in in het zoekfilter en exporteer de rijen naar een Excel-sheet.

Het gaat om ruim 14.000 API-calls op deze administratie.

Groepeer deze op tabelnaam in Excel met een draaitabel:

image
image764×388 12.4 KB

Circa 9.000 calls die sowieso gefaald zijn, maar het lijkt er op dat SalesEntries, PurchaseEntries en Receivables geoptimaliseerd (of vervangen) dienen te worden.

Zie voor meer tips:

3

Dank voor de snelle reactie.

SalesEntries, PurchaseEntries en Receivables zijn relatief kleine tabellen, respectievelijk halen deze (zonder filtering) 41K rijen, 20K rijen en 42K rijen binnen. Dit zijn dus relatief kleine tabellen.

Voor mij is het echter niet duidelijk waarom deze tabellen zoveel API-calls veroorzaken en hoe we dit op kunnen lossen en dus kunnen optimaliseren/vervangen. Als ik de bijgevoegde artikelen lees, is de oorzaak kennen cruciaal om te kunnen optimaliseren.

Wat mij vooral verbaasd is ook het feit dat het niet elke dag/refresh zo is, maar sporadisch.

Ik ontvang hier graag meer informatie over.

4

Het volledig ophalen van 41K rijen uit bijvoorbeeld SalesEntries veroorzaakt circa 800 API-calls (41.000 / 60 paginagrootte). Dit is terug te vinden in het scherm Sessie-I/O’s. Exact Online kent verschillende API’s, met verschillende paginagroottes. De gangbare waardes zijn:

  • 100 per XML API-call
  • 60 per REST API-call
  • 1.000 per REST API-call *Bulk
  • 1.000-1.000.000 per REST API-call *Incremental

Beste is de genoemde adviezen te volgen qua filtering en frequentie verversing, of te vervangen door efficientere aanroepen.

Zodra eenmaal de daglimiet overschreden is voor een administratie, zullen alle volgende verzoeken die niet uit cache beantwoord kunnen worden altijd een foutmelding geven. De hoeveelheid API-calls gebruikt bepaalt het moment van optreden.

5

Wederom bedankt voor de reactie.

Voor zo ver ik begrijp zijn de tabellen SalesEntries, PurchaseEntries en Receivables van een type wat veel API-calls veroorzaakt.

Echter, bij andere soortgelijke dashboards zie ik niet hetzelfde probleem en het blijft voor mij een vraag waarom dit ineens problematisch is.

Momenteel staat de verversing van dit dashboard op 1x per dag, ‘s nachts, en de verversing lukt dan niet, terwijl het tot voor kort mogelijk was om meerdere keren op een dag te verversen.

Als ik de adviezen lees komt het kortweg neer op de volgende oplossingen;

  • Filteren van de tabellen; dit zijn relatief kleine tabellen waarvan alle informatie nodig is.
  • Minder vaak verversen; ik ververs nu maar 1x per dag, wat niet lukt. We willen graag de mogelijkheid terug hebben om meerdere keren per dag te verversen, maar minder kan in ieder geval niet.
  • Andere tabellen gebruiken met *Incremental; voor zo ver ik weet zijn er geen soortgelijke tabellen met een incremental refresh.

Ik dan ook ontvang graag concrete oplossingen hoe we er voor kunnen zorgen dat de refresh weer gaat werken, met behoud van de tabellen en alle rijen. Ook blijf ik benieuwd naar de achterliggende reden waarom dit probleem zich nu ineens voordoet terwijl dit voorheen niet was én andere soortgelijke dashboards deze problematiek niet ervaren.

6

Voor de optimalisatie van rapporten is advies om contact te zoeken met een van onze partners. Brede vragen zoals bovenstaande zijn niet praktisch te behandelen via deze forums.