SAPモジュールプールプログラミングとは？ダイアログプログラミングの構造と保守手順

SAPのモジュールプールプログラミングは、ABAPで画面付きの業務処理を作るための開発方式です。SAP GUI上に表示する画面をDynproとして定義し、画面の前後でABAP処理を実行します。ダイアログプログラミング、従来型画面プログラミング、モジュールプール開発という呼び方もあります。

01モジュールプールプログラミングの基本

モジュールプールは、実行可能プログラムのように直接起動するレポートではなく、画面処理を中心に構成されたABAPプログラムです。通常、プログラム種別はモジュールプールとして登録し、トランザクションコードから最初の画面を呼び出します。

画面処理は、次の要素で構成されます。

• ABAPプログラム：画面から呼び出す処理モジュールを保持する
• Dynpro：画面項目、ラベル、ボタン、サブ画面、画面属性を定義する
• 画面フロー・ロジック：PBOとPAIの処理モジュールを呼び出す
• GUIステータス：メニュー、ツールバー、ファンクションコードを定義する
• トランザクションコード：開始画面とプログラムを利用者の操作に結び付ける

SAP用語全体の位置付けを確認する場合は、SAPモジュールとはも参照してください。モジュールプールは、FI、MM、SDなどの業務領域に固有の画面処理を実装するための技術要素です。

02Dynproの処理サイクル

Dynproは、画面を表示して入力を受け取り、利用者の操作に応じて次の画面や処理へ進む単位です。1つの画面番号に対して、画面属性、レイアウト、項目、フロー・ロジックを定義します。

基本的な処理サイクルは、次の順序です。

1. トランザクションコードが開始画面を呼び出す
2. PBOで画面表示前の値設定や入力属性を調整する
3. 画面がSAP GUIに表示される
4. 利用者が値を入力し、保存や戻るなどの操作を行う
5. PAIで入力値を検証し、ファンクションコードを判定する
6. 次の画面へ遷移する、同じ画面を再表示する、または処理を終了する

この流れを理解すると、画面に値が出ない問題と、ボタンを押しても処理が進まない問題を切り分けやすくなります。画面表示前の問題はPBO、利用者の操作後の問題はPAIから調査を始めます。

03PBOとPAIの役割

PBOはProcess Before Outputの略で、画面を出力する直前に実行されます。データベースから取得した値を画面項目へ設定したり、項目を入力可能または表示専用に切り替えたり、GUIステータスを設定したりする場所です。

PAIはProcess After Inputの略で、画面入力を受け取った直後に実行されます。入力チェック、必須項目の検証、ファンクションコードの分岐、保存処理、次画面の指定などを行います。

PROCESS BEFORE OUTPUT.
  MODULE status_0100.
  MODULE set_screen_data.

PROCESS AFTER INPUT.
  MODULE user_command_0100.

PBOで設定した値が画面に表示されない場合は、画面項目とABAP変数の結び付きを確認します。PAIで入力値を受け取れない場合は、画面項目名、項目属性、処理モジュールの呼び出し位置を順に確認します。

ABAPの文法や開発オブジェクトとの関係を整理したい場合は、ABAPとはを確認すると、モジュールプールの説明とつながります。

04画面フロー・ロジックの設計

画面フロー・ロジックは、Dynproの処理順序を宣言する部分です。主にPBOとPAIのセクションを持ち、それぞれからABAPプログラム内の処理モジュールを呼び出します。

処理モジュールは、画面番号を含めた命名にすると保守しやすくなります。たとえば、画面0100のPBOならSTATUS_0100、画面0100のPAIならUSER_COMMAND_0100のように、役割と画面を名前から判別できる形にします。

画面遷移は、次画面の指定とファンクションコードの処理を分けて考えます。通常処理では次画面へ進み、戻る操作では前画面へ戻り、終了操作ではトランザクションを終了します。画面番号を直接あちこちに記述するより、画面遷移の責任を整理した方が変更時の影響を抑えられます。

05OK_CODEとファンクションコード

ボタン、メニュー、キーボード操作などの利用者アクションは、ファンクションコードとしてPAIへ渡されます。プログラム側では、画面のOK_CODEを受け取り、CASE文などで処理を分岐します。

MODULE user_command_0100 INPUT.
  DATA lv_ok_code TYPE sy-ucomm.

  lv_ok_code = sy-ucomm.
  CLEAR sy-ucomm.

  CASE lv_ok_code.
    WHEN 'SAVE'.
      PERFORM save_data.
    WHEN 'BACK'.
      LEAVE TO SCREEN 0.
    WHEN 'EXIT'.
      LEAVE PROGRAM.
  ENDCASE.
ENDMODULE.

実際の画面では、GUIステータスに登録したファンクションコードと、PAIで判定する値を一致させます。ボタンを押しても分岐しないときは、GUIステータス、画面上のボタン、OK_CODE、PAIモジュールの順に確認します。

