Introduction to SAP Gateway and OData

Introduction to OData and SAP NetWeaver Gateway

© 2014 SAP AG or an SAP affiliate company. All rights reserved. 2
Disclaimer
This presentation outlines our general product direction and should not be relied on in making a
purchase decision. This presentation is not subject to your license agreement or any other agreement
with SAP. SAP has no obligation to pursue any course of business outlined in this presentation or to
develop or release any functionality mentioned in this presentation. This presentation and SAP's
strategy and possible future developments are subject to change and may be changed by SAP at any
time for any reason without notice. This document is provided without a warranty of any kind, either
express or implied, including but not limited to, the implied warranties of merchantability, fitness for a
particular purpose, or non-infringement. SAP assumes no responsibility for errors or omissions in this
document, except if such damages were caused by SAP intentionally or grossly negligent.

Agenda
Introduction to SAP NetWeaver Gateway
 A Solution for the Multi-Channel Business
 Understanding Atom and OData
 OData Entity Data Model
 The Starting Point for Consuming an OData Service
 Requesting Multiple Entries from an OData Collection
 Consuming Single Entries from an OData Service
 Development Approaches for Building an OData Service
 Creating an OData Service Using the Gateway Service Builder

A Solution for the Multi-Channel Business
Introduction to SAP NetWeaver Gateway

SRM SCM ERPPLMCRM
Moving Away From Point-to-point Solutions
Browser Based
Applications
Mobile
Devices
Enterprise
Software
Consumer
Devices
SAP Business Suite
Point-to-point solutions often lead both to a duplication of
development and administrative effort.
– The same application is developed for multiple mobile
operating systems
– Different app on-boarding processes required for
different mobile devices
This then leads to:
– Poor scalability
– Increased system landscape complexity
– Increased administration effort
Cloud

OData
SRM SCM ERPPLMCRM
Browser Based
Applications
Mobile
Devices
Enterprise
Software
Consumer
DevicesCloud
SAP Business Suite
SMP3
Duet
Enterprise
 Any environment, any platform, any experience
 Optimized for user-interaction scenarios
 Suitable for any SAP Business Suite version
 No internal SAP knowledge required for consumption of
an OData service
SAP NetWeaver Gateway
One Data Model  One API  Multiple End-user Experiences

Understanding Atom and OData

What is the Open Data Protocol (OData)?
SAP Annotations
OData
Atom
Syndication
XML
HTTP(S)
It is an extension of the Atom Publishing and Atom
Syndication standards and offers a standardised
implementation of a RESTful API.
OData provides database-like access to server-side
resources; hence, it has been described as:
“ODBC for the Web”
Atom
Publishing
JSON
OData is an open standard, originally developed by
Microsoft, but now administered by the OASIS Organisation.

What is Atom? 1/2
Atom is pair of standards
Atom Syndication Format
- A read-only, XML based protocol for the syndication of Web-
content. Originally released in Dec 2005 as an improvement to
RSS (Rich Site Summary)
- Web-content is aggregated into table-like structures called “Feeds”
- Each row in a feed is called an “Entry”
SAP Annotations
OData
XML
HTTP(S)
Atom
Publishing
JSONAtom
Syndication

What is Atom? 2/2
Atom is pair of standards
Atom Syndication Format
- A read-only, XML based protocol for the syndication of Web-
content. Originally released in Dec 2005 as an improvement to
RSS (Rich Site Summary)
- Web-content is aggregated into table-like structures called “Feeds”
- Each row in a feed is called an “Entry”
Atom Publishing Format
- An HTTP-based extension of Atom Syndication that allows
documents to be manipulated (created, updated & deleted)
SAP Annotations
OData
XML
HTTP(S)
JSONAtom
Syndication
Atom
Publishing

What Does OData Add to Atom?
The problem with the Atom Publishing Format is that it
does not specify how data should be encoded within a
Feed.
OData therefore extends Atom by providing a metadata
description of the message.
OData provides definitions for:
- Simple Types
- Complex Types
- Associations between entries
- Navigation Paths between entries
- Custom behaviour beyond the standard CRUD
operations
SAP Annotations
XML
HTTP(S)
JSONAtom
Syndication
Atom
Publishing
OData

What Does OData Add to Atom?
OData is also extensible.
This allows SAP to supplement the data types used by
OData with extra information from the ABAP Data
Dictionary.
Supplementary information includes:
- Linking currency code and currency value fields
- Providing different length text descriptions
- etc..
XML
HTTP(S)
JSONAtom
Syndication
Atom
Publishing
OData
SAP Annotations

