Acerca del ejemplo del Manejador de errores
El ejemplo del Manejador de errores se basa en un
escenario en el que un negocio implicado en el proceso de transacciones
desea desarrollar una rutina para gestionar errores. El ejemplo muestra cómo utilizar algunas de las características
proporcionadas con WebSphere Message Broker.
Algunas empresas, como los bancos, desean asegurarse de que las
transacciones se procesan sólo una vez y que hay un registro de errores. En
el ejemplo del Manejador de errores, los mensajes sobre números de empleado
pasan a través de un flujo de mensajes que actualiza una base de datos con
esta información. Al poner un mensaje con un número de personal no válido, se puede observar cómo funciona la rutina de
gestión de errores.
El ejemplo del Manejador de errores muestra las siguientes tareas:
- Cómo utilizar una rutina de gestión de errores para recopilar
información sobre los errores y almacenar la información en una base de
datos. La rutina del manejador de errores que se utiliza en el ejemplo es un subflujo que se puede añadir, sin modificar,
a cualquier flujo de mensajes.
- Cómo configurar flujos de mensajes para controlar la transaccionalidad. En
particular, el ejemplo muestra el uso de transacciones coordinadas
globalmente para asegurar la integridad general de los datos. En z/OS, esta es la modalidad de funcionamiento por omisión. En
plataformas distribuidas, la coordinación global requiere pasos de
configuración específicos y se implementa utilizando los protocolos XA. En este ejemplo, el flujo de mensajes principal del ejemplo actualiza
una base de datos DB2 con información sobre los números de personal. El subflujo de gestión de errores actualiza otra base de datos
DB2 con información sobre los errores que se han producido al procesar el
número de personal. La actualización de base de datos en el flujo principal está bajo
control transaccional, de forma que si se produce un error y el mensaje lo
procesa el subflujo de gestión de errores, la actualización de base de
datos sobre el número de personal se restituye y no se confirma. La actualización de base de datos en el subflujo del
manejador de errores está fuera del control transaccional para asegurar que
la información sobre errores no se restituya, ya que la información debe
confirmarse para proporcionar un registro de errores.
Los mensajes
Se facilitan dos mensajes de entrada para ejecutar el ejemplo de Manejador de errores: un mensaje que contiene
un número de serie válido de personal y un mensaje que contiene un número de serie no válido de personal.
El mensaje de personal válido se proporciona en XML, de la manera siguiente:
<Staff>
<StaffNumber>1</StaffNumber>
<NameInfo>
<LastName>Smith</LastName>
<FirstName>Jack</FirstName>
</NameInfo>
</Staff>
El mensaje de personal no válido se proporciona en XML, de la manera siguiente:
<Staff>
<StaffNumber>99</StaffNumber>
<NameInfo>
<LastName>Doe</LastName>
<FirstName>Jane</FirstName>
</NameInfo>
</Staff>
Los flujos de mensajes
La siguiente figura muestra el flujo de mensajes principal (main).

