デバッグで SAP を読み解く ~ ABAP エンジニアの矜持 ~

SAP キャリアスタートのきっかけと歩き方

これから SAP に携わるエンジニアの方に、ABAP エンジニアの良さ・大事さを知ってもらえたらと思いブログを綴りたいと思います。

エンジニアとして SAP に関わるきっかけは、大きく分けて以下の2つのケースが考えられます。

① 基幹システムとして SAP を導入する/している会社で社内 SE として勤めている
② SAP 事業を営んでいる IT ベンダーにエンジニアとして入社する

①の場合、ある程度業務を理解した状態で SAP に触れることができるので、SAP 標準の業務プロセスへの理解が早い。
②の場合、IT 知識やスクラッチ開発経験はあるが業務には無知な状態なので、パッケージである SAP には取っ付きにくい。

私は、開発ベンダーの一員としての経験しかなく、SAP の教育環境も整っているとは言えない②からのスタートでした。そんな環境の中、1人前の SAP エンジニアになるためにはどうすれば良いのか?
自分の中で導き出したのは次の2つの道でした。

  • 業務目線からのアプローチ
    ⇒ お客様の業務を理解し、それに対して SAP の機能がどのように適用できるかを当てはめていく
  • システム目線からのアプローチ
    ⇒ SAP の機能から何ができるのかを把握し、それをお客様の業務に照らし合わせていく

理想は商流や物流、業務プロセスなどを把握し、システムに落として込んでいく「業務目線からのアプローチ」だと思います。業務知識のない自分がこの道をいくためには、一から情報を集めて業務を理解するところから始めなければなりませんが、多忙なお客様や先輩などを捕まえて、説明の時間を割いてもらうことは当時新人だった自分にとって高いハードルでした。

そこから、自分が生きるための術として選択したのが、「システム目線からのアプローチ」の道でした。そう、SAP システムの中には、ABAP という言語で記された膨大な量の参考書があったのです。

SAP は良くできたツール

尊敬する先輩の一人に、「SAP は良くできたツール」とお話し頂いたことがあります。

「導入するのが大変」 や「扱いづらい」など、シチュエーションによっては毛嫌いされることもありますが(特に日本では)、世界各国で数多くの導入実績のある製品で、標準機能で出来ないことには大抵理由があり、筋が通ったシステムであると思います。
そのため、SAP の導入プロジェクトでは如何にリスクなく、そのギャップを埋めていくかが永遠のテーマです。

『基本的には「ツール」なんだから、やろうと思えば大抵のことは実現出来るよ』と出来る人だから言える先輩のセリフに憧れの感情を抱きつつ、たしかに SAP はデータを加工・閲覧することにとても優れているツールのように思います。
その SAP は基本的には「ABAP」言語で開発された大量のプログラムで構成されており、ABAP を読み解くチカラがあればプログラムから機能の概要を把握をすることも可能です。読み解くための強力な支援ツールである SAP の「デバッグ」を利用すれば、データの流れも同時に確認できるので開発する上で非常に有益です。

「デバッグ」は、ABAP で構成されているプログラムであればどこでも実行することができて、まるで ス●ードラーニングのように、処理を実行しながらプログラムの流れや意図が読み取れるようにもなります。(※あくまで著者の感想で、個人差があります)

今回はその「デバッグ」の便利な扱い方を含め、その他「調査ツール」のご紹介を簡単にできればと思います。

デバッグ

■ デバッグ起動 - ユーザコマンド ”/h”

動きを確認したい画面にて、”/h” のコマンドを入力 → Enter で、デバッグが起動します。
以降のオペレーションで、その画面のデバッグによる処理ステップが確認できます。

■ 新 ABAP デバッガ

デバッグには新旧両方のバージョンが存在し、新バージョン(通常起動するもの)の方が各種ツールが充実しています。

■ 新 ABAP デバッガ / ブレークポイント位置

デバッグ画面の上部メニューより、選択可能です。
ブレークポイント (デバッグを止めたい位置) の指定ができます。