Output Formats Supported by OData
OData messages can be transferred either in XML or JSON format.
XMLJSON

The Principles of REST as Implemented in HTTP
The REST design concept states that a client should be able to manipulate the business data held in a
server (such data is known generically as a “server-side resource”).
HTTP implements this design concept by allowing you to send a request using different HTTP Methods.
The name of the method tells the server what type of operation is to be performed.
HTTP Method REST Operation
POST Create a new resource
GET Retrieve 0..n existing resources
PUT Update an existing resource
DELETE Delete an existing resource

The Principles of REST as Implemented in HTTP
The REST design concept states that a client should be able to manipulate the business data held in a
server (such data is known generically as a “server-side resource”).
HTTP implements this design concept by allowing you to send a request using different HTTP Methods.
The name of the method tells the server what type of operation is to be performed.
HTTP Method REST Operation
POST Create a new resource
GET Retrieve 0..n existing resources
PUT Update an existing resource
DELETE Delete an existing resource
The names of the REST operations give rise to the acronym CRUD

OData Entity Data Model

Entity Data Model – Overview
An Entity Data Model (EDM) is the starting point for building an OData service. An EDM describes
both the data structures and their inter-relationship used in a business scenario.
1
*
1
* 1 *

Entity Data Model – Entity Types
An Entity Type is the basic building block of an Entity Data Model. It is a data structure used to
define one part of a business object.* In ABAP terms, and Entity Type is like a Dictionary Structure.
* Or possibly the entire business object if its structure is very simple

Entity Data Model – Entity Type Key Field(s)
Every Entity Type must have at least one of its fields nominated as a key field.
It is invalid to have an Entity Type with zero key fields.

Entity Data Model – Associations 1/2
In order to describe the relationships between entity types, you can declare Associations.
In database terms, this is the same as creating a foreign key relationship between two tables.
For one flight… there are many bookings
From one airport…
You can take many flights
1
* 1 *

1
*
1
* 1 *
Entity Data Model – Associations 2/2
Associations can also be reflexive; that is, an instance of one entity type can be related to other
instances of the same entity type.
direct flights can be taken
to many other airports
From one airport…

1
*
1
* 1 *
Entity Data Model – Navigation Properties (or Paths)
Since associations are just design time declarations, in order for them to become usable at runtime
they must be implemented as Navigation Properties (or Paths)*
* The terminology is flexible here
…is implemented as the
DepartingFlights
Navigation Path
The association between
the Airport and Flight
entity types…

1
*
1
* 1 *
The reflexive Airport
association…
…is implemented
as the AirportsTo
Navigation Path

1
*
1
* 1 *
…is implemented
as the Bookings
Navigation Path
The association
between the Flight and
Booking entity types…

Entity Data Model – Entity Sets
Multiple instances of an entity type are aggregated to form a table-like structure known as an Entity Set
(also known as a "collection")

The Starting Point for Consuming an OData Service

OData Service Document – The Starting Point For Consumption
After an Entity Data Model has been implemented as an OData Service, the Gateway system
will provide you with a URL to access this service. This URL is known as the OData Service’s
Base URL and acts as the starting point for consumption.
When this URL is requested, the Gateway service responds with the Service Document.
This is the highest-level description of the resources exposed by that OData service.
<app:service xml:lang="en" xml:base="http://<some_server>:<some_port>/sap/opu/odata/IWFND/RMTSAMPLEFLIGHT/">
<app:workspace>
<atom:title type="text">Data</atom:title>
<app:collection sap:pageable="false" sap:content-version="1" href="BookingCollection">
<atom:title type="text">BookingCollection</atom:title>
<sap:member-title>Flight Booking</sap:member-title>
</app:collection>
<app:collection sap:creatable="false" sap:deletable="false" sap:content-version="1" href="CarrierCollection">
<atom:title type="text">CarrierCollection</atom:title>
<sap:member-title>Carrier</sap:member-title>
</app:collection>
<app:collection sap:label="Travel Agencies" sap:searchable="true" sap:content-version="1" href="TravelagencyCollection">
<atom:title type="text">Travel Agencies</atom:title>
<gp:collectionLayout display-order="0010" top-level="true"/>
<sap:member-title>Travel Agency</sap:member-title>
...snip...

