Exact OnlineがInvantive Data Hub 26.0.X以降、日次制限に達しました

ptr · 2026 年 7 月 3 日午前 11:37

Data Hubのバージョン26.0.X以降、Exact Onlineのドシエに対するAPIコールの1日の制限に達する問題に直面しています。以前はこのような問題はありませんでした。

現在、問題の原因を分析しています。更新スキーマでは、SalesOrderLinesエンドポイントが312k行以上で含まれており、これが高い消費量の論理的な原因となっていました。これは一時的に更新から外しました。

それでも、制限に再び達してしまいます。以下にエンドポイントの概要と予想されるコール数の概算を示します。これにより、トークンのリフレッシュ等の他のコールがあるとしても、合計約3.4kのコールが予想されます。

これにより、推測として1日5kの制限内に収まると思っていますが、何か見落としがあり、予想以上にコール数が多くなる可能性はありますか？

テーブル	tpn_count_rows	1回のコールでの結果数	必要なAPIコール数
ExactOnlineREST.PurchaseOrder.GoodsReceiptLines	20182	60	336
ExactOnlineREST.PurchaseOrder.GoodsReceipts	1750	60	29
ExactOnlineREST.Purchase.PurchaseInvoices	1038	60	17
ExactOnlineREST.Purchase.PurchaseInvoiceLines	20053	60	334
ExactOnlineREST.Logistics.ItemAssortments	10	60	0
ExactOnlineREST.Logistics.ItemAssortmentProperties	558	60	9
ExactOnlineREST.Financial.Journals	25	60	0
ExactOnlineREST.Financial.FinancialPeriods	72	60	1
ExactOnlineREST.Incremental.GLAccountsIncremental	830	1000	1
ExactOnlineREST.Incremental.TransactionLinesIncremental	492070	1000	492
ExactOnlineXML.XML.Items	8588	60	143
ExactOnlineREST.Logistics.ItemsBulk	8588	1000	9
ExactOnlineXML.XML.AROutstandingItems	427	60	7
ExactOnlineREST.Subscription.SubscriptionLineTypes	2	60	0
ExactOnlineREST.Subscription.SubscriptionLines	2	60	0
ExactOnlineREST.Subscription.Subscriptions	2	60	0
ExactOnlineREST.Subscription.SubscriptionTypes	4	60	0
ExactOnlineREST.HRM.Costunits	43	60	1
ExactOnlineREST.HRM.Costcenters	4	60	0
ExactOnlineREST.SalesInvoice.SalesInvoicesBulk	22474	1000	22
ExactOnlineREST.SalesInvoice.SalesInvoiceLinesBulk	326384	1000	326
ExactOnlineREST.SalesOrder.GoodsDeliveryLinesBulk	298456	1000	298
ExactOnlineREST.SalesOrder.GoodsDeliveriesBulk	35471	1000	35
ExactOnlineREST.SalesOrder.SalesOrders	27720	60	462
ExactOnlineREST.SalesOrder.SalesOrdersBulk	27720	1000	28
ExactOnlineREST.SalesOrder.SalesOrderLinesBulk	312594	1000	313
ExactOnlineREST.CRM.AccountClassifications	37	60	1
ExactOnlineREST.CRM.AddressesBulk	11560	1000	12
ExactOnlineREST.CRM.ContactsBulk	4415	1000	4
ExactOnlineREST.CRM.AccountsBulk	10330	1000	10
ExactOnlineREST.Logistics.SupplierItems	7989	60	133
ExactOnlineREST.PurchaseOrder.PurchaseOrders	1040	60	17
ExactOnlineREST.PurchaseOrder.PurchaseOrderLines	19986	60	333

forums · 2026 年 7 月 3 日午後 12:27

実際のAPIコールは、Invantive Cloudの「セッションI/O」画面で見ることができます。ここにはオンプレミス計測も含まれています。

これを利用して最大の消費者を特定することをお勧めします。

ptr · 2026 年 7 月 3 日午後 2:16

「セッションI/O」は問題管理パーティションに基づいて次の洞察を示しています。

「テーブル名」に従ってグループ化されたI/Oの存在数の概要。

