Choice, Split ve temel entegrasyon desenlerini kullanın

EIP (Enterprise Integration Pattern), mesaj işleme sırasında tekrar karşılaşılan bir sorunu çözen akış desenidir. Lunex’in Processors kataloğundaki birçok öğe bu desenleri uygular. Örneğin Choice yol seçer, Split bir mesajı parçalara ayırır, Aggregate ilişkili mesajları birleştirir.

Önce akış sırasını ve mesajın body/header/property alanlarını öğrenin. Aşağıdaki tam route örneklerini ayrı .camel.yaml dosyalarında kullanabilirsiniz. Direct girişleri için mesajı Input panelinden simülasyonla verin.

JSON örneklerindeki Simple alan erişimi için camel-bean desteğini, JSON metnini ayrıştıracaksanız camel-jackson bağımlılığını hazırlayın. Mevcut bağımlılıkları koruyarak ekleme işlemi yapılandırma rehberindedir.

İhtiyacınıza göre adım seçin

Choice: siparişin yolunu seçin

choice-order.camel.yaml dosyasına aşağıdakini ekleyin:

- route:
    id: classify-order
    from:
      uri: direct:classifyOrder
      steps:
        - choice:
            when:
              - simple: '${body[amount]} > 1000'
                steps:
                  - setHeader:
                      name: Decision
                      constant: review
            otherwise:
              steps:
                - setHeader:
                    name: Decision
                    constant: automatic
        - setBody:
            simple: '${header.Decision}: ${body[id]}'

Choice öncesinden son Set Body sonrasına kadar bölüm seçin. Input body type → JSON value kullanın.

Son Set Body, iki dalın dışındadır ve seçilen daldan sonra çalışır. Birden çok When varsa ilk doğru dal seçilir; koşulları en özel durumdan daha genel duruma doğru sıralayın. Otherwise bulunmaması, eşleşmeyen mesaj için otomatik hata oluşturmaz. Choice referansı diğer seçenekleri açıklar.

Filter: bir bölümü atlamak, bütün route’u durdurmak değildir

Bu örnekte Filter yalnız accepted başlığının eklenmesini kontrol eder. Sonraki Set Body her iki durumda da çalışır.

- route:
    id: filter-order
    from:
      uri: direct:filterOrder
      steps:
        - filter:
            simple: '${body[amount]} > 1000'
            steps:
              - setHeader:
                  name: accepted
                  constant: 'yes'
        - setBody:
            constant: after-filter

Filter ve son Set Body’yi birlikte seçin; JSON value ile {"amount":120} verin, headers alanını {} bırakın. Son body after-filter, accepted başlığı ise yoktur. 1500 ile yeniden deneyince body yine aynı, başlık yes olur. Filter referansı.

Mesaj koşulu sağlamıyorsa hata istiyorsanız Validate; bir dalın işlemeyi sonlandırmasını istiyorsanız o dala Stop yerleştirin. Bunlar Filter’ın iç bölümünü atlamaktan farklı sonuçlar doğurur.

Split: listeyi parçalara ayırın

split-orders.camel.yaml dosyasına ekleyin:

- route:
    id: split-orders
    from:
      uri: direct:splitOrders
      steps:
        - split:
            simple: '${body}'
            parallelProcessing: false
            stopOnException: true
            steps:
              - setBody:
                  simple: 'Order ${body[id]}'
        - setHeader:
            name: BatchFinished
            constant: 'yes'

1. Designer’da Split → Start before, sonraki Set Header → End after seçin.
2. Input body type → JSON value ile şu listeyi verin:

[{"id":"A-100"},{"id":"A-101"},{"id":"A-102"}]

3. Simulate çalıştırın. Split içindeki Set Body sonucunu açın; Visit listesindeki üç alt mesajı inceleyin.
4. Sırasıyla Order A-100, Order A-101, Order A-102 görmelisiniz.
5. Split dışındaki Set Header sonucunda BatchFinished = yes vardır. Body, girişteki sipariş listesidir; üç metnin otomatik birleşimi değildir.

Bu örnekte bir aggregation strategy tanımlanmadığı için Split sonrası ana mesaj korunur. Parçalardan yeni bir toplu yanıt üretmek istiyorsanız Split’in Aggregation Strategy ayarını ayrıca tanımlayın. Split içindeki nesneleri yerinde değiştirmekten kaçının; paylaşılan nesne referansları ana veriyi de etkileyebilir.