What's the Entity Data Model behind an OData Service?
In order to discover the Entity Data Model behind an OData service, you can add the suffix
$metadata to the Base URL. This will return an XML representation of the Entity Data Model.
The representing an Entity Data Model in JSON format will not be available until OData V4*
E.G. Issuing http://<server>:<port>/sap/opu/odata/sap/RMTSAMPLEFLIGHT/$metadata
Will return an <edmx> document, something like this:
<edmx:Edmx Version="1.0">
<edmx:DataServices m:DataServiceVersion="2.0">
<Schema Namespace="RMTSAMPLEFLIGHT" xml:lang="en">
<EntityType Name="Subscription" sap:semantics="subscriptions" sap:content-version="1">
<Key>
<PropertyRef Name="ID"/>
</Key>
<Property Name="ID" Type="Edm.String" Nullable="false" MaxLength="32" sap:label="Sub. ID" sap:creatable="false"
sap:updatable="false" sap:filterable="false"/>
<Property Name="user" Type="Edm.String" MaxLength="12" m:FC_TargetPath="SyndicationAuthorName"
m:FC_KeepInContent="false" sap:label="User Name" sap:creatable="false" sap:filterable="false"/>
<Property Name="updated" Type="Edm.DateTime" Precision="0" m:FC_TargetPath="SyndicationUpdated"
m:FC_KeepInContent="false" sap:label="Time Stamp" sap:creatable="false" sap:filterable="false"/>
<Property Name="title" Type="Edm.String" MaxLength="255" m:FC_TargetPath="SyndicationTitle" m:FC_KeepInContent="false"
sap:label="Title" sap:filterable="false"/>
...snip...

HTTP Request  OData Operation  ABAP Method
Even though OData uses different terminology than REST, the same operations are invoked by
using a combination of HTTP method, query string parameters and/or an XML body.
The actual OData operations are then implemented by different methods within the ABAP Class(es)
implementing the OData Service.
HTTP
Method
Base URL plus Query String XML Body OData Operation ABAP Method
GET Nothing Handled by the Gateway Framework
GET Entity Set Name None or $filter QUERY GET_ENTITYSET
GET Entity Set Name Key Predicate READ GET_ENTITY
PUT Entity Set Name Key Predicate Yes UPDATE UPDATE_ENTITY
POST Entity Set Name Yes CREATE CREATE_ENTITY
DELETE Entity Set Name Key Predicate DELETE DELETE_ENTITY
GET/POST Operation Name Parameter List Custom Operation EXECUTE_ACTION

Requesting Multiple Entries from an OData Collection
OData QUERY Operations

Accessing an OData Collection – Construct the URL
Starting from the Service Document, we can now construct the URL to access any collection
listed in the workspace by appending the value of the href parameter of the required collection
to the OData service's Base URL.
<app:service xml:lang="en"
xml:base="http://<server>:<port>/sap/opu/odata/IWFND/RMTSAMPLEFLIGHT/">
<app:workspace>
<atom:title type="text">Data</atom:title>
<app:collection sap:pageable="false" sap:content-version="1" href="CarrierCollection">
<atom:title type="text">CarrierCollection</atom:title>
<sap:member-title>Carrier</sap:member-title>
</app:collection>
When this URL is issued, we will receive the contents of the collection called “CarrierCollection”.
http://<server>:<port>/sap/opu/odata/IWFND/RMTSAMPLEFLIGHT/ CarrierCollection
http://<server>:<port>/sap/opu/odata/IWFND/RMTSAMPLEFLIGHT/
CarrierCollection

<feed xml:base="http://<server>:<port>/sap/opu/odata/IWFND/RMTSAMPLEFLIGHT/" ...snip...>
...snip...
...snip...
Accessing an OData Collection – Understanding the Results
When using XML format, an OData collection is always delivered as an Atom <feed> element.
<entry>
<id>http://<server>:<port>/sap/opu/odata/IWFND/RMTSAMPLEFLIGHT/CarrierCollection('AA')</id>
<title type="text">CarrierCollection('AA')</title>
<updated>2013-09-05T12:46:57Z</updated>
<category term="RMTSAMPLEFLIGHT.Carrier" ...snip...>
<link href="CarrierCollection('AA')" rel="edit" title="Carrier"/>
<link href="CarrierCollection('AA')/$value" rel="edit-media" type="text/html"/>
<link href="CarrierCollection('AA')/carrierFlights" ...snip... title="carrierFlights"/>
<link href="CarrierCollection('AA')/$links/carrierFlights" ...snip... title="carrierFlights"/>
<content type="text/html" src="CarrierCollection('AA')/$value"/>
<m:properties>
<d:carrid>AA</d:carrid>
<d:CARRNAME>American Airlines</d:CARRNAME>
<d:CURRCODE>USD</d:CURRCODE>
<d:URL>http://www.aa.com</d:URL>
<d:mimeType>text/html</d:mimeType>
</m:properties>
</entry>

