ODataサービスの作り方｜SEGW方式とCDS View＋RAP方式を比較する

はじめに

前回の記事では、SAP Gateway の役割とODataリクエストの処理フロー、CDS ViewからODataサービスが生成される2つの方式を紹介しました。本記事では、そのサービス構築の具体的な手順にフォーカスし、SEGW方式とCDS View + RAP方式を比較しながら解説します。

本記事で扱う内容は以下の3つです。

1. SEGW方式（Service Builder）— 従来型の手動構築アプローチ
2. CDS View + RAP方式 — S/4HANA Cloud 時代の宣言的アプローチ
3. 2つの方式の使い分け — どちらを選ぶべきかの判断基準

なぜ両方の方式を知る必要があるのか（why so）：S/4HANA の新規開発では RAP が推奨されていますが、既存システムには SEGW で構築された OData サービスが大量に存在します。保守・拡張では SEGW の理解が必須であり、新規開発では RAP の知識が求められる――つまり現場では両方を扱えることが実務能力として求められます。

SEGW方式（Service Builder）

概要

SEGW（SAP Gateway Service Builder）は、OData サービスをGUIベースで構築するツールです。TコードSEGWで起動し、エンティティタイプの定義からサービスの登録までを画面上で操作します。

SEGW方式の構築ステップ

flowchart LR
  A["① プロジェクト作成\nTコード SEGW"] --> B["② データモデル定義\nエンティティ構造を設計"]
  B --> C["③ サービス実装\nMPC / DPC クラス"]
  C --> D["④ サービス登録\n/IWFND/MAINT_SERVICE"]
  D --> E["⑤ テスト\n/IWFND/GW_CLIENT"]

• ②データモデル定義では、エンティティタイプ・エンティティセット・Navigation Property を定義します
• ③サービス実装では、MPC（モデル定義）と DPC（データ取得ロジック）が自動生成され、拡張クラスで手動カスタマイズします

各ステップの詳細

ステップ①：プロジェクト作成

TコードSEGWを実行し、新規プロジェクトを作成します。

ステップ②：データモデル定義

SEGWのモデル定義画面で、エンティティタイプとその関連を定義します。

エンティティタイプの定義方法には3つのアプローチがあります。

エンティティの設計粒度はテーブルに揃えるのが基本です。この考え方についてはODataとは何か？SAPの外部連携を支えるAPIプロトコルの基礎で解説しています。

ステップ③：サービス実装（MPC と DPC）

SEGWでモデルを定義すると、以下の4つのABAPクラスが自動生成されます。

flowchart LR
  subgraph "自動生成（再生成で上書き）"
    MPC["MPC\nモデル定義"]
    DPC["DPC\nCRUDメソッド雛形"]
  end
  subgraph "手動拡張（安全に編集可能）"
    MPC_EXT["MPC_EXT\nモデル拡張"]
    DPC_EXT["DPC_EXT\nデータ取得/更新\nロジック実装"]
  end
  MPC -->|"継承"| MPC_EXT
  DPC -->|"継承"| DPC_EXT

重要：ロジックの実装は必ず DPC_EXT（拡張クラス）に行います。DPC 本体に書くと、SEGW でモデルを再生成した際にコードが上書きされて消えます。

DPC_EXT で実装する代表的なメソッドは以下の通りです。

ステップ④：サービス登録

SEGWでサービスを生成した後、/IWFND/MAINT_SERVICE（フロントエンドサーバー）でサービスを有効化します。この手順を忘れると、ODataサービスにアクセスしても404エラーになります。

ステップ⑤：テスト

/IWFND/GW_CLIENT でODataリクエストを実行し、正しいレスポンスが返るか確認します。テスト・デバッグの詳細はODataサービスのテスト・デバッグで解説しています。

SEGW方式のメリット・デメリット

CDS View + RAP 方式

概要

RAP（RESTful ABAP Programming Model）は、S/4HANA（特にS/4HANA Cloud）におけるODataサービス開発の標準モデルです。CDS Viewでデータモデルを定義し、Behavior Definition で振る舞いを宣言、Service Definition / Binding でサービスを公開します。

