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

Newer Version Available

This content describes an older version of this product. View Latest

トリガ

Apex は、トリガを使用して呼び出すことができます。Apex トリガを使用すると、Salesforce のレコードへの変更の前後にカスタムアクション (挿入、更新、削除) を実行できます。
トリガは、次の操作の前後に実行する Apex コードです。
  • insert
  • update
  • delete
  • merge
  • upsert
  • undelete

たとえば、オブジェクトのレコードがデータベースに挿入される前、レコードが削除された後、またはレコードがごみ箱から復元された後に実行されるトリガがあります。

Contact または Account、CaseComment などの一部の標準的な子オブジェクト、およびカスタムオブジェクトなど、トリガをサポートする最上位の標準オブジェクトのトリガを定義できます。トリガにアクセスするオブジェクトのオブジェクト管理設定からトリガを定義するには、[トリガ] に移動します。

トリガには次の 2 種類があります。
  • before トリガは、レコードがデータベースに保存される前にレコードの値を更新または検証する場合に使用します。
  • after トリガは、システムによって設定された項目値 (レコードの Id 項目や LastModifiedDate 項目など) にアクセスする場合や、監査テーブルへのログインやキューを使用した非同期イベントの実行など、他のレコードの変更を有効にする場合に使用します。after トリガを実行するレコードは参照のみです。

トリガは、最初にトリガを実行したレコードと同じ種類の別のレコードを変更することもで���ます。たとえば、取引先責任者 A が更新された後でトリガを実行する場合、このトリガは取引先責任者 BC、および D を変更することもできます。トリガを使用して他のレコードを変更でき、これらの変更によってさらに複数のトリガを実行できるために、Apex ランタイムエンジンはこうしたすべての操作を単一の作業単位とみなし、実行可能な操作数の制限を設定して無限に操作が反復されないようにします。実行ガバナと制限を参照してください。

さらに、before トリガでレコードを更新または削除したり、after トリガでレコードを削除したりすると、ランタイムエラーが発生します。これは、直接操作または間接操作のいずれの場合にも該当します。たとえば、取引先 A を更新し、取引先 A の更新 before トリガが取引先責任者 B を挿入し、取引先責任者 B の挿入 after トリガが取引先 A をクエリして DML update ステートメントまたはデータベースメソッドを使用してその取引先を更新する場合、before トリガで取引先 A を間接的に更新することになるため、ランタイムエラーが発生します。

実装に関する考慮事項

トリガを作成する前に、次の点に留意してください。

  • upsert トリガは、必要に応じて before および after の insert トリガまたは before および after の update トリガを実行します。
  • merge トリガは、削除されるレコードには before および after の delete トリガを実行し、保持されるレコードには before update トリガのみを実行します。トリガと Merge ステートメントを参照してください。
  • レコードが復元された後に実行するトリガは、特定のオブジェクトでのみ機能します。トリガと復元レコードを参照してください。
  • トリガが終了するまで、項目履歴は記録されません。トリガで項目履歴をクエリしても、現在のトランザクションの履歴は表示されません。
  • 項目履歴管理では現在のユーザの権限が優先されます。現在のユーザにオブジェクトまたは項目を直接編集する権限がない場合は、履歴管理が有効になっているオブジェクトまたは項目を変更するトリガを有効にしても、変更履歴は記録されません。
  • API バージョン 20.0 以前では、Bulk API 要求によってトリガが起動されると、そのトリガが処理する 200 レコードの各チャンクが、100 レコードのチャンクに分割されます。Salesforce API バージョン 21.0 以降では、API チャンクがさらに分割されることはありません。Bulk API 要求によって 200 レコードのチャンクに対してトリガが複数回起動される場合、同じ HTTP 要求のこれらのトリガ呼び出しごとにガバナ制限がリセットされます。