...snip...
...snip...
Within the <feed> element are zero or more <entry> elements.
<entry>
<m:properties>
</m:properties>
</entry>

...snip...
...snip...
Within the <feed> element are zero or more <entry> elements.
<entry>
<m:properties>
</m:properties>
</entry>
The <m:properties> element
contains the actual business data

Accessing an OData Collection – How Many Entries Are There?
If you suspect that an OData collection may contain a very large number of entries, then to avoid
requesting the entire contents of that collection, you should use the $count command.
This command is used by adding a slash after the collection name and then the $count command
If we use the BookingCollection belonging to the RMTSAMPLEFLIGHT OData service as an
example, you can ask the Gateway server how many entries are in this collection as follows:
http://<server>:<port>/sap/opu/odata/IWFND/RMTSAMPLEFLIGHT/BookingCollection/$count
When this command is used, the only response you will get from the server is a single integer, E.G.
94078
OData Service Base URL Collection
name
OData
command

Accessing an OData Collection – Filtering
You can filter out unwanted entries from a <feed> with the $filter query string parameter.
The value of the $filter parameter is a filter condition consisting of logical, arithmetic, and
grouping operators. Also available are string, date, math, and type-related functions.
The URL
/FlightCollection?$filter=carrid eq 'LH' and year(fldate) eq '2013' and month(fldate) eq '11'
will return a list of only those flights operated by Lufthansa during November, 2013.
IMPORTANT!
1. OData filtering is performed using standard HTTP query string parameters. This is a different
syntax than that shown for the earlier OData commands such as $count
2. You must implement the ABAP coding that responds to this parameter
3. A space (or %20) must be used as a separator character between operators in the $filter
condition.
4. All non-numeric values must be enclosed within single quotes.
5. Note the use of functions to extract the year and month parts from a date field

Accessing an OData Collection – Paging
Even after you have applied a filter to reduce the number of entries in a collection, you may still
have too many entries to display in a single screen. Therefore, you can use the $top and $skip
query string parameters to reduce the number of entries returned to the client. This allows you to
implement paging.
$top=t returns only the first t entries
$skip=s omits the first s entries and returns the entries starting from s+1
BookingCollection?$top=5 reduces the <feed> down to the first 5 entries.
BookingCollection?$skip=5 Skip the first 5 entries from the <feed> then send the rest
For example:
BookingCollection?$top=5&$skip=15 Skip the first 15 entries, then send the next 5
So, assuming we have 5 entries per page, this command sends page 4

1
*
1
* 1 *
Accessing an OData Collection – Expanding a Collection 1/3
The OData requests used so far instruct the server to return a <feed> element
containing zero or more <entry> elements.
However, let's say we want to see all the bookings, for all the flights operated by a
particular carrier on a particular day.
<feed>
<entry>
0..n
Here we can take advantage of the fact that a
Navigation Path exists between the Flight and
Booking entity types.
So rather than making a request to see first
the list of flights, followed by multiple requests
to see the associated bookings; this
information can be obtained in a single request
using the $expand query string parameter.

Here's the $filter command to view all Lufthansa flights leaving during November
/FlightCollection?$filter=carrid eq 'LH' and year(fldate) eq '2013' and month(fldate) eq '11'
We also know that the association between the Flight and Booking entity types has been
implemented as the navigation path flightBookings.
Therefore, we can extend the URL above as follows:
/FlightCollection?$filter=carrid eq 'LH' and⏎
year(fldate) eq '2013' and month(fldate) eq '11'&$expand=flightBookings
The Gateway server responds by sending a <feed> element containing all relevant flight <entry>
elements; but within each flight <entry>, there is a nested <feed> element containing the associated
bookings.

We still receive a <feed> of flight <entry> elements.<feed>
<entry>
0..n
<link>
1..n
<m:inline>
1..1
<feed>
1..1
Each flight <entry> corresponds to a particular flight
Every <entry> has one or more <link> elements
The <link> element corresponding to the navigation flightBookings
contains the results of the $expand command within an <m:inline> element
This is where you will find the nested <feed> element containing all the
bookings for that particular flight

