SAP ODataとは？ ～利用ケースや構成要素、得意分野をわかりやすく解説～（vol.88）

,
  • 公開日：2022.12.05

SAP S/4HANAでは、FioriをSAP UI5で開発する場合や、外部システムやアプリケーションとデータ連携を行う場合に、OData（Open Data Protocol）を使用するケースが増えています。
SAP S/4HANAには標準のOData APIが用意されており、手軽にデータ連携が実現できるほか、SQLなどの簡単なプログラミング言語を理解されていれば、自作でODataサービスを作成することもできます。
しかし、SAPに携わる方々にとって、ODataはまだ馴染みの薄いアーキテクチャであり、日本語で概要や作成手順を解説したページは少ないのが現状です。

そこで本ブログ記事では、様々なアプリケーションと連携して使われることの多いSAP S/4HANA環境におけるODataの利用ケースや構成要素、ODataの得意な分野/苦手な分野を解説します。

ODataとは？

OData（Open Data Protocol）は、Microsoft社が策定したREST APIの標準プロトコルで、HTTPを使用してWEBサーバー等とブラウザ等でデータのやりとりをするための手順などを定めた規格です。

REST（ful）APIとは、RESTの原則に従ったWEBサービスであり、大まかに説明すると次の条件を満たすWEBサービスを指します。

  • WEBサーバーとブラウザの通信ではセッション管理などは行わず、ステートレス（リクエストの内容が同じであればレスポンスも同じとなる方式）である
  • URI（Uniform Resource Identifier）で情報のアドレスを表現可能である
    ※ブラウザに入力するURLもURIの一種です
  • GET/POST/PUT/DELETEなどのHTTPメソッドでデータの操作（取得/作成/更新/削除など）を行う

SQLをご存じの方は、「SELECT/INSERT/UPDATE/DELETEなどのSQL文と似たようなURIによって、データが操作できるWEBサービス」と考えてもらうとわかりやすいかもしれません。
また、URIによってデータの取得をリクエストした場合のレスポンスは、JSONもしくはXML形式で返すという特徴もあります。

色々と説明しましたが、簡潔に述べると、OData＝「HTTPを使ってサーバーとデータをやり取りするためのオープンなプロトコル」のことです。
ODataには複数のバージョンが存在し、これまでバージョン1.0～バージョン4.0まで公開されています。SAP S/4HANA環境では、OData v2.0とOData v4.0が混在しており、開発手順も異なります。

一般的なODataのイメージ（クライアント～サーバーまでの関連）は、次の図の通りです。

上図の通り、ODataに対して発行するhttpメソッドにてGET/POST/PUT/DELETEを指定することで、Databaseへデータの取得/作成/更新/削除のリクエストを行うことが可能となります。

クライアントとODataのデータ授受については、XMLやJSONと呼ばれるデータフォーマットを介して行われます。特にJSONは、JavaScriptにおいてデータ操作を行うためのフォーマットの１つであるため、クライアント側がWebアプリケーションの場合は親和性が高く、フロントエンドのアプリケーションを比較的容易に構築することが可能です。

SAP S/4HANA環境におけるODataの利用用途

冒頭でも記載しましたが、SAP S/4HANA環境におけるODataの用途は次の通りです。

  1. Fioriのようなフロントエンドで用いるデータ授受（バックエンドとしての用途）
    SAP S/4HANAには、従来のクライアント端末にインストールしてSAP S/4HANAを利用するSAP GUIの他に、SAP UI5（JavaScriptベースのフレームワーク）を用いたFioriと呼ばれるWEBブラウザで動作するUIが提供されています。
    ＊Fioriについての詳細（設定方法やよく利用されるタイルなど）は、こちらのブログをご覧ください。

    フロントエンドであるFioriとビジネスロジックを繋ぐために、バックエンドとしてODataが用いられます。ODataを事前に定義しておくことで、ABAPの知識がないWEB開発者でも、Fioriの実装を行うことが可能となります。

    FioriやODataを一般的な3層アーキテクチャで表現すると、次のようなイメージとなります。

  2. SAP S/4HANA以外のシステムやアプリケーションとのデータ連携（データインターフェースとしての用途）
    SAP S/4HANAでは、データ層としてSAP HANAというDBを用いる必要があります。
    SAP S/4HANAはデータを直接参照することが不可となっており、アプリケーション層を介したデータ連携に限定されています。
    アプリケーション層を介したデータ連携の手段のひとつとして、ODataを用いたデータ連携があります。

    ODataやSAP HANAを一般的な3層アーキテクチャで表現すると、次のようなイメージとなります。

    取得したデータにリアルタイム性が求められない場合は、RFCという技術を用いたデータ連携ができる弊社ソリューション「BusinessSPECTRE」が適しています。
    ただし、外部システム/アプリケーションと連携しながらサプライチェーンを管理している場合、受発注/生産/在庫などの情報には、リアルタイム性が求められます。そういった場合は、httpプロトコルでデータ連携を行えるODataが適しています。

