Hataları yönetin ve yeniden deneyin

Hata yönetimi, başarısız bir adımın ardından mesajın ve çağıranın ne göreceğini belirler. İki soruyu birlikte yanıtlayın: işlem yeniden denenebilir mi; denemeler bittiğinde mesaj nereye gider ve hangi sonuç döner?

Veritabanına yazan bir işlemde bunu uygulamalı görmek için sipariş ve stok rollback örneğini ve tekrar deneme kararlarını izleyin. Hata yanıtı üretmek, önceki yazmaları kendiliğinden geri almaz.

Geçersiz bir müşteri kodu ile geçici bağlantı kesintisi aynı davranışı gerektirmez. İlkinde açık bir iş hatası döndürmek, ikincisinde sınırlı yeniden deneme yapmak uygun olabilir.

Hata türünü ayırın

Route içindeki exception handler, başlamayan bir container’ı düzeltmez. API request doğrulamasında reddedilen girdi de iş route’unun onException adımlarına ulaşmayabilir. Önce hatanın hangi sınırda oluştuğunu bulun.

Hata yönetimi araçlarını seçin

Görsel editörde ilgili route veya Route Configuration üzerinde adım ekleyebilir; On Exception, Try, Catch, Finally gibi öğeleri uygun kapsamda seçebilirsiniz. Hata yöneticisi ve redelivery ayrıntıları özellik panelinde düzenlenir. Karmaşık yapı veya kapsamı Code görünümünden de kontrol edin.

İş hatasını kontrollü yanıta çevirin

Aşağıdaki tam örnek, invalid gövdesi geldiğinde hatayı yakalar ve güvenli bir JSON hata içeriği oluşturur. Ayrı bir order-errors configuration yalnızca onu referanslayan route’a uygulanır.

- routeConfiguration:
    id: order-errors
    onException:
      - onException:
          exception:
            - java.lang.IllegalArgumentException
          redeliveryPolicy:
            maximumRedeliveries: 0
          handled:
            constant: "true"
          steps:
            - setHeader:
                name: CamelHttpResponseCode
                constant: 400
            - setHeader:
                name: Content-Type
                constant: application/json
            - setBody:
                constant: '{"code":"INVALID_ORDER","message":"Order data is not valid"}'
- route:
    id: validate-order
    routeConfigurationId: order-errors
    from:
      uri: direct:validateOrder
      steps:
        - choice:
            when:
              - simple: "${body} == 'invalid'"
                steps:
                  - throwException:
                      exceptionType: java.lang.IllegalArgumentException
                      message: Invalid order input
            otherwise:
              steps:
                - setBody:
                    constant: accepted

1. Örneği bir .camel.yaml dosyasına koyun ve kaydedilmesini bekleyin.
2. Simulation içinde validate-order route’unu seçin.
3. Metin body olarak invalid gönderin. Handler’ın çalışmasını, gövdeyi ve CamelHttpResponseCode header’ını inceleyin.
4. Başka bir metin gönderin; bu kez accepted sonucu beklenir.
5. Route’u HTTP API’den çağıracaksanız validateOrder operation’ını ve onun istek/yanıt sözleşmesini ayrıca tanımlayın. HTTP durum kodu ancak HTTP çağrısında anlam kazanır.

handled: true, hatayı çağırana exception olarak iletmez; özgün route hata noktasında durur ve handler sonucunu üretir. continued ise handler sonrasında akışı sürdürmek içindir. Hata sonrası sıradaki iş adımının çalışıp çalışmaması gerektiğine göre seçin; teknik exception’ın yakalanması işin başarıyla tamamlandığı anlamına gelmez.

Geçici hataya yeniden deneme ekleyin

İlgili On Exception → Redelivery Policy altında örneğin:

redeliveryPolicy:
  maximumRedeliveries: 3
  redeliveryDelay: "1000"
  useExponentialBackOff: true
  backOffMultiplier: 2

Bu, ilk denemeye ek olarak en fazla üç tekrar ve büyüyen bekleme süresi tanımlar. Gecikme milisaniyedir. Redelivery genellikle başarısız adımı yeniden çalıştırır; tüm iş akışının baştan güvenle tekrarlanacağını varsaymayın. Exception türünü bağlı component’in gerçekten ürettiği hataya göre seçin.

