SAP ODataとは｜BAPIを超えるWeb API

当ページのリンクには広告が含まれています。

2025/11/04

SAPシステムの世界では、長らく「汎用モジュール」や「BAPI（Business Application Programming Interface）」が外部連携やカスタム開発の中心的なインターフェースとして君臨してきた。R/3の時代から続くこれらの仕組みは、SAPの機能を外部システムやアプリケーションから呼び出す、堅牢で信頼性の高い、定番の方法である。

しかし、時代は大きく変わった。

Webとクラウドが主役となり、システム連携は「HTTP」をベースにした軽量な API 中心の世界へ移行している。
SAPも例外ではなく、その変革の中心にあるのが OData（Open Data Protocol） である。

ODataは、単なるデータ取得の手段ではない。

それは「SAPの外へ、そしてクラウドへ拡張するための共通言語」であり、S/4HANAおよびSAP BTPの標準API基盤として位置付けられている。

本記事では、

そもそもODataとは何か
汎用モジュール／BAPIとの違い
ODataが利用できるSAP環境
ODataの利用シーン、メリット・デメリット
RESTとの関係
ODataの調べ方

といった観点から、「BAPIの次に来るインターフェース」として、ODataをわかりやすく解説していく。

SAP初心者はもちろん、従来の汎用モジュールやBAPIと比較しながら解説しているため、これからODataへの移行を検討しているSAPエンジニアにも役立つ内容となっている。ぜひ最後まで読んでほしい。

SAP ODataとは何か

ODataの基本的な仕組み

OData（Open Data Protocol）は、Microsoftが提唱した「データアクセスの標準化プロトコル」であり、現在ではOASIS（Organization for the Advancement of Structured Information Standards、日本語では一般的に「構造化情報標準推進機構」と訳される）によって標準化されている。

ODataはHTTPベースで動作する。つまり、Webを前提としており、クライアントが「URLクエリ」を通じてデータを操作できるよう設計されている。

たとえば次のようなリクエストが可能だ。

GET /sap/opu/odata/sap/API_SALES_ORDER_SRV/A_SalesOrder?$filter=SalesOrganization eq '1710'&$select=SalesOrder,Customer,TotalNetAmount

この一行で、販売組織 1710 の受注伝票を取得し、$select で必要なフィールド（受注番号、受注先、受注金額など）を指定して取得できる。

つまり、ODataは「SQL的な問い合わせをHTTPで実現する仕組み」と言える。

また、ODataでは主に以下の概念が登場する。

Entity（エンティティ）：BAPIでいう構造体に近い。ビジネスオブジェクトを表す。
EntitySet（エンティティセット）：エンティティの集合。データテーブルに相当。
Navigation Property：リレーションシップを表現し、他のエンティティへのリンクを可能にする。

これらによって、SAP内のビジネスデータを「Webの言語」で公開できるようになった。

プロトコル仕様（v2とv4）

SAPでは長らく OData v2 が主流で、SAP Gateway を通じて実装される。
最近の S/4HANA Cloud や SAP BTP（CAP）では OData v4 が主力となっている。

OData v4では以下が強化された。

JSON形式の標準化（軽量・高速）
デルタクエリ（差分取得）
バッチ処理の効率化
メタデータの拡張性向上

汎用モジュール／BAPIとの違い

RFC vs HTTP

BAPIは内部的に「RFC（Remote Function Call）」を利用する。Webが主流となる以前のSAPシステムは、RFCによるアプリケーション間通信は一般的な手法であった。

RFCによる通信は堅牢で高速だが、NCO（SAP .NET Connector）や JCO（SAP Java Connector）といった専用ライブラリや接続設定が必要である。要するに、SAP外のシステムからBAPIを利用するには「通信ドライバ」が必要となるため、クラウド時代にはやや扱いづらい。

一方、ODataはHTTP標準プロトコルで動作するため、ブラウザ・モバイル・クラウドアプリから直接呼び出せるという大きな利点がある。

ODataは「SAPシステムを外の世界とつなぐ」ことを容易にし、ネットワーク境界を超える連携を自然に実現する。

トランザクション処理とコミットの考え方

BAPIでは、トランザクション処理のための BEGIN ～ COMMIT / ROLLBACK の制御が明示的に必要である。

ODataでは、HTTPの POST や PATCH リクエスト単位でトランザクションが完結する設計になっている。
複数の操作を一括実行したい場合は「Batch Request」でまとめて送信する。

つまり、BAPIは「機能単位の呼び出し」、ODataは「リソース単位の操作」に発想が変わったと言える。

セキュリティと認可

ODataは SAP Gateway（またはCAP）^※が HTTPエンドポイントとして公開するため、SICF 設定や OAuth2.0 認証が活用される。

また、ビジネスロジック層では従来通り「権限オブジェクト（Authorization Object）」が有効である。つまり、ODataは表層がHTTPに変わっても、裏側の権限制御はSAPのセキュリティの仕組みを継承している。

