Fiori×OData｜FioriアプリがODataをどう使うか・Fiori Elementsの仕組み

はじめに

このODataシリーズの最終回では、Fioriアプリが裏側でODataをどのように使っているかを解説します。Fioriは「綺麗な画面」だけでなく、ODataを通じてSAPのデータにアクセスする一貫したアーキテクチャを持っています。

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

1. FioriアプリのアーキテクチャとOData — 画面の裏側で何が起きているか
2. SAPUI5のODataモデル — データバインディングの仕組み
3. Fiori Elements — CDS Viewのアノテーションから自動生成されるUI

なぜこの知識が必要か（why so）：Fiori アプリのカスタマイズや新規開発では、「画面に表示されるデータがどこから来るか」を理解する必要があります。答えはすべて OData です。OData サービスの構造を知っていれば、Fiori の動作原理が理解でき、問題発生時の原因切り分けも格段に速くなります。

Fiori アプリのアーキテクチャと OData

Fiori アプリの構成要素

SAP Fiori アプリは、大きく3つの層で構成されています。

flowchart LR
  subgraph "ブラウザ（**クライアント**側）"
    A["SAPUI5\n（JavaScriptフレームワーク）"]
    B["ODataモデル\n（データ管理）"]
    A --> B
  end
  subgraph "SAP **Gateway**"
    C["ODataサービス\n（HTTPエンドポイント）"]
  end
  subgraph "SAP**バックエンド**"
    D["CDS View / DPC\n（データ取得・更新）"]
    E["ビジネスデータ\n（テーブル）"]
    D --> E
  end
  B -->|"HTTP/OData\nGET/POST/PUT/DELETE"| C
  C --> D

Fiori アプリのすべてのデータ操作は OData を経由するのが基本原則です。画面に表示されるデータの取得、ユーザーが入力したデータの保存、検索条件によるフィルタリング――すべてが OData リクエストとして実行されます。

ユーザー操作と OData リクエストの対応

ユーザーが Fiori アプリ上で行う操作は、裏側で以下の OData リクエストに変換されています。

補足：Fioriアプリの実際の動作ではMERGE（V2）やPATCH（V4）による部分更新が一般的です。PUTはエンティティ全体の置き換えを意味するため、変更したフィールドだけを送信するMERGE/PATCHの方が効率的で、SAPUI5のODataモデルもデフォルトでこの方式を採用しています。

読者への示唆（so what）：Fiori アプリが「遅い」「データが表示されない」といった問題は、ブラウザの開発者ツール（F12）の Network タブで OData リクエストを確認することで原因を特定できます。どの URL にリクエストが飛んでいるか、レスポンスのステータスコードは何か、レスポンス時間はどれくらいか――これらを確認するだけで、問題の層（フロントエンド/Gateway/バックエンド）を切り分けられます。OData のエラーパターンと切り分け方法についてはODataサービスのテスト・デバッグで解説しています。

SAPUI5 の OData モデル

OData モデルとは

SAPUI5 では、OData モデルがアプリケーションとバックエンドの間のデータ管理層として機能します。UI のコントロール（テーブル、フォーム、入力フィールドなど）は OData モデルにデータバインドされており、モデルのデータが変わるとUIが自動的に更新されます。

flowchart LR
  subgraph "SAPUI5 アプリ"
    UI["UIコントロール\n（テーブル・フォーム）"] -->|"データバインディング\n{PropertyName}"| M["ODataモデル\n（データキャッシュ）"]
  end
  M -->|"GETリクエスト\n（自動送信）"| S["ODataサービス"]
  S -->|"JSONレスポンス"| M

読者への示唆（so what）：ODataモデルの仕組みを理解していると、データが画面に反映されない問題のデバッグ時に、モデルのキャッシュ状態やバインディングパスの誤りを効率的に特定できます。

OData V2 モデルと V4 モデル

SAPUI5 では OData のバージョンに応じて異なるモデルクラスを使います。

S/4HANA Cloudの新規開発ではV4モデルが推奨されます。既存のSEGWベースのサービスを利用する場合はV2モデルを使います。プロジェクトで使用するODataバージョンはバックエンドのサービス実装方式に依存するため、先にサービス側の方針を確認してください。

バッチリクエスト

SAPUI5 の OData モデルは、複数のリクエストを1つの HTTP リクエストにまとめて送信する「バッチリクエスト」をサポートしています。

flowchart LR
  subgraph "バッチなし（3回のHTTPリクエスト）"
    A1["GET /HeaderSet"] --> A2["GET /ItemSet"] --> A3["GET /StatusSet"]
  end
  subgraph "バッチあり（1回のHTTPリクエスト）"
    B1["POST /$batch\n中身:\nGET /HeaderSet\nGET /ItemSet\nGET /StatusSet"]
  end

なぜバッチが重要か（why so）：Fiori アプリの1画面には複数のデータソースが表示されることが多く（ヘッダ情報、明細一覧、ステータスなど）、それぞれ別の OData リクエストが必要です。バッチリクエストにより、これらを1回のHTTP通信にまとめることで、ネットワークのラウンドトリップを削減しパフォーマンスを向上させます。

パフォーマンス問題の調査では、ブラウザのNetworkタブで$batchリクエストの中身を展開し、不要なリクエストが含まれていないかを確認することが第一歩です。

Fiori Elements

Fiori Elements とは

