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:
- Iflow'u edit moduna alın ve JMS Sender adaptörüne tıklayın.
- "Processing" sekmesinde "Dead-Letter Queue" seçeneğinin işaretli olduğunu doğrulayın.
- Expiration Period (varsayılan 90 gün) değerini senaryonuza göre ayarlayın.
- Retry Interval'i kullanım örneğinize uygun seçin (genelde 60 dakika makul bir başlangıçtır).
- 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.
