OData is the acronym for “Open Data Protocol”.

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.

SAP Netweaver Gateway (blue box within Application Layer in the below
picture) is a technology platform that seamlessly connects devices,
platforms and environments to SAP Enterprise Data using the OData
services.
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.

Here are roughly summarized the key differences between RESTful and
RESTless web services (it does not have to be strictly valid):

1. Protocol

 RESTful services use REST architectural style,

 RESTless services use SOAP protocol.
2. Business logic / Functionality

 RESTful services use URL to expose business logic,

 RESTless services use the service interface to expose business logic.
3. Security

 RESTful inherits security from the underlying transport protocols,

 RESTless defines its own security layer, thus it is considered as more
secure.
4. Data format

 RESTful supports various data formats such as HTML, JSON, text, etc,
 RESTless supports XML format.
5. Flexibility

RESTful is easier and flexible,


RESTless is not as easy and flexible.

6. Bandwidth

 RESTful services consume less bandwidth and resource,

 RESTless services consume more bandwidth and resources.

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.

Unit conversion in odata

https://help.sap.com/doc/saphelp_gateway20sp12/2.0/en-US/52/16751aa3cc4fb3b775cf4237766357/
content.htm?no_cache=true

Filter query in SAP ODATA

/sap/opu/odata/sap/ZDEMO_GW_SRV_SRV/ProductsSet?$filter=ProductId eq ‘HT-
1000’.

link of odata -> /sap/opu/odata/sap/<service_name>/$metadata

Important Odata T-codes

T-code: SEGW to create Service

/n/IWFND/MAINT_SERVICE -> Activate and maintain service

/o/iwfnd/gw_client – SAP Gateway client -> where we run the URI

/IWFND/ERROR_LOG -> check error log

IW Stands for "Information Worker". Name for the team within SAP which developed Gateway.

IW_BEP - Here BEP stands for Business Enablement Provisioning

IW_FND - Here FND stands for Foundation

IWFND component does the Server Job: Example:

Exposing/Registering the service through SICF

 Parsing and validating incoming requests from json/xml to ABAP and routing to IWBEP layer

Data from IWBEP layer is converted into json/XML

1. To update the database we call post_entity_set method

2. Deep entity in oData

IWBEP does backend enablement job. Example:

Service Builder

Parent classes for DP classes and MP classes

how to add service in odata

unit conversion in odata

Function Import: http://www.saplearners.com/function-import-in-sap-odata-service/

What is Function Import?

Function Imports are the actions like the release of a sales
order/purchase order executed in the back-end system. They can be
used whenever the given requirement does not fit into the CRUD-Q
operations.
They are defined at the service level and you can have N number of
function imports functions.

Let’s talk about different runtime artifacts. ending with

 DPC – DPC stands for data provider class – It holds all

standard logic to perform or handle the
request/response. It is generated by SAP standard. Don’t
touch this class as this class will be regenerated/reconstructed
every time you generate the project.
 DPC_EXT – This is the extension of class DPC. All the business
logic will go over here. As a developer, you will spend most of
the time 😉
 MPC – MPC stands for Model provider class. It holds all the
structure information. like types, table types, etc. similar
to DPC this was also generated by standard SAP, hence don’t
touch the class as this will generate/recreate each time you
generate the project.
 MPC_EXT- This is an extension of MPC class when you can
define your custom types and also used for changing the
runtime information of the Data model.

As we have already gone through the basics of OData in Part 2 of

the series, let’s focus on creating an OData service in the system
itself. Let’s begin.
To create an OData service/Project, you need to go to the
transaction SEGW. or /n/IWBEP/SB. The Transaction will look like
below
To create a project, click on the create project button -> You will get
once pop up, provide the project name and description as below. If
you want to put this information in into transport then provide the
package name else save in local object

once you create a project, you will get the details of the project

So an OData project is consisting of the following element

 1. Data Model – This comprised of Entity Type, Association,
Entity Set (details can be checked in Part 1)
2. Service Implementation –Once the Data Model is created
then you can create the business logic either via ABAP code or
through Mapping. This can be done under this section
3. Runtime Artifacts – This will contain the list of ABAP objects
created in the system associate with this project
4. Service Maintenance –In this section, you get the detail
about the service registration like status, RFC destination, etc.

Let’s create a data model first – there are a couple of ways to create
an entity type and entity set, You can create an entity type and
entity set manually by adding individual fields and its
properties/attributes

The other way is to import it from different sources like DDIC,

