OData

As everyone says, OData is the acronym for “Open Data Protocol”. The protocol is a set of rules which
every player has to follow. To put it straight, OData interface is an open standard that can be consumed
by any application, program, software or device of the Non-SAP World that can connect with SAP using
the HTTP(s) protocol and can manipulate (read, write, modify and understand i.e. parse and construct)
an XML document. Since the protocol is HTTP based, any programming language with HTTP stack can
be used for consuming OData services.

In other words, OData is a Web protocol for unlocking and sharing data; freeing it from silos that exist in
some software applications. The OData protocol supports serialization in multiple popular formats,
including JSON and Atom/XML. With OData, developers are able to build cross-platform Web and mobile
Applications.
With OData, organizations can develop services with the high levels of data integration and cross-
platform interoperability that are required by the modern day complex business.
SAP Netweaver Gateway
Th below figure shows that SAP NetWeaver Gateway sits in SAP Application Layer. It is the Window for
outside world to peep into SAP and transfer data to/from SAP. Outer world can send HTTP(s)message
and SAP would provide them with OData. Also note, OData is an open source to exchange data over the
Internet. SAP Netweaver Gateway (blue box within Application Layer in the below picture) is a
technology that seamlessly connects 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.

Both Client side (Outer World) and Server side (SAP) development can be in completely different
programming languages as long as both are able to communicate with each other via HTTP.

Clients that consume the service to query and manipulate the data from OData Services are also called
as “Consumers” of OData Service. Similarly, Servers that expose the OData services via endpoints are
known as “Producers” of OData services.

Prior to OData, external non-SAP developers have connected to SAP using RFC/BAPI or web services.
In those cases, the non-SAP developers (Web developers) needed to know beforehand the structures of
the data passed from SAP. The non-SAP developers needed to have at least a basic knowledge of the
internal workings of an SAP system. But the scenario has changed with OData.

Advantages of OData for Programmers and Developers.

i. The OData interface is implemented using XML or JSON. Both of these formats are well known, plain
text protocols for the transmission of information over the Web.
ii. OData message is self-describing. So any non-SAP Web developer can understand the content of the
OData message without the knowledge of ABAP or how SAP works.
It is understood by now that Server hosts the Data and Clients can call the Service to retrieve the
resources and manipulate them. Servers expose one or more endpoints which are Services that refers to
the Resources. Clients or non-SAP World developers only need to know the Server side endpoints to call
the service to query or manipulate the data.

With the advent of OData, the communication barrier between SAP and Non-SAP Web Developers is
removed. It is an Open book now. There is no cost or license agreement needed for the use of OData.

FYI: Microsoft originally developed and introduced OData. Not SAP. Surprise for an ABAPer. .
Citrix Systems Inc., IBM Corp., Microsoft Corp., Progress Software, SAP AG, WSO2 etc collaborated
together to standardize the OData for implementation of a RESTful API. Now OData is managed by
the Oasis Organisation .
Why is OData called ODBC (Open Database Connectivity) of the Web?
Ans: OData offers database-like access to server-side resources. Hence, OData is also described as

“ODBC for the Web”. Confused? Let’s simplify it.

ODBC is a standard API to access the DBMS, independent of the database management systems or
operating systems. ODBC achieves this by adding drivers between the Application layer and the DBMS to
translate the queries requested by the applications into instructions which DBMS can understand.
Similarly, OData acts like middleware between producers and consumers to communicate data. There is
a uniform way to consume data and is independent of the producer (SAP or Non-SAP OData) much like
ODBC.
What was the need for OData in SAP?
Ans: Before the introduction of OData, there was the “Point-to-Point” solution for SAP to Non-SAP
integration. One application for two different organizations or platforms needed two different design in
SAP. This led to duplication of work, effort, time and money.

Check the below image. For pulling the same data from SAP, there are multiple interfaces created to
cater the need of multiple end users (browsers/mobile/cloud/custom devices/software etc).
This mean there was poor scalability, increased system landscape complexity and increased
administration effort.
The alternative to Point-toPoint solution is “One Data Model -> One API -> Multiple End-User
Experiences”. Please check the image below. One OData service along with SAP NetWeaver Gateway
suffices all the needs of multiple end applications.
This approach provides one solution to any environment, any platform and any experience. Moreover, no
SAP knowledge required for consumption of OData.

What is the nearest competitor of OData?

Ans: GData from Google.
OData’s extensibility feature was one of the most important reasons why SAP chose OData over
GData. This is particularly useful in cases where SAP specific values need to be described in this
protocol; for instance, currency fields. A currency field contains two separate values, the currency amount
and the currency code. These two values must always be treated as a linked pair and OData’s
extensibility allows for this.