ODataはSAP Gateway（オンプレミス）やCAP（Cloud Application Programming Model）を通じて提供される。CAPはSAP BTP上のクラウドネイティブ開発フレームワークであり、CDSモデルからODataサービスを自動生成する仕組みである。

ODataが利用可能なSAP環境

S/4HANA（On-Premise/Cloud）

S/4HANAでは、標準的に数千種類のODataサービスが提供されている。

たとえば、前述の「販売伝票」や「購買発注」「会計仕訳」など、主要な業務オブジェクトには、既にAPIが用意されている。

これらはすべて SAP API Business Hub から確認できる。

SAP Gateway、BTP、CAP

オンプレ環境では「SAP Gateway」を通じてODataが公開される。

一方のクラウド開発では「SAP BTP（Business Technology Platform）」上で CAP（Cloud Application Programming Model） を使ってODataを定義するのが主流である。

CAPはNode.jsやJavaで動作し、エンティティを宣言的に定義すれば自動でODataエンドポイントを生成できる。

FioriアプリとOData

SAP Fioriアプリは、すべてODataを通じてSAPデータにアクセスしている。

つまり、ODataを理解することは「Fioriの裏側を理解する」ことに直結する。Fiori ElementsやUI5アプリの開発では、ODataのメタデータ構造を前提にUIが動的生成される。

ODataでできること

SQLと同等のことができる

ODataはデータ参照だけでなく、登録・更新・削除（CRUD操作）も可能である。
これらの操作は「HTTPメソッド」または「OData操作（OData operation）」と呼ばれる。

該当するSQL文のイメージと合わせ、下の表に整理しておく。

HTTPメソッド（OData）	ODataでの意味	操作区分	該当するSQL文のイメージ
GET	データ取得（読み取り）	Read	`SELECT ... FROM ... WHERE ...`
POST	新規エンティティ作成	Create	`INSERT INTO ... (col1, col2, ...) VALUES (...);`
PATCH（MERGE）	既存エンティティの部分更新	Update	`UPDATE ... SET colA = ..., colB = ... WHERE ...;` ※変更項目のみ更新
PUT	エンティティ全体置換	Update	全項目を上書きする `UPDATE ... SET col1=..., col2=..., ... WHERE ...;`（実装により「削除＋再挿入（`DELETE`→`INSERT`）」で表現される場合もある）
DELETE	エンティティ削除	Delete	`DELETE FROM ... WHERE ...;`

これらの操作をWebブラウザや Python などから簡単に行える点は、BAPIの場合と比べて圧倒的に利便性が高いと言える。

外部連携（モバイル・RPA・BI）

ODataはRPAツール（UiPath、Automation Anywhere）やBI（Power BI、Tableau）から直接アクセス可能だ。
専用の通信コネクタは不要なので、「SAPデータをノーコードで扱う」の技術基盤となっている。

パフォーマンス設計

ODataでは、$selectで列を絞り込み、$filterで条件指定し、$topで件数制限をかけることができる。
つまり「欲しいデータだけを返す」最適化が可能だ。
従来のRFCの「構造体に全項目を詰めて返す」方式に比べ、ネットワーク負荷を大幅に軽減できる。

ODataのデメリット

通信のための専用ドライバを必要とせず、URLだけでトランザクションを完結できるなど、メリットの多いODataであるが、欠点もある。

大量データには不向き

数十万件以上を扱う場合は注意が必要だ。

この理由は、JSON/XML形式で全件を返すため、サイズが数百MB～GBになるためである。この結果、通信帯域・ブラウザやクライアントのメモリを圧迫する。また、処理に時間がかかりすぎるとタイムアウトが発生することもある。

トランザクション制御が限定的

複雑なトランザクション処理（コミット制御）には不向きである。

一般的なSQLやABAPプログラミングでは、複数のテーブルに対する処理を一つの論理単位＝トランザクション処理として扱うことができ、処理の途中で失敗すれば全件ロールバック、処理が最後まで成功すれば全件コミット、という制御が可能である。

一方のODataは、１回のHTTP呼び出しが一つのトランザクションとなるため、HTTP呼び出しの単位でコミットまたはロールバックが実行される。

デバッグが難しい

HTTP層＋ABAP層という、プログラム処理が複数のレイヤーをまたぐため、ABAP単層と比べてトレースやデバッグの難易度は高い。

ODataとRESTの違い

RESTとは

RESTとは、インターネットの基本的な仕組み（HTTP）をそのまま利用して、システム同士がデータをやり取りするための設計思想である。簡単に言えば、「URLを使ってリソース（データ）を操作するルール」のことだ。

RESTの設計思想に基づいて実装されているWeb APIのことを、「REST API」と呼ぶ。

REST API の具体例

REST APIは、直接見えるものではないが、Webアプリやスマホアプリなど、身近なところで多く活用されている。
その一例を紹介しておこう。

