オブジェクト関数のスケジュールのベスト・プラクティス: 容量実行のテスト

オブジェクト関数の実行には30分の制限があるため、各オブジェクト関数の実行で実行される作業を分割することをお薦めします。これは、テスト環境で一連の容量実行をテストすることによって最適に行うことができます。

同じオブジェクト関数を使用すると、各ジョブ実行で、処理される合計データのサブセットを処理できます。同じジョブを定期的に実行するようにスケジュールすることで、複数のジョブ実行にわたってデータの完全なセットを処理できます。

テストは、次の数のステップで実行できます:

30分間隔で処理できるデータの量を決定します。

各実行で処理されるデータのサイズは、オブジェクト関数のGroovyスクリプトによって制御されます。オブジェクト関数でGroovyスクリプトの変更を使用して、次のファクタを制御できます:
- 条件定義の表示
- ビュー基準定義から返された結果セットに定義されたデータ・フィルタ
  
  ノート: データベース拡張を使用して、ビュー基準およびデータ・フィルタ結果の検索効率を向上できます。たとえば、データベース列の検索で追加の索引を定義すると、全表スキャンよりはるかに速く結果を戻すことができます。
- setMaxFetchSizeで指定された最大フェッチ・サイズ。定義されていない場合、通常はデフォルトで500行に設定されます。
  
  選択したデータ・サイズが原因でジョブがExprTimeoutExceptionで失敗する場合は、setMaxFetchSizeを使用してデータ・サイズを小さくしてください。
30分間の制限内で処理できるデータの量は、データの複雑さ、そのデータに対する操作のタイプ、および結果のデータベースの更新操作の複雑さに依存し、これらはすべてトラフィックとリソースの競合の影響を受けます。データの複雑さは、操作対象のオブジェクトを構成する属性、および操作を完了するためにトラバースまたは更新する必要がある親、子および関連オブジェクト構造を反映したものです。データが複雑になるほど、操作の完了に必要な情報を収集して操作するコストが高くなります。

たとえば、属性がほとんどなく、関連する親、子、関連オブジェクトがない単純なカスタム・オブジェクトの場合、コストは最小になりますが、商談などの即時利用可能な標準オブジェクトでは、属性数が多く、子および関連オブジェクト関連(アカウント、担当者、リードなど)が複数ある場合、検索および更新コストは高くなります。

操作のタイプに関して、挿入操作では最も高いコストが発生し、更新後に読取りが発生し、処理されるデータ量が増加するとコストが増加します。更新操作の場合、処理可能なデータの量は、検索操作のコストと更新のコストによって異なります。前者はビュー基準によって指示され、後者は、オブジェクト関数のGroovyスクリプトで指定されているように、検索から取得した結果セットに対して実行される操作によって決定されます。データベース更新操作は、オブジェクト関数で指定された操作のタイプに依存します。読取りではデータベースの更新コストは発生しませんが、挿入および更新操作ではデータの複雑さが増大します。
各ジョブの完了にかかる時間を決定します。

データ・サイズに加えて、オブジェクト関数をサポートするために必要なデータベース操作のタイプは、ジョブの完了に大きく影響する可能性があります。データベース・データの作成、更新および削除(ビジネス・ルールで許可されている場合)は通常、データの読取りよりも完了に時間がかかります。データベースの更新を完了してトランザクションを作成するために必要な時間は、オブジェクト関数の実行時間を超える可能性があります。このコストは、オブジェクト・データの複雑さが高い場合に特に高くなります。これらのコストは、30分の制限をはるかに超えているジョブ完了時間に見られることがよくあります。ジョブのスケジュール時間と完了時間の間隔は、ジョブの完了にかかる時間です。
ジョブの完了時に各ジョブをわずかに実行するようにスケジュールします。

前のジョブが完了したことを確認するには、各ジョブをスケジュールしながら、ステップ2で取得したジョブ完了時間に数分を追加することをお薦めします。