SAP RFC & BAPI
SAP RFCの種類を整理：同期・非同期・トランザクショナルRFCの使い分け
SAP RFCの同期RFC、非同期RFC、トランザクショナルRFC、キューRFC、bgRFCの違いを整理し、業務要件に応じた選択、監視、再実行、障害切り分けの実務手順を解説します。
SAP RFC（Remote Function Call）は、SAPシステム間または外部プログラムから、リモート対応した関数モジュールを呼び出す仕組みです。設計時は、呼び出し元が結果を待つか、処理を後で実行できるか、順序保証や再実行が必要かを先に決めます。通信方式を要件に合わせると、タイムアウト、重複登録、処理順序の乱れを抑えやすくなります。
BAPIは業務オブジェクトを扱うための標準化されたインターフェースで、多くの場合はRFC経由で呼び出します。RFCが通信方式を表すのに対して、BAPIは業務操作のインターフェースとして位置づけます。BAPIの役割は「SAP BAPIとは何か」で整理しています。
SAP RFCの通信方式を選ぶ基準
方式を選ぶときは、次の順序で要件を確認します。
- 呼び出し元が、その場で業務結果を必要とするか
- 受信側の処理が一時的に停止しても、送信データを保持するか
- 複数メッセージの処理順序を保証するか
- 失敗した処理を自動または運用操作で再実行するか
- 同じ要求が複数回届いた場合に、重複登録を防げるか
画面操作の完了判定や入力チェックの結果が必要なら同期RFCが基本です。大量連携や夜間連携では、送信側と受信側の稼働時間を分離できる非同期系の方式が適しています。順序制御や再送管理が要件に含まれる場合は、トランザクショナルRFC、qRFC、bgRFCを候補にします。
リモートファンクションコールの基本では、RFCの呼び出し元、受信側、接続先定義の関係を確認できます。
同期RFCの動作と運用ポイント
同期RFCでは、呼び出し元が関数モジュールの処理結果を受け取るまで、呼び出し処理が継続します。戻り値、例外、業務メッセージをその場で評価できるため、在庫照会、得意先情報の取得、登録前の妥当性確認など、即時応答が必要な処理に向いています。
同期RFCの設計では、受信側の処理時間と通信タイムアウトを合わせます。処理が長時間になる場合は、呼び出し元のワークプロセスや外部プログラムが待機し続けるため、ピーク時間の同時実行数も確認します。データ更新を伴う場合は、コミットの責任範囲を明確にし、呼び出し元と受信側で二重にコミットを管理しないようにします。
障害時は、まず次の情報を同じ時刻範囲でそろえます。
- 呼び出し元の業務ログとRFC例外
- 受信側のアプリケーションログ
- 接続先の疎通結果と認証状態
- 入出力パラメータの業務キー
- データベース更新の有無
同期RFCの再実行では、元の要求が受信側で完了してから応答だけが失われたケースに注意します。業務キーで登録済みデータを確認し、再送前に重複登録を防ぐ判定を行います。
非同期RFCの処理モデル
非同期RFCでは、呼び出し側は受信側の業務処理完了を待たずに次の処理へ進みます。送信側の処理を短時間で終えられる一方、受信側の結果は後から確認する運用になります。大量データの連携、日次処理、送信側と受信側の稼働時間が一致しない連携で利用しやすい方式です。
設計時には、送信成功と業務処理成功を別の状態として管理します。送信要求が受け付けられたことは、受信側で業務更新が完了したことを意味しません。連携ID、業務キー、送信日時、処理状態、エラー内容を記録すると、後続の監視と再実行が安定します。
非同期処理の運用では、次の監視項目を用意します。
- 未処理件数と処理待ち時間
- エラー件数と最古のエラー時刻
- 同一業務キーの重複要求
- 受信側の処理時間の増加
- 送信側と受信側の時刻差
応答を待たない方式でも、エラー処理は省略できません。エラーを業務担当者へ通知するのか、技術担当者が再処理するのか、また再処理前にデータを修正するのかを決めておきます。
トランザクショナルRFCの役割
トランザクショナルRFC（tRFC）は、RFC要求をトランザクション単位で登録し、受信側での実行を後から行う方式です。送信側の処理と受信側の実行を分離し、通信障害や受信側の一時停止が発生した場合も要求を保持して処理を継続できます。
tRFCは、業務処理を一度だけ実行するための運用設計と組み合わせて使います。システム障害後の再送、受信側の一時停止、夜間の遅延処理に対応しやすい一方、業務側で重複防止を考慮した設計が必要です。処理の成功後に応答が失われる状況を想定し、業務キーや連携IDを使って再実行の可否を判定します。
実行待ちやエラーの確認では、送信元、受信先、作成日時、状態、エラー内容を記録します。運用担当者が再処理する場合は、対象を限定し、元データの修正履歴と再処理結果を残します。通信方式の選択だけでなく、監視画面、担当者、再処理手順まで含めて設計することが重要です。
qRFCとbgRFCの使い分け
qRFCは、キューを使ってRFC要求の実行順序を制御する方式です。同じキューに属する要求を順番に処理したい場合に適しています。得意先、製品、拠点などの単位で更新順序を守る必要がある連携では、キューの単位と並列度を業務要件に合わせます。
キューの停止が長引くと、後続要求も処理待ちになります。そのため、キューの詰まりを検知する監視、停止理由の記録、再開権限、滞留時の業務影響をあらかじめ定義します。順序保証の範囲を広くしすぎると並列処理の効果が下がるため、順序が必要な業務単位だけをキューに割り当てます。
bgRFCは、バックグラウンドでRFC処理を実行するための仕組みです。処理の非同期化と運用管理を重視する連携で候補になります。ユニット単位またはキュー単位での設計、実行優先度、エラー時の再処理、監視担当を決めてから採用します。
qRFCとbgRFCの選択では、次の観点を比較します。
| 観点 | qRFC | bgRFC |
|---|---|---|
| 主な目的 | キューによる順序制御 | バックグラウンド実行の管理 |
| 設計の中心 | キュー名と順序単位 | ユニットまたはキューの実行設計 |
| 注意点 | 先行要求の滞留が後続へ影響 | 実行状態と再処理の管理 |
| 適した要件 | 順序が業務結果に直結する連携 | 非同期実行と運用制御を重視する連携 |
RFC方式を実装前に決める項目
設計書には、RFC方式だけでなく業務上の完了条件を記載します。最低限、次の項目を連携単位ごとに定義します。
- 呼び出し元と受信側のシステム
- 使用する関数モジュールまたはBAPI
- 同期応答が必要な項目
- 登録、変更、取消の業務キー
- コミットとロールバックの責任範囲
- 処理順序を保証する単位
- 再送条件と再処理の実施者
- タイムアウト、最大リトライ回数、通知先
- 監査ログに残す項目
BAPIを使う場合は、業務オブジェクトの状態遷移と戻りメッセージを確認します。単にRFC接続が成功しただけで業務処理が成功したと判定せず、BAPIの戻り情報と更新結果を確認します。BAPI名や関連するBusiness Object Repositoryの調べ方は、BAPIの命名とBORを確認する方法にまとめています。
RFC障害を切り分ける実務手順
障害の切り分けは、通信、認証、呼び出し、業務データ、非同期キューの順に範囲を狭めます。
1. 通信経路を確認する
呼び出し元から接続先までのネットワーク経路、ホスト名、ポート、ファイアウォール、名前解決を確認します。接続先定義の変更時刻と障害発生時刻を照合し、同じ接続先を使う他の連携にも影響があるかを確認します。
2. 認証と権限を確認する
接続に使うユーザーの有効期間、ロック状態、パスワード、必要なRFC実行権限を確認します。認証成功後に関数実行で失敗する場合は、呼び出す関数や業務オブジェクトに必要な権限を確認します。
3. 関数とパラメータを確認する
関数モジュール名、インポート値、テーブルパラメータ、文字コード、日付形式、単位、業務キーを確認します。同期RFCでは例外と戻り値、非同期系では登録された要求の状態をそれぞれ確認します。
4. 業務更新を確認する
受信側で更新が完了したか、コミットが実行されたか、業務伝票やマスタの状態が期待どおりかを確認します。処理完了後に通信が切れたケースでは、業務キーで既存データを確認してから再送します。
5. キューと再処理を確認する
qRFCやbgRFCを使う場合は、キューまたは実行単位の停止、先行要求のエラー、滞留時間、再処理履歴を確認します。再処理の前に、受信側で部分的な更新が残っていないかを確認します。
代表的なエラーの見方は、SAP RFC・BAPIのよくあるエラーパターンで確認できます。エラー文だけで方式を変更せず、方式、業務状態、再実行の結果を一つの記録にまとめます。
運用に引き継ぐ監視と再実行
本番運用では、RFC連携を「送信」「受付」「実行」「業務完了」の状態に分けて監視します。同期RFCは応答時間と例外件数、tRFCは未処理・エラー・再送件数、qRFCはキューの停止と滞留、bgRFCは実行待ちと失敗を中心に監視します。
再実行手順には、対象の特定方法、事前確認、実行権限、実行後の確認、担当者への通知を含めます。再実行可能な業務と、業務担当者の承認が必要な業務を分けると、障害対応を安全に標準化できます。
連携を変更する際は、方式だけでなくタイムアウト、並列度、キュー単位、ログ保持期間、通知条件も見直します。変更後は、正常系、受信側停止、通信切断、重複送信、再実行のシナリオを検証し、運用手順に結果を反映します。
まとめ
SAP RFCの使い分けは、応答の必要性、処理の分離、順序保証、再実行、重複防止の五つの観点で決めます。即時結果が必要なら同期RFC、受信側との時間を分離するなら非同期RFC、要求の保持と後続実行を管理するならtRFC、順序制御が必要ならqRFC、バックグラウンド実行と運用管理を重視するならbgRFCが候補です。
実装時は、RFC接続の成功を業務処理の成功と同一視せず、業務キー、処理状態、エラー、再実行結果を追跡できる形にします。方式選定と同時に監視・再処理・責任分界を決めることで、連携障害への対応時間を短縮できます。