Manejar errores de MQInput

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

Proceso de reintento

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.

  1. Si el nodo ha propagado muchas veces un mensaje al terminal de salida después de repetidos intentos fallidos en el flujo de salida, y el número de reintentos ha alcanzado el límite de umbral de restituciones, intenta propagar el mensaje a través del terminal de anomalías, si está conectado. Si no ha conectado el terminal de anomalías, el nodo intentará poner el mensaje en otra cola.

    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.

  2. Si no se ha alcanzado el número máximo de reintentos, el nodo obtiene de nuevo el mensaje de la cola. Si falla, se maneja como un error interno (descrito anteriormente). Si se ejecuta correctamente, el nodo propaga el mensaje al flujo de salida.
  3. Si se alcanza el número máximo de restituciones:
    • Si ha conectado el terminal de anomalías, el nodo propaga el mensaje a dicho terminal. Debe manejar el error en el flujo conectado al terminal de anomalías.
    • Si no ha conectado el terminal de anomalías, el nodo intenta poner el mensaje en una cola disponible, en orden de preferencia:
      1. El mensaje se coloca en el nombre de reposición en cola para restitución de la cola de entrada (atributo de cola BOQNAME), si hay uno definido.
      2. Si la cola de restitución no está definida o el nodo no la puede identificar, el mensaje se coloca en la cola de mensajes no entregados (DLQ), si hay una definida. (Si el gestor de colas del intermediario se ha definido mediante el mandato mqsicreatebroker, se ha definido una DLQ con el nombre por omisión SYSTEM.DEAD.LETTER.QUEUE y se ha habilitado para este gestor de colas.)
      3. Si el mensaje no se puede colocar en ninguna de estas colas porque hay un error MQPUT (incluido que las colas no existan) o porque el nodo no las puede identificar, no se podrá manejar de forma segura sin riesgos de pérdidas.

        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.

  4. Si se ha alcanzado o sobrepasado el doble del umbral de restituciones, el nodo intenta poner el mensaje en una cola disponible, en orden de preferencia, como se ha definido en el paso anterior.

Manejo de errores de grupos de mensajes

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.

Avisos | Marcas registradas | Descargas | Biblioteca | Soporte | Su opinión
Copyright IBM Corporation 1999, 2006 Última actualización: 22/08/2006
ac00414_