Fiori Elements は、CDS View のアノテーションを基にFiori の UIを自動生成する仕組みです。開発者が HTML や JavaScript を書かなくても、CDS View のアノテーション（@UI.*）を定義するだけで標準的な画面が生成されます。

従来の Freestyle Fiori との違い

Fiori Elements のテンプレート

Fiori Elements には、業務パターンに応じた**テンプレート（フロアプラン）**が用意されています。

flowchart LR
  subgraph "よくある画面遷移"
    A["List Report\n（検索・一覧）"] -->|"1件選択"| B["Object Page\n（詳細・編集）"]
  end
  subgraph "ODataリクエスト"
    C["GET /EntitySet\n?$filter=...\n（一覧取得）"]
    D["GET /EntitySet('key')\n?$expand=...\n（詳細取得）"]
  end
  A --> C
  B --> D

CDS View アノテーションと Fiori Elements の対応

Fiori Elements は CDS View の @UI アノテーションを読み取って画面を構成します。CDS View のアノテーション体系についてはCDS Viewとは何か？S/4HANAのデータモデリングを支える新しい基盤で解説しています。

具体例：CDS View アノテーションから List Report が生成されるまで

define view entity Z_C_PurchaseOrder
  as projection on Z_I_PurchaseOrderHeader
{
      @UI.selectionField: [{ position: 10 }]
      @UI.lineItem: [{ position: 10, label: '発注番号' }]
  key PurchaseOrder,

      @UI.selectionField: [{ position: 20 }]
      @UI.lineItem: [{ position: 20, label: '会社コード' }]
      CompanyCode,

      @UI.lineItem: [{ position: 30, label: '仕入先' }]
      Supplier,

      @UI.lineItem: [{ position: 40, label: '作成日' }]
      CreatedAt,

      _Item
}

この CDS View から生成される List Report は以下のような構成になります。

HTML/JavaScript を1行も書かずに、CDS View のアノテーションだけで検索画面が完成するのが Fiori Elements の強みです。

OData シリーズ全体の振り返り

本シリーズ全5回で扱った内容を整理します。

flowchart LR
  subgraph "第1回：ODataの基礎"
    A1["エンティティ設計\nクエリオプション"]
  end
  subgraph "第2回：SAP×OData"
    A2["SAP Gateway\nFES/BES構成"]
  end
  subgraph "第3回：サービスの作り方"
    A3["SEGW方式\nRAP方式"]
  end
  subgraph "第4回：テスト・デバッグ"
    A4["Gateway Client\nエラーログ"]
  end
  subgraph "第5回：Fiori×OData"
    A5["SAPUI5モデル\nFiori Elements"]
  end
  A1 --> A2 --> A3 --> A4 --> A5

各回の詳細トピック（Navigation Property、処理フロー、使い分け判断基準、頻出エラーパターン、アノテーション体系など）は下表を参照してください。

よくある疑問

Q1. Fiori Elements と Freestyle Fiori はどちらを選ぶべきですか？

原則として Fiori Elements を第一候補とし、Elements のテンプレートでは実現できない要件がある場合にのみ Freestyle を選びます。

Q2. Fiori アプリから直接 ABAP を呼ぶことはできますか？

Fiori（SAPUI5）はブラウザ上で動く JavaScript アプリのため、ABAP を直接呼ぶことはできません。すべてのバックエンドアクセスは OData サービスを経由します。ABAP のロジックを実行したい場合は、OData サービスの Function Import（V2）や Action（V4）として公開し、Fiori 側からHTTPリクエストで呼び出します。Function Import（V2）やAction（V4）は、ODataサービスに独自の操作（例：発注の承認、在庫の払出など）を追加する仕組みです。

Q3. Fiori Launchpad とは何ですか？

Fiori Launchpad は、複数の Fiori アプリを統合的に管理・起動するポータル画面です。ユーザーはブラウザから Fiori Launchpad にログインし、タイルをクリックして各アプリを起動します。各タイルの裏側で、対応する OData サービスが呼び出されます。

Q4. OData 以外のデータアクセス方法は Fiori にありますか？

SAPUI5 は OData モデル以外にも JSON モデルや XML モデルをサポートしていますが、これらはクライアント側のローカルデータ用です。SAP バックエンドのデータにアクセスする場合は、OData が標準的かつ推奨される手段です。

まとめ

• Fiori アプリのすべてのデータ操作は OData サービスを経由しており、ユーザーの画面操作は裏側で GET / POST / PUT / DELETE に変換されている
• SAPUI5 の OData モデルがアプリとバックエンドの間のデータ管理層として機能し、データバインディングにより UI が自動更新される
• バッチリクエストにより、複数の OData リクエストを1回の HTTP 通信にまとめてパフォーマンスを向上させている
• Fiori Elements は CDS View の @UI アノテーションから UI を自動生成する仕組みであり、HTML/JavaScript を書かずに標準的な画面を構築できる
• 新規開発では Fiori Elements を第一候補とし、テンプレートで実現できない要件がある場合のみ Freestyle を選択する
• 問題発生時はブラウザの開発者ツール（Network タブ）で OData リクエストを確認することで、フロントエンド/Gateway/バックエンドの切り分けが可能

FioriとODataの連携をさらに深く理解するには、SAPUI5のデータバインディングやFiori Elementsの実装を実際に手を動かして学ぶのが効果的です。ABAP・OData・RAP・UI5 Fioriまで一貫して学べる実践講座で、Fiori開発の全体像を体系的に身につけられます。