OK_CODEの処理後に値を消去する設計にすると、直前の操作が次の画面サイクルへ残ることを防げます。保存処理では、入力チェック、データ更新、コミット、メッセージ表示の順序も明確にします。

06画面項目とデータ連携

Dynproの画面項目は、ABAPプログラムのグローバルデータや構造項目と名前で連携します。画面項目名とプログラム側の項目名が一致しない場合、PBOで値を設定しても表示されず、PAIでも期待した値を取得できません。

入力値をデータベースへ保存する場合は、画面項目の値をそのまま更新処理へ渡さず、次の検証を行います。

• 必須項目が入力されているか
• 日付、数量、通貨などの形式が適切か
• 権限上、対象データを変更できるか
• 対象レコードが存在し、更新対象として有効か
• 同時更新や業務上の整合性に問題がないか

登録処理と更新処理が複数のデータ変更から構成される場合は、LUWとはで説明される論理作業単位を意識します。途中でエラーが発生したときに、部分的な更新だけが残らないよう、コミットとロールバックの責任範囲を設計します。

07モジュールプールを調査する手順

既存画面の仕様を調べるときは、画面上の表示から始めると効率的です。トランザクションコード、画面番号、項目名、ボタンのファンクションコードを記録し、そこからプログラムと画面定義へ進みます。

実務では次の順序で確認します。

1. 対象トランザクションを特定する
2. 現在の画面番号を確認する
3. 画面項目の技術名と入力属性を確認する
4. PBOの処理モジュールで初期値設定を追う
5. PAIの処理モジュールで入力チェックと分岐を追う
6. GUIステータスで操作可能なファンクションコードを確認する
7. 次画面指定と終了処理を確認する
8. データ更新がある場合はLUWとコミット位置を確認する

デバッグでは、PBOとPAIの処理モジュールにブレークポイントを置きます。画面が表示される前に停止するか、操作後に停止するかで、調査対象を分けられます。入力値の確認では、画面項目、対応するABAP項目、データベース更新用の作業領域を順番に比較します。

08よくある障害と切り分け

画面に初期値が表示されない

PBOの処理モジュールが呼び出されているか、取得処理が値を返しているか、画面項目とABAP項目の名前が対応しているかを確認します。画面項目が表示専用になっている場合も、値の見え方に影響します。

入力した値がPAIで空になる

入力項目の技術名、画面項目とプログラム項目の対応、PAIモジュールの呼び出し順序を確認します。画面項目が別の構造項目に割り当てられている場合は、想定した変数とは異なる場所に値が格納されます。

ボタンを押しても処理が実行されない

GUIステータスにファンクションコードが登録されているか、画面上のボタンが期待したコードを送信しているか、PAIでそのコードを判定しているかを確認します。コードを受け取った直後にCLEARしている場合は、ブレークポイントをその前に設定します。

保存後に同じデータが再表示される

更新処理の実行結果、コミットの位置、PBOで再読込する条件を確認します。保存後の画面遷移でPBOが再実行されるため、PBOが古い作業領域の値を再設定していないかも確認します。

画面遷移が意図せず終了する

PAI内の次画面指定、LEAVE系の処理、戻る・終了ファンクションの分岐を確認します。サブ画面や呼び出し元画面を含む構成では、現在の画面スタックと遷移先を記録してから調査します。

09変更と輸送の管理

モジュールプールの変更では、ABAPソース、Dynpro、GUIステータス、テキスト、検索ヘルプなど、関連する開発オブジェクトをまとめて確認します。画面だけを変更しても、対応する処理モジュールやGUIステータスが輸送対象から漏れると、移送先で動作が変わります。

変更依頼へ登録する前に、次の確認を行います。

• 変更した画面番号とプログラム名を記録する
• PBO、PAI、GUIステータスの変更を確認する
• 新しい画面やサブ画面の依存関係を確認する
• 権限、メッセージ、テーブル変更の有無を確認する
• 開発、品質保証、本番の各環境で動作確認の観点を分ける

輸送依頼の考え方は、Transport Requestとはも関連します。画面変更の影響範囲を記録しておくと、障害発生時に直前変更との関係を調べやすくなります。

10現場での設計判断

モジュールプールは、複数画面を使う業務フローや、入力順序を制御する処理に適しています。一方、単純な一覧表示や大量データ処理では、レポート、ALV、WebベースのUIなど別の方式が適する場合があります。

既存のモジュールプールを保守する場合は、画面の見た目だけでなく、PBOとPAI、GUIステータス、トランザクションコード、更新処理を一つの処理単位として捉えます。特に、画面操作とデータ更新の境界を明確にし、エラー時のメッセージと更新状態を確認できるようにすることが重要です。

ダイアログプログラミングの調査では、画面、イベント、ファンクションコード、データ更新を個別に見るのではなく、1回の画面サイクルとして追跡します。この見方を使うと、表示・入力・遷移・保存のどこで問題が起きているかを短時間で特定できます。