Siden versjon 26.0.X av Data Hub har vi nådd den daglige grensen for API-anrop for en Exact Online-fil. Tidligere var dette ikke tilfelle.
For øyeblikket analyserer vi hvor problemet ligger; i oppdateringsskjemaet var SalesOrderLines-endepunktet fortsatt inkludert med 312k+ rader, noe som utgjorde en logisk årsak til høyt forbruk. Dette ble midlertidig fjernet fra oppdateringen.
Likevel når vi igjen grensen, nedenfor en oversikt over endepunktene og en grov estimat av forventet antall anrop. Dette resulterer i et forventet antall anrop på rundt 3.4k (gitt at det sannsynligvis er flere anrop rundt for oppfrisknings-tokens osv.).
Dermed forblir vi etter estimatet under grensen på 5k per dag. Overser vi noe som gjør at antallet anrop er drastisk høyere enn estimatet?
Det anbefales å matche antall API-kall med antall rader. Dette kan raskt tilpasses ved hjelp av tipsene på:
En *Incremental vil normalt gjøre omtrent 1.000 API-kall kun ved en initial load eller hvis det er noen feil (for eksempel for stor avvik mellom det som er cachet og antall rader).
Fra de 4 API-kallene ved (deleted) kan man i hvert fall se at det har skjedd en full oppdatering fire ganger i den målte perioden.
Dette kan analyseres ved å se på Sessions-I/O for å finne ut når og innenfor hvilken session-ID kallene skjer.
Noe lignende gjelder for *Bulk-tabeller: i Sessions-I/O-skjermet finnes det ledetråder for å finne ut når det lastes inn på nytt. I motsetning til *Incremental vil imidlertid hver nye lastehandling (gitt 300K rader i SalesInvoiceLinesBulk) forårsake omtrent 300 API-kall. Hvis den samme spørringen kjøres igjen ett sekund senere, vil dette igjen generere omtrent 300 API-kall, osv.
Dette kan henge sammen med de 4 API-kallene ved (deleted). Det er mulig at et script har blitt kjørt gjentatte ganger i den målte perioden.
Skriptet starter kl. 07.30 CET via Windows Task Scheduler og lager en loggfil, på servernivå finner jeg bare én loggfil.
I/O-ene stammer alle fra kjøringen som startet denne morgenen og samsvarer tidsmessig med loggene:
Start:
2026-07-03 05:30:12.399 Information itgensql264: Invantive UniversalSQL-setning startet.
Stopp:
2026-07-03 09:20:22.922 Error itgencun016: Error itgeneor229: Det er ikke mer daglig kapasitet tilgjengelig for bruk av Exact Online API på Exact Online-divisjonen ‘……’.
Vennligst optimaliser din API-bruk, eller kontakt Exact Online Support for å få flere API-kall per dag enn den nåværende grensen på 5 000 kall, eller prøv igjen i morgen.
Filen med spørringene følger denne strukturen:
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;
... andre tabeller ...
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;
... andre tabeller ...
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;
... andre tabeller ...
Undersøkelse med Claude AI ble gjennomgått, dette med følgende input:
I/O-er fra 03/07/2026 synk
Logg fra 03/07/2026 synk (feil)
Logg fra 10/06/2026 synk (vellykket, fortsatt på v24)
Her er noen punkter som muligens er relevante?
Ingen 1000 poster / kall
Fingeravtrykket av regresjonen er i julis rader-per-kall. Fra I/O-eksporten returnerer hver store tabell i juli nesten nøyaktig ~500 rader per kall:
TransactionLines: 492.070 rader / 999 kall = 492/kall
SalesOrderLinesBulk: 312.594 / 626 = 499/kall
SalesInvoiceLinesBulk: 326.384 / 654 = 499/kall
GoodsDeliveryLinesBulk: 298.456 / 598 = 499/kall
Exact Online’s bulk- og synk-endepunkter returnerer inntil 1.000 rader per side. Å få en jevn ~500 på tvers av fire uavhengige tabeller er ikke en tilfeldighet — det er en side størrelse på 500, dvs. halvsidesider, dobbel så mange kall for samme data. Anvender du denne dobling på TransactionLines pluss de tre bulk-tabellene, får du omtrent 1.800–1.900 kall som en 1.000-raders side ville ha dekket i ~950.
ODS-intervall 1 sek
Blir en inkrementell tabell stadig supplert hvis "/*+ ods(true, interval ‘1 seconds’) */" elementet ikke inkluderes?
For tiden vil dette føre til at det alltid utføres en fullstendig synk?*
Takk for tilbakemeldingen. Jeg har sammenstilt I/O-ene etter tidspunkt ved siden av loggfilen som anbefalt, og bildet av flere innlastinger blir bekreftet. I dag går oppdateringen nedover, og vi følger med på om dette vil utløse en grense igjen.
Innsikter fra AI:
Kontekst: Data Hub 26.0.167. Oppdateringen kjørte 03/07 fra 05:30 til krasjet kl. 09:20:22 på itgeneor229 («no daily capacity remaining … the current limit of 5 000 calls»). I/O-eksporten inneholder 6 004 forespørsler, hvorav ~5 990 innenfor dette ene vinduet.
1. Sidestørrelsen er korrekt. Per forsøk henter Data Hub ~999 rader/kall (f.eks. 312 594 rader / 313 kall), altså den av Exact foreskrevne ~1 000. Min tidligere angivelse «500/kall» var en tellefeil: jeg delte det lagrede antall rader med totalantallet kall over to forsøk.
2. Hver store tabell hentes to ganger. Når jeg sorterer forespørslene etter tidspunkt, deles hver store tabell inn i to nesten identiske forsøk med en inaktiv pause imellom (0 kall under pausen), mens loggen kun registrerer én Downloaded … rows:
Tabellen
Forsøk 1
Forsøk 2
Logg “Downloaded”
SalesOrderLinesBulk
05:34–05:45 (313 kall / 417 MB)
05:57–06:08 (313 kall / 421 MB)
312 594 rader (1×)
SalesInvoiceLinesBulk
07:27–07:34 (327 kall)
07:40–07:48 (327 kall)
326 384 rader (1×)
GoodsDeliveryLinesBulk
07:01–07:11 (299 kall)
07:17–07:26 (299 kall)
298 456 rader (1×)
TransactionLinesIncremental
08:22–08:25 (500 kall)
08:38–08:42 (499 kall)
492 070 rader (1×)
XML Items
07:54–07:57 (86 kall)
08:00–08:03 (86 kall)
—
De to forsøkene er byte-for-byte symmetriske (f.eks. 417 vs 421 MB for SalesOrderLinesBulk). Dataene lagres dermed én gang, men hentes to ganger.
3. Innvirkning på den daglige grensen. De andre forsøkene utgjør til sammen ~1 524 kall. Uten denne gjentakelsen kommer runnen ned på ~4 480 kall — under grensen på 5 000. Overskridelsen skyldes derfor ikke sidestørrelsen eller synkroniserings-ankeret, men den doble henting.
4. Sammenligning med et vellykket forsøk (09/06, Data Hub 24.0.445, samme ods=1s): loggen viser der én Downloaded … rows per tabell, og prosessen ble fullført uten daglig grense, med sammenlignbare (til og med større) volumer på divisjonskode. Merk: den eldre loggen inneholder ingen I/O på forespørselsnivå, så jeg kan ikke nøyaktig telle antall kall fra juni — den doble henting er bare synlig i 26.0.167-eksporten.
Spørsmål: Kan dere hjelpe med å forklare hvorfor hver bulk/synk-tabel hentes i to forsøk? Konkret:
Utløser både ODS-seeding og den påfølgende SELECT count(*) hver sin separate henting?
Hva venter runnen på under den inaktive pausen på ~6–12 min mellom de to forsøkene?
De tre filene er analysert. Disse sporene inneholder ikke selve oppdateringssyklusen. Det er kun de første filene ved oppstart av prosessen og dekker noen sekunder.
Det som er bemerkelsesverdig, er at det er tre separate prosesser som starter innen få minutter etter hverandre. For testen er det nødvendig å kjøre programmet i sin helhet og deretter gjenta. Gitt 5.000 API-anrop bør det vare minst 5.000 sekunder.
Rådet er å samle spor fra de fullstendige kjøringene og sende dem inn. Det er best etter en oppgradering til 26.0.169, som nå er tilgjengelig som “gjeldende” versjon på https://download.invantive.com.
En intern analyse fremhevet en trend der antallet API-kall for AccountsIncremental (kundetabell) er (trendemessig) høyere med versjon 26.0 enn under versjon 25.0 i en testadministrasjon i Exact Online.
I denne administrasjonen er det omtrent 100 000 relasjoner, og en spørring leser AccountsIncremental 10 til 20 ganger om dagen.
Versjon
Antall Kall per Dag
25.0.190
220
25.0.205
391
25.0.210
112
25.0.211
145
26.0.011
2283
26.0.054
319
26.0.066
569
26.0.069
1091
26.0.148
1920
26.0.164
724
26.0.167
3690
For den nyeste versjonen 26.0.167 er det tilgjengelig en sporlogg. Denne vil brukes til en analyse.
