CDS View Entity'ye Geçiş: DDIC Tabanlı CDS Görünümlerini Taşımak

Yıllarca define view ile yazdığımız CDS görünümlerinin yerini define view entity aldı. Eski görünümler çalışmaya devam ediyor ama yeni özellik almıyor ve ABAP Cloud'da hiç yok. Bu yazıda iki nesil arasındaki farkları, göçte nelerin kırıldığını ve güvenli bir geçiş planını anlatıyorum.

ABAP CDS

CDS View Entity

ABAP Cloud

S/4HANA

Mustafa Önder · 31 Ekim 2026 · 13 dk okuma

CDS ilk geldiğinde her görünüm iki nesne üretiyordu: CDS varlığının kendisi ve @AbapCatalog.sqlViewName ile adını verdiğimiz bir DDIC SQL görünümü. ABAP 7.55 (S/4HANA 2020) ile gelen CDS view entity bu ikinci nesneyi ortadan kaldırdı. Artık tek bir ad, tek bir nesne var.

SAP eski görünümleri (belgede artık DDIC-based view deniyor) kaldırmayacağını, ama yeni özellikleri yalnız view entity'lere ekleyeceğini açıkladı; ABAP anahtar kelime belgesi de DEFINE VIEW'u eskimiş (obsolete) ifadeler arasında listeliyor. Bu yazı, mevcut görünümlerinizi taşırken nelere dikkat etmeniz gerektiğini anlatıyor. Bilgiler SAP'nin ABAP belgesine ve SAP'nin göç üzerine yayımladığı yazılara dayanır; ayrıntılar sürüme göre değişebilir, kendi sisteminizin belgesiyle karşılaştırın.

İki Nesil CDS: Ne Değişti?

Konu	DDIC tabanlı görünüm (define view)	View entity (define view entity)
Üretilen nesneler	CDS varlığı + DDIC SQL görünümü	Yalnız CDS varlığı
Ad	DDL kaynağı, CDS varlığı ve SQL görünümü ayrı adlar taşıyabilir	DDL kaynağı ile varlık adı aynı
İstemci (client)	`@ClientHandling` anotasyonlarıyla yönetilir	Otomatik; bu anotasyonlar desteklenmez
Parametre kullanımı	`:p_param` veya `$parameters.p_param`	Yalnız `$parameters.p_param`
`SELECT *`	Desteklenir	Desteklenmez; alanlar tek tek yazılır
Uzantı	`EXTEND VIEW` (DDIC append görünümüyle)	`EXTEND VIEW ENTITY` (append görünümü yok)
ABAP Cloud	Kullanılamaz	Tek seçenek
Yeni özellikler	Eklenmiyor	Ekleniyor

Aktivasyon tarafında da fark var: SQL görünümü üretilmediği için DDIC'e bağımlılık azalır ve aktivasyon hızlanır. Bunun yanında view entity sözdizimi daha katıdır; eski görünümün hoş gördüğü bazı yazımlar (ör. AS'siz takma ad) burada hata verir.

Neden Geçmeli, Ne Zaman Beklemeli?

Yeni geliştirme: Burada tartışma yok; SAP de yeni görünümleri yalnız view entity olarak yazmayı öneriyor. ABAP Cloud dil sürümünde zaten başka seçenek yok.
Değişikliğe açılan eski görünüm: Bir görünüme zaten dokunacaksanız göçü aynı işe katmak çoğu zaman en ucuz andır; test zaten yapılacaktır.
Kimsenin dokunmadığı, sorunsuz çalışan görünüm: Acele etmeyin. Göç gönüllüdür ve eski görünümler desteklenmeye devam ediyor. Önce aşağıdaki bağımlılıkları çıkarın.

Bazı durumlarda göç (henüz) mümkün değildir ya da pahalıdır:

Veri kaynağı bir DDIC veritabanı görünümü veya DDIC harici görünümüyse (view entity bunları kaynak, join ya da ilişki hedefi olarak kabul etmez).
Görünüm DECIMAL_SHIFT kullanıyorsa (yerine CURR_TO_DECFLOAT_AMOUNT veya GET_NUMERIC_VALUE önerilir, ama sonuç tipi değişir).
SQL görünümü sistem dışından okunuyorsa: veritabanı düzeyinde rapor araçları, native SQL ya da SQL görünümü üzerine kurulmuş başka bir uygulama.

Önce ve Sonra: Bir Görünümün Dönüşümü

Aşağıda RAP proje örneğindeki masraf formuna benzeyen basit bir başlık görünümü var. Önce DDIC tabanlı hâli:

@AbapCatalog.sqlViewName: 'ZVEXPREPORT'
@AbapCatalog.compiler.compareFilter: true
@AbapCatalog.preserveKey: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Expense report'
define view Z_I_ExpenseReport
  as select from zexp_report
  association [0..*] to Z_I_ExpenseItem as _Item
    on $projection.ReportId = _Item.ReportId
{
  key report_id    as ReportId,
      company_code as CompanyCode,
      employee     as Employee,
      report_date  as ReportDate,
      @Semantics.amount.currencyCode: 'Currency'
      total_amount as TotalAmount,
      @Semantics.currencyCode: true
      currency     as Currency,
      _Item
}

