1

OData
Everything that you need to know

Anubhav Pandey
February 8, 2016 4 minute read
 2

Contents
OData – Everything that you need to know (Part 1) ......................................................................................................... 3
Introduction .................................................................................................................................................................. 3
How Internet Works? .................................................................................................................................................... 3
URI and URL are not the same thing ............................................................................................................................. 4
Defining the Request and Response ............................................................................................................................. 4
OData – Everything that you need to know (Part 2) ......................................................................................................... 6
What is REST?................................................................................................................................................................ 6
The Six Constraints ........................................................................................................................................................ 7
OData – Everything that you need to know (Part 3) ......................................................................................................... 8
What is OData? ............................................................................................................................................................. 8
Advantages with OData ................................................................................................................................................ 9
ODBC for the Web......................................................................................................................................................... 9
OData – Everything that you need to know (Part 4) ....................................................................................................... 11
SAP Netweaver Gateway – An Introduction ............................................................................................................... 11
SAP Annotation with Odata ........................................................................................................................................ 13
OData – Everything that you need to know (Part 5) ....................................................................................................... 15
1. Hub Deployment: Development in the Backend system ........................................................................................ 15
2. Hub Deployment: Development in the Hub ........................................................................................................... 16
3. Embedded Deployment .......................................................................................................................................... 17
OData – Everything that you need to know (Part 6) ....................................................................................................... 18
OData – Everything that you need to know (Part 7) ....................................................................................................... 22
OData – Everything that you need to know (Part 8) ....................................................................................................... 23
OData – Everything that you need to know (Part 9) ....................................................................................................... 24
OData – Everything that you need to know (Part 10)..................................................................................................... 25
 3

OData – Everything that you need to know (Part 1)

Introduction
This series of blogs is an attempt to provide a comprehensive guide to OData and how it is consumed in
the SAP world. There has been a lot of content on the Internet explaining what is OData, how the services
and published and how to consume which is scattered and assumes that the reader has clarity already on
some very important fundamentals. However, there are so many aspects which deserves more than just a
mention. In this blog, we will try and cover the topic 360 degrees.

We start with the very basics of HTTP and then gradually build on to OData and finally conclude with a
detailed end-to-end exercise on how to create an OData service and how to consume it.

How Internet Works?

It might sound to be an unrelated topic when the focus is on OData. HTTP is the common thread between
the two. HTTP is the underlying protocol on which OData is based and also one of the most common
language which is spoken on the Internet.

You would typically need a Web Browser, address of the document you want to read or the URL (Uniform
Resource Locator), a Web Server running at the system where the document is located.

Web Browser is a software which is responsible to retrieving and presenting resources on the web. Web
Browser parses the HTML response received from the Web and prepares a DOM Tree. DOM stands for
Document Object Model and it is a language-independent convention of representing objects in HTML.
Web Browser acts as an interface between you and the World Wide Web.

You can request for a document located somewhere on this planet by providing its address via the browser
which sends HTTP requests to the web server. The Web server then sends back HTTP response that is
parsed by the Web Browser for you to view the document on your machine.

HTTP stands for Hyper Text Transfer Protocol and as the name suggest it defines the semantics of what
the browser and the web server can communicate to each other. The how part of the communication or the
byte by byte transfer of the data packets across the network is not HTTP but it is done via TCP/IP
protocols.
 4

An important component in the story so far is also the Web Server. In a nutshell, Web Server is a server
program which sits on a physical server and waits for requests from a client. Whenever a request is
received the Web Server prepares a response and sends it back to the client using HTTP protocol. It is
important to note that HTTP is not the only but, by far most commonly used protocol and that the client here
can be a browser or any other software that communicates in HTTP.

Let us now try and put up a formal definition to the HTTP.

“HTTP is based on a Client-Server architecture style and it uses a stateless request/response protocol to
communicate between the client and the web server. The HTTP protocol helps define what requests can be
sent across by the client and response sent by web server. The communication of data over the network is
however done using on TCP/IP protocol”.

It is evident that HTTP is based on client server architecture from our description till now, browser being the
client which sends HTTP request and web server which sends the response back to the browser. But, why
stateless?

Every single HTTP request that is received by the web server is forgotten after a response has been sent
across. Web servers do not process an HTTP request by remembering the previous request.

URI and URL are not the same thing

We mentioned a while back that you need to know the URL of the document you wish to view in your
browser. Can I not mention a URI as an address to get the document on the web? Let us quickly
understand the difference between the two.

URI or the Uniform Resource Identifier can be classified as a name, locator or both that identifies a
resource uniquely.