HTTP (Hyper Text Transfer Protocol) is an integral part of OData. So it deserves a small mention.
HTTP is based on Client-Server Architecture. The Browser is the Client which sends HTTP request
and Web Server is the Server which sends the response back to the browser. HTTP defines “WHAT” can
be transferred between Client and Server. “HOW” the data packets are transferred via HTTP is handled
by TCP/IP protocols.
What is stateless?
Ans: Every single HTTP request that is received by the Web Server is forgotten after a response has
been sent across. Web Servers do not remember or recall the previous request. This is called stateless.
What is RESTful?
Ans: OData is REST-inspired technology for reading, writing, and modifying information on the Web (not
just SAP). REST = REpresenational State Transfer. REST 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.
REST services are called as REST services because the Services are really working with Resources
instead of Operations. Any communication between client and services are using URI (Unified Resource
Identifier) over HTTP protocol using HTTP method. The URI is really the representation of the Resources
(like POHeader, POItem, Customer, Vendor etc). Also, in RESTful service, once you identified the
Resource, you will be working with a uniform interface, because it uses HTTP methods (GET, PUT,
POST and DELETE) to work with the resource. So, the client does not need to know what the exact
operation name defined in the service contract to call that method. GET method is used whenever we
need to get the representation of an existing resource. POST is used to add new resource into the
system. PUT is to modify the existing resource and DELETE is to remove the resource from the
system. No matter what is the Service in whatever Platform, GET, PUT, POST, DELETE remains the
same.
Still confusing? Let us try to understand with the below real example (Do not worry, how we created it.
We will learn how to create them in our next post).

In the above OData Service, POHeaderSet, POItemSet, ZEKKOEKPOSet are “Resource” names.
Create, Delete, GetEntity, GetEntitySet etc are the “Operation” names. While calling this OData services,
the outside world (Client) needs to call the URI with the Resource details. Also, outside world only needs
to use GET, POST, PUT etc verbs to pull data, create data and update data etc at the server side. These
verbs are uniform and standardized for all OData. Clients do not need to know the server side actual
methods or operations like Create / GetEntity / GetEntitySet etc which are called behind the scene.
It is also important to note here that it is possible to have multiple URIs pointing to the same
Resource with the same output. Let us check it with the below example.
URI 1: /sap/opu/odata/sap/ZGW_PURCHASE_SRV/POItemSet(Ebeln=’4500004723′,Ebelp=’00010′)

URI 2: /sap/opu/odata/sap/ZGW_PURCHASE_SRV/POHeaderSet(‘4500004723’)/HeaderToItemNav
The above two URIs point to the same Resource.

How to check if your system has SAP Netweaver Gateway?

Ans: At NW 7.3 and prior to NW 7.3, SAP Netweaver Gateway had three add-ons
namely GW_CORE, IW_FND and IW_BEP. The GW_CORE and IW_FND components were required for
Gateway Server functionalities, whereas IW_BEP was used for Gateway Backend functionalities.
After 7.4 release, all the three components are bundled into a single component SAP_GWFND called
Gateway Foundation.

This is just the introduction of OData and SAP Netweaver Gateway along with some related
terminologies. In the subsequent parts, we will dive deeper in the actual practical scenarios of OData. We
will learn how to create OData services, play with the GET, POST, PUT etc operations along with the
backend methods which need to be re-defined to meet our requirement. We will also
check Navigationsand Associations of Data Models and learn how to handle them. At the end, we will
build SAPUI5 Applications to consume our OData service.
Next Post: SAP Netweaver Gateway and OData Tutorial Part II: Create your first OData Service
OData and SAP Netweaver Gateway.

Part II. Create your first OData Service

In the Part I post Introduction to SAP Netweaver Gateway and OData, we learned about the definition,
terminologies and concept of SAP Netweaver Gateway, OData and HTTPs. Now we have a fair idea of
the RESTful and STATEless concept. In this article, we will do a hands-on exercise and generate our
first OData Service in SAP and play around with the different URIs of the service. These URIs are the
endpoints of Server side of OData which the outside world (Client side) would need to call using HTTP(s)
in order to update/extract data to/from SAP. In SAPUI5 applications, we need to consume these URIs to
connect to SAP and play with its data. We will re-define the standard methods and add our custom ABAP
logic to meet our requirements.

A. Define Data Model

Go to t-code SEGW (SAP Gateway Service Builder). Remember it like SE38. Instead of 38, add GW for
GateWay. So our friendly t-code for today’s topic is SEGW. Hit the Create Icon and provide the name of
the Project, description and package (or local) and save it.

The project gets created with four folders, namely Data Model, Service Implementation, Runtime
Artifacts and Service Maintenance. Please take note that Data Model further has three sub-folders
viz Entity Types, Associations and Entity Sets. All the folders are empty by default.
Before you ask yourself, what is Entity Types and Entity Sets, let me answer it quickly. After all, SAPYard

is here to hand hold you and help you cross this SAP Gateway learning curve smoothly.

