SAP RFC & BAPI
SAP BAPIとは？RFCとの違いと標準インターフェースの使い方
SAP BAPIの意味、RFCとの違い、標準インターフェースとしての設計、呼び出し時の確認ポイントを、ABAPや外部連携を担当する実務者向けに整理します。
SAP連携の設計で「BAPIを使う」と決めたあと、RFCとの関係、対象の業務オブジェクト、コミットの扱い、エラーの調査箇所を整理しないまま実装を始めると、接続は成功しているのに業務データが確定しない、という問題が起きます。この記事では、BAPIの役割をRFCとの違いから整理し、設計・実装・障害対応の順に確認します。
BAPIとは何か
BAPIは、SAPの業務オブジェクトに対して外部プログラムから業務処理を実行するための、標準化されたインターフェースです。BAPIはBusiness Application Programming Interfaceの略で、製品内部の画面操作をそのまま自動化するのではなく、受注、品目、仕入先、在庫などの業務単位に沿ってデータを受け渡します。
技術的には、BAPIはRFCで呼び出せる関数モジュールとして実装されます。ただし、RFCで呼び出せる関数モジュールがすべてBAPIというわけではありません。BAPIには業務オブジェクトとの対応、公開されたインターフェース、パラメータや戻り値の設計があり、連携側はこの契約に従って呼び出します。
BAPIを選ぶと、SAP GUIの画面項目や画面遷移に依存しない連携を設計できます。画面入力の記録や独自テーブルへの直接更新よりも、業務ロジックと整合性を保ちやすい点が実務上の利点です。利用前には、対象BAPIの仕様、必須項目、戻り値、更新確定の手順を確認します。
RFCとBAPIの違い
RFCは、SAPシステム間またはSAPと外部システムの間で、リモートから関数モジュールを呼び出すための通信方式です。一方、BAPIは業務処理を外部公開するためのインターフェースです。つまり、RFCは通信の仕組み、BAPIは業務機能の公開契約という関係です。
| 観点 | RFC | BAPI |
|---|---|---|
| 主な意味 | リモート関数呼び出しの通信方式 | 業務オブジェクト向けの標準インターフェース |
| 対象 | RFC対応の関数モジュール | 公開された業務メソッド |
| 設計の焦点 | 接続先、宛先、呼び出し方式 | 業務データ、整合性、戻り値 |
| 利用例 | 独自のリモート関数を呼び出す | 受注登録や品目取得などを実行する |
接続設定や通信方式を詳しく整理するときは、RFCの基本とリモート関数呼び出しを参照してください。BAPIを使う場合も、接続先の定義、ユーザー権限、ネットワーク、文字コード、タイムアウトはRFCの仕組みに従います。
BAPIを選ぶ判断基準
BAPIを採用するかは、業務要件と対象システムの公開インターフェースを確認して決めます。次の順序で調査すると、実装後の手戻りを抑えられます。
- 業務単位を定義する：登録、変更、照会、削除、確定など、外部システムが実行したい業務を分けます。
- 対象オブジェクトを特定する：受注、購買、品目、在庫、請求など、SAP側の業務オブジェクトに対応付けます。
- 公開インターフェースを確認する：BAPIの入力、出力、戻り値、必須項目、更新処理を確認します。
- 業務トランザクションを確認する：BAPIで実現できる範囲と、画面や別の業務APIが必要な範囲を分けます。
- テストデータで整合性を確認する：登録結果、伝票番号、ステータス、エラーメッセージを検証します。
BAPIの選定では、関数名だけで判断せず、業務オブジェクトと処理結果を確認します。似た名前のBAPIでも、登録対象、更新可能な項目、後続処理、コミット要件が異なる場合があります。
標準インターフェースとしての設計
BAPIを外部連携で使う場合、連携処理を「入力変換」「BAPI呼び出し」「戻り値判定」「更新確定」「結果通知」に分けます。入力変換では外部システムのコードをSAP側のコードへ変換し、単位、通貨、日付、桁数、先頭ゼロを確認します。
戻り値は、呼び出しの成否だけでなく、メッセージ種別、メッセージ番号、メッセージ変数、登録された伝票番号を保存します。外部システムに返すエラーは、利用者が修正できる入力エラーと、管理者が調査するシステムエラーに分類すると運用しやすくなります。
更新系BAPIでは、BAPIの呼び出しが成功した後に更新確定が必要になる構成があります。呼び出し結果を確認せずにコミットすると、不完全なデータを確定する可能性があります。反対に、必要な確定処理を実行しないと、呼び出し側では成功に見えてもデータが確定しません。処理単位、再実行時の重複、ロールバック方針を設計書に明記します。
呼び出し方式の選択や同期・非同期処理の整理には、RFCとBAPIの通信方式が役立ちます。大量データでは、1件ごとの呼び出しによる負荷、並列数、応答待ち時間、再送方法も合わせて決めます。
ABAPでの確認ポイント
ABAP側でBAPIを呼び出す場合は、対象関数モジュールのインターフェースを確認し、構造、テーブル、戻り値を正しくマッピングします。特に、ヘッダと明細の関係、明細番号、変更フラグ、単位、通貨、日付形式は、登録結果に直結します。
開発時には次の観点を確認します。
- 入力構造の必須項目が埋まっているか
- 明細テーブルのキーが一意になっているか
- 戻り値テーブルのメッセージをすべて収集しているか
- 成功時に返される伝票番号やオブジェクトキーを保存しているか
- 更新確定とロールバックの境界が処理単位と一致しているか
- 同じ要求を再送した場合の重複登録を防げるか
BAPI名、関連する業務オブジェクト、BOR上の名称を対応付けて管理すると、後任者が仕様を追いやすくなります。命名とBORの関係は、BAPIの命名規則とBORの確認方法で整理しています。
外部システムから呼び出すときの実装
外部システムからBAPIを呼び出す場合は、まず接続先、クライアント、ユーザー、言語、認証方式、接続プールを設定します。接続先の設定は、開発・検証・本番で分離し、接続先をコードへ直接埋め込まない構成にします。
次に、入力データの検証をSAP呼び出し前に実行します。必須項目、コード体系、日付、数量、通貨、文字数を外部側で検証しておくと、SAPへの不要な呼び出しとログの混乱を減らせます。ただし、SAP側で行われる権限、マスタ、ステータス、期間、在庫などの業務チェックも結果として扱います。
レスポンスでは、通信エラー、BAPIの業務エラー、更新確定エラーを分けて記録します。タイムアウトだけを理由に即時再送すると、SAP側で処理済みの要求が重複する可能性があります。要求ID、外部キー、送信時刻、応答時刻、伝票番号を記録し、再送前に処理状況を確認できるようにします。
BAPI障害の切り分け
BAPIの障害は、接続、認証、インターフェース、業務データ、更新確定、性能の層に分けて調査します。最初に、SAPへ到達しているか、呼び出しが実行されたか、戻り値が生成されたかを確認します。
接続・認証の問題では、接続先、クライアント、ユーザー、パスワード、ネットワーク、接続権限を確認します。BAPIの戻り値が存在しない場合は、業務処理以前の通信または認証を優先して調べます。
業務エラーでは、戻り値のメッセージ種別、番号、変数を保存し、同じ入力をSAP側の検証環境で再現します。マスタ不足、期間クローズ、ステータス不整合、権限不足は、通信が正常でもBAPIが処理を完了できない代表的な要因です。
更新結果の問題では、コミットの有無、ロールバック、更新タスク、後続処理を確認します。障害の記録には、BAPI名、呼び出し時刻、外部要求ID、入力の識別子、戻り値、再送回数を含めます。よくあるエラーの分類と確認順序は、RFC・BAPIの代表的なエラーパターンにまとめています。
運用で守るポイント
本番運用では、BAPIの仕様書だけでなく、呼び出し元、業務責任者、エラー通知先、再送手順を明確にします。障害時に同じ要求を何度も送らないため、処理状態を「受付」「送信中」「SAP処理済み」「確定済み」「要調査」のように管理します。
権限は、対象BAPIの実行に必要な範囲へ絞り、開発用ユーザーを本番連携に流用しません。ログにはパスワードや機密データを出力せず、調査に必要なキーとメッセージを残します。接続先変更、BAPI変更、SAP側の業務設定変更は、テスト結果と切り戻し手順を添えて管理します。
BAPIは、画面操作を置き換えるだけの仕組みではありません。業務オブジェクト、入力契約、戻り値、更新確定、再送制御を一つの処理設計として扱うことで、安定したSAP連携を運用できます。