行ラベル	ソート順の合計
ExactOnlineREST.Incremental.TransactionLinesIncremental (new/modified)	999
ExactOnlineREST.SalesOrder.SalesOrders	926
ExactOnlineREST.PurchaseOrder.GoodsReceiptLines	674
ExactOnlineREST.Purchase.PurchaseInvoiceLines	670
ExactOnlineREST.SalesInvoice.SalesInvoiceLinesBulk	654
ExactOnlineREST.SalesOrder.SalesOrderLinesBulk	626
ExactOnlineREST.SalesOrder.GoodsDeliveryLinesBulk	598
ExactOnlineREST.PurchaseOrder.PurchaseOrderLines	317
ExactOnlineXML.XML.Items	172
ExactOnlineREST.SalesOrder.GoodsDeliveriesBulk	72
ExactOnlineREST.PurchaseOrder.GoodsReceipts	60
ExactOnlineREST.SalesOrder.SalesOrdersBulk	56
ExactOnlineREST.SalesInvoice.SalesInvoicesBulk	46
ExactOnlineREST.Purchase.PurchaseInvoices	36
ExactOnlineREST.Logistics.ItemAssortmentProperties	20
ExactOnlineREST.Logistics.ItemsBulk	18
ExactOnlineREST.Workflow.CustomerCooperations	12
ExactOnlineREST.Incremental.TransactionLinesIncremental/$count	6
ExactOnlineREST.Incremental.TransactionLinesIncremental (deleted)	4
ExactOnlineREST.Incremental.GLAccountsIncremental/$count	4
ExactOnlineREST.Incremental.TransactionLinesIncremental (metadata)	4
ExactOnlineREST.Financial.FinancialPeriods	4
ExactOnlineREST.Incremental.GLAccountsIncremental (new/modified)	2
ExactOnlineREST.Subscription.SubscriptionLineTypes	2
ExactOnlineREST.Logistics.ItemAssortments	2
ExactOnlineREST.Subscription.SubscriptionLines	2
ExactOnlineREST.Incremental.GLAccountsIncremental (metadata)	2
ExactOnlineREST.Subscription.Subscriptions	2
ExactOnlineREST.Incremental.GLAccountsIncremental (timemachine)	2
ExactOnlineREST.Financial.Journals	2
ExactOnlineXML.XML.AROutstandingItems	2
ExactOnlineREST.Incremental.GLAccountsIncremental (deleted)	2
ExactOnlineREST.HRM.Costcenters	2
ExactOnlineREST.Subscription.SubscriptionTypes	2
ExactOnlineREST.HRM.Costunits	2
合計	6004

次に注目すべき点：

ExactOnlineREST.Incremental.TransactionLinesIncremental (new/modified)

予想外に高くなっています
このリフレッシュは次のステートメントで開始されます：

select /*+ ods(true, interval '1 seconds') */ count(*) 
from   ExactOnlineREST.Incremental.TransactionLinesIncremental@eolbe;

これが原因で高くなっているのでしょうか？

コール数が多いバルクテーブル

ExactOnlineREST.SalesInvoice.SalesInvoiceLinesBulkに654回のコール
このテーブルは初期テーブルと並行して約300kのレコードがあります。
バルクテーブルが1コールで1000レコードを返すと考えると、ここでは300コールを期待するでしょうか？

forums · 2026 年 7 月 3 日午後 2:21

アドバイスとして、APIコールの数を行数に合わせることが推奨されています。この方法は以下のリンクにあるヒントを使って素早く行えます：

*Incremental は、通常は初回のロードや何かがうまくいかなかった場合（例えば、キャッシュにあるデータと実際の行数に大きな乖離があるとき）に限り、約1,000のAPIコールを行います。

(deleted) の4つのAPIコールからは、測定期間中に4回フル更新が行われたことが読み取れます。

これは、セッションI/Oを調べ、どのセッションID内でコールが行われたかを確認することで解析可能です。

同様のことが *Bulk テーブルにも当てはまります。セッションI/O画面でいつ更新が行われたかを確認する手がかりを提供しています。ただし、*Incremental とは異なり、新たなロードアクションごとに（例えば SalesInvoiceLinesBulk に300K行があると仮定すると）約300のAPIコールが発生します。1秒後に同じクエリが再び実行されると、再度約300のAPIコールが発生します、など。

これは、(deleted) の4つのAPIコールに関連している可能性があります。測定期間中にスクリプトが繰り返し実行されていた可能性があります。

ptr · 2026 年 7 月 3 日午後 2:31

スクリプトは07:30 CETにWindowsのタスクスケジューラを通じて開始され、ログファイルを作成しますが、サーバーレベルでは1つのログファイルしか見つかりません。

I/Oは全て、今朝開始された実行からのもので、ログの時間と合致しています。

開始:

2026-07-03 05:30:12.399 Information itgensql264: Invantive UniversalSQL文の開始。

停止:

2026-07-03 09:20:22.922 Error itgencun016: エラー itgeneor229: Exact Online部門『……』のExact Online API使用には、日次キャパシティがこれ以上利用できません。
  APIの使用を最適化するか、Exact Onlineサポートに連絡して、現在の制限である1日5,000回以上のAPI呼び出しの利用を取得するか、明日再試行してください。

クエリが含まれるファイルの構造は以下の通りです:

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;
... 他のテーブル ...

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;
... 他のテーブル ...

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;
... 他のテーブル ...

forums · 2026 年 7 月 3 日午後 2:55

