SAP×OData｜SAP GatewayとCDS Viewの役割を理解する

はじめに

前回の記事では、ODataプロトコルの基礎（エンティティ設計・Navigation Property・クエリオプション）を解説しました。本記事では視点をSAPシステムに移し、SAP の中で OData がどのように動いているかを解説します。

具体的には以下の3つを扱います。

1. SAP Gateway とは何か — OData サービスを公開するための基盤
2. フロントエンドサーバーとバックエンドサーバー — OData リクエストが処理される経路
3. CDS View から OData サービスが生成される仕組み — 「定義」と「公開」の関係

なぜこの知識が必要か（why so）：OData のプロトコル仕様を知っていても、SAP の中で「誰が OData リクエストを受け取り」「どこでデータを取得し」「何を経由してレスポンスを返すか」が分からないと、トラブルシューティングもサービス設計もできません。Fiori アプリの裏側で何が起きているかを理解するための必須知識です。Fiori と OData の関係についてはODataとFioriの連携も併せて参照してください。

SAP Gateway とは何か

一言で言うと

SAP Gateway は、SAP システムの OData サービスを外部に公開するためのミドルウェアです。外部クライアント（Fiori アプリ、モバイルアプリ、BIツールなど）からの HTTP リクエストを受け取り、SAP のビジネスデータにアクセスする入り口の役割を担います。

SAP Gateway が必要な理由

SAP のバックエンドシステム（S/4HANA、ECC）は、もともと RFC（Remote Function Call） という SAP 固有のプロトコルで通信する設計です。しかし、Web ブラウザやモバイルアプリは RFC を直接呼べません。

SAP Gateway はこの「プロトコルの壁」を取り払い、HTTP/HTTPS で OData プロトコルを話せる層を提供します。

flowchart LR
  subgraph "外部クライアント"
    C1["Fioriアプリ\n（ブラウザ）"]
    C2["モバイルアプリ"]
    C3["外部システム\n（BIツール等）"]
  end
  subgraph "SAP Gateway"
    GW["ODataリクエストを\n受信・解釈・ルーティング"]
  end
  subgraph "SAPバックエンド"
    BE["ビジネスデータ\n＋ロジック"]
  end
  C1 -->|"HTTP/OData"| GW
  C2 -->|"HTTP/OData"| GW
  C3 -->|"HTTP/OData"| GW
  GW -->|"内部呼び出し\n（RFC等）"| BE

SAP Gateway が担う具体的な処理

フロントエンドサーバーとバックエンドサーバー

2つのサーバー構成

SAP の OData 基盤は、フロントエンドサーバー（FES） と**バックエンドサーバー（BES）**という2つの役割で構成されます。

flowchart LR
  subgraph "フロントエンドサーバー（FES）"
    F1["SAP Gateway（SAP_GWFND）\nサービス登録・ルーティング"]
  end
  subgraph "バックエンドサーバー（BES）"
    B1["データプロバイダー\nクラス（DPC）"]
    B2["CDS View\n（データモデル）"]
    B3["ビジネスデータ\n（テーブル）"]
    B1 --> B3
    B2 --> B3
  end
  F1 -->|"RFC接続"| B1
  F1 -->|"RFC接続"| B2

組み込み型（Embedded）と分離型（Hub）

この FES と BES の配置パターンには2つの方式があります。

flowchart LR
  subgraph "組み込み型（Embedded）"
    E1["S/4HANA\nFES + BES\n（同一サーバー）"]
  end
  subgraph "分離型（Hub）"
    H1["Gateway Hub\n（FES専用）"]
    H2["ECC\n（BES）"]
    H3["S/4HANA\n（BES）"]
    H1 -->|"RFC"| H2
    H1 -->|"RFC"| H3
  end

なぜ分離型があるのか（why so）：大規模な企業では、ECC と S/4HANA が並行稼働していたり、複数のバックエンドシステムが存在したりします。分離型の Hub 構成にすると、1つの Gateway を入り口にして複数のバックエンドのODataサービスを統合的に公開できます。

