SAP Integration Suite'de Dead Letter Handling Nasıl Yapılır? Mesaj Kaybını Önleme Rehberi

SAP Integration Suite'de işlenemeyen bir mesajın sonsuz döngüye girip sistemi kilitlemesini önleyen en kritik mekanizma Dead Letter Handling'dir. Bu yazıda DLQ'nun nasıl çalıştığını, ne zaman devreye girdiğini ve mesaj kaybetmeden doğru kurgulamanın yollarını ele alacağız.

SAP Integration Suite’de Dead Letter Handling ile Mesaj Kaybını Nasıl Önlersiniz?

Kısa cevap: SAP Integration Suite'de Dead Letter Handling (DLQ), node çökmesi veya bellek hatası gibi beklenmedik nedenlerle işlenemeyen mesajların sonsuz döngüye girmesini engelleyen güvenlik mekanizmasıdır. Bir mesaj iki defa anormal şekilde başarısız olursa otomatik olarak Dead Letter Queue'ya alınır ve sistem ayakta kalır. Bu sayede tek bir bozuk mesaj yüzünden tüm entegrasyon trafiği durmaz, hiçbir mesaj da kaybolmaz; geri dönülebilir bir konuma alınır. Bu yazıda DLQ'nun ne zaman devreye girdiğini, normal retry'dan farkını, izleme adımlarını ve sahada karşılaştığımız tipik senaryoları örneklerle açıklıyoruz.

Dead Letter Handling Nedir?

Dead Letter Handling, asenkron mesajlaşmada işlenemeyen mesajların ne yapılacağını tanımlayan bir tasarım desenidir. Mesaj, normal kuyrukta kalmak yerine "ölü mektup kuyruğuna" (Dead Letter Queue – DLQ) taşınır. Böylece:

• Üretim sistemleri sürekli aynı bozuk mesajla uğraşmaz.
• Mesaj silinmez, geri çağrılabilir bir yerde bekler.
• Operasyon ekibi sorunu fark edip müdahale edebilir.

SAP Integration Suite (eski adıyla SAP CPI) tarafında bu mekanizma özellikle JMS adaptörü üzerinden çalışan asenkron iflow'larda devreye girer. Yazının ilerleyen bölümlerinde adımları somut bir senaryo üzerinden ele alacağız.

DLQ Ne Zaman Devreye Girer? (Yaygın Yanılgı)

Sahada en sık karşılaştığımız hata: "Mapping hatası alan mesajlar DLQ'ya gidiyor sanıyorduk." Aslında durum farklıdır.

DLQ devreye girer:

• Worker node beklenmedik şekilde çöktüğünde (out-of-memory, kill, restart).
• Mesaj polled edildikten sonra işlem tamamlanmadan node yeniden başlatıldığında.
• Tipik olarak iki ardışık node-level başarısızlıktan sonra mesaj DLQ'ya alınır.

DLQ devreye girmez:

• Mapping exception, format hatası, business validation hatası.
• Receiver sistemin 4xx/5xx döndürmesi (bağlantı problemleri normal retry mekanizmasında işlenir).
• Senaryoda explicit retry tasarladıysanız, mesaj tanımladığınız retry/error path'inde gezer.

Kısaca: DLQ, "içerik bozuk" mesajları için değil, "sistem mesajı işleyemedi ve döngüye soktu" senaryoları için tasarlanmıştır. Bu ayrımı netleştirmek, hata yönetiminin doğru kurulması için kritiktir.

JMS Adaptöründe Dead Letter Queue Konfigürasyonu

Dead Letter Handling, JMS Sender adaptöründe varsayılan olarak açıktır. Iflow'unuzu açıp JMS Sender adaptörünü seçtiğinizde "Dead-Letter Queue" işaretli bir checkbox göreceksiniz. Adımlar şöyledir:

1. Iflow'u edit moduna alın ve JMS Sender adaptörüne tıklayın.
2. "Processing" sekmesinde "Dead-Letter Queue" seçeneğinin işaretli olduğunu doğrulayın.
3. Expiration Period (varsayılan 90 gün) değerini senaryonuza göre ayarlayın.
4. Retry Interval'i kullanım örneğinize uygun seçin (genelde 60 dakika makul bir başlangıçtır).
5. Iflow'u deploy edin ve Message Locks monitor'den kuyruktaki kilitleri izleyin.

Performans notu: DLQ mekanizması veritabanı üzerinde çalıştığı için yüksek hacimli senaryolarda dikkate değer bir maliyet getirir. Mesaj boyutunuzun küçük ve sabit olduğunu biliyorsanız, performans için DLQ'yu kapatabilirsiniz; ancak büyük mesajların node'u out-of-memory'ye sokma riskini göz önünde bulundurmalısınız. Tavsiyemiz: DLQ'yu açık bırakın, bunun yerine sender adaptörde size check ile büyük mesajları en başta reddedin.

DLQ’daki Mesajları İzleme ve Geri Alma

DLQ'ya düşen mesajlar otomatik olarak geri yüklenmez. Operasyonel olarak izlenmesi ve manuel ya da yarı-otomatik bir mekanizmayla ele alınması gerekir.

Adım 1: Queue Monitor

Operations View → Manage Stores → Message Queues bölümünde DLQ'daki mesajları görebilirsiniz. Status alanı "Blocked" olan mesajlar müdahale bekleyenlerdir.