Google Maps Platform API: Googleが提供する地図情報サービスのAPI群。
住所から緯度・経度を取得したり、逆に座標から住所を求めたりできる。
スマホアプリや業務システムで、Google Mapを利用した地図・位置情報を扱うアプリは、大抵このAPIを利用している。したがって、広く多く使われているAPIである。
Twitter API: Twitter（現X）が公開するAPIで、ツイートの取得・投稿、フォロワー情報の取得などを行う。
SNS連携やデータ分析の分野で最も広く利用されている。
OpenAI API: ChatGPTでお馴染みのOpenAI社が公開しているAPI。ChatGPTに相当するAIの機能をアプリから呼び出せる。
本ブログでも高頻度で取り上げているAPIだ。

REST原則とOData拡張

ODataはこのRESTの原則をベースにしており、そこに「データの検索条件（$filter、$selectなど）を標準化する仕組み」を加えたものがODataプロトコルである。

つまり、ODataはRESTの原則（リソース指向・ステートレス通信）を継承しつつ、「データ操作の標準文法」を追加したものである。

RESTが「哲学」だとすれば、ODataは「その哲学を実装する具体的なプロトコル」と言える。

API設計思想の比較

項目	REST	OData
データ取得	エンドポイントごとに定義	クエリで柔軟に指定
メタデータ	手動ドキュメント化	`$metadata`で自動生成
拡張性	柔軟だが標準化されていない	標準仕様に基づく一貫性

ODataのメタデータ

メタデータは「データのためのデータ」

ODataを理解するうえで欠かせない概念が「メタデータ（metadata）」である。

メタデータとは、直訳すると「データのためのデータ」であり、ODataサービスの設計図・取扱説明書のようなものだ。

たとえば、家を建てるときに設計図がないと配線や配管がわからないように、ODataでも「どんなテーブル（エンティティ）があり、どんな項目を持ち、どんな操作ができるか」を示すための設計情報が必要になる。
この設計情報がメタデータである。

これは SAP Gateway や S/4HANA Cloud のODataサービスに共通する仕様である。

メタデータの確認方法

ODataの世界では、メタデータは標準化されたXML形式で提供され、サービスURLの末尾に$metadataを付けるだけで確認・取得できる。

販売伝票を取得するOData APIのメタデータURL

たとえば、前述の受注伝票を取得する OData API「API_SALES_ORDER_SRV」のメタデータは、次のようなURLをWebブラウザから指定することで表示することが可能だ。

https://my-s4hana.example.com/sap/opu/odata/sap/API_PURCHASEORDER_PROCESS_SRV/$metadata

このURLをWebブラウザで実行すれば、XML形式のメタデータを取得できる。

その冒頭部分は次のようになっている。

<?xml version="1.0" encoding="utf-8"?>
<edmx:Edmx Version="1.0"
  xmlns:edmx="http://schemas.microsoft.com/ado/2007/06/edmx">
  <edmx:DataServices>
    <Schema Namespace="API_SALES_ORDER_SRV"
      xmlns="http://schemas.microsoft.com/ado/2008/09/edm">
      <EntityType Name="A_SalesOrder">
        <Key>
          <PropertyRef Name="SalesOrder"/>
        </Key>
        <Property Name="SalesOrder" Type="Edm.String" Nullable="false" MaxLength="10"/>
        <Property Name="SalesOrderType" Type="Edm.String" MaxLength="4"/>
        <Property Name="CustomerID" Type="Edm.String" MaxLength="10"/>
        <Property Name="TotalNetAmount" Type="Edm.Decimal" Precision="15" Scale="2"/>
      </EntityType>
    </Schema>
  </edmx:DataServices>
</edmx:Edmx>

この定義を読むことで、次のような情報が明確になる：

エンティティ名：A_SalesOrder（販売伝票ヘッダに相当）
主キー：SalesOrder
項目一覧：SalesOrderType、CustomerID、TotalNetAmount など
データ型や桁数、NULL許可などの属性

すなわち、ODataのメタデータを読むことで「どのようなデータ構造なのか」「どの項目を指定できるのか」「どの操作（GET, POST, PATCHなど）が許可されているのか」を把握できる。

この操作は、T-Code: BAPI「BAPI Explorer」 や T-Code: SE37「汎用モジュールビルダ」で、「汎用モジュール／BAPIのパラメータを確認する」感覚に近い。

メタデータを活用するメリット

メタデータが公開されており、それを取得できると、以下のようなメリットがある。

自動生成ツールとの連携: 各種開発ツール（SAP Cloud SDK、UI5、Power BIなど）は、この $metadata を解析し、自動的に型定義やデータバインディングを生成できる。
APIのバージョン管理: メタデータを比較すれば、サービスの変更点（項目追加・削除・型変更）を追跡できる。
ドキュメント代替: API仕様書を手書きする必要がなく、実際の稼働中サービスから常に最新情報を取得できる。