CDS Viewの基礎（アノテーション、アソシエーション、VDMレイヤー）についてはCDS Viewとは何か？S/4HANAのデータモデリングを支える新しい基盤、VDMとRAPの棲み分けやProjection Viewの位置づけはABAP CDSの全体像 — VDMとRAPの違い・棲み分けを理解するで解説しています。

RAP方式の構築ステップ

flowchart LR
  A["① CDS View定義\nエンティティ構造"] --> B["② Behavior Definition\nCRUD許可/バリデーション"]
  B --> C["③ Behavior Implementation\nABAPロジック"]
  C --> D["④ Service Definition\n公開対象を選択"]
  D --> E["⑤ Service Binding\nV2/V4指定・有効化"]

• ①CDS View定義では、エンティティ構造に加えアソシエーション（関連付け）も定義します

各ステップの詳細

ステップ①：CDS View 定義

Eclipse（ABAP Development Tools = ADT）上で CDS View を作成します。ヘッダ-明細構造の場合、2つの CDS View を定義し、アソシエーションで関連付けます。

-- ヘッダ
define root view entity Z_I_PurchaseOrderHeader
  as select from ekko
  composition [1..*] of Z_I_PurchaseOrderItem as _Item
{
  key ebeln as PurchaseOrder,
      bukrs as CompanyCode,
      lifnr as Supplier,
      erdat as CreatedAt,
      _Item
}

-- 明細
define view entity Z_I_PurchaseOrderItem
  as select from ekpo
  association to parent Z_I_PurchaseOrderHeader as _Header
    on $projection.PurchaseOrder = _Header.PurchaseOrder
{
  key ebeln as PurchaseOrder,
  key ebelp as PurchaseOrderItem,
      matnr as Material,
      menge as Quantity,
      netpr as NetPrice,
      _Header
}

注目ポイント：RAP では composition（コンポジション）と association to parent を使って親子関係を定義します。これは単なる参照ではなく、「ヘッダと明細はライフサイクルを共にする（ヘッダ削除時に明細も削除される）」という意味を持ちます。

ステップ②：Behavior Definition

CDS View に対して、どのCRUD操作を許可するかを宣言的に定義します。

**managed** implementation in class zbp_i_purchaseorderheader unique;
strict;  // strictはより厳密な構文チェックを有効にするオプションです

define behavior for Z_I_PurchaseOrderHeader
persistent table ekko
lock master
authorization master
{
  create;
  update;
  delete;

  association _Item { create; }

  validation validateCompanyCode on save
    { field CompanyCode; }
}

define behavior for Z_I_PurchaseOrderItem
persistent table ekpo
lock dependent by _Header
authorization dependent by _Header
{
  update;
  delete;

  field ( readonly ) PurchaseOrder;
}

なぜ Behavior Definition が画期的か（why so）：SEGW方式では CRUD 操作のロジックを DPC_EXT に全て手動で書く必要がありました。RAP の managed シナリオでは、DB への INSERT / UPDATE / DELETE をフレームワークが自動的に実行してくれます。開発者はバリデーションやアクションなどのビジネスロジックだけを書けばよいのです。

ステップ③：Behavior Implementation

Behavior Definition で宣言したバリデーションやアクションの ABAP ロジックを実装します。

CLASS lhc_purchaseorderheader DEFINITION INHERITING FROM cl_abap_behavior_handler.
  PRIVATE SECTION.
    METHODS validateCompanyCode FOR VALIDATE ON SAVE
      IMPORTING keys FOR Z_I_PurchaseOrderHeader~validateCompanyCode.
ENDCLASS.

CLASS lhc_purchaseorderheader IMPLEMENTATION.
  METHOD validateCompanyCode.
    READ ENTITIES OF Z_I_PurchaseOrderHeader IN LOCAL MODE
      ENTITY Z_I_PurchaseOrderHeader
        FIELDS ( CompanyCode ) WITH CORRESPONDING #( keys )
      RESULT DATA(orders).

    LOOP AT orders INTO DATA(order).
      " 会社コードの存在チェック
      SELECT SINGLE FROM t001
        FIELDS bukrs
        WHERE bukrs = @order-CompanyCode
        INTO @DATA(lv_bukrs).

      IF sy-subrc <> 0.
        APPEND VALUE #(
          %tky = order-%tky
          %msg = new_message_with_text( text = '無効な会社コードです' severity = if_abap_behv_message=>severity-error )
        ) TO reported-z_i_purchaseorderheader.

        APPEND VALUE #( %tky = order-%tky ) TO failed-z_i_purchaseorderheader.
      ENDIF.
    ENDLOOP.
  ENDMETHOD.