Split ayarlarını bilinçli seçin

Temel ayarların kapsamı Split referansında açıklanır. Gözlemdeki CamelSplitIndex sıfırdan başlar; ilk parça 0 değerindedir. Gerçek veriyle çalışmadan önce boş liste, tek öğe ve bir öğenin hata vermesi durumlarını da deneyin.

Aggregate: birbirinden ayrı mesajları bir grupta tamamlayın

Örneğin aynı siparişin üç ayrı kalem mesajı farklı zamanlarda geliyor. Aggregate kurarken şu kararları verin:

1. Correlation Expression: Hangi mesajlar aynı gruba ait? Örneğin Header diliyle OrderId değeri. İki farklı siparişin aynı gruba girmemesi gerekir.
2. Aggregation Strategy: Yeni kalem önceki sonuca nasıl ekleniyor? Bir liste oluşturmak ile tutarları toplamak farklı kurallardır. Seçtiğiniz strategy nesnesini/bean’ini runtime’a hazırlayın.
3. Tamamlanma: Grup ne zaman gönderilecek? Örneğin Completion Size = 3, üç mesajı bekler; Completion Timeout, grubun belirli süre yeni mesaj almamasına göre tamamlanabilir.
4. Eksik veya geç mesaj: Üçüncü kalem gelmezse, grup tamamlandıktan sonra bir kalem daha gelirse veya çalışma yeniden başlarsa ne olacağını tanımlayın.
5. Saklama: Yeniden başlatma sonrasında bekleyen gruplar korunmalıysa uygun kalıcı aggregation repository hazırlayın; varsayılan bellek deposuna dayanmayın.

Split’in Aggregation Strategy’si bir girişten çıkan parçaların sonucunu toplar; Aggregate adımı ise ayrı gelen mesajları gruplar. Her Split’in arkasına Aggregate eklemek zorunlu değildir. Aggregate referansı strategy, tamamlanma ve repository seçeneklerini açıklar.

Simülasyonun her çalıştırması yeni bir denemedir. Üç ayrı Simulate çağrısının aynı Aggregate belleğini paylaşmasını beklemeyin. Mesajlar arası birikmeyi, timeout’u ve yeniden başlatmayı aynı gerçek geliştirme runtime’ında kontrollü girişlerle doğrulayın.

Multicast, ardışık To ve WireTap farkı

Multicast varsayılan olarak hedefleri sırayla işler; Parallel Processing açıldığında eşzamanlı çalıştırır. Normal tamamlanmada sonraki adıma geçmeden hedeflerin tamamlanmasını bekler. Çıkışın iki yanıtı bir JSON dizisine çevirmesini istiyorsanız uygun Aggregation Strategy gerekir; varsayılan son yanıtı kullanır. Kopyalar içlerindeki değiştirilebilir nesneleri paylaşabileceği için bir dalın nesneyi yerinde değiştirmesine dikkat edin. Multicast referansı.

Kalıcı teslimat, bağımsız tekrar deneme veya uzun süreli bekleme gerekiyorsa broker kuyruğu tasarlayın. Multicast ve WireTap tek başına dayanıklı mesaj deposu oluşturmaz.

Loop: önceki tekrarın sonucuyla devam edin

Aşağıdaki route’ta Loop adımını tek başına simüle edin. Text girdisi start olsun.

- route:
    id: repeat-marker
    from:
      uri: direct:repeatMarker
      steps:
        - loop:
            constant: '3'
            steps:
              - setBody:
                  simple: '${body}-x'

İç Set Body’nin üç Visit sonucu start-x, start-x-x, start-x-x-x olur. Varsayılan Loop’ta her tekrar önceki mesajla devam eder. Copy seçeneği açılırsa her tekrar başlangıç mesajının bir kopyasıyla başlar; bu örnekteki biriken sonuç beklenmez. Loop referansı.

Akışı doğrulayın

Her desen için normal girdi, sınır değer, boş/eksik alan ve hata durumunu deneyin. Yalnız son body’ye bakmayın: seçilen dalı, Visit sayısını, headers/properties değerlerini ve dış sistemdeki etkiyi de kontrol edin. Simülasyonda dış alıcı yanıtlarını Receivers ile verirsiniz; gerçek teslimatı daha sonra Run ile doğrulayın.

Koşulları yazmak için Simple, daha ayrıntılı dönüşümler için Groovy, başarısız işlerin davranışı için hata yönetimi ile devam edin.