SAP Entegrasyon Senaryoları: IDoc, RFC, OData, REST ve Olaylar — Hangisi Ne Zaman?

"Bu entegrasyonu REST ile mi yapalım, IDoc ile mi?" sorusu genellikle toplantının ilk beş dakikasında sorulur ve çoğu zaman ekibin en iyi bildiği teknolojiyle cevaplanır. Sonuç tanıdıktır: senkron çağrılardan oluşan kırılgan zincirler, hata verdiğinde kimsenin fark etmediği akışlar, "dün gece neden çift sipariş oluştu?" soruşturmaları.

SAP, dış dünyayla konuşmak için çok sayıda araç sunar; sorun araç eksikliği değil, seçimin gerekçesiz yapılmasıdır. Bu yazıda her aracın güçlü olduğu yeri, sahada tipik olarak nerede kırıldığını ve hataların nasıl yönetileceğini anlatıyorum.

Teknolojiden Önce Sorulacak Beş Soru

1. Yön: SAP mi karşı tarafı çağırıyor, karşı taraf mı SAP'yi? Yoksa ikisi de bir aracıya mı konuşuyor?
2. Cevap beklentisi: Çağıran taraf sonucu hemen mi bilmeli (senkron), yoksa "aldım, işleyeceğim" yeterli mi (asenkron)? Ekranda bekleyen bir kullanıcı var mı?
3. Hacim ve sıklık: Günde on belge mi, saatte on bin mi? Anlık mı, gece toplu mu?
4. Teslim garantisi: Bir mesaj kaybolursa ne olur? Aynı mesaj iki kez işlenirse ne olur? Sıra önemli mi?
5. Karşı taraf: Ne konuşabiliyor? Başka bir SAP sistemi, modern bir REST API, yalnızca dosya bırakabilen eski bir sistem?

Teknoloji Haritası

IDoc: Asenkron, İzlenebilir, Yeniden İşlenebilir

IDoc eski görünse de çözdüğü problem hâlâ güncel: bir belgeyi başka bir sisteme güvenilir biçimde taşımak. Her IDoc'un bir numarası, bir durum geçmişi ve bir yeniden işleme yolu vardır. Bir REST entegrasyonunda sıfırdan kurmanız gereken izleme ve tekrar deneme altyapısı, IDoc'ta kutudan çıkar.

Özel bir giden IDoc oluşturmak birkaç satırdır. Hangi alıcıya, hangi port üzerinden ve ne zaman gönderileceği koddan değil, partner profilinden (WE20) gelir:

DATA communication TYPE STANDARD TABLE OF edidc WITH EMPTY KEY.
DATA data_records  TYPE STANDARD TABLE OF edidd WITH EMPTY KEY.

DATA(control) = VALUE edidc( mestyp = 'ZSHIPMENT'
                             idoctp = 'ZSHIPMENT01'
                             rcvprt = 'LS'
                             rcvprn = 'CARRIER01' ).

" Segment yapısı düz ve karakter tipli olmalı
data_records = VALUE #( ( segnam = 'Z1SHIPHDR'
                          sdata  = shipment_header ) ).

CALL FUNCTION 'MASTER_IDOC_DISTRIBUTE'
  EXPORTING
    master_idoc_control            = control
  TABLES
    communication_idoc_control     = communication
    master_idoc_data               = data_records
  EXCEPTIONS
    error_in_idoc_control          = 1
    error_writing_idoc_status      = 2
    error_in_idoc_data             = 3
    sending_logical_system_unknown = 4
    OTHERS                         = 5.

IF sy-subrc = 0.
  " IDoc, çağıran programın commit'i ile kalıcı olur
  COMMIT WORK.
ENDIF.

communication tablosu oluşan IDoc numaralarını döndürür; bunları kendi belgenizle ilişkilendirip kaydetmek, ileride "bu sevkiyat hangi IDoc ile gitti?" sorusunu saniyeler içinde cevaplatır.

RFC ve BAPI: SAP'ler Arası Senkron Çağrı

İki SAP sistemi arasında "şimdi şu belgeyi oluştur ve numarasını bana söyle" ihtiyacı varsa RFC üzerinden BAPI çağrısı hâlâ en kısa yoldur. Ama iki tür hatayı birbirinden ayırmak şarttır:

DATA return  TYPE STANDARD TABLE OF bapiret2 WITH EMPTY KEY.
DATA rfc_msg TYPE c LENGTH 200.

CALL FUNCTION 'BAPI_SALESORDER_CREATEFROMDAT2'
  DESTINATION 'ERP_PROD'
  EXPORTING
    order_header_in       = header
  IMPORTING
    salesdocument         = sales_document
  TABLES
    return                = return
    order_items_in        = items
    order_partners        = partners
  EXCEPTIONS
    system_failure        = 1 MESSAGE rfc_msg
    communication_failure = 2 MESSAGE rfc_msg
    OTHERS                = 3.