Consuming Single Entries from an OData Service
OData READ Operations

Accessing an OData Collection – Reading a Single Entry 1/4
Up until now, we have been using OData QUERY operations.
These are requests that use the HTTP GET method and return a <feed> element containing zero or
more <entry> elements.
HTTP
Method

Now we will look at using OData READ operations.
These requests also use the HTTP GET method, but return just a single <entry> element.
Q: Since both QUERY and READ operations are sent using the HTTP GET method, how is the
Gateway server able to distinguish between a QUERY and a READ operation?
HTTP
Method

Now we will look at using OData READ operations.
These requests also use the HTTP GET method, but return just a single <entry> element.
Q: Since both QUERY and READ operations are sent using the HTTP GET method, how is the
Gateway server able to distinguish between a QUERY and a READ operation?
A: By the presence of a Key Predicate in the URL
HTTP
Method

An OData QUERY operation is transformed into a READ operation by adding a Key Predicate
/CarrierCollection QUERY  returns a <feed> of all entries in the collection
/CarrierCollection(carrid='LH') READ  returns the one <entry> matching the key predicate
CollectionName
The key predicate must be enclosed in parentheses and specify
the key values that uniquely identify a single entry

The result of a READ operation as that a single <entry> element will be returned.
If the key predicate specifies a non-existent entry, you will still get an <entry> element returned, but
it will not contain any business data.
<entry xml:base="http://<server>:<port>/sap/opu/odata/IWFND/RMTSAMPLEFLIGHT/">
<id>http://<server>:<port>/sap/opu/odata/IWFND/RMTSAMPLEFLIGHT/CarrierCollection('LH')</id>
<title type="text">CarrierCollection('LH')</title>
<category term="RMTSAMPLEFLIGHT.Carrier" scheme="http://schemas.microsoft.com/ado/2007/08/dataservices/scheme" />
<link href="CarrierCollection('LH')" rel="edit" title="Carrier" />
<link href="CarrierCollection('LH')/$value" rel="edit-media" type="image/gif" />
<link href="CarrierCollection('LH')/carrierFlights" ...snip... title="carrierFlights" />
<link href="CarrierCollection('LH')/$links/carrierFlights" ...snip... />
<content type="image/gif" src="CarrierCollection('LH')/$value" />
<m:properties>
<d:carrid>LH</d:carrid>
<d:CARRNAME>Lufthansa</d:CARRNAME>
<d:CURRCODE>EUR</d:CURRCODE>
<d:URL>http://www.lufthansa.com</d:URL>
<d:mimeType>image/gif</d:mimeType>
</m:properties>
</entry>

Development Approaches for Building an OData Service

Building an OData Service – Development Approaches
When you come to build an OData service, two different approaches are available:
1) If you enjoy ABAP coding, you could
write the entire service directly in the
ABAP Development Workbench! 

2) Or you could use the Gateway Service
Builder tool in one of two ways:
OData Service Builder
(txn SEGW)

1. Generate an OData service from
existing units of code such as BAPIs,
GENIL or BOL objects etc.
(txn SEGW)
Service Registration
and Hub Activation
Service Generation

1. Generate an OData service from
existing units of code such as BAPIs,
GENIL or BOL objects etc.
2. Develop a service by adding your own
code into a generated framework
(txn SEGW)
and Hub Activation
In this presentation, we will focus only on
the use of the Gateway Service Builder
Service GenerationService Development

Development Approaches – Service Generation
The “Service Generation” approach should be used in situations in which you wish expose existing
ABAP functionality through the OData interface.
(txn SEGW)
Declarative
Model
Definition*
Import
Data Model
(EDMX)
Import DDIC/
RFC/BOR
Interface*
Redefine
Data Source
Service
(GenIL, SPI,
BW Easy
Query,
MDX)
Code-Based Implementation*
Code-Based Extensions*
Map RFC/BOR
Operation*
and Hub Activation
Include
Gateway
Service*
Service Implementation
(Code based or mapping)
Service Development
This approach is aimed primarily at
people having business process
knowledge, rather than programming
knowledge.
You can also create OData mash-ups by
including existing OData services within
your new service.

Development Approaches – Service Development
OData services can be developed (as opposed to generated) in a two-step process:
(txn SEGW)
Declarative
Model
Definition*
Import
Data Model
(EDMX)
Import DDIC/
RFC/BOR
Interface*
Redefine
Data Source
Service
(GenIL, SPI,
BW Easy
Query, MDX)Code-Based Implementation*
Map RFC/BOR
Operation*
and Hub Activation
Include
Gateway
Service*
Service Generation
Implement functionality behind each
OData operation
1) Define the service’s data model.
This causes an ABAP class called a
“Model Provider” to be generated.
Create Entity Data Model

