Sinds de 26.0.X versie van Data Hub lopen we tegen het bereiken van de dagelijkse limiet van de API calls aan voor een Exact Online-dossier. Voordien was dit nog niet het geval.
Momenteel analyseren we waar het probleem zit, in het vernieuwingsschema was de SalesOrderLines endpoint nog opgenomen met 312k+ rijen wat een logische oorzaak vormde voor een hoog verbruik. Deze werd voorlopig uit de vernieuwing gehaald.
Doch lopen we terug tegen de limiet aan, hieronder een overzicht van de endpoints en een ruwe inschatting van het verwachtte aantal calls.Dit resulteert in een verwacht aantal calls van om en bij de 3.4k (in acht genomen dat hier waarschijnlijk nog andere calls rond hangen voor refresh tokens e.d.).
Hierdoor blijven we naar inschatting onder de limiet van 5k per dag, zien we iets over het hoofd waardoor het aantal calls drastisch hoger zou zijn dan de inschatting?
Advies is om de aantallen API-calls aan te sluiten bij het aantal rijen. Dat kan snel via de tips op:
Een *Incremental zal normaliter pakweg 1.000 API-calls alleen doen bij initiele load of als er iets mis is (bijvoorbeeld te grote deviatie tussen wat in cache staat en wat aantal rijen is).
Uit de 4 API-calls bij (deleted) is in ieder geval af te lezen dat er vier keer een volledige actualisatie heeft plaatsgevonden in de gemeten periode.
Dat kan geanalyseerd worden door in Sessie-I/O’s te kijken hoe laat en binnen welke sessie-ID de calls plaatsvinden.
Iets vergelijkbaars geldt voor *Bulk-tabellen: in het scherm Sessie-I/O’s biedt aanknopingspunten om te achterhalen wanneer er ververst wordt. Anders dan bij *Incremental zal echter iedere verse laadactie (uitgaande van 300K rijen in SalesInvoiceLinesBulk) circa 300 API-calls veroorzaken. Als een seconde later nogmaals dezelfde query draait, dan genereert dat ook weer pakweg 300 API-calls, etc.
Dit kan aansluiten bij de 4 API-calls bij (deleted). Mogelijk dat een script herhaaldelijk heeft gedraaid binnen de gemeten periode.
Het script start op 07.30 CET op via Windows Taakplanner en maakt hierbij een log bestand, op serverniveau kan ik maar één log bestand vinden.
De I/O’s zijn allemaal afkomstig van de run dat deze ochtend gestart werd en sluiten qua tijdstip aan met de logs:
Start:
2026-07-03 05:30:12.399 Information itgensql264: Invantive UniversalSQL statement started.
Stop:
2026-07-03 09:20:22.922 Error itgencun016: Error itgeneor229: There is no daily capacity remaining available for Exact Online API use on Exact Online division ‘……’.
Please optimize your API use, or contact Exact Online Support to acquire more API calls per day than the current limit of 5 000 calls, or try again tomorrow.
Het bestand met de queries volgt volgende opbouw:
use 123@eolbe;
SELECT /*+ ods(true, interval '1 seconds') */ count(*) FROM ExactOnlineREST.SalesOrder.SalesOrderLinesBulk@eolbe;
SELECT /*+ ods(true, interval '1 seconds') */ count(*) FROM ExactOnlineREST.SalesOrder.SalesOrdersBulk@eolbe;
... other tables ...
use 456@eolbe;
SELECT /*+ ods(true, interval '1 seconds') */ count(*) FROM ExactOnlineREST.SalesOrder.SalesOrderLinesBulk@eolbe;
SELECT /*+ ods(true, interval '1 seconds') */ count(*) FROM ExactOnlineREST.SalesOrder.SalesOrdersBulk@eolbe;
... other tables ...
use 789@eolbe;
SELECT /*+ ods(true, interval '1 seconds') */ count(*) FROM ExactOnlineREST.SalesOrder.SalesOrderLinesBulk@eolbe;
SELECT /*+ ods(true, interval '1 seconds') */ count(*) FROM ExactOnlineREST.SalesOrder.SalesOrdersBulk@eolbe;
... other tables ...
Onderzoek met Claude AI werd doorlopen, dit met volgende input:
I/O’s van 03/07/2026 sync
Log van 03/07/2026 sync (fout)
Log van 10/06/2026 sync (succesvol, nog op v24)
Hierbij enkele punten die mogelijks relevant zijn?
Geen 1000 records / call
The fingerprint of the regression is in July's rows-per-call. From the I/O export, every large table in July returns almost exactly ~500 rows per call:
TransactionLines: 492,070 rows / 999 calls = 492/call
SalesOrderLinesBulk: 312,594 / 626 = 499/call
SalesInvoiceLinesBulk: 326,384 / 654 = 499/call
GoodsDeliveryLinesBulk: 298,456 / 598 = 499/call
Exact Online's bulk and sync endpoints return up to 1,000 rows per page. Getting a uniform ~500 across four independent tables isn't coincidence — it's a page size of 500, i.e. half-size pages, double the calls for the same data. Apply that doubling to TransactionLines plus the three bulk tables and you get roughly 1,800–1,900 calls that a 1,000-row page would have served in ~950.
ODS interval 1 sec
Wordt een incrementele tabel steeds aangevuld indien het “/*+ ods(true, interval ‘1 seconds’) */” element achterwege gelaten wordt?
Momenteel zou dit ervoor zorgen dat er steeds een volledige sync plaatsvindt?
Advies is om de relatie te leggen naar tijdstippen; het klinkt als meerdere loads. Exact Online kent alleen door Exact precies voorgeschreven paginagroottes.
De hint ods heeft geen invloed op de logica voor incrementele tabellen of HTTP caches; zie ook:
Bedankt voor de feedback. Ik heb de I/O’s per tijdstip naast het logbestand gelegd zoals geadviseerd, en het beeld van meerdere loads wordt bevestigd. Vandaag loopt de vernieuwing terug en volgen we op of dit terug een limiet zal triggeren.
Inzichten van AI:
Context: Data Hub 26.0.167. De refresh liep op 03/07 van 05:30 tot de crash om 09:20:22 op itgeneor229 (“no daily capacity remaining … the current limit of 5 000 calls”). De I/O-export bevat 6 004 requests, waarvan ~5 990 binnen dit ene venster.
1. Paginagrootte klopt. Per pass haalt Data Hub ~999 rijen/call op (bv. 312 594 rijen / 313 calls), dus de door Exact voorgeschreven ~1 000. Mijn eerdere “500/call” was een telfout: ik deelde het opgeslagen aantal rijen door het totaal aantal calls over twee passes.
2. Elke grote tabel wordt tweemaal opgehaald. Wanneer ik de requests op tijdstip sorteer, valt elke grote tabel uiteen in twee bijna identieke passes met een inactief gat ertussen (0 calls tijdens het gat), terwijl het log slechts één Downloaded … rows registreert:
Tabel
Pass 1
Pass 2
Log “Downloaded”
SalesOrderLinesBulk
05:34–05:45 (313 calls / 417 MB)
05:57–06:08 (313 calls / 421 MB)
312 594 rijen (1×)
SalesInvoiceLinesBulk
07:27–07:34 (327 calls)
07:40–07:48 (327 calls)
326 384 rijen (1×)
GoodsDeliveryLinesBulk
07:01–07:11 (299 calls)
07:17–07:26 (299 calls)
298 456 rijen (1×)
TransactionLinesIncremental
08:22–08:25 (500 calls)
08:38–08:42 (499 calls)
492 070 rijen (1×)
XML Items
07:54–07:57 (86 calls)
08:00–08:03 (86 calls)
—
De twee passes zijn byte-voor-byte symmetrisch (bv. 417 vs 421 MB voor SalesOrderLinesBulk). De data wordt dus één keer opgeslagen, maar twee keer over de lijn gehaald.
3. Impact op de daglimiet. De tweede passes zijn samen ~1 524 calls. Zonder die herhaling komt de run op ~4 480 calls — onder de limiet van 5 000. De overschrijding komt dus niet door paginagrootte of de sync-anchor, maar door de dubbele ophaling.
4. Vergelijking met een geslaagde run (09/06, Data Hub 24.0.445, zelfde ods=1s): het log toont daar één Downloaded … rows per tabel en de run eindigde zonder daglimiet, met vergelijkbare (zelfs grotere) volumes op divisiecode. Kanttekening: dat oudere log bevat geen I/O op requestniveau, dus ik kan het aantal calls voor juni niet exact tellen — de dubbele ophaling is enkel in de 26.0.167-export zichtbaar.
Vraag: kunnen jullie helpen verklaren waarom elke bulk/sync-tabel in twee passes wordt opgehaald? Concreet:
Triggeren de ODS-seeding én de daaropvolgende SELECT count(*) elk een aparte ophaling?
Waarop wacht de run tijdens het inactieve gat van ~6–12 min tussen de twee passes?