Apex 開発者ガイド
jNewer Version Available
デバッグログ
- データベースの変更
- HTTP コールアウト
- Apex エラー
- Apex によって使用されるリソース
- 次のような自動化されたワークフロー処理:
- ワークフロールール
- 割り当てルール
- 承認プロセス
- 入力規則
自分自身を含む特定ユーザ、クラス、およびトリガのデバッグログを保持および管理できます。クラスおよびトリガの追跡フラグを設定してもログの生成や保存は行われません。クラスおよびトリガの追跡フラグによって他のログレベル (ユーザ追跡フラグによって設定されたログレベルなど) が上書きされますが、ログが記録されることはありません。クラスまたはトリガが実行されたときにログ記録が有効であれば、実行時にログが生成されます。
デバッグログを表示するには、[設定] から、[クイック検索] ボックスに「デバッグログ」と入力し、[デバッグログ] を選択します。次に、確認するデバッグログの横にある [表示] をクリックします。[ダウンロード] をクリックしてログを XML ファイルとしてダウンロードします。
デバッグログセクションの調査
デバッグログを生成した後、表示される情報の種類や量は、ユーザに設定した検索値によって異なります。ただし、デバッグログの形式は常に同じです。
- ヘッダー
- ヘッダーには、次の情報が含まれます。
- トランザクションで使用される API のバージョン。
- ログの生成に使用されるログのカテゴリとレベル。次に例を示します。
- 次に、ヘッダーの例を示します。この例では、API バージョンは 40.0 で、次のデバッグログカテゴリおよびレベルが設定されています。
Apex コード DEBUG Apex プロファイリング INFO コールアウト INFO データベース INFO システム DEBUG 入力規則 INFO Visualforce INFO ワークフロー INFO - 実行ユニット
- 実行ユニットは、トランザクションと同じです。実行ユニットには、トランザクション内で発生したすべての情報が含まれています。EXECUTION_STARTED と EXECUTION_FINISHED の間が実行ユニットの範囲です。
- コードユニット
- コードユニットは、トランザクション内の作業単位です。たとえば、webService メソッド、または入力規則であるトリガはコードの単位の 1 つです。
-
CODE_UNIT_STARTED と CODE_UNIT_FINISHED の間が、コードの単位の範囲です。作業の単位に他の作業単位を組み込むことができます。次に例を示します。
- コードの単位には、次が含まれますが、これらには限定されません。
- トリガ
- ワークフローの呼び出しおよび時間ベースのワークフロー
- 入力規則
- 承認プロセス
- Apex リードの変換
- @future メソッドの呼び出し
- Web サービスの呼び出し
- executeAnonymous コール
- Apex コントローラの Visualforce プロパティアクセス
- Apex コントローラの Visualforce アクション
- execute メソッドの各実行のほか、Apex start メソッドや finish メソッドの一括実行
- Apex System.Schedule execute メソッドの実行
- 受信メールの処理
- ログの行
- ログの行は、コードユニット内に含まれ、どのコードやルールが実行されたかを示します。ログの行は、デバッグログに書き込まれたメッセージである場合もあります。次に例を示します。
- ログの行は、一連の項目で構成され、項目はパイプ (|) で区切られます。形式は次のとおりです。
- タイムスタンプ: イベント発生時の時刻と括弧で囲まれた値で構成されます。時刻はユーザのタイムゾーンで、形式は HH:mm:ss.SSS となります。括弧内の値は、要求が開始されてからの経過時間をナノ秒単位で表します。[Execution Log (実行ログ)] ビューを使用すると、経過時間の値は開発者コンソールで確認したログには含まれません。ただし、[Raw Log (未加工ログ)] ビューを使用すると、経過時間を確認できます。[Raw Log (未加工ログ)] ビューを開くには、開発者コンソールの [Logs (ログ)] タブからログの名前を右クリックし、[Open Raw Log (未加工のログを開く)] を選択します。
- イベント識別子: デバッグログエントリをトリガしたイベントを指定します (SAVEPOINT_RESET や VALIDATION_RULE など)。コードが実行されたメソッド名、または行番号と文字番号など、そのイベントで記録された詳細情報も含まれます。
- その他のログデータ
- さらに、ログには次の情報が含まれます。
- 累積リソース使用状況は、多くのコードユニットの末尾に記録されます。このようなコードユニットとして、トリガ、executeAnonymous、Apex のメッセージの一括処理、@future メソッド、Apex テストメソッド、Apex Web サービスメソッド、Apex リードの取引開始などがあります。
- 累積プロファイル情報はトランザクションの終わりに 1 回記録され、DML の呼び出し、コストのかかるクエリなどの情報が含まれます。「コストのかかる」クエリでは、多くのリソースが使用されます。
Apex クラスおよびトリガ用デバッグログの検索条件の設定
デバッグログの検索条件により、ログの冗長性をトリガおよびクラスレベルで微調整できます。これは Apex ロジックのデバッグ時に特に便利です。たとえば、複雑なプロセスの出力を評価する場合、1 つの要求内で特定のクラスのログの冗長性を上げ、他のクラスまたはトリガのログをオフにすることができます。
クラスまたはトリガのデバッグログレベルを上書きすると、これらのデバッグレベルは、クラスまたはトリガが呼び出すクラスメソッドと、結果として実行されるトリガにも適用されます。実行パス内のすべてのクラスメソッドとトリガは、これらのデバッグログ設定を上書きする場合を除き、コール元から設定を継承します。
次の図は、クラスおよびトリガレベルで上書きされるデバッグログレベルを示しています。このシナリオでは、Class1 が何らかの問題を起こし、詳しい調査が必要であるとします。このために、Class1 のデバッグログレベルが最も詳細なレベルに引き上げられます。Class3 ではこのログレベルが上書きされないため、Class1 の詳細なログレベルが継承されます。ただし、UtilityClass はすでにテストされ、正しく動作することがわかっているため、ログの検索条件はオフになっています。同様に、Class2 は問題の原因であるコードパスに含まれていないため、ログは最小限に抑えられ、Apex コードカテゴリのエラーのみを記録します。Trigger2 は、Class2 からこれらのログ設定を継承します。
-
Trigger1 が Class1 のメソッドと Class2 の別のメソッドをコールします。次に例を示します。
-
Class1 は Class3 のメソッドをコールし、このメソッドが次にユーティリティクラスのメソッドをコールします。次に例を示します。
-
Class2 によってトリガ Trigger2 の実行が起動されます。次に例を示します。