El nodo MQInput realiza las acciones siguientes cuando maneja errores con mensajes persistentes y de transacción. Los errores encontrados con mensajes que no son de transacción se manejan tal como se describe en el tema Gestionar errores en el nodo de entrada.
Esta acción se resume en la tabla siguiente:
Suceso de error | Terminal de anomalías conectado | Terminal de anomalías no conectado | Terminal de captación conectado | Terminal de captación no conectado |
---|---|---|---|---|
El nodo detecta un error interno | El flujo conectado al terminal de anomalías maneja el error | El mensaje se coloca en una cola alternativa; si se produce un error, el nodo vuelve a intentarlo | No aplicable | No aplicable |
El nodo propaga un mensaje al terminal de salida, la excepción se produce en el flujo de salida | No aplicable | No aplicable | El flujo conectado al terminal de captación maneja el error | El nodo vuelve a intentarlo |
El nodo propaga el mensaje al terminal de captación, se produce la excepción en el flujo conectado al terminal de captación | Error anotado, se ha restituido el mensaje | Error anotado, se ha restituido el mensaje | No aplicable | No aplicable |
El nodo propaga el mensaje al terminal de anomalías, se produce la excepción en el flujo conectado al terminal de anomalías | No aplicable | No aplicable | El nodo vuelve a intentarlo | El nodo vuelve a intentarlo |
El nodo intenta el proceso de reintento cuando se restituye un mensaje a la cola de entrada. Comprueba si el mensaje se ha restituido anteriormente y, en caso afirmativo, si el contador de restituciones ha alcanzado el número máximo de restituciones. WebSphere MQ mantiene el contador de restituciones para cada mensaje en MQMD.
Al crear la cola se especifica el atributo del número máximo de restituciones BOTHRESH (o se deja el valor por omisión 0). Si acepta el valor por omisión 0, el nodo lo aumenta a 1. El nodo también establece el valor 1 si no puede detectar el valor actual. Esto significa que si un mensaje no se ha restituido anteriormente, se restituye y se vuelve a intentar, al menos una vez.
Si se produce una anomalía externa al terminal de anomalías, se realizan reintentos adicionales hasta que el campo de número de restituciones de MQMD alcanza el doble del umbral de restituciones establecido para la cola de entrada. Cuando se alcanza este límite, el nodo intenta poner el mensaje en otra cola.
El mensaje no se puede eliminar, por lo que el flujo de mensajes sigue intentando restituir el mensaje. Registra la situación de error escribiendo errores en las anotaciones de error locales. Una segunda indicación de este error es el aumento continuo de la cuenta de restituciones del mensaje en la cola de entrada.
Si esta situación se ha producido porque no existe ninguna de las colas, puede definir una de las colas de restitución mencionadas anteriormente. Si la condición que impedía el proceso del mensaje se ha solucionado, puede aumentar temporalmente el valor del atributo BOTHRESH. Así se impulsa el mensaje a través de un proceso normal.
WebSphere MQ da soporte a los grupos de mensajes. Puede especificar que un mensaje pertenece a un grupo y, entonces, su proceso se realiza con referencia a los demás mensajes del grupo (es decir, o se confirman todos los mensajes o se restituyen todos los mensajes). Cuando envía mensajes agrupados a un intermediario, esta condición se mantiene si ha configurado el flujo de mensajes correctamente y no se producen errores durante el proceso de los mensajes en grupo.
Para configurar el flujo de mensajes para manejar los mensajes agrupados correctamente, siga las acciones que se describen en el Nodo MQInput. Sin embargo, no se puede garantizar el correcto proceso del grupo de mensajes si se produce un error mientras se procesa uno de los mensajes.
Si ha configurado el nodo MQInput tal como se describe, bajo circunstancias normales, todos los mensajes del grupo se procesan en una sola unidad de trabajo que se confirma cuando se ha procesado satisfactoriamente el último mensaje del grupo. No obstante, si se produce un error antes de que se procese el último mensaje del grupo, la unidad de trabajo que incluye los mensajes hasta el mensaje que genera el error (éste incluido) está sujeta al manejo de errores definido por las normas que aquí se documentan, lo cual puede dar como resultado la restitución de la unidad de trabajo.
Sin embargo, es posible que el flujo de mensajes lea y procese correctamente cualquiera de los demás mensajes dentro del grupo y, por tanto, se manejen y confirmen en una nueva unidad de trabajo. Se emite una confirmación cuando se encuentra y procesa el último mensaje. Por lo tanto, si se produce un error dentro de un grupo, pero no en el primer mensaje ni en el último, es posible que esa parte del grupo se restituya y que otra parte se confirme.
Si sus requisitos de proceso de mensajes exigen que esta situación se maneje de una manera específica, debe proporcionar un método adicional de manejo de errores para manejar errores dentro de grupos de mensajes.Por ejemplo, podría registrar el error del grupo de mensajes dentro de una base de datos e incluir una comprobación en la base de datos cuando recupere cada mensaje, forzando una restitución si el grupo actual ya ha encontrado un error. Así se aseguraría que todo el grupo de mensajes se restituya y que no se procese a menos que todos estén correctos.