Manejar errores en flujos de mensajes

El nodo de integración proporciona un manejo básico de errores para todos los flujos de mensajes. Si el proceso básico no es suficiente y desea realizar acciones específicas en respuesta a ciertas condiciones y situaciones de error, puede mejorar sus flujos de mensajes utilizando terminales de nodo de flujo de mensajes para que proporcionen un manejo de errores personalizado.

Acerca de esta tarea

Por ejemplo, puede diseñar un flujo de mensajes que espere ciertos errores que desea procesar de una manera concreta. Otro ejemplo es que su flujo de mensajes actualiza una base de datos y que debe retrotraer estas actualizaciones si no hay otro proceso de mensajes que finalice correctamente.

Las opciones que puede utilizar para esto pueden llegar a ser muy complejas. Las opciones que se proporcionan para los nodos MQInput y TimeoutNotification son extensas porque estos nodos tratan con mensajes y transacciones persistentes. El nodo MQInput también se ve afectado por las opciones de configuración para WebSphere® MQ.

Puesto que puede decidir manejar distintos errores de distintas maneras, no hay procedimientos fijos para describir. Esta sección proporciona información sobre los principios del manejo de errores y las opciones que están disponibles, y usted debe decidir la combinación de opciones que necesita en cada situación, basándose en la información que se proporciona en esta sección.

Hay dos enfoques generales para manejar errores en un flujo de mensajes:
  • Comprobar errores

    Conecte el terminal de anomalías de un nodo para comprobar explícitamente si hay errores que se producen dentro de dicho nodo. Si se producen errores, se propaga una lista de excepciones al terminal de anomalías. El mensaje en curso permanece tal como estaba antes de que es invocara el nodo.

    Puede introducir comprobaciones de errores más especializadas en nodos que se pueden personalizar utilizando ESQL. Por ejemplo, puede crear manejadores de salida dentro de estos nodos. Para obtener más información sobre cómo utilizar ESQL para crear manejadores de salida, consulte Sentencia DECLARE HANDLER.

  • Captar excepciones

    Si no conecta un terminal de anomalías, un error en el nodo se convierte en una excepción que se emite desde el nodo. Los cambios que se realizaron en el mensaje en curso antes de que se emitiera la excepción se invierten. La excepción podría hacer que la transacción actual se retrotrayera, lo que significa que las actualizaciones en los recursos transaccionales se invierten. Los árboles raíz y de entorno local se retrotraen en paralelo. El árbol del entorno no se retrotrae a menos que se retrotraiga toda la transacción para el flujo.

    Puede impedir que se retrotraiga la transacción y controlar el grado en que se invierten los cambios de mensajes, incluyendo un nodo TryCaptura en el flujo de mensajes. Si se genera una excepción más allá del terminal Try del nodo TryCaptura , se propaga una lista de excepciones al terminal de captación del nodo. El mensaje de inflight vuelve al estado en el que estaba antes de que llegara al nodo de TryCaptura .

    La mayoría de nodos de flujo de mensajes disponen de un terminal de captación. Estos nodos suelen estar al principio de una transacción, en la que una excepción no detectada causaría una retrotracción. En estos nodos, el terminal de captación se comporta como si un nodo TryCaptura estuviera conectado directamente al terminal de salida. Utilice el terminal de captación para gestionar las excepciones emitidas más allá del nodo de flujo de mensajes. Conecte el terminal de anomalías para manejar errores dentro del propio nodo.

Puede elegir una o más de estas opciones en los flujos de mensajes:

  • Conectar el terminal de anomalías del nodo a una secuencia de nodos que procesa la excepción interna del nodo (el flujo de anomalía).
  • Conectar al terminal de captación del nodo a una secuencia de nodos que procese excepciones generadas fuera de ella (el flujo de captación).
  • Inserte uno o más nodos TryCaptura en puntos específicos del flujo de mensajes para capturar y procesar excepciones generadas por el flujo conectado al terminal de prueba.
  • Incluya un nodo Throw o codifique una sentencia ESQL THROW para generar una excepción.
  • Asegúrese de que todos los mensajes recibidos por un nodo MQInput se procesan en una transacción o no se procesan en una transacción.
  • Asegúrese de que todos los mensajes recibidos por un nodo MQInput son persistentes o no son persistentes.

Si incluye nodos definidos por usuario en el flujo de mensajes, debe consultar la información proporcionada con el nodo para comprender cómo puede manejar los errores con estos nodos. Las descripciones en esta sección solamente abarcan los nodos incorporados.

