SAP OData for a Functional.....

OData is a RESTful API.

Generally most of the time we are using two types of APIs: 1. REST and 2. SOAP

Simple Object Access Protocol (SOAP) and Representational State Transfer (REST)

This is the general approach to understand the OData flow in the Easy way.

1. Data is created and saved in the relevant SAP database tables.

2. Once the data is saved, an OData service (configured for this purpose) is triggered. This can happen through an event (like data creation or update) or manually by calling the OData service from SAP.

3. The OData service is handled by the SAP Gateway, which processes the request in the application layer.

4. The Gateway reads the data from the SAP database tables and converts it into an appropriate format (usually JSON or XML).

5. The OData service transports the customer data as a payload (JSON/XML) to the endpoint URL of the third-party software.

6. The processed data is sent from the SAP system to the third-party software via HTTP(S) in the form of a REST API call.

7. The third-party system receives the customer data at its defined endpoint (API URL).

8. It processes the received data and saves it in its own database according to its internal structure.

9. The third-party software can send a response back to SAP (e.g., success or failure status).

Here is the backend flow from the technical Prospective

A client sends an HTTP request (GET, POST, PUT, DELETE) to an SAP Data service endpoint.

The SAP Gateway is responsible for routing the incoming request to the correct Data service.

The service is registered and activated in SAP Gateway using transaction /IWFND/MAINT_SERVICE.

The Model Provider Class (MPC) defines the metadata of the service, including entity types, properties, and relationships.

The MPC is responsible for providing the metadata when requested (e.g., $metadata).

The Data Provider Class (DPC) is invoked by the Gateway to process the request based on its type (GET, POST, etc.).

The DPC interprets the request and identifies which method needs to be called (e.g., GET_ENTITYSET, POST_ENTITY).

For data retrieval or modification, the DPC interacts with the backend system (e.g., SAP ECC, S/4HANA).

If data is requested, the DPC queries the backend system (e.g., fetching customer records).

If data is being modified (POST, PUT), the DPC handles the creation or update of records in the backend.

The DPC_EXT (extension of DPC) contains custom business logic, validation, or enhancements to standard DPC methods.

The DPC_EXT can be used to implement custom rules, transformations, or additional processing before data is returned.

After data is processed, the DPC formats the response in Data-compliant formats like JSON or XML.

The response includes the requested data, confirmation messages, or status codes, based on the operation.

The SAP Gateway then receives the response from the DPC.

The Gateway formats the response appropriately and prepares to send it to the client.

If an error occurs, such as invalid input or system failure, the error is handled and returned in a standardized error format.

The error message is sent back to the client, detailing the issue (e.g., "Invalid Request" with error code).

The final response is sent back to the client (web/mobile app), completing the transaction.

The Data service ensures seamless data exchange between clients and SAP backend systems, following the Data protocol.

Some Imp. Transactions:-

/IWFND/MAINT_SERVICE - Register and Activate the Service

/n/IWFND/GW_CLIENT = By this T code, You can see the URL and we can see the values are passing correct or not, Used for testing

CG3Y - To download the file

CG3Z - To Upload the file

How to check and what are the fields is there for a Odata Service:-

Go to SEGW >> Go to your Service >> Expand your Service >> Expand the Data Model >> Expand Entity types >> Expand the Properties

HTTP Status Codes

200 OK: The request was successful.

201 Created: A new record was created (POST method).

204 No Content: The operation succeeded, but no content is returned (DELETE method).

400 Bad Request: There’s an issue with the request syntax or parameters.

401 Unauthorized: Authorization is required.

404 Not Found: The requested resource doesn’t exist.

500 Internal Server Error: A server-side issue occurred.

In OData most of the functionality is developed from the Runtime artifacts

MDL = Defines the metadata (entities, properties, associations) of the Data service. Represents the data model structure and metadata for the service. Used to define how data is structured and what metadata will be exposed.

SRV = Defines the service logic for handling data operations (CRUD). Contains business logic and operations for processing Data requests. Used to implement CRUD operations and service logic to interact with the backend.

MPC = Defines the service’s data model, including entities, entity sets, associations, and properties. This class is used to generate the metadata ($metadata) of the service.

MPC_EXT = The MPC_EXT class is an extension of the Model Provider Class. While the standard MPC class defines the data model (structure, entities, and relationships), the MPC_EXT class allows you to extend this model with additional entities, properties, and associations. Essentially, it enables you to add custom fields or modify the data model without altering the base service.

DPC - Contains the business logic for the service. It processes incoming requests, fetches data from the backend (or performs other operations), and sends the response back to the client.

DPC_EXT = The DPC_EXT class extends the Data Provider Class, which contains the logic for handling CRUD operations (Create, Read, Update, Delete) on the Data entities. The DPC_EXT allows you to implement your custom business logic for these operations. This extension is crucial when you need to modify the standard behaviour of data handling for your specific requirements.

Service Registration = Links the OData service with the backend system, enabling it to be consumed by external clients through the service URL.

In Odata we are using some URI option. Below URI are the most used URIs in

$batch:- Groups multiple OData requests into a single batch request to optimize network calls.

$filter:- Filters data based on specific conditions.

$format=json:- Specifies the response format as JSON (default in most cases).

$format=xlsx:- Specifies the response format as an Excel file (if supported by the service).

$metadata: Provides metadata about the OData service, such as available entity sets, types, and associations.

Thank you