助言としては、セッションI/Oの情報を使用してログファイルに接続することをお勧めしますが、時間も含めてです。

現時点では、バグがあると考える理由はありません。

ptr · 2026 年 7 月 3 日午後 3:01

これに関して詳細な手順書はありますか？

実行すべき具体的なステップがまだ完全に理解できていません。

forums · 2026 年 7 月 3 日午後 3:12

いいえ、ここには手続きや計画はありません。

アドバイスとしては、経験豊富なコンサルタントを関与させるか、Claude AI を介してアドバイスを求めることです。

ptr · 2026 年 7 月 3 日午後 4:34

Claude AIを用いた調査が以下のインプットで進められました:

2026年7月3日 I/Oの同期
2026年7月3日ログ同期（エラー）
2026年6月10日ログ同期（成功、まだv24）

以下にいくつかの関連があるかもしれないポイントがあります。

1,000レコード/コールがない

レグレッションの指紋は7月の1回あたりの行数にあります。I/Oエクスポートから、7月のすべての大テーブルがほぼ正確に〜500行/コールを返しています:

TransactionLines: 492,070行 / 999コール = 492/コール
SalesOrderLinesBulk: 312,594 / 626 = 499/コール
SalesInvoiceLinesBulk: 326,384 / 654 = 499/コール
GoodsDeliveryLinesBulk: 298,456 / 598 = 499/コール

Exact Onlineのバルクおよび同期エンドポイントは最大でページ当たり1,000行を返します。4つの独立したテーブルにおいて均一に〜500が得られるのは偶然ではありません — ページサイズ500、つまり半分のサイズのページで、同じデータに対してコール数が倍になります。TransactionLinesに加え、3つのバルクテーブルでこの倍増を適用すると、約1,800〜1,900コールとなり、1,000行のページであれば約950で済んだでしょう。

ODS間隔 1秒

「*/*+ ods(true, interval ‘1 seconds’) */」要素が省かれると、インクリメンタルテーブルは常に追加されるのでしょうか？

現時点では、常に完全同期が行われる理由になるのでしょうか？

forums · 2026 年 7 月 3 日午後 8:55

アドバイスとしては、時刻に関連付けることです。複数のロードのように聞こえます。Exact Online は、Exact によって厳密に規定されたページサイズしかサポートしていません。

ヒント ods は、インクリメンタルテーブルやHTTPキャッシュのロジックには影響を与えません。詳細については以下を参照してください：

ptr · 2026 年 7 月 4 日午前 6:18

フィードバックをありがとう。アドバイス通りにログファイルと照らし合わせて時間ごとのI/Oを確認したところ、複数回のロードがあることが確認できました。今日は更新が後退しており、再び制限がトリガーされるかどうかを追跡しています。

AIの洞察:

コンテキスト: Data Hub 26.0.167。リフレッシュは03/07の05:30からクラッシュする09:20:22まで itgeneor229 で実行されました（「利用可能なデイリーキャパシティが残っていません…5,000コールの現在の制限」）。I/Oエクスポートには6,004リクエストが含まれており、そのうち約5,990がこの単一のウィンドウ内にあります。

1. ページサイズは正しいです。 Data Hubはコールごとに約999行を取得します（例: 312,594行 / 313コール）、したがって、Exactが指定した約1,000です。以前の「500/コール」は数え間違えで、二回の実行全体のコール数で保存された行数を割っていました。

2. 各大きなテーブルは2回取得されます。 時間でリクエストをソートすると、各大きなテーブルが2つのほぼ同一の実行に分かれ、間に非アクティブなギャップ（ギャップ中にコールはゼロ）があります。一方、ログは1回のDownloaded … rowsのみを記録しています。

テーブル	パス1	パス2	ログ「Downloaded」
SalesOrderLinesBulk	05:34–05:45 (313コール / 417MB)	05:57–06:08 (313コール / 421MB)	312,594行 (1回)
SalesInvoiceLinesBulk	07:27–07:34 (327コール)	07:40–07:48 (327コール)	326,384行 (1回)
GoodsDeliveryLinesBulk	07:01–07:11 (299コール)	07:17–07:26 (299コール)	298,456行 (1回)
TransactionLinesIncremental	08:22–08:25 (500コール)	08:38–08:42 (499コール)	492,070行 (1回)
XML Items	07:54–07:57 (86コール)	08:00–08:03 (86コール)	—

これらの2回のパスは、バイト単位で正確に一致しています（例: SalesOrderLinesBulkで417MB対421MB）。したがって、データは一度だけ保存されますが、2回ラインを通過しています。

3. デイリー制限への影響。 2回目のパスは合わせて約1,524コールです。それらの繰り返しがなければ、ランは約4,480コールとなり、5,000の制限を下回ります。したがって、超過はページサイズや同期アンカーではなく、重複取得によるものです。

