WebSphere Message Broker, Versión 8.0.0.5 Sistemas operativos: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

Consulte la información sobre la última versión del producto en IBM Integration Bus, Versión 9.0

Manejar errores en flujos de mensajes

El intermediario 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 para que proporcionen un manejo de errores personalizado.

Por ejemplo, puede diseñar un flujo de mensajes que espere ciertos errores que desea procesar de una manera concreta. O quizá el flujo actualiza una base de datos, y debe restituir estas actualizaciones si otro proceso no se completa satisfactoriamente.

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 amplias porque en estos nodos tratan con transacciones y mensajes persistentes. El nodo MQInput también se ve afectado por las 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ás 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 más información sobre la utilización de 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.

    Puede impedir que la transacción se retrotraiga y controlar hasta qué punto se invierten los cambios de mensajes, incluyendo un nodo TryCatch en el flujo de mensajes. Si se emite una excepción más allá del terminal de intentos del nodo TryCatch, entonces se propaga una lista de excepciones al terminal de captación del nodo. El mensaje en curso vuelve al estado en el que estaba antes de que accediera al nodo TryCatch.

    Otros nodos, además del nodo TryCatch tienen 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 TryCatch estuviera conectado directamente al terminal de salida. Utilice el terminal de captación para manejar excepciones que se emiten más allá del nodo del 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:

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:

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 intermediario no realiza ninguna restitución ni ninguna acción, a menos que haya una excepción en el flujo de captación. 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 Catch del nodo de entrada, puede conectar el terminal Failure 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 flujo de anomalías también se inicia si se genera una excepción fuera del nodo MQInput (en los flujos de salida o de captación), el mensaje es transaccional y el restablecimiento del mensaje en la cola de entrada hace que el contador de restituciones alcance el umbral de restituciones.

    El nodo HTTPInput no propaga el mensaje al Nodo si se genera una excepción fuera del nodo y no se ha conectado su 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 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 intermediario proporciona el proceso predeterminado (que varía con el tipo de nodo de entrada).
  • Si necesita un método más amplio para manejar los errores y la recuperación, incluya uno o más nodos TryCatch para proporcionar más áreas específicas 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.

Para más información, consulte Conectar terminales de anomalías, Gestionar errores en el nodo de entrada y 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:

Para obtener más información sobre actualizaciones de bases de datos coordinadas, consulte Configuración de la transaccionalidad de 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 flujos de mensajes para agregación, consulte Manejar excepciones en flujos de agregación.

El siguiente ejemplo muestra cómo utilizar una rutina de manejo de errores para captar información sobre errores y para almacenar dicha información en una base de datos. La rutina de manejo de errores es un subflujo que puede añadir, sin modificar, a los flujos de mensajes. El ejemplo también muestra cómo configurar flujos de mensajes para controlar las transacciones; en particular, el uso de transacciones coordinadas globalmente para asegurar la integridad total de los datos.

Puede ver información sobre los ejemplos sólo cuando utilice el Information Center que está integrado en WebSphere Message Broker Toolkit o el Information Center en línea. Puede ejecutar ejemplos sólo cuando utilice el Information Center que está integrado en WebSphere Message Broker Toolkit.

Avisos | Marcas registradas | Descargas | Biblioteca | Soporte | Comentarios

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        Última actualización:
        
        Última actualización: 2015-02-28 16:58:15


Tema de tareaTema de tarea | Versión 8.0.0.5 | ac00410_