はじめに
最近、S/4HANAのデータを外部と連携するユースケースが増え、｢OData｣に関する説明依頼や問い合わせを受けることが増えています。前回投稿した「CDS View｣の基本的なことまとめ」の閲覧数が想定よりも多いので、今回は｢OData｣をテーマに記事を書きました。｢OData｣に関しては、まとめ記事も多いので、「何がすごいのか、便利なのか」にフォーカスを当てて書きたいと思います。
「SAP Business Technology Platform (BTP)の基本的なことのまとめ」や｢SAP Side by Side開発の基本的なことまとめ｣に続く基本的事項の説明記事となります。
また、本記事は概要把握や個人とトライアル利用の参考として、まとめたものなので、プロジェクトでの利用の際は、SAP社への問合せの実施や正式情報であるHelp Portalを活用して下さい。
一言でいうと（なにもの？）
「OData」は、インターネット通信で一般的に使用される通信規格であり、httpベースでデータをやり取りするための規格です。この仕組みを利用してAPIの通信を行うことで、システム間でデータのやり取りが可能になります。
ポイントはSAP社固有の規格ではなく、複数のIT企業によって標準化された規格であること、および後続で説明しますが、現状のWEBシステム開発で使われている技術要素をベースにしており、汎用性が高いことです。また、基幹システムで求められるような高度なデータのやり取りを実現するための仕様を保持しています。
一言でいうと（なにがすごいの？）
汎用的な技術であるため、様々なシステムや規格の統一を考慮することなく自由にやり取りができます。そのため、S/4HANAなどのシステムとのやり取りのハードルが極めて低くなりました。また、きわめて多くの情報をAPIに含めることが可能です。
ODataの歴史
マイクロソフトによって開発されました。マイクロソフトはプロトコルの標準化を目指し、その開発と維持を一部他の主要なテクノロジー企業（IBM, SAP等）と行いました。現在は、OASIS OData Technical Committeeという非営利組織によって運用されています。
従来のしくみと何が違うのか？
従来、SAPとデータをやり取りする場合は、ファイルベースのやり取りを行うか、SAP社が定めた規格であるRFCやIDocに従う必要がありました。そのため、やり取りのためには、規格に合わせたアダプターのようなものが必要であり、あらかじめ準備された製品でなければデータをやり取りすることができませんでした。（SOAPというODataに近い方式でデータをやり取りする方法もありますが、ここでは省略します。）
これに対して、「OData」は開かれた汎用性の高い規格です。よって、（ネットワーク的な問題やセキュリティ的な問題を一旦置いておくとすると）、WEBアプリやMobileアプリなどから、S/4HANAのデータを比較的簡単に取得したり、更新したりすることができます。
どうやって使うの？
S/4HANAにおいて、「OData」を利用するためには大きくわけて3つの方法があります。
標準API （Whitelisted API）の利用
SAP社が多くの標準APIを準備しておりそれを活用します。利用できるAPIのリストは「SAP Business Accelerator Hub（旧SAP Business API Hub）」に記載されています。「T-code:/n/iwfnd/maint_service」にてAPIの有効化が可能です。
CDS ViewのOData化
「CDS View｣の基本的なことまとめ」にも記載しましたが、「CDS View」はOData APIとして公開可能です。注意事項としては、この場合にできることは「Read」に限定されます。この場合も利用機能は、「T-code:/n/iwfnd/maint_service」となります。
OData APIの作り込み
ABAPをベースにしたOData APIの作り込みやBAPIや汎用MをOData APIとして公開することができます。「RAP（ABAP RESTful Application Programming Model）」を使用して標準のAPIと同じようなアーキテクチャでAPIを作成する方法や、「T-code: SEGW」を使用して旧来のABAPプログラム（BAPIや汎用M）をOData化する方法があります。
何がすごいの？
汎用性の高さは前述で説明しましたが、それ意外にもODataのすごさがいくつかあります。それを実際の事例を元にしながら説明していきます。
SQLの様な操作ができる
通常、APIを使用して情報をやり取りする場合、その内容は固定されています。しかし、S/4HANAのマスタやトランザクションは、1つのオブジェクトに対して多くの項目を保持しているため、やり取りする情報が多くなります。そのため、自由にキー項目や取得対象の項目を選択できる（SQLのような操作ができる）APIの汎用性が高くなります。ODataでは、これを実現しています。
（より細かく知りたい方は、BTPのスペシャリストであられる@tamiさんが書かれている「【SAPUI5】OData(3) ODataのQuery optionsを使ってみる」等をご確認下さい。）
品目マスタを取り扱うAPIである「Product Master」を例に、細かな点を解説していきます。
S/4HANAに触れた方ならすぐにわかると思いますが、品目マスタを取り扱うと言っても、品目マスタには様々なビューのデータが存在しています。基本ビュー単位のデータもあれば、プラント単位のデータも存在しています。そのため、品目を取り扱う「Product Master」には様々な種類の呼び方が存在します。
例えば、/A_Product('{Product}')は品目コードをキーにして品目情報を取得します。また、/A_Product('{Product}')/to_Descriptionは品目コードをキーにして品目テキストを取得します。さらに、/A_ProductPlant(Product='{Product}',Plant='{Plant}')は品目コードとプランをキーにしてプラントレベルの情報を取得するといった具体的な使い方があります。
詳しい解説の前に、少しOData APIの構造についても補足します。（例として↑にリンクを記載した「SAP Business Accelerator Hub」のAPIのテスト機能「Try Out」の情報を元に記載します）
APIは、そのAPIに共通な部分である「service root URL」と呼ばれるものと、その条件を示す「resource path」、さらにSQLのような条件を指定する「query options」に分類されます。
それでは実際のAPIの構造をみていきましょう。
「SAP Business Accelerator Hub」の「Product Master」における「service root URL」はhttps://sandbox.api.sap.com/s4hanacloud/sap/opu/odata/sap/API_PRODUCT_SRVです。
上の呼び方毎に「resource path」を追加します。基本情報を品目コード単位で取得したい場合は[https://sandbox.api.sap.com/s4hanacloud/sap/opu/odata/sap/API_PRODUCT_SRV/A_Product('Product')]となります。
Productの箇所は実際の品目コードで置き換えます。（このサイトでは21というコードが最初に定義されているので、それを今後は使います。）
試しにAPIを実行すると、下記のスクリーンショットのように品目マスタの基本ビューレベルの情報が返されます。
今回は情報取得のための「GET」を使いましたが、新規作成の「POST」、情報更新のための「PATCH」も同様です。
情報毎に「resource path」を使用してやり取りする情報の種類を制御する方法について説明しましたが、さらに具体的に情報を選択したい場合もあるかと思います。（例えば、基本ビューレベルの情報は不要など）そのような場合には、「query options」を使用します。これにより、取得する情報の項目を調整することができます。
例えば、品目コードと品目タイプの情報だけを受け取るケースを仮定します。その場合は「query options」を追加し(https://sandbox.api.sap.com/s4hanacloud/sap/opu/odata/sap/API_PRODUCT_SRV/A_Product('21')?$select=Product%2CProductType)とします。
これにより下記のように一部のデータの抽出が実施されます。
このようなかたちで、ODataはSQLの様なデータのやりとり実現します。
アプリケーションの機能と統合しアプリ開発を促進する
ODataは非常の多くの情報を保持することが可能です。これらをアプリケーション側（ODataの利用側）でフル活用することによって、アプリ開発を促進します。
BTPデータ連携基盤製品である「Integration Suite」を例に見ていきましょう。
「Integration Suite」はデータ連携のソリューションのため、システムからデータを取得し、別のシステムにデータを送信します。
この場合のデータ取得の実装では、取得元の情報を調査し、取得すべき情報をデータ連携基盤側に定義します。そして、次に取得元のデータマッピングを実施するという手順になります。取得元がAPIだったりすると、その呼び出しをコーディングしたりします。
基本的には、「調査→データ定義→マッピング実装」という流れになるのですが、ODataを取り扱える「Integration Suite」の場合は一括で実装できます。
「Integration Suite」にて、「OData API」をデータ取得元として利用するケースを想定します。
このケースにおいて、データ取得元の「OData API」を指定します。
するとAPIの取得情報の候補が表示されます。
ここでのポイントは、「OData API」にアクセスした際に、API経由で取得できる情報を引っ張ってきて、候補値として表示していることです。これならば、事前にAPIの項目を調査する必要もなく、必要な項目にチェックして保存すれば、データ定義やマッピング実装は不要です。このような操作は通常のシンプルなhttp通信のAPIでは実現できず、ODataを取り扱える基盤で、ODataを用いてやり取りをしているから実現できることになります。
いまいちピントこない方はこちらのTutorialをやってみるのも良いかと思います。
これは一例なのですが、SAP社はこのような仕組みを前提として、ノーコードであったり、プロコードの生産性を上げるようなODataの特性を活かしたサービスを構築しています。「Fiori Elements」なども、その一例になります。
最後に
「OData」はS/4HANAやBTPを利用した開発のコアになる技術要素なので、しっかりと理解することが必要です。
コンサルやSEの方は「OData」を活用し、エンジニアの方は「OData」の特性を損なわない開発を心がけていただければと思います。