Module 26: OData Services (ABAP Backend)

OData (Open Data Protocol) is SAP’s standard way to expose business data and operations as RESTful services.
In ABAP, OData services are commonly used to serve Fiori/UI5 applications and external consumers.

---

1. OData Concepts (Foundation)

What is OData?

OData is a REST-based protocol that supports:

• Standard HTTP methods
• CRUD operations
• Query options
• Metadata-driven services

Key Idea

OData exposes business entities, not database tables.

---

Core OData Building Blocks

Concept	Meaning
Entity	Business object (e.g. SalesOrder)
Entity Set	Collection of entities
Property	Field of an entity
Association	Relationship between entities
Navigation	Traversal between entities
Service	Endpoint exposing entities

---

HTTP Methods → CRUD-Q Mapping

HTTP Method	Operation
GET	Read / Query
POST	Create
PUT / PATCH	Update
DELETE	Delete
GET (with $filter, $expand)	Query

---

2. SEGW (Service Builder)

What is SEGW?

SEGW is the SAP Gateway Service Builder used to create ABAP-based OData services.

Legacy vs Reality

SEGW is not obsolete.
It is still heavily used in productive ECC and S/4 systems.

---

SEGW Architecture

SEGW Project
├─ Data Model
│ ├─ Entity Types
│ ├─ Entity Sets
│ └─ Associations
├─ Service Implementation
│ ├─ *_DPC_EXT (Data Provider)
│ └─ *_MPC_EXT (Model Provider)

---

3. Entity Sets & Associations

---

3.1 Entity Types & Entity Sets

• Entity Type → Structure definition
• Entity Set → Table-like collection

Example:

• Entity Type: SalesOrder
• Entity Set: SalesOrderSet

Design Rule

Design entities based on business semantics, not tables.

---

3.2 Associations & Navigation

Associations define relationships between entities.

Example:

• SalesOrder → Items (1:n)

SalesOrderSet → ItemsSet

Navigation allows:

/SalesOrderSet('500001')/Items

CDS Parallel

Associations in OData are conceptually similar to CDS associations.

4. CRUD-Q Operations (Very Important)

CRUD-Q operations are implemented in the DPC_EXT class.

4.1 CREATE (POST)

METHOD salesorderset_create_entity.
  " Read input data
  io_data_provider->read_entry_data(
    IMPORTING es_data = ls_data
  ).

  " Create logic
ENDMETHOD.

4.2 READ (GET – Single & Collection)

Single entity:

METHOD salesorderset_get_entity.
ENDMETHOD.

Collection:

METHOD salesorderset_get_entityset.
ENDMETHOD.

4.3 UPDATE (PUT / PATCH)

METHOD salesorderset_update_entity.
ENDMETHOD.

4.4 DELETE (DELETE)

METHOD salesorderset_delete_entity.
ENDMETHOD.

4.5 QUERY Options ($filter, $orderby, $top)

Handled automatically if:

• You delegate filtering to framework

• Or use io_tech_request_context

Performance Rule

Always push filtering to DB (Open SQL / CDS), not ABAP loops.

5. Deep Structures (Deep Insert & Deep Read)

What is a Deep Structure?

A deep structure contains:

• Header data

• One or more nested internal tables

Used for:

• Header + Item creation

• Complex object graphs

5.1 Deep Insert Example

Payload:

{
  "SalesOrder": "500001",
  "Items": [
    { "Item": "10", "Material": "MAT1" },
    { "Item": "20", "Material": "MAT2" }
  ]
}

ABAP Handling:

io_data_provider->read_entry_data(
  IMPORTING es_data = ls_deep_data
).

Transaction Rule

Deep inserts must be transactionally consistent (single LUW).

5.2 Deep Read ($expand)

/SalesOrderSet('500001')?$expand=Items

Modern Best Practice

Prefer CDS-based OData with $expand for deep reads where possible.

6. Error Handling in OData

How Errors Are Returned

• HTTP status codes (400, 404, 500)

• Error payloads

• Message container

mo_context->get_message_container( )->add_message(
  iv_msg_type = 'E'
  iv_msg_text = 'Invalid Sales Order'
).

UI5 Expectation

UI5 expects meaningful error messages, not short dumps.

7. OData Performance Best Practices

Follow These Rules

• Use CDS as data source

• Avoid SELECT inside loops

• Implement paging

• Use $select to limit fields

• Support $filter and $expand

8. SEGW OData vs RAP OData

Aspect	SEGW (Gateway Service Builder)	RAP (RESTful ABAP Programming Model)
Approach	Code-first	Model-first
Primary Tool	SEGW transaction	ADT (Eclipse)
Data Model	Manually defined entities	CDS-based data model
Boilerplate Code	High (MPC/DPC methods)	Very low
Business Logic Location	DPC_EXT methods	Behavior Definitions & Handlers
CRUD Implementation	Manual (one method per operation)	Framework-managed
OData Version	OData V2	OData V4
Transaction Handling	Manual (COMMIT/ROLLBACK)	Framework-managed
Validation Logic	Custom ABAP code	Declarative + behavior validation
Authorization	Manual checks	CDS-based authorizations
Draft Handling	Custom implementation	Built-in
Deep Structures	Manual handling	Native support
Side Effects	Manual	Declarative
Performance Optimization	Developer responsibility	Framework-optimized
Extensibility	Limited	Strong (extensions, projections)
Upgrade Safety	Medium	High
Future Proof	❌ (Maintenance only)	✅ (Strategic)

8.1 Transaction Handling

Area	SEGW	RAP
COMMIT	Explicit	Automatic
Rollback	Manual	Automatic
LUW control	Developer	Framework

::: Say: “RAP enforces transactional consistency by design.” :::

SAP Direction

SEGW is a code-heavy, manual OData framework, while RAP is a CDS-based, model-driven framework that provides built-in transaction handling, validation, authorization, and extensibility. RAP is SAP’s strategic future.

9. Common Mistakes

Avoid These

• Exposing tables directly

• Business logic in DPC methods

• Ignoring query options

• No transaction handling

• Poor error messages

10. Summary

• OData exposes business entities via REST

• SEGW is the classic ABAP OData tool

• Entity sets represent collections

• CRUD-Q maps to HTTP methods

• Deep structures handle complex payloads

• Proper error handling is essential

• RAP is the strategic future

11. Practice Exercises

• Create a SEGW project with one entity set.

• Implement GET_ENTITYSET.

• Add CREATE operation.

• Implement deep insert (header + items).

• Test with /IWFND/GW_CLIENT.

12. What’s Next?

➡️ Module 27: RAP (RESTful ABAP Programming Model)

Learning Tip

If you understand SEGW OData well, RAP will feel much easier.