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 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.
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 excepciones generadas fuera de ella (el flujo de captación).
- Insertar uno o más nodos TryCatch
en puntos específicos del flujo de mensajes para captar y procesar las excepciones generadas por el flujo conectado al terminal de intentos.
- Incluir un nodo Throw o
codificar una secuencia
THROW de origen/destinatario ESQL para generar una excepción.
- Si se utiliza una agregación, conectar el terminal de captación del nodo AggregateReply para procesar las excepciones de agregación.
- Asegurarse de que todos los mensajes recibidos por un nodo MQInput se procesen en
una
transacción o fuera de ella.
- Asegurarse 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
los nodos 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.
Para obtener más información, consulte
Manejar errores de MQInput.
- Un`pequeño número de nodos incorporados tienen
terminales de captación. Son los nodos 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.
- El nodo MQInput y
TimeoutNotification tienen procesos
adicionales para los mensajes de transacción (otros nodos de entrada no manejan mensajes
de transacción).
Para obtener más información, consulte Manejar errores de MQInput y
Manejo de errores de TimeoutNotification.
- 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 captación 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, 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.
Los nodos HTTPInput y
SCADAInput no propagan el mensajes al terminal de anomalías si se genera una excepción fuera del nodo y no se 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 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:
- Puede especificar si las actualizaciones se confirman o se restituyen. Puede
establecer la propiedad del 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 predeterminado del manejo
de errores de bases de datos.
Para obtener más información sobre actualizaciones de bases de
datos coordinadas, consulte
Configurar flujos de mensajes coordinados globalmente.
Los flujos de mensajes para agregación requieren consideraciones
adicionales que no se tratan en esta sección. Para obtener información sobre flujos de mensajes para agregación,
consulte el apartado 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 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.
Los ejemplos sólo pueden verse cuando se utiliza el
centro de información que está integrado en el Kit de herramientas de Message
Brokers.