4. 成功したランとの比較（09/06, Data Hub 24.0.445, 同じods=1s）：ログには各テーブルで1回のDownloaded … rowsのみが表示され、ランはデイリー制限なしに終了し、類似（より大きい）なボリュームでディビジョンコードを使用していました。注意すべき点は、古いログはリクエストレベルでのI/Oを含んでいないため、6月のコール数を正確にカウントできず、重複取得は26.0.167エクスポートにのみ現れます。

質問: なぜ各バルク/同期テーブルが2回のパスで取得されるのか説明していただけますか？具体的には：

ODSシーディングとその後のSELECT count(*)がそれぞれ別個の取得をトリガーしているのですか？
2回のパスの間の6〜12分の非アクティブなギャップ中にランは何を待っているのですか？

forums · 2026 年 7 月 4 日午前 10:35

提供された情報に基づいては、あまり多くを言うことはできません。

以下のことをお勧めします:

定期的なリフレッシュを停止する
Provide Support with Data Hub and other on-premises products に記載されているようにInvantive Traceを有効にする
ジョブを1回実行する
ジョブをもう一度実行する
トレースファイルをzipにし、URLを明記の上support@invantive.euに送信する

ptr · 2026 年 7 月 4 日午後 2:19

トレースがアクティブになっていますが、これはできれば毎日の制限がリセットされた後に開始するトレースであると考えてよろしいですか？

forums · 2026 年 7 月 4 日午後 6:05

正確に、「itgeneor229」が完全性を妨げないようにするためです。

ptr · 2026 年 7 月 5 日午前 6:29

".zip"ファイルの送信が「未配信メール警告」になっています

メッセージには3つの「.zip」ファイルが含まれており、合計600kbのみです

ptr · 2026 年 7 月 7 日午後 4:02

今日、トレースリングが提供されました。

この更新が、同じデータコンテナ名を持つ2番目の接続が存在する環境で実行されていることに注意してください。その結果として副作用が考えられます： Invantive Data Hubリリース26.0で間違った接続が選ばれる - invantive？

forums · 2026 年 7 月 7 日午後 7:16

3つのファイルが分析されました。これらのトレースにはリフレッシュサイクルそのものは含まれていません。これらはプロセス開始時の最初のファイルで、数秒間続きます。

注目すべきは、数分おきに開始する3つの個別のプロセスであることです。テストにはプログラムを完全に実行してから繰り返すことが求められています。5,000回のAPIコールを考慮すると、少なくとも5,000秒かかるはずです。

完全なランのトレースを収集して送信することが推奨されます。最善策は、現在「現行」バージョンとして利用可能な26.0.169へのアップグレード後です。 https://download.invantive.com.

ptr · 2026 年 7 月 8 日午前 5:53

バージョン26.0.170へのアップデートが予定され、現在進行中です。

3つのトレーシングは、1つのテーブルを限られたシミュレーションで3回連続して開始したものでした。

Claude AIは、この際にAPIテーブルが短時間で2回読み取られるというフィードバックをしましたが、これは余談です。

トレーシングが新しいバージョンで完了し、問題が続く場合は、新しいトレースが提供されます。

forums · 2026 年 7 月 9 日午前 7:52

内部分析によると、AccountsIncremental（顧客テーブル）のAPIコールの数が、Exact Onlineのテスト管理において、リリース25.0の下よりもリリース26.0で傾向的に多いことが明らかになりました。

この管理には約100,000の関係が含まれており、クエリはAccountsIncrementalを1日に10〜20回読み取ります。

リリース	1日あたりのコール数
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

最近のリリース26.0.167のトレースがあり、これが分析に使用される予定です。

ptr · 2026 年 7 月 9 日午後 1:53

26.0.170の更新のトレーシングは、Invantive Supportにダウンロードリンクを通じて提供されました。

トピック		返信	表示
Itgeneor229 Exact API limiet na Itgenboe161 Vragen (alle) exact-online , invantive-cloud , power-bi	12	1183	2022 年 5 月 31 日
Itgenboe409: De dagelijkse limiet van 2.500 verzoeken is met 2 overschreden Vragen (alle) exact-online , invantive-query-tool , teamleader-focus , invantive-bridge-online , invantive-cloud , power-bi	3	15	2026 年 10 月 2 日
Conflicteert real-time data ophalen met beperkte API limieten? Vragen (alle) exact-online , invantive-sql	2	24	2026 年 1 月 29 日
Itgenboe656 error bij verversen gegevens via invantive bridge online Vragen (alle) exact-online , invantive-cloud , power-bi	6	24	2026 年 8 月 4 日
Itgenoda316 ExactOnlineREST.Incremental.TransactionLinesIncremental Vragen (alle) exact-online , invantive-cloud	3	10	2026 年 6 月 18 日

Exact OnlineがInvantive Data Hub 26.0.X以降、日次制限に達しました

関連トピック