読者への示唆（so what）：S/4HANA の新規導入であれば、基本は組み込み型でスタートし、複数システム統合の要件が出てきた段階で Hub 構成を検討するのが一般的です。Basis 担当者やインフラ設計に関わる場面で、この構成の違いを理解していることが重要です。SAP のシステム構成の基本についてはSAPのクライアントとは何かも参考にしてください。

OData リクエストの処理フロー

ユーザーが Fiori アプリで操作した時、裏側で何が起きているかを追ってみましょう。

GET リクエスト（データ読み取り）の場合

flowchart LR
  A["① Fioriアプリ\nGET /PurchaseOrderSet\n?$top=10"] --> B["② SAP Gateway\nURL解析\n認証チェック"]
  B --> C["③ サービス特定\nどのDPC/CDS Viewか"]
  C --> D["④ データ取得\nCDS View実行\nor DPCメソッド呼出"]
  D --> E["⑤ レスポンス変換\nABAP → JSON"]
  E --> F["⑥ Fioriアプリ\nJSONを受け取り\n画面表示"]

各ステップの詳細を整理します。

なぜ処理順序を理解すべきか（why so / so what）：この処理順序を理解しておくと、エラー発生時にFES側（ルーティング・認証）の問題かBES側（ビジネスロジック）の問題かを切り分けられます。たとえば、HTTP 401 や 403 が返る場合は②の認証段階の問題、HTTP 500 でバックエンドのダンプが出る場合は④のデータ取得段階の問題、というように原因箇所を素早く特定できます。

POST / PUT / DELETE（更新系）の場合

更新系のリクエストも基本フローは同じですが、以下の追加処理が入ります。

• CSRF トークン検証：更新リクエストの前に x-csrf-token: Fetch ヘッダーでトークンを取得し、リクエスト時に送信する（クロスサイトリクエストフォージェリ対策）
• ロック処理：SAP のエンキュー/デキュー（SAPのデータロック機構）による排他制御
• コミット/ロールバック：データ更新後の COMMIT WORK または ROLLBACK WORK

CDS View から OData サービスが生成される仕組み

2つの公開方式

CDS View から OData サービスを公開する方法は、大きく2つの世代があります。

@OData.publish 方式（V2）

最もシンプルな方法です。CDS View にアノテーションを1行追加するだけで、OData V2 サービスが自動生成されます。

@OData.publish: true  -- この1行でODataサービスが自動生成
define view Z_I_PurchaseOrder as select from ekko {
  key ebeln as PurchaseOrder,
      bukrs as CompanyCode
}

メリット：圧倒的にシンプル。読み取り専用のサービスであれば、これだけで十分

制約：

• 生成されるのは V2 サービスのみ
• 更新処理（Create / Update / Delete）を実装するには、生成された DPC クラスを手動で拡張する必要がある
• ビジネスロジック（バリデーション等）の組み込みが限定的

RAP 方式（V4）

S/4HANA Cloud 時代の標準的な開発モデルです。CDS View をベースに、以下の要素を組み合わせてサービスを構築します。

flowchart LR
  subgraph "RAP の構成要素"
    A["データモデル\n（CDS View）"] --> B["振る舞い定義\n（Behavior Definition）"]
    B --> C["ロジック実装\n（**Behavior Implementation**）"]
    A --> D["公開範囲\n（Service Definition）"]
    D --> E["プロトコル指定\n（**Service Binding**）"]
  end

CDS View のアノテーションや VDM 構造についてはCDS Viewとは何か？S/4HANAのデータモデリングを支える新しい基盤で解説しています。

なぜ RAP が必要なのか（why so）：@OData.publish 方式は読み取りには便利ですが、更新処理・バリデーション・権限チェックといった実務に必要なロジックを組み込むには不十分でした。RAP は「データモデル」と「振る舞い」を分離して定義することで、読み取りから更新まで一貫した開発モデルを提供します。RAP は SAP の Clean Core 戦略とも密接に関連しており、詳しくはSAP Clean Core戦略を参照してください。