Adım 2: Mesajı Tekrar İşleme Alma

Sorunun kök nedeni çözüldüğünde (örneğin worker node restart sonrası ortam stabil hale geldiğinde) ilgili mesajı seçip "Retry" diyebilirsiniz. Mesaj tekrar normal kuyruğa alınır ve standart akış üzerinden işlenir.

Adım 3: Otomatik Alarm

Üretim ortamlarında DLQ'nun manuel kontrolüne güvenmek tehlikelidir. SAP Integration Suite'in /api/v1/Queues OData servisini kullanarak DLQ doluluğunu sorgulayan ve eşik aşıldığında alarm üreten yardımcı iflow'lar geliştirilebilir. Bu, üretimde "sessiz mesaj kaybı"nı önlemenin en kritik adımıdır.

Sahadan Bir Örnek: Sipariş Mesajları Neden DLQ’ya Düştü?

Bir müşterimizde S/4HANA'dan gelen sipariş mesajları belirli saatlerde DLQ'ya düşüyordu. Mesajların içeriği temizdi, mapping çalışıyordu, hedef sistem ayakta görünüyordu. Klasik soru: "Mesaj neden DLQ'da?"İncelemede şunu gördük: Sipariş mesajlarına ek olarak gönderilen büyük dosyaların boyutu kontrol edilmiyordu. Yoğun saatlerde 30-40 MB'lık mesajlar peş peşe geldiğinde worker node bellek limitine ulaşıyor, restart oluyor, mesaj DLQ'ya alınıyordu.Çözüm: Sender adaptörde size check eklendi (10 MB üstü mesajlar reddedildi), büyük dosyalar ayrı bir SFTP akışına yönlendirildi. DLQ trafiği üç hafta içinde sıfıra düştü. Önemli ders: DLQ'yu kapatmak değil, oraya düşme nedenlerini önlemek esastır.

Dead Letter Handling İçin En İyi Uygulamalar

• DLQ'yu açık tutun. Performans gerekçesiyle kapatmak yerine, mesaj boyutunu ve içeriğini iflow başında valide edin.
• Size check kullanın. Büyük mesajları en başta reddetmek, DLQ'ya yığılmasını önler.
• Alarm kurun. DLQ doluluğunu izleyen otomatik bir kontrol mekanizması olmadan üretime çıkmayın.
• Business hatalarını ayırın. Mapping ve validation hatalarını ayrı bir error path'e (Data Store ya da error queue) yönlendirin; DLQ bu işler için tasarlanmamıştır.
• Expiration süresini bilinçli seçin. Varsayılan 90 gün her senaryo için doğru değildir; finansal mesajlarda daha uzun, geçici sinyallerde daha kısa süre uygun olabilir.
• Sıralı işleme gerekiyorsa dikkatli olun. DLQ'dan geri alınan mesajlar sıralamayı bozabilir. Order-sensitive akışlarda bu davranışı önceden test edin.

Sıkça Sorulan Sorular

DLQ ile retry mekanizması aynı şey mi?

Hayır. Retry, mesajı belirli aralıklarla tekrar dener. DLQ ise sistem tarafından beklenmedik şekilde işlenemeyen mesajları güvenli bir alana taşır. İkisi farklı problemler için tasarlanmıştır ve genelde birlikte çalışır.

DLQ’daki mesajlar otomatik geri yüklenebilir mi?

Standart davranışta hayır; bilinçli bir tercih. Mesajın neden DLQ'ya düştüğü değerlendirilmeden geri yüklenmesi aynı sorunun tekrarına yol açabilir. Ancak ihtiyaç halinde Data Store tabanlı custom retry akışlarıyla yarı-otomatik bir çözüm tasarlanabilir.

Tüm adaptörlerde DLQ var mı?

Hayır. Dead Letter Queue özelliği özellikle JMS adaptöründe tam destekli olarak gelir. AMQP gibi adaptörlerde davranış messaging broker'ın yeteneğine bağlıdır. SOAP, HTTP gibi senkron adaptörlerde DLQ kavramı yoktur; hata anında çağrana iletilir.

DLQ Yönetimini Daha Akıllı Hale Getirmek

Dead Letter Handling güçlü bir güvenlik ağı sunar; ancak üretim ortamlarında ekiplerin gerçekten ihtiyaç duyduğu şey, DLQ'yu manuel kontrol etmek zorunda kalmadan görünürlük ve müdahale yeteneğine sahip olmaktır.

Sonuç

Dead Letter Handling, SAP Integration Suite’de mesaj kaybını önleyen en kritik güvenlik mekanizmalarından biridir; ancak gerçek değeri, doğru yapılandırılması ve aktif olarak izlenmesiyle ortaya çıkar. DLQ’yu sadece “açık bırakıp unutulan bir checkbox” olmaktan çıkarıp operasyonel bir disipline dönüştürdüğünüzde, hem üretim kararlılığınız hem de mesaj güvenliğiniz ciddi şekilde artar.SAP Integration Suite ve MDP Integration Platform ortamınızda Dead Letter Handling kurgusunu doğru tasarlamak, mevcut DLQ trafiğini analiz etmek ve uçtan uca izleme ve alarm yapısını hayata geçirmek için bizimle iletişime geçebilirsiniz.