Entity Type is our very own structure (or a work area (holds just one row)). And you guessed it
right, Entity Set is an internal table (holds more than one entity/rows). ABAPers, are you gaining

confidence? You just learned two new terms.

Let us create our first structure; oops!! work area; oops Entity Type (right term in Gateway terminology).
Right click on Entity Types folder and select “Create”, provide the name you like and do not forget to tick
the checkbox “Create Related Entity Set”. For our example, POHeader is the structure (work area) while
POHeaderSet is our internal table.

Check the Service Implementation folder has POHeaderSet Operations auto generated. These are ABAP
Methods which would be triggered when the relevant endpoints would be called.

Now we need to define the fields of the structure/work area and internal table.
Double click on the Properties folder, hit the create icon and then start adding the field names and the
type and length. In the example, we have added Ebeln and Bukrs. So on and so forth, we need to build
our Entity Type.

Also Read: SAP HANA from Space Level

Doesn’t it look too tiresome to add one field at a time in the Entity Type? There has to be a better
way. The above steps are just to let you know such thing exists. In real projects, you would like to use the
below method. Delete the POHeader Entity Type and POHeaderSet Entity Set by right clicking and hitting
delete.

Let us create them again.

Right click on the Data Model folder and Import the DDIC Structure. Give the Entity Type name and ABAP
structure whose fields you want to import to your Entity Type. Do not forget to click the checkbox for Entity
Set (unless you are sure you will not need an internal table).
Hit Next and choose the fields from EKKO (our example) structures which you want to add to your Entity
Type.

Next, choose the Key for your structure/entity type and entity set. For our example it is Ebeln.

After you hit finish hit the save button and check the Properties and Service Implementation folder. They
would have the structure and operations respectively.
At this point, let us import one more Entity Type called POItem from EKPO using the steps just mentioned
above.
From the above image, it is clear that every Entity Types will have its own Properties and Navigation
Properties Folder. And every Service Implementation Entity Set will have its own Operations (Create,
GetEntity, Update, Delete etc).

As of now, we have a Header Table and an Item/Detail Table. Let us assume we do not need any more
Entity Types.

B. Implement/Register the Service

Let us go ahead and generate and register our service.

Hit the Generate icon and hit ok. Provide the package and transport number or save it as local. You
should get the success message as shown below.

Please note the Technical Service Name is the actual Service which the external system needs to
call. Two classes, Model Provider Class (MPC) and Data Provider Class (DPC) are also generated
along with Base and Extended Class.
Model Provider Class inherits from /IWBEP/CL_MGW_ABS_MODEL and Data Provider Class inherits
from /IWBEP/CL_MGW_ABS_DATA. The below image shows the relationship between the generated
classes and their superclasses (parents).
FYI: Data Provider Class provides the Gateway Service functionalities. Model Provider
Class defines the Gateway Service interface. DPC and MPC are not connected by any coding. They
talk to each other via Configuration.

C. Add Service to Service Catalog (Register the Service to Gateway Hub)

We have implemented the Service, now we need to add the service to the Service Catalog.

Most of the tutorial present on the internet shows that the Service Maintenance folder would have an
entry with System details and the Register/Maintain buttons are active (as in above image). If you see an
entry in Service Maintenance folder, it means your system has “Embedded Deployment“.

SAP Net weaver gateway components are installed as add-ons on the SAP backend system itself in the
Embedded Deployment option. Both the OData modeling and the exposing of the Services to the
outer world is done from the backend system.

The advantage of Embedded Deployment Strategy:

i. Saves cost as there is no need of any dedicated Gateway Hub
ii. It is faster as the runtime overhead due to remote calls in case of two separate systems (separate front
end and back end) is avoided

Disadvantages of Embedded Deployment Strategy:

i. There is no single point connection to the backend via Gateway Hub; instead, back end system is
directly exposed to the outer world (consumers), so better security measures need to be in place
ii. Back end system upgrade would follow a different cycle than Netweaver Gateway
iii. If the landscape has multiple SAP Business Suite backend, then each system needs to have its own
installation and configuration of Netweaver Gateway components.

If you have Embedded System, hit the Register and Maintain buttons and you are good.

The above image is not from our sap system. Our system does not show any entry in Service
Maintenance folder. Our architecture is “Hub Deployment with Development in the Backend System“.
In this strategy, the SAP Netweaver Gateway is installed on separate SAP machine called as Gateway
Hub. Gateway Hub would be the window for the outer world to SAP. Gateway Hub would register and
expose the OData Services, but the development would still happen in the SAP backend system.
The advantage of Hub Deployment with Development in the Backend System Strategy:
i. Better security as it has only one point of access to SAP Backend system for outer space via Gateway
Hub
ii. Although Gateway components are in different SAP system, it still has direct access to Backend DDIC
and business data for OData Model/Services
iii. Gateway Hub can be in advanced newer version NW 7.3/7.4 or up while Backend still can be in the
lower release. Gateway on new release would support SAPUI5.