La figura siguiente muestra el subflujo de manejo de errores.
La siguiente tabla lista los tipos de nodos que se usan en el ejemplo de Manejador de errores. El nodo Subflow
no es técnicamente un nodo y no está disponible en la paleta de nodos; el nodo Subflow representa únicamente de dónde se llama al subflujo, Error_Handler.msgflow, dentro
del flujo de mensajes principal.
Tipo de nodo |
Nombre de nodo |
MQInput |
STAFF_IN |
MQOutput |
STAFF_FAIL; STAFF_OUT |
Database |
Update Staff Database; Update Error Database |
Filter |
Check Valid Staff Number; Check Backout Count |
Throw |
Throw; Throw to Complete Rollback |
TryCatch |
TryCatch |
Subflow |
Error_Handler |
Si desea ver más información, lea lo referente a los nodos en los flujos de mensajes del ejemplo de Manejador de errores en la documentación de
WebSphere Message Broker.
Ruta seguida por el mensaje válido de personal
Cuando pone el mensaje de personal válido en la cola de entrada, el
mensaje se desplaza a través de los nodos, tal como se describe a
continuación. Si se ha inhabilitado alguna de las colas, el mensaje no
podrá seguir esta ruta.
En el flujo de mensajes principal:
- STAFF_IN. El nodo obtiene el mensaje de entrada de la cola de entrada.
- Error_Handler. Este nodo representa el subflujo de gestión de errores. Ahora el mensaje deja el flujo de
mensajes principal y entra en el subflujo.
En el subflujo:
- Start Subflow. El mensaje se pasa al nodo siguiente en el flujo.
- Check Backout Count. El nodo
comprueba si el contador de restituciones es cero. Puesto que es la primera vez que el mensaje de
entrada pasa por este nodo, actualmente el contador es cero y el mensaje
se pasa al nodo siguiente. Si el contador fuera mayor que cero, el mensaje se elimina.
- TryCatch. Ya que el número de personal es válido, el mensaje
se pasa al nodo Back To Main Flow. Si el número de personal en el mensaje
no es válido y el proceso del mensaje ha llegado a un punto en el que esto se
ha descubierto, el mensaje se pasa al nodo Update Error Database.
- Back To Main Flow. En este punto, el mensaje deja el subflujo y
vuelve al flujo de mensajes principal.
En el flujo de mensajes principal:
- Check Valid Staff Number. Ya que el número de personal es válido, el mensaje se pasa al nodo Update Staff
Database.
- Update Staff Database. La base de datos STAFFDB se actualiza con los detalles de personal que hay en el mensaje.
- STAFF_OUT. El nodo pone el mensaje en la cola STAFF_OUT.
Ruta seguida por el mensaje no válido de personal
Cuando pone el mensaje de personal no válido en la cola de entrada, el
mensaje se desplaza a través de los nodos, tal como se describe a
continuación. Si se ha inhabilitado alguna de las colas, el mensaje no
podrá seguir esta ruta. Para obtener más información sobre lo que hace cada nodo, pulse en los nodos de las figuras, en
el tema principal.
En el flujo de mensajes principal:
- STAFF_IN. El nodo obtiene el mensaje de entrada de la cola de entrada.
- Error_Handler. Este nodo representa el subflujo de gestión de errores. Ahora el mensaje deja el flujo de
mensajes principal y entra en el subflujo.
En el subflujo:
- Start Subflow. El mensaje se pasa al nodo siguiente en el flujo.
- Check Backout Count. El nodo
comprueba si el contador de restituciones es cero. Puesto que es la primera vez que el mensaje de
entrada pasa por este nodo, actualmente el contador es cero y el mensaje
se pasa al nodo siguiente. Compare con el paso 13, más abajo.
- TryCatch. El número de personal en el mensaje no es válido, pero
esto todavía no se ha descubierto. Como resultado, el mensaje de entrada
se pasa al nodo Back To Main Flow, en lugar de al nodo
Update Error Database.
- Back To Main Flow. En este punto, el mensaje deja el subflujo y
vuelve al flujo de mensajes principal.
En el flujo de mensajes principal:
- Check Valid Staff Number. Puesto que el número de personal no es
válido, el mensaje se pasa al nodo Throw Exception, en lugar de al
nodo Update Staff Database.
- Throw Exception. El nodo detiene el proceso del mensaje y añade el
número de error "3001" y el texto "Invalid staff
number" al contenido del mensaje. Ahora se 'restituye' el mensaje. Es decir, el mensaje se propaga de vuelta al
punto de control que, en este caso, es el nodo TryCatch en el subflujo.
En el subflujo:
- TryCatch. El nodo reconoce que se ha producido una excepción en el
proceso del mensaje y lo pasa al nodo Update Error Database.
- Update Error Database. La base de datos ERRORDB se actualiza con los
detalles del error, tal como se ha definido en el nodo Throw
exception (paso 8).
- Throw To Complete Rollback. El nodo detiene el proceso del mensaje y añade el
número "3002" y el texto "From Error_Handler
message flow. See ERRORDB for details" al contenido del mensaje. A
continuación, el mensaje se propaga de vuelta al punto de
control, que es el nodo STAFF_IN en el flujo de mensajes principal.
Esta es la fase final del proceso de captación. Tiene el efecto de
restituir toda la transacción, incluidas las actualizaciones de base de
datos bajo control transaccional (es decir, la actualización
STAFFDB en el flujo principal) en la ruta de intento original. Sin embargo, la actualización ERRORDB, que está fuera del control
transaccional, sigue confirmada.
En el flujo de mensajes principal:
- STAFF_IN. Puesto que se ha producido una excepción en el proceso del mensaje, éste se pasa al nodo STAFF_FAIL en
lugar de pasarlo a través del flujo de mensajes de nuevo.
- STAFF_FAIL. El nodo pone el mensaje en la cola STAFF_FAIL. De
forma alternativa, si la cola STAFF_FAIL está inhabilitada, el mensaje no
se detiene aquí. Se pasa de nuevo al nodo STAFF_IN y, a continuación, al subflujo. A
continuación, el mensaje llega al nodo Check Backout Count. El nodo
comprueba si el contador de restituciones es cero. Puesto que el mensaje
ha pasado a través de este nodo anteriormente, el contador de
restituciones ya no es cero y el mensaje se elimina. Al eliminar el
mensaje se evita que se produzca una situación en la que, si la cola
STAFF_FAIL está inhabilitada, el mensaje sigue desplazándose por el flujo
una y otra vez. Compare con el paso 4, más arriba.
Cuando utiliza un nodo TryCatch o cuando adjunta nodos al terminal de captación de un nodo MQInput, puede suponer
que cualquier proceso que se haya producido en la ruta de prueba, si los nodos están configurados correctamente, no se
confirmarán si se llama a la ruta de captación. Sin embargo, éste no es el caso. Por ejemplo, si se actualiza una base de
datos en la ruta de prueba bajo control transaccional, y se llama a la ruta de
captación y ésta se completa normalmente, la actualización de base de
datos seguirá confirmada.
El requisito en este ejemplo es leer un mensaje, actualizar una base de
datos y escribir el mensaje en otra cola. Si se produce un error, se restituye la actualización de la base de datos. El proceso de
captación actualiza la base de datos de errores con los detalles del error
y graba el mensaje original en la cola de anomalías. En términos de
programación, esto es lo que sucede:
BEGIN (Start 'outer' unit-of-work.)
MQGET (Get message from the input queue.)
TRY
BEGIN (Start 'inner' unit-of-work.)
Update database
MQPUT (Put message onto the output queue.)
IF ERROR
ROLLBACK inner unit-of-work GO TO CATCH
ELSE
COMMIT inner and outer unit-of-work as one unit-of-work
END IF
CATCH
Update error database
MQPUT (Put message onto the failure queue.)
COMMIT unidad de trabajo externa
Sin embargo, el gestor de transacciones XA y WebSphere MQ no dan
soporte a dos niveles de unidades de trabajo en la misma aplicación. A consecuencia de esto, el ejemplo de manejador de
errores utiliza las siguientes estructuras:
- La actualización de la base de datos en la ruta de prueba está
dentro del control transaccional. En el ejemplo, es la actualización STAFFDB.
- La actualización de la base de datos en la ruta de captación está
fuera del control transaccional. Es la base de datos ERRORDB.
- El terminal Failure del nodo MQInput está conectado a un nodo MQOutput, que apunta a una cola de anomalías.
- La fase final del proceso de captación es generar un error de nuevo, utilizando un nodo Throw.
- A continuación, el mensaje se restituye a través de la ruta de anomalías al nodo MQInput y, de allí, a la cola
de anomalías.
Hay dos bases de datos en este ejemplo, en lugar de sólo una, porque
en WebSphere MQ no se puede utilizar la misma conexión de base de datos
para las transacciones coordinadas y las no coordinadas, en el mismo flujo
de mensajes. En el ejemplo del Manejador de errores, la actualización de base
de datos en el flujo de mensajes principal está bajo control transaccional,
de forma que si se produce un error, la actualización se restituye y no se
confirma. La actualización de base de datos en el subflujo no está bajo
control transaccional, de forma que la actualización siempre se confirma. Como resultado, el ejemplo del Manejador de errores requiere dos bases de datos aparte.
Si desea ver más información, lea lo referente a
la
coordinación de transacciones en flujos de mensajes en la documentación de WebSphere Message Broker.
Volver a la Página de presentación de ejemplos