2011-05-29 19 views
5

Estoy trabajando en PoC para motores de procesos pequeños basados ​​en Camel. Los requisitos son tener la capacidad de ejecutar un conjunto de pasos de consecuencia y cada uno de ellos podría tardar horas en ejecutarse. El estilo de comunicación asincrónica es una opción obvia en este caso, pero me cuesta trabajo hacer que parte del "proceso" sea la correcta.Enfoque para manejar procesos de larga duración con Camel

Al enviar un mensaje al sistema externo, tengo que esperar para completarlo. Mientras pueda tomar mucho tiempo, estoy pensando en detener el procesamiento del paso concreto después de enviar el mensaje y luego comenzar un nuevo "trabajo" al recibir el mensaje de finalización. Así que, literalmente, el procesamiento de cada paso se manejará como una ruta Camel comenzando en la misma cola JMS y luego el enrutador basado en contenido decidirá qué lógica concreta se debe ejecutar en función de los encabezados del mensaje o su contenido.

El problema, sin embargo, es cómo evitar el potencial de pérdida de mensajes. Por ejemplo, en el paso concreto estoy enviando un mensaje y detengo el proceso. Por alguna razón, el sistema externo no procesó el mensaje, por lo tanto, mi sistema no recibe ninguna notificación. Esto significa que el proceso está atascado a menos que algún otro componente genere un mensaje para activarlo.

Además, siempre que el sistema se cierre en cualquier momento tengo que crear lógica para continuar procesando mensajes después del reinicio (lo que implica algún tipo de persistencia del mensaje, reenvío y estrategia de gestión de transacciones).

Todos estos temas se suman, por lo tanto, me gustaría preguntar a los campeones de Camel la experiencia para proporcionar sugerencias sobre cómo diseñar ese tipo de lógica con Camel. Sé que ese producto de BPM dedicado o ESB podría manejar este problema mucho más fácilmente, pero no quiero inflar la solución.

Se agradecen todos los consejos, especialmente en términos de capacidades de Camel que podrían ayudar a simplificar la solución.

Respuesta

2

El soporte BAM de Camel debe proporcionarle algunos de los soportes de proceso de larga duración (tiempos de espera, escenarios de manejo de errores, etc.). Además, JMS y transactions ayudará con los requisitos de mensajería fiables/persistentes, etc.

buena suerte y hacernos saber si la tierra en un enfoque alternativo ...

2

sugeriría el patrón Reclamación Check es el más apropiado para el estado persistente entre invocaciones externas de larga ejecución. Regístrese en el estado de su proceso antes de enviar el mensaje de salida.

Una forma de manejar la detección de la falta de respuesta del proceso externo es publicar dos mensajes. Un mensaje va al proceso externo, otro va a una cola interna. Llamaré al segundo el mensaje de tiempo de espera de proceso. Es un mensaje muy pequeño con solo el ID de correlación y un tiempo de vencimiento apropiado. Si el proceso se recibe del proceso externo, el proceso de recepción tendrá la identificación de correlación y podrá eliminar el mensaje de la cola de tiempo de espera de proceso. Si el proceso externo no responde, la cola de mensajes no entregados para la cola de espera de proceso debe estar conectada a una ruta en camello que alerta a un administrador o realiza la acción automática adecuada, p. recuperar la verificación de reclamo, etc. Esto debería permitir un estado persistente con un mínimo de sobrecarga y sin herramienta de BPM y, por lo tanto, no hay un solo punto de falla.

Cuestiones relacionadas