Development Approaches – Service Development
OData services can be developed (as opposed to generated) in a two-step process:
(txn SEGW)
Declarative
Model
Definition*
Import
Data Model
(EDMX)
Import DDIC/
RFC/BOR
Interface*
Redefine
Data Source
Service
(GenIL, SPI,
BW Easy
Map RFC/BOR
Operation*
and Hub Activation
Include
Gateway
Service*
Service Generation
OData operation
1) Define the service’s data model.
This causes an ABAP class called a
“Model Provider” to be generated.
2) The Gateway Service Builder generates a
“Data Provider” class into which you can
either:
a) Directly write your own code, or
b) Implement functionality from BAPIs or RFC
modules
Create Entity Data Model

Service Development – Define the Service’s Data Model
When defining the Data Model for an OData service, you have various options available to you:
(txn SEGW)
Declarative
Model
Definition
Import
Data Model
(EDMX)
Import DDIC/
RFC/BOR
Interface
Redefine
Data Source
Service
(GenIL, SPI,
BW Easy
Map RFC/BOR
Operation*
and Hub Activation
Include
Gateway
Service*
Service Generation
OData operation
1) The fields in the entity types are declared
manually.
This process is very similar to creating
data structures in the ABAP Data
Dictionary

(txn SEGW)
Declarative
Model
Definition
Import
Data Model
(EDMX)
Import DDIC/
RFC/BOR
Interface
Redefine
Data Source
Service
(GenIL, SPI,
BW Easy
Map RFC/BOR
Operation*
and Hub Activation
Include
Gateway
Service*
Service Generation
OData operation
manually.
Dictionary
2) Create the Data Model in an external tool
(such as the GWPA) and then import the
generated .edmx file

(txn SEGW)
Declarative
Model
Definition
Import
Data Model
(EDMX)
Import DDIC/
RFC/BOR
Interface
Redefine
Data Source
Service
(GenIL, SPI,
BW Easy
Map RFC/BOR
Operation*
and Hub Activation
Include
Gateway
Service*
Service Generation
OData operation
manually.
Dictionary
2) Create the Data Model in an external tool
(such as the GWPA) and then import the
generated .edmx file
3) Use a data structure definition found in
the ABAP Dictionary or that belongs to an
existing unit of ABAP code*
* This step is not the same as actually consuming the functionality provided by a BAPI.
Here we are simply using an existing ABAP data structure as the basis for creating an
OData entity type.

Service Development – Implement the OData Functionality
Once you have built the OData data model, you can start to define the actual business functionality
behind the OData operations. Two approaches are possible here:
(txn SEGW)
Declarative
Model
Definition
Import
Data Model
(EDMX)
Import DDIC/
RFC/BOR
Interface
Redefine
Data Source
Service
(GenIL, SPI,
BW Easy
Query, MDX)
Code-Based Implementation
Map Operation
to RFC/BOR
and Hub Activation
Include
Gateway
Service*
Service Generation
1) Code the individual OData operations
manually, or

Service Development – Implement the OData Functionality
Once you have built the OData data model, you can start to define the actual business functionality
behind the OData operations. Two approaches are possible here:
(txn SEGW)
Declarative
Model
Definition
Import
Data Model
(EDMX)
Import DDIC/
RFC/BOR
Interface
Redefine
Data Source
Service
(GenIL, SPI,
BW Easy
Query, MDX)
Code-Based Implementation
Map Operation
to RFC/BOR
and Hub Activation
Include
Gateway
Service*
Service Generation
1) Code the individual OData operations
manually, or
2) Map individual OData operations to
distinct RFC modules or BOR objects

© 2014 SAP AG or an SAP affiliate company. All rights reserved.
No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG.
The information contained herein may be changed without prior notice.
Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.
National product specifications may vary.
These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and
SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth
in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.
SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and
other countries.
Please see http://www.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices.

Introduction to SAP Gateway and OData

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (17)

Similar to Introduction to SAP Gateway and OData

Similar to Introduction to SAP Gateway and OData (20)

More from Chris Whealy

More from Chris Whealy (8)

Recently uploaded

Recently uploaded (20)

Introduction to SAP Gateway and OData