Akış sırasını ve mesajın değişimini okuyun

Bir route, girişine gelen her mesaj için tanımlı adımları yürütür. Aynı adım listesindeki işlemler sırayla ilerler; Choice, Split veya Multicast gibi bir işlem bu sıranın içinde kendi çalışma kuralını uygular. Diyagramı okumak için hem okları hem de adımların hangi bloğun içinde olduğunu takip edin.

Önce mesaj ve veri temellerini, ardından Designer ile route oluşturmayı öğrenin. Bu sayfadaki örnek için dış servis gerekmez; simülasyon yeterlidir.

Giriş, adımlar ve çıkış

Akışın parçası	Ne olur?
`from`	Mesajın nereden geldiğini belirler. Timer mesaj üretir, JMS kuyruktan alır, Direct aynı runtime’daki bir çağrıyı kabul eder.
`steps`	Gelen mesaj üzerinde sırayla çalışacak işlemleri içerir.
`to`	Mesajı bir endpoint’e gönderir. Bu endpoint başka bir route veya dış sistem olabilir.
Route’un sonu	Bu route’taki adımlar biter. Sonucun çağırana dönmesi veya kuyruk tesliminin tamamlanması, girişin ve hata yönetiminin çalışma biçimine bağlıdır.

Ekrandaki bir Set Body öğesi, kendisine gelen body’yi okuyup yeni değerle değiştirir. Dört Set Body’yi art arda eklemek dört bağımsız çıktı oluşturmaz. Örneğin ilk adım Constant A, ikinci adım Constant B ise sonraki adımın body’si B olur. Önceki değer gerekiyorsa değişiklikten önce bir Set Property ile saklayın.

Örnek: bir route diğerini çağırıyor

Source → Files → Create file ile flow-order.camel.yaml oluşturun. Aşağıdaki iki route’u aynı dosyaya koyun; Saved durumunu bekleyin.

- route:
    id: prepare-greeting
    description: Prepare greeting
    from:
      uri: direct:prepareGreeting
      steps:
        - setProperty:
            name: originalName
            simple: '${body}'
        - setBody:
            simple: 'Hello ${body}'
        - to:
            uri: direct:markGreeting
        - setBody:
            simple: '${body}!'
- route:
    id: mark-greeting
    description: Mark greeting
    from:
      uri: direct:markGreeting
      steps:
        - setBody:
            simple: '${body} / checked'

direct:markGreeting aynı çalışan proje içindeki ikinci route’u çağırır. Çağrı tamamlanınca ilk route, To’dan sonraki adımla devam eder. Dosyanın ikinci route’u kendiliğinden ilkinden sonra çalışmaz; onu çalıştıran bu açık çağrıdır. Aynı adlı Direct endpoint’ler farklı proje runtime’larını birbirine bağlamaz. Bu davranışın ayrıntısı Direct referansındadır.

Prepare greeting route'undaki adımlar, Direct ile çağrılan Mark greeting route'u ve çağrıdan sonra devam eden son Set Body.

Mesajı adım adım izleyin

Designer görünümünde ilk route’un Set Property adımına sağ tıklayıp Start before seçin.
Aynı route’un son Set Body adımına sağ tıklayıp End after seçin. Bölüm seçimi başlangıç ve bitiş kapsamını açıklar.
Input → Input body type → Text seçin; Body’ye Lunex yazın. Headers ve exchange properties boş JSON nesnesi ({}) olabilir.
Simulate seçin. Output → Observed step ile ana route ve çağrılan route’un adımlarını inceleyin.

Tamamlanan adım	Body	`originalName` exchange property
Set Property	`Lunex`	`Lunex`
İlk Set Body	`Hello Lunex`	`Lunex`
Çağrılan route’un Set Body’si	`Hello Lunex / checked`	`Lunex`
Ana route’un son Set Body’si	`Hello Lunex / checked!`	`Lunex`

Before, seçilen adıma giren; After, o adım tamamlandıktan sonraki mesajdır. Compare ile değişikliği karşılaştırın. Örneğin To adımının After değeri, çağırdığı Direct route’un sonucunu da içerir. Sonuçları inceleme tekrarları ve hata sonuçlarını açıklar.

Bu Direct girişler zamanlayıcı değildir: yalnız Run seçmek kendiliğinden Lunex mesajı üretmez. Gerçek çalışmada bir route, API operation’ı veya uygun giriş kaynağı bu route’u çağırmalıdır. HTTP girişi için operation–route ilişkisini kullanın.

İç içe adımları okuyun

Code görünümündeki girinti kapsamı, aynı steps listesindeki konum sırayı belirler. Designer’da yeni adımı hangi öğeye eklediğinizi kontrol edin.

Konum	Ne zaman çalışır?
Choice içindeki bir `when` dalı	O dal seçildiğinde.
Choice ile aynı seviyedeki sonraki adım	Seçilen dal tamamlanıp akış normal devam ettiğinde.
Split’in `steps` listesi	Her alt mesaj için.
Split ile aynı seviyedeki sonraki adım	Split tamamlandıktan sonra ana mesaj için.
Do Try içindeki adım	Try bölümüne girildiğinde; hata halinde uygun Catch/Finally kuralları devreye girer.

Bir Logger’ı Split’in içine koyarsanız her parça için kayıt üretir; dışına koyarsanız Split sonrası mesajı kaydeder. Insert/Add sonrasında Code’daki girintiyi ve simülasyondaki Visit kayıtlarını birlikte inceleyin. Temel EIP rehberi bu farkı örneklerle gösterir.

Ekrandaki yerleşim çalışma sırası mıdır?

Grafiğin ekrana sığdırılması, yakınlaştırılması veya Architecture yerleşiminin değiştirilmesi route kaynaklarını yeniden sıralamaz. Çalıştırma tanımı dosyadaki route, endpoint ve steps yapısıdır. Aynı projede iki Timer veya iki kuyruk tüketicisi varsa mesajları birbirinden bağımsız başlatabilirler; bir route’un sayfada üstte bulunması diğerinden önce biteceği anlamına gelmez.

Paralel Split/Multicast, SEDA veya broker kullanımı sıralamayı ayrıca etkiler. İşin “A tamamlanınca B” olması gerekiyorsa bağlantının bekleme davranışını ve paralellik seçeneklerini tasarlayın. Mesajlaşma kalıcı kuyruk ile aynı runtime içindeki çağrıyı ayırır.

Beklediğiniz adım çalışmadıysa

Belirti	Kontrol
Yeni Set Body eski değeri kaybetti	Constant mı, önceki body’yi kullanan expression mı? Korunacak değeri daha önce sakladınız mı?
Bir dalda gözlem yok	Choice koşulu o dalı seçti mi; daha önce hata veya Stop oluştu mu?
Split içindeki adım bir kez çalıştı	Simülasyonda yalnız iç adımı mı seçtiniz? Bölmeyi denemek için Split’in tamamını seçin.
İkinci route çalışmadı	`to` ile `from` endpoint adları eşleşiyor mu; ikisi aynı runtime’da mı?
Yeni düzenleme görünmüyor	Simülasyonu yeniden çalıştırın; gerçek runtime için Saved sonrası Run/Reload veya commit ve Build uygulayın.

Sıradaki konu: Processors, Components ve Kamelets; ardından Choice, Split ve diğer EIP’ler.