TDEV
İletişime Geçin
← Blog

SAP Clean Core: 4 Seviyeli Extensibility Modeli

Bu yazı, SAP S/4HANA dönüşüm sürecinde mevcut ABAP kütüphanelerini modern Clean Core prensiplerine adapte etmek ve sistem sürdürülebilirliğini sağlamak isteyen çözüm mimarları ve geliştiriciler içindir.

SAP’nin uzun süredir gündeminde olan “Clean Core” vizyonu, sistem güncellemelerini (upgrade) zorlaştıran geleneksel zenginleştirmeleri ve modifikasyonları çekirdek sistemden izole etmeyi hedefler. Ancak kurumsal ölçekteki SAP müşterileri için mevcut tüm Z’li geliştirmeleri bir anda ABAP Cloud modeline geçirmek ya da tamamını SAP Business Technology Platform (SAP BTP) üzerine taşımak her zaman gerçekçi bir yaklaşım değildir.

Ağustos 2025’te yayınlanan güncel ABAP Extensibility Guide ve SAP S/4HANA 2025 release stratejisiyle birlikte, SAP bu geçişi daha yönetilebilir kılmak adına derecelendirilmiş bir değerlendirme modeli sundu: 4 Seviyeli (Level A-D) Extensibility Modeli. Bu model, hedeflenen “Tam Clean Core” durumu ile mevcut teknik borç (technical debt) arasındaki gri alanları net bir metodolojiye oturtmaktadır.

Clean Core Değerlendirmesinde Değişim: İkili Yapıdan Kademeli Modele

Geçmişte Clean Core yaklaşımı sıklıkla ikili bir mantıkla değerlendiriliyordu: Bir geliştirme ya Clean Core ilkesine tamamen uygundu (ABAP Cloud / Released APIs kullanımı) ya da “klasik” kabul edilip teknik borç olarak nitelendiriliyordu. Bu yaklaşım, canlı sistemlerde onlarca yıllık geçmişe sahip devasa kod bloklarını yönetmeyi zorlaştırıyordu.

Ağustos 2025 güncellemesiyle resmiyet kazanan Level A-D modeli, işletmelere ve yazılım mimarlarına zenginleştirmelerin uyumluluk düzeyini objektif kıyaslamalarla ölçümleme imkanı tanıyor. Model, sistem içerisindeki her bir custom nesnenin (custom object) Clean Core hedeflerine ne kadar yakın olduğunu ve ne düzeyde bir upgrade riski taşıdığını dört farklı seviyede tanımlar.

flowchart TD
    subgraph CoreSystem ["SAP S/4HANA On-Stack / Cloud"]
        LevelD[Level D: Modifikasyon ve Doğrudan Erişim]
        LevelC[Level C: Sarmalanmış Klasik ABAP]
        LevelB[Level B: Cloud-Ready On-Stack ABAP Cloud]
        LevelA1[Level A: On-Stack Developer Extensibility]
    end

    subgraph SideBySide ["SAP BTP"]
        LevelA2[Level A: Side-by-Side Extensibility]
    end

    LevelD -->|Encapsulation & Modernization| LevelC
    LevelC -->|ABAP Cloud Conversion| LevelB
    LevelB -->|Released API Integration| LevelA1
    LevelA1 -->|Decoupling if needed| LevelA2

4 Seviyeli (Level A-D) Extensibility Modelinin Detayları

Level A: Tam Uyumlu (Fully Clean / Standard Compliant)

Level A, SAP’nin stratejik Clean Core hedefine eksiksiz uyan geliştirmeleri temsil eder. Bu seviyedeki kodlar, gelecekteki upgrade süreçlerinden tamamen bağımsızdır ve sıfır sürüm geçişi riski taşır.

Level B: Cloud-Ready On-Stack (Cloud-Ready / Encapsulated)

Level B, kod yapısı olarak modern ABAP Cloud standartlarına göre yazılmış ancak bazı fonksiyonel bağımlılıklar nedeniyle henüz tam Released API seviyesine erişememiş yapıları kapsar.

Level C: Yönetilen Klasik Geliştirmeler (Classic with Governance)

Level C, işletmelerin mevcut SAP S/4HANA Cloud Private Edition veya on-premise sistemlerinde yer alan, klasik ABAP dili ile yazılmış ancak mimari olarak kontrol altına alınmış kodları ifade eder.

Level D: Uyumsuz ve Yüksek Riskli Yapılar (Non-Compliant / High Risk)

Level D, Clean Core prensiplerini doğrudan ihlal eden ve sistem kararlılığını riske atan tüm uygulamaları kapsar.

Seviyeler Arası Karşılaştırma ve Senaryo Matrisi

Özellik / Kriter Level A (Fully Clean) Level B (Cloud Ready) Level C (Controlled Classic) Level D (Non-Compliant)
Dil Kapsamı (Language Scope) ABAP Cloud / Key User ABAP Cloud Classic ABAP Classic ABAP / Direct Access
Kullanılan API Türü Public Released APIs (C1) Custom Wrapper + Released APIs Unreleased Internal APIs Unreleased / Direct DB Access
Upgrade Etkisi Sıfır Etki Çok Düşük (Sadece Wrapper) Orta (Sözdizimi & Fonksiyon Testi) Yüksek (Sistem Kırılması)
Geliştirme Ortamı ADT (ABAP Development Tools) / BTP ADT ADT / SE80 SE80 / Modifikasyon
Hedef Platform Fit SAP S/4HANA Cloud (Public/Private) & BTP S/4HANA Cloud Private Edition / 2025 S/4HANA Cloud Private Edition Kabul Edilemez / Tasfiye Edilmeli

