İçeriğe geç

SAP OData V4 Servisi: SEGW'den CDS'e Geçiş Rehberi

SEGW ile yazdığınız OData V2 servislerini neden ve nasıl CDS tabanlı OData V4'e taşımalısınız — kod örnekleriyle adım adım.

Mustafa Önder Mustafa Önder  ·  6 Haziran 2026  ·  12 dk okuma

İçindekiler

  1. Neden OData V2'den V4'e Geçmeli?
  2. SEGW vs CDS Tabanlı Yaklaşım
  3. CDS View ile OData V4 Servisi Oluşturma
  4. Kritik CDS Annotation'ları
  5. Business Object Interface ile CRUD İşlemleri
  6. Servis Aktivasyonu ve Test
  7. SEGW Ne Zaman Hâlâ Geçerlidir?
  8. Sonuç

SAP Fiori uygulamaları ve harici entegrasyonların büyük çoğunluğu OData servisleri üzerinden çalışır. Yıllarca SEGW (SAP Gateway Service Builder) OData servislerinin standart geliştirme aracıydı. Ancak S/4HANA ve RAP (ABAP RESTful Application Programming) modeliyle birlikte bu yaklaşım hızla yerini CDS tabanlı OData V4'e bırakıyor.

Bu yazıda SEGW ve CDS tabanlı yaklaşımların farkını, hangi senaryoda hangisini kullanmanız gerektiğini ve CDS ile OData V4 servisi oluşturmanın adımlarını gerçek kod örnekleriyle anlatıyorum.

Neden OData V2'den V4'e Geçmeli?

OData V4, V2'ye kıyasla hem teknik hem de fonksiyonel açıdan önemli avantajlar sunar:

  • Daha güçlü sorgulama: V4'te $apply ile aggregation (toplama, gruplama) doğrudan URL'de yapılabilir. V2'de bu için ayrı servis metotları yazmak gerekirdi.
  • Gerçek tip desteği: V4, Edm.Date, Edm.TimeOfDay, Edm.DateTimeOffset gibi tipleri düzgün destekler. V2'de tarih/zaman yönetimi çoğu zaman sorun çıkarırdı.
  • Actions ve Functions: V4'te iş mantığı Actions (veri değiştiren) ve Functions (salt okunur) olarak standart bir şekilde tanımlanır.
  • SAP'nin geleceği: SAP'nin tüm yeni Fiori uygulamaları ve Joule entegrasyonları OData V4 üzerine inşa ediliyor. V2 yeni geliştirmeler için önerilmiyor.
  • CDS ile entegrasyon: CDS View üzerinden OData V4 servisi oluşturmak, veri modelini ve servis tanımını tek bir yerde tutmanızı sağlar — senkronizasyon sorunu ortadan kalkar.

SEGW vs CDS Tabanlı Yaklaşım

SEGW ile OData V2 servisinin mimarisi şöyle çalışır:

SEGW (Eski Yaklaşım)

1. SEGW'de entity type, entity set ve ilişkiler manuel tanımlanır.
2. Her operasyon (GET_ENTITY, GET_ENTITYSET, CREATE_ENTITY...) için ayrı ABAP Class metotu yazılır.
3. Veriye erişim mantığı bu metotlar içinde ABAP kodu ile gerçekleştirilir.
4. Servis, /IWFND/MAINT_SERVICE ile sisteme kayıt edilir.

Sorun: Veri modeli (tablo/CDS) ile servis tanımı birbirinden bağımsız — birini değiştirince diğerini unutmak çok kolay. Yüzlerce satır standart kod (boilerplate) yazılması gerekiyor.

CDS Tabanlı OData V4 (Yeni Yaklaşım)

1. Veri modeli CDS View olarak tanımlanır.
2. CDS View üzerine annotation eklenerek servis otomatik üretilir.
3. İş mantığı Behavior Definition ve Behavior Implementation Class'ta toplanır.
4. Servis, SICF üzerinden otomatik aktif hale gelir.

Avantaj: Veri modeli ve servis tek kaynak. Annotation değişince servis metadata'sı otomatik güncellenir. Boilerplate kod minimumdur.

CDS View ile OData V4 Servisi Oluşturma

Basit bir örnek üzerinden gidelim: bir satış siparişi listesi servisi oluşturacağız.

Adım 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
}

Adım 2 — Consumption View (OData'ya açılan katman)

@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
}

Adım 3 — Service Definition

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

Adım 4 — Service Binding (OData V4)

