SAP連携
BAPIの命名規則とBORとは：オブジェクト・メソッドの読み解き方
SAPのBAPIを調査・設計するときに役立つ命名規則とBusiness Object Repository（BOR）の関係を整理します。オブジェクトタイプ、メソッド、関連する関数モジュールの確認手順と、名前だけで判断できない場合の切り分け方を実務向けに解説します。
BAPIを調査するときは、関数モジュール名だけでなく、Business Object Repository（BOR）に登録されたオブジェクトタイプとメソッドの関係を確認します。名前から業務用途を推測できても、実際の入力構造、戻り値、更新処理の確定にはメタデータとテストが必要です。この記事では、既存BAPIの読み解き方と、カスタムBAPIを設計するときの整理方法を扱います。
BAPIとBORの役割を分けて理解する
BORは、業務オブジェクトタイプ、その属性、イベント、メソッドなどを管理するリポジトリです。BAPIは、業務オブジェクトに対して外部から呼び出せる標準化されたインターフェースとして位置づけられます。したがって、BORのメソッドと、実際にRFCで呼び出す関数モジュールは関連しますが、同じ種類のオブジェクトではありません。
実務では、次の3層に分けて確認すると混乱しにくくなります。
- BORオブジェクトタイプ：業務対象を表す単位
- BORメソッド：業務対象に対する操作
- RFC対応関数モジュール：外部システムから実行する技術的な呼び出し単位
たとえば受注を扱う場合、受注を表すオブジェクトタイプに対して、作成、変更、照会などのメソッドが定義されます。実際の連携では、対応するBAPI関数モジュールを呼び出し、パラメータと戻りメッセージを処理します。BAPIの基本概念はBAPIの基本とRFCとの関係でも整理しています。
BAPI命名規則の基本パターン
代表的な命名は、BAPI_<BusinessObject>_<Method> の形式です。<BusinessObject>には業務オブジェクトを表す名前、<Method>には操作を表す名前が入ります。たとえばオブジェクトの詳細取得を示す名前では、オブジェクト名とGETDETAILのような操作名を組み合わせます。
よく使われる操作の表現には、次のようなものがあります。
| 操作の意味 | 命名で使われる表現の例 | 確認する内容 |
|---|---|---|
| 作成 | CREATE | 必須項目、採番、コミット要否 |
| 変更 | CHANGE | 変更可能項目、更新条件 |
| 削除または取消 | DELETE、業務固有の操作名 | 物理削除か業務取消か |
| 詳細照会 | GETDETAIL | キー項目、返却構造 |
| 一覧照会 | GETLIST | 選択条件、ページング、件数 |
この規則は検索の入口として有効ですが、名前だけで処理内容を確定しません。たとえばDELETEという語があっても、業務上の取消やステータス変更を行う実装があります。SE37やBAPI関連のメタデータで、パラメータ、例外、戻りメッセージ、更新処理を確認します。
カスタムBAPIでは、業務オブジェクトと操作の名前を一貫させます。既存の標準BAPIと区別できる名前空間を使い、入力構造と出力構造を業務用語に合わせて定義します。呼び出し側が名前から用途を把握できること、将来の変更で既存契約を壊さないことが重要です。
BORオブジェクトとメソッドを確認する手順
既存BAPIの調査は、次の順番で進めます。
- 連携仕様から業務対象と業務操作を分けて記録する
- BAPI名から候補となるオブジェクトとメソッドを検索する
- BOR上のオブジェクトタイプとメソッドの説明を確認する
- 対応する関数モジュールのインターフェースを確認する
- テスト環境で正常系、必須項目不足、権限不足を個別に検証する
- 更新系処理ではコミットとロールバックの扱いを確認する
BOR上のメソッドを調べるときは、メソッドの説明だけでなく、対象キー、戻り値、関連する属性も確認します。オブジェクトのキーを誤ると、関数モジュールの実行自体は成功しても対象データを取得できない場合があります。
呼び出し方式や同期・非同期の整理が必要なときは、RFCの通信タイプと使い分けを参照してください。BAPIの選定と通信方式の選定は別の判断として記録すると、障害時の切り分けが容易になります。
オブジェクト名と関数モジュール名を照合する
BAPIの名前から候補を絞った後は、次の情報を同じ表にまとめます。
| 確認項目 | 記録する内容 |
|---|---|
| BORオブジェクトタイプ | 業務対象の識別子と説明 |
| BORメソッド | 操作名、キー、戻り情報 |
| 関数モジュール | RFC呼び出しに使う技術名 |
| 入力 | 構造、テーブル、必須項目 |
| 出力 | 結果構造、戻りメッセージ |
| 更新制御 | コミット、ロールバック、ロック |
| 権限 | 実行ユーザーに必要な権限 |
この表を作ると、同じ業務対象に複数のBAPIがある場合でも、用途の違いを比較できます。作成用、変更用、照会用のBAPIを別々に扱い、トランザクション境界とエラー処理を仕様に明記します。
BAPIの戻りテーブルにエラーが入る設計では、RFCの技術的な実行成功と、業務処理の成功を分けて判定します。呼び出しが通信エラーにならなくても、戻りメッセージにエラーや警告が含まれることがあります。更新系では、成功メッセージを確認した後にコミットを実行し、エラー時にはロールバックを行う流れを連携側で管理します。
命名だけで判断できない場合の切り分け
名前と実際の動作が一致しないように見える場合は、まず呼び出し先、パラメータ、戻りメッセージを分けて確認します。特に次の順序で調べると、推測による修正を減らせます。
- 呼び出している関数モジュールが仕様書の名前と一致しているか確認する
- 接続先とログオンユーザーを確認する
- 入力構造のキー、日付、単位、通貨などの値を確認する
- 戻りメッセージを全文で保存する
- 更新系ではコミットの実行結果を確認する
- 同じ入力をテスト環境で再現する
接続先の問題とBAPI内部の業務エラーは、別のログとして記録します。RFC接続の設定確認が必要な場合は、RFC宛先をSM59で確認する手順が関連します。接続が確立していても、ユーザー権限、会社コード、プラント、販売組織などの業務条件で処理が失敗するため、通信結果だけで成功判定をしません。
カスタムBAPIを設計するときの実務ポイント
カスタムBAPIを作る場合は、最初に業務契約を定義します。呼び出し側が渡すキー、必須項目、初期値、更新対象、戻りメッセージ、コミット方針を文書化します。関数モジュールの名前を先に決めるより、業務オブジェクトと操作の境界を先に決める方が、後続の設計変更を抑えられます。
設計時には次の点を確認します。
- オブジェクト名が業務用語と一致している
- メソッド名が一つの責務を表している
- 入出力構造が呼び出し側で扱いやすい
- エラーと警告を戻りメッセージで判定できる
- 更新処理のコミット責任が明確である
- 再実行時の重複登録や二重更新を防げる
- 権限チェックとロック処理を設計に含めている
標準BAPIを拡張する場合は、標準インターフェースの意味を変えず、追加項目の扱いを明確にします。既存の連携先が依存する項目やメッセージを変更すると、呼び出し側の判定に影響します。リリース前には、正常系だけでなく、部分入力、重複キー、ロック中、権限不足、コミット失敗を検証します。
運用で残すべきBAPI調査記録
BAPIを一度調べて終わりにせず、次の情報を連携資産として残します。
- 業務オブジェクトとメソッドの対応
- 関数モジュール名と接続先
- 入出力項目の説明とサンプル値
- 成功・警告・エラーの判定方法
- コミットとロールバックの手順
- 必要権限と実行ユーザー
- テスト結果と再現条件
- 変更履歴と影響を受ける連携先
この記録があれば、担当者が変わってもBAPI名の推測だけで調査を始めずに済みます。特にオブジェクト、メソッド、関数モジュールを別列で管理することが、BORとRFCの役割を混同しないための基本です。
まとめ
BAPIの命名規則は、業務オブジェクトと操作を見つけるための検索手掛かりです。BORではオブジェクトタイプとメソッドの関係を確認し、RFCでは対応する関数モジュールのインターフェースと実行結果を確認します。
実務では、名前、メタデータ、入力、戻りメッセージ、コミット、権限を一つの調査記録にまとめます。命名を設計の軸にしつつ、最終的な動作はテストとログで確認することで、連携障害の切り分けとカスタムBAPIの保守性を高められます。