一括データ処理のベスト・プラクティス
自動化作業には、入力データのファイルや、多数の項目を含むJSONオブジェクトなどのバルク・データの処理が含まれる場合があります。 バルク・データの処理には、いくつかのオプションがあります。

質問
フロー・チャートの質問に対する回答がディシジョン・プロセスにどのように役立つかを理解します。
| 質問 | 例 | 質問が重要な理由 |
|---|---|---|
![]() |
たとえば、レコード1、レコード2などを更新する必要がありますか。 5つのレコードを同時に更新できますか? |
ロボットは、問題なく順番にオーダーを処理できます。 ただし、ビジネス要件で許可されている場合は、レコードを並行して処理することで効率化の機会が得られます。 |
![]() |
たとえば、100レコードを更新する必要があり、各更新に30秒かかる場合、合計処理時間は50分です。 |
一般に、すべてのレコードの合計処理時間が30分を超える場合、Oracleでは、統合を使用して複数のロボット間で作業の配分を管理することをお薦めします。 一方、すべてのレコードの合計処理時間が30分未満の場合は、ロボットが独自の作業の配布を管理でき、より堅牢なソリューション・アーキテクチャを必要としません。 30分の時間制限は、Oracleが推奨する制限です。 組織は別の期間を選択できます。 レコードのセットが正常に処理されたかどうか、およびサービス制限を判断するために待機する時間を考慮してください。 「Oracle Integration 3のプロビジョニングと管理」の「サービス制限」を参照してください。 |
処理オプション
フロー・チャートには、複数の処理オプションが用意されています。 詳細はこちらをご覧ください。
| 処理オプション | 説明 | ユースケース |
|---|---|---|
![]() |
パラレル反復を処理するforeachループとの統合を作成します。 統合により、データが並行して処理されます。 各ブランチは、1つ以上のレコードを処理するためにロボット・インスタンスを起動します。 たとえば、100レコードのデータ・セットがあるとします。 統合では5つのパラレル・ブランチがサポートされ、各ブランチは1つのロボットをコールします。 したがって、統合とロボットは一度に5レコードを処理します。 呼び出すロボット・インスタンスの数と各ロボットに渡すレコードの数に関するガイダンスについては、読み続けてください。 |
このソリューションは、処理するレコードが多数あるか、各レコードの処理に時間がかかり、ビジネス要件によってレコードを任意の順序で処理できるため、レコードの合計処理時間が長い場合に効率的です。 |
![]() |
順次反復を処理するforeachループとの統合を作成します。 統合によって、すべてのレコードが一度に1つずつ繰り返され、各レコードのロボット・インスタンスが順番に呼び出されます。 呼び出すロボット・インスタンスの数と各ロボットに渡すレコードの数に関するガイダンスについては、読み続けてください。 |
このソリューションは、次のシナリオに最適です:
|
![]() |
データセット全体を単一のロボット・インスタンスに渡す統合を作成します。 ロボットで、すべてのレコードを一度に1つずつ繰り返すforeachループを作成します。 |
このソリューションは簡単かつ簡単で、比較的迅速に処理でき、特定の順序で処理する必要があるレコードに最適です。 |
追加ファクタ: ロボットとレコードの数
いくつかのシナリオでは、レコードを処理するロボットの数と、各ロボットが処理するレコード数を決定する必要があります。
次のシナリオでは、これらのディシジョンを行う必要があります:


