Go to t-code 

SEGW (SAP Gateway Service Builder).

Define Data Model
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.

Entity Type is our very own structure (or a work area (holds just one row)).
Entity Set is an internal table (holds more than one entity/rows).
Let us create our first s Entity Type :
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.

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.

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.

et 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.
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.

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.
Code Snippet:

DATA : ls_key_tab LIKE LINE OF it_key_tab,

lv_ebeln TYPE ekko-ebeln.

* IT_KEY_TAB has key name and value

READ TABLE it_key_tab INTO ls_key_tab
WITH KEY name = 'Ebeln'. " Case sensitive
IF sy-subrc EQ 0.
lv_ebeln = ls_key_tab-value.
ENDIF.

* Select one PO entry

SELECT SINGLE * FROM ekko INTO CORRESPONDING FIELDS OF er_entity
WHERE ebeln = lv_ebeln.

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 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.

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.

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. 
 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.

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).
METHOD poitemset_get_entity.

DATA: ls_key_tab TYPE /iwbep/s_mgw_name_value_pair,

lv_ebeln TYPE ebeln,
lv_ebelp TYPE ebelp.

* Get the key property values

READ TABLE it_key_tab INTO ls_key_tab WITH KEY name = 'Ebeln' .
IF sy-subrc = 0.
lv_ebeln = ls_key_tab-value.
ENDIF.

* Get the key property values

READ TABLE it_key_tab INTO ls_key_tab WITH KEY name = 'Ebelp' .
IF sy-subrc = 0.
lv_ebelp = ls_key_tab-value.
ENDIF.

* Select one row

SELECT SINGLE * FROM ekpo INTO CORRESPONDING FIELDS OF er_entity
WHERE ebeln = lv_ebeln
AND ebelp = lv_ebelp.

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.
METHOD poitemset_get_entityset.
DATA: ls_key_tab TYPE /iwbep/s_mgw_name_value_pair,
lv_ebeln TYPE ebeln.

* Get the key property values

READ TABLE it_key_tab WITH KEY name = 'Ebeln' INTO ls_key_tab.
IF sy-subrc = 0.
lv_ebeln = ls_key_tab-value.
ENDIF.

IF lv_ebeln IS NOT INITIAL.

SELECT * FROM ekpo INTO CORRESPONDING FIELDS OF TABLE et_entityset

WHERE ebeln = lv_ebeln.
ELSE.

SELECT * UP TO 10 ROWS FROM ekpo INTO CORRESPONDING FIELDS OF TABLE et_entityset.

ENDIF.

ENDMETHOD.

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.
URI to send non-Key Filters in the OData Service

?&$filter=Xblnr eq ‘RON MILLS 2’

URI to send multiple Filters in the OData Service

?$filter=Erdat gt datetime’2015-01-01T00:00:00’and Ekgrp eq ’17’and Werks eq ‘4030’.

 Association and Navigation

Association specifies the cardinality between Entity Types. When an Association is created, a Navigation

Property of the Entity Type is also generated. The Navigation tells the relationship between entities with
the help of Association which it points to and the Association, in turn, tell the cardinality relationship
between entities.
Let us create one Association and check how it looks in the system. Go to t-code SEGW, under Data
Model, right-click on the Association folder and Create your first Association.

You need to specify the Key (Dependent Property like Foreign Key concept) between the Principal Entity
and Dependent Entity.

AssociationSet is also generated, in case we want it for multiple entries (i.e tables/arrays).
Hit the Finish icon and Association, Navigation Property and Association Set are generated.

The below figure sums up the relationship between Entities, Navigation Property, Association and
AssociationSet.
Let us check the how the metadata of the service look after we added the above
Association.URI: /sap/opu/odata/sap/ZGW_PO_SRV/$metadata

Did you notice, the metadata has the signature of the Navigation Property of the Entity Type?

Also, check the response below for the Association and AssociationSet definition.
We have been using the below URI to fetch one entry of the PO Header in our previous articles. If you try
to execute the same URI again, this time, you would notice there is an additional link. This additional new
link has the Query Option with the Navigation Property.
URI: /sap/opu/odata/sap/ZGW_PO_SRV/POHeader Set(‘4500002012’)
The result of the POHeaderSet with one primary key as Query option shows a new href link. It gives the
hint that we can navigate to the PO Item data by adding the Navigation Property the Query option.

If you expand one entry of the above result, you would be able to view an alternative link to get the exact
one PO Item.

The alternate Link to get one specific PO Item is displayed in the result of POHeaderSet query. Isn’t that
useful?
URI: /sap/opu/odata/sap/ZGW_PO_SRV/POItemSet(Ebeln=’4500001729′,Ebelp=’00010′)

Que: What is the difference between the below two URIs?

URI 1: /sap/opu/odata/sap/ZGW_PO_SRV/POHeaderSet(‘4500001729’)/HeadToItemNav
URI 2: /sap/opu/odata/sap/ZGW_PO_SRV/POHeaderSet(‘4500001729’)?$expand=HeadToItemNav
Ans: First URI would pull the item level entries only while the second URI would pull the item level entries
and also display the header level data. In short, the $expand query option is expanding the Header
information with the help of the Navigation property and showing the dependent entity type.
 POST Operation

As the name suggests, it is mainly used for creating new entries. For our stand-alone test, we cannot
directly choose POST Operation and execute the URI. POST Operation is a two steps process in t-
code /n/IWFND/GW_CLIENT. We need to first prepare the request stringusing GET Operation and
then use the string to POST data.

i. Execute GET Operation with “Use as Request” option

URI: /sap/opu/odata/sap/ZGW_PO_SRV/zekkoekpoSet(Ebeln=’4580000990′,Ebelp=’00001′)

ii. Execute the POST operation

Oops, you get an error.

We still have two activities to perform.

i. Redefine CREATE_ENTITY method
ii. Call the POST Operation with correct URI

Let us redefine the method and write simple ABAP code to insert entries in the custom table. If you do not
know how to re-define the Data Provider Class method, please refer to our earlier post: Create your first
OData Service.
METHOD zekkoekposet_create_entity.
DATA: ls_ZRK_CODATA LIKE er_entity.

io_data_provider->read_entry_data( IMPORTING es_data = ls_ZRK_CODATA ).

ls_ZRK_CODATA-mandt = sy-mandt.

er_entity = ls_ZRK_CODATA.

INSERT INTO ZRK_CODATA VALUES ls_ZRK_CODATA.

ENDMETHOD.
Before we execute the POST Operation, let us confirm there is no e

ntry in the custom table.

Put an external breakpoint on the CREATE_ENTITY Method to prove that it is triggered while executing
POST operation.

Let us execute the POST-Operation again.

URI: /sap/opu/odata/sap/ZGW_PO_SRV/zekkoekpoSet(Ebeln=’4580000990′,Ebelp=’00001′)

You get the same error “Method Not Allowed”.

Did you mark; our action did not stop at the breakpoint. What does it mean? It means the method was
not triggered at all and the URI is not the correct one.

Scroll up and check, we specifically said: “Call the POST Operation with correct URI”. So the correct
URI to POST is: /sap/opu/odata/sap/ZGW_PO_SRV/zekkoekpoSet
Finally, the Method is triggered and the debugger stops at the break point.

Check the status is “Created”.

Let us validate if the entry is really populated in the custom table.

Will see an example with RFC