Apex 開発者ガイド
jNewer Version Available
デバッグログ
- データベースの変更
- HTTP のコールアウト
- Apex のエラー
- Apex によって使用されるリソース
- 次のような自動化されたワークフロー処理:
- ワークフロールール
- 割り当てルール
- 承認プロセス
- 入力規則
自分自身を含む特定ユーザ、クラス、およびトリガのデバッグログを保持および管理できます。クラスおよびトリガの追跡フラグを設定してもログの生成や保存は行われません。クラスおよびトリガの追跡フラグによって他のログレベル (ユーザ追跡フラグによって設定されたログレベルなど) が上書きされますが、ログが記録されることはありません。クラスまたはトリガが実行されたときにログ記録が有効であれば、実行時にログが生成されます。
デバッグログを表示するには、[設定] から、[クイック検索] ボックスに「デバッグログ」と入力し、[デバッグログ] を選択します。次に、確認するデバッグログの横にある [表示] をクリックします。[ダウンロード] をクリックしてログを XML ファイルとしてダウンロードします。
- 各デバッグログは最大 5 MB です。デバックログのサイズが 5 MB を超えると、System.debug ステートメントの始めの方のログの行など、古いログの行が削除されてサイズが縮小されます。ログの行は、デバッグログの最初からだけでなく、どの位置からでも削除できます。
- システムデバッグログは 24 時間保持されます。監視デバッグログは 7 日間保持されます。
- 15 分間で 250 MB を超えるデバッグログを生成すると、追跡フラグが無効になります。追跡フラグを最後に更新したユーザにメールが送信され、15 分後に追跡フラグを再度有効化できることが通知されます。
- 組織で 250 MB を超えるデバッグログが蓄積された場合、組織のユーザは追跡フラグを追加したり、編集したりできなくなります。この制限に達した後、さらにログを生成できるように追跡フラグを追加または編集するには、デバッグログをいくつか削除します。
デバッグログセクションの調査
デバッグログを生成した後、表示される情報の種類や量は、ユーザに設定した検索値によって異なります。ただし、デバッグログの形式は常に同じです。
- ヘッダー
- ヘッダーには、次の情報が含まれます。
- トランザクションで使用される API のバージョン。
- ログの生成に使用されるログのカテゴリとレベル。次に例を示します。
- 次に、ヘッダーの例を示します。
143.0 APEX_CODE,DEBUG;APEX_PROFILING,INFO;CALLOUT,INFO;DB,INFO;SYSTEM,DEBUG;VALIDATION,INFO;VISUALFORCE,INFO; 2WORKFLOW,INFOこの例では、API バージョンは 43.0 で、次のデバッグログカテゴリおよびレベルが設定されています。Apex コード DEBUG Apex プロファイリング INFO コールアウト INFO データベース INFO システム DEBUG 入力規則 INFO Visualforce INFO ワークフロー INFO - 実行ユニット
- 実行ユニットは、トランザクションと同じです。実行ユニットには、トランザクション内で発生したすべての情報が含まれています。EXECUTION_STARTED と EXECUTION_FINISHED の間が実行ユニットの範囲です。
- コードユニット
- コードユニットは、トランザクション内の作業単位です。たとえば、webservice メソッド、または入力規則であるトリガはコードの単位の 1 つです。
-
CODE_UNIT_STARTED と CODE_UNIT_FINISHED の間が、コードの単位の範囲です。作業の単位に他の作業単位を組み込むことができます。次に例を示します。
1EXECUTION_STARTED 2CODE_UNIT_STARTED|[EXTERNAL]execute_anonymous_apex 3CODE_UNIT_STARTED|[EXTERNAL]MyTrigger on Account trigger event BeforeInsert for [new]|__sfdc_trigger/MyTrigger 4CODE_UNIT_FINISHED <-- The trigger ends 5CODE_UNIT_FINISHED <-- The executeAnonymous ends 6EXECUTION_FINISHED - コードの単位には、次が含まれますが、これらには限定されません。
- トリガ
- ワークフローの呼び出しおよび時間ベースのワークフロー
- 入力規則
- 承認プロセス
- Apex リードの変換
- @future メソッドの呼び出し
- Web サービスの呼び出し
- executeAnonymous コール
- Apex コントローラの Visualforce プロパティアクセス
- Apex コントローラの Visualforce アクション
- Apex start メソッドや finish メソッドの一括実行、および execute メソッドの各実行
- Apex System.Schedule execute メソッドの実行
- 受信メールの処理
- ログの行
- ログの行は、コードユニット内に含まれ、どのコードやルールが実行されたかを示します。ログの行は、デバッグログに書き込まれたメッセージである場合もあります。次に例を示します。
- ログの行は、一連の項目で構成され、項目はパイプ (|) で区切られます。形式は次のとおりです。
- タイムスタンプ: イベント発生時の時刻と括弧で囲まれた値で構成されます。時刻はユーザのタイムゾーンで、形式は HH:mm:ss.SSS となります。括弧内の値は、要求が開始されてからの経過時間をナノ秒単位で表します。[Execution Log (実行ログ)] ビューを使用すると、経過時間の値は開発者コンソールで確認したログには含まれません。ただし、[Raw Log (未加工ログ)] ビューを使用すると、経過時間を確認できます。[Raw Log (未加工ログ)] ビューを開くには、開発者コンソールの [Logs (ログ)] タブからログの名前を右クリックし、[Open Raw Log (未加工のログを開く)] を選択します。
-
イベント識別子: デバッグログエントリをトリガしたイベントを指定します (SAVEPOINT_RESET や VALIDATION_RULE など)。
コードが実行されたメソッド名、または行番号と文字番号など、そのイベントで記録された詳細情報も含まれます。行番号を特定できない場合、代わりに [EXTERNAL] が記録されます。たとえば、管理パッケージに含まれる組み込みの Apex クラスまたはコードでは [EXTERNAL] が記録されます。
一部のイベント (CODE_UNIT_STARTED、CODE_UNIT_FINISHED、VF_APEX_CALL_START、VF_APEX_CALL_END、CONSTRUCTOR_ENTRY、CONSTRUCTOR_EXIT) では、イベント識別子の最後にパイプ (|) とその後に Apex クラスまたはトリガの typeRef が含まれます。
トリガの場合、typeRef は SFDC トリガプレフィックス __sfdc_trigger/ で始まります。たとえば、__sfdc_trigger/YourTriggerName または __sfdc_trigger/YourNamespace/YourTriggerName のようになります。
クラスの場合、typeRef では YourClass、YourClass$YourInnerClass または YourNamespace/YourClass$YourInnerClass の形式が使用されます。
- その他のログデータ
- さらに、ログには次の情報が含まれます。
- 累積リソース使用状況は、多くのコードユニットの末尾に記録されます。このようなコードユニットとして、トリガ、executeAnonymous、Apex のメッセージの一括処理、@future メソッド、Apex テストメソッド、Apex Web サービスメソッド、Apex リードの変換などがあります。
- 累積プロファイル情報はトランザクションの終わりに 1 回記録され、DML の呼び出し、コストのかかるクエリなどの情報が含まれます。「コストのかかる」クエリでは、多くのリソースが使用されます。
137.0 APEX_CODE,FINEST;APEX_PROFILING,INFO;CALLOUT,INFO;DB,INFO;SYSTEM,DEBUG;
2 VALIDATION,INFO;VISUALFORCE,INFO;WORKFLOW,INFO
3Execute Anonymous: System.debug('Hello World!');
416:06:58.18 (18043585)|USER_INFO|[EXTERNAL]|005D0000001bYPN|devuser@example.org|
5 Pacific Standard Time|GMT-08:00
616:06:58.18 (18348659)|EXECUTION_STARTED
716:06:58.18 (18383790)|CODE_UNIT_STARTED|[EXTERNAL]|execute_anonymous_apex
816:06:58.18 (23822880)|HEAP_ALLOCATE|[72]|Bytes:3
916:06:58.18 (24271272)|HEAP_ALLOCATE|[77]|Bytes:152
1016:06:58.18 (24691098)|HEAP_ALLOCATE|[342]|Bytes:408
1116:06:58.18 (25306695)|HEAP_ALLOCATE|[355]|Bytes:408
1216:06:58.18 (25787912)|HEAP_ALLOCATE|[467]|Bytes:48
1316:06:58.18 (26415871)|HEAP_ALLOCATE|[139]|Bytes:6
1416:06:58.18 (26979574)|HEAP_ALLOCATE|[EXTERNAL]|Bytes:1
1516:06:58.18 (27384663)|STATEMENT_EXECUTE|[1]
1616:06:58.18 (27414067)|STATEMENT_EXECUTE|[1]
1716:06:58.18 (27458836)|HEAP_ALLOCATE|[1]|Bytes:12
1816:06:58.18 (27612700)|HEAP_ALLOCATE|[50]|Bytes:5
1916:06:58.18 (27768171)|HEAP_ALLOCATE|[56]|Bytes:5
2016:06:58.18 (27877126)|HEAP_ALLOCATE|[64]|Bytes:7
2116:06:58.18 (49244886)|USER_DEBUG|[1]|DEBUG|Hello World!
2216:06:58.49 (49590539)|CUMULATIVE_LIMIT_USAGE
2316:06:58.49 (49590539)|LIMIT_USAGE_FOR_NS|(default)|
24 Number of SOQL queries: 0 out of 100
25 Number of query rows: 0 out of 50000
26 Number of SOSL queries: 0 out of 20
27 Number of DML statements: 0 out of 150
28 Number of DML rows: 0 out of 10000
29 Maximum CPU time: 0 out of 10000
30 Maximum heap size: 0 out of 6000000
31 Number of callouts: 0 out of 100
32 Number of Email Invocations: 0 out of 10
33 Number of future calls: 0 out of 50
34 Number of queueable jobs added to the queue: 0 out of 50
35 Number of Mobile Apex push calls: 0 out of 10
36
3716:06:58.49 (49590539)|CUMULATIVE_LIMIT_USAGE_END
38
3916:06:58.18 (52417923)|CODE_UNIT_FINISHED|execute_anonymous_apex
4016:06:58.18 (54114689)|EXECUTION_FINISHEDApex クラスおよびトリガ用デバッグログの検索条件の設定
デバッグログの検索条件により、ログの冗長性をトリガおよびクラスレベルで微調整できます。これは Apex ロジックのデバッグ時に特に便利です。たとえば、複雑なプロセスの出力を評��する場合、1 つの要求内で特定のクラスのログの冗長性を上げ、他のクラスまたはトリガのログをオフにすることができます。
クラスまたはトリガのデバッグログレベルを上書きすると、これらのデバッグレベルは、クラスまたはトリガが呼び出すクラスメソッドと、結果として実行されるトリガにも適用されます。実行パス内のすべてのクラスメソッドとトリガは、これらのデバッグログ設定を上書きする場合を除き、コール元から設定を継承します。
次の図は、クラスおよびトリガレベルで上書きされるデバッグログレベルを示しています。このシナリオでは、Class1 が何らかの問題を起こし、詳しい調査が必要であるとします。このために、Class1 のデバッグログレベルが最も詳細なレベルに引き上げられます。Class3 ではこのログレベルが上書きされないため、Class1 の詳細なログレベルが継承されます。ただし、UtilityClass はすでにテストされ、正しく動作することがわかっているため、ログの検索条件はオフになっています。同様に、Class2 は問題の原因であるコードパスに含まれていないため、ログは最小限に抑えられ、Apex コードカテゴリのエラーのみを記録します。Trigger2 は、Class2 からこれらのログ設定を継承します。
-
Trigger1 が Class1 のメソッドと Class2 の別のメソッドをコールします。次に例を示します。
1trigger Trigger1 on Account (before insert) { 2 Class1.someMethod(); 3 Class2.anotherMethod(); 4} -
Class1 は Class3 のメソッドをコールし、このメソッドが次にユーティリティクラスのメソッドをコールします。次に例を示します。
1public class Class1 { 2 public static void someMethod() { 3 Class3.thirdMethod(); 4 } 5} 6 7public class Class3 { 8 public static void thirdMethod() { 9 UtilityClass.doSomething(); 10 } 11} -
Class2 によってトリガ Trigger2 の実行が起動されます。次に例を示します。
1public class Class2 { 2 public static void anotherMethod() { 3 // Some code that causes Trigger2 to be fired. 4 } 5}