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
espera ciertas errores que desea procesar de una forma específica, o un
flujo que actualice una base de datos y deba restituir estas
actualizaciones si otro proceso no se completa 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 amplias porque estos nodos tratan
con mensajes y transacciones persistentes. 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á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.
Puede elegir una o más de estas
opciones en los flujos de mensajes:
- Conectar el terminal de anomalías de un nodo a una secuencia de
nodos que procese la excepción interna del nodo (el flujo de anomalía).
- Conectar el terminal de captación del nodo de entrada
o un nodo TryCatch a una secuencia de nodos que
procese las excepciones que se generan fuera de ella (el flujo de
captación).
- Insertar uno o más nodos TryCatch en puntos específicos
del flujo de mensajes y procesar las excepciones que genera el flujo
conectado al terminal de intentos.
- Incluir un nodo Throw o codificar una sentencia
THROW ESQL para generar una excepción.
- Si utiliza una agregación, conectar el terminal de
captación del nodo AggregateReply para procesar las excepciones de agregación.
- Asegúrese de que todos los mensajes recibidos por un nodo MQInput se procesen en una transacción o fuera de ella.
- Asegúrese de que todos los mensajes recibidos por un nodo MQInput son persistentes o no lo son.
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 AggregateControl, AggregateRequest, Input, Label, Output,
Passthrough, Publication, Real-timeInput, Real-timeOptimizedFlow, Throw, Trace y TryCatch.
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 un terminal de anomalías, o no está conectado, el
intermediario genera una excepción y devuelve el control
al nodo anterior más cercano que pueda procesarlo. Puede ser un nodo TryCatch, 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, intenta poner el mensaje en la cola de reposición en cola para restitución
de la cola de entrada o (si ésta no está definida) en la cola de mensajes no entregados
del gestor de colas del intermediario.
Si desea ver más información, consulte lo siguiente:
- Un pequeño número de nodos incorporados tienen
terminales de captación.
Éstos son AggregateReply, HTTPInput, MQInput,
SCADAInput, JMSInput, JMSOutput, TimeoutNotification y TryCatch.
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 anomalías 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 mensaje.
- Los nodos MQInput
y TimeoutNotification realizan proceso adicional para los mensajes de
transacción (otros nodos de entrada no manejan mensajes de transacción).
Si desea ver más información, consulte los temas siguientes:
- Si incluye un nodo Trace que especifica $Root o
$Body, se analiza el mensaje entero. 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 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 de anomalías del nodo
MQInput o
HTTPInput , puede conectar el terminal de anomalías y proporcionar un
flujo de anomalías para manejar las excepciones generadas por el nodo. Cuando se produce una excepción en el nodo, se invoca inmediatamente el
flujo de anomalías.
El flujo de anomalías también se invoca 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.
Los nodos HTTPInput y SCADAInput
no propagan el mensaje al terminal de anomalías si se genera una
excepción fuera 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 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 por omisión (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.
Si desea ver más información, consulte los temas siguientes:
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 de nodo
Transaction 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 por omisión del manejo
de errores de bases de datos.
Para obtener más información sobre las
actualizaciones de bases de datos coordinadas, consulte
Configurar nodos para flujos de mensajes coordinados.
Los
flujos de mensajes para agregación requieren consideraciones adicionales
que no se tratan en esta sección y que se describen en
Manejar excepciones en flujos de agregación.
El Ejemplo Manejador de errores 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 cualquier
flujo 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.