Acerca del ejemplo Manejador de errores
El ejemplo Manejador de errores se basa en un caso de ejemplo en que una empresa implicada en transacciones de procesos desea desarrollar una rutina para manejar 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 cola
de WebSphere MQ.
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, que es la modalidad predeterminada de funcionamiento en z/OS.
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 con información sobre números de personal.
El subflujo de gestión de errores genera cualquier mensaje siempre que se hayan producido errores en una cola.
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 manejo 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 la cola en el subflujo del manejador de errores está fuera de control
transaccional para garantizar que no se restituye la información sobre errores.
Los mensajes
Se proporcionan dos mensajes de entrada para ejecutar el ejemplo Manejador de errores:
- Un mensaje que contiene un número de serie de personal válido
- Un mensaje que contiene un número de serie de personal no válido
El mensaje de personal válido aparece en el código XML siguiente:
<Staff>
<StaffNumber>1</StaffNumber>
<NameInfo>
<LastName>Smith</LastName>
<FirstName>Jack</FirstName>
</NameInfo>
</Staff>
El mensaje de personal no válido aparece en el código XML siguiente:
<Staff>
<StaffNumber>99</StaffNumber>
<NameInfo>
<LastName>Doe</LastName>
<FirstName>Jane</FirstName>
</NameInfo>
</Staff>
Los flujos de mensajes
El diagrama siguiente muestra el flujo de mensajes principal.

