SAP RFC・BAPI呼び出しで起きるエラーパターンと実践的な切り分け手順

RFCやBAPIの呼び出しエラーは、通信確立、認証・権限、入力値、業務ルール、トランザクション確定のどこで発生したかによって対処が変わります。最初からABAP実装だけを調べるのではなく、処理を層に分けて確認すると、再現条件と担当範囲を整理しやすくなります。

BAPIはRFC対応の関数モジュールとして呼び出せる業務インターフェースです。インターフェースの基本はBAPIの基本で確認でき、RFC接続の仕組みはRFCの全体像に整理されています。ここでは、呼び出し側のアプリケーション、SAP側の関数モジュール、業務データ、更新確定を一つの運用フローとして扱います。

01エラーを層に分けて確認する

最初に確認するのは、エラーが「SAPへ到達する前」「関数モジュールの実行中」「戻り値の判定時」「更新確定時」のどこに現れたかです。接続自体が成立していない場合、BAPIのパラメータを変更しても改善しません。一方、接続できていてRETURNに業務エラーが入る場合は、ネットワーク設定よりも入力値やマスタ、業務ステータスを調べます。

エラーメッセージの文字列だけで判断せず、呼び出しID、実行時刻、接続先クライアント、呼び出した関数名、入力データの識別子を記録します。個人情報や認証情報はログに残さず、再現に必要な業務キーだけを残す運用が安全です。

02RETURN構造を先に評価する

多くのBAPIでは、戻り値のRETURNパラメータに処理結果が格納されます。典型的にはBAPIRET2型の構造またはそのテーブルを使い、TYPE、ID、NUMBER、MESSAGE、MESSAGE_V1からMESSAGE_V4などを確認します。呼び出し側は例外だけでなく、RETURNに入ったメッセージも必ず評価します。

TYPEは処理結果を分類する重要な値です。Sは成功、Iは情報、Wは警告、Eはエラー、Aは異常終了として扱う設計が一般的です。業務要件によって警告を許容するかを決め、少なくともEとAを成功扱いにしない判定を実装します。

CALL FUNCTION 'BAPI_EXAMPLE'
  EXPORTING
    headerdata = ls_header
  TABLES
    return     = lt_return.

DATA(lv_failed) = abap_false.

LOOP AT lt_return INTO DATA(ls_return).
  IF ls_return-type = 'E' OR ls_return-type = 'A'.
    lv_failed = abap_true.
  ENDIF.
ENDLOOP.

MESSAGEだけを保存すると、同じ文面の原因を区別できないことがあります。TYPE、ID、NUMBER、MESSAGE_V1からMESSAGE_V4を併記し、呼び出し時刻と業務キーを組み合わせて記録します。外部システムへ返すメッセージは利用者向けに整え、内部ログには原因分析に必要な技術情報を残します。

03通信エラーを切り分ける

通信エラーでは、まずRFC宛先が想定した接続先を指しているかを確認します。接続先システム、クライアント、ユーザー、言語、接続方式、ゲートウェイ関連の設定を確認し、接続テストと実際のBAPI実行を分けて記録します。接続テストが失敗する段階では、業務データの調査を先に進めません。

タイムアウトは、ネットワーク遅延だけでなく、SAP側処理の長時間化、ロック待ち、大量データ取得、外部システム側の応答待ちでも発生します。呼び出し側のタイムアウト値を単純に延長せず、処理時間、対象データ量、SAP側の実行状況を同じ時刻で照合します。

RFCには同期型、トランザクション型、キュー型など複数の通信方式があります。方式ごとの再送、順序性、エラー確認の考え方はRFCの通信方式と合わせて整理すると、再実行による二重登録を防ぎやすくなります。

04権限エラーを実行コンテキストで見る

ダイアログユーザーでSAP GUIから実行できても、RFCユーザーから同じBAPIを実行できるとは限りません。RFCユーザーには、対象の関数モジュールを実行する権限に加え、BAPIが参照・更新する業務オブジェクトや組織範囲に対応した権限が必要です。

確認時は、ユーザー名、クライアント、呼び出し元システム、実行日時、対象オブジェクトを記録します。権限不足の調査では、失敗時の認可チェックログを担当者に確認してもらい、広い権限を一時的に付与する方法ではなく、実際に不足している権限を特定します。

接続先クライアントの違いも結果に影響します。開発、品質保証、本番でマスタや組織設定が異なる場合、同じ入力値でも結果が変わります。環境名だけでなく、クライアント番号と接続先を監視ログに残します。

05入力値と業務ルールを確認する

入力値エラーでは、必須項目、桁数、形式、単位、通貨、日付、言語、組織項目を順番に確認します。画面入力で自動補完される値が、BAPI呼び出しでは明示的に必要になることがあります。画面処理をそのまま外部インターフェースへ置き換えず、BAPIのインターフェース定義と業務上の必須条件を照合します。

