SAPの必須知識 汎用モジュール「CALL FUNCTION」の基礎知識

———————————————

コラム監修：佐京正則

 

大学卒業後、新卒で国内のベンチャー企業に入社。

その後、約11年間、外資系企業や国内のインフラ関連企業にてSAP ERPの導入、開発、運用までを経験。

経験モジュールはSD、MM、FI。

2015年よりライターとして活動を開始。

IT製品の導入にまつわる企業課題、エンタープライズIT製品に関するコンテンツの執筆、ホワイトペーパー作成などを手掛ける。

また、CRM/ERPベンダーに対して顧客導入事例の作成支援なども提供。

ビジネス課題と企業向けITが結びついたコンテンツを得意とする。

———————————————

 

0.はじめに

汎用モジュールは、SAP ERP内の様々なプログラムに対応できるよう設計されたモジュールのことを指します。

汎用性と再利用性が高く、開発者は汎用モジュールを活用することで、コードの重複を避け、開発時間を短縮し、全体的な開発コストを削減できます。

ここでは、ABAPerの必須知識「汎用モジュール」の基礎知識を解説します。

 

 

 

1.汎用モジュールとは？

汎用モジュールとは、SAP ERP内において「再利用可能」であり、なおかつ「汎用性」を持ったプログラムの部品です。

 

イメージとしては、複数のABAPプログラムから共通して呼び出せる“ライブラリ関数”や“共通サービス”のような存在です。

同じ処理をあちこちにコピーペーストする代わりに、一箇所にまとめておくための仕組みだと捉えると分かりやすいでしょう。

 

汎用モジュールは、ABAPプログラム側から命令文 「CALL FUNCTION」 で呼び出されます。

呼び出し元のプログラムは「どの汎用モジュールを」「どのパラメータで」実行するかを指定し、その結果として処理済みの値やメッセージを受け取ります。

 

呼び出し口さえ決めておけば、プログラムのタイプによらず同じロジックを共有できるため、開発効率と保守性の両方を高められます。”

 

“また、一度汎用モジュール化しておけば、後から仕様変更やバグ修正が発生した場合でも、その汎用モジュールを修正するだけで、CALL FUNCTION で呼び出しているすべてのプログラムに変更内容を一括で反映できます。

これにより、コード重複を減らしつつ、保守コストと障害リスクを大きく下げられる点も、汎用モジュールの大きなメリットです。”

 

 

1-1.汎用モジュールとサブルーチンの違い

いわゆるサブルーチン（FORM〜ENDFORM）のような形式ではありますが、サブルーチンとは明確に異なります。

あらかじめ親（呼び出し元）となるプログラムを用意し、そこから任意のデータを渡しつつ呼び出して使うという点はサブルーチンと同じですが、「どのプログラムからでも呼び出せるように公開されている点」が大きな違いです。”

 

・サブルーチン…定義したプログラム内でのみ利用可能

・汎用モジュール…SAP内に存在する任意のプログラムから呼び出し可能（CALL FUNCTION で利用）

 

つまり、サブルーチンが「専用の下請け処理」だとすれば、汎用モジュールは「システム全体で使い回す共通サービス」という位置づけになります。

 

例えば、請求書番号のチェックロジックをサブルーチンで書いてしまうと、そのプログラムからしか利用できませんが、汎用モジュールとして実装しておけば、請求書登録画面・一括更新バッチ・外部IFなど、あらゆるプログラムから同じロジックを共有できます。

 

さらに、サブルーチンではパラメータやデータ構造をコード上で定義する必要がありますが、汎用モジュールではSAPが標準で用意している「汎用モジュールビルダ」を使って、インターフェース（IMPORTING / EXPORTING / TABLES / 例外など）を定義できます。

 

したがって、「どのデータを入力し」「どんな結果を返し」「どこからデータを取得するか」といった設計さえできていれば、画面の案内に従って設定していくだけで、ある程度の形に仕上げることが可能です。”

 

 

1-2.汎用モジュールとサブルーチンの使い分け

次に、サブルーチンと汎用モジュールをどのように使い分けるかを整理しておきましょう。

 

両者とも「処理をまとめて再利用する」という目的は同じですが、「どの範囲で再利用したいか」によって役割が変わります。

簡単にまとめると、使い分けは次の通りです。

 

・サブルーチン…単体のプログラム内の処理を構造化する（プログラム内の共通処理）

・汎用モジュール…複数のプログラムの処理を構造化（共通化）する（システム横断の共通処理）

 

例えば、1つのレポートプログラムの中で、ヘッダ出力や集計処理を整理したいだけであればサブルーチンで十分です。

 