Disadvantage: More cost and maintenance effort along with the runtime overhead due to remote calls.
Coming back to our screen. We are in our Backend system, therefore by default, we do not get the option
to maintain and register our service in our backend system. We need to go to our front end system where
we have the Netweaver Gateway i.e. our Gateway Hub.

Go to your Gateway Hub (Front-end system) and execute t-code /n/IWFND/MAINT_SERVICE. Save

this t-code in your favorite list or remember it by heart. You will need it for all your OData services.
Our service is still not added to the Service Catalog. After we add the service to the Service Catalog,
only then is our service available for the outer world to access.
Hit the Add Service button, provide your backend system alias and external service name (our case
ZGW_PO_SRV). You will get the service you created in the backend. Click on it and it would show the
Service (technical/external) name along with the Technical name of the Model (ZGW_PO_MDL) and hit
save. Go back to the Service Catalog screen.
Find your service, click on it. It would show up in System Aliases window at the lower right corner. Let us
test it using SAP Gateway Client. Or use t-code /IWFND/GW_CLIENT (remember this t-code as well).
You can also test by Call Browser option. For now, we will use SAP Gateway Client option.

OOPs!! You get this error. Status 403, Forbidden with the message “No authorization to access Service”.
Let us check the Authorization Object issue in t-code SU53 and ask your SAP Security Team to provide
you access to this authorization.
Just in case your security team asks what has to be done. The below screenshot might help him.

Where did the ZGW_PO_SRV_0001 come from? The below screen might help.
Assuming your authorization is in place. Let us try t-code /n/IWFND/MAINT_SERVICE, select the service
and hit SAP Gateway Client or directly use t-code /n/IWFND/GW_CLIENT. Hit the Execute button. This
time the status code is 200 i.e success.

Congratulations!! You just created, maintained and activated your first OData Service.

In the above image, our URI (/sap/opu/odata/sap/ZGW_PO_SRV/?$format=xml) has format XML. Let us
change it to JSON (/sap/opu/odata/sap/ZGW_PO_SRV/?$format=json). Both xml and json informs that
they have two Entity Sets.
Please note: The word json is case sensitive. Give lower case “json”.

Now let us check the metadata of the OData. In layman’s term metadata means the structure and

properties or full skeleton (X-Ray view).

It shows the Entity Type (work area/structure) Names. In our OData, we have two (POHeader and
POItem). It also shows the Entity Set (Internal tables) Names which are also two for our case
(POHeaderSet and POItemSet). At the bottom of the page, you would see a link. That is the link which
opens your service in Web Browser. Copy the link and paste it in your browser (you need to give your
SAP Front End credentials).
If you were a non-sap web developer who would need to consume this SAP OData service and you just
have the service name and URI. You would be interested in knowing the details of the structures so that
you can make use of it in your non-sap application. The first thing you would do is use?$format to check
the details.

Below is two popular way to check the format.

1. ?$format = json
http://txaixegd01.sapyard.com:8000/sap/opu/odata/sap/ZGW_PO_SRV/?$format=json

2. ?$format=xml
http://txaixegd01.sapyard.com:8000/sap/opu/odata/sap/ZGW_PO_SRV/?$format=xml
How can ABAPers find the error of OData service if any?
In case you enter something incorrect in the URI or your URI is not working, you will get the
message“Run transaction /IWFND/ERROR_LOG on SAP Gateway hub system” to find the issue.

T-code /n/IWFND/ERROR_LOG would be an ABAPers friend for stormy weather. Check the message for
the URI.

For the above error, a “?” is missing in front of “$”.

wrong: http://txaixegd01.sapyard.com:8000/sap/opu/odata/sap/ZGW_PO_SRV/$format=xml
right: http://txaixegd01.sapyard.com:8000/sap/opu/odata/sap/ZGW_PO_SRV/?$format=xml
Check the /n/IWFND/ERROR_LOG screen.

Now let us check if we can pull some data for POHeaderSet.

Enter URI http://txaixegd01.sapyard.com:8000/sap/opu/odata/sap/ZGW_PO_SRV/POHeaderSet in your

browser or /sap/opu/odata/sap/ZGW_PO_SRV/POHeaderSet in your SAP t-code /IWFND/GW_CLIENT.

OOPs, we get the error, Not Implemented. Method ‘POHEADERSET_GET_ENTITYSET‘ not

implemented in data provider class.
In our backend system, in t-code SEGW, we created the Entity Types/Set and activated the service and
registered it. The MPC and DPC were generated. But the DPC methods were not re-defined. We need
to write our ABAP code and logic to pull data from the backend system and populate the Entity Set
(internal table). Once the entity set is populated, we can see the output in our OData service call.

Let us just re-define the method and write no code. What do you expect the OData service to return (give
output)?

