Approccio per gestire i processi a vita lunga con Camel

Question

Sto lavorando su PoC per il piccolo motore di processo basato su Camel. I requisiti devono avere la capacità di eseguire serie di passaggi delle conseguenze e ognuno di essi potrebbe richiedere ore per essere eseguito. In questo caso, lo stile di comunicazione asincrona è una scelta ovvia, ma sono in difficoltà con la parte "processo" giusta.

Quando si invia un messaggio a un sistema esterno, è necessario attendere il completamento. Finché potrebbe richiedere molto tempo, sto pensando di interrompere l'elaborazione del passaggio concreto dopo che ho inviato un messaggio e poi di iniziare un nuovo "lavoro" dopo aver ricevuto il messaggio di completamento. Quindi, l'elaborazione letterale di ogni passaggio verrà gestita come una rotta Camel a partire dalla stessa coda JMS e quindi il router basato sul contenuto deciderà quale logica concreta dovrebbe essere eseguita in base alle intestazioni del messaggio o al suo contenuto.

Il problema, tuttavia, è come evitare potenziali perdite di messaggi. Ad esempio, nella fase concreta invierò un messaggio e interromperò l'elaborazione. Il sistema esterno per qualche motivo non ha elaborato il messaggio, pertanto il mio sistema non riceve alcuna notifica. Ciò significa che il processo è bloccato a meno che qualche altro componente generi un messaggio per riattivarlo.

Purché il sistema possa essere arrestato in qualsiasi momento, devo sviluppare la logica per continuare a elaborare i messaggi dopo il riavvio (che implica una sorta di persistenza dei messaggi, di riconsegna e strategia di gestione delle transazioni).

Tutti questi numeri si sommano quindi mi piacerebbe chiedere ai campioni Camel esperienza di fornire suggerimenti su come progettare questo tipo di logica usando Camel. So che il prodotto BPM dedicato o ESB potrebbe gestire questo problema molto più facilmente ma non voglio ingigantire la soluzione.

Qualsiasi consiglio è ben accetto, soprattutto in termini di funzionalità Camel che potrebbero aiutare nella semplificazione della soluzione.

Answer 1

Il supporto di Camel's BAM dovrebbe fornire alcuni dei longevi supporto del processo (timeout, scenari di gestione degli errori, ecc.). Inoltre, JMS e transactions aiuterà con i requisiti di messaggistica affidabile/persistenti, ecc

buona fortuna e farci sapere se si terra su un approccio alternativo ...

Answer 2

vorrei suggerire la rivendicazione Controllare modello è il più appropriato per lo stato persistente tra invocazioni esterne di lunga durata. Verificare lo stato del processo prima di inviare il messaggio in uscita.

Un modo per gestire il rilevamento della mancata risposta dal processo esterno consiste nel pubblicare due messaggi. Un messaggio va al processo esterno, un altro va a una coda interna. Chiamerò il secondo messaggio di timeout del processo. È un messaggio molto piccolo con solo l'ID di correlazione e un tempo di scadenza appropriato. Se il processo viene ricevuto dal processo esterno, il processo di ricezione avrà l'id di correlazione e sarà in grado di rimuovere il messaggio dalla coda di timeout del processo. Se il processo esterno non risponde, la coda di messaggi non recapitati per la coda di timeout del processo deve essere connessa a una route cammello che avvisa un amministratore o prende l'azione automatica appropriata, ad es. recupero del controllo dei reclami, ecc. Questo dovrebbe consentire lo stato persistente con un minimo di overhead e nessun tool BPM e quindi nessun singolo punto di errore.