ABAP Cloud ve Clean Core: Modifikasyonsuz S/4HANA Geliştirme Rehberi

SAP'nin son yıllardaki en tekrarlanan iki kelimesi "clean core". Kurumsal sunumlarda öyle sık geçiyor ki pek çok ABAP geliştiricisi için içi boşalmış bir pazarlama terimine dönüştü. Oysa altında somut ve teknik bir şey var: çekirdeği bozmadan geliştirme yapmanın, dil seviyesinde zorlanan bir tanımı.

Bu yazıda clean core'u slogan olarak değil mühendislik problemi olarak ele alıyorum: ABAP Cloud dil sürümü tam olarak neyi kapatıyor, kapattığı her şeyin karşılığı ne, release contract'lar nasıl okunur, release edilmemiş bir nesneye erişmek gerektiğinde meşru yol nedir ve mevcut Z kodunuzun ne kadarının bu modele uyduğunu nasıl ölçersiniz.

Clean Core Nedir, Neden Şimdi Konuşuluyor?

Klasik ABAP dünyasında bir gereksinimi karşılamanın çok yolu vardı ve bunların çoğu SAP'nin standart nesnelerine doğrudan dokunuyordu: standart bir tabloya SELECT atmak, standart bir include'a kod eklemek, SAP nesnesini modifiye etmek, release edilmemiş bir function module'ü çağırmak. Bunların hiçbiri o an yasak değildi ve hepsi çalışıyordu.

Faturası upgrade zamanında geliyordu. SAP bir tablonun yapısını değiştirdiğinde, bir function module'ün davranışını güncellediğinde ya da bir include'ı yeniden düzenlediğinde, o nesneye dayanan özel kodunuz sessizce ya da gürültüyle bozuluyordu. SPAU/SPDD listeleri, upgrade projelerinin en öngörülemeyen kalemiydi ve bu maliyet sistemin ne kadar "özelleştirilmiş" olduğuyla birlikte büyüyordu.

Clean core bu problemin adını koyuyor ve şu ilkeyi getiriyor: özel kodunuz, SAP'nin açıkça kararlılık sözü verdiği arayüzler dışında hiçbir şeye dokunmasın. Sözün verildiği nesneye "released API", söze de "release contract" deniyor. Bu sınırın dışına çıkmadığınız sürece SAP içeride ne değiştirirse değiştirsin kodunuz çalışmaya devam eder.

Konunun şimdi sıkışmasının pratik sebebi bulut: S/4HANA Cloud Public Edition'da modifikasyon diye bir seçenek yok, klasik ABAP erişilebilir değil. SAP bu modeli buluttan öğrendi ve on-premise/Private Cloud tarafına da aynı modeli taşıdı. S/4HANA geçişi planlayan bir ekip için soru artık "clean core'a geçelim mi" değil, "hangi kodu hangi katmana koyacağız".

Üç Katmanlı Genişletilebilirlik Modeli

SAP'nin önerdiği model, "her şey temiz olsun" gibi uygulanamaz bir talep değil. Üç katman tanımlıyor ve hangi kodun hangi katmanda durabileceğini, o katmanın maliyetiyle birlikte söylüyor:

Modelin can alıcı noktası Tier 2. Pek çok ekip clean core'u "ya hep ya hiç" olarak okuyup, ilk karşılaştıkları released olmayan nesnede tüm yaklaşımı bırakıyor. Oysa Tier 2 tam olarak bunun için var: kirli erişimi yok etmiyorsunuz, tek bir noktaya hapsediyorsunuz. SAP ileride o işlev için bir API release ettiğinde değiştireceğiniz yer tek bir sınıf olur.

ABAP Cloud Dil Sürümü: Neyi Kapatıyor?

ABAP Cloud ayrı bir dil değil; ABAP'ın kısıtlanmış bir dil sürümüdür (ADT'deki resmi adı ABAP for Cloud Development). Kaynak kodda bir pragma ile açılmaz: nesnenin özelliğidir ve pratikte paket düzeyinde yönetilir. ADT'de paketi oluştururken "ABAP Language Version" olarak ABAP for Cloud Development seçtiğinizde, o pakette oluşturulan nesneler bu kuralla derlenir.