SAPデータ活用って、正直どうすればいいの？
～BIツールの最適解～

SAP S/4HANA環境におけるODataの構成要素

SAP S/4HANA環境におけるODataの利用用途を解説しましたが、具体的にどのような要素で構成されているのでしょうか？
データ取得・参照＝GETのみを行う場合と、データ登録/更新/削除＝POST/PUT/DELETEも行う場合とで異なりますが、SAP S/4HANA環境におけるODataは次の要素で構成されます。

  1. メソッド
    プロジェクトに対してメソッドを紐づけ、GET/POST/PUT/DELETEで実行する処理を定義します。
    具体的な設定方法は割愛しますが、例えば、販売伝票や購買伝票のようにヘッダと明細に分かれているようなデータであれば、ヘッダ側で指定した条件に基づき、ヘッダのデータと明細のデータを「Association」という関連を持たせる設定を行うことで、まとめて取得する といったことも可能です。また、「Deep Insert」と呼ばれる仕組みで、ヘッダ1件に対し複数明細をまとめて登録する といった定義も可能です。
  2. プロジェクト
    Tr-Cd：SEGW 等で定義します。プロジェクトの単位がODataの構成単位となります。
    メソッドをプロジェクトに定義することでODataを利用するのですが、例えば、複数のロジックが異なるメソッドを１つのプロジェクトに定義することができます。
    用途は類似しているが、インプットや処理ロジック、アウトプットが異なるメソッドを、１つのプロジェクト＝１つのOData として定義し、まとめることも可能です。
    逆に、管理上の理由などで、メソッドごとにODataを厳密に分けて定義することも可能です。
  3. CDS View
    GETに限定されますが、CDS Viewと呼ばれるViewを定義し、プロジェクトに紐づけることで、容易にODataのGETメソッドを実装することができます。
    CDS Viewは、固有のお作法はありますが、一般的なRDBで用いられるようなSQLを用いるため、SQLを理解している開発者であれば、容易に実装が可能です。
    また、一部のCDS ViewはSAP S/4HANAに標準で用意されています。取得したいテーブルやカラム、条件に合致するCDS Viewがあれば、ノンコーディングでODataのGETメソッドを実装することが可能です。
    さらに、標準のCDS Viewは、SAPのバージョンアップを見据えた開発にも有効です。標準のCDS Viewは、バージョン間の差異をSAP社が担保しているため、それらを紐づけたODataについては、バージョンアップ時の影響を最小限に留めることができます。

上記が各構成要素の概要です。なお、各種設定/実装方法は、OData v2.0とOData v4.0で異なる点があるためご注意ください。
SAP S/4HANA環境におけるOData v2.0とOData v4.0の差異や、具体的な利用方法、設定/開発方法は、改めて本ブログ記事に追記する形式で解説して参ります。

SAP S/4HANA環境におけるODataの得意な分野

ODataでは、取得したデータの形式はJSONやXML形式で返ってくると説明しましたが、こちらがODataの得意な分野と関連していますので、JSONを例に解説します。

JSON（JavaScript Object Notation）とは、「JavaScriptのオブジェクト表記法を用いたデータ交換フォーマット」です。様々な言語でサポートされており、JSONを間に挟むことで各プログラミング言語間のデータの受け渡しが簡単にできます。
JSON（JavaScript Object Notation）は、名前にJavaScriptと入っているように、プログラミング言語であるJavaScriptと相性が良いです。ブラウザ上で動くアプリケーションはJavaScriptで作られていることが多いので、ブラウザと様々なバックエンドのシステムとの通信にJSONが使われるようになりました。

JavaScriptでオブジェクトを作成する際は {} や [] などの括弧を使って記述しますが、JSONでも同様に、項目名と値をペアで指定します。

{
“項目名1”: 値1,
“項目名2”: 値2
}

また、ネスト（階層化）させることも可能です。
例えば、ユーザマスタの場合、次のようになります。