URL (Uniform Resource Locator) is actually a subset of URI that not only identifies a resource uniquely but
also provide means of locating the resource.

Defining the Request and Response

HTTP requests are sent with one of the defined Request Method that indicates the action to be taken on
the resource. Following are the two most commonly used methods:

GET

This is used to retrieve information of the resource from the server.

POST

This method is usedto send data to the server.

 5

For example, if you enter a text string on Google search page and press enter, it will generate an HTTP
Request with GET method in the background. On the other hand, if you provide your username/password
on a Login page and press enter a POST HTTP request will be send to the server.

HTTP Response from the Web Server comes with data and the status code. The status code provides a
context to the response. For instance, if you do not correctly provide the resource location, the web browser
will send you a response which you are not expecting. Along with the data response comes the status
code, known universally in the HTTP world, that explains to the user what could be the reason for an
unexpected response.

HTTP codes are 3 digit integers.

Code and Description

1xx: Informational

It means the request has been received and the process is continuing.

2xx: Success

It means the action was successfully received, understood, and accepted.

3xx: Redirection

It means further action must be taken in order to complete the request.

4xx: Client Error

It means the request contains incorrect syntax or cannot be fulfilled.

5xx: Server Error

It means the server failed to fulfill an apparently valid request.

For example, status code 400 means Bad Request. It means that the server did not understand the
request.

OData allow creation and consumption of RESTful APIs. In the next blog, I will cover what are RESTful
APIs as the next stepping stone towards understanding OData
 6

OData – Everything that you need to know (Part 2)

In my previous blog, I discussed about how Internet works and gave an introduction to what is HTTP and
the difference between URL and URI. IN this blog we will discuss REST based APIs.

Previous Blogs in the series:

OData – Everything that you need to know (Part 1)

What is REST?
REST or REpresentational State Transfer is an architectural style that uses simple and lightweight
mechanism for inter-machine communication. It is an alternative to the RPC (Remote Procedure Calls) and
Web Services.

REST is resource based unlike RPC or SOAP which are action based. In SOAP you will have a request to
get material data whereas in REST, material will be identified as a resource using URI and then use HTTP
verbs to determine which operation shall be performed on the resource. It is important to note here that it is
possible to have multiple URIs pointing to the same resource.

Representation of the resource is the not the resource itself but only a representation.

The term representation is how the resources are manipulated in a rest based architecture

Representations depicts parts of the resource state which are transferred between client and server in
mostly JSON or XML format. Client will typically have enough information to manipulate the resource on the
server. For example, if Person is modelled as a resource and there is a service to get contact information
of a person then the representation that you will get of that Person would be Name, Address and Phone
details in JSON or XML format.
 7

The Six Constraints

Following are the six constraints defined which are attributes of a RESTful API.

1. Uniform Interface

Uniform Interface is fundamental to the design of any REST based service. The uniform interface simplifies
and decouples the architecture, which enables each part to evolve independently.

What that means is that it should be possible to identify the individual resource in the request, for example
using URI. Once the Client has a representation of the Resource then, it should have enough information to
update or delete the resource. And that the Client should not assume that any particular action is available
on a resource beyond those described in the representation received from the server previously.

2. Stateless

The Server should not contain any Client state. It is possible to process a request only if they are self-
descriptive and that the request should have enough context to act upon. For example, if the Person
resource address needs to be updated then it is required that the Client pass on the particular Person
resource details in the request for which it has received the representation from the Server in the previous
request. If the state has to be maintained, it should be at the Client side.

3. Client-Server

We have already established this constraint that the RESTful architecture is a Client-Server architecture.
Resource representations are transferred between client and server. We should always keep at the back of
our minds that the Client of RESTful APIs will not have direct connects to the Resources.

4. Cacheable

Another constraint on a RESTful API is that any response that is coming from the Sever should be
cacheable on the Client side. Caching could be implicit, explicit or negotiable. Implicit and Explicit caching
is self-explanatory whereas Negotiable caching means that the Server and Client agree on how long a
representation can be cached on the Client.

5. Layered System

The constraint of Layered System is closely related to the above two constraints of Client-Server and
Cacheable. It suggests that the Client of a RESTful API should not assume that there will be a direct
connection between the client and the server. There could be multiple layers of software or/and hardware in
between the two. The Client need not know whom exactly it is talking to and whether a response is coming
from the server or is accessed from a local cache. This improves scalability.

6. Code on Demand

This constrains suggests that it should be possible that a Server can extend a Client temporarily. It means
that Server can transfer logic to the client as representation to be executed at the client.