Eclipse ADT'de Service Definition'a sağ tıklayın → New Service Binding → Binding Type olarak OData V4 - UI seçin. Aktivasyon sonrası servis URL'si otomatik oluşur.

Kritik CDS Annotation'ları

CDS tabanlı OData V4'te annotation'lar servisin davranışını ve Fiori Elements uygulamasının görünümünü yönetir. (CDS View'ların finansal raporlama tarafındaki kullanımı için ACDOCA rehberine de bakabilirsiniz.) En sık kullanılanlar:

UI Annotation'ları (Fiori Elements için)

@UI.lineItem: [{ position: 10, label: 'Sipariş No' }]
SalesOrder,

@UI.lineItem: [{ position: 20, label: 'Müşteri' }]
@UI.selectionField: [{ position: 10 }]
SoldToParty,

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

Search ve Filter Annotation'ları

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

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

Metadata Extension (Annotation'ları ayırmak için)

Annotation'ları CDS View içine yazmak yerine ayrı bir Metadata Extension dosyasında tutmak kodun okunabilirliğini artırır ve CI/CD süreçlerinde fark almayı kolaylaştırır:

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

Business Object Interface ile CRUD İşlemleri

Salt okunur (GET) servisler için yukarıdaki adımlar yeterlidir. CREATE, UPDATE, DELETE işlemleri için Behavior Definition eklemek gerekir.

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 (önemli metotlar)

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.
    " İş mantığı buraya gelir
    " keys içindeki her sipariş için onay işlemi yapılır
    LOOP AT keys ASSIGNING FIELD-SYMBOL(<key>).
      " ...
      APPEND VALUE #(
        %tky = <key>-%tky
        " result alanları
      ) TO result.
    ENDLOOP.
  ENDMETHOD.

ENDCLASS.

Servis Aktivasyonu ve Test

Service Binding aktive edildikten sonra:

  • Preview: Eclipse ADT'de Service Binding açın → "Preview" butonuyla Fiori Elements uygulamasını direkt tarayıcıda açabilirsiniz.
  • Metadata kontrolü: /sap/opu/odata4/sap/<servis_adı>/srvd/sap/<servis_adı>/0001/$metadata URL'sine GET isteği atın. V4 metadata XML döner.
  • Postman ile test: Bearer token (SAP OAuth) veya Basic Auth ile $top=10 parametresiyle GET isteği atarak veri gelip gelmediğini doğrulayın.
  • Gateway Error Log: Sorun olursa /IWFND/ERROR_LOG yerine artık ABAP Application Log (transaction SLG1) kullanılır.

SEGW Ne Zaman Hâlâ Geçerlidir?

CDS tabanlı V4'ün tüm avantajlarına rağmen SEGW'in hâlâ mantıklı olduğu durumlar vardır:

  • Legacy sistemler (ECC, S/4HANA 1709 öncesi): CDS + RAP, S/4HANA 1809 ve üzerinde tam olarak desteklenir. Daha eski sistemlerde SEGW zorunludur.
  • Mevcut SEGW servisi bakımı: Çalışan bir V2 servisi varsa yeniden yazmak yerine bakımını sürdürmek çoğu zaman daha pratiktir.
  • Çok karmaşık iş mantığı: Bazı durumlarda Behavior Implementation'ın kısıtlamaları nedeniyle SEGW'in esnekliği tercih edilebilir.
  • Non-SAP tüketiciler: Bazı harici sistemler henüz OData V4'ü desteklemiyor. V2 zorunlu olabilir.

Sonuç

CDS tabanlı OData V4, S/4HANA'da yeni Fiori uygulamaları geliştirmenin standart yolu haline geldi. Veri modeli ve servis tanımının tek bir yerde tutulması, annotation tabanlı UI yönetimi ve RAP'ın sağladığı standart CRUD altyapısı, SEGW'e kıyasla hem geliştirme süresini hem de bakım maliyetini önemli ölçüde düşürüyor.

Yeni bir Fiori projesi başlatıyorsanız ya da mevcut SEGW servislerinizi modernize etmeyi planlıyorsanız CDS + OData V4'ten başlamanızı öneririm. Projenizin teknik mimarisini birlikte değerlendirmek isterseniz iletişime geçebilirsiniz.

OData V4 ve Fiori geliştirme projeniz için teknik danışmanlık alın.

Ücretsiz Ön Değerlendirme
← Blog'a Dön

İletişim

Projeleriniz için bizimle iletişime geçin.