一方で、「伝票番号の採番ロジック」「金額の丸め処理」「権限チェック」など、今後ほかのプログラムでも使い回しそうな処理であれば、最初から汎用モジュールとして実装しておく方がベターです。

中長期的なメンテナンス性が高くなるからです。

 

なお、プロジェクトによっては「基本的に共通処理はすべて汎用モジュールとして作成する」といったルールを定めているケースもあります。

同じ処理をあちこちに実装してしまうと、後からの仕様変更時に修正漏れが発生しやすくなるためです。

 

このあたりはプロジェクトの性質や開発チームの方針によりますので、自社案件での“標準的な考え方”を早めに確認しておくと安心です。

 

 

1-3.汎用モジュールの実装方法

では実際に、汎用モジュールを利用する手順を見ていきましょう。

汎用モジュールは、自分で「定義」と「呼び出し」を行うことができれば、簡単に実装できます。

 

汎用モジュールの実装方法は以下の3ステップで行います。

 

ステップ1：汎用グループへの登録

ステップ2：汎用モジュールの登録

ステップ3：IMPORT/EXPORTの定義・ロジックの実装

 

順にみていきましょう。

 

・汎用グループへの登録
汎用グループとは、汎用モジュールを任意の観点（業務単位・機能単位など）でまとめた“フォルダ”のようなものです。

 

汎用モジュールが1つひとつの「ファイル」だとすると、汎用グループはそれらを論理的に束ねる「フォルダ」に相当します。
例えば、経費精算に関する汎用グループがあるとすると、その中に「出張精算用汎用モジュール」「日当計算汎用モジュール」「交通費精算汎用モジュール」などがまとまっているイメージです。
業務単位でグルーピングしておくことで、後からメンテナンスするときにも対象を見つけやすくなります。

新しく汎用モジュールを作成する場合は、既存の汎用グループに追加するか、新たな汎用グループを作成しておく必要があります。
汎用グループの作成・登録は、トランザクションコード「SE37（汎用モジュールビルダ）」から行います。

 

SE37画面で汎用グループ名と説明テキストを入力し、保存すればグループの準備は完了です。

 

・汎用モジュールの登録
汎用グループを用意したら、次に実際の汎用モジュールを作成します。

 

SE37の画面で汎用モジュール名を入力し「作成」を選択すると、どの汎用グループに所属させるかを指定する画面が表示されます。
ここで先ほど登録した汎用グループと紐づけます。
汎用モジュールの名称（関数名）は、グループ単位で統一した命名規則を使用するのが一般的です。
開発標準やプロジェクト内の命名ルールに従いましょう。

 

名前は頻繁に使用するため、「業務内容」や「処理内容」が一目で分かるようにしておくことが重要です。

 

・インターフェース定義とロジック実装
次に、汎用モジュールに対してインプット・アウトプットを定義します。

 

SE37の「インポート」「エクスポート」「テーブル」「例外」タブなどを使い、呼び出し元から渡されるパラメータと、汎用モジュール側から返却する値を設定していきます。

汎用モジュールの IMPORTING / EXPORTING は、サブルーチンにおける USING / CHANGING パラメータに相当すると考えるとイメージしやすいでしょう。

インターフェースを定義したら、「ソースコード」タブで実際の処理ロジック（SELECT文、ループ処理、演算など）をABAPで記述していきます。

画面の構成自体はシンプルなので、基本的なABAPに慣れていれば、初心者でも手順に従って実装できるはずです。

ここで作成した汎用モジュールは、後続の章で説明するように、ABAPプログラム側から CALL FUNCTION <汎用モジュール名> の形式で呼び出して利用します。

 

「SE37で定義・実装し、アプリケーションプログラムから CALL FUNCTION」 で利用するという全体像を押さえておくと、汎用モジュールの位置づけが理解しやすくなります。

 

 

 

2.汎用モジュールの呼び出し

作成した汎用モジュールは、命令「CALL FUNCTION」で呼び出し可能です。

また、呼び出す際にはパラメータなどを指定します。

 

 

2-1.汎用モジュールの基本書式

以下は、汎用モジュール呼び出しの際の基本書式です。

 

CALL FUNCTION ‘汎用モジュール名’

EXPORTING

“呼び出し元から渡す入力値”

IMPORTING

“汎用モジュール側から返却される出力値”

CHANGING

“呼び出し元から渡しつつ、中身を書き換える値”

TABLES

“内部テーブルとしてやり取りするデータ”

EXCEPTIONS

“エラーや例外発生時の戻り値定義”.

 

ここで重要なのは、「その汎用モジュールで必要なものだけを記述すればよい」という点です。

単純な処理であれば EXPORTING と IMPORTING だけで十分な場合もありますし、内部テーブルを扱う処理であれば TABLES を使う、といった形で使い分けます。

 