Bu, alışkanlıkla değil derleyiciyle zorlanan bir disiplin demektir. Yasak bir şey yazdığınızda uyarı almazsınız; kodunuz derlenmez. Tam liste sürümle birlikte gelişiyor, ama pratikte karşınıza çıkacaklar şunlar:

Klasik ABAP'tan ABAP Cloud'a: Karşılık Tablosu

Geçişte en çok zaman kaybettiren şey, kapatılan her yapı için karşılığını tek tek aramak. Sahada en sık ihtiyaç duyulanları bir arada topluyorum:

Uygulamada: Dört Tipik Dönüşüm

Tablo yön verir ama asıl iş koddadır. En sık karşılaşılan dört dönüşümü açalım.

1. Tablo okumadan released CDS view'a

" ABAP Cloud'da DERLENMEZ — MARA released bir nesne değil
SELECT SINGLE matnr, mtart, meins
  FROM mara
  WHERE matnr = @material_id
  INTO @DATA(material).

" Doğrusu: SAP'nin release ettiği interface view
SELECT SINGLE Product, ProductType, BaseUnit
  FROM I_Product
  WHERE Product = @material_id
  INTO @DATA(product).

Farkı basit bir isim değişikliği sanmak yanıltıcıdır. Released view alanlarını iş anlamıyla adlandırır (meins değil BaseUnit) ve daha önemlisi SAP bu view'ın alan listesini ve anlamını koruyacağına söz verir; alttaki tablo yapısı değişse bile view sizin için sabit kalır. Örnekteki isim farkı da tesadüf değil: S/4HANA'da "malzeme" kavramı veri modelinde "ürün" (product) olarak ele alınır.

2. Enqueue function module'den lock object API'sine

" Klasik
CALL FUNCTION 'ENQUEUE_EZ_SALES_ORDER'
  EXPORTING  salesorder     = order_id
  EXCEPTIONS foreign_lock   = 1
             system_failure = 2.