IF sy-subrc <> 0.
  " Teknik hata: ağ, karşı sistem, yetki. Tekrar denemek anlamlı olabilir.
  RETURN.
ENDIF.

IF line_exists( return[ type = 'E' ] ) OR line_exists( return[ type = 'A' ] ).
  " İş hatası: veri yanlış. Tekrar denemek sonucu değiştirmez.
  CALL FUNCTION 'BAPI_TRANSACTION_ROLLBACK' DESTINATION 'ERP_PROD'.
ELSE.
  CALL FUNCTION 'BAPI_TRANSACTION_COMMIT' DESTINATION 'ERP_PROD'
    EXPORTING
      wait = abap_true.
ENDIF.

Bu kodda üç şey kritik. BAPI'ler kendi kendine commit etmez; BAPI_TRANSACTION_COMMIT aynı destination ile, yani aynı RFC oturumunda çağrılmalıdır. RETURN tablosu kontrol edilmeden yapılan commit, hatalı belgeyi yarım bırakabilir. Ve teknik hata ile iş hatası ayrı ele alınmalıdır: veri hatası olan bir çağrıyı otomatik tekrar denemek, aynı hatayı yüz kez üretmekten başka işe yaramaz.

Cevabın hemen gerekmediği ama teslimin garanti olması gereken durumlarda senkron RFC yerine bgRFC (background RFC) tercih edilmelidir: çağrı kuyruğa alınır, karşı sistem kapalıysa daha sonra iletilir ve kuyruk tipine göre sıra korunur. Eski tRFC ve qRFC'nin yerini alan modern altyapı budur; izleme ekranı SBGRFCMON'dur.

OData: SAP'yi Dışarıya Açmak

Bir Fiori uygulaması, bir mobil uygulama veya bir web portalı SAP verisini anlık okuyup yazacaksa doğru araç OData'dır. S/4HANA'da yeni servisler CDS ve RAP ile yazılır; aynı iş nesnesi bir UI binding ile Fiori'ye, bir Web API binding ile dış sistemlere açılabilir. Böylece dış sistem de Fiori kullanıcısıyla aynı doğrulamalardan geçer.

Servisin nasıl kurulduğunu OData V4 ve CDS yazısında, iş kurallarının nasıl yazıldığını RAP rehberinde anlattım. Entegrasyon açısından iki uyarı yeterli:

• OData toplu aktarım aracı değildir. Gece yüz bin kaydı sayfa sayfa OData ile çekmek mümkündür ama hem SAP'yi hem karşı tarafı gereksiz yorar. Toplu veri için replikasyon, dosya veya analitik çıkarım araçları daha uygundur.
• Dış tüketiciye ayrı servis açın. Fiori için yazılmış bir UI servisini dış sisteme vermek, ekran ihtiyacı değiştiğinde entegrasyonu kırar. Web API binding'i ve ayrı bir projeksiyon, sözleşmeyi bağımsız tutar.

ABAP'tan Dışarıya REST Çağrısı

Türkiye'deki projelerde çok sık görülen bir senaryo bu yöndedir: SAP'nin bir kargo firmasının, bir bankanın veya bir e-belge entegratörünün API'sini çağırması. Aşağıdaki örnek bir sevkiyatı taşıyıcı API'ye gönderir. Adres ve kimlik bilgileri kodda değil, SM59'daki HTTP destination'dadır:

TRY.
    DATA(destination) = cl_http_destination_provider=>create_by_http_destination(
                          i_name = 'Z_CARRIER_API' ).
    DATA(client) = cl_web_http_client_manager=>create_by_http_destination( destination ).

    DATA(payload) = xco_cp_json=>data->from_abap( shipment
                      )->apply( VALUE #( ( xco_cp_json=>transformation->underscore_to_camel_case ) )
                      )->to_string( ).

    DATA(request) = client->get_http_request( ).
    request->set_uri_path( '/v1/shipments' ).
    request->set_header_field( i_name = 'Content-Type' i_value = 'application/json' ).
    " Aynı sevkiyat iki kez gönderilirse karşı taraf ikinci kaydı oluşturmasın
    request->set_header_field( i_name = 'Idempotency-Key' i_value = shipment-shipment_id ).
    request->set_text( payload ).

    DATA(response) = client->execute( if_web_http_client=>post ).
    DATA(status)   = response->get_status( ).
    DATA(body)     = response->get_text( ).
    client->close( ).

    IF status-code <> 201.
      log_error( external_id = shipment-shipment_id
                 text        = |Taşıyıcı API { status-code } döndü: { body }| ).
    ENDIF.

  CATCH cx_http_dest_provider_error cx_web_http_client_error INTO DATA(error).
    log_error( external_id = shipment-shipment_id
               text        = error->get_text( ) ).
ENDTRY.

Hata, ekranda kaybolan bir mesaj olarak değil, uygulama günlüğüne (SLG1) yazılır. Released BALI sınıflarıyla bu birkaç satırdır; günlük nesnesi (ZINTEGRATION) önceden tanımlanmalıdır:

METHOD log_error.
  TRY.
      DATA(log) = cl_bali_log=>create_with_header(
                    cl_bali_header_setter=>create( object      = 'ZINTEGRATION'
                                                   subobject   = 'CARRIER'
                                                   external_id = CONV #( external_id ) ) ).
      log->add_item( cl_bali_free_text_setter=>create(
                       severity = if_bali_constants=>c_severity_error
                       text     = CONV #( text ) ) ).
      cl_bali_log_db=>get_instance( )->save_log( log = log ).
    CATCH cx_bali_runtime.
      " Günlük yazılamasa bile asıl işi durdurma
  ENDTRY.
ENDMETHOD.

Olay Tabanlı Entegrasyon

"Talep onaylandığında İK sistemine, bordro sistemine ve bildirim servisine haber ver" gibi bir ihtiyacı üç ayrı senkron çağrıyla çözmek, SAP'yi üç sistemin de ayakta olmasına bağımlı kılar. Olay tabanlı yaklaşımda SAP yalnızca "talep onaylandı" olayını yayınlar; kimin dinlediğini bilmez.

Güncel S/4HANA sürümlerinde bunun yolu RAP business event'leridir. Olay behavior definition'da tanımlanır:

define behavior for ZR_LeaveRequest alias LeaveRequest
// ... diğer tanımlar
{
  event LeaveApproved;
}

ve kaydetme aşamasında — veri gerçekten kalıcı olurken — yayınlanır. Bu, RAP rehberindeki with additional save senaryosudur:

METHOD save_modified.
  RAISE ENTITY EVENT zr_leaverequest~LeaveApproved
    FROM VALUE #( FOR request IN update-leaverequest
                  WHERE ( Status = 'A' AND %control-Status = if_abap_behv=>mk-on )
                  ( %key = request-%key ) ).
ENDMETHOD.

Olayın dışarıya ulaşması için bir event binding ve bir olay aracısı (SAP Event Mesh, Advanced Event Mesh veya kurumun kullandığı başka bir broker) gerekir. Olayı kaydetme aşamasında yayınlamak önemlidir: işlem geri alınırsa olay da hiç çıkmaz, dinleyiciler var olmayan bir onaya tepki vermez.

Noktadan Noktaya mı, Middleware mı?

İki sistem ve tek bir akış varsa doğrudan bağlantı genellikle yeterlidir ve daha az parça demektir. Middleware (SAP Integration Suite, SAP PO veya başka bir entegrasyon platformu) şu durumlarda kendini öder:

• Aynı veri birden çok sisteme gidiyor ve her biri farklı format istiyor.
• Format dönüşümü, yönlendirme kuralları veya protokol çevirisi (IDoc → REST, dosya → OData) gerekiyor.
• Bütün akışları tek yerden izlemek, uyarı üretmek ve yeniden işlemek isteniyor.
• Kurum dışı ortaklarla EDI gibi standart protokoller konuşuluyor.

Hâlâ SAP PO kullanan kurumlar için not: SAP'nin açıkladığı bakım takvimine göre PO 7.5'in ana bakımı 2027 sonunda sona eriyor. Yeni akışları PO'da büyütmek yerine Integration Suite'e geçiş planının parçası olarak tasarlamak mantıklıdır; güncel tarihleri SAP'nin bakım stratejisinden teyit edin.

Hata Yönetimi ve İzleme

Bir entegrasyonun kalitesi, her şey yolundayken değil, bir şey bozulduğunda belli olur. Tasarım aşamasında şu dört soruya cevap verilmiş olmalıdır:

Tablonun son satırına dikkat: kendi yazdığınız REST entegrasyonlarında yeniden işleme mekanizması yoktur, siz kurarsınız. Basit ama etkili bir yol, gönderilemeyen kayıtları durumuyla birlikte bir tabloya yazıp periyodik bir arka plan işiyle tekrar denemektir.

Senaryoya Göre Hızlı Karar Tablosu

Sık Yapılan Hatalar

Sonuç

SAP entegrasyonunda "en iyi teknoloji" yoktur; senaryoya uyan teknoloji vardır. IDoc hâlâ belge taşımanın en izlenebilir yoludur, RFC hâlâ SAP'ler arası anlık çağrının en kısa yoludur, OData SAP'yi uygulamalara açmanın, HTTP istemcisi dış API'lere ulaşmanın, olaylar ise sistemleri birbirinden ayırmanın yoludur.

Seçimi belirleyen, teknolojiden önce sorulan sorulardır: cevap hemen mi gerekiyor, mesaj kaybolursa ya da iki kez gelirse ne olur, hata kime ulaşacak? Bu soruların cevabı netse, teknoloji seçimi çoğu zaman kendiliğinden ortaya çıkar. Entegrasyon projelerinde sunduğum kapsamı entegrasyon hizmet sayfasında bulabilirsiniz.