Go to change mode in the DPC Extension class and not in Base class (we work in the extension class
since we are enhancing the inherited class).
Put the cursor the method you want to re-define. Hit the re-define method icon and hit enter. Some auto
generated code would show up.

We would learn about all the importing and exporting parameters of the methods in next article. For now
save as it is and activate the class. Check the folder Redefinition has the method
‘POHEADERSET_GET_ENTITYSET’ listed. This means our method is successfully re-defined.

Let us check the output. Go to t-code /n/IWFND/MAINT_SERVICE or /n/IWFND/GW_CLIENT and give

the URI: /sap/opu/odata/sap/ZGW_PO_SRV/POHeaderSet.
 This time we do not get any error. The status code is 200 and it is OK. But, the body has no data yet.

Quite obviously, we did not write any logic to populate the internal table (entityset).

Now, let us write one small statement to pull 10 entries from Purchase Order table EKKO in the method
and activate it.

1
2 METHOD poheaderset_get_entityset.
3
4 SELECT * UP TO 10 ROWS FROM ekko INTO CORRESPONDING FIELDS OF TABLE et_entityset.
5
6 ENDMETHOD.

Now, let us check the output again.

10 entries are returned. If you expand the entries, you would see the details of each row.

Now, we can see the same output in the browser as well.

Let us stop here for today. In the next post, we will implement all the other methods and manipulate the
URIs to meet our requirement. We would show you how Association and Navigation links can be
created to flow/pull/push data to and from different Entity (i.e. Navigation and Association between data

models). The next article will be more hands on with lots of code and tips. So, please stay tuned.

Bonus Contents for this Post

i. Hub Deployment with Development in the Gateway Hub

There is a third Deployment Strategy, in addition to the two mentioned above, for SAP Netweaver
Gateway. It is “Hub Deployment with Development in the Gateway Hub“. The Gateway component
need not be installed in the backend system as all the development related to SAP Netweaver Gateway
takes place in the Gateway Hub. If we don’t want to do any kind of developments in the backend system
and leverage the standard/custom what is already existing in the system, this might be the strategy.

Disadvantages of Hub Deployment with Development in the Gateway Hub:

i. No access to backend data dictionary objects directly. Only the existing BAPIs and RFCs can be the
data source for OData Service development
iii. Additional cost and maintenance effort as compared an embedded deployment option with just one
system.

ii. How is the URL for OData Service determined for the Web Browser?
In this post, we have used t-code /IWFND/MAINT_SERVICE and execute SAP Gateway Client (or directly
from t-code /IWFND/GW_CLIENT) to test our OData Service in SAP screen. We also saw that we can
call the URL in web browser and test it as were doing in SAP Gateway Client. But, how actually is the
URL created for Web Browser?

Ans: The actual URL for OData in Web Browser consists of: http(s)://<Hostname>:<Service i.e Port
Number>/(rest is from the relevant ICF path).
Now another question arises, how do we know the Hostname, Service (Port Number) and ICF path of our
SAP system?
Ans: Go to t-code SICF. Execute it with default values. Menu Goto->Port Information. The pop-up
window would have the Hostname and the Service name (Port Number) for the system.

In order to find the default ICF path, provide the service name in the t-code SICF and execute it. Expand
the roots till you reach the service name. For our example the ICF path is sap->opu->odata->sap-
>zgw_po_srv.
Now concatenate the http, Hostname, Service (Port Number) and ICF path. For our example, it would
be http://txaixegd01.retail.sapyard.com:8000/sap/opu/odata/sap/ZGW_PO_SRV/. So next time if

someone asks you what is the Hostname and Port of your system, you know how to find it.

Next Post: OData and SAP Netweaver Gateway. Part III. Query Options in OData Service URI

OData and SAP Netweaver Gateway. Part III. Query Options in OData Service URI

In the previous tutorial, we created our first working SAP OData Service. It was OData at it most
simplest form with just one method re-defined to get POHeaderSet. We will work on the same
ZGW_PO_SRV service of the earlier post and add more complexity and features to dive deep into OData
implementation and put forth the concept behind it.

All the tutorial series in SAPYard are designed to commence from simple terms with simple examples and
build on the more practical complex scenario later. If you are a beginner on OData and if you have not
visited our Introduction to OData and Part II (Create First OData Service) then we highly recommend
you to pause here for a while, have a quick look into those two topics before you move forward with this
post. If you already understand the terms and concepts or if you have fairly good exposure of OData,
please continue and enjoy.

A. READ Operation (i.e. GET_ENTITY method)

“GET” is the HTTP Method for all external Consumer Applications which call the URI of the OData
Service.

Till now we learned that our URI ‘/sap/opu/odata/sap/ZGW_PO_SRV/POHeaderSet’ works in GW Client

