API (Application Programming Interface)

List of API belong to SAP AND SAP ABAP?

• RFC
• Web Services - SOAP (Simple Object Access Protocol) | REST (Representational State Transfer)
• OData
• SAP Cloud Platform APIs (SCP)
• SAP API Business Hub
• SAP Cloud Platform API Management

RFC -

What is RESTful? Tcode = SICF

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.

What is SOAP?
SOAP stands for Simple Object Access Protocol. It's a messaging protocol for interchanging data
in a decentralized and distributed environment. SOAP can work with any application layer
protocol, such as HTTP, SMTP, TCP, or UDP. It returns data to the receiver in XML format.

WSDL - Web Services Description Language

O data services (SEGW)
O-data services: OData(Open Data Protocol) is a Web protocol for unlocking and sharing data,
The OData protocol supports serialization in multiple popular formats, including JSON and
Atom/XML. With OData, developers can build cross-platform Web and mobile Applications.

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.

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

System Alias:
System Alias = a logical name that tells SAP Gateway which backend system to use.
Like(LOCAL QUALITY PRODUCATION)

what is mean by stateless and stateful communication in Odata Service in sap?

1. Stateless Communication (Default in OData)

Meaning:
Each OData request is Independent.
The SAP Gateway does not remember anything from previous requests.
Every request must contain all required information.
Characteristics
• No session data stored on server
• Better scalability
• Default and recommended for OData
• Works well with HTTP
Example (Stateless)
GET /sap/opu/odata/sap/ZSALES_SRV/SalesOrderSet('50000123')
If you send the same request again:
• Gateway does not remember previous calls
• Authorization, filters, and keys are reprocessed
SAP Example
• Fiori apps
• External system integration
• Mobile applications
 SAP OData services are stateless by design

2. Stateful Communication
Meaning
The server keeps context (state) between multiple requests.
Examples of state:
• Internal tables
• Global variables
• Locks
• Temporary selections
How Stateful Works in SAP
• Uses SAP user session
• Relies on ABAP memory / session memory
• Same session ID must be reused
Example (Stateful)
First call stores data in memory
gv_salesorder = '50000123'.
Second call uses that stored value
READ TABLE gt_items WITH KEY vbeln = gv_salesorder.
This breaks stateless principles.

3. Why Stateful Is NOT Recommended in OData

Issue Explanation
Scalability Session consumes server resources
Load balancing Requests may hit different app servers
Timeouts Session may expire
Hard to debug Hidden dependencies
SAP Fiori Fiori assumes stateless services

Here are the simple step-by-step steps to create an OData Service in SAP (Gateway – ABAP, OData V2):

1. Create Project (SEGW)

1. Go to Transaction: SEGW
2. Click Create Project
3. Enter:
o Project name
o Description
4. Click Save
2. Define Data Model
a) Create Entity Type
• Right-click Data Model → Entity Types → Create
 • Add properties
• Mark Key fields
b) Create Entity Set
• Right-click Entity Type → Create Entity Set

3. Generate Runtime Objects

• Click Generate Runtime Objects
• This creates:
o MPC / MPC_EXT
o DPC / DPC_EXT

4. Implement Service Logic (DPC_EXT)

Go to DPC_EXT class and implement methods:
• GET_ENTITYSET → Read multiple records
• GET_ENTITY → Read single record
• CREATE_ENTITY
• UPDATE_ENTITY
• DELETE_ENTITY

5. Register & Activate Service

1. Go to /IWFND/MAINT_SERVICE
2. Click Add Service
3. Select system & service
4. Click Add Selected Services

6. Test the Service

• Use /IWFND/GW_CLIENT
• Or browser:
/sap/opu/odata/sap/ZMY_SERVICE_SRV/

7. (Optional) Add Annotations

• Use MPC_EXT → DEFINE method
• Or annotation modeler

Quick Flow
SEGW → Model → Generate → Code → Register → Test

What was the need for OData in SAP? It is easy to understand and extensible and provides
consumers with a predictable interface for querying a variety of data sources.

If you create project by default four folder created → Data Model.

Service Implementation.
Runtime Artifacts (CRUD).
 Service Maintenance.

Data model (CREATE):

