ABAPの不具合を調べるとき、プログラムの先頭から1行ずつ実行すると時間がかかります。効率よく原因にたどり着くには、再現条件と期待値を確認し、値が初めてずれる場所を絞り込むことが大切です。
この記事では、SAP GUIでのデバッガの起動方法、ブレークポイントとウォッチポイントの使い分け、内部テーブルの調べ方を、実務の手順に沿って説明します。
デバッグ前に「何が違うか」を具体化する
まず、再現できる入力条件と期待結果をそろえます。たとえば「受注番号Aの明細10では数量が5になるはずなのに、出力は8」という具合です。実行ユーザー、対象データ、選択条件、実行日時、オンラインかジョブかも記録します。エラーで終了した場合は、先にST22やSM37でエラー情報を確認する記事を参考に、停止した箇所とメッセージを調べます。
次に、疑わしい値が「入力時から違う」「取得後に違う」「計算後に違う」「出力時だけ違う」のどこに当てはまるか仮説を立てます。最初のブレークポイントは、プログラムの先頭ではなく、値を取得・変更・出力する境界に置くと調査範囲を狭められます。
SAP GUIでデバッガを起動する方法
| 方法 | 使いやすい場面 | 操作の要点 |
|---|---|---|
| ブレークポイント | 疑わしい処理の場所が分かっている | ソースの実行行に設定し、同じ条件で処理を再実行する |
コマンドフィールドの /h |
画面操作の途中から調べたい | SAP GUIのコマンドフィールドに入力してEnterを押し、その後に調べたい画面操作を行う |
/h はSAP GUIで次の画面処理をデバッグするための入口です。指定したソース行へ直行する機能ではありません。目的の処理が分かっているなら、ブレークポイントを併用します。Fiori・HTTP・RFCなどSAP GUIの画面操作とは異なる実行経路では、実行ユーザーとセッションに合った外部ブレークポイントなどが必要です。通常の画面実行と同じつもりで設定すると止まらないことがあります。
止まった後はF5・F6・F7・F8を使い分ける
| キー | 動き | 使いどころ |
|---|---|---|
| F5 | 次の処理へ1ステップ進む。呼び出し先があれば中に入る | 疑わしいメソッドや汎用モジュールの内部を調べる |
| F6 | 呼び出し先の内部に入らず、現在の処理を進める | 関係のない処理を飛ばして呼び出し結果を見る |
| F7 | 現在の呼び出し元へ戻る | 呼び出し先の確認を終えたとき |
| F8 | 次の停止位置まで続行する | 次のブレークポイントやウォッチポイントへ進む |
同じ場所で何度もF5を押す前に、いま見ている変数の値、直前に実行した行、呼び出しスタックを確認します。F8で続行すると次の停止位置まで一気に進むため、確認したい区間の後にも停止位置を用意しておきます。
ブレークポイントは対象データを絞って使う
ループが数千回動く処理で毎回停止すると、目的の明細にたどり着けません。対象の受注番号や明細番号など、再現に必要なキーが分かっている場合は、条件付きブレークポイントを使います。条件を付けられない場面では、疑わしい分岐の直後に置く、またはその値を作る処理から先に調べる方法も有効です。
「設定したのに止まらない」ときは、ブレークポイントが実行可能な行にあるか、分岐条件を満たしているか、実行ユーザー・クライアント・実行経路が想定どおりかを確認します。HTTPやRFCの処理では外部ブレークポイントの対象ユーザーも確認してください。
値がどこで変わったか分からないならウォッチポイント
ウォッチポイントは、監視する変数の値が変化したときに処理を停止します。たとえば、合計金額 lv_total が途中で想定外の値になるなら、デバッガでその変数を監視し、処理を続行します。止まった行と直前の値を見れば、どの代入・計算で変化したかを追いやすくなります。必要に応じて条件を加え、対象の値になったときだけ止めます。
内部テーブル全体にもウォッチポイントを設定できる環境がありますが、大きなデータでは実行速度やメモリに影響します。まずは明細キー、件数、合計値など小さな対象を監視し、必要な範囲だけ調べるのが実用的です。
内部テーブルは「対象行」と「変化の前後」を見る
大量の内部テーブルを最初から最後まで眺めるより、対象のキーで該当行を探します。デバッガのテーブル表示で行・列を絞り、処理の前後で件数、キー、重要項目を比較します。値がずれる場合は、SELECTで取得した直後、ループ内の更新直後、出力用テーブルへ追加する直前などに停止位置を置くと原因を切り分けやすくなります。
元記事ではExcelへのダウンロードを勧めていましたが、まずはデバッガ上で対象行を絞る方法を試してください。外部での集計が必要な場合だけ、業務データの持ち出しルールを確認して必要最小限のデータを扱います。調査のためにデバッガ上の値を書き換えた場合、その結果は本来のプログラムの結果とは分けて記録します。
原因を見つけた後の確認
- 値が初めて期待値から外れた行と、そのときの入力値を記録する。
- 修正後、元の再現条件で期待結果に戻ることを確認する。
- 同じ処理を通る別のデータや、空データ・複数行などの境界条件も確認する。
- 再現条件、原因、修正内容、確認結果を残す。
たとえばループ2周目だけ前の行の値が残る不具合なら、1件だけのテストでは見つかりません。LOOPとCLEARの注意点も併せて確認すると、修正後のテスト観点を作りやすくなります。
まとめ
ABAPのデバッグは、やみくもに1行ずつ進めるより、再現条件と期待値を決めて「値が初めてずれた場所」を探すほうが効率的です。場所が分かるならブレークポイント、変更箇所が分からないならウォッチポイントを使います。内部テーブルは対象行を絞り、修正後は元の条件と境界条件で再確認しましょう。
参考・関連記事
- バグの少ないABAPプログラムを書く基本：不具合を減らす設計と実装の観点。
- LOOP内のCLEAR漏れを確認する方法：複数件処理で値が残る問題の例。
- ST22・SM37で実行時エラーを調べる：デバッグ前にエラーの発生箇所を絞る。
- バックグラウンド実行の基本：ジョブと対話実行の違いを確認する。