⇒ブレークポイント:命令(個人的おすすめ度:☆2)
指定した ABAP 命令に対してブレークポイントが設定されます。
例えば「MESSAGE」命令を指定すると、処理中メッセージが出力される部分で処理前にブレークポイントが設定されます。

⇒ブレークポイント:サブルーチン(個人的おすすめ度:☆3)
指定したプログラムのサブルーチン (Form 文) に対して、ブレークポイントが設定されます。
例えば呼び出されるプログラム ID がわかっている場合、この機能でブレークポイントを設定し、どの処理で該当ロジックが通っているのか?を確認する場合に便利です。

⇒ブレークポイント:汎用モジュール(個人的おすすめ度:☆3)
「ブレークポイント:サブルーチン」と同じく、汎用モジュールがわかっている場合、その ID にてブレークポイントを設定することができます。

⇒ブレークポイント:メソッド(個人的おすすめ度:☆2)
「ブレークポイント:サブルーチン」と同じく、クラスメソッドがわかっている場合、その ID にてブレークポイントを設定することができます。

⇒ブレークポイント:例外(個人的おすすめ度:☆4)
例外(ショートダンプ)発生個所(前)にブレークポイントが設定されます。
障害発生時など、例外クラスが判明している場合は、検証環境などで同じデータで実行し、例外クラスでデバッグを止めれば、発生している原因を迅速に究明することができます。

⇒メッセージでのブレークポイント(個人的おすすめ度:☆5)
例外クラスのブレークポイント同様、メッセージでのブレークポイント設定ができます。
例外が発生するケースよりも「エラーメッセージ」として出力されるケースが多くメッセージ発生の条件などを調査する際に非常に有益です。

■ 新 ABAP デバッガ / ウォッチポイント (個人的おすすめ度:☆5)

明確な ABAP 行に設定する「ブレークポイント」に対して、該当変数の中身に変化があった場合に止まります。
条件を指定すれば、該当変数が条件を満たす値に更新された際に止まります。(例:>=1000 )
該当ロジックまでブレークポイントで処理して、LOOP 処理内で目的の伝票番号の動きをウォッチポイントで止めて確認する等に利用できます。

■ 新 ABAP デバッガ / ブレーク・ウォッチポイント確認

設定した ブレークポイント・ウォッチポイント の確認・削除・有効/無効化 ができます。

パフォーマンストレース (トランザクション:ST05)

トレースを ON ⇒ OFF の間に実行されたプログラム・読み込まれたテーブルを一覧表示してくれる機能。
「マスタデータの読み方がわからない」「登録されているテーブルがわからない」等のケースで、トレースを ON にして該当トランザクション(画面)を操作すると、起動したプログラム・テーブルを知ることができます。

【画面説明】
Activate Trace・・・トレース ON
Deactivate Trace・・・トレース OFF
Display Trace・・・トレース結果一覧表示
Select Trace Type
SQL Trace・・・実行された SQL 文をトレース対象とする
Buffer Trace・・・SQL で取得でなくバッファより取得されたデータをトレース対象とする
RFC Trace・・・RFC(リモートファンクションコール)で、SAP 外より起動した処理をトレース対象とする

トレース結果の中で、伝票番号などのキーワードを検索することができる。
該当行でダブルクリックすると、処理されているプログラムの該当行を閲覧することが可能です。
「ObjectName」列が読み込まれたテーブル ID が表示されている。

最後に

ある程度の ABAP 命令の読解力が必要となってはきますが、SAP のデバッグ機能を使いこなせれば、障害・設計・パフォーマンス等の様々な調査が行えるようになります。

社内のナレッジや開発担当者などを頼れる環境がある場合には、そちらから情報を得ることができるかと思いますが。リソースが自分しかない場合には少なからず通らなくてはいけない道であり、そのような環境に置かれているエンジニアの方々に、このブログが何かしらの参考になれば幸いです。

よいデバッグライフを!