This is the only optional constraint.

A RESTful service needs to adhere to all of the above mentioned constraints (except Code on Demand) to
be called as a RESTful API.Having covered HTTP and REST based services we will cover OData in my
next blog.
 8

OData – Everything that you need to know (Part 3)

In my previous two blogs, I have covered the basics of how Internet works, HTTP and what are REST
based services. So, now that we have laid the foundation we will start with understanding what is OData
protocol.

Previous Blogs in the series:

OData – Everything that you need to know (Part 1)

OData – Everything that you need to know (Part 2)

What is OData?
“Open Data Protocol (OData) is an open data access protocol from Microsoft that allows the creation and
consumption of query-able and interoperable RESTful APIs in a simple and standard way”.

The protocol enables the Clients to publish and manipulate the resource identified by URIs and defined in a
data model using simple HTTP messages.

To put it in simple words, OData is an open source to exchange data over the Internet. Server hosts the
data and clients can call this service to retrieve the resources and manipulate them. Servers expose one or
more endpoints which are services that refers to the resources. Clients need to know this server side
endpoints to call the service to query or manipulate the data. The protocol is HTTP based and designed
with RESTful mindset which means it follows the constraints to be called as a RESTful service.

Since the protocol is HTTP based, any programming language with HTTP stack can be used to consume
OData services. Existing Client side libraries can be used to transform the JSON or ATOM payloads from
the server into objects making programming simple. On the other hand, many libraries exists on the Server
side to generate the payloads in ATOM or JSON from the existing data.

It is important to note that both Client side and Server side development can be in completely different
programming languages till the time both are able to communicate via HTTP.

Clients consume the service to query and manipulate the data from OData Services and are also called as
Consumers of OData Service.

Similarly, Servers that expose the OData services via endpoints are known as Producers of Odata
services.

So, we now know that in OData protocol, the resources are exposed in two formats; XML based Atom and
JSON.
 9

A brief description of what is Atom ad JSON.

Atom is a combination of two protocols, Atom Syndication and Atom Publishing protocol. The Atom
Syndication Format is an XML language used for web feeds, while the Atom Publishing Protocol (AtomPub
or APP) is a simple HTTP-based protocol for creating and updating web resources.

JSON stands for JavaScript Object Notation is a light weight data-interchange format. JSON is self-
descriptive and easy to use and is completely language-independent.

Advantages with OData

There is a lot of data on the web today but lot of it is locked up in different specific applications or formats
and different to access from outside. Many Organizations have now started exposing data using REST
based services however, it is difficult to write applications which works with multiple data sources as each
provider will expose the data in a slightly different way. OData service producer can expose its service
along with metadata which contains the semantics for consumption. OData exploits the common formats
like XML, Atom and JSON for communication which are commonly understood. Clients can now
understand these OData services using generic tools and can combine information from multiple data
sources.

Exposing your data with OData services comes with multifold advantages. For example, as we mentioned
earlier, as a consumer, you need not worry about the programming language used by producer as long as
the services are exposed as OData service.

ODBC for the Web

ODBC (Open Database Connectivity) is a standard API to access the database management systems
independent of the database management systems or operating systems. ODBC manages this by adding
drivers between the Application layer and the DBMS to translate the queries fired by application into
instructions which DBMS can understand.

OData has similarity with the ODBC in a sense that here, OData provides the middleware between
producers and consumers to communicate data. There is a uniform way to consume data and is
independent of the producer much like ODBC. The fact that OData is based on HTTP RESTful services
makes it the ODBC for the Web!
 10

In my next blog, I will talk about SAP Netweaver Gateway, SAP OData Channel and the main elements of
an OData service
 11

OData – Everything that you need to know (Part 4)

In my previous three blogs, I have covered the basic concepts of HTTP, what are RESTful APIs and their
constraints and finally what are Odata service and that they are RESTful services built that uses simple
HTTP to communicate between Client and Server.

Previous Blogs in the series:

OData – Everything that you need to know (Part 1)

OData – Everything that you need to know (Part 2)

OData – Everything that you need to know (Part 3)

OData provides a way to expose the data in a uniform way. Although, Microsoft initially came up with the
specification of Odata but, there is a lot of industry support behind OData like, Netflix, eBay, IBM. SAP
being one of them. In this blog, we will discuss SAP Netweaver Gateway and how along with OData SAP
can cater to multiple channels with a unified data model. In future blogs, we will see how to create OData
service in a real-world scenario and explain various aspects of OData during the course.

SAP Netweaver Gateway – An Introduction