and the corresponding Browser URI works in the browser. We have re-defined just one method
POHEADERSET_GET_ENTITYSET. It returns an array or internal table of PO Header data. But,
suppose the front end application of the consumer system wants to connect to SAP using our OData
service by providing the PO number and pull only that PO numbers details. In short, if the consumer
application expects only one row of information. How can they achieve it?

The URI for the consumer system should look like below. They need to pass the primary Key as the
parameter of the URI.

URI to READ: /sap/opu/odata/sap/ZGW_PO_SRV/POHeaderSet(‘4500002012’).

This means we want to see only PO number ‘4500002012’ details. Let us check what output we get with
our current OData service which we created in our last post.
We get the error message ‘Method ‘POHEADERSET_GET_ENTITY’ not implemented in data provider
class’.

What does the error message mean? It implies, if we want just one entry data, the Data Provider Class
(DPC) would call the POHEADERSET_GET_ENTITY method and not the
POHEADERSET_GET_ENTITYSET method. We need to correlate, work area with the entity and
array/internal table with entity set.

So, as the error message suggests, let us implement the ‘POHEADERSET_GET_ENTITY’ method in t-
code SEGW. Right click on the GetEntity (Read) Operation. Choose Go to ABAP Workbench. Information
message would pop up. Hit continue.
Select the method ‘POHEADERSET_GET_ENTITY’ and hit the Redefine method icon as explained in the
earlier post. Alternatively, we can right click on the method and choose ‘Redefine’ option. For a change, I
have taken the second route this time.
 Remove the auto-generated code and use code similar to the snippet shown below in method
POHEADERSET_GET_ENTITY.

1
2 DATA : ls_key_tab LIKE LINE OF it_key_tab,
3 lv_ebeln TYPE ekko-ebeln.
4
5 * IT_KEY_TAB has key name and value
6 READ TABLE it_key_tab INTO ls_key_tab
7 WITH KEY name = 'Ebeln'. " Case sensitive
8 IF sy-subrc EQ 0.
9 lv_ebeln = ls_key_tab-value.
10 ENDIF.
11
12 * Select one PO entry
13 SELECT SINGLE * FROM ekko INTO CORRESPONDING FIELDS OF er_entity
14 WHERE ebeln = lv_ebeln.

For the URI ‘/sap/opu/odata/sap/ZGW_PO_SRV/POHeaderSet(‘4500002012′)’, the importing

paramter IT_KEY_TAB would hold ‘Ebeln’ and ‘4500002012’ as ‘name’ and ‘value‘ respectively.

Let us see the output again. Got to t-code /n/IWFND/GW_CLIENT or using the Browser URI and execute.
This time it returns the details of the PO passed on the URI parameter.
What did we learn just now? We need to pass the KEY field value in the URI in order to fetch its details.

Let us change the format to JSON and see how it looks. The URI is
/sap/opu/odata/sap/ZGW_PO_SRV/POHeaderSet(‘4500002012’)?$format=json

The same output in JSON format looks like below in the browser.
The JSON format looks cleaner. Some developers might toggle around with the XML and JSON format to
view the information passed by OData and then design the solution.

Let us step back. Now let us execute the URI with just POHeaderSet i.e.
/sap/opu/odata/sap/ZGW_PO_SRV/POHeaderSet. Let us see what info comes up in the result.
i. You get the link for the browser
ii. You get the link to pull one particular entity type information, i.e. just one PO detail
As we keep enhancing the OData Model and Service, the information in the result set keeps growing with
more links and navigation options. We will witness them gradually as we reach that stage of our tutorial.

B. READ one particular field or property of the Entity Type (/Field1)

At times, we need to pull just one field of the structure for the key element. For example, you know the
PO number from somewhere in your application, now you need to find our the Vendor who is supplied the
material.
So the URI is /sap/opu/odata/sap/ZGW_PO_SRV/POHeaderSet(‘4500002013’)/Lifnr.

Simple, just add the property name i.e the field name of the Entity Type at the URI.

Similarly, if you want to know the company code for which the PO was created, you know how to pull it.

URI would be /sap/opu/odata/sap/ZGW_PO_SRV/POHeaderSet(‘4500002013’)/Bukrs.

C. Count the number of entries in the system ($count)

In many cases, we need to know how many entries exist for our Query. You might need to know the
count just to report or to plan some action based on it. Whatever may be the reason, you need to
add $count at the end of your URI to find the number count.

URI: /sap/opu/odata/sap/ZGW_PO_SRV/POHeaderSet/$count
We have hard-coded UP TO 10 Rows in our selection statement, therefore the Query Count shows as 10.
Remove the UP TO 10 from code and check the count in your system.

A tough question for you now. What would be the count of the READ URI?

URI: /sap/opu/odata/sap/ZGW_PO_SRV/POHeaderSet(‘4500002012’)/$count

It has to be one, right? After all, we are passing the Primary Key as the URI parameter.

