この文章は Salesforce 機械翻訳システムを使用して翻訳されました。詳細はこちらをご参照ください。
英語に切り替える

検出されなかった例外発生後のプラットフォームイベントトリガの再開

イベントストリーム内にチェックポイントを設定し、プラットフォームイベントトリガが新しい呼び出しの実行をそこから再開できるようにします。Apex ガバナ制限に達した場合や別の検出されなかった例外が発生した場合は、トリガの新しい実行中にチェックポイントが使用されます。トリガ処理は、最後に成功したチェックポイントのイベントメッセージの後から再開します。また、1 回のトリガ実行で処理されるイベントの数を明示的に制御するようにチェックポイントを設定することもできます。ただし、メタデータ API または Tooling API を使用すると、トリガのバッチサイズをより簡単に設定できます。詳細は、「PlatformEventSubscriberConfig の使用によるプラットフォームイベントトリガのユーザおよびバッチサイズの設定」を参照してください。

処理するイベントメッセージ数が少ないほど、トリガは Apex ガバナ制限に達する可能性が低くなります。プラットフォームイベントトリガの最大バッチサイズは 2,000 で、Apex オブジェクトトリガの最大バッチサイズは 200 です。そのため、プラットフォームイベントトリガは制限に達する可能性がより高く、この機能によるメリットがあります。

トリガ再開のチェックポイントを設定するには、最後に正常に処理されたイベントメッセージの再実行 ID をこのメソッドのコールを使用して設定します。

トリガの実行フローが意図的に、または未処理の例外 (制限の例外など) によって停止すると、新しいバッチ (Trigger.New の sObject リスト) を使用して、トリガがもう一度起動します。新しいバッチは、設定した再実行 ID の後のイベントメッセージから開始します。setResumeCheckpoint(replayId) メソッドによってトリガ実行は停止しませんが、明示的に実行を終了することができます。たとえば、バッチサイズを制御するには、一部のイベントメッセージが処理されたら実行フローを終了するようにします。

指定された再生 ID が有効でない場合、このメソッドでは EventBus.InvalidReplayIdException が発生します。無効な再生 ID は、Trigger.new リストのイベントの現在のトリガバッチにない再生 ID です。

1 つの���リガのバッチを再開しても、同じイベントオブジェクトの別のトリガには影響ありません。ただし、実行順序を保証することはできないため、同じオブジェクトで複数のトリガを設定するのはベストプラクティスではありません。そのため、オブジェクトごとに 1 つのトリガのみを追加することをお勧めします。

メモ

このトリガ例では、各反復の最後に処理されたイベントメッセージの再実行 ID を設定します。制限の例外が発生すると、トリガがもう一度起動し、設定された再実行 ID の後のイベントメッセージから処理が再開されます。

この例では、プラットフォームイベントトリガのバッチサイズを制御し、Apex オブジェクトトリガのバッチサイズ 200 に一致させます。このトリガは、すでに処理済みのイベントメッセージの数を数えます。setResumeCheckpoint(replayId) は、正常に処理された各イベントメッセージの後でループの各反復でコールされます。イベント数が 200 件を超えるとループが終了し、トリガの実行が停止されます。未処理のイベントメッセージがある場合、トリガは再度起動します。新しいトリガ呼び出しに送信されたイベントメッセージのリストは、設定された再実行 ID のイベントメッセージの後のイベントメッセージで開始されます。

API バージョン 51.0 以降、メタデータ API または Tooling API の PlatformEventSubscriberConfig を使用してトリガのバッチサイズを設定できます。詳細は、「PlatformEventSubscriberConfig の使用によるプラットフォームイベントトリガのユーザおよびバッチサイズの設定」を参照してください。

メモ

TestBatchSizeTriggerResumption テストクラスには ControlBatchSizeTrigger のテストが含まれます。クラスのテストメソッドは 201 件のイベントメッセージを公開します。次に、deliver() メソッドを 2 回コールしてトリガを 2 回起動します。最初の呼び出しは、200 件のイベントメッセージを処理します。2 番目の呼び出しは、最後のイベントメッセージを処理します。このテストでは、最後に処理されたイベントメッセージの再実行 ID を保持する EventBusSubscriber.Position プロパティを調査してトリガが呼び出されたことを検証します。