Entity Types: Entity Type is our very own structure (or a work area (holds just one row)).
Association: It Define the relationship between different entity types: Example Relationship
between and EMPLOYE and DEPARTMENT.
Association Set: An Association set groups Association instances (similar to how an Entity Set
groups Entity Type instances).
Entity Sets: Entity Set is an internal table (holds more than one entity/rows).
Deep Entity sets: Deep insert is used to POST(Create) the nested structure of feed/collections to
the back-end system. It is opposite to the $expand in which we GET(Read) the nested structure
of collections.
Complex Type: complex types consist of a collection of properties without a unique key.
Function Import: The Open Data Protocol (OData) includes standard CRUD (Create, Retrieve,
Update, and Delete) operations that map to the HTTP methods POST, GET, PUT/MERGE/PATCH,
and DELETE. In addition, OData supports further service operations (function imports) that can
be invoked(आवाहन) by the HTTP methods GET or POST for anything that cannot be mapped to
the standard CRUD operations. You can implement such additional service operations in the
Service Builder by creating function imports within your data model.

OData HTTP What it meant to an ABAPer

Operation Method
Create POST Insert <table> from <workarea>
Read GET Select Single * From <table> into <workarea>
Update PUT/PATCH Update <table> set <workarea>
Delete DELETE Delete from <table>
Query GET Select * From <table> Into Table
Function GET/POST Everything covered by GET and POST. But only use if scenario does not fit into
Import CRUDQ operations.

Navigation property: Entity Types include one or more navigation properties.

Data model option:

Importing Data Model from File: importing of the data model files defined by external model
Importing a DDIC Structure: import an existing ABAP (DDIC) structure and reuse this data to
create new complex types and entity types with ease
You can import the following DDIC structures into the Service Builder:
• Views
• Database tables
• Structures
Importing a Data Source (RFC/BOR Interface): Import RFC/BOR Interface function with which you
can import an existing data source and reuse this data to create new entity types with ease.
-Creating an entity type from a data source comprises three steps:
• Importing the data source.
• Selecting the parameters from the selected data source.
• Editing the selected parameters.
Importing Search Help as a Data Source: In the Service Builder, you can reuse existing Search
Helps in a system as data sources to create new entity types.
Including an OData Service: Including OData Service function to include models in the Service
Builder and then create associations using the included models.

Redefining Services: The Service Builder allows you to redefine both OData services created using
SAP Gateway and the external services (SPI, BW Query, GenIL) that have been created using
different frameworks.
• Extending an OData Service Using Service Builder
• Redefining OData Service (SAP GW)
• Redefining Services from External Framework (SPI, BW Query, GenIL)

Tcode for odata services (SEGW)

Structure of OData Service?

It have mainly two parts
1) Service document - Service documents consists of all list of resources URI’s that can be
accessible.
2) Service metadata document - Service metadata documents contains Meta data of all
elements in the service. You can see the metadata of a service by simple adding
“$metadata” to the service URI.

Key Classes in SAP Gateway Service (Runtime Artifacts)

1. Model Provider Class (MPC)
o Inherits from /IWBEP/CL_MGW_ABS_MODEL
o Defines the service interface for the Gateway service.
2. Model Provider Extension Class (MPC_EXT)
o Contains annotations for the model (e.g., entity types, associations).
3. Data Provider Class (DPC)
o Inherits from /IWBEP/CL_MGW_ABS_DATA
o Provides the core Gateway service functionality.
4. Data Provider Extension Class (DPC_EXT)
o Handles CRUD operations (Create, Read, Update, Delete) in methods like
CREATE_ENTITY, GET_ENTITY.
5. SRV (Service Implementation)
o The service definition in SAP Gateway.
6. MRD (Metadata Repository)
o Contains the service metadata for the service.
 Key Points:
• MPC defines the interface; DPC provides service logic.
• MPC and DPC communicate via configuration, not direct coding.
• Annotations and CRUD operations are written in MPC_EXT and DPC_EXT respectively.

If you have Base Classes Like MPC and DPC why we need to DPC_EXT and MPC_EXT?

You need DPC_EXT (Data Provider Extension) and MPC_EXT (Model Provider Extension) classes
because they are designed for customization and future-proofing in OData services (especially SAP
Gateway), allowing you to add business logic or modify the data model without overwriting the system-
generatedbase MPC and DPC classes.

OData Query Options – ABAP Perspective

OData Query Option Coding Required ABAP Equivalent / Meaning