Aynı görünüm view entity olarak:

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Expense report'
define view entity Z_I_ExpenseReport
  as select from zexp_report
  association [0..*] to Z_I_ExpenseItem as _Item
    on $projection.ReportId = _Item.ReportId
{
  key report_id    as ReportId,
      company_code as CompanyCode,
      employee     as Employee,
      report_date  as ReportDate,
      @Semantics.amount.currencyCode: 'Currency'
      total_amount as TotalAmount,
      currency     as Currency,
      _Item
}

Değişenler: sqlViewName, compareFilter ve preserveKey anotasyonları kalktı (ilk ikisinin karşılığı olan SQL görünümü yok; compareFilter view entity'de her zaman açıktır ve değiştirilemez), define view yerine define view entity yazıldı ve para birimi alanındaki @Semantics.currencyCode silindi. Tutar alanı para birimine @Semantics.amount.currencyCode ile bağlanmaya devam ediyor; view entity'de CURR tipli alanlar için bu bağ zorunludur.

Göçte Değişen Kurallar

Parametreler: İki nokta sözdizimi kalktı; yalnız $parameters kullanılır.
Takma ad ve önek: Takma ad için AS zorunlu; join ya da ilişki kullanan görünümlerde her alan kaynak önekiyle yazılır.
Anotasyon konumu: Alanın arkasına yazılan @< anotasyonları kabul edilmez; anotasyon alanın önüne gelir.
Birim ve para birimi: @Semantics.currencyCode ve @Semantics.unitOfMeasure desteklenmez; bağı tutar/miktar alanında @Semantics.amount.currencyCode ve @Semantics.quantity.unitOfMeasure kurar.
İstemci alanı: İstemci yönetimi örtük olduğu için @ClientHandling anotasyonları ve seçim listesindeki istemci alanı kalkar.
Tamponlama: DDIC tamponlama anotasyonları view entity'de desteklenmez.
UNION: Anahtar alanlar dallar arasında aynı olmalı; alan anotasyonları yalnız ilk dalda yazılır. Alan tipleri ve uzunlukları da ilk daldan belirlenebildiği için sonraki dallarda kesilme olup olmadığını kontrol edin.
Toplama: AVG için sonuç tipi açıkça verilir (AVG( ... AS ... )).

// DDIC-based view
where report_date >= :p_from_date

// CDS view entity
where report_date >= $parameters.p_from_date

Not: Bu liste tam değildir. SAP'nin göç raporu her görünüm için hangi kuralın uygulanacağını ayrıntılı listeler; kendi sürümünüzün belgesindeki fark listesine de bakın.

SQL Görünümüne Bağlı Olanlar

Göçün asıl riski CDS kaynağında değil, silinen SQL görünümünü kullanan her şeydedir. Göç sırasında DDIC SQL görünümü silinir; onu kullanan her senaryo çalışmaz hâle gelir. En sık rastlanan, ABAP kodunun görünümü SQL görünümü adıyla okumasıdır:

" Önce: DDIC SQL görünümünün adıyla (göçten sonra derlenmez)
SELECT FROM zvexpreport
  FIELDS reportid, companycode, totalamount, currency
  WHERE companycode = @lv_company_code
  INTO TABLE @DATA(lt_reports).

" Sonra: CDS varlığının adıyla (DCL de uygulanır)
SELECT FROM z_i_expensereport
  FIELDS ReportId, CompanyCode, TotalAmount, Currency
  WHERE CompanyCode = @lv_company_code
  INTO TABLE @DATA(lt_reports).

Burada gözden kaçan bir davranış farkı var: CDS erişim kontrolü (DCL) yalnız CDS varlığı okunduğunda uygulanır. SQL görünümü adıyla okuyan eski kod yetki filtresinden geçmiyordu; varlık adına geçtiğinde @AccessControl.authorizationCheck: #CHECK olan görünümlerde kullanıcı artık yalnız yetkili olduğu satırları görür. Bu genellikle doğru olandır, ama "rapor eksik geliyor" şikâyeti olarak dönebilir. Ayrıntılar için CDS yetkilendirme ve DCL yazısına bakın.

Göçten önce listelenmesi gereken diğer bağımlılıklar:

Uzantılar: Görünüme EXTEND VIEW ile yazılmış uzantılar ve onların DDIC append görünümleri. Yeni uzantılar EXTEND VIEW ENTITY ile yazılır; mevcut uzantıların göçten sonraki durumunu test sisteminde doğrulayın.
Arama yardımları: SQL görünümüne doğrudan atanmış bir arama yardımı varsa bu atama göçte kaybolur.
DDIC üzerinden kullanım: SQL görünümünü veri kaynağı olarak kullanan başka DDIC nesneleri, SE16 gibi araçlarla yapılan erişimler, BW ya da veri çıkarma senaryoları.
Veritabanı düzeyinde erişim: SQL görünümünü doğrudan okuyan native SQL, AMDP veya harici araçlar.

Göç Araçları

Araç	Ne yapar	Sürüm
`RUTDDLS_MIGRATION_CANDIDATES`	Analiz: hangi görünümün taşınabileceğini ve engelleri listeler	ABAP 7.55 ve sonrası
`RUTDDLSV2MIGRATION`	Göç: kuralları uygular, görünümün etkin olmayan yeni sürümünü oluşturur; önce simülasyon modunda çalıştırılır	ABAP 7.56 (ABAP Platform 2021) ve sonrası
ADT ile elle göç	Kaynağı ADT'de düzenleyip etkinleştirmek	ABAP 7.56 ve sonrası

Göç raporu görünümü etkinleştirmez; etkinleştirme geliştiricinin son adımıdır ve SQL görünümü o anda silinir. Daha yeni sürümlerde ADT'de aynı işi yapan bir sihirbaz da bulunabilir. Ön koşullardan biri, DDL kaynağının adıyla CDS varlığının adının aynı olmasıdır; farklıysa göç mümkün değildir.

Geri dönüş yok: Araçla yapılan göç geri alınamaz. Ters göç için SAP'ye BC-DWB-DIC bileşeninde destek kaydı açmak gerekir. Bu yüzden göçü önce bir geliştirme sisteminde, bağımlılıkları çıkarılmış görünümlerle yapın.

Adım Adım Göç Planı

Envanter: Z/Y ad alanındaki DDIC tabanlı görünümleri ve RUTDDLS_MIGRATION_CANDIDATES sonucunu çıkarın.
Bağımlılıklar: Her görünüm için SQL görünümü adının nerede kullanıldığını (kullanım yeri listesi, kod araması), uzantıları ve arama yardımlarını listeleyin.
Sıralama: Önce engeli ve dış tüketicisi olmayan, aşağı katmandaki görünümlerle başlayın; üst katmanlara doğru ilerleyin.
Kod düzeltmesi: SQL görünümü adını kullanan ABAP kodunu göçten önce varlık adına çevirin. Bu adım eski görünümle de çalışır, dolayısıyla ayrı taşınabilir ve DCL etkisi ayrı test edilir.
Simülasyon ve göç: RUTDDLSV2MIGRATION'ı simülasyonla çalıştırın, uyarıları okuyun, sonra göçü yapıp etkinleştirin.
Test: Göç öncesi ve sonrası aynı sorgunun satır sayısını ve toplamlarını karşılaştırın; Fiori uygulamalarını ve OData servislerini açın.
Taşıma: Değişen kod ve görünümleri aynı taşıma isteğinde (transport) toplayın; aksi hâlde hedef sistemde kod, artık var olmayan SQL görünümüne bakabilir.

Sık Yapılan Hatalar

Önce görünümü taşıyıp sonra kodu aramak

SQL görünümünü okuyan kod göçten sonra sözdizimi hatası verir. Kullanım yerlerini önce çıkarın ve kodu önce düzeltin.

DCL etkisini test etmemek

Varlık adına geçen eski kod artık yetki filtresinden geçer. Yetkisi sınırlı bir test kullanıcısıyla da deneyin.

Kodu ve görünümü ayrı taşımalara koymak

Görünüm canlıya önce giderse SQL görünümü silinir ve eski kod kırılır. İkisini aynı taşımada ya da doğru sırada gönderin.

Uyarıları okumadan etkinleştirmek

compareFilter ve istemci anotasyonlarının kalkması bazı görünümlerde anlamı değiştirebilir. Simülasyon çıktısındaki uyarılar tam olarak bunları gösterir.

Sonuç

View entity'ye geçiş sözdiziminden çok bir bağımlılık işidir. CDS kaynağındaki değişiklikler çoğunlukla mekaniktir ve araçlar bunun büyük kısmını yapar. Asıl iş SQL görünümünü kullanan kodu, uzantıları ve dış tüketicileri önceden bulmaktır. Yeni görünümleri bugünden view entity olarak yazın; eskileri dokunduğunuz anda, bağımlılıklarını çıkararak taşıyın.

CDS ile servis tarafı için OData V4 ve CDS yazısına, ABAP Cloud kuralları için ABAP Cloud ve Clean Core yazısına, sunduğum geliştirme kapsamı için SAP geliştirme hizmet sayfasına bakabilirsiniz.

Mevcut CDS görünümlerinizin envanterini çıkarmak, bağımlılıkları bulmak ve view entity'ye güvenli bir geçiş planı yapmak için destek alın.

Ön Görüşme Talep Et

Blog'a Dön

İçindekiler

1. İki Nesil CDS: Ne Değişti?

2. Neden Geçmeli, Ne Zaman Beklemeli?

3. Önce ve Sonra: Bir Görünümün Dönüşümü

4. Göçte Değişen Kurallar

5. SQL Görünümüne Bağlı Olanlar

6. Göç Araçları

7. Adım Adım Göç Planı