SAP Basis観点でSAP ERPと外部APIの通信トラブル発生時の調査方法　ITコンサルタント馮 壮

SAP Basis観点でSAP ERPと外部APIの通信トラブル発生時の調査方法（OSレイヤ含む）について少しお話したいと思います。

SAP ERPと外部APIの通信トラブルを調査する際は、OSレイヤ・ネットワーク・SAPレイヤ・アプリケーションログ の順に問題を特定することが重要です。

1. まずは「どこで問題が発生しているか」切り分ける

通信トラブルは クライアント側（外部API）・ネットワーク・サーバー側（SAP ERP） のどこで問題が発生しているかを特定するのが重要です。

チェック項目/調査ポイント

・通信自体が失敗しているか? 
　ping, telnet, traceroute, netstatなどのコマンドを使用してポートなどが開いているかを確認
　AWS環境ならもし、通信ができない場合、セキュリティーポリシーの設定が正しいかを確認

・SAPがリクエストを受信しているか? 
　SAPの ICMログ（SMICM）, SAP Gatewayログ（SMGW）を確認

・アプリケーションエラーが発生しているか?    
　SAPトランザクションログ（SM21, ST22, SLG1）を確認

・APIレスポンスが異常か?    
　APIレスポンスのHTTPステータスコードを確認

 2. OSレイヤの調査（Linux/Windows）

通信の問題がある場合、まずはOSレベルでの接続確認を行います。

■ネットワーク接続の確認

1) ping で通信可能か確認（ICMP）
　ping <SAPサーバーのIPアドレス>
    　•応答がない場合 → ネットワーク障害、ファイアウォール制限の可能性あり
   　 •応答があるが接続できない場合 → ポート制限の可能性あり

2) telnet で特定のポートに接続できるか確認
　telnet <SAPサーバーのIPアドレス> <ポート番号>
　例）SAP Gatewayの8443ポートに接続できるか確認
　telnet 192.168.1.100 8443
    　•成功（画面が黒くなる） → ネットワーク的には問題なし
    　•失敗（接続エラー） → ポート制限 or SAPサービスが起動していない

telnetが実装していない場合、powershellのコマンドtest-netconnectionを使用して、確認可能
例）SAP Gatewayの8443ポートに接続できるか確認
test-netconnection 192.168.1.100 -port 8443

3) traceroute で通信経路を確認
　traceroute <SAPサーバーのIPアドレス>  # Linux
　tracert <SAPサーバーのIPアドレス>    # Windows
    　•途中で途切れている場合 → その地点のルーターやファイアウォールで通信がブロックされている可能性あり

■ファイアウォール・ポートの確認

1) OSのファイアウォール設定確認（Linux）
　例）sudo iptables -L -n
　例）sudo firewall-cmd --list-all   # RHEL/CentOSの場合
  　  •必要なポート（443, 8443, 33xx など）が開放されているか確認
   　 •もしブロックされていたら、ポートを開放

　例）sudo iptables -A INPUT -p tcp --dport 8443 -j ACCEPT
　例）sudo systemctl restart firewalld

2) Windowsのファイアウォール設定確認
　Get-NetFirewallRule -DisplayGroup "SAP"
   　 •必要なポートが開放されているか確認
   　 •ポート開放
　　例）New-NetFirewallRule -DisplayName "Allow SAP" -Direction Inbound -Protocol TCP -LocalPort 8443 -Action Allow

3) netstat でポートの使用状況を確認
　netstat -tulnp  # Linux
　netstat -ano    # Windows
   　 •SAPのサービス（ICM, Gateway）がリスニング状態になっているか確認

■DNS・名前解決の確認
SAPシステムにホスト名で接続する場合、DNSが正しく設定されているか確認
nslookup <SAPサーバーのホスト名>
host <SAPサーバーのホスト名>  # Linux
    •解決できない場合 → /etc/hosts に直接記述するか、DNS設定を修正
    •もし、AD環境の場合、ドメイン参加しているか

　例）echo "192.168.1.100 sapserver" | sudo tee -a /etc/hosts

3. SAPレイヤの調査

OS・ネットワークレベルで問題がなければ、SAP側のログを確認する。

■SAP ICMログ（SAP Webサービス, OData）
ICM（Internet Communication Manager）が正しく動作しているか確認する
SAP GUI で SMICM を実行 → ログ（Shift+F6） を開く
    •HTTP error 500 → SAPアプリケーション側のエラー（ST22をチェック）
    •Connection refused → SAP ICMがリスニングしていない → icm/server_port_0 の設定を確認する
※HTTPSの通信を利用する場合、下記のパラメータのコンフィグ設定が必要
例）icm/server_port_1= PROT=HTTPS,PORT=443$$,TIMEOUT=90,PROCTIMEOUT=1800

■SAP Gatewayログ（RFC通信エラー）
RFC通信が失敗する場合、SMGW でログを確認する
SAP GUIで SMGW → トレース（Shift+F5） を開く

■SAPのシステムログ
SAP GUIで SM21 を実行
    •Connection error → ネットワーク問題
    •RFC_NO_AUTHORITY → 認証エラー（ユーザー権限を確認）

■ABAPダンプログ
SAP GUIで ST22 を実行し、エラーダンプを確認
    •TIME_OUT → 通信の応答が遅すぎる（タイムアウト設定を増やす）
    •SYSTEM_FAILURE → SAPの処理エラー（プログラム側を修正）

4. APIのレスポンス確認

外部APIの通信が成功しているが、期待通りのレスポンスが返ってこない場合は、HTTPステータスコードを確認する。
例）curl -v -k -X GET "https://sapserver:8443/sap/opu/odata/SAP/ZAPI_SRV/"

HTTPステータス説明
200 OK    正常
401 Unauthorized 認証エラー（OAuth, Basic認証の確認）
403 Forbidden ユーザー権限エラー
404 Not Found APIのURLが間違っている
500 Internal Server Error SAP側のエラー（ST22で詳細を確認）

 トラブルシューティング手順まとめ

1: OSレイヤ（Linux/Windows）
　ping, telnet, traceroute でネットワーク確認
　netstat, iptables, firewall-cmd でポート確認
2: SAPレイヤ（ICM, Gateway）
　SMICM, SMGW, SM21, ST22 でログ確認
3: APIレスポンス確認
　curl, Postman でステータスコード確認

この手順に沿って調査すれば、SAP ERPと外部APIの通信トラブルを効率的に特定できます。
しかし、プロジェクトごとにシステム構成が異なる為、（例えば外部APIとSAP ERPシステムの間にDispatcherが存在する場合）DispatcherでのHttpsなどの許可と設定確認も必要です。

以前私が経験したプロジェクトで、外部APIとSAP ERP間の通信エラーが発生したことがありました。
その際ERP側に原因があると考え、SAP Basisに調査を依頼しましたが、結果、外部APIの設定が足りないことが原因でした。
ERPのみならず、外部APIの設定も確認することが肝要です。