$select No Field projection → SELECT FLD1 FLD2 FROM DBTAB
$count No Count rows → SELECT COUNT(*) FROM DBTAB
$expand No Join tables → LEFT OUTER JOIN
$format No Output format (e.g., JSON, XML)
&sap-ds-debug=true No Navigate service metadata easily
$orderby Yes Sort → SORT itab BY property
$top Yes Limit rows → SELECT ... UP TO N ROWS FROM DBTAB
$skip Yes Pagination → Skip rows in internal table
$filter Yes Filter → SELECT ... WHERE field = value
$inlinecount Yes Count with data (legacy for OData v2)
$skiptoken Yes Advanced paging (e.g., cursor-based pagination)

OData Query String: HTTP Status Code?

Status Code Categories:

• 1xx – Informational (rare in OData)

• 2xx – Success
• 3xx – Redirection
• 4xx – Client Errors
• 5xx – Server Errors
 OData HTTP Status Codes – Summary Table

Status Code Message Description

200 OK GET request successful
201 Created POST request successful
203 Non-Authoritative Info POST processed successfully (with modified data)
204 No Content DELETE request successful, no content returned
400 Bad Request Invalid syntax or parameters in URI
401 Unauthorized Authentication required
403 Forbidden User lacks authorization
404 Not Found Record not found
405 Method Not Allowed HTTP method not allowed for the resource
406 Not Acceptable Format not supported
500 Internal Server Error Generic server-side failure
501 Not Implemented Functionality not supported on server
502 Bad Gateway Gateway/proxy error
503 Service Unavailable Server temporarily unavailable

OData Query String for GET Method/ What OData operation you have work.

DPC_EXT
OData Query (URI) Key Parameters
Method
/sap/opu/odata/sap/<SERVICE>/<ENTI
GET_ENTITYSET Export: ET_ENTITYSET
TYSET>
GET_ENTITYSET ...?$format=json Export: ET_ENTITYSET
...? $filter=Property1 eq 'value' and Import: IT_FILTER_SELECT_OPTIONS,
GET_ENTITYSET
Property2 eq 'value' IV_FILTER_STRINGExport: ET_ENTITYSET
...? $orderby=Property1,Property2...?
GET_ENTITYSET $orderby=Property1 desc, Property2 Import: IT_ORDERExport: ET_ENTITYSET
desc
Import: IV_SEARCH_STRINGExport:
GET_ENTITYSET ...? $search='value'
ET_ENTITYSET
Import: IS_PAGING-TOPExport:
GET_ENTITYSET ...? $top=10&$skip=20
ET_ENTITYSET
GET_ENTITY <ENTITYSET>(Key='value') Import: IT_KEY_TABExport: ER_ENTITY
GET_ENTITY Import: IT_NAVIGATION_PATHExport:
Navigated call with association
(with nav) ER_ENTITY
DPC_EXT
OData Query (URI) Key Parameters
Method
Import: IV_ENTITY_NAME,
EXPANDED_ENTI IV_ENTITY_SET_NAME,
...? $expand=<Navigation Entity>
TY IT_NAVIGATION_PATH,
IT_KEY_TABExport: ER_ENTITYSET

METADATA: In layman’s term metadata means the structure and properties or full skeleton (X-
Ray view).

How to pass multiple fields of the Composite Primary Key?

/sap/opu/odata/sap/ZMY_SERVICE_SRV/MyEntitySet(
SalesOrder='500000001',
Item='00010')

-------------------------------------------------------------------------------------------------------------------------------
BusinessScenario:

Scenario: OData Service for Sales Order Creation (POST Operation)

Project:
Developed a custom Fiori app to create Sales Orders in S/4HANA.

Steps Involved:
1. Backend Development (SAP Gateway System):
o Created custom OData service using SEGW (SAP Gateway Service Builder).
o Defined Entity: SalesOrderHeader and SalesOrderItems.
2. Implemented POST Operation:
o In the DPC_EXT class, implemented CREATE_ENTITY method to handle the POST call.
o Used BAPI_SALESORDER_CREATEFROMDAT2 to create sales orders.
3. CALL FUNCTION 'BAPI_SALESORDER_CREATEFROMDAT2'
4. EXPORTING
5. order_header_in = ls_header
6. TABLES
7. order_items_in = lt_items
8. return = lt_return.
9. Service Registration:
o Registered the service in /IWFND/MAINT_SERVICE.
o Tested using SAP Gateway Client (/IWFND/GW_CLIENT).
10. Fiori Integration:
o Consumed the OData service in a SAPUI5 Fiori app for order creation.
o Frontend used POST method to send sales order data from the UI.
 Real-Time Issues Faced:
