Business Process Choreographer proporciona un recurso para manejar anomalías temporales de infraestructura.
Este apartado describe cómo el contenedor de procesos de empersa maneja los mensajes erróneos. Contrasta con el mecanismo más sencillo que utiliza el contenedor de tareas humanas, descrito en Manejo de mensajes erróneos para tareas humanas.
Los procesos de larga duración constan de una secuencia de transacciones. Las transacciones se separan mediante mensajes JMS (Java Message Service), que el servidor envía a un bean controlado por mensajes. Este bean pasa los mensajes entrantes al servidor de proceso, para su proceso. Cada transacción consta de las acciones siguientes:
Si el servidor no pudiera procesar un mensaje recibido por el bean controlado por mensajes sería por uno de los motivos siguientes:
A continuación se detallan las respuestas a estas causas:
Causa | Respuesta |
---|---|
Infraestructura no disponible | El bean controlado por mensajes intenta, durante un tiempo especificado, recuperarse de esa situación. Intenta mantener todos los mensajes disponibles hasta que el servidor esté operativo de nuevo. Este problema podría deberse a un error de la base de datos, por ejemplo. |
Mensaje dañado | Después de un número especificado de reintentos, se coloca el mensaje en la cola de almacenamiento, donde se puede manipular o revisar. Desde esta cola, también se puede volver a desplazar a la cola de entrada, para recuperar la transacción. |
La implementación de mensajes para procesos de empresa es como se detalla a continuación:
Cuando un bean controlado por mensajes opera en modalidad de inmovilización, periódicamente intenta procesar un mensaje. Los mensajes que no se pueden procesar se colocan en la cola de entrada, sin incrementar el número de entregas ni el número de veces que pasan a la cola de retención. Tan pronto como se pueda procesar satisfactoriamente un mensaje, el bean controlado por mensajes cambia de nuevo a la modalidad de proceso normal.
Este recurso consta de dos límites numéricos, dos colas, la modalidad de inmovilización y el funcionamiento de reintento de mensajes.
El límite de reintentos define el número máximo de veces que un mensaje se puede transferir a través de la cola de retención antes de colocarlo en la cola de almacenamiento.
Para colocarlo en la cola de retención, el proceso de un mensaje debe dar un error tres veces.
Por ejemplo, si el límite de reintentos es 5, un mensaje debe pasar por la cola de retención cinco veces (debe dar un error 3 * 5 = 15 veces), antes de que se inicie el último bucle de reintento. Si el último bucle de reintento falla dos veces más, el mensaje se coloca en la cola de almacenamiento. Esto significa que un mensaje debe dar un error (3 * LímiteReintentos) + 2 veces antes de que se coloque en la cola de almacenamiento.
En una aplicación muy importante para el rendimiento que se ejecute en una infraestructura fiable, el límite de reintentos debe ser pequeño, por ejemplo, uno o dos. Este parámetros se puede encontrar en la consola administrativa, en la página de configuración Contenedor de procesos de empresa.
El límite de mensajes de la cola de retención define el número máximo de mensajes que puede haber en la cola de retención. Si la cola de retención se desborda, el sistema entra en modalidad de inmovilización. Para que el sistema entre en modalidad de inmovilización tan pronto como un mensaje dé un error, establezca el valor en cero. Para que el contenedor de procesos de empresa sea más tolerante a las anomalías de infraestructura, aumente el valor.
Este parámetros se puede encontrar en la consola administrativa, en la página Contenedor de procesos de empresa. (Para localizar este parámetro, pulse Contenedor de procesos de empresa. El campo Límite de reintentos está en la cabecera Propiedades generales).
. A continuación, en la cabecera Valores de contenedor de procesos de empresa, pulseLa cola de retención retiene los mensajes con error que se repiten moviéndolos de nuevo a la cola de trabajo interna del contenedor de procesos de empresa. Si un mensaje da un error tres veces, se coloca en la cola de retención. Si el mensaje da un error (3 * LímiteReintentos) + 2 veces, se coloca en la cola de almacenamiento. (Para obtener más información sobre el límite de reintentos, consulte el apartado Límite de reintentos.) Si la cola de retención alcanza el límite definido por el límite de mensajes de la cola de retención y otro mensaje da un error, la cola se desborda y el sistema entra en modalidad de inmovilización. El administrador puede mover los mensajes de esta cola de nuevo a la cola interna llevando a cabo la tarea de consulta y repitiendo los mensajes con error.
La cola de almacenamiento contiene mensajes que han dado un error (3 * LímiteReintentos) + 2 veces. (Para obtener más información sobre el límite de reintentos, consulte el apartado Límite de reintentos.) El administrador puede mover los mensajes de esta cola de nuevo a la cola interna llevando a cabo la tarea de consulta y repitiendo los mensajes con error.
El administrador puede volver a mover los mensajes de las colas de almacenamiento o de retención a la cola interna. Esto puede realizarse mediante la consola administrativa o mediante mandatos administrativos.
Se entra en modalidad de inmovilización cuando la cola de retención se desborda. Cuando sucede esto, se presupone que existe una anomalía de infraestructura seria, aunque posiblemente temporal. La finalidad de la modalidad de inmovilización es evitar que el sistema utilice muchos recursos, mientras una anomalía de infraestructura hace que la mayor parte de mensajes dé errores igualmente. En modalidad de inmovilización, el sistema duerme durante dos segundos antes de intentar procesar el mensaje siguiente. En el momento en el que un mensaje se procesa satisfactoriamente, el sistema reanuda el proceso normal de mensajes.
(c) Copyright IBM Corporation 2005, 2006.
Este centro de información está basado en tecnología Eclipse (http://www.eclipse.org)