D. Extract only some fields of the Entity Type ($select=Field1,Field2,Field3)

You have an OData Service with data model having 10 properties(fields), but in your consuming
application, you need just three fields. You can pull all the fields and then filter in your application. But

smart developers would only pull what is needed. Nothing more nothing less.

Say for our POHeaderSet entity, we need Company Code, Created By and the PO number. Our URI
would be /sap/opu/odata/sap/ZGW_PO_SRV/POHeaderSet?$select=Ernam,Bukrs,Ebeln.
If you want to view the same output in JSON format, append &$format=json at the end.

/sap/opu/odata/sap/ZGW_PO_SRV/POHeaderSet?$select=Ernam,Bukrs,Ebeln&$format=json
FYI: Whenever you find a question mark “?”, you should understand, it is the beginning of a query
option.

The above are some standard query options which do not need any backend programming in OData
model/service. There are some more query options which need coding. We will discuss them some other
day in a separate post.

E. Set Breakpoint and check the Methods called in Debug mode

In Part II of our tutorial, I informed you that we are in “Hub Deployment with Development in the
Backend System”. I created the OData Model and Service in our backend system and I am testing the
service in our front end system. Let us now debug and investigate which method gets triggered
while READ (one entry, GetEntity) and QUERY (internal table, GetEnititySet) operations are executed.

In the backend system, go to t-code SEGW. Expand the Service Implementation Folder and
POHeaderSet and right click on GetEntity (Read) Operation, choose Go to ABAP Workbench. It will take
you to the related backend method of the DPC (Data Provider Class). If you know the extension class of
your DPC, you can directly go to it using SE24 or SE80 as you would have accessed any other regular
class method.
Put an External Breakpoint (not session breakpoint) on methods POHEADERSET_GET_ENTITY and
POHEADERSET_GET_ENTITYSET as we would be calling the service from the browser or from our
front end system.

Let us go to the t-code /n/IWFND/GW_CLIENT in the front end system and execute
‘/sap/opu/odata/sap/ZGW_PO_SRV/POHeaderSet’ with HTTP Method GET. Hit the execute button.
We have breakpoints at two methods, but only the POHEADERSET_GET_ENTITY_SET method is
triggered as our URI is specified for the whole set (i.e. it is a Query Operation). SAP Netweaver
Gateway has inbuilt capability to figure out the right method of the DPC. Isn’t it cool? Developers just
need to write the correct logic to fetch the data. Integration between service and model is done by
Netweaver Gateway.

Now, let us execute the URI ‘/sap/opu/odata/sap/ZGW_PO_SRV/POHeaderSet(‘4500002013′)’

to Readjust one entry of the DataSet. Execute and your debugger would stop at the breakpoint in method
POHEADERSET_GET_ENTITY.
This was too obvious, but still, we wanted to show it here as some of you might still do not have the right
SAP NetWeaver system. Our screenshots would help those enthusiastic readers.

Enough of POHeaderSet. Let us get some Item data as well. After all, everything is not alway on the

head.

F. Redefine the POItem methods for READ and QUERY Operations

Go to SEGW t-code again, ZGW_PO->Service Implementation->POItemSet->GetEntity (Read) -> Right

Click -> Go to ABAP Workbench.
You will get an information saying it has not been implemented. Carry on, it will take you to the Class
Builder screen. Redefine the method ‘POITEMSET_GET_ENTITY’.

Remove the auto-generated commented code and write your logic to fetch the data. You can refer the
below code. Importing parameter IT_KEY_TAB has the ‘field name’ and the ‘value’ of the Key fields
which are expected to be passed to the Method (usually as the Parameters of the URI).
1
2 METHOD poitemset_get_entity.
3
4 DATA: ls_key_tab TYPE /iwbep/s_mgw_name_value_pair,
5 lv_ebeln TYPE ebeln,
6 lv_ebelp TYPE ebelp.
7
8 * Get the key property values
9 READ TABLE it_key_tab INTO ls_key_tab WITH KEY name = 'Ebeln' .
10 IF sy-subrc = 0.
11 lv_ebeln = ls_key_tab-value.
12 ENDIF.
13
14 * Get the key property values
15 READ TABLE it_key_tab INTO ls_key_tab WITH KEY name = 'Ebelp' .
16 IF sy-subrc = 0.
17 lv_ebelp = ls_key_tab-value.
18 ENDIF.
19
20 * Select one row
21 SELECT SINGLE * FROM ekpo INTO CORRESPONDING FIELDS OF er_entity
22 WHERE ebeln = lv_ebeln
23 AND ebelp = lv_ebelp.
24
25 ENDMETHOD.