{
“users”: [{
“name”: “山田一郎”,
” department “: “営業部”,
}, {
“name”: “田中次郎”,
” department “: “経理部”,
}, {
“name”: “伊藤三郎”,
” department “: “総務部”,
}]
}

では、JSONでデータのやりとりを行うODataが得意な分野について考えてみましょう。
JSONは、JavaScriptで扱うオブジェクトと形式が同じため、変換処理などを行う手間がかからない分、高速に動作します。
現在、JavaScriptのライブラリは数多く開発されていますが、多くはCRUD処理を行う画面開発に向いています。

CRUD処理とは、CREATE（生成）/READ（読み込み）/UPDATE（更新）/DELETE（削除）の頭文字で、例えばSAP S/4HANAのようなERPシステムのマスタ登録/照会/変更/削除を行う画面を想像してもらうとわかりやすいかと思います。
このCRUD処理ですが、ODataのRESTの原則で説明した、「GET/POST/PUT/DELETE等のHTTPメソッドによるデータ処理と相性が良い」というのは、直観的にも理解しやすいのではないでしょうか？
それでは、逆にODataの苦手な分野とは何なのでしょうか。

SAP S/4HANA環境におけるODataの苦手な分野

前章で、ODataはWebブラウザなどのクライアントからHTTPメソッドを介してJSON形式でデータを返すため、JavaScriptを使ったCRUD処理画面と相性がよいことを解説しました。JSONやXMLはネスト（階層化）した構造も表現できるため、汎用性の高いフォーマットではありますが、人が見た場合には複雑なものは直観的にはわかりにくくなります。

人が直観的にわかりやすいフォーマットとしては、EXCELなどのテーブル形式やCSV形式などが挙げられます。先ほどのユーザマスタをCSV（先頭行を項目名）とすると、次のようになります。

name, department
山田一郎,営業部
田中次郎,経理部
伊藤三郎,総務部

複雑なネスト構造は１つのテーブルでは表現できませんが、人の目からも分かりやすいだけでなく、SAP S/4HANAのようなERPシステムがデータを格納しているデータベースでも、このようなテーブル形式で保存されています。
つまり、ODataでSAP S/4HANAからデータ取得を行う場合、テーブル形式からJSON形式への変換が行われているのです。

ここで、ODataの苦手な分野について考えてみましょう。
ズバリ、ODataの苦手な分野は、JSONがそのまま使えない、JavaScript以外で記述されたアプリケーションです。
例えば、RPA（Robotic Process Automation）ツールや、外部のDWH（Data Ware House）にデータを連携して分析するツールなどが挙げられます。
これらのツールは、CSV形式やテーブル形式の取り扱いが得意なため、JSON形式からテーブル形式への変換処理を行ってからデータを使用することになるからです。

その他、JSON形式からテーブル形式への変換とは別に、プログラミング言語で取り扱えるように変換する処理（シリアライズ/デシリアライズ）も発生するため、データ量が多くなると影響が大きくなります。また、CSVなどの形式に比べ、JSONやXMLはサイズが大きくなる傾向があり、大量データを扱う場合にはネットワークの負荷が高くなり、パフォーマンスに影響する場合があります。

ODataは、マスタなどの入力画面をJavaScriptで開発する場合には非常に相性が良いですが、大量のデータを取り扱うDWHなどでは、サイズや変換の面でデメリットがあります。
変換処理やシリアライズ処理は大量データに対応して高速化を実現しているシステムもあるようですが、まだ数が少ないのが実態です。

まとめ

ここまで、ODataとはどういったものか、SAP S/4HANA環境における利用用途や構成要素、得意分野/苦手分野を解説してきました。

「2027年問題」に伴い、長らく利用していたSAP ECC6.0をSAP S/4HANAへ移行する場合、既存の外部システムやアプリケーションとのインターフェースを見直す必要があります。そこで、新たな技術要素としてODataを利用するケースが想定されます。バージョンアップ時の影響やシステム全体としての柔軟性を考慮して、どのような仕組みでSAP S/4HANAとのインターフェースを構築すべきかを検討しましょう。

弊社電通総研では、ODataを使用したインターフェース構築はもちろん、ODataの苦手とするDWHへのデータ連携ソリューションとしてBusinessSPECTREをご提供しております。
BusinessSPECTREは、RFCという技術を使用してデータ連携しており、大量データの取り扱いにも対応しています。

SAPデータの利活用でお悩みの際は、是非、弊社までお声掛けください。
https://erp.dentsusoken.com/inquiry/

＊本記事は、2023年3月1日時点の情報を基に作成しています。