ENDCLASS.

ステップ④：Service Definition

どの CDS View をサービスとして公開するかを定義します。

define service Z_SD_PurchaseOrder {
  expose Z_I_PurchaseOrderHeader as PurchaseOrderHeader;
  expose Z_I_PurchaseOrderItem as PurchaseOrderItem;
}

ステップ⑤：Service Binding

Service Definition に対して、OData のバージョン（V2 / V4）を指定し、サービスを有効化します。この操作は Eclipse（ADT）上で行います。

1つのService Definitionに対して、V2用・V4用など複数のService Bindingを作成できるため、プロトコルバージョンの切り替えが柔軟に行えます。

Service Binding を作成・有効化すると、SEGW での手動登録や /IWFND/MAINT_SERVICE での有効化が不要になります（RAP では自動的にサービスが登録されます）。

RAP方式のメリット・デメリット

2つの方式の使い分け

判断フローチャート

flowchart LR
  A{"対象システムは？"} -->|"S/4HANA\n（On-Premise / Cloud）"| B{"新規開発？"}
  A -->|"ECC"| E["SEGW方式\n（唯一の選択肢）"]
  B -->|"はい"| C["RAP方式\n（推奨）"]
  B -->|"既存サービスの\n保守・拡張"| D{"元のサービスは？"}
  D -->|"SEGW"| F["SEGW方式で\n拡張を継続"]
  D -->|"CDS View"| G["RAP方式に\n移行を検討"]

比較まとめ表

読者への示唆（so what）：「どちらが正しい」ではなく、状況に応じた使い分けが重要です。ただし、S/4HANA Cloud では SEGW が使えない（カスタムコードの制限がある、詳細はクリーンコア戦略を参照）ため、Cloud 環境ではRAP が唯一の選択肢になります。将来の Cloud 移行を見据えて、今から RAP のスキルを蓄積しておくことが実務上の保険になります。

よくある疑問

Q1. RAP の managed と unmanaged の違いは何ですか？

新規開発では managed を選び、既存ロジック（BAPI 等）を再利用する必要がある場合に unmanaged を選ぶのが一般的です。

Q2. SEGW で作ったサービスを RAP に移行できますか？

直接的な自動移行ツールはありません。実務上は以下のアプローチが取られます。

1. 新規に RAP で作り直す（データモデル・ロジックを再設計）
2. SEGW のサービスを残しつつ、新機能は RAP で追加（段階的移行）

移行コストが大きいため、既存の SEGW サービスが安定稼働していれば無理に移行する必要はありません。

Q3. Service Definition で expose しない CDS View は外部からアクセスできますか？

いいえ。Service Definition で expose した CDS View のみが OData サービスとして公開されます。内部的に使うだけの Interface View は expose せず、Consumption View だけを公開するのが標準的な設計です。

まとめ

• SEGW方式は GUI ベースで OData V2 サービスを構築する従来型のアプローチ。MPC でモデルを定義し、DPC_EXT に CRUD ロジックを手動実装する
• RAP方式は CDS View + Behavior Definition + Service Definition/Binding で OData サービスを宣言的に構築する S/4HANA 時代の標準
• RAP の managed シナリオでは CRUD の DB 操作が自動化され、開発者はバリデーション・アクションなどのビジネスロジックだけを実装すればよい
• ECC では SEGW 一択、S/4HANA の新規開発では RAP が推奨、既存 SEGW サービスの保守はそのまま SEGW で継続
• S/4HANA Cloud では SEGW が使えないため、Cloud 移行を見据えた RAP スキルの蓄積が実務上重要

次の記事 ODataサービスのテスト・デバッグ では、構築した OData サービスのテスト・デバッグ手法を解説しています。

SEGWやRAPでのサービス構築をさらに実践的に学ぶなら、ABAP・OData・RAP・BTP CAPまでカバーした実践講座で手を動かすのが近道です。全335レクチャーでSEGWからRAPへの移行スキルも体系的に身につきます。