Similarly, redefine the method ‘POITEMSET_GET_ENTITYSET’ to write your logic to pull the array of
data, i.e. internal table. You can refer to the snippet below.
1
2 METHOD poitemset_get_entityset.
3 DATA: ls_key_tab TYPE /iwbep/s_mgw_name_value_pair,
4 lv_ebeln TYPE ebeln.
5
6 * Get the key property values
7 READ TABLE it_key_tab WITH KEY name = 'Ebeln' INTO ls_key_tab.
8 IF sy-subrc = 0.
9 lv_ebeln = ls_key_tab-value.
10 ENDIF.
11
12 IF lv_ebeln IS NOT INITIAL.
13
14 SELECT * FROM ekpo INTO CORRESPONDING FIELDS OF TABLE et_entityset
15 WHERE ebeln = lv_ebeln.
16 ELSE.
17
18 SELECT * UP TO 10 ROWS FROM ekpo INTO CORRESPONDING FIELDS OF TABLE et_entityset.
19
20 ENDIF.
21
22 ENDMETHOD.

Please note, all the code snippets are only for reference. The actual logic would depend on the project
requirement and the application’s need.

Now we can perform all the Query Operations on POItemSet which we did for the POHeaderSet. Please
pardon the brevity of the below points as we have already provided the details above for HeaderSet.

i. /sap/opu/odata/sap/ZGW_PO_SRV/POItemSet
Please take note of all the href (links). They work as hints for the developers to build their queries in the
consumer applications.

ii. /sap/opu/odata/sap/ZGW_PO_SRV/POItemSet?$format=json

iii. /sap/opu/odata/sap/ZGW_PO_SRV/POItemSet(Ebeln=’6000000251′,Ebelp=’00010′)
Here we have used the href we found on the above URI result.
iv. /sap/opu/odata/sap/ZGW_PO_SRV/POItemSet?$select=Ebeln,Ebelp,Werks
Pull only three fields from the Data Model.

v. /sap/opu/odata/sap/ZGW_PO_SRV/POItemSet?$select=Ebeln,Ebelp,Werks&$format=json
By now you should know if we need to apply two sets of query options, we can do it by using
Ampersand “&”. For this example we are using “select&format” query option.

vi. /sap/opu/odata/sap/ZGW_PO_SRV/POItemSet/$count

vi. /sap/opu/odata/sap/ZGW_PO_SRV/POItemSet(Ebeln=’6000000251′,Ebelp=’00010′)/Matnr
Fetch just one field from the URI.
Let us stop here for today. In this tutorial, we learned how to redefine the methods and write our custom
logic. We debugged and confirmed that GET_ENTITY method is called for READ Operation and
GET_ENTITYSET method is called for QUERY (array) Operation. We also acquainted ourselves with the
commonly used Query Options.

Till now our data is fetched using GET HTTP method call and POHeader and POIteam are retrieved
independently. In subsequent articles, we would show POST, PUT, PATCH, DELETE etc HTTP Methods.
Also, in real projects, we need to pull item data based on Header and vice-versa (Entity Types needs to
be inter-connected). So there should be some link for the data to flow between datasets. We can achieve
it by Associations and Navigations, which we will definitely see in our next post.

Play around with the Query Options. Make your own parameters and learn what you can do and what you
cannot. All these URIs would be needed in our SAPUI5 application which we will create in the due course
of our tutorial to consume this OData Service and its URIs from our SAPUI5 application.

Bonus Contents for this Post

i. How does the data in importing parameter IT_KEY_TAB look like?

ii. What is the difference between URN, URL and URI?
I do not have much knowledge about these terms and how it works. And as ABAPers, we might not need
to know the details as well. But we should have some understanding of these abbreviations.

These are some high-level components of a URI. Protocol, Host, Port, Service, Resource, Query Options.

In layman’s term the:

URN = Mickey Mouse (Name) – a Name.
URL = Disney World, Florida (Location) – a Locator. How can we reach the Location? Flight, Cruise, by
Road or Train? You can walk too. The mechanism to reach to the location can be compared to the
protocols like HTTP(S), FTP, MAILTO etc. A URL needs to specify a Protocol (it is a must have criteria)
URI = an Identifier.
Both Name and Locator can be an Identifier. Hence URN and URL can be URI.

As mentioned above, URL also needs to tell how to reach the Locator. Can we reach it by http protocol or
ftp or mailto etc. Whenever the protocol is specified, it becomes a URL.

So all URIs are not URLs but all URLs are URI.

In SAP t-code /IWFND/GW_CLIENT, when we are testing our OData Service, we are using the URI or
URL? To be on safer side we should say in one voice URI. But check the screen one more time. We are
also specifying the Protocol as HTTP. So, if you say, we are using a URL, you are technically correct

too.

Wiki summarizes it very precisely:

“One can classify Uniform Resource Identifier (URIs) as locators (URLs), or as names (URNs), or as
both. A Uniform Resource Name (URN) functions like a person’s name, while a Uniform Resource
Locator(URL) resembles that person’s street address. In other words: the URN defines an item’s identity,
while the URL provides a method for finding it”.