特に確認しやすい代表例は次のとおりです。

• ヘッダと明細で会社コード、プラント、保管場所などの組織項目が一致しているか
• 材料、得意先、仕入先、勘定コードなどのマスタが接続先に存在するか
• 日付が会計期間、購買期間、販売期間などの業務条件を満たしているか
• 数量、単位、通貨、換算値が対象マスタと整合しているか
• 参照伝票のステータスが後続処理を許可しているか

空白と初期値は同じ意味にならない場合があります。文字列の前後空白、数値のゼロ、日付の初期値、通貨コードの未設定を呼び出し前に正規化し、送信したペイロードを監査可能な形で保存します。パスワードや個人情報などの機密値はマスキングします。

06ロックと並列実行を調べる

同じ業務キーを複数の処理が同時に更新すると、ロックエラー、更新待ち、重複作成が発生します。再試行の前に、対象伝票やマスタが別処理で使用中でないかを確認します。短時間の一時的な競合には限定的な再試行が有効ですが、同じ入力を無制限に送る設計は避けます。

再試行には冪等性が必要です。外部側で一意な要求IDを発行し、SAP側の伝票番号や参照項目と関連付けます。処理結果を受け取れなかった場合でも、先に登録が成功していないかを照会してから再送します。タイムアウトだけを理由に新しい登録を送ると、二重登録につながる可能性があります。

07COMMITとロールバックを設計する

BAPI呼び出しがRETURNで成功しても、更新確定が完了しているとは限りません。更新系BAPIでは、処理の後に適切なコミット処理を実行し、コミット結果も確認します。エラーが発生した場合は、同じ論理トランザクション内でロールバックを実行し、呼び出し側の状態とSAP側の状態を記録します。

一般的な流れは、入力検証、BAPI実行、RETURN評価、成功時のコミット、失敗時のロールバック、結果照会です。複数のBAPIを組み合わせる場合は、どこまでを一つの論理単位にするかを先に決めます。途中のBAPIだけが確定する設計では、後続処理が失敗したときに不完全な業務データが残ります。

1. 要求IDと業務キーを発行する
2. 入力値と接続先を検証する
3. 更新系BAPIを実行する
4. RETURNのE/Aを確認する
5. 成功時にコミットを実行する
6. コミット結果を確認する
7. 失敗時はロールバックし、状態を照会する

コミット後に外部システムへの応答が失われるケースも想定します。応答がないときは、再登録ではなく業務キーや要求IDによる照会を先に行います。監査ログには、BAPI実行、RETURN、コミット、照会、最終判定を一連の相関IDで結び付けます。

08ABAP側で再現性を確保する

外部呼び出しだけで原因が分からない場合は、同じ接続先クライアント、同じユーザー権限、同じ入力値でSAP側の再現を行います。テストデータは本番業務データのコピーを無制限に使わず、機密情報を除いた再現用データを準備します。

ABAP側では、受信した入力、BAPI実行前の変換結果、RETURN全件、コミットまたはロールバックの結果を相関IDで追跡します。大量のペイロードを常時記録するのではなく、エラー時に必要な項目を残す運用とし、ログの保持期間とアクセス権も定義します。

RFC接続、BAPI実装、業務データのどこに問題があるかを分けるため、最小の入力で成功するケースを作ります。その後、ヘッダ、明細、組織項目、参照伝票を一つずつ追加します。最小ケースが成功し、完全なケースだけが失敗するなら、差分項目と業務ルールに調査対象を絞れます。

09運用時の再発防止策を整える

障害対応後は、エラーを「通信」「認証・権限」「入力」「業務ステータス」「ロック」「コミット」「外部応答」に分類してナレッジ化します。各分類に、検知方法、確認するログ、担当チーム、再実行条件、利用者への案内を紐付けます。

監視では、エラー件数だけでなく、BAPI別の成功率、処理時間、タイムアウト率、再試行回数、RETURNのTYPE別件数を集計します。特定の業務キーで失敗が集中する場合は、マスタや業務ステータスを確認し、全体的な通信障害と区別します。

再実行手順には、対象期間、対象システム、要求ID、重複確認、コミット状態、ロールバック状態、担当者の承認を含めます。自動再試行は通信断や一時的なロックなど対象を限定し、入力不備や権限不足を自動送信し続けないようにします。

10切り分け結果を記録する

最終的な障害記録には、発生時刻、呼び出し元、接続先、クライアント、RFC宛先、関数名、業務キー、RETURNのTYPE・ID・NUMBER・MESSAGE、コミット状態、再実行結果を残します。これにより、同じエラーが再発したときに、通信設定から調べ直す必要がなくなります。

RFCとBAPIは、呼び出しが成功したかどうかだけでなく、業務データが意図した状態になったかまで確認して完了とします。通信、入力、権限、更新確定を分離し、RETURNと要求IDを中心に追跡できる設計にすると、調査時間と二重登録のリスクを抑えられます。