" ABAP Cloud
TRY.
    DATA(lock) = cl_abap_lock_object_factory=>get_instance(
                   iv_name = 'EZ_SALES_ORDER' ).

    lock->enqueue(
      it_parameter = VALUE #(
        ( name = 'SALESORDER' value = REF #( order_id ) ) ) ).

    " ... iş mantığı ...

    lock->dequeue(
      it_parameter = VALUE #(
        ( name = 'SALESORDER' value = REF #( order_id ) ) ) ).

  CATCH cx_abap_lock_failure INTO DATA(lock_error).
    " Kilit alınamadı — sy-subrc olarak değil, istisna olarak gelir
ENDTRY.

Buradaki asıl kazanım, hata yönetiminin sy-subrc kontrolünden istisna sınıfına taşınması. Kilit alınamadığında fark etmeden devam etme ihtimali dil seviyesinde ortadan kalkıyor.

3. Klasik HTTP istemcisinden destination tabanlı istemciye

TRY.
    " Hedef URL ile ya da sistemde tanımlı bir destination üzerinden kurulur
    DATA(destination) = cl_http_destination_provider=>create_by_url(
                          i_url = 'https://api.ornek.com/v1/orders' ).

    DATA(client) = cl_web_http_client_manager=>create_by_http_destination(
                     i_destination = destination ).

    DATA(request) = client->get_http_request( ).
    request->set_header_field( i_name  = 'Accept'
                               i_value = 'application/json' ).

    DATA(response) = client->execute( if_web_http_client=>get ).

    IF response->get_status( )-code <> 200.
      RAISE EXCEPTION NEW zcx_api_error( ).
    ENDIF.

    DATA(payload) = response->get_text( ).
    client->close( ).

  CATCH cx_http_dest_provider_error cx_web_http_client_error INTO DATA(http_error).
    " Bağlantı veya hedef hatası
ENDTRY.

Örnek kısalık için URL'yi doğrudan veriyor. Üretim kodunda sistemde tanımlı bir destination ile çalışmak daha doğrudur; sertifika, kimlik doğrulama ve ortam farkları o zaman koddan tamamen çıkar.

4. JSON dönüşümü: XCO kütüphanesi

/ui2/cl_json pek çok projede fiilî standart hâline gelmişti ama ABAP Cloud için released değil. Karşılığı XCO kütüphanesi:

" JSON metninden ABAP yapısına
DATA order TYPE zif_order_api=>ty_order.

xco_cp_json=>data->from_string( payload )->write_to( REF #( order ) ).

" ABAP yapısından JSON metnine
DATA(json_text) = xco_cp_json=>data->from_abap( order )->to_string( ).

XCO yalnız JSON'dan ibaret değil; UUID üretimi, metin işlemleri, tarih/saat dönüşümleri ve repository meta verisi okuma gibi pek çok yardımcıyı released olarak sunar. ABAP Cloud'a geçen bir ekibin erken tanıması gereken kütüphane budur.

Released API'ler ve Release Contract'lar

"Released" tek bir şey değil. SAP her released nesneye bir veya birden fazla release contract atar ve kontrat, o nesneyi hangi amaçla kullanabileceğinizi söyler. Kontratı okumadan "bu nesne released" demek yanıltıcıdır: bir nesne uzaktan çağrı için released olup ABAP Cloud kodunuzdan kullanılamayabilir.

Pratik sonuç: bir gereksinim için API ararken sorunuz "released mı?" değil, "benim kullanacağım amaç için released mı?" olmalıdır. ABAP Cloud kodu yazıyorsanız aradığınız, C1 kontratı ve Use in Cloud Development işaretidir. SAP Business Accelerator Hub'da gördüğünüz pek çok API uzaktan tüketim (C2) içindir; bunları stack içinden çağırmaya kalktığınızda derleyici izin vermez.

Doğru API'yi Bulmak

ABAP Cloud'a yeni geçen ekiplerin en çok vakit kaybettiği yer burası. Üç yöntemi birlikte kullanmak gerekiyor:

• ADT'deki Released Objects ağacı. Project Explorer'da sistem projenizin altında released nesneler tür tür listelenir. Bir iş nesnesi veya alan adıyla arayıp hangi CDS view'ların ve sınıfların kullanımınıza açık olduğunu görebilirsiniz. Günlük çalışmada en hızlı yol budur.
• Nesnenin API State bilgisi. Elinizde zaten bir nesne adı varsa ADT'de açıp Properties görünümündeki API durumuna bakmak, hangi kontratla ve hangi görünürlükle release edildiğini kesin olarak söyler. "Bu nesneyi kullanabilir miyim" sorusunun tek güvenilir cevabı buradadır.
• SAP Business Accelerator Hub. Özellikle uzak entegrasyon (C2) API'leri için kataloğun kendisi. Buradan bulduğunuz bir API'yi ABAP Cloud içinden kullanmayı planlıyorsanız kontratını mutlaka ADT'de doğrulayın.

Bir de negatif yöntem var ve şaşırtıcı derecede etkilidir: kodu ABAP Cloud paketinde yazmaya başlayıp derleyicinin itiraz ettiği yerleri listelemek. Derleyici, hangi nesnenin kullanılamadığını tek tek söyler. Bu liste aynı zamanda Tier 2 wrapper ihtiyacınızın envanteridir.

Tier 2: Release Edilmemiş Nesneye Meşru Erişim

Er ya da geç şu durumla karşılaşacaksınız: ihtiyacınız olan işlevin released bir karşılığı yok. Örneğin eski bir modülde, yalnız klasik bir function module'ün yaptığı bir fiyat hesabı var ve bunu yeniden yazmak makul değil.

Yanlış iki tepki şunlar: (a) clean core'u bırakıp her şeyi klasik pakette yazmak, (b) işlevi ABAP Cloud'da sıfırdan yeniden yazıp iş mantığını iki yere bölmek. Doğrusu Tier 2 wrapper'dır.

" --- Tier 1 paketi (ABAP Cloud): kendi kontratımız ---
" Yalnız yerleşik tipler — released olmayan DDIC tiplerine bağımlılık yok
INTERFACE zif_legacy_pricing PUBLIC.

  TYPES: BEGIN OF ty_condition,
           condition_type TYPE c LENGTH 4,
           amount         TYPE p LENGTH 13 DECIMALS 2,
           currency       TYPE c LENGTH 5,
         END OF ty_condition.

  METHODS read_condition
    IMPORTING order_id         TYPE c
    RETURNING VALUE(condition) TYPE ty_condition
    RAISING   zcx_pricing_error.

ENDINTERFACE.

" --- Tier 2 paketi (Standard ABAP): izole edilmiş kirli erişim ---
" Bu sınıf ADT'de C1 / "Use in Cloud Development" olarak release edilir.
CLASS zcl_legacy_pricing_adapter DEFINITION
  PUBLIC FINAL
  CREATE PUBLIC.

  PUBLIC SECTION.
    INTERFACES zif_legacy_pricing.

ENDCLASS.

CLASS zcl_legacy_pricing_adapter IMPLEMENTATION.

  METHOD zif_legacy_pricing~read_condition.
    DATA legacy_condition TYPE zlegacy_s_condition.

    " Released olmayan nesneye erişim SADECE burada —
    " örnekte eski bir Z function module
    CALL FUNCTION 'Z_LEGACY_PRICING_READ'
      EXPORTING
        iv_vbeln     = order_id
      IMPORTING
        es_condition = legacy_condition
      EXCEPTIONS
        not_found    = 1
        OTHERS       = 2.

    IF sy-subrc <> 0.
      RAISE EXCEPTION NEW zcx_pricing_error( ).
    ENDIF.

    " Dışarıya kendi tipimizle dönüyoruz — eski yapı sızmıyor
    condition = VALUE #( condition_type = legacy_condition-kschl
                         amount         = legacy_condition-kbetr
                         currency       = legacy_condition-waers ).
  ENDMETHOD.

ENDCLASS.

Bu desenin görünenden büyük bir yan faydası var: Tier 1 kodunuz artık bir arayüze bağlı olduğu için test edilebilir hâle geliyor. Testte gerçek wrapper yerine bir test double verir, iş mantığını hiçbir SAP nesnesine dokunmadan doğrularsınız. Clean core ve test edilebilirlik, aynı tasarım hamlesinin iki sonucudur.

Uzantı Noktaları: BAdI, CDS Extend, RAP

Kendi uygulamanızı yazmak clean core'un yarısı. Diğer yarısı, SAP'nin standart uygulamasının davranışını değiştirmek — eskiden modifikasyon veya implicit enhancement ile yapılan şey. ABAP Cloud'da bunun yolu, SAP'nin açıkça açtığı uzantı noktalarından geçer.

BAdI ile davranış değiştirme

Released bir BAdI varsa, uygulaması ABAP Cloud paketinde yazılabilir. Modifikasyondan farkı şudur: SAP o çağrı noktasının varlığını ve arayüzünü koruyacağına söz verir; içerideki uygulamayı değiştirse bile sizin kodunuz çağrılmaya devam eder.

CLASS zcl_order_check_badi DEFINITION
  PUBLIC FINAL
  CREATE PUBLIC.

  PUBLIC SECTION.
    INTERFACES if_badi_interface.
    " Örnek ad — gerçek arayüz adı, BAdI tanımında yazar
    INTERFACES if_ex_order_check.

  PRIVATE SECTION.
    CONSTANTS c_approval_limit TYPE p LENGTH 13 DECIMALS 2 VALUE '50000.00'.

ENDCLASS.

CLASS zcl_order_check_badi IMPLEMENTATION.

  METHOD if_ex_order_check~check.
    " Kendi iş kuralımız — SAP nesnesi modifiye edilmiyor
    IF order-net_value > c_approval_limit.
      APPEND VALUE #( severity = 'E'
                      text     = 'Onay limiti asildi' ) TO messages.
    ENDIF.
  ENDMETHOD.

ENDCLASS.

CDS view genişletme

SAP'nin bir CDS view'ına kendi alanınızı eklemek mümkündür — ancak yalnız o view genişletme için release edilmişse (C0). Her released view genişletilebilir değildir; kullanım (C1) ile genişletme (C0) ayrı sözlerdir. View entity uzantısında uzantının adı, DDL kaynağının adıdır; with ifadesinden sonra ayrıca yazılmaz:

" DDL kaynağı: ZX_SALESDOCUMENT_EXT
extend view entity I_SalesDocument with
{
  _Extension.ZZ1_ProjectCode,
  _Extension.ZZ1_ApprovalLevel
}

Örnekteki ZZ1_ önekli alanlar, key user Custom Fields uygulamasıyla eklenmiş alanlardır. Hangi view'ın hangi alanlarla ve hangi ilişki üzerinden genişletilebildiği o view'ın extensibility bilgisinde tanımlıdır.

RAP davranış uzantısı

SAP'nin RAP tabanlı bir iş nesnesine kendi doğrulamanızı (validation), belirleyicinizi (determination) veya aksiyonunuzu eklemek için behavior extension kullanılır. Koşul yine aynı: iş nesnesinin uzantıya açılmış olması gerekir.

" Sadeleştirilmiş başlık — SAP iş nesnelerinde uzantı genellikle
" nesnenin released interface'i üzerinden tanımlanır
extension implementation in class zbp_salesorder_ext unique;

extend behavior for SalesOrder
{
  validation zz_ValidateProjectCode on save { field ZZ1_ProjectCode; }
}

Üç yöntemin ortak mantığı şu: değişikliğinizi SAP'nin kodunun içine değil, SAP'nin sizin için açtığı yuvaya koyuyorsunuz. Yuva yoksa değişiklik de yapılamaz — bu kısıt gibi görünse de upgrade kararlılığının bedelidir. Gereken uzantı noktası yoksa SAP'ye talep iletmek, uzun vadede modifiye etmekten daha kısa yoldur.

Mevcut Kodu Ölçmek: ATC ve Custom Code Migration

Buraya kadarki her şey yeni kod içindi. Asıl soru genellikle şu: elimizdeki Z kodunun ne kadarı bu modele uyuyor? Tahminle cevaplanacak bir soru değil; ölçülür.

Sık Yapılan Beş Yanlış Anlama

Bu konudaki tartışmaların çoğu teknik bir anlaşmazlıktan değil, aynı terime farklı anlam yüklenmesinden çıkıyor.

• "Clean core, Z kodu olmaması demek." Değil. Clean core, Z kodunun SAP'nin çekirdeğine dokunmaması demek. ABAP Cloud ile yazılmış on bin satır Z kodu clean core'a tamamen uygundur.
• "On-premise'de bizi ilgilendirmiyor." Zorunlu olmadığı doğru. Ama upgrade maliyeti on-premise'de de gerçek ve SAP yeni uzantı noktalarını bu modele göre açıyor. Bugün klasik yazdığınız her yeni nesne, ileride taşınacak bir borçtur.
• "Her şeyi hemen taşımamız gerekiyor." Model tam tersini söylüyor. Tier 3'ün varlığı, mevcut kodun kalabileceğinin kabulüdür. Kritik olan, yeni kodun nereye yazıldığıdır.
• "ABAP Cloud daha kısıtlı, yani daha zayıf." Kısıtların çoğu zaten bırakmanız gereken şeyleri kapatıyor: dynpro, prosedürel kod, standart tabloya doğrudan erişim. Geriye kalan, modern ABAP'ın tamamı.
• "Key user extensibility yeterli, geliştiriciye gerek yok." Key user katmanı basit alan ve kural eklemelerinde çok verimlidir, ama sınırları nettir. Gerçek iş mantığı, entegrasyon ve karmaşık veri modelleri developer extensibility gerektirir. İkisi rakip değil, aynı modelin iki aracıdır.

Uygulanabilir Yol Haritası

Büyük bir dönüşüm programı ilan etmeden, ilk günden ilerleyebileceğiniz bir sıra:

Sonuç

Clean core, kod yazma özgürlüğünüzü kısıtlayan bir yönetmelik değil; upgrade maliyetini geliştirme anına taşıyan bir takas. Eskiden ucuz görünen her kısayolun faturası upgrade projesinde kesiliyordu ve o fatura hiçbir zaman önceden bilinmiyordu. ABAP Cloud bedeli öne alıp öngörülebilir kılıyor: bugün biraz daha fazla düşünüyorsunuz, upgrade'de ise çok daha az.

Modelin uygulanabilir olması Tier 2 sayesinde. "Her şey temiz olacak" deseydi hiçbir kurumsal sistemde uygulanamazdı. Kirli erişimi yasaklamak yerine izole edip kayıt altına almayı önerdiği için sahada işliyor.

Başlangıç noktası büyük bir program değil, tek bir karar: bir sonraki yeni nesneyi ABAP Cloud paketinde açmak. Karşınıza çıkan ilk üç kısıt, kod tabanınız hakkında haftalarca sürecek bir analizden daha fazlasını söyleyecektir.