読者への示唆（so what）：現時点では @OData.publish 方式のサービスが多く残っていますが、新規開発は RAP で行うのがSAPの推奨です。既存サービスの保守では @OData.publish の知識が必要、新規開発では RAP の知識が必要――両方を押さえる必要がある過渡期です。

SAP Gateway の主要なトランザクションコード

OData サービスの管理・監視に使う主要なTコードを整理します。トランザクションコードの基本についてはSAP主要トランザクションコード一覧も参照してください。

名前空間の補足：IWFND = Frontend Server（FES）側、IWBEP = Backend Server（BES）側のコンポーネント名前空間です。Tコードの接頭辞でどちら側の管理機能かを判別できます。

なぜこれらのTコードが重要か（why so）：OData サービスが「動かない」「エラーが出る」といった問題の多くは、サービスの有効化漏れやルーティング設定の不備が原因です。これらのTコードは問題の切り分けに不可欠です。テスト・デバッグの具体的な手法はODataサービスのテスト・デバッグ手法で詳しく解説しています。

よくある疑問

Q1. SAP Gateway は追加インストールが必要ですか？

S/4HANA では SAP Gateway が標準で組み込まれています（Embedded 構成）。ECC の場合は、SAP Gateway のアドオン（SAP_GWFND）を別途インストールするか、Hub 構成で別サーバーに配置する必要があります。

Q2. 1つのCDS Viewから複数のODataサービスを作れますか？

はい。RAP 方式では、1つの CDS View に対して複数の Service Definition / Service Bindingを作成できます。たとえば、同じデータモデルから「外部API向けの読み取り専用サービス」と「管理画面向けのCRUDサービス」を別々に公開することが可能です。

Q3. ECCでもODataサービスは使えますか？

はい。ECC に SAP Gateway コンポーネントをインストールすれば、SEGW（Service Builder）で OData サービスを構築できます。ただし、CDS View の機能が限定的なため、@OData.publish や RAP は使えず、SEGW でモデルとDPCを手動で構築する必要があります。SEGW と RAP それぞれでのサービス作成手順はODataサービスの作成手順を参照してください。

Q4. SAP BTP（Business Technology Platform）との関係は？

SAP BTP 上のアプリケーション（Fiori Elements、CAP など）は、S/4HANA の OData サービスをリモートで呼び出す形で連携します。この場合、S/4HANA 側の SAP Gateway がODataサービスのエンドポイントとなり、BTP 側がクライアントとして HTTP リクエストを送信します。BTP の Destination 設定で接続先の S/4HANA を登録し、認証方式（OAuth、Principal Propagation など）を構成します。

まとめ

• SAP Gatewayは、SAPシステムの OData サービスを HTTP で外部公開するミドルウェアであり、リクエスト解析・認証・ルーティング・レスポンス変換を担う
• SAP の OData 基盤はフロントエンドサーバー（FES）とバックエンドサーバー（BES）で構成され、S/4HANA では組み込み型（Embedded）がデフォルト
• OData リクエストは「URL解析 → サービス特定 → データ取得 → JSON変換 → レスポンス返却」の順で処理される
• CDS View から OData を公開する方法は @OData.publish（V2・シンプル） と RAP（V4・本格的） の2方式があり、新規開発は RAP が推奨
• Gateway の主要Tコード（/IWFND/MAINT_SERVICE、/IWFND/GW_CLIENT 等）はサービスの管理・トラブルシューティングに不可欠

次のステップとして、OData サービスのテスト・デバッグ手法（Gateway Client の使い方、エラーログの読み方、よくあるエラーパターン）をODataサービスのテスト・デバッグ手法で解説しています。

SAP GatewayやCDS Viewの裏側で動くABAPの仕組みをもっと深く理解したいなら、ABAP・OData・RAP・UI5 Fioriまで一気通貫で学べる講座が効率的です。全335レクチャーで基礎から実装まで手を動かしながら習得できます。