RAP: S/4HANA Geliştirmede Mimari Dönüşüm

S/4HANA 1909 ile hayatımıza giren ABAP RESTful Application Programming Model (RAP), klasik ABAP geliştirme yaklaşımını kökten değiştiriyor. 2021 ve sonrası sürümlerde olgunlaşarak bugün S/4HANA geliştirmesinin fiili standardı haline geldi. Ancak sahadaki duruma baktığımızda, hâlâ SEGW ve Function Module kombinasyonuyla geliştirme yapan ekiplerin azımsanmayacak sayıda olduğunu görüyoruz.

Klasik Yaklaşımın Maliyeti

Eski yöntemle tek bir iş uygulaması geliştirmek şu adımları gerektiriyordu:

1. DDIC'te tablo tanımla
2. Function Module veya BAPI yaz
3. SEGW'de Gateway projesi aç, entity ve operasyon tanımla
4. OData mapping'i manuel yap
5. SAPUI5/Fiori uygulaması yaz
6. Her katmanı ayrı test et

Bu yaklaşım; tekrar eden iş, katmanlar arası tutarsızlık ve orantısız bakım yükü demek. RAP bu zinciri kısa devre yapıyor.

RAP Mimari Katmanları

SAP, RAP mimarisini üç ana bölümde tanımlıyor. Alt katmanda Data Model & Behavior (CDS Interface View, BDEF, BIMP), ortada Business Service Provisioning (Projection View'ları, Service Definition, Service Binding), üstte ise Service Consumption (Fiori Elements, Web API) yer alıyor:

Data Model & Behavior — CDS Interface View

CDS Interface View (ZI_), Business Object katmanının temelini oluşturur. BDEF ve BIMP, bu view ile birlikte aynı katmanda yer alır — üçü birlikte bağımsız bir Business Object tanımlar. Annotation'lar sayesinde UI behavior'ını da bu katmanda şekillendirmek mümkün.

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Satış Siparişi'
define root view entity ZI_SalesOrder
  as select from vbak
  association [0..1] to I_Customer as _Customer
    on $projection.SoldToParty = _Customer.Customer
{
  key vbeln as SalesOrder,
      erdat as CreationDate,
      kunnr as SoldToParty,
      netwr as NetValue,
      waerk as Currency,

      /* Navigasyon için association */
      _Customer
}

Behavior Definition (BDEF)

BDEF, entity'nin desteklediği operasyonları (create, update, delete, action) ve bu operasyonların kurallarını (validation, determination) tanımlar. Kod değil, sözleşme (contract).

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

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

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

  /* Custom action */
  action ( features : instance ) confirmOrder
    result [1] $self;

  /* Kaydetmede çalışan validation */
  validation checkMandatoryFields on save { create; update; }

  /* Draft: form kapatılsa bile veri kaybolmaz */
  draft table zdraft_salesorder;
  with draft;
}

Behavior Implementation (BIMP) — Business Logic

CLASS zbp_i_salesorder DEFINITION
  PUBLIC ABSTRACT FINAL FOR BEHAVIOR OF zi_salesorder.
ENDCLASS.

CLASS zbp_i_salesorder IMPLEMENTATION.

  METHOD confirm_order.
    READ ENTITIES OF zi_salesorder IN LOCAL MODE
      ENTITY salesorder
        FIELDS ( soldtoparty netvalue status )
        WITH CORRESPONDING #( keys )
      RESULT DATA(orders).

    LOOP AT orders INTO DATA(order).
      IF order-netvalue <= 0.
        APPEND VALUE #(
          %tky        = order-%tky
          %state_area = 'CONFIRM' ) TO failed-salesorder.
        APPEND VALUE #(
          %tky      = order-%tky
          %msg      = new_message_with_text(
            severity = if_abap_behv_message=>severity-error
            text     = 'Net değer sıfırdan büyük olmalı' ) )
          TO reported-salesorder.
        CONTINUE.
      ENDIF.

      MODIFY ENTITIES OF zi_salesorder IN LOCAL MODE
        ENTITY salesorder
          UPDATE FIELDS ( status )
          WITH VALUE #( ( %tky = order-%tky  status = 'C' ) ).
    ENDLOOP.
  ENDMETHOD.

  METHOD check_mandatory_fields.
    READ ENTITIES OF zi_salesorder IN LOCAL MODE
      ENTITY salesorder
        FIELDS ( soldtoparty )
        WITH CORRESPONDING #( keys )
      RESULT DATA(orders).

    LOOP AT orders INTO DATA(order)
      WHERE soldtoparty IS INITIAL.
      APPEND VALUE #(
        %tky = order-%tky
        %state_area = 'MANDATORY' ) TO failed-salesorder.
    ENDLOOP.
  ENDMETHOD.

ENDCLASS.

Business Service Provisioning — Projection Layer

