SAP OData V4 Service: From SEGW to CDS — A Developer's Guide

The vast majority of SAP Fiori applications and external integrations run over OData services. For years, SEGW (SAP Gateway Service Builder) was the standard tool for building OData services. With S/4HANA and the RAP (ABAP RESTful Application Programming) model, however, this approach is rapidly giving way to CDS-based OData V4.

In this article I explain the difference between the SEGW and CDS-based approaches, when to use which, and how to build an OData V4 service with CDS Views — with real code examples throughout.

Why Move from OData V2 to V4?

OData V4 offers significant technical and functional advantages over V2:

• Richer querying: V4 supports aggregation (grouping, totals) directly in the URL via $apply. In V2 this required writing separate service methods.
• Proper type support: V4 correctly handles Edm.Date, Edm.TimeOfDay, Edm.DateTimeOffset and similar types. Date/time handling in V2 was a frequent source of bugs.
• Actions and Functions: In V4, business logic is modelled as Actions (data-changing) and Functions (read-only) in a standardised way.
• SAP's direction: All new SAP Fiori apps and Joule integrations are being built on OData V4. V2 is no longer recommended for new development.
• CDS integration: Building an OData V4 service from a CDS View keeps the data model and service definition in a single place — no synchronisation drift.

SEGW vs CDS-Based Approach

Building an OData V4 Service with CDS Views

Let's walk through a concrete example: a sales order list service.

Step 1 — Root CDS View (Interface View)

@AbapCatalog.sqlViewName: 'ZI_SALESORDER'
@AbapCatalog.compiler.compareFilter: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Sales Order Interface View'

define view ZI_SalesOrder
  as select from vbak as so
  association [0..*] to ZI_SalesOrderItem as _Items
    on $projection.SalesOrder = _Items.SalesOrder
{
  key so.vbeln      as SalesOrder,
      so.erdat      as CreationDate,
      so.ernam      as CreatedBy,
      so.kunnr      as SoldToParty,
      so.netwr      as NetValue,
      so.waerk      as Currency,
      so.vbtyp      as SalesDocumentType,

      /* Association */
      _Items
}

Step 2 — Consumption View (the OData-facing layer)

@EndUserText.label: 'Sales Order Consumption View'
@AccessControl.authorizationCheck: #NOT_REQUIRED

@Metadata.allowExtensions: true

define root view entity ZC_SalesOrder
  provider contract transactional_query
  as projection on ZI_SalesOrder
{
  key SalesOrder,
      CreationDate,
      CreatedBy,
      SoldToParty,
      NetValue,
      Currency,
      SalesDocumentType,

      /* Redirected association */
      _Items : redirected to composition child ZC_SalesOrderItem
}

Step 3 — Service Definition

@EndUserText.label: 'Sales Order Service'
define service ZSD_SalesOrder {
  expose ZC_SalesOrder    as SalesOrder;
  expose ZC_SalesOrderItem as SalesOrderItem;
}

Step 4 — Service Binding (OData V4)

In Eclipse ADT, right-click the Service Definition → New Service Binding → select OData V4 - UI as the Binding Type. After activation the service URL is generated automatically.

Key CDS Annotations

In CDS-based OData V4, annotations control both the service's behaviour and the appearance of Fiori Elements applications. (For the financial-reporting side of CDS Views, see the ACDOCA guide.) The most commonly used ones:

@UI.lineItem: [{ position: 10, label: 'Sales Order' }]
SalesOrder,

@UI.lineItem: [{ position: 20, label: 'Customer' }]
@UI.selectionField: [{ position: 10 }]
SoldToParty,

@UI.lineItem: [{ position: 30, label: 'Net Value', criticality: 'NetValueCriticality' }]
@UI.dataPoint: { title: 'Net Value' }
NetValue,

@Search.searchable: true
@Search.defaultSearchElement: true
SoldToParty,

@ObjectModel.filter.transformedBy: 'NUMC'
SalesOrder,

@Metadata.layer: #CUSTOMER
annotate view ZC_SalesOrder with
{
  @UI.facets: [{
    id:       'GeneralInfo',
    type:     #COLLECTION,
    label:    'General Information',
    position: 10
  }]
  SalesOrder;
}

CRUD Operations with Business Object Interface

The steps above are sufficient for read-only (GET) services. CREATE, UPDATE and DELETE operations require a Behavior Definition.

Behavior Definition

managed implementation in class ZBP_SalesOrder unique;
strict ( 2 );

define behavior for ZC_SalesOrder alias SalesOrder
persistent table vbak
lock master
authorization master ( instance )
{
  create;
  update;
  delete;

  field ( readonly )  SalesOrder;
  field ( mandatory ) SoldToParty, NetValue, Currency;

  association _Items { create; }

  action confirmOrder result [1] $self;

  mapping for vbak corresponding
  {
    SalesOrder   = vbeln;
    CreationDate = erdat;
    SoldToParty  = kunnr;
    NetValue     = netwr;
    Currency     = waerk;
  }
}

Behavior Implementation (key methods)

CLASS ZBP_SalesOrder DEFINITION
  PUBLIC ABSTRACT FINAL
  FOR BEHAVIOR OF ZC_SalesOrder.

  PUBLIC SECTION.
    CLASS-METHODS confirmOrder
      FOR ACTION SalesOrder~confirmOrder
      IMPORTING keys FOR SalesOrder~confirmOrder
      RESULT result.

ENDCLASS.

CLASS ZBP_SalesOrder IMPLEMENTATION.

  METHOD confirmOrder.
    " Business logic goes here
    " Process confirmation for each order in keys
    LOOP AT keys ASSIGNING FIELD-SYMBOL(<key>).
      " ...
      APPEND VALUE #(
        %tky = <key>-%tky
        " result fields
      ) TO result.
    ENDLOOP.
  ENDMETHOD.

ENDCLASS.

Service Activation and Testing

Once the Service Binding is activated:

• Preview: Open the Service Binding in Eclipse ADT → click "Preview" to open the Fiori Elements app directly in the browser.
• Metadata check: Send a GET request to /sap/opu/odata4/sap/<service_name>/srvd/sap/<service_name>/0001/$metadata. The V4 metadata XML is returned.
• Postman testing: Use Bearer token (SAP OAuth) or Basic Auth and add $top=10 to verify data is returned.
• Error log: Instead of /IWFND/ERROR_LOG, use the ABAP Application Log (transaction SLG1) for troubleshooting.

When Is SEGW Still Valid?

Despite all the advantages of CDS-based V4, there are scenarios where SEGW remains the right choice:

• Legacy systems (ECC, S/4HANA pre-1809): CDS + RAP is fully supported from S/4HANA 1809 onwards. On older systems SEGW is the only option.
• Maintaining existing V2 services: If a working V2 service exists, continuing to maintain it is usually more pragmatic than rewriting it.
• Very complex business logic: In some cases the constraints of Behavior Implementation make SEGW's flexibility preferable.
• Non-SAP consumers: Some external systems do not yet support OData V4. V2 may be mandatory.

Conclusion

CDS-based OData V4 has become the standard for building new Fiori applications on S/4HANA. Keeping the data model and service definition in one place, annotation-driven UI management, and the standardised CRUD infrastructure provided by RAP all significantly reduce development time and maintenance cost compared with SEGW.

If you are starting a new Fiori project or planning to modernise existing SEGW services, I recommend starting with CDS + OData V4. Feel free to reach out if you would like to evaluate your project's technical architecture together.