Seit der Version 26.0.X von Data Hub stoßen wir auf das Erreichen des täglichen Limits der API-Anfragen für ein Exact Online-Dossier. Zuvor war dies noch nicht der Fall.
Derzeit analysieren wir, wo das Problem liegt. Im Erneuerungsplan war das SalesOrderLines-Endpoint noch mit 312k+ Zeilen aufgenommen, was eine logische Ursache für einen hohen Verbrauch darstellte. Diese wurde vorerst aus der Erneuerung herausgenommen.
Dennoch stoßen wir erneut an die Grenze, im Folgenden ein Überblick über die Endpunkte und eine grobe Schätzung der erwarteten Anzahl der Anfragen. Dies führt zu einer geschätzten Anzahl von Anfragen von etwa 3,4k (berücksichtigt man, dass hier wahrscheinlich noch andere Anfragen rund um Refresh-Tokens etc. anfallen).
Daher bleiben wir unserer Schätzung nach unter dem Limit von 5k pro Tag. Übersehen wir etwas, wodurch die Anzahl der Anfragen drastisch höher wäre als geschätzt?
Der Rat lautet, die Anzahl der API-Aufrufe an die Anzahl der Zeilen anzupassen. Dies kann schnell über die Tipps unter folgendem Link geschehen:
Ein *Incremental wird normalerweise etwa 1.000 API-Aufrufe nur bei der initialen Ladung oder wenn etwas nicht stimmt, durchführen (zum Beispiel bei einer zu großen Abweichung zwischen dem, was im Cache steht und der Anzahl der Zeilen).
Aus den 4 API-Aufrufen bei (deleted) lässt sich zumindest ablesen, dass in der gemessenen Periode viermal eine vollständige Aktualisierung stattgefunden hat.
Dies kann analysiert werden, indem man in den Sitzungs-I/Os nachsieht, wann und unter welcher Sitzungs-ID die Aufrufe stattfinden.
Ähnliches gilt für *Bulk-Tabellen: Im Bildschirm Sitzungs-I/Os gibt es Hinweise, wann ein Aktualisierungsvorgang stattfindet. Anders als bei *Incremental wird jedoch jeder neue Ladevorgang (bei 300.000 Zeilen in SalesInvoiceLinesBulk) etwa 300 API-Aufrufe erzeugen. Wird eine Sekunde später dieselbe Abfrage erneut ausgeführt, werden wieder etwa 300 API-Aufrufe generiert, usw.
Dies könnte mit den 4 API-Aufrufen bei (deleted) übereinstimmen. Möglicherweise hat ein Skript mehrfach innerhalb der gemessenen Periode ausgeführt.
Das Skript startet um 07:30 Uhr CET über den Windows Taskplaner und erstellt dabei eine Protokolldatei. Auf Serverebene kann ich nur eine Protokolldatei finden.
Die I/Os stammen alle von dem Lauf, der an diesem Morgen gestartet wurde, und stimmen zeitlich mit den Protokollen überein:
Start:
2026-07-03 05:30:12.399 Information itgensql264: Invantive UniversalSQL-Abfrage gestartet.
Stop:
2026-07-03 09:20:22.922 Fehler itgencun016: Fehler itgeneor229: Es ist keine tägliche Kapazität mehr verfügbar für die Nutzung der Exact Online API in der Exact Online Abteilung '……'.
Bitte optimieren Sie Ihre API-Nutzung oder kontaktieren Sie den Exact Online Support, um mehr API-Aufrufe pro Tag als das aktuelle Limit von 5.000 Aufrufen zu erhalten, oder versuchen Sie es morgen erneut.
Die Datei mit den Abfragen hat folgenden Aufbau:
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;
... andere Tabellen ...
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;
... andere Tabellen ...
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;
... andere Tabellen ...
Untersuchung mit Claude AI wurde durchgeführt, mit folgendem Input:
I/O’s vom 03.07.2026 sync
Log vom 03.07.2026 sync (Fehler)
Log vom 10.06.2026 sync (erfolgreich, noch auf v24)
Hier einige Punkte, die möglicherweise relevant sind?
Keine 1000 Datensätze / Aufruf
Der Fingerabdruck der Regression liegt in den Zeilen-pro-Aufruf im Juli. Aus dem I/O-Export ergibt sich, dass jede große Tabelle im Juli fast genau ~500 Zeilen pro Aufruf zurückgibt:
TransactionLines: 492.070 Zeilen / 999 Aufrufe = 492/Aufruf
SalesOrderLinesBulk: 312.594 / 626 = 499/Aufruf
SalesInvoiceLinesBulk: 326.384 / 654 = 499/Aufruf
GoodsDeliveryLinesBulk: 298.456 / 598 = 499/Aufruf
Exact Online's Bulk- und Sync-Endpunkte geben bis zu 1.000 Zeilen pro Seite zurück. Ein uniformes ~500 über vier unabhängige Tabellen zu erhalten, ist kein Zufall — es ist eine Seitengröße von 500, das heißt Halbseitengrößen, doppelt so viele Aufrufe für dieselben Daten. Wendet man diese Verdoppelung auf TransactionLines plus die drei Bulk-Tabellen an, erhält man ungefähr 1.800–1.900 Aufrufe, die eine 1.000-Zeilen-Seite in ~950 bedient hätte.
ODS Intervall 1 Sekunde
Wird eine inkrementelle Tabelle stets ergänzt, wenn das „/*+ ods(true, interval ‘1 seconds’) */“ Element weggelassen wird?
Derzeit würde dies dazu führen, dass stets ein vollständiger Sync stattfindet?
Der Rat ist, die Beziehung zu Zeitpunkten herzustellen; es klingt nach mehreren Ladevorgängen. Exact Online kennt nur von Exact genau vorgeschriebene Seitengrößen.
Der Hinweis ods hat keinen Einfluss auf die Logik für inkrementelle Tabellen oder HTTP-Caches; siehe auch:
Vielen Dank für das Feedback. Ich habe die Ein-/Ausgänge (I/O) pro Zeitpunkt neben die Protokolldatei gelegt, wie empfohlen, und das Bild von mehreren Loads wird bestätigt. Heute läuft die Erneuerung zurück und wir beobachten, ob dies erneut ein Limit auslöst.
Einsichten von KI:
Kontext: Data Hub 26.0.167. Der Refresh lief am 03.07 von 05:30 bis zum Absturz um 09:20:22 auf itgeneor229 („keine tägliche Kapazität mehr verfügbar … das aktuelle Limit von 5.000 Aufrufen“). Der I/O-Export enthält 6.004 Anfragen, wovon ca. 5.990 in diesem einen Fenster.
1. Seitengröße stimmt. Pro Durchgang ruft Data Hub ca. 999 Zeilen/Aufruf ab (z.B. 312.594 Zeilen / 313 Aufrufe), also die von Exact vorgeschriebenen ca. 1.000. Mein vorheriger „500/Aufruf“ war ein Zählfehler: Ich teilte die gespeicherte Zeilenanzahl durch die Gesamtanzahl der Aufrufe über zwei Durchgänge.
2. Jede große Tabelle wird zweimal abgerufen. Wenn ich die Anfragen nach Zeitpunkt sortiere, zerfällt jede große Tabelle in zwei nahezu identische Durchgänge mit einer inaktiven Lücke dazwischen (0 Aufrufe während der Lücke), während das Protokoll nur ein Downloaded … rows registriert:
Tabelle
Durchgang 1
Durchgang 2
Protokoll „Downloaded“
SalesOrderLinesBulk
05:34–05:45 (313 Aufrufe / 417 MB)
05:57–06:08 (313 Aufrufe / 421 MB)
312.594 Zeilen (1×)
SalesInvoiceLinesBulk
07:27–07:34 (327 Aufrufe)
07:40–07:48 (327 Aufrufe)
326.384 Zeilen (1×)
GoodsDeliveryLinesBulk
07:01–07:11 (299 Aufrufe)
07:17–07:26 (299 Aufrufe)
298.456 Zeilen (1×)
TransactionLinesIncremental
08:22–08:25 (500 Aufrufe)
08:38–08:42 (499 Aufrufe)
492.070 Zeilen (1×)
XML Items
07:54–07:57 (86 Aufrufe)
08:00–08:03 (86 Aufrufe)
—
Die beiden Durchgänge sind bytegenau symmetrisch (z.B. 417 vs. 421 MB für SalesOrderLinesBulk). Die Daten werden also einmal gespeichert, aber zweimal abgerufen.
3. Einfluss auf das Tageslimit. Zusammen sind die zweiten Durchgänge ca. 1.524 Aufrufe. Ohne diese Wiederholung kommt der Lauf auf ca. 4.480 Aufrufe — unter dem Limit von 5.000. Die Überschreitung kommt also nicht durch Seitengröße oder den Sync-Anker, sondern durch den doppelten Abruf.
4. Vergleich mit einem erfolgreichen Lauf (09.06, Data Hub 24.0.445, gleiches ods=1s): das Protokoll zeigt dort ein Downloaded … rows pro Tabelle und der Lauf endete ohne Tageslimit, mit vergleichbaren (sogar größeren) Volumina auf Divisionscode. Anmerkung: dieses ältere Protokoll enthält keine I/O auf Anfragenebene, daher kann ich die Anzahl der Aufrufe für Juni nicht exakt zählen — der doppelte Abruf ist nur im 26.0.167-Export sichtbar.
Frage: Könnt ihr helfen zu erklären, warum jede Bulk/Sync-Tabelle in zwei Durchgängen abgerufen wird? Konkret:
Lösen das ODS-Seeding und das anschließende SELECT count(*) jeweils einen separaten Abruf aus?
Worauf wartet der Lauf während der inaktiven Lücke von ca. 6–12 Minuten zwischen den beiden Durchgängen?
Die drei Dateien wurden analysiert. Diese Traces enthalten nicht den eigentlichen Refresh-Zyklus. Es sind nur die ersten Dateien beim Prozessstart und umfassen einige Sekunden.
Auffällig ist, dass es sich um drei separate Prozesse handelt, die im Abstand von wenigen Minuten gestartet werden. Für den Test ist es erforderlich, das Programm vollständig laufen zu lassen und dann zu wiederholen. Da 5.000 API-Calls erforderlich sind, muss das mindestens 5.000 Sekunden dauern.
Es wird empfohlen, Traces von den vollständigen Durchläufen zu sammeln und zu senden. Am besten nach einem Upgrade auf 26.0.169, das jetzt als “aktuelle” Version auf https://download.invantive.com verfügbar ist.
Eine interne Analyse aufdeckte einen Trend, bei dem die Anzahl der API-Aufrufe für AccountsIncremental (Kundentabelle) mit der Version 26.0 tendenziell höher liegt als bei der Version 25.0 in einer Testadministration in Exact Online.
In dieser Administration gibt es circa 100.000 Beziehungen und eine Abfrage liest AccountsIncremental 10 bis 20 Mal pro Tag aus.
Version
Anzahl der Aufrufe pro Tag
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
Für die aktuelle Version 26.0.167 gibt es eine Trace, die für die Analyse verwendet wird.