Search helps, etc
I will go with the approach importing from the DDIC structure, we
will check other approaches in due course.
Then select the list of fields you want to import
Then modify the entity type properties if required and set the key
field. In this case, I have taken the custom structure of sales order
header information, hence I have selected the key field as the order
number
once you finish the wizard, we will see both entity type and set are
created in the project. Now to click on the generate button

Upon generation -> it will ask for names for the Runtime artifacts
Apart from these four classes, there is a technical service
name(ending with SRV) and model(MDL) name generated which is
used for service registration purposes.
Unit Conversion in ODATA

Unit conversion in OData services can be achieved by using the $filter query option to convert units
within the service. For example, to convert miles to kilometers, you can use the following query:

GET /odata/service/Entities?$filter=Distance eq 10.0 * 1.60934

This will return the entities with a distance of 10 miles in kilometers.

Alternatively, you can also use the $expand query option to retrieve related units
and their values. For example:

GET /odata/service/Entities?$expand=RelatedUnits

This will return the entities with their related units and their values. With the help
of these query options, unit conversion can be achieved within the OData service.

 Paging in an OData service allows the client to request a specific subset of

data from the server, which is especially useful for large datasets. This is
typically achieved using query parameters like `$top` and `$skip` in the OData
URL.

- `$top`: Specifies the maximum number of items to be returned in the response.

- `$skip`: Specifies the number of items to be skipped in the response before returning the requested
subset of data.

For example, a client can request the first 50 items by setting the `$top` parameter to 50, and then
request the next 50 items by setting the `$skip` parameter to 50 and `$top` to 50.

The OData service then processes these parameters and returns the requested subset of data to the
client, allowing for efficient retrieval and processing of large datasets.
$batch request is useful to group multiple requests and sends a batch to the data service in
a single HTTP request.

DEEP entity in ODATA

https://community.sap.com/t5/technology-blogs-by-members/step-by-step-development-for-create-
deep-entity-operation/ba-p/13074869

File Upload/Download through NetWeaver Gateway

Here I will explain file handing in NW Gateway in few simple steps.

1) Create a NetWeaver Gateway project in SEGW.

2) Create an Entity type “File” (you can choose any name)

Create an Entity Set for the Entity Type by checking the check box.

Mark Entity Type “File” as Media

3) Create one property “FileName” mark it as key and type as String

4) Generate run-time objects (or artifacts)
5) Go to data provider extension class in edit mode and redefine method

/IWBEP/IF_MGW_APPL_SRV_RUNTIME~GET_STREAM and

/IWBEP/IF_MGW_APPL_SRV_RUNTIME~UPDATE_STREAM. Then add below code.

/IWBEP/IF_MGW_APPL_SRV_RUNTIME~GET_STREAM for download file

DATA: ls_stream TYPE ty_s_media_resource,

ls_upld TYPE zzupld.

READ TABLE it_key_tab ASSIGNING FIELD-SYMBOL(<fs_key>) INDEX 1.

DATA: lv_filename TYPE char30.

lv_filename = <fs_key>-value.

SELECT SINGLE * FROM zzupld INTO ls_upld WHERE filename = lv_filename.

IF ls_upld IS NOT INITIAL.

ls_stream-value = ls_upld-value.

ls_stream-mime_type = ls_upld-mimetype.
copy_data_to_ref( EXPORTING is_data = ls_stream

CHANGING cr_data = er_stream ).

ENDIF.

/IWBEP/IF_MGW_APPL_SRV_RUNTIME~UPDATE_STREAM for upload file

DATA: lw_file TYPE zzupld.

READ TABLE it_key_tab ASSIGNING FIELD-SYMBOL(<fs_key>) INDEX 1.

lw_file-filename = <fs_key>-value.

lw_file-value = is_media_resource-value.

lw_file-mimetype = is_media_resource-mime_type.

lw_file-sydate = sy-datum.
lw_file-sytime = sy-uzeit.

MODIFY zzupld FROM lw_file.

I have created a Z table ZZUPLD to store/extract the file

6) Register the service & service is ready for use

7) Test the service from GW client. Upload the file into the Z table and extract it.

/sap/opu/odata/sap/ZDEMO_FILE_SRV/FileSet(lor.jpg)/$value
Browse your local file system and select your file. Once you upload the file SAP with automatically

change the HTTP method as PUT . Execute the method. lor.jpg file got uploaded with ~status_code =

204.
File got updated in Z table

9) To download the file, just change the HTTP method to GET and execute. Program will read the

existing file from the Z table as per FileName.

Here we are passing lor.jpg so GET operation will download the file we uploaded in Z table.

Similarly you can upload any file type to the Z table and can download them. In my next blog I will

upload files from my UI5 application.