ちなみに、各パラメータブロックの役割は、ざっくり次のように整理できます。

 

・EXPORTING：呼び出し元 → 汎用モジュール へ渡す入力値（INパラメータ）

・IMPORTING：汎用モジュール → 呼び出し元 へ返す出力値（OUTパラメータ）

・CHANGING：呼び出し元から渡した値を汎用モジュール内で更新し、そのまま呼び出し元に返すパラメータ（IN/OUTパラメータ）

・TABLES：内部テーブルを丸ごと渡したり、結果テーブルを受け取ったりするためのパラメータ（レガシー開発では多用されるが、最近は IMPORTING / CHANGING で構造体テーブルを扱うケースも増えています）

・EXCEPTIONS：処理中にエラーが発生した際に、「どの種類のエラーが起きたか」を呼び出し元に知らせるための定義（sy-subrc の値と紐づけて扱います）

 

例えば、「入力パラメータを受け取り、処理した結果を1件だけ返す」ようなシンプルな汎用モジュールであれば、EXPORTING と IMPORTING だけで十分です。

一方、「明細行を内部テーブルで渡し、加工結果をテーブルで受け取る」ような処理では、TABLES や CHANGING を組み合わせて書くことになります。

 

入出力と使用するテーブル、例外を指定すれば動作するため、文法そのものは非常にシンプルだと言えるでしょう。

 

 

2-2.汎用モジュールの動かし方

汎用モジュールは単体で動かすことができず、「呼び出し元のプログラム」が必要です。

なのでテスト用のアドオンプログラムを用意するか、SAP標準機能の「汎用モジュールテスト」を用意しましょう。

 

ここでは汎用モジュールテストでの動作確認方法を紹介します。

 

・SE37を実行し、画面上で「F8」を押下

・インポートパラメータを手動で入力

・実行ボタンを押下

 

たったこれだけですが、しっかりと実装されていればエクスポートパラメータに任意の値が出力されます。

 

 

2-3.テストの入力作業を効率化するコツ

上の例を見てもわかるように、SE37からのF8実行の場合、インポートパラメータを手動で入力する手間があります。

 

インタフェースプログラムの場合、インポートパラメータは膨大な量になるので、毎回手動入力するのは面倒です。

ミスの温床になりますし。

そこでテスト画面上部にある「テストデータ一覧」でデータを保存してしまいましょう。

テストデータ一覧を押下すると、テストデータに名前を付けたうえでパラメータ情報の保存が可能です。

 

数十個におよぶインポートパラメータを何パターンもテストするような場合には、この「テストデータ一覧からの保存」が便利ですね。

 

 

 

3.汎用モジュールはどのようなときに作るべきか？

SAP関連プロジェクトでは、「汎用モジュール化すべきかどうか」で議論が起こることがあります。

 

一般的に汎用モジュールは「該当ロジックの再利用の見込み」や「保守性」を基準に作成の判断を下します。

特に次のようなケースでは汎用モジュール化を検討するとよいでしょう。

 

 

3-1.複数のプログラムから呼び出される可能性が高いとき

1つ目は、複数のプログラムから同じ処理を呼び出したいときです。

たとえば、伝票番号の採番ロジックや金額の丸め処理、権限チェックなど、将来的にレポート・画面・バッチ・インターフェースなどから利用されそうな処理は、最初から汎用モジュールに切り出しておくと開発効率が上がります。

 

例としては以下が挙げられます。

 

・権限チェック／ロール判定処理

・ログ出力・トレース出力処理

・メッセージハンドリング（共通のエラーメッセージ生成）処理

・汎用的な日付・期間計算、通貨換算処理

 

これらを汎用モジュールとして整備しておくことで、「この機能はこの汎用モジュールを使ってください」といったガイドが容易になり、プロジェクト横断で実装方針と品質をそろえやすくなります。

 

 

3-2.重要なロジックを切り出しておきたい場合

2つ目は、業務的に重要なロジックを「部品」として独立させておきたいときです。

請求チェック、与信判定、締め処理の可否判定など、ビジネスの中で必須のロジックは、汎用モジュールとして切り出しておきましょう。

単体テストがしやすいうえに、他メンバーにも仕様が伝わりやすくなります。

 

一方で、特定のレポート内でしか使わないレイアウト処理や、一度きりのデータ移行用ロジックのように、使い回す予定がない処理まで汎用モジュール化する必要はありません。

無理に汎用モジュールにすると、グループや命名の管理コストが増え、かえって開発効率が落ちてしまいます。

 

 

3-3. 仕様変更やパラメータ追加が頻発しそうな処理

税計算ロジック、丸めルール、閾値（上限・下限）、フラグ制御など、本番運用の中で微調整が入りやすい処理は汎用モジュール向きです。

 

