Manejo de errores MQInput

El nodo MQInput lleva a cabo acciones exclusivas cuando maneja errores con mensajes transaccionales o permanentes. (Los errores que se encuentran con mensajes no transaccionales, se manejan tal como se describe en el apartado Gestión de errores en el nodo de entrada).

Esta acción se resume en la tabla siguientes:

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 error interno El flujo de anomalías maneja el error El mensaje se transfiere a una cola alternativa. Si la transferencia da error, el nodo lo reintenta No aplicable No aplicable
El nodo propaga el mensaje al terminal de salida. Excepción en el flujo de salida No aplicable No aplicable El flujo de captación maneja el error Reintento del nodo
El nodo propaga el mensaje al terminal de captación. Excepción en el flujo de captación Anotación del error, restitución del mensaje Anotación del error, restitución del mensaje No aplicable No aplicable
El nodo propaga el mensaje al terminal de anomalías. Excepción en el flujo de anomalías No aplicable No aplicable Reintento del nodo Reintento del nodo

Proceso de reintento

El nodo intenta el proceso de reintento cuando un mensaje se restituye en la cola de entrada. Comprueba si el mensaje se ha restituido previamente y, en caso de que sea así, si la cuenta de restituciones ha alcanzado (igualado) el umbral de restitución. WebSphere MQ mantiene la cuenta de restituciones para cada mensaje en el MQMD.

Debe especificar (o permitir el valor por omisión de 0) del atributo del umbral de restitución BOTHRESH cuando crea la cola. Si acepta el valor por omisión de 0, el nodo lo aumenta a 1. El nodo también establece el valor en 1 si no puede detectar el valor actual, lo que significa que si un mensaje no se ha restituido previamente, como mínimo, se restituye y reintenta una vez.

  1. Si el nodo ha propagado varias veces un mensaje al terminal de salida tras repetidos intentos anómalos al flujo de salida y el número de reintentos ha alcanzado el límite del umbral de restitución, intenta propagar el mensaje a través del terminal de anomalías, si se ha conectado. Si el terminal de anomalías no se ha conectado, el nodo intenta transferir el mensaje a otra cola, tal como se describe en el apartado 3.

    Si la anomalía se produce fuera del terminal de anomalías, se realizan otros reintentos hasta que el campo de cuenta de restituciones de MQMD alcanza dos veces el umbral de restitución establecido para la cola de entrada. Cuando se alcanza este límite, el nodo intenta transferir el mensaje a otra cola, tal como se describe en el paso 3.

  2. Si no se ha alcanzado el umbral de restitución, el nodo vuelve a obtener el mensaje de la cola. Si se produce un error, se maneja como un error interno (tal como se ha descrito más arriba). Si se ejecuta correctamente, el nodo propaga el mensaje al flujo de salida.
  3. Si se ha alcanzado el umbral de restitución:
    • Si se ha conectado el terminal de anomalías, el nodo propaga el mensaje a dicho terminal. El usuario debe manejar el error del flujo de anomalías.
    • Si no se ha conectado el terminal de anomalías, el nodo intenta transferir el mensaje a una cola disponible, por orden de preferencia:
      1. El mensaje se transfiere al nombre de reposición en cola para restitución de la cola de entrada (atributo de cola BOQNAME), si se ha definido una.
      2. Si no se ha definido la cola de restitución o si el nodo no la puede identificar, el mensaje se transfiere a la cola de mensajes no entregados (DLQ), si se ha definido una. (Si se ha definido el gestor de colas del intermediario con el mandato mqsicreatebroker, se ha definido una DLQ con un nombre por omisión de SYSTEM.DEAD.LETTER.QUEUE y está habilitada para este gestor de colas).
      3. Si el mensaje no se puede transferir a ninguna de estas colas debido a que existe un error MQPUT (además de incluir que la cola no existe) o a causa de que el nodo no la puede identificar, no se puede manejar de modo seguro sin riesgo de pérdida.

        El mensaje no se puede descartar y, por consiguiente, el flujo de mensajes sigue intentando restituirlo. Registra la situación del error escribiendo errores en las anotaciones de error locales. Una segunda indicación de este error es el continuo incremento de la CtaRestituciones del mensaje en la cola de entrada.

        Si esta situación se produce debido a que no existe ninguna cola, puede definir una de las colas de restitución que se han mencionado más arriba. Si se borra la condición que impide el proceso del mensaje, puede aumentar temporalmente el valor del atributo BOTHRESH. De este modo se fuerza el proceso normal del mensaje.

  4. Si se ha alcanzado o excedido dos veces el umbral de restitución, el nodo intenta transferir el mensaje a una cola disponible, por orden de preferencia, tal como se describe en el paso 3.

Manejo de errores de grupos de mensajes

WebSphere MQ ofrece soporte para grupos de mensajes. Puede especificar que un mensaje pertenece a un grupo y que su proceso se lleve a cabo en relación a los demás mensajes del grupo (es decir, que se confirmen todos los mensajes o que se restituyan todos los mensajes). Cuando envía mensajes agrupados a un intermediario, esta condición se mantiene si el flujo de mensajes se ha configurado correctamente y no se producen errores durante el proceso de mensajes del grupo.

Para configurar el flujo de mensajes de modo que se manejen mensajes agrupados correctamente, siga las acciones que se describen en el apartado Nodo MQInput. Sin embargo, el proceso correcto del grupo de mensajes no se puede garantizar en caso de que se produzcan errores mientras se está procesando uno de los mensajes.

Si ha configurado el nodo MQInput descrito, bajo circunstancias normales todos los mensajes del grupo se procesan en una única unidad de trabajo que se confirma una vez que se ha procesado correctamente el último mensaje del grupo. Sin embargo, si se produce un error antes de que se procese el último mensaje del grupo, la unidad de trabajo en la que se incluyen los mensajes, hasta e incluido el mensaje que genera el error, está sujeta al manejo de errores que definen las normas que se documentan aquí. El resultado puede ser la restitución de la unidad de trabajo.

No obstante, el flujo de mensajes puede leer y procesar cualquiera de los mensajes restantes del grupo y, por consiguiente, se manejan y confirman en una nueva unidad de trabajo. Se emite una confirmación cuando se encuentra y procesa el último mensaje. Por consiguiente, si se produce un error dentro de un grupo, pero no en el primero o en el último mensaje, es posible que una parte del grupo se restituya y que otra se confirme.

Si sus requisitos de proceso de mensajes necesitan que esta situación se maneje de un modo determinado, debe facilitar el manejo de errores para manejar errores dentro de grupos de mensajes. Por ejemplo, puede anotar la anomalía del grupo de mensajes en 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. De este modo se garantiza que se restituya y no se procese el grupo de mensajes completo a menos que todos sean satisfactorios.

Conceptos relacionados
Flujos de mensajes

Tareas relacionadas
Manejo de errores en flujos de mensajes
Gestión de errores en el nodo de entrada
Captación de excepciones en un nodo TryCatch
Utilización de subflujos
Creación de un flujo de mensajes
Definición del contenido del flujo de mensajes

Referencia relacionada
Nodos incorporados
Nodo MQInput
WebSphere MQ Enterprise Transport