2012-08-09 10 views
5

Moja obecna sytuacja:Mule 3: Kontrolowanie czy przepływ może być wykonywany

Obecnie mam aplikacja Mule ESB z trzech strumieni, które wiadomości procesowe pochodzące z dwóch różnych źródeł, te trzy strumienie są ze sobą powiązane przy użyciu kolejki maszyn wirtualnych.

przepływu 1:

przychodzących (punkt końcowy 1) -> (wykonać przetwarzanie i przekształcenia wiadomości) -> wychodzących (końcowy 3)

przepływu 2:

Przychodzące (punkt końcowy nr 2) -> (przetwarzanie komunikatów i transformacje) -> Wychodzące (punkt końcowy nr 3)

Przepływ nr 3

przyjazdowa (Endpoint # 3) -> (Wykonaj przetwarzania i transformacji wiadomości, robić rzeczy) ->

Problem Wychodzące/Problem:

Teraz to, co chcę zrobić, to wprowadzić czwarty flow, Flow # 4, który pobiera informacje o stanie z przychodzącego punktu końcowego i opierając się na tych informacjach, może uniemożliwić wykonanie Flow # 3/uniemożliwić przetwarzanie jego wiadomości przychodzących.

Innymi słowy, najbardziej chciałbym, aby Flow 4 działał przy uruchomieniu aplikacji ESB (tak jak wszystkie przepływy wydają się robić automatycznie) i na podstawie informacji o stanie, które otrzymuje z wiadomości przychodzącej , uniemożliwić/zezwolić lub włączyć/wyłączyć przepływ nr 3 od kiedykolwiek przetwarzania wiadomości z punktu końcowego # 3.

Oto co mi idealnie wymagać:

Wymagania:

  1. musi być w stanie osiągnąć wyłącznie poprzez XML przepływu muł, bez dodatkowych POJO/niestandardowe obiekty Java.
  2. Przepływ nr 4 musi zostać wykonany przy uruchomieniu aplikacji ESB i musi zostać przetworzona tylko pierwsza wiadomość przychodząca.
  3. Idealnie nie chcę, aby Flow nr 3 miał kompozytowe źródło przychodzące lub musiał oceniać każdą przychodzącą wiadomość stan jakiejś zmiennej globalnej.

Jaki jest najlepszy sposób na osiągnięcie tego, co chcę zrobić?

Jeśli nie ma naprawdę dobrego rozwiązania, to jeśli muszę pominąć wymaganie nr 3, jaki jest najlepszy sposób na uzyskanie takiej globalnej zmiennej, która jest dzielona między dwoma niezależnymi przepływami, które nie są powiązane przez niektóre wychodzące -> przychodzący punkt końcowy w konfiguracji XML? Próbowałem już używać właściwości sesji, ale wymagają one, aby przepływy były powiązane jako podfajdy lub przez punkt końcowy.

Dzięki.

+0

Już miałem zaproponować # 3, tj. za pomocą zmiennej globalnej w rejestrze Mule. Dlaczego nie jest to dopuszczalne? Ponadto, chociaż nie będzie wymagana niestandardowa klasa Java, pojawi się kilka skryptów MEL/Groovy. –

+0

Cóż, znowu wymagania, szczególnie # 3, są właśnie tym, co idealnie mi się podoba. Ale jeśli nie ma lepszego rozwiązania lub sposobu osiągnięcia pożądanego zachowania, to jest to moja ostatnia deska ratunku. Jak zmienna globalna, jak to zrobić, zostanie wykonana w konfiguracji XML? Jak deklarować globalnie zmienną w XML poza przepływami i odnosić ją do przepływów? Dzięki. – MikeCompSciGeek

Odpowiedz

6

Użyj właściwości globalne i kilka wyrażeń MEL aby tak się stało:

<global-property name="gate_open" value="true" /> 

<flow name="gated-flow"> 
    <vm:inbound-endpoint path="gated.in" /> 
    <expression-filter expression="#[app.registry.gate_open]" /> 
    ... 
</flow> 


<flow name="gate-controller"> 
    <vm:inbound-endpoint path="gate.in" /> 
    <expression-component> 
     app.registry.gate_open = false 
    </expression-component> 
</flow> 

wysyła żadnych wiadomości do vm://gate.in zamknie bramę i gated-flow zatrzyma przetwarzania wiadomości, które otrzymuje.

Możesz użyć dowolnego protokołu, zamiast VM.

+0

Awesome, thanks! To znacznie prostsze i czystsze rozwiązanie, niż myślałem. – MikeCompSciGeek

+0

Wygląda na to, że jest przeznaczony do przyjmowania tylko jednej wiadomości: oba strumienie otrzymują komunikat od punktu końcowego, a jeden przepływ zamyka drugi przepływ. Zastanawiam się, czy może to spowodować sytuację wyścigową, w wyniku której może wystąpić jedna z dwóch nieprzyjemnych rzeczy: 1) przepływy kontrolera wyłączają bramkowany przepływ przed pierwszą wiadomością lub 2) druga wiadomość może zostać zsunięta przez bramę przed pierwszą wiadomością. przepływ kontrolera ma szansę zmienić wartość zmiennej. – Rondo

+1

"oba strumienie otrzymują komunikat od punktu końcowego": ujemne, słuchają dwóch różnych kolejek maszyn wirtualnych: 'gated.in' i' gate.in'. –

Powiązane problemy