Tekrar edilen işlem dış sisteme kayıt oluşturuyorsa aynı işin iki kez yapılmasını önleyen bir iş anahtarı veya idempotency tasarımı kullanın. Belirsiz timeout sonrasında karşı taraf isteği işlemiş olabilir. API istemcisinin, route’un ve broker’ın tekrar ayarlarını birlikte değerlendirin; üç katmanın aynı işi art arda çoğaltmasını önleyin.

Kurtarılamayan mesajı dead letter yapın

Tekrar işlendiğinde de başarısız olacak bir mesaj, başarılı mesajların önünden ayrılmalı ve inceleme için saklanmalıdır. Lunex’te bunun yeri dead letter’lardır: her kurulumda DLA adresinde toplanır, Lunex MCP araçlarıyla listelenir, incelenir, yeniden denenir veya silinir.

• Mesaj bir Artemis kuyruğundan transacted: true ile tüketiliyorsa hatayı fırlatın. Broker teslimi yeniden dener ve denemeler bitince mesajı dead letter yapar. Hedefin her denemede aynı şekilde reddedeceğini bildiğiniz hatada mesajı io.etzel.lunex.ParkMessage ile hemen park edin.
• Mesaj senkron bir çağrıdan, örneğin bir HTTP isteğinden geliyorsa hatayı yukarıdaki gibi kontrollü bir yanıta çevirin. Mesajı çağıran sistem tutar.
• Kaynak mesajı yeniden gönderemiyorsa önce kalıcı bir kuyruğa yazın ve ayrı bir teslim akışıyla tüketin. Adımlar kuyruk oluşturma ve teslim rehberindedir.

Route’a kendi deadLetterChannel hata yöneticisini veya ayrı bir hata kuyruğunu eklemeyin. Böyle bir kuyruktaki mesajlar dead letter araçlarında ve uyarılarda görünmez. Teslim akışındaki bir routeConfigurationId ayrıca park kuralını devre dışı bırakır. Park örneği ve dead letter araçları asenkron mesajların sorumluluğu ve dead letter’lar sayfasındadır.

Yerel try/catch kullanın

Bir adım grubunun hatasını aynı yerde ele almak için şu yapı kullanılabilir:

- doTry:
    steps:
      - throwException:
          exceptionType: java.lang.IllegalStateException
          message: Example failure
    doCatch:
      - exception:
          - java.lang.IllegalStateException
        steps:
          - setBody:
              constant: fallback-result
    doFinally:
      steps:
        - log:
            message: Local attempt finished

Bu parça bir route’un steps listesine eklenir. Beklenen sonuç fallback-result gövdesi ve finally log’udur. doTry kendi hata kapsamını kurar; içindeki hatalar için normal onException politikasının da çalışacağını varsaymayın. Hatanın yerel catch’e mi ortak handler’a mı ait olacağına açıkça karar verin. Try/catch kapsamının teknik tanımı bu davranışı açıklar.

API hata sözleşmesini tamamlayın

İş hatası için döndüğünüz durum kodunu, content type’ı ve JSON yapısını API design → Responses içinde belgeleyin. Dışarıya stack trace, parola veya iç sistem ayrıntısı döndürmek yerine anlaşılır kod ve mesaj üretin. Gerekli ayrıntıyı uygun kayıt seviyesinde içeride tutun.

400, 404 veya 409 tanımını eklemek route’a otomatik hata davranışı katmaz. CamelHttpResponseCode, Content-Type ve body’yi handler’da üretin; sonra Try it → Running project ile gerçek yanıtı görün.

Hata davranışını doğrulayın

Her akışta en az doğru girdi, beklenen iş hatası ve bağlı sistem başarısızlığı senaryosunu çalıştırın. Simulation’da örnek receiver yanıtlarıyla dalları inceleyin; gerçek runtime’da bağlantı, redelivery ve broker davranışını ayrıca doğrulayın.

İşlem kaydını Application ID ile ilişkilendirin. Handler sonucu, son body/header, deneme sayısı ve dead letter’a düşen mesajı birlikte kontrol edin. Genel Exception yakalayıp her durumda başarı döndürmek, işletim sırasında gerçek hatayı görünmez hâle getirebilir.