Klasik Geliştirmelerin Modernizasyon Yolu (Transformation Path)

Mevcut klasik ABAP kod kütüphanesini bu yeni 4 seviyeli modele göre dönüştürmek sistematik bir yaklaşım gerektirir. Süreç, doğrudan kod yazmaktan ziyade bir analiz ve refactoring stratejisidir.

sequenceDiagram
    autonumber
    participant ATC as ABAP Test Cockpit
    participant Dev as Geliştirici / Mimar
    participant Wrapper as Custom Isolation Layer
    participant Standard as SAP S/4HANA Core

    ATC->>Dev: Level D/C Tespiti (Modifikasyon / Unreleased API)
    Dev->>Standard: Doğrudan Tablo/API Erişimini Kes
    Dev->>Wrapper: Custom Wrapper Oluştur (Level C -> Level B)
    Wrapper->>Standard: Sarmalanmış Nesne Çağrısı
    Note over Dev, Standard: Released API Yayınlandığında
    Dev->>Standard: Wrapper'ı Released API ile Değiştir (Level B -> Level A)

Step 1: ABAP Test Cockpit (ATC) ve Analiz

Dönüşümün ilk aşaması, sistemdeki tüm Z’li nesnelerin ABAP Test Cockpit (ATC) ve Custom Code Migration App aracılığıyla taranmasıdır. August 2025 güncellemeleriyle gelen ATC kontrol varyantları, kodları doğrudan bu seviyelere (A-D) göre etiketleyebilmektedir.

Step 2: Level D Kodların Hızlıca Tasfiyesi veya Sarmalanması

Sistemdeki Level D nesneler öncelikli hedef olmalıdır.

Step 3: Level C Nesnelerin Level B Seviyesine Taşınması (Encapsulation)

Eğer kullanılan bir SAP fonksiyonu veya tablosu için henüz resmi bir Released API yoksa, kod doğrudan Level A yapılamaz. Bu durumda Custom Wrapper stratejisi uygulanarak seviye Level B’ye yükseltilir:

  1. Unreleased olan SAP nesnesini çağıran özel bir arabirim (Interface veya Class) oluşturulur.
  2. İş mantığı, ABAP Cloud dil kurallarına (Strict Mode) uygun olarak yeniden yazılır.
  3. SAP ilerleyen sürümlerde ilgili API’yi “Released” yaptığında, sadece oluşturulan wrapper içeriği güncellenerek kod Level A seviyesine çekilir.

Step 4: Level B Nesneleri Level A Seviyesine Tamamlama

SAP, her yeni platform sürümünde (örneğin SAP S/4HANA Cloud Private Edition 2025 güncellemesiyle) binlerce yeni API’yi release etmektedir. Sistem güncellendikçe, Level B için oluşturulan custom wrapper’lar silinerek doğrudan resmi SAP Released API’lerine bağlanmalı ve tam Clean Core (Level A) sağlanmalıdır.

Dikkat Edilmesi Gereken Tuzaklar (Pitfalls)

Dönüşüm sürecinde teknik ekiplerin en sık karşılaştığı hatalı yaklaşımlar şunlardır:

  1. Level B Seviyesini Nihai Hedef Görmek: Level B, dönüşüm sürecinde geçici ve kabul edilebilir bir duraktır. Ancak mimari hedef, zaman içinde SAP’nin sunduğu yeni Released API’leri takip ederek Level A oranını maksimuma çıkarmak olmalıdır.
  2. Yalancı Sarmalama (Fake Encapsulation): Karmaşık bir klasik koda sadece bir wrapper class ekleyip kodun iç yapısını değiştirmeden bırakmak, o kodu Level B yapmaz. İç mantığın ABAP Cloud dil kısıtlamalarına (örneğin obsolete ifadelerin kaldırılması, yetki kontrollerinin eklenmesi) uyumlu hale getirilmesi şarttır.
  3. Her Şeyi Side-by-Side Yapmaya Çalışmak: Küçük bir veri doğrulama mantığını veya basit bir ekran zenginleştirmesini SAP BTP üzerine taşımak gereksiz network gecikmesine (latency) ve yüksek lisans maliyetlerine yol açar. On-Stack Developer Extensibility (Level A/B) yetersiz kaldığında veya dış sistem entegrasyonu gerektiğinde Side-by-Side tercih edilmelidir.
  4. Customizing ve Data Model Bağımlılıklarını Unutmak: Clean Core sadece ABAP kodundan ibaret değildir. Yanlış tasarlanmış custom veritabanı tabloları veya standart dışı Customizing yapıları da uyumluluk seviyesini düşürür. Custom veritabanı tablolarının CDS View’lar üzerinden izole edilmesi gerekir.

Özet ve Stratejik Değerlendirme

Ağustos 2025 güncellemeleriyle detaylandırılan 4 Seviyeli (A-D) Extensibility Modeli, Clean Core dönüşümünü bir “hepsini ya da hiçbirini yapma” baskısından çıkarıp, yönetilebilir bir yol haritasına dönüştürmüştür.

İşletmeler, ATC analizleri ile kod kütüphanelerinin mevcut seviye dağılımını (örneğin %10 Level A, %30 Level B, %40 Level C, %20 Level D) görünür kılabilir. Hedef; Level D seviyesini sıfırlamak, Level C kodları sarmalayarak Level B’ye çekmek ve SAP S/4HANA release güncellemeleriyle paralel olarak Level A oranını kademeli şekilde artırmak olmalıdır. Bu kademeli dönüşüm, hem sistem sürdürülebilirliğini ve güvenliğini garanti altına alır hem de upgrade maliyetlerini kalıcı olarak düşürür.

Kaynaklar

Anahtar Kelimeler