2011-05-29 16 views
5

Pracuję nad PoC dla małego silnika procesowego opartego na Camelu. Wymagania to możliwość wykonania zestawu kroków konsekwencji, a każda z nich może potencjalnie zająć kilka godzin. Asynchroniczny styl komunikacji jest oczywistym wyborem w tym przypadku, ale mam problem z uzyskaniem części "procesowej".Podejście do obsługi długotrwałych procesów z Camelem

Wysyłając wiadomość do zewnętrznego systemu, muszę poczekać na zakończenie. Dopóki może to zająć dużo czasu, myślę o zatrzymaniu przetwarzania konkretnego kroku po wysłaniu wiadomości, a następnie o rozpoczęciu nowego "zadania" po otrzymaniu wiadomości o zakończeniu. Przetwarzanie dosłownie każdego kroku będzie traktowane jako trasa wielbłądów rozpoczynająca się w tej samej kolejce JMS, a następnie router oparty na treści zdecyduje, która konkretna logika powinna zostać wykonana na podstawie nagłówków wiadomości lub jej treści.

Problem polega jednak na tym, jak uniknąć potencjalnej utraty komunikatów. Na przykład w konkretnym kroku wysyłam wiadomość i kończę przetwarzanie. System zewnętrzny z jakiegoś powodu nie przetworzył wiadomości, więc mój system nie otrzymał żadnego powiadomienia. Oznacza to, że proces utknął, chyba że jakiś inny składnik wygeneruje komunikat, aby go obudzić.

Tak długo, jak system może być wyłączony w dowolnym momencie, muszę zbudować logikę, aby kontynuować przetwarzanie komunikatów po restarcie (co implikuje pewien rodzaj trwałości komunikatu, ponownego dostarczenia i strategii zarządzania transakcjami).

Wszystkie te problemy łączą się, dlatego chciałbym poprosić Camel Champions o sugestie, jak zaprojektować tego rodzaju logikę za pomocą Camela. Wiem, że dedykowany produkt BPM lub ESB może poradzić sobie z tym problemem o wiele łatwiej, ale nie chcę rozbudowywać tego rozwiązania.

Wszelkie porady są mile widziane, zwłaszcza jeśli chodzi o możliwości Camel, które mogą pomóc w uproszczeniu rozwiązania.

Odpowiedz

2

Wsparcie dla Camel w BAM powinno zapewnić część długotrwałej obsługi procesu (limity czasu, scenariusze obsługi błędów itp.). Również JMS i transactions pomoże z wiarygodnych trwałych wymagań/komunikatorów itp

Powodzenia i daj nam znać, jeśli lądujesz na alternatywnym podejściem ...

2

Proponuję roszczenie Sprawdź wzór jest najbardziej odpowiednie do utrzymywania stanu między długimi uruchomieniami wywołań zewnętrznych. Sprawdź stan swojego procesu przed wysłaniem wiadomości wychodzącej.

Jednym ze sposobów na wykrycie braku odpowiedzi z procesu zewnętrznego jest wysłanie dwóch wiadomości. Jedna wiadomość przechodzi do procesu zewnętrznego, a druga do kolejki wewnętrznej. Drugi zadzwonię do komunikatu o przekroczeniu czasu procesu. Jest to bardzo mały komunikat z tylko identyfikatorem korelacji i odpowiednim czasem wygaśnięcia. Jeśli proces zostanie odebrany z procesu zewnętrznego, proces odbiorczy będzie miał identyfikator korelacji i będzie w stanie usunąć komunikat z kolejki limitu czasu procesu. Jeśli proces zewnętrzny nie odpowiada, kolejka oczekujących oczek w kolejce limitu czasu procesu powinna być połączona z trasą wielbłądziczną, która ostrzega administratora lub podejmuje odpowiednie automatyczne działania, np. pobieranie sprawdzenia oświadczenia itp. Powinno to pozwolić na utrzymywanie stanu z minimalnym narzutem i brakiem narzędzia BPM, a zatem nie ma pojedynczego punktu awarii.

Powiązane problemy