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

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

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

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

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

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

本記事では、

といった観点から、「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では主に以下の概念が登場する。

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

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

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

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

汎用モジュール／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が、OpenAI API である。本ブログでもたびたび取り上げているAPIだ。

あわせて読みたい

非エンジニアでもできる！Excel+OpenAI APIの使い方完全ガイド ExcelからOpenAI APIを呼び出して生成AIを活用！報告書作成・要約・分析コメント・関数の自動生成まで、業務効率化を実現する方法を実例付きで解説！

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://エンドポイントのアドレス/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仕様書を手書きする必要がなく、実際の稼働中サービスから常に最新情報を取得できる。

ODataの調べ方

SAP API Business Hub

BAPIを探す場合、T-Code: BAPI「BAPI Explorer」で検索するのが定番の方法であるが、ODataを検索するには「SAP API Business Hub」を利用する。

SAP API Business Hub

モジュール別・製品別・業務プロセス別にAPIが整理されており、サンプルリクエストをその場で試すことも可能だ。
UIは直感的で、技術者以外でも理解しやすい。

---

汎用モジュール／BAPIの探し方を紹介している記事は以下。

RISE with SAP・Grow with SAPを支えるODataの役割

ODataは単なる技術仕様ではなく、SAPのクラウド戦略の中核をなす共通インターフェースである。

特に「RISE with SAP」および「Grow with SAP」のようなクラウドモデルにおいて、その重要性は一層高まっている。

RISE with SAPにおけるODataの位置づけ

「RISE with SAP」は、既存のオンプレミスSAPをS/4HANA Cloudへと移行し、クラウドネイティブな運用に再構築する包括的なサービスモデルである。

このとき、企業は既存ABAPカスタマイズや外部連携を、クラウド標準のAPI対応へ再設計する必要がある。

その標準APIこそが OData である。

ODataは、S/4HANA Cloudが提供する公式APIの大部分を占めており、SAP API Business Hubに登録されている「Public API」はほぼOData形式で公開されている。
すなわち、BAPIからODataへの移行が、クラウド化対応の第一歩となる。

つまり、ODataは「クラウド時代の外部I/F」であり、RISE with SAPの実行基盤を支える通信層である。

Grow with SAPにおけるODataの位置づけ

一方「Grow with SAP」は、中堅企業を中心にクラウドネイティブな新規導入を促進するプログラムである。

オンプレ資産を持たない企業が最初からS/4HANA Cloudを採用する場合、その拡張開発は SAP BTP上のCAP（Cloud Application Programming Model） や SAP Build などで行われる。

これらの開発基盤が自動的に生成・利用しているのが OData v4サービス である。

Grow with SAPの世界では、ODataは「拡張と統合の共通プロトコル」として機能している。
ODataを理解していれば、ABAPだけでなく、JavaScriptやNode.js、ローコード開発者もSAP拡張に参入できる機会がある。

まとめ｜SAP ODataが切り開く次世代インターフェースの世界

ODataは、SAPシステムにおける単なる「新しい通信方式」ではない。

それはSAPがクラウドネイティブへ進化するための「共通言語」であり、BAPIや汎用モジュールを超える存在である。

SAPエンジニアにとって、ODataの理解はもはや“選択肢”ではなく“前提条件”となりつつある。
クラウド時代におけるSAP開発の新常識――それが SAP OData である。