CDS Projection View (ZC_), Interface View üzerine as projection on ile kurulur. Service consumption'a özel @UI annotation'ları ve @AccessControl kuralları burada tanımlanır. Aynı Business Object; UI servisi, Web API ve farklı OData versiyonları için birden fazla projection üzerinden bağımsız biçimde sunulabilir.

define view entity ZC_SalesOrder
  as projection on ZI_SalesOrder {

  @UI.lineItem: [{ position: 10, importance: #HIGH }]
  SalesOrder,

  @UI.lineItem: [{ position: 20, importance: #HIGH }]
  SoldToParty,

  @UI.lineItem: [{ position: 30, importance: #MEDIUM }]
  NetValue,

  /* Projection association */
  _Customer
}

Business Service Provisioning — Service Definition & Binding

Service Definition hangi entity'lerin servis kapsamına gireceğini belirtir. Service Binding protokolü (OData V4) ve senaryoyu (UI servisi veya Web API) bağlar; Fiori Elements, bu binding üzerinden doğrudan bağlanır. RAP bu adımı büyük ölçüde otomatikleştirir — OData metadata, framework tarafından oluşturulur.

Managed, Unmanaged, Hybrid

RAP'ta üç senaryo var ve hangisini seçeceğiniz mevcut altyapıya bağlı:

Senaryo	Ne Zaman	Dezavantaj
Managed	Yeni geliştirmeler, clean persistence	Varolan BAPI'leri kullanamaz
Unmanaged	Tamamen özel save mantığı gerekli	Her şeyi kendiniz yazıyorsunuz
Managed + Unmanaged Save	Yeni RAP modeli + mevcut BAPI	İkili kompleksite

S/4HANA geçişi sırasında legacy BAPIs üzerinde çalışmaya devam etmek zorundaysanız, Managed with Unmanaged Save en yaygın tercih. Yeni business logic RAP'ta, save sequence eski BAPI'yi çağırıyor:

managed with unmanaged save
implementation in class zbp_i_salesorder unique;

Draft Handling

Draft, kullanıcı bir formu kaydetmeden kapattığında verilerin kaybolmamasını sağlar. ERP uygulamalarında kaçınılmaz bir gereksinim. RAP'ta framework tamamen yönetiyor: draft tablosu otomatik oluşuyor, lock ve lifecycle SAP tarafından ele alınıyor.

Fiori Elements ile Otomatik UI

RAP'ın CDS annotation'ları, Fiori Elements şablonlarının büyük bölümünü otomatik oluşturur. Ayrı bir SAPUI5 uygulaması yazmak zorunda kalmadan List Report + Object Page elde edebilirsiniz:

@UI: {
  headerInfo: {
    typeName:       'Satış Siparişi',
    typeNamePlural: 'Satış Siparişleri',
    title:          { type: #STANDARD, value: 'SalesOrder' }
  },
  lineItem: [
    { position: 10, label: 'Sipariş No',  importance: #HIGH  },
    { position: 20, label: 'Müşteri',     importance: #HIGH  },
    { position: 30, label: 'Net Değer',   importance: #MEDIUM },
    { position: 40, label: 'Para Birimi', importance: #LOW   }
  ],
  selectionField: [
    { position: 10, element: 'SalesOrder'  },
    { position: 20, element: 'SoldToParty' },
    { position: 30, element: 'CreationDate'}
  ]
}
define view entity ZC_SalesOrder as projection on ZI_SalesOrder {
  ...
}

Business Events: Side-by-Side Extension'lar İçin

S/4HANA 2022 ile RAP'a eklenen Business Events, BTP üzerindeki CAP uygulamalarının S/4HANA olaylarına abone olmasını sağlıyor. Clean core mimarisinin temel taşlarından biri budur: S/4HANA'ya dokunmadan, event-driven entegrasyon.

define behavior for ZI_SalesOrder ...
{
  ...
  event SalesOrderConfirmed;   /* BTP Event Mesh'e publish */
}

" Implementation:
METHOD confirm_order.
  ...
  RAISE ENTITY EVENT zi_salesorder~salesorderconfirmed
    FROM DATA OF zi_salesorder
    WITH VALUE #( ( %key = order-%key ) ).
ENDMETHOD.

Ne Zaman RAP Kullanmalı?

Senaryo	Karar
S/4HANA'da yeni iş uygulaması	✅ RAP — Managed senaryo
Mevcut BAPI/FM üzerine OData	✅ RAP — Managed + Unmanaged Save
BTP üzerinde side-by-side extension	❌ RAP değil → CAP
ECC sisteminde geliştirme	❌ RAP yok → Klasik OData/SEGW
Karmaşık form + draft ihtiyacı	✅ RAP — Draft handling

RAP, S/4HANA geliştirmesinde SEGW + Function Module kombinasyonunu kalıcı olarak geride bıraktı. Ekip içinde yetkinliği inşa etmek zaman alıyor; ancak bir kez yerleştiğinde, bakım ve yükseltme maliyetleri klasik yaklaşıma kıyasla belirgin biçimde düşüyor.