El diagrama 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 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; STAFF_UPDATE_ERROR |
Compute |
Copiar mensaje; Crear mensaje de salida |
Filter |
Check Valid Staff Number; Check Backout Count |
Throw |
Throw; Throw to Complete Rollback |
TryCatch |
TryCatch |
Subflow |
Error_Handler |
Para obtener más información, consulte
Nodos incorporados y
Utilizar subflujos
en la documentación de WebSphere Message Broker.
Ruta seguida por el mensaje válido de personal
Cuando el mensaje de personal válido se coloca en la cola de entrada, el mensaje viaja a través de los nodos.
Si no hay ninguna cola inhabilitada, el mensaje no podrá seguir esta ruta.
- En el flujo de mensajes principal:
- Nodo STAFF_IN. Este nodo obtiene el mensaje de entrada de la cola de entrada.
- Nodo Error_Handler. Este nodo representa el subflujo de gestión de errores.
El mensaje deja el flujo de mensajes principal y entra en el subflujo.
- En el subflujo:
- Nodo Start Subflow. El mensaje pasa al nodo siguiente en el flujo.
- Nodo Check Backout Count. Este nodo comprueba si la cuenta de retrotracciones es cero.
Puesto que es la primera vez que el mensaje de entrada pasa a través de este nodo, el contador estará en cero y el mensaje pasará al nodo siguiente.
Si el contador fuera mayor que cero, el mensaje se elimina.
- Nodo TryCatch. Ya que el número de personal es válido, el mensaje
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 detectado este número de personal no válido, el mensaje pasará al nodo STAFF_UPDATE_ERROR.
- Nodo Back To Main Flow. El mensaje deja el subflujo y vuelve al flujo de mensajes principal.
- En el flujo de mensajes principal:
- Nodo Check Valid Staff Number. Ya que el número de personal es válido, el mensaje pasa al nodo Update Staff
Database.
- Nodo Update Staff Database. La base de datos STAFFDB se actualiza con los detalles de personal que hay en el mensaje.
- Nodo STAFF_OUT. Este nodo coloca el mensaje en la cola STAFF_OUT.
- Si no tiene una base de datos, el mensaje seguirá en la cola a través del terminal Failure.
Este caso de ejemplo demuestra este ejemplo sin utilizar una base de datos y no debe utilizarse en producción.
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 en esta sección.
Si no hay ninguna cola inhabilitada, el mensaje no podrá seguir esta ruta.
Para obtener más información sobre lo que hace cada nodo, consulte Nodos incorporados
en la documentación de WebSphere Message Broker.
- En el flujo de mensajes principal:
- Nodo STAFF_IN. Este nodo obtiene el mensaje de entrada de la cola de entrada.
- Nodo Error_Handler. Este nodo representa el subflujo de gestión de errores.
El mensaje deja el flujo de mensajes principal y entra en el subflujo.
- En el subflujo:
- Nodo Start Subflow. El mensaje pasa al nodo siguiente en el flujo.
- Nodo Check Backout Count. Este nodo comprueba si la cuenta de retrotracciones es cero.
Puesto que es la primera vez que el mensaje de entrada pasa a través de este nodo, el contador estará en cero y el mensaje pasará al nodo siguiente.
Compare con el paso 5b más adelante en esta sección.
- Nodo TryCatch. El número de personal en el mensaje no es válido, pero esto todavía no se ha descubierto.
El mensaje de entrada se pasa al nodo Back To Main Flow, en lugar de al nodo STAFF_UPDATE_ERROR.
- Nodo Back To Main Flow. El mensaje deja el subflujo y vuelve al flujo de mensajes principal.
- En el flujo de mensajes principal:
- Nodo Check Valid Staff Number. Puesto que el número de personal no es válido,
el mensaje se pasa al nodo Throw, en lugar de pasar al nodo Update Staff Database.
- Nodo Throw. Este nodo detiene el proceso del mensaje y anota el número de error "3001" y el texto "Invalid staff number" en el contenido del mensaje.
El mensaje se restituye a, es decir, el mensaje se propaga de nuevo al punto de control, que en este caso es el nodo TryCatch en el subflujo.
- En el subflujo:
- Nodo TryCatch. Este nodo reconoce que se ha producido una excepción en el proceso
del mensaje y pasa el mensaje al nodo STAFF_UPDATE_ERROR.
- Nodo STAFF_UPDATE_ERROR. El mensaje se envía a la cola STAFF_UPDATE_ERROR.
- Nodo Throw To Complete Rollback. Este nodo detiene el proceso del mensaje y registra
el número "3002" y el texto "Procedente del flujo de mensajes Error_Handler."
en el 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 fase es la última 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 STAFF_UPDATE_ERROR, externa al control transaccional, seguirá estando confirmada.
- En el flujo de mensajes principal:
- Nodo STAFF_IN. Puesto que se ha producido una excepción en el proceso del mensaje, el mensaje pasa al nodo STAFF_FAIL, en lugar de pasar de nuevo a través del flujo de mensajes.
- Nodo 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í.
El mensaje se devuelve al nodo STAFF_IN y, a continuación, al subflujo.
A
continuación, el mensaje llega al nodo Check Backout Count, que comprueba si la cuenta de retrotracciones está a cero.
Puesto que el mensaje
ha pasado a través de este nodo anteriormente, el contador de restituciones ya no es cero y se elimina el mensaje. Al eliminar el mensaje se evita que se produzca una situación en que, si se ha inhabilitado la cola STAFF_FAIL, el mensaje seguirá viajando a través del flujo. Compare este paso con el paso 2b.
Cuando se utiliza un nodo TryCatch o cuando se adjuntan nodos al terminal Catch de un nodo MQInput, puede suponer
que no se confirma ningún proceso que se haya producido en la ruta de prueba, si los nodos están configurados correctamente, siempre que se invoque la
ruta de captación.
Esta suposición no es correcta.
Por ejemplo, si se actualiza una base de datos de la ruta de prueba bajo control transaccional y se invoca la ruta de captación y se completa normalmente, la actualización de la 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, el ejemplo siguiente muestra 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
Send message to STAFF_UPDATE_ERROR queue
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.
Por lo tanto, el manejador de errores utiliza las estructuras siguientes:
- La actualización de la base de datos, STAFFDB, en la ruta de prueba está
dentro del control transaccional.
- La actualización de la cola, STAFF_UPDATE_ERROR, en la vía de acceso de captación está fuera del control transaccional.
- 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.
- El mensaje se restituye a continuación en la ruta de anomalías al nodo MQInput y, de allí, a la cola de anomalías.
Para obtener más información, consulte
Transacciones de flujos de mensajes
en la documentación de WebSphere Message Broker.
Volver a la página inicial del ejemplo