• CSRF token error during initial testing → Resolved by fetching token via GET before POST.
• Missing authorization (S_SERVICE) → Coordinated with Basis to update roles.
• BAPI return handling → Errors had to be parsed and shown on UI clearly.

Outcome:
Successfully enabled end users to create sales orders directly from a custom Fiori app using an OData
POST operation.

SAP UI5 / Fiori – Interview Summary

What is Fiori?
• SAP Fiori is a design language for building modern SAP apps using the UI5 framework.
• Fiori apps follow a role-based, responsive, and simple user experience model.
Types of Fiori Applications:
• Transactional: Perform actions like creating Sales Orders, POs, Invoices.
• Fact Sheets: Drill-down views for master and contextual data.
• Analytical: Real-time KPIs and dashboards with embedded analytics.

Standard Fiori App Activation Steps:

1. Fiori Library:
o Check installation, configuration, extensibility, and support via the Fiori Apps Library.
o Example: “Approve Timesheets” App → Check prerequisites.
2. Frontend Service Activation:
o Transaction: SICF → Activate the required SAPUI5 application/service.
3. Backend OData Service Activation:
o Transaction: /IWFND/MAINT_SERVICE → Add and activate OData services.
4. Authorizations:
o Assign standard PFCG roles (with BASIS support) to admins and users.
5. System Alias Assignment:
o Transaction: /IWFND/V_MGDEAM → Map frontend to backend system.
6. Fiori Launchpad Configuration:
o Transaction: /UI2/FLPD_CUST (Client-specific Designer)
o Create custom catalogs and link standard catalogs.
7. Tiles & Target Mapping:
o Add Tiles to the catalog and ensure Target Mappings are assigned.

Important Notes:
• System Alias: Used for routing backend calls in SAP Gateway.
• Find Hostname & Port:
o T-Code /UI2/FLP → Launchpad
o T-Code /UI2/FLPD_CUST → Designer
• Error Handling:
o T-Code /IWFND/ERROR_LOG → Check OData and service errors.
 How to Debug a Fiori Application:
• Browser Developer Tools (F12):
Check Console & Network tabs for frontend/UI5 issues.
• SAP Gateway Client (/IWFND/GW_CLIENT):
Test OData calls directly.
• OData Error Log (/IWFND/ERROR_LOG):
View backend errors related to service calls.
• ABAP Debugging:
Set breakpoints in the DPC_EXT class method (e.g., GET_ENTITY, CREATE_ENTITY) via SE80 or
SE24.

Debugged:
To debug a GET_ENTITY method, set an external breakpoint in the method and execute the
service request via Gateway Client or tools like Postman.

/sap/opu/odata/IWBEP/<SERVICE_NAME>/ENTITYSETNAME(KEY1=value1, KEY2=value2)
Copy
Steps to Debug

1. Set External Breakpoints

Place an external breakpoint in the relevant method (e.g., GET_ENTITY, GET_ENTITYSET) of the
DPC_EXT class. Ensure the code is activated and the correct method is selected.

2. Use Gateway Client

Execute the service request using /IWFND/GW_CLIENT. This tool simulates browser behavior
and allows you to test OData services without requiring X-CSRF tokens for operations like POST
or DELETE.

3. Debugging via SICF

• If debugging does not trigger, activate debugging in SICF:

• Open transaction SICF.
• Locate your service.
• Navigate to Edit > Debugging > Activate Debugging.
• Re-execute the request.

4. Check Error Logs

Use /IWFND/ERROR_LOG for front-end errors and /IWBEP/ERROR_LOG for back-end errors.
These logs provide detailed insights into request failures and allow replaying requests for
further analysis.

5. Trace Execution

Enable traces using /IWFND/TRACES to capture detailed execution data. Adjust trace levels as
needed and analyze payloads or performance metrics.

6. Cache Cleanup
If changes are not reflected, clear caches using transactions like /IWFND/CACHE_CLEANUP or
/IWBEP/CACHE_CLEANUP.

How to Identify OData Services Used in a Fiori App:

• F12 → Network tab:
Filter by “$metadata” or “/sap/opu/odata” to see OData calls.
Metadata: Data about data. Example: (e.g., field names, types, keys, relationships).
• SAP Fiori App Library:
Search the app → Check the “Implementation Information” tab for OData service names.
• /IWFND/MAINT_SERVICE:
Use this to activate or search for services in the system.