For Business Users, ease of access has become critical with the advent of various mobile devices that
support end-to-end scenarios and also provides a rich user experience. There is a need to better integrate
data, reduce complexity and improve productivity. This has been a challenge for the Developer community
to be able to support multiple platforms to consume enterprise data more easily than ever before and on
the other hand provide solutions that are scalable and with low TCO (Total Cost of Ownership).

Point-to-point solutions are not the right way as it has lot of drawbacks including duplication of development
effort, increased cost, complex landscape, poor scalability and difficult to maintain.

SAP Netweaver Gateway is a technology that has the answer to this. It can seamlessly connect devices,
platforms and environments to SAP Enterprise Data using the OData services. SAP Netweaver Gateway
offers connectivity to SAP Business data using any programming language and without the need of strong
SAP development knowledge.
 12

SAP Netweaver Gateway comes with design-time tools to facilitate modeling OData services for
consumption. These tools improve user experience and provide automatic connectivity to the SAP backend
that reduces development efforts and improves productivity.

SAP Netweaver Gateway sits on top of the existing SAP Backend infrastructure. There are set of add-on
components that needs to be installed on a SAP Backend system to enable SAP Netweaver Gateway
services. It is this architecture that enables consumption of SAP data by variety of interfaces such as BAPIs
and RFCs
 13

SAP Netweaver Gateway Service Builder tools is SAP GUI based modeler to create and publish Odata
services using transaction SEGW.

There is also an Eclipse-based Odata Modeler tool available. It provides an easier way to model the service
that is a much easier way to develop if you are not too familiar with ABAP programming language. The
models can be conveniently created here are exported to the development environment for the Gateway.

SAP Annotation with Odata

SAP has leveraged the extensibility feature provided by Atom Publishing protocol to add SAP specific
annotations. AtomPub allows you to add your own markups in the service document. SAP adds
annotations from the ABAP Data Dictionary, for example, labels to the documents which can then be
consumed by the front end application without having to worry about translations in this case.
 14

In my next blog, I will focus on the various deployment options for SAP Netweaver Gateway.
 15

OData – Everything that you need to know (Part 5)

In my previous blog, we introduced you to the SAP Netweaver Gateway and how it leverages the Odata
protocol liberates SAP Business Data for consumption on virtually any platform, environment or device.

Previous Blogs in the series:

OData – Everything that you need to know (Part 1)

OData – Everything that you need to know (Part 2)

OData – Everything that you need to know (Part 3)

OData – Everything that you need to know (Part 4)

In this blog we will see the various deployment options for SAP Netweaver Gateway and their pros and
cons.

Before getting into the various deployment options with SAP Netweaver Gateway, it is important to
understand the different components.

SAP Netweaver Gateway prior to NW 7.4 had three add-ons namely GW_CORE, IN_FND and IW_BEP.
While the first two components were required for Gateway server functionalities, IW_BEP was used for
Gateway backend functionalities.

From the onset of NW 7.0 release, all the three components are bundle into a single component
SAP_GWFND or Gateway Foundation.

There are three possible deployment options to pick from and we will discuss each one of them.

1. Hub Deployment: Development in the Backend system

In this deployment strategy, the SAP Netweaver Gateway is installed on separate SAP machine referred to
as Gateway Hub. The OData services are registered and exposed from the Gateway Hub but are
developed in the SAP backend system. If SAP Business Suite backend systems are running on NW
release prior to 7.4 then component IW_BEP should be installed. For systems running on NW7.4 onwards
the SAP_GWFND component contains both Gateway server and backend functionalities as mentioned
before.

Advantages of this deployment options are as follows:

 There is only a single access point of access to the SAP Backed systems. No direct access from
outside world provides enhanced security.

 Gateway Hub can be a system running on newer release NW 7.31 or NW 7.4 with Backed system
running on lower release is perfectly acceptable.
o Gateway on newer release would mean support for SAP UI5.
o Supports added authentication features.
 Direct access to metadata (DDIC) and business data for OData Modeling by backend systems.
 16

2. Hub Deployment: Development in the Hub

Hub Deployment with development in the Gateway Hub is an option where just like the previous option,
there is a dedicated Gateway Hub as a separate system from the backend system. Since, all the
development related to SAP Netweaver Gateway takes place in the Gateway Hub, backend not necessary
should have any Gateway components installed. It is a feasible option if you don’t want to do any kind of
developments in the backend system and leverage what is already available.

There are a few disadvantages though:

 Access to the data source for Odata service development is only limited to existing BAPIs and
RFCs.

 There will be no direct access to the backed dictionary objects to the Gateway Hub where the Odata