Cuando diseñe el método de manejo de errores, tenga presente los siguientes factores:

  • La mayoría de nodos incorporados tienen terminales de anomalías. Las excepciones son los nodos AggregateControl, AggregateRequest, Entrada, Etiqueta, Salida, Passat, Publicación, Rastreoy TryCaptura .

    Cuando se detecta una excepción dentro de un nodo, el mensaje y la información sobre la excepción se propagan al terminal de anomalías del nodo. Si el nodo no tiene una terminal de Anomalías, o no está conectado, el nodo de integración emite una excepción y devuelve el control al nodo en sentido ascendente más cercano que pueda procesarlo. Este nodo puede ser un nodo TryCaptura , un nodo AggregateReply o el nodo de entrada.

    Si un nodo MQInput detecta un error interno, su comportamiento es ligeramente diferente. Si el terminal de anomalías no está conectado, el nodo de MQInput intenta colocar el mensaje en la cola de restitución de la cola de entrada, o si no se ha definido, en la cola de mensajes no entregados del gestor de colas asociado al nodo de integración.

    Para obtener más información, consulte Manejo de errores de nodo MQInput.

  • Muchos nodos incorporados tienen terminales de captación (catch). Estos nodos suelen estar al principio de una transacción. Por ejemplo:
    • Nodos de entrada: FileInput, HTTPInput, JMSInput, MQInput, PeopleSoftInput, SAPInput, SCAInput, SiebelInput, SOAPInput, TCPIPClientInput, TCPIPServerInput
    • Nodos de salida y respuesta: SCAAsyncResponse, SOAPAsyncResponse
    • Nodos de direccionamiento: AggregateReply, Colector, Resequence
    • Nodos de construcción: TryCaptura
    • Nodos de temporizador: TimeoutNotification

    Un mensaje se propaga a un terminal de captación sólo si se ha propagado fuera del nodo anteriormente (por ejemplo, a los nodos conectados al terminal de salida).

  • Cuando se propaga un mensaje a un terminal de Fallo o de Captación, el nodo crea una nueva lista de excepciones y la rellena con una excepción que representa el error que se ha producido. La lista de excepciones se propaga como parte del árbol de mensajes. Cuando se propaga un mensaje al terminal de anomalías debido a un problema que se ha producido en los flujos de captación y salida (por ejemplo, errores repetidos de análisis que han provocado que se alcance el umbral de restituciones), los errores de análisis originales no se encuentran en la lista de excepciones; la lista de excepciones contiene la excepción que indica que se ha alcanzado el umbral de restituciones.
  • Los nodos MQInput y TimeoutNotification tienen proceso adicional para mensajes transaccionales (otros nodos de entrada no manejan mensajes transaccionales).

    Para obtener más información, consulte Manejo de errores de nodo MQInput y Cómo manejar los errores de notificación.

  • Si incluye un nodo Rastreo que especifica$Rooto bien$Body, se analiza el mensaje completo. Esto puede generar errores de analizador que, de otra forma, no se detectan.
Los principios generales del manejo de errores son:
  • Si conecta el terminal de captación del nodo de entrada, está indicando que el flujo maneja todas las excepciones que se generan en cualquier sitio del flujo de salida. El nodo de integración no retrotrae una transacción a menos que haya una excepción en el flujo de captación. Si el flujo de captación finaliza correctamente, se confirma el mensaje. Si desea alguna acción de restitución después de que se haya generado y detectado una excepción, debe proporcionarla en el flujo de captación.
  • Si no conecta el terminal de Captación del nodo de entrada, puede conectar el terminal de Fallo y proporcionar un flujo de anomalías para manejar las excepciones generadas por el nodo. Cuando se produce una excepción en el nodo, el flujo de anomalías se inicia inmediatamente.

    El nodo HTTPInput no propaga el mensaje al terminal de anomalías si se genera una excepción más allá del nodo y no ha conectado el terminal de captación.

  • Si un nodo propaga un mensaje a un flujo de captación y se produce otra excepción que devuelve el control al mismo nodo de flujo de mensajes de nuevo, el nodo maneja el mensaje como si el terminal de captación no estuviera conectado.
  • Si no conecta terminales de anomalías o de captación del nodo de entrada, el nodo de integración proporciona el proceso predeterminado (que varía con el tipo de nodo de entrada).
  • Si necesita un enfoque de recuperación y error más completo, incluya uno o más nodos TryCaptura para proporcionar más áreas localizadas de manejo de errores.
  • Si tiene un procedimiento común para manejar errores específicos, quizá sea conveniente crear un subflujo que incluya la secuencia de nodos necesaria. Incluya este subflujo cuando necesite que se lleve a cabo esa acción.
  • Si ha establecido el proceso de seguridad en un nodo de entrada y se ha emitido una excepción de seguridad, el mensaje no se propagará al flujo de mensajes. El mensaje se restituye o se devuelve un error. Para obtener más información, consulte Proceso de excepciones de seguridad.
  • Las excepciones de análisis pasan directamente al terminal de anomalías. Si el terminal de anomalías no está conectado o si se produce una excepción en el flujo de anomalías, se restituirá el mensaje. Las restituciones en el flujo de anomalías continúan hasta que se supere una vez el umbral de restitución y no dos como ocurría anteriormente.

Para obtener más información, consulte Conexión de terminales de anomalíay Captura de excepciones en un nodo TryCatch.

Si los flujos de mensajes incluyen actualizaciones de bases de datos, la forma en que configura los nodos que interactúan con estas bases de datos también puede afectar la forma en que se manejan los errores:

  • Puede especificar si las actualizaciones se confirman o se restituyen. Puede establecer la propiedad del nodo Transacción para especificar si las actualizaciones de bases de datos se confirman o se restituyen con el flujo de mensajes (opción Automática) o se confirman o se restituyen cuando el nodo finaliza (opción Confirmar). Debe asegurarse de que la combinación de los valores de estas propiedades y el proceso de error del flujo de mensajes ofrece el resultado correcto.
  • Puede especificar cómo se manejan los errores de base de datos. Puede establecer las propiedades Tratar los avisos como errores y Generar excepción en error de la base de datos para cambiar el comportamiento predeterminado del manejo de errores de bases de datos.

Para obtener más información sobre las actualizaciones coordinadas de la base de datos, consulte Configuración de transaccionalidad para flujos de mensajes.

Los flujos de mensajes para agregación requieren factores adicionales que no se tratan en esta sección. Para obtener información sobre los flujos de mensajes para la agregación, consulte Manejo de excepciones en flujos de agregación.