ODataサービスのテスト・デバッグ｜Gateway Client・エラーログ・よくあるエラーパターン

はじめに

OData サービスを構築したら、次に必要なのは「正しく動くこと」を確認するテストと、「動かない時」に原因を特定するデバッグです。OData のトラブルは、プロトコルの仕様・SAP Gateway の設定・バックエンドのロジック――複数の層にまたがって発生するため、体系的な切り分け手法を知っておくことが重要です。

ODataの基本概念についてはODataとは何か？SAPにおける役割と基本概念を解説を参照してください。本記事では以下の3つを扱います。

1. Gateway Client（/IWFND/GW_CLIENT） — SAP 内蔵の OData テストツール 2. エラーログと主要な確認ポイント — 問題の切り分け手法 3. よくあるエラーパターンと対処法 — 実務で遭遇する頻出エラー

なぜテスト・デバッグスキルが重要か（why so）：OData サービスの問題は「画面が動かない」としてFiori側から報告されますが、原因はFioriアプリ・Gateway・バックエンドのどの層にもあり得ます。Fiori の開発者が Gateway の設定を確認できない、Basis 担当者が DPC（Data Provider Class：ODataサービスのバックエンドロジックを実装するABAPクラス）のロジックを追えない――こうした「層をまたぐ問題」を効率的に切り分けるために、全体像を理解しておく必要があります。OData サービスの構築方法についてはODataサービスの作り方｜SEGW方式とCDS View＋RAP方式を比較するで解説しています。

Gateway Client（/IWFND/GW_CLIENT）

Gateway Client とは

Gateway Client は、SAP 内蔵の OData テストツールです。ブラウザや Postman のようにHTTPリクエストを送信し、レスポンスを確認できます。SAP にログインした状態で使えるため、認証設定を別途行う必要がなく、最も手軽なテスト手段です。Gateway の全体像についてはSAP Gateway の仕組みと役割を解説を参照してください。

Tコード：/IWFND/GW_CLIENT

基本的な使い方

flowchart LR
  A["① **リクエストURI**入力"] --> B["② HTTPメソッド選択"]
  B --> C["③ 実行・レスポンス確認"]
  C --> D["④ 結果分析"]

• ① リクエストURI入力：/sap/opu/odata/sap/サービス名/エンティティセット の形式でURIを入力
• ② HTTPメソッド選択：GET / POST / PUT / DELETE から選択
• ③ 実行・レスポンス確認：HTTPステータスコードとJSON/XMLのレスポンスボディを確認
• ④ 結果分析：データ内容が期待通りか確認。エラー時はメッセージの詳細を確認

よく使うリクエストパターン

テストは「サービスルート → メタデータ → 一覧取得 → 個別取得 → フィルタ/展開」の順に進めるのが効率的です。上流で問題があると下流のテストが全て失敗するため、この順序で段階的に確認することで原因の特定が容易になります。

テスト時のチェックポイント

テストで確認すべき項目を優先度順に整理します。この優先度は「上位の項目が正常でないと、下位の項目を確認しても意味がない」という依存関係に基づいています。たとえばHTTPステータスが500の状態でデータ件数やパフォーマンスを確認しても無意味です。

POST リクエスト（データ作成）のテスト

GET 以外のリクエストをテストする場合は、CSRF トークンの取得が必須です。

flowchart LR
  A["① GET/HEADリクエスト送信\nx-csrf-token: Fetch"] --> B["② CSRFトークン取得"]
  B --> C["③ POSTリクエスト送信\nCSRFトークン設定"]

Gateway Client では「HTTPヘッダー追加」ボタンからヘッダーを設定できます。POST のボディ（JSON）は「リクエストボディ」入力欄に記述します。

エラーログと主要な確認ポイント

エラー調査の全体フロー

OData のエラーが発生した場合、「どの層で問題が起きているか」を最初に切り分けるのが鉄則です。

flowchart LR
  A["エラー発生"] --> B{"HTTPステータスは？"}
  B -->|"404"| C["サービス未登録 / URL誤り"]
  B -->|"403"| D["権限不足"]
  B -->|"400"| E["リクエスト不正"]
  B -->|"500"| F{"エラーログを確認"}
  F -->|"Gateway層"| G["**/IWFND/ERROR_LOG**"]
  F -->|"バックエンド層"| H["**ST22** / DPCデバッグ"]

• 404：**/IWFND/MAINT_SERVICE** でサービス登録状態を確認
• 403：**SU53** / PFCG で権限設定を確認
• 400：URLやJSONの構文を見直す
• 500（Gateway層）：/IWFND/ERROR_LOG でエラーメッセージを確認
• 500（バックエンド層）：ST22 でダンプ確認、またはDPCクラスをデバッグ