次の要因を検討してください
| 要因 | 詳細情報 |
|---|---|
|
ロボット・インスタンスを呼び出すためのオーバーヘッド |
各ロボットは、レコードの更新など、1つ以上の具体的な目標を達成します。 しかし、その目標を達成するためには、ロボットは、アプリケーションのオープン、サインイン、適切なページへの移動など、他のタスクを完了する必要があります。 ロボットが特定の目標に備えるために行うすべてのタスクは、ロボットのオーバーヘッドです。 たとえば、実行に1分15秒かかるロボット(1m 15s)は、1分間の正しいページへの移動と、15秒間の目標達成に費やすことがあります。 ロボットは1分間のオーバーヘッドがあります。 |
|
すべてのレコードの合計処理時間 |
次のコンポーネントによって、すべてのレコードの合計処理時間が決まります:
たとえば、3つのレコードをロボット・インスタンスに渡すと、2つのロボットのオーバーヘッドがなくなりますが、ロボット・インスタンスの合計実行時間も増加します。 |
|
30分(または別の組織が作成した)時間制限 |
時間制限は、ロボットが成功したかどうかを知るまでに待機する時間です。 この値は、一連のレコードの最大処理時間になり、特定のロボット・インスタンスに送信するレコード数の計算に役立ちます。 自動化の効率を最大化するために、Oracleでは、オーバーヘッド時間を制限するために、ロボット・インスタンスに最大レコード数を渡すことをお勧めします。 また、パラレル処理を使用すると、すべてのレコードの処理前に経過するクロック時間を短縮できます。 ただし、パラレル処理の各ブランチには間接費がかかることに注意してください。 間接費期間やその他のコンポーネントによっては、レコードを5つのブランチに配分する方が、レコードを3つのブランチにのみ配分するよりも効率が悪い場合があります。 |
サンプル計算
サンプル計算は、使用するロボットの最適な数とそれらを送信するレコード数を計算する方法を理解するのに役立ちます。
単純なシナリオ
ロボットの実行には1分15秒 (1m 15s)かかります。 ロボットは、右のページに移動する1分を費やし、目標を達成する15秒を費やします。 レコード数やロボット・インスタンス数が異なれば、この作業の合計処理時間に影響します。
| シナリオ | 詳細情報 |
|---|---|
|
5つのロボット・インスタンスがそれぞれ1つのレコードを処理します(順次または並列) |
各ロボットを実行するには1m 15sが必要であり、その結果、合計処理時間は6m 25sになります:
ロボットは順次または並列で実行できます。 |
|
1つのロボット・インスタンスが5つのレコードを順番に処理 |
ロボットにはオーバーヘッドが1分かかり、レコードごとに処理時間が15秒かかるため、合計処理時間は2m 25sになります:
|
|
1つのロボット・インスタンスが150レコードを順番に処理 |
間接費を削減すると、自動化の効率が向上しますが、レコードを1つのロボット・インスタンスに多すぎると、処理時間がより長くなる可能性があります。 たとえば、あるロボットが150レコードを更新した場合、オーバーヘッド時間を149分節約できます。 ただし、合計処理時間は38m 30sで、すべての更新が正常に完了したかどうかを判断するために待機するよりも時間がかかる場合があります。
|
順次処理
ビジネスでレコードを順番に処理する必要がある場合は、各ロボット・インスタンスが処理するタスクの最適な数を決定します。
これらの計算を完了する方法を次に示します。
-
間接費時間の決定
たとえば、1分間の正しいページへの移動に費やし、15秒の目標を達成するロボットを考えてみます。 このロボットには1分(60秒)のオーバーヘッドがあります。
-
レコードを処理する最大時間の決定
30分の時間制限は1,800秒です:
30 minutesx60 seconds= 1,800 seconds各レコードには、60秒のオーバーヘッドが必要です。 最大処理時間から間接時間を差し引く必要があります:
1,800 seconds-60 seconds= 1,740 secondsこの計算では、30分以内に間接費を1回完了してから、残りの時間を使用してレコードを処理することを前提としています。
-
処理できるレコード数の計算
ロボットは各レコードを処理するために15秒必要です。
ロボットが処理できるレコードの最大数を計算するには、レコードを処理する最大時間を各レコードを処理する時間で除算します:
1,740 seconds maximum time/15 seconds per record= 116 records
理論的には、処理する各ロボットの最適なレコード数は116です。
ノート:
この結論は、いくつかの潜在的に欠陥のある仮定をしているので理論的です。 たとえば、計算では、処理時間は変化しないものの、実際のレスポンス時間は大きく異なると想定しています。 計算機による最適な値は、これらのさまざまな状況を反映していません。 ディシジョンを行う際には、ネットワーク・レイテンシなど、これらの計算で考慮されない要件に対応するウィグル・ルームをビルドすることを検討してください。並列処理
レコードを並行して処理できる場合は、ジョブの時間を最小限に抑える方法で作業を配分できます。
-
潜在的間接費時間の合計を計算
たとえば、処理するレコードが100個あり、各レコードに60秒のオーバーヘッド時間が必要な場合、潜在的なオーバーヘッドの合計は6,000秒です:
100 recordsx60 seconds of overhead= 6,000 seconds of potential overhead1つのロボット・インスタンスを使用して複数のレコードを処理することで、この値を減らすことができます。
-
間接費なしで処理時間を計算
たとえば、各レコードの処理に15秒が必要な場合(オーバーヘッド時間なし)、合計処理時間は1,500秒です:
15 seconds of processing timex100 tasks= 1,500 secondsこの時間を減らすことはできません。 ただし、レコードを並行して処理することで、クロックにかかる時間を短縮できます。
-
複数のシナリオを検討して、必要な数のパラレル・ブランチ(最大5つ)および各プロセスが処理するレコード数を確認
オーバーヘッドを含む処理時間を最小限に抑えるには、30分間の時間制限(または組織が選択した時間制限)内にとどまりながら、オーバーヘッド時間をできるだけ短縮する必要があります。 レコードを並行して処理すると、ジョブが完了するまでのクロックの合計時間が最小限に抑えられます。
いくつかのシナリオを計算して、希望する組合せを検索します。 たとえば:
シナリオ ブランチ当たりの合計処理時間 計算 2つのブランチ、ブランチあたり50レコード
810秒 (13 ½分) 60 seconds of overhead+(50 records x 15 seconds of processing time)= 810 seconds3つのブランチ、ブランチあたり33または34レコード
570秒 (9 ½分) 60 seconds of overhead+(34 records x 15 seconds of processing time)= 570 seconds4つのブランチ、ブランチあたり25レコード
435秒 (7 ¼分) 60 seconds of overhead+(25 records x 15 seconds of processing time)= 435 seconds5つのブランチ、ブランチあたり20レコード
360秒(6分) 60 seconds of overhead+(20 records x 15 seconds of processing time)= 360 seconds5つのブランチ、ブランチあたり20レコード、2つの異なるバッチで送信
各バッチは210秒 (3 ½分)で終了し、ブランチ当たりの合計処理時間は420秒 (7分)です
[60 seconds of overhead + (10 records x 15 seconds of processing time)]x2= 420 secondsレコード数が多い場合や処理時間が長い場合は、バッチ内の各ブランチにレコードを送信することを検討する必要がある場合があります。 多くの場合、このアプローチにより、特定のレコード・バッチの処理時間が短縮されますが、合計処理時間が長くなります。 次の表に、500件のレコードを並行して処理するための計算例を示します。
シナリオ ブランチ当たりの合計処理時間 計算 2つのブランチ、ブランチあたり250レコード
3810秒 (63 ½分)
この値は30分間の制限を超えています
60 seconds of overhead+(250 records x 15 seconds of processing time)= 3810 seconds3つのブランチ、ブランチあたり166または167レコード
2565秒 (42 ¾分)
この値は30分間の制限を超えています
60 seconds of overhead+(167 records x 15 seconds of processing time)= 2565 seconds4つのブランチ、ブランチあたり125レコード
1935秒 (32 ¼分)
この値は30分間の制限を超えています
60 seconds of overhead+(125 records x 15 seconds of processing time)= 1935 seconds4つのブランチ、ブランチあたり125レコード、2つの異なるバッチで送信 各バッチは1005秒(16分半)で終了し、ブランチ当たりの合計処理時間は2010秒(33分半)です
[60 seconds of overhead + (63 records x 15 seconds of processing time)]x2= 2010 seconds5つのブランチ、ブランチあたり100レコード
1560秒(26分)
60 seconds of overhead+(100 records x 15 seconds of processing time)= 1560 seconds5つのブランチ、ブランチあたり100レコード、2つの異なるバッチで送信
各バッチは810秒 (13 ½分)で終了し、ブランチ当たりの合計処理時間は1620秒 (27分)です
[60 seconds of overhead + (50 records x 15 seconds of processing time)]x2= 1620 seconds -
要件に適したシナリオを選択
計算を考慮します。 通常のボリュームよりも長い時間、ネットワーク待機時間、およびその他の予期しない問題のために、いくつかのウィグルルームにビルドします。 次に、アプローチを選択します。
Oracleでは、現実世界でアプローチが成功することを確認するために、稼働前に統合およびロボットのテストを行うことをお薦めします。


