Cloud Orchestrator におけるAPIレート制限と大きなデータフィールドの使用の最適化

Japan Knowledge Base Team

•2024年5月22日

はじめに

UiPath Automation Cloud Orchestratorの一部のAPIをご利用のお客様には影響が出る可能性がある変更になりますので、是非ご一読ください。変更の詳細は公式ドキュメントをご参照ください。

影響があるAPIエンドポイントおよび対象フィールド

特定のAPIリクエストに対するレート制限
- ※1 GET/odata/Jobs(302140031)のようにジョブを特定する場合には本制限の対象外
- ※2 GET/odata/QueueItems (299605865)のようにキューアイテムを特定する場合には本制限の対象外
- ※3 [ジョブを取得]/[キューアイテムを取得]/[Orchestrator への HTTP 要求]
大きなデータフィールドの利用制限
- ※4 フィルター$topにも影響があります
- ※5 GET/odata/Jobs(302140031)のようにジョブを特定する場合には本制限の対象外

影響有無の確認方法

APIレート制限に関しては、公式ガイドの「スパイクの詳細を表示する」をご参照いただき、貴社内で該当のAPIのご利用有無及び利用状況についてご確認ください。（対象フィールドについては個別に貴社内でご確認が必要になります。）

対応しない場合の影響

特定のAPIリクエストに対するレート制限
- 公式ドキュメントに記載がある制限を超えるすべての要求は、HTTP 429 応答を返します。クライアント側はエラー応答を受けることとなり、利用しているワークフローやスクリプトなどで適切にハンドリングしない限り異常終了することが考えられます。
大きなデータフィールドの利用制限
- 本変更が適用後、GET/odata/Jobs エンドポイントから削除されるフィールドはご利用いただけません。
  また、GET/odata/QueueItems エンドポイントの各種フィールドは公式ドキュメントに記載がある制限以内でのご利用が推奨され、影響の通知方法に記載の内容で、エラーメッセージが返されるか、管理者宛てにメール通知が届きます。

対応方法

特定のAPIリクエストに対するレート制限
- 利用頻度の調整および処理内容の修正
  - API の使用パターンと、公式ドキュメントに記載がある GetAll タイプのエンドポイントから取得した情報を確認します。（APIの利用状況は公式ガイドの「スパイクの詳細を表示する」をご参照ください。）
  - 必要に応じて、API 呼び出しの頻度とデータ抽出手順を調整して、これらの制限範囲内で利用する方法をご検討ください。
  - 上記の検討を実施しても、APIレート制限を超えるアクセスが発生する場合の対応方法としては、公開ヘッダーの情報に含まれるRetry-Afterの値を参照して、適切な時間が経過した後にRetry実行していただくように修正する方法が考えられます。 ※アクティビティを利用している場合、バージョン 2024.3 以降のシステムアクティビティでは Retry-after 応答ヘッダーが適用されます。つまり、Orchestrator の操作が自動的にリトライされます。この方法を活用するには、常に最新バージョンのシステムアクティビティを使用してください。
- 代替手段
  - ジョブおよびキューアイテムのデータを取得する例については、「ジョブをエクスポートする」および「キューアイテムをエクスポートする」をご覧ください。
  - Insights のリアルタイムのデータエクスポートオプションを使用する方法もございます。
大きなデータフィールドの利用制限
- 代替手段
  - ジョブおよびキューアイテムのデータを取得する例については、「ジョブをエクスポートする」および「キューアイテムをエクスポートする」をご覧ください。
  - Insights のリアルタイムのデータエクスポートオプションを使用する方法もございます。

質問がある場合、またはさらに説明が必要な場合は、アカウントマネージャーまたはサポートチームにお問い合わせください。

事例紹介

ジョブの実行状況を確認するために、Orchestratorに存在するフォルダ数分繰り返し処理を発行していたケース
- Orchestrator内で多数のフォルダを管理されており、ジョブの実行状況監視の目的で各フォルダに対して繰り返しAPIのリクエスト処理をしていたことで、100回/分のリクエスト上限を超えた。
処理中のキューアイテムが無くなった直後、別のプロセスを実行していたケース
- 処理中のキューアイテム情報を随時確認し、完了に変わり次第別のプロセスを実行するような運用を行っていたことで、100回/分のリクエスト上限を超えた。