主要な確認ツール一覧

以下がODataのテスト・デバッグで使用する主要なTコードです。Tコードの基本についてはSAP Tコードとは？主要トランザクションコード一覧を参照してください。

/IWFND/ERROR_LOG の読み方

/IWFND/ERROR_LOG は OData のトラブルシューティングで最初に確認すべきツールです。

読者への示唆（so what）：エラーログの「エラーメッセージ」と「スタックトレース」を組み合わせて読むことで、「何が原因か（メッセージ）」と「どこで発生したか（スタック）」の両方が分かります。この2つを特定してから対処に入ることで、試行錯誤の時間を大幅に削減できます。

ABAP デバッガーでの DPC デバッグ

エラーログだけでは「どのメソッドで失敗したか」は分かっても「なぜ失敗したか」までは分からないケースがあります。たとえば条件分岐の結果やループ中の変数値など、実行時の状態を確認するにはデバッガーでの追跡が必要です。SEGW 方式のサービスでバックエンドのロジックをデバッグする場合、DPC_EXT のメソッドにブレークポイントを設定します。

RAP 方式の場合は、Behavior Implementation クラスの該当メソッドにブレークポイントを設定します。

よくあるエラーパターンと対処法

パターン①：404 Not Found — サービスが見つからない

症状：OData リクエストに対して HTTP 404 が返る

原因と対処：

パターン②：403 Forbidden — 権限不足

症状：HTTP 403 が返る、または「権限がありません」のメッセージ

原因と対処：

パターン③：500 Internal Server Error — サーバー内部エラー

症状：HTTP 500 が返る

これは最も原因の幅が広いエラーです。以下の順序で切り分けます。

パターン④：200 OK だがデータが0件

症状：HTTP 200 が返るがレスポンスのデータが空

パターン⑤：CSRF トークンエラー

症状：POST / PUT / DELETE で「CSRF token validation failed」

対処：更新系リクエストの前に、GETまたはHEAD リクエストで x-csrf-token: Fetch ヘッダーを送信してトークンを取得し、更新リクエストのヘッダーにそのトークンを含める必要があります。Fiori アプリではフレームワークが自動処理するため通常は発生しませんが、外部システムからの呼び出しやテストツールで頻出します。

パターン⑥：$expand が動作しない

症状：$expand=ToItems を指定してもナビゲーション先のデータが返らない

テスト効率を上げるTips

Tip 1：$metadata を最初に確認する

新しいサービスをテストする際は、最初に $metadata を確認するのが鉄則です。エンティティタイプの構造、プロパティ名、Navigation Property の名前が正しいかを確認してからデータ取得のテストに進むことで、「名前が違った」という初歩的なミスを避けられます。

Tip 2：$top=1 で軽くテストする

エンティティセットの全件取得は時間がかかる場合があります。最初は $top=1 をつけて1件だけ取得し、構造とデータの妥当性を確認します。

Tip 3：Gateway Client のリクエスト履歴を活用する

Gateway Client は過去のリクエスト履歴を保持しています。「前回」ボタンで直前のリクエストを呼び出せるため、URL を再入力する手間が省けます。

Tip 4：外部ツール（Postman 等）との使い分け

まとめ

• Gateway Client（/IWFND/GW_CLIENT）は SAP 内蔵の OData テストツールであり、認証設定不要で最も手軽なテスト手段
• エラー調査は「HTTP ステータスコードでの層の切り分け」から始める（404=サービス設定、403=権限、500=バックエンドロジック）
• /IWFND/ERROR_LOG は OData トラブルシューティングで最初に確認すべきツール。エラーメッセージ＋スタックトレースで原因と発生箇所を特定
• 頻出エラーパターン（404、403、500、0件、CSRF、$expand）の切り分け手順を覚えておくと、調査時間を大幅に短縮できる
• テストの基本は「$metadata で構造確認 → $top=1 で軽くテスト → 本格テスト」の順序

次回の記事 Fiori アプリと OData の関係｜Fiori が OData をどう使うか では、Fiori が OData をどう使うか、Fiori Elements の仕組みを解説します。

ODataのテスト・デバッグ力をさらに高めるには、Gateway Clientの操作だけでなくABAP側のロジックまで理解することが不可欠です。ABAP・OData・RAP・UI5 Fioriまで一貫して学べる実践講座で、トラブルの原因を自力で追える実践力が身につきます。