services are modeled. The access is limited to only to remote access.

 Having a landscape with dedicated system as Gateway Hub involves additional costs as compared
an embedded deployment option. This is true for the above deployment option as well.
 17

3. Embedded Deployment
In the Embedded Deployment option, the SAP Netweaver gateway components are installed as add-ons on
the SAP backed system itself. Both the Odata modeling and the exposing of the services is done from the
backend system. This deployment strategy saves cost as there is no dedicated Gateway Hub. Also, the
runtime overhead due to remote calls in the above two deployment options is reduced.

Disadvantages:

 If there are multiple SAP Business Suite Backed systems in the landscape then, each system will
have to have its own installation and configuration of Netweaver Gateway components.

 Upgrade of backed systems will follow a different cycle than that of Netweaver Gateway.

 Additional security measures needed as there is no single access point from the backend system to
the consumers.

In the next blog, we will explain the case study that will be the basis of our future blogs related to end-to-
end steps of producing and consuming OData services.
 18

OData – Everything that you need to know (Part 6)

In my previous blogs, we discussed the basics of HTTP, REST and finally Odata with context of SAP
Netweaver Gateway. We also saw what are the possible deployment options available. In short we have
laid the foundation for what is coming in the following blogs, i.e. end-to-end guide of creating, publishing
and consuming Odata services.

Previous Blogs in the series:

OData – Everything that you need to know (Part 1)

OData – Everything that you need to know (Part 2)

OData – Everything that you need to know (Part 3)

OData – Everything that you need to know (Part 4)

OData – Everything that you need to know (Part 5)

In this blog, we will define the problem statement and give you a glimpse of what we are trying to build as a
small application to showcase the power of OData. We will also build a simple Fiori-like app as a frontend
consumer. Knowledge of Fiori is not at all a must here. As I mentioned earlier, during the course of the end-
to-end exercise we will also explain various artifacts of OData.

In the next few blogs we will be creating a simple Master-Detail Fiori-like app based on SAP Flight Model
example. . We will leverage the existing backend developments to expose the data as OData service that
will be consumed by frontend. Future blogs will follow the Embedded deployment environment but, most of
the steps we do here is applicable to the other two deployments. It is just a matter of where you do the
modeling.

Here, is a link to the Overview of Fiori in case you wish to know more.

The app we are going to develop is a very simple app based on SFLIGHT example to check seat
availability and add new flight tours.

Master-detail app will have the left navigation panel will feature the list of Airlines along with codes. The
detail section of the app will contain the tabular list of different flights corresponding Airline. User will be
allowed to select a flight and check for availability for a given date and class. App will also allow user to add
new flights for a specific Airline and dates on which the flights are scheduled. We will showcase the
CRUDQ operations along with navigations from master to object view and function imports during the
course of this app.

Data Model for SFLIGHT that we will use.

 19

UI Mock-ups for the Sflight App:

Master-Detail view with Airlines information on left navigation panel and various flights operating for a
specific airlines on the details section.
 20

Check Availability sceanrio

Information on seats availability

 21

Adding a new Flight tour for future dates.

In my next blog, I will cover the Service Document, Service Document Metadata and Entity Data Model
concepts and then we are ready to get into the system.

Next Blog: OData – Everything that you need to know (Part 7)

 22

OData – Everything that you need to know (Part 7)

In my last blog, I had given a breif overview of the data model for the OData service that we will build in the
next segments. In this blog, I am posting a video explaining the structure of an OData service, OData Meta
Model, browsing through an existing OData service in the system and explaining the URI convention used
for consuming OData services.

Watch video: https://youtu.be/FrNcnTaGPpM

Watch video: https://youtu.be/LiL8dmWYwZg

 23

OData – Everything that you need to know (Part 8)

In Part 7 of this blog series, we saw the structure of an OData service in the system and discussed
the OData URI convention model.

In this blog, we will create the OData model for the flight example.

Watch video: https://youtu.be/MpJ8SjaLhJM

Watch video: https://youtu.be/sCXr5sgh0zw

 24

OData – Everything that you need to know (Part 9)

In the previous blog, I created the data model of the OData service for the Flight example. In this
segment I will explain he OData Channel, model provider and data provider classes and also
implement the service.

Watch video: https://youtu.be/9-ikXRzktBs

 25

OData – Everything that you need to know (Part 10)

In previous few blogs, we saw how the structure of an OData service, service document,
metadata, URI convention and also created an OData service from scratch.

In this blog, I will simply show you the steps required to register the service and then it is ready for
consumption.

Watch video: https://youtu.be/zA5VvNUhhS0