SAP
SAP RFCとは？仕組み・接続方式・設定・障害対応を基礎から解説
SAP RFC（Remote Function Call）の基本概念、接続方式、通信の流れ、設定項目、権限、障害対応までを初心者向けに整理します。BAPIとの関係や確認ポイントも解説します。
SAPを周辺システムと連携させるとき、「RFC」という言葉を頻繁に目にします。しかし、RFCは単なる接続先やトランザクションコードの名称ではありません。SAPの関数モジュールを、同じシステムまたは別システムから呼び出すための通信方式です。
この記事では、SAP RFCの基本を、ABAP開発者だけでなく、運用担当者やインフラ担当者にも分かるように整理します。接続方式、通信の流れ、SM59で管理する宛先、ユーザーと権限、テスト方法、障害時の切り分けまでを順に確認します。
SAP RFCとは？
RFCはRemote Function Callの略称です。SAPシステム内にある関数モジュールを、別のプログラムや別のSAPシステムから呼び出すための仕組みを指します。呼び出し元と呼び出し先が同じシステムにある場合もあれば、ERPと別のSAP製品、SAPと外部アプリケーションの間で利用される場合もあります。
通常のローカル関数呼び出しでは、同じプログラム内の処理を直接実行します。一方、RFCでは呼び出し先との通信、パラメータの受け渡し、結果の返却が必要です。そのため、ネットワーク、宛先設定、認証、権限、タイムアウトなど、アプリケーション以外の要素も結果に影響します。
RFCで呼び出せる関数モジュールには、リモート呼び出しに対応する属性が設定されます。この属性がない関数モジュールは、一般的なRFCの呼び出し対象として扱えません。標準機能だけでなく、業務要件に応じて開発したカスタム関数モジュールをRFC対応にすることもできますが、公開するインターフェースの設計には注意が必要です。
RFCとBAPIの違い
BAPIは、SAPが業務オブジェクトを外部から扱うために提供する標準的なインターフェースです。多くのBAPIはRFC対応の関数モジュールとして実装されていますが、RFCとBAPIは同じ意味ではありません。
RFCは通信・呼び出しの技術です。BAPIは、受注、得意先、品目などの業務オブジェクトを操作するための標準APIという位置付けです。つまり、BAPIをRFC経由で呼び出すことはありますが、すべてのRFC対応関数モジュールがBAPIになるわけではありません。
この違いを理解しておくと、「RFC接続はできるのに業務処理が失敗する」という問題を整理しやすくなります。通信の成功は、業務データの登録成功を意味しません。BAPIによっては、処理後にコミットを明示的に実行する必要があります。
SAPの周辺モジュールや業務領域を先に整理したい場合は、関連するSAPモジュールの概要も参照してください。
RFCの通信方式
RFCには用途に応じた複数の通信方式があります。方式を選ぶときは、処理を同期的に待つ必要があるか、バックグラウンドで実行したいか、外部プログラムを起動する必要があるかを確認します。
同期RFC
同期RFCでは、呼び出し元が呼び出し先の処理完了と戻り値を待ちます。結果を受け取ってから次の処理に進みたい場合に適しています。たとえば、得意先情報を照会し、その結果を使って後続の登録処理を行うような連携です。
ただし、呼び出し先の処理時間が長い場合、呼び出し元も待機します。ネットワーク遅延やロック、ダンプが発生すると、処理全体が長時間停止する可能性があります。タイムアウト値だけを大きくするのではなく、処理を分割できないかも検討します。
非同期RFC
非同期RFCでは、呼び出し元は要求を送信した後、呼び出し先の完了を待たずに処理を続けます。大量データの送信や、即時の戻り値が不要な連携に向いています。
一方で、送信後の結果をその場で受け取れないため、エラー確認の方法を別途設計しなければなりません。送信ログ、再処理の仕組み、重複送信を防ぐ識別子などを準備しておくと、運用が安定します。
トランザクションRFC
トランザクションRFCは、要求を一度登録し、処理の再実行や重複防止を考慮して実行する方式です。通信が一時的に不安定な環境や、確実な一回処理が求められるシナリオで利用されます。
要求には、重複を識別するためのトランザクションIDが付与されます。送信側が同じ要求を再送しても、受信側が同じ処理を二重に実行しないように管理します。実際の設計では、処理済み状態や失敗状態の監視方法まで決めることが重要です。
キューRFC
キューRFCは、送信する処理をキューに積み、定められた順序で処理する方式です。処理順序が業務上重要な場合や、受信側の負荷を調整したい場合に利用されます。
キューが停止すると後続の要求も処理されないことがあるため、キューの状態監視が必要です。単に接続テストが成功していても、実際のキュー処理が止まっていれば連携は完了しません。
RFC接続の構成要素
RFC接続を理解するには、呼び出し元、呼び出し先、宛先、認証情報、ネットワーク経路を分けて考えると分かりやすくなります。
- 呼び出し元：RFCを実行するABAPプログラム、BAPI呼び出し、外部連携プログラムなど
- 呼び出し先：関数モジュールを実行し、結果を返すSAPシステムまたは外部RFCサーバー
- RFC宛先：接続先ホスト、システム番号、クライアント、ログオン情報などをまとめた定義
- 認証情報：接続時に使用するユーザー、パスワード、証明書、またはSSO関連情報
- ネットワーク経路：アプリケーションサーバー、メッセージサーバー、ゲートウェイ、ファイアウォールなど
呼び出し元のプログラムに接続先を直接書き込むのではなく、一般的にはRFC宛先を参照します。これにより、開発環境、テスト環境、本番環境で接続先を切り替えやすくなります。
SM59で管理するRFC宛先
SAP GUIでは、トランザクションコードSM59を使ってRFC宛先を確認・管理します。ここでは宛先の種類、接続先情報、ログオン設定、Unicode関連の設定、起動オプションなどを確認できます。
ただし、SM59で定義を登録しただけでは、必ずしも業務連携が実行できるとは限りません。接続テストは、ネットワークと基本的なログオンを確認するテストです。対象の関数モジュールを実行できるか、必要な業務権限があるか、データの整合性が保たれるかは別途確認が必要です。
RFC宛先には、代表的に次のようなタイプがあります。実際の名称や表示項目は、SAPのリリースや構成によって異なる場合があります。
- ABAP接続：別のABAPベースのSAPシステムへ接続するための宛先
- TCP/IP接続：外部プログラムやRFCサーバーとの通信に利用する宛先
- 論理接続：論理システム名を基にした連携で利用される定義
- HTTP系の接続：RFCとは別の通信方式ですが、連携設計で比較対象になることがあります
設定を変更する際は、誰が、いつ、何を変更したかを記録します。本番環境では、パスワード変更や接続先変更が複数の連携に影響する可能性があるため、変更管理と事前テストを省略しないことが大切です。
RFC通信の処理フロー
RFCの処理は、概ね次の順序で進みます。
- 呼び出し元プログラムが、RFC宛先と実行する関数モジュールを指定する
- SAP側またはRFCライブラリが、宛先情報を読み込む
- ネットワーク経路を通じて、接続先へログオン要求を送る
- 接続先がユーザー認証と接続元の確認を行う
- パラメータが送信され、対象の関数モジュールが実行される
- 結果、メッセージ、例外、更新状態などが呼び出し元へ返される
- 必要に応じてコミット、ロールバック、ログ記録を実行する
この流れのどこで失敗したかによって、確認すべき場所が変わります。ログオン前なら宛先やネットワーク、ログオン後の権限エラーならユーザー設定、関数実行時の失敗ならパラメータやアプリケーションログを優先します。
RFCユーザーと権限
RFC専用ユーザーを作成する場合は、通常の対話型ユーザーとは異なる運用方針を検討します。対話ログオンを不要にしたり、パスワードの管理方法を定めたりすることで、利用目的を明確にできます。
権限は、接続できることと、目的の処理を実行できることを分けて設計します。接続テストが成功しても、対象の関数モジュールに必要な権限、業務オブジェクトへの権限、対象クライアントへのアクセス権が不足していれば、実行時にエラーになります。
過剰な権限を持つ共通ユーザーを複数の連携で使い回すと、監査や原因調査が難しくなります。連携単位または用途単位でユーザーを分け、必要最小限の権限を付与し、定期的に利用状況を確認します。
パスワードをソースコードや設定ファイルに平文で保存する設計も避けます。接続先の保護、秘密情報の保管、通信の暗号化、証明書の有効期限管理を、システム運用の責任範囲に含めて考えます。
RFC接続テストの進め方
RFCに問題が起きたときは、いきなりABAPプログラムを修正するのではなく、層を分けてテストします。次の順番で確認すると、原因の範囲を狭めやすくなります。
- 宛先確認：接続先ホスト、システム番号、クライアント、ユーザーが正しいか確認する
- 接続テスト：SM59などで、基本的なネットワーク接続とログオンを確認する
- 権限確認：接続ユーザーが対象の処理に必要な権限を持つか確認する
- 関数テスト：入力値を最小限にして、対象関数モジュールを実行する
- 業務結果確認：戻り値、メッセージ、更新結果、コミット状態を確認する
- 監視確認：短時間の成功だけでなく、定期実行時のログと失敗時の再処理を確認する
本番環境でテストデータを使う場合は、登録や更新を伴わない照会処理から始めます。更新系の関数をテストするときは、対象データ、ロールバック方法、関係部署への通知を事前に決めます。
RFC障害の切り分け
RFCエラーのメッセージは、発生場所を推測する手掛かりになります。エラー文だけで判断せず、発生時刻、呼び出し元、宛先、ユーザー、関数名、入力データ、直前の変更を一緒に記録します。
接続できない場合
ホスト名やポート番号の誤り、名前解決の問題、ファイアウォール、SAProuter、ゲートウェイ、接続先サービスの停止を確認します。複数の呼び出し元で同時に失敗しているなら、共通するネットワークや接続先側の障害を優先します。
ログオンできない場合
ユーザーのロック、パスワード期限、クライアント番号、ログオン言語、認証方式を確認します。接続先をコピーして別環境で試す場合、環境ごとにユーザーや認証ポリシーが異なる点に注意します。
権限エラーになる場合
RFCを実行するユーザーと、画面操作を行うユーザーが異なることがあります。誰の権限で処理が実行されているかを確認し、対象の関数モジュールや業務オブジェクトに必要な権限を調査します。権限を広げる前に、失敗している操作を特定します。
処理は成功するが結果が違う場合
パラメータの形式、単位、日付、通貨、小数点、コード値、言語依存の値を確認します。また、更新系の処理ではコミットが実行されていない、または別トランザクションから参照しているため結果が見えない場合があります。
タイムアウトする場合
処理量、ロック待ち、接続先の負荷、ネットワーク遅延、タイムアウト設定を確認します。単純にタイムアウトを延長するのではなく、ページング、分割処理、非同期化、キュー化などで処理設計を見直します。
RFC運用で注意したいポイント
RFCは便利な反面、連携が増えるほど依存関係が複雑になります。次の項目を運用設計に含めると、障害時の復旧と変更の影響確認が容易になります。
- 接続先と利用目的を一覧化する
- RFCユーザー、所有部署、連絡先、パスワード更新方法を記録する
- 開発・テスト・本番の宛先を明確に分離する
- 接続先変更時の影響範囲と切り戻し方法を決める
- 同期処理にはタイムアウトと再試行方針を設定する
- 非同期処理には送信ログ、受信ログ、再処理手順を用意する
- 重複登録を防ぐための一意キーやトランザクションIDを設計する
- 個人情報や機密データを送信する場合は、通信経路と保管先を確認する
- 接続失敗だけでなく、業務結果の不整合も監視する
SAPのトランザクションコードを調べる機会が多い場合は、SAPトランザクションコード一覧を手元の確認資料として活用できます。
RFCと外部連携を設計する考え方
新しい連携をRFCで実装する前に、RFCが本当に適切かを検討します。既存の標準API、IDoc、OData、SOAP、ファイル連携、メッセージング基盤などが利用できる場合、要件や運用体制によっては別方式の方が保守しやすいことがあります。
選定では、リアルタイム性、処理量、再送要件、順序性、認証方式、監視のしやすさ、SAPのアップグレード影響を比較します。特定の内部関数モジュールに直接依存すると、将来の変更で影響を受ける可能性があります。可能な限り、標準的で安定したインターフェースを優先します。
また、「接続できれば完了」という設計にしないことが重要です。業務処理が成功したか、相手側でコミットされたか、送信データを再現できるか、失敗時に誰が何を確認するかまで定義します。
RFCを学ぶための実践ステップ
初心者は、いきなり複雑な外部連携を読むより、ローカル呼び出しとリモート呼び出しの違いを理解するところから始めます。次に、SM59の宛先、接続テスト、ユーザー権限、関数モジュールのインターフェースを順番に確認します。
学習用の環境では、照会系の標準関数や安全なテスト用関数を使い、入力パラメータと戻り値を記録します。その後、エラーを意図的に発生させ、宛先不備、認証失敗、権限不足、アプリケーションエラーの違いを比較します。
SAPの運用全体を体系的に学びたい場合は、SAPシステム管理の学習方法も参考になります。RFCだけでなく、ユーザー管理、ジョブ、ログ、移送、データベース監視を関連付けると、実際の障害対応力が高まります。
まとめ
SAP RFCは、SAP内外の機能を呼び出すための重要な通信基盤です。RFC、BAPI、RFC宛先、ユーザー権限、ネットワークを別々の要素として理解すると、接続設定や障害対応を整理しやすくなります。
特に重要なのは、接続テストの成功と業務処理の成功を分けて考えることです。宛先、認証、権限、パラメータ、コミット、監視、再処理までを一つの連携として設計すれば、運用時の切り分けと復旧がスムーズになります。