こうした処理を直接実装してしまうと、「仕様変更のたびに複数箇所を修正する」「修正漏れによる不整合や障害が起こる」といったリスクが高まります。

一方であらかじめ汎用モジュールとして1か所に集約しておけば、「仕様変更でもその汎用モジュールだけを修正すればよい」「テストも部品単位で集中的に実施できる」などのメリットがあり、変更に強いシステムになるわけです。

 

「この処理は、運用の中で何度もチューニングされそうか？」という視点を持つようにしましょう。

 

 

 

4.汎用モジュール、BAPI、BADIの違い

前述したように、汎用モジュールは「プログラムの部品」を指す言葉です。

 

この「汎用モジュール」という土台の上に位置づけられるのが BAPI と BADI です。

どちらも実装レベルでは汎用モジュールをベースにした仕組みとして提供されており、「用途」と「設計思想」が異なります。

 

 

4-1.BAPI：標準で用意されているビジネスロジックの窓口

BAPI（Business Application Programming Interface） は、SAPが標準で公開しているビジネスAPIです。

 

「BAPI_」 から始まる名称の汎用モジュールとして実装されており、外部システム連携や他モジュールとの連携で利用されます。

「受注登録」「伝票照会」など、業務オブジェクト単位でインターフェースが整理されているのが特徴です。

 

原則として標準BAPIは、「外部から標準ロジックを呼び出すための窓口」として扱います。

 

 

4-2.BADI：カスタム処理の挿入ポイント

一方の BADI（Business Add-In） は、SAP標準のロジック内に自社固有のロジックを差し込むための拡張ポイントです。

 

標準トランザクションの中に「ここでカスタム処理を追加できます」というフックが用意されており、このフックの部分に独自実装（BADI実装）をぶら下げるイメージですね。

伝票保存時の追加チェックや、標準画面での項目補完など、「標準の流れはそのまま活かしつつ、一部だけ振る舞いを変えたい」といったケースで使われます。

 

 

4-3.3者の違い

整理すると、

 

汎用モジュール：CALL FUNCTION で呼び出すプログラム部品全般（もっとも広い概念）

BAPI：外部連携・モジュール間連携のための標準汎用モジュール群（公開API）

BADI：標準処理にカスタマイズロジックを差し込むための拡張仕組み（カスタマイズ用）

 

という関係になります。

 

実務的には、

 

「自前のロジックを共通部品化したい → 汎用モジュール」

「外部IFの入口にして、外部から標準ロジックを使いたい → BAPI」

「標準ロジックの一部だけ自社固有のものに変えたい → BADI」

 

と覚えておくとイメージが持ちやすくなるでしょう。

 

 

 

5.汎用モジュールのスキルは市場価値を上げるか？

汎用モジュールの知識と実務経験は、ABAPエンジニアとしての市場価値を「かなり」押し上げます。

 

理由は、汎用モジュールがSAP ERPにおける主要な開発技術のひとつであり、アドオン開発ではほぼ必須だからです。

開発現場では、「共通部品としてロジックを切り出し、CALL FUNCTION で再利用できる形にする」スキルが常に求められます。

 

また、実務では「標準機能（BAPIなど）だけでは要件を満たせない部分を、汎用モジュールで補う」ケースが非常に多くあります。

たとえば、標準BAPIの前後に追加チェックを挟んだり、複数の標準機能をまとめて呼び出す“ラッパー”を作ったりといった設計ができるエンジニアは、プロジェクト側から重宝されます。

 

一方で、「何でも自作する」のではなく、まず標準で用意されているBAPIや既存の汎用モジュールを探し、使えるものは積極的に流用できることも重要です。

BAPI Explorer や SE37/SE80 で関連するオブジェクト名から候補を探し、仕様を読み解いたうえで「標準で足りない部分だけを自作する」判断ができる人は評価されやすくなります。

 

 

 

6.まとめ

今回は汎用モジュールの実装方法と、呼び出し命令「CALL FUNCTION」について解説しました。

 

ABAPerとしては非常に入門的な内容ですが、頻繁に使用する知識でもあります。

汎用モジュールを使いこなせるようになると、開発効率がかなり上昇します。

「標準機能を理解したうえで、汎用モジュールで不足分を設計・実装できる人」は、どのプロジェクトでも横断的に活躍できる人材です。汎用モジュールの設計・実装・再利用をきちんと身につけておくことは、ABAPエンジニアとしての単価や案件の選択肢を広げるうえで有利になります。

 

また、汎用モジュール自体を組み合わせてサービス化しているベンダーも多いので、極めて行くとかなり強力な武器になります。

 

基